Dzisiejszy wpis jest ogólny. Nie chcę wchodzić zbyt wąskie dziedziny cyberbezpieczeństwa. Na przestrzeni lat zdobyłem doświadczenie, które pomaga mi odnaleźć się w codziennych zadaniach w zakresie bezpieczeństwa chmury. Jest to tylko i wyłącznie moje spojrzenie na to zaganienie. Dobrze jest mieć własną opinię w danym temacie.
Spoglądając na mapy takie jak The Map of Cybersecurity Domains Henry Jiang | March 2021 | REV 3.0; można odnieść wrażenie że bezpieczeństwo chmury to tylko mały wycinek całości. Pomimo dobrej szczegółowości, nie do końca akurat zgodziłbym się z oznaczeniem "Cloud security" na mapie przedstawionej przez autora. Cloud to całe środowisko - gdzie w szczególności wyróżnia się dwa podstawowe - on-premise oraz samą chmurę. Nie umieściłbym więc cloud security na tym diagramie - a raczej traktował cały ten diagram jako coś do czego można się odnieść chcąc zadbać o security chmury.
To samo więc odniósłbym do innych diagramów - przykładowo https://roadmap.sh/devsecops - gdzie jeszcze bardziej uproszczono diagram do CSPM/IAM/Key Management Service. Wybrano 3 elementy, na które warto zwrócić uwagę wśród dziesiątek, na które musimy zwrócić uwagę. Nie mówię, że Cloud Security Posture Management jest złe, ale czy zawsze jest to rozwiązanie optymalne?
Pytanie więc pojawia się następujące: Jak mogę zabezpieczyć swoje środowisko chmurowe? Moim zdaniem należy zacząć od podstawy formalności i branżowych procesów, a w szczególności procesu Risk Management.
Risk Management
Nie możemy być w 100% bezpieczni - musimy zgodzić się na pewne ryzyko (risk acceptance).
Jak ocenić poziom akceptowalnego ryzyka? Jak ogólnie odnieść się do ryzyka i je obliczyć?
O tym może w osobnym poście - ale na pewno polecam książkę "How to measure Anything in Cybersecurity Risk" Douglas W.Hubbard & Richard Seiersen.
Powołując się na książki z certyfikacji CISSP, można wyróżnić trzy podstawowe kroki:
- Value (Identyfikacja assetów dla naszej organizacji oraz ich ocena)
- Risk analysis (Określenie ryzyka dla każdego assetu w kontekście konkretnych "Threats".)
- Treatment (Decyzja - Accept/Mitigate/Transfer/Avoid)
W tym temacie moglibyśmy wchodzić naprawdę w duże szczegóły. Jak w każdym z resztą temacie, gdzie celem jest uzyskanie najważniejszych informacji.
Zachęcam więc do zgłębienia tego tematu we własnym zakresie. Na pewno na ten moment dobrze jest wiedzieć mniej więcej, co jest dla mnie dopuszczalne, a co nie.
Przykładowo:
- Czy instancja zawierająca moją aplikację, może łączyć się do internetu?
- Czy chcę mieć dodatkową ochronę przed atakami DDoS od dostawcy chmury? A co jeśli ktoś dokona na mnie http flood - kto za to zapłaci?
- ...
Czyli bardzo dużo pytań, na które ciężko czasem sobie odpowiedzieć, a jeszcze ciężej jest wyprodukować ich pełną listę w kontekście wybranego środowiska.
Ryzyko powstaje tam gdzie zasób, który tworzymy. Musimy więc dobrze poznać środowisko w którym dany zasób tworzymy oraz poznać jego mechaniki.
Kiedy już wiemy jakie platfroma chmura daje nam możliwości - przykładowo w tworzeniu instancji maszyny wirtualnych, będzie nam łatwiej zadać prawidłowe pytania.
Przy małych środowiskach zależy nam na prostocie i praktycznym podejściu. Jeżeli mówimy natomiast o większym projekcie, musimy mieć możliwość poukładania wszystkiego w jedną zgodną z "compliance" całość - od Framework'ów. Temat Framework'ów jest zbyt głęboki, aby omawiać go w prostym poście - ale polecam rozejrzeć się w kontekście Cybersecurity frameworks. Można przykładowo sporjzeć na prosty framework zawierający "Security Controls" o nazwie - CIS Security Matrix.
Wszystko zależy od skali.
To właśnie od skali naszego biznesu i ilości miejsc w których ryzyko się pojawia, zależy to w jaki sposób będziemy musieli podejść do całości zagadnienia zabezpieczenia środowiska chmurowego.
Małe środowiska / projekty
Masz małe środowisko, niskie ryzyko? Często spotykanym podejściem jest praktyczne podejście do bezpieczństwa. Czyli to znajomość platformy/oprogramowania osoby wdrażającej środowisko i jego świadomość istniejących zagrożeń będzie świadczyła o renomie Twojego środowiska. Jeżeli osoba nie ma wystarczających umiejętności, Twoje zasoby będą podatne na kompromitację.
Niestety mało kto na tym poziomie inwestycji znajduje czas i zasoby na analizę kontroli bezpieczeństwa z CIS Framework oraz przeprowadzenie testów penetracyjnych.
Poznaj zasady gry - access control
"Controlling acces to any resource in a secure system involves two entities. Subject - the active entity that requests access to a resource . Object - the pasive entity that the subject want to access.
Authorization or access control is the management of the realtionship between subjects and objects.
Podstawowe zabezpieczenie środowiska chmurowego można oprzeć o klasyczny model Subject-Object Access control.
Każdy zasób w chmurze jest obiektem: maszyna wirtualna, bucket, baza danych, sekret, klucz kryptograficzny, funkcja serverless, obraz kontenera, load balancer czy API. Każdy użytkownik, aplikacja, pipeline CI/CD, service account lub inny zasób chmurowy może być podmiotem. Bezpieczeństwo zaczyna się w momencie, w którym każda relacja między podmiotem a obiektem jest jawnie zdefiniowana, monitoriowana i której zasady są możliwa do określenia.
Oznacza to że musimy zdefiniować listę zasobów w chmurze i jasno określić ich relacje oraz konfiguracje. Może tutaj nam pomóc przygotowanie diagramu dla docelowej architektury, który w dobry sposób zobrazyuje powstające ryzyka. Mozna pokusić się tutaj o proste diagramy DFD (Data Flow Diagram) lub nawet diagram DFD konkretnie ukierunkowany pod threat modeling (z zastosowaniem narzędzi takich jak OWASP Threat Dragon).
Przykładowo:
- Instancja masznyny wirtualnej - użytkownik z sieci internetowej ma dostęp do instancji maszyny wirtualnej. Dostęp jest regulowany polityki sieciowe. Dostęp może być monitorowany.
- IAM - użytkownik platformy chmurowej ma dostęp do panelu zarządzania zasobami. Dostęp jest regulowany przez polityki dostępu. Dostęp może być monitorowany.
- Aplikacja - użytkownik z sieci internetowej ma dostęp do aplikacji uruchomionej na instancji maszyny wirtualnej. Możliwe do wykonania przez aplikację zapytania są definiowane przez system IAM aplikacji. Dostęp jest regulowany przez polityki dostępu. Dostęp może być monitorowany.
- KMS (Key Management Service dla AWS) - dostęp do kluczy używanych przykładowo do szyfrowania dysków maszyny wirtualnej. Dostęp jest regulowany przez polityki sieciowe i dostępu. Dostęp może być monitorowany.
- Storage - dostęp do dysków lub cloud storgae. Dostęp jest regulowany przez polityki sieciowe i polityki dostępu. Dostęp może być monitorowany.
- ...
Jak można zauważyć skupiam się tutaj na zasobach, które wykorzystuję do przygotowania mojej produkcyjnej aplikacji oraz domyślne ustawienia konta dostawcy chmury (IAM).
Warto tutaj trzymać się podstawowych zasad kontroli oraz monitoringu dostępu:
- Need to Know
- Least Privilege
- Separation of Duties and Responsibilites
- Zero Trust / Trust but Verify
Nie sposób nie wspomnieć tutaj o podejściu Defense in Depth. Nasze kontrole bezpieczeństwa muszą być wdrożone wielowarstwowo - szczególnie musimy dopilnować poprawnej konfiguracji sieciowej.
*Source Defense in depth
Jeżeli wiemy co chcemy ochronić, docelowo dobrze jest chronić dany object/subject na wiele sposobów i nie polegać tylko na pojednycznej warstwie. Przykładem może być tutaj ograniczenie nie tylko dostępu sieciowego do dostępu dla maszyny wirtualnej, ale również właściwa polityka IAM dla użytkownika, która zezwala na dostęp tylko do ograniczonej puli zasobów, gdzie dla pozostałych kont takiego dostępu do maszyny wirtualnej nie ustanawiamy.
W przypadku projektów o większej skali, szczegółowa analiza ryzyka będzie niezbędnym krokiem do pełnego zobrazowania postury bezpieczeństwa naszego środowiska. Zastosowanie framework’ów i standardów takich jak ISO 27001, ISO 27017, NIST Cybersecurity Framework, NIST Risk Management Framework, NIST SP 800-53 może się okazać krokiem w dobrą stronę w kontekście zapewnienia dla procesu odpowiednich kroków. Nie wspominając tutaj o pozostałych standardach takich jak PCI DSS, która jest już ukierunkowana pod konkretnego odbiorcę/sektor.
Schemat pipeline contentu.