Identitet er den nye perimeteren

Forrige leksjon trakk en linje mellom det en skyleverandør sikrer og det kunden må sikre. På kundens side gjør ett element mer av jobben enn noe annet: identitet — hvem som får logge inn, og hva de deretter kan gjøre. Et tradisjonelt kontornettverk hadde en vegg og en låst dør; en skykonto har et innloggingsskjema, tilgjengelig fra hvor som helst på jorden, til enhver time. Å sikre den innloggingen er mesteparten av hva «sikkerhet i skyen» betyr i praksis.

Hvordan kontoer faktisk blir overtatt

Kontoovertakelse involverer sjelden en angriper som bryter seg inn i en skyleverandørs systemer. Den følger typisk mønsteret for tyveri av legitimasjon fra trusselmodellerings-kurset i denne akademien: et passord gjenbrukt fra en lekket, urelatert tjeneste, eller en overbevisende phishing-side som ganske enkelt ber om innloggingen direkte. Når en angriper har gyldig legitimasjon, har de fleste skytjenester ingen måte å skille dem fra den ekte kontoeieren — noe som er nøyaktig hvorfor den ene kontrollen CISA fremhever over alle andre er flerfaktorautentisering (MFA).

MFA, og hvorfor ikke alle former er like gode

CISA sier rett ut at «brukere som slår på MFA er betydelig mindre sannsynlige å bli hacket», fordi et stjålet passord alene slutter å være nok. Men CISA rangerer også de tilgjengelige formene for MFA etter hvor godt de motstår phishing, og rangeringen betyr noe: «den eneste utbredte phishing-resistente autentiseringen er FIDO/WebAuthn-autentisering» — standarden bak passkeys og maskinvare-sikkerhetsnøkler, dekket i kryptografi-kurset. En tekstmeldingskode er, i CISAs ord, fortsatt mye bedre enn ingen andre faktor, men den kan avskjæres eller videresendes av en tilstrekkelig motivert angriper; push-varsler i apper med tallmatching ligger et sted i mellom. For en skykonto som inneholder noe sensitivt, er å slå på den sterkeste MFA-muligheten kontoen tilbyr det enkelttiltaket med høyest verdi i denne leksjonen.

OAuth: tillatelsene du gir til andre apper

Hver gang du klikker «fortsett med Google» eller kobler et planleggingsverktøy til kalenderen din, bruker du OAuth, beskrevet av standardens egen dokumentasjon som «bransjestandarden for autorisasjon». Den nyttige egenskapen er at tredjepartsappen aldri ser passordet ditt — du logger inn direkte med leverandøren din, og godkjenner deretter et spesifikt, begrenset sett med tillatelser, kalt scopes, for den appen. Risikoen er nettopp den tillatelsen: en planleggingsapp som bare trenger å lese ledig/opptatt-tidene i kalenderen din, kan be om, og rutinemessig få, tillatelse til å lese og sende e-post som deg. Hver tilkoblede app er en stående tilgangsbevilgning som består til noen tilbakekaller den, noe som er hvorfor den siste leksjonen i dette kurset dekker gjennomgang av den listen, ikke bare å sette den opp riktig én gang.

Lekkede nøkler: OAuths mindre synlige søskenbarn

Automatiserte verktøy og integrasjoner autentiserer ofte med en API-nøkkel i stedet for en menneskelig innlogging — en lang streng som fungerer som et passord, men som ikke skrives inn av en person og ofte ikke er beskyttet av MFA i det hele tatt. Disse nøklene ender opp eksponert oftere enn de fleste forventer: limt inn i en support-sak, ved et uhell forpliktet til et kodelager, etterlatt i en konfigurasjonsfil delt bredere enn tiltenkt. Å behandle en API-nøkkel med samme forsiktighet som et passord — aldri dele den i klartekst, rotere den hvis den kan ha vært eksponert, og begrense hva den får lov til å gjøre — lukker et gap som MFA, bygget for menneskelige innlogginger, ikke dekker.