Dlaczego Zero Trust ma sens w świecie mikroserwisów i Kubernetes
Tradycyjne „zaufaj sieci” kontra chmura i mikroserwisy
W klasycznej infrastrukturze bezpieczeństwo często opierało się na prostym założeniu: sieć wewnętrzna jest „bezpieczna”, Internet jest „zły”. Stawiało się mocny firewall na brzegu, dzieliło VLAN-y, dorzucało IPS/IDS i uznawało temat za w miarę zamknięty. W świecie chmury i mikroserwisów takie podejście rozpada się w drobny mak: usługi komunikują się dynamicznie, pody pojawiają się i znikają, ruch przechodzi przez wiele warstw abstrakcji, a granica „wewnątrz / na zewnątrz” jest praktycznie nie do zdefiniowania.
Kubernetes sam z siebie nie implementuje żadnego założenia „sieć wewnętrzna jest zaufana”. On po prostu zapewnia płaską, routowalną sieć między podami. Jeśli nie zrobisz nic więcej, każdy pod może rozmawiać z każdym innym. Wystarczy jedno skuteczne włamanie do słabiej chronionego mikroserwisu, aby atakujący mógł przeskakiwać pomiędzy usługami, aż w końcu trafi na coś naprawdę cennego, jak baza danych z danymi klientów czy system płatności.
Do tego dochodzą zewnętrzne komponenty: zdalni pracownicy, VPN-y, integracje z partnerami, CI/CD w chmurze. Trudno tu mówić o jakiejkolwiek „zamkniętej sieci”, jeśli pipeline z zewnętrznego SaaS-a ma dostęp do API klastra produkcyjnego. Bez podejścia Zero Trust całość konstrukcji opiera się w dużej mierze na zaufaniu, że nikt nie popełni błędu konfiguracyjnego i że każde ogniwo łańcucha jest szczelne.
Cechy mikroserwisów, które zwiększają powierzchnię ataku
Architektura mikroserwisowa bywa przedstawiana jako panaceum na wszystkie problemy, ale z perspektywy bezpieczeństwa jest to po prostu dużo więcej ruchomych części. Zamiast jednego monolitu m