Cloud Security Architecture

Data: 2020-11-18
Autor: Sebastian Konkol
Cloud Security Architecture

W kilku ostatnich projektach – w firmie z branży bankowości, branży bardzo świadomej zagadnień bezpieczeństwa – w których całość rozwiązania działała w oparciu o chmurę, miałem przyjemność pełnić rolę doradcy w zakresie architektury bezpieczeństwa. W tych projektach powtarzała się ewolucja myślenia o bezpieczeństwie w kontekście rozwiązań chmurowych – od robienia tradycyjnie (rozwiązania on-premises) do nowocześnie (chmura). Może być ciekawie?

Cloud zmienia wszystko – to na dzisiaj już chyba oczywista oczywistość, choć nie we wszystkich aspektach (np. procesy zakupowe) dopasowaliśmy już do tego SOP (Standard Operating Procedures). Najczęściej wymaga przejścia do fundamentów, bo zbyt wiele naszych praktyk zasadza się na fundamentach on-premises. Analogiczna sytuacja dotyczy bezpieczeństwa, gdzie architektura bezpieczeństwa on-premises opierała się np. o bezpieczeństwo fizyczne (wejście do serwerowni, dostęp do macierzy dyskowych) i dzięki temu wyższe „warstwy” mogły działać z założeniem istnienia bezpieczeństwa fizycznego, na czym opierają się praktyki tworzenia rozwiązań bezpieczeństwa w tych warstwach wyższych. Przeniesienie tych praktyk na tworzenie rozwiązań w chmurze pozbawia je bezpiecznego fundamentu. Aby pokazać, jak bardzo, posłużę się kilkoma przykładami, jak zmienia się myślenie o elementach architektury bezpieczeństwa: tożsamość użytkownika bez „własnego” (zaufanego?) dostawcy tożsamości, komunikacja między komponentami wymagająca wzajemnego uwierzytelnienia, obowiązkowy audit trail i automatyka egzekwowania polityk dostępu, czy procedury backup / odtwarzanie bez „własnego” zasobu archiwalnego. To zaledwie takie hardcore’owe bezpieczeństwo, pomijając szersze spojrzenie (np. Legal Compiiance, Business Continuity, Disaster Recovery czy informatyka śledcza).

Bezpieczeństwo w chmurze to wszechobecna współdzielona odpowiedzialność, gdzie za coś odpowiada dostawca chmury, za coś odpowiada użytkujący chmurę (pomijając, że jest to odpowiedzialność kontraktowa). Wszyscy znamy „drabinkę odpowiedzialności” (fizyczna, infrastruktura, wirtualizacja, sieć, system operacyjny, aplikacja, dane, dostęp użytkownika) dla IaaS, PaaS i SaaS, ale to rysunek poglądowy. Prawdziwa dyskusja zaczyna się w prawdziwym świecie na prawdziwych rozwiązaniach będących najczęściej patchworkiem IaaS, PaaS i SaaS (często od różnych dostawców). Kilka, chyba podstawowych acz bardziej chmurowych, przykładów odmienności spojrzenia na architekturę bezpieczeństwa. Ponieważ wszystko w chmurze jest współdzielone, ufać można tylko takiemu zabezpieczeniu, jakie się samemu, explicite skonstruuje (Zero Trust). Zważywszy na to, że użytkuje się konfiguracyjnie wydzieloną część infrastruktury, nie ma strefy bezpiecznej otaczającej komponent – granica komponentu staje się perymetrem (w zasadzie więc pojęcie perymetru traci sens). Szyfrowanie on-transit w relacji end-to-end przy konstrukcji topologii sieci w oparciu o usługi dostawcy (czyt. nie zaufane) oznacza szyfrowanie między naszym komponentem i naszym komponentem, bez „przeszyfrowywania” po drodze (wszystkie gateway’e, bridge to nie są elementy zaufane). Polecam intelektualny eksperyment szyfrowania danych w bazie danych (at rest), a szczególnie ich odszyfrowywania.

A prawdziwa zabawa zaczyna się dopiero wtedy, jak zaczniemy działać w trybie hybrid cloud czy multicloud

Zagadnienia architektury bezpieczeństwa w chmurze są znacząco odmienne od ich odpowiedników w komfortowym otoczeniu on-premises. Z tego wszystkiego wynika jednoznacznie, skąd taki nacisk na składowe architektury bezpieczeństwa (IAM, DLP, IDS/IPS, SIEM), skąd taka waga API. Z tego także wynika, że jedynym poprawnym podejściem jest risk-based assessment i dopasowanie do wyników rozwiązań bezpieczeństwa. Architektura bezpieczeństwa to nie jest działalność czysto inżynierska, opierająca się wyłącznie na wiedzy o tym, jak ma działać rozwiązanie, dla którego tworzona jest architektura bezpieczeństwa. Opiera się ona na ocenie ryzyka wysnutego z wiedzy o tym, czemu ma służyć rozwiązanie i w jakiej działalności biznesowej ma uczestniczyć, w jakim kontekście realizować swoje zadania i jak realizacja tych zadań może wpłynąć na biznes. Tworzenie architektury bezpieczeństwa polega na doborze zabezpieczeń adekwatnych do tak określonego ryzyka – zabezpieczeń w bardzo szerokiej gamie obszarów. W myśleniu o bezpieczeństwie w chmurze obowiązuje bowiem zupełnie inny paradygmat.

W przypadku on-premises zakładaliśmy, że środowisko jest bezpieczne, a rozwiązania bezpieczeństwa służyły raczej zapewnieniu bezpieczeństwa środowiska. Możemy tak założyć, bo wszak nasze Data Centre to i tak nasza odpowiedzialność, więc domyślne zaufanie dla środowiska on-premises jest uzasadnione. W chmurze możemy założyć jedynie, że bezpieczne jest to, co tworzymy, a całą resztę należy zaprojektować. Operator chmury nie podlega regule domyślnego zaufania. Architektura bezpieczeństwa w chmurze to zupełnie inna historia.

Pozostaw komentarz