Identitet är den nya perimetern

Föregående lektion drog en linje mellan vad en molnleverantör säkrar och vad kunden måste säkra. På kundens sida gör en sak mer jobb än något annat: identitet — vem som får logga in, och vad de sedan kan göra. Ett traditionellt kontorsnätverk hade en vägg och en låst dörr; ett molnkonto har ett inloggningsformulär, nåbart från var som helst på jorden, när som helst. Att säkra den inloggningen är det mesta av vad ”säkerhet i molnet” betyder i praktiken.

Hur konton faktiskt tas över

Kontoövertagande involverar sällan en angripare som bryter sig in i en molnleverantörs system. Det följer oftast mönstret för stöld av autentiseringsuppgifter från hotmodelleringskursen i den här akademin: ett lösenord återanvänt från en läckt, orelaterad tjänst, eller en övertygande nätfiskesida som helt enkelt frågar efter inloggningen direkt. När en angripare har giltiga autentiseringsuppgifter har de flesta molntjänster inget sätt att skilja dem från den riktiga kontoägaren — vilket är precis varför den enskilda kontroll CISA framhäver mest av alla är flerfaktorsautentisering (MFA).

MFA, och varför inte alla former är likvärdiga

CISA säger rakt ut att ”användare som aktiverar MFA är betydligt mindre benägna att bli hackade”, eftersom ett stulet lösenord ensamt slutar räcka. Men CISA rangordnar också de tillgängliga formerna av MFA efter hur väl de motstår nätfiske, och rangordningen spelar roll: ”den enda allmänt tillgängliga nätfiskeresistenta autentiseringen är FIDO/WebAuthn-autentisering” — standarden bakom passkeys och hårdvarusäkerhetsnycklar, som täcks i kryptografikursen. En textmeddelandekod är, med CISAs ord, fortfarande mycket bättre än ingen andra faktor, men den kan avlyssnas eller vidarebefordras av en tillräckligt motiverad angripare; app-baserade push-aviseringar med sifferparning ligger däremellan. För ett molnkonto som innehåller något känsligt är att slå på det starkaste MFA-alternativet kontot erbjuder det enskilda steget med högst värde i den här lektionen.

OAuth: behörigheterna du ger till andra appar

Varje gång du klickar på ”fortsätt med Google” eller ansluter ett schemaläggningsverktyg till din kalender använder du OAuth, beskrivet av standardens egen dokumentation som ”branschstandarden för auktorisering”. Dess användbara egenskap är att tredjepartsappen aldrig ser ditt lösenord — du loggar in direkt med din leverantör, och godkänner sedan en specifik, begränsad uppsättning behörigheter, kallade scopes, för den appen. Dess risk är precis den behörighetstilldelningen: en schemaläggningsapp som bara behöver läsa ledig/upptagen-tider i din kalender kan be om, och rutinmässigt beviljas, behörighet att läsa och skicka e-post som dig. Varje ansluten app är en stående åtkomsttilldelning som består tills någon återkallar den, vilket är varför den sista lektionen i den här kursen tar upp att granska den listan, inte bara att ställa in den korrekt en gång.

Läckta nycklar: OAuths mindre synliga kusin

Automatiserade verktyg och integrationer autentiserar ofta med en API-nyckel istället för en mänsklig inloggning — en lång sträng som fungerar som ett lösenord men som inte skrivs av en person och ofta inte skyddas av MFA alls. Dessa nycklar hamnar exponerade oftare än de flesta förväntar sig: inklistrade i ett supportärende, oavsiktligt incheckade i ett kodförråd, kvarlämnade i en konfigurationsfil delad bredare än avsett. Att behandla en API-nyckel med samma försiktighet som ett lösenord — aldrig dela den i klartext, rotera den om den kan ha exponerats, och begränsa vad den får göra — täpper till ett gap som MFA, byggd för mänskliga inloggningar, inte täcker.