Tożsamość jest nowym obwodem obronnym

Poprzednia lekcja wyznaczyła granicę między tym, co zabezpiecza dostawca chmury, a tym, co musi zabezpieczyć klient. Po stronie klienta jedna rzecz ma większe znaczenie niż wszystko inne: tożsamość — kto może się zalogować i co potem może zrobić. Tradycyjna sieć biurowa miała ścianę i zamknięte drzwi; konto w chmurze ma formularz logowania, dostępny z dowolnego miejsca na Ziemi, o dowolnej porze. Zabezpieczenie tego logowania to w praktyce większość tego, co oznacza „bezpieczeństwo w chmurze”.

Jak faktycznie przejmuje się konta

Przejęcie konta rzadko wiąże się z włamaniem atakującego do systemów dostawcy chmury. Zwykle przebiega według schematu kradzieży danych uwierzytelniających znanego z kursu o modelowaniu zagrożeń w tym uniwersytecie: hasło powtórnie użyte z innej, zaatakowanej usługi, albo przekonująca strona phishingowa, która po prostu prosi wprost o dane logowania. Gdy atakujący ma już ważne dane uwierzytelniające, większość usług chmurowych nie ma jak odróżnić go od prawdziwego właściciela konta — dlatego właśnie pojedynczą kontrolą, którą CISA wskazuje ponad wszystkie inne, jest uwierzytelnianie wieloskładnikowe (MFA).

MFA i dlaczego nie wszystkie jego formy są równe

CISA stwierdza wprost, że „użytkownicy, którzy włączają MFA, są znacznie mniej narażeni na włamanie”, ponieważ samo skradzione hasło przestaje wystarczać. Ale CISA szereguje też dostępne formy MFA według odporności na phishing, i ta kolejność ma znaczenie: „jedynym powszechnie dostępnym uwierzytelnianiem odpornym na phishing jest uwierzytelnianie FIDO/WebAuthn” — standard stojący za kluczami dostępu (passkeys) i sprzętowymi kluczami bezpieczeństwa, omówiony w kursie o kryptografii. Kod SMS jest, słowami CISA, wciąż dużo lepszy niż brak drugiego składnika, ale może zostać przechwycony lub przekierowany przez wystarczająco zdeterminowanego atakującego; powiadomienia push w aplikacji z dopasowaniem liczby plasują się pomiędzy. Dla konta w chmurze przechowującego cokolwiek wrażliwego, włączenie najsilniejszej opcji MFA oferowanej przez to konto to pojedynczy krok o najwyższej wartości z tej lekcji.

OAuth: uprawnienia, które przyznajesz innym aplikacjom

Za każdym razem, gdy klikasz „kontynuuj z Google” albo łączysz narzędzie do planowania ze swoim kalendarzem, korzystasz z OAuth, opisywanego przez dokumentację samego standardu jako „branżowy standardowy protokół autoryzacji”. Jego użyteczną cechą jest to, że aplikacja firmy trzeciej nigdy nie widzi twojego hasła — logujesz się bezpośrednio u swojego dostawcy, a następnie zatwierdzasz konkretny, ograniczony zestaw uprawnień, zwanych zakresami (scopes), dla tej aplikacji. Jego ryzykiem jest dokładnie to przyznanie uprawnień: aplikacja do planowania, która potrzebuje tylko odczytać, kiedy masz wolny czas w kalendarzu, może poprosić o uprawnienie do odczytywania i wysyłania poczty w twoim imieniu — i rutynowo je otrzymać. Każda połączona aplikacja to trwałe przyznanie dostępu, które utrzymuje się, dopóki ktoś go nie cofnie, dlatego ostatnia lekcja tego kursu omawia przeglądanie tej listy, a nie tylko poprawne skonfigurowanie jej raz.

Wyciekłe klucze: mniej widoczny kuzyn OAuth

Zautomatyzowane narzędzia i integracje często uwierzytelniają się kluczem API zamiast ludzkiego logowania — długim ciągiem znaków, który działa jak hasło, ale nie jest wpisywany przez człowieka i często w ogóle nie jest chroniony przez MFA. Takie klucze wyciekają częściej, niż większość ludzi się spodziewa: wklejone do zgłoszenia wsparcia technicznego, przypadkowo dodane do repozytorium kodu, pozostawione w pliku konfiguracyjnym udostępnionym szerzej niż zamierzono. Traktowanie klucza API z taką samą ostrożnością jak hasła — nigdy niedzielenie się nim jawnym tekstem, wymiana go, jeśli mógł wyciec, i ograniczanie tego, co wolno mu robić — zamyka lukę, której MFA, zbudowane dla ludzkich logowań, nie obejmuje.