Att härda dina molnkonton

De föregående tre lektionerna i den här kursen täckte vem som ansvarar för vad, varför identitet är den verkliga perimetern, och vad som händer med din data när den väl är lagrad. Den här lektionen gör det till en kort, återkommande genomgång — den typ av underhåll en liten organisation realistiskt kan hålla igång, snarare än en engångskonfiguration som tyst blir föråldrad.

Granska aktiva sessioner och enheter

Varje större kontoleverantör håller en lista över enheter och sessioner som för närvarande är inloggade, och en logg över senaste aktivitet. Att granska den regelbundet besvarar en enkel fråga: är någon annan än de som borde vara det inne på det här kontot? En okänd enhet, en inloggning från en oväntad plats, eller en session som aldrig loggades ut på en enhet du inte längre äger är alla värda att agera på omedelbart — avsluta sessionen och byta lösenord. Det här följer direkt av identitetslektionen tidigare i den här kursen: ett stulet lösenord förblir användbart för en angripare bara så länge den resulterande sessionen förblir obemärkt.

Granska tredjepartsappars åtkomst

Identitetslektionen tog också upp OAuth: varje ”fortsätt med”-anslutning eller kalenderintegration är en stående åtkomsttilldelning som består tills den återkallas. De flesta leverantörer listar varje ansluten app under ett kontos säkerhets- eller integritetsinställningar, och visar vad var och en beviljades — läsa e-post, hantera kalender, komma åt filer — ofta för en tjänst du provade en gång för flera år sedan och glömde bort. En återkommande, ibland genomförd rensning av den här listan, genom att ta bort allt oanvänt eller okänt, minskar antalet vägar in i ett konto utan att röra lösenordet alls.

Bekräfta att säkerhetskopior faktiskt finns, och var

Ett molnkontofel — en utelåsning, en felaktig radering, ett tjänsteavbrott — är i sig en risk som lektionen om delat ansvar placerade på kundens sida av linjen. Den GitHub-publicerade molnsäkerhetsguiden den här lektionen korskontrollerar mot listar ”säkerhetskopior, testad återställning” bland de centrala motståndskraftspraxis den rekommenderar, tillsammans med rutinmässig rotation av autentiseringsuppgifter och åtkomstgranskningar; det stämmer överens med motsvarande vägledning stora leverantörer publicerar för sina egna kunder. För en individ eller liten organisation översätts det till två konkreta vanor: vet var din säkerhetskopia faktiskt finns (en andra molntjänst, en krypterad extern disk, eller båda), och testa faktiskt att återställa från den ibland, eftersom en säkerhetskopia ingen har öppnat bara är ett hopp, inte en plan.

Slå på loggning och aviseringar där de finns

De flesta konsument- och småföretagsmolnkonton erbjuder någon form av säkerhetsavisering — ett e-postmeddelande eller push-avisering för en ny inloggning, ett lösenordsbyte, eller en ny enhet som lagts till. Dessa är oftast valfria eller gömda i inställningar snarare än standard. Att slå på dem kostar inget och förkortar direkt gapet mellan att ett konto komprometteras och att någon märker det, vilket ofta är den enskilda faktor som betyder mest för hur mycket skada ett intrång orsakar.

Att göra detta till en vana, inte en engångsuppgift

Ingen av dessa fyra kontroller tar mer än några minuter var för sig, och ingen av dem kräver säkerhetsbakgrund. Det som gör dem effektiva är upprepning: en kvartalsvis genomgång av sessioner, anslutna appar, säkerhetskopiestatus och aviseringsinställningar fångar den långsamma ansamlingen av glömd åtkomst som en enda konfigurationssession aldrig kommer att göra. Det här sluter cirkeln den här kursen öppnade med modellen för delat ansvar: leverantören säkrar infrastrukturen en gång och underhåller den kontinuerligt; kundens sida av samma överenskommelse är en vana, inte en uppgift att bli klar med.