Share via

Zabezpieczenia usługi AKS

  • Artykuł

W tym artykule przedstawiono aspekty ładu zabezpieczeń usługi Azure Kubernetes Service (AKS), które należy wziąć pod uwagę przed wdrożeniem dowolnego rozwiązania.

W tym artykule opisano sposób implementowania rozwiązań przy użyciu platformy Azure i oprogramowania open source. Decyzje podejmowane podczas tworzenia strefy docelowej w skali przedsiębiorstwa mogą częściowo wstępnie zdefiniować ład. Aby zrozumieć zasady ładu, zobacz Zarządzanie zabezpieczeniami i zgodność w skali przedsiębiorstwa.

Powierzchnie ataków

Podczas tworzenia strategii zabezpieczeń dla klastrów Kubernetes należy wziąć pod uwagę następujące pięć powierzchni ataków:

  • Kompilacja
  • Rejestr
  • Klaster
  • Węzeł
  • Aplikacja

Dla każdej kategorii omawiamy główne zagrożenia, które należy wziąć pod uwagę i zaradcze dla tych zagrożeń.

Tworzenie zabezpieczeń

Zabezpieczenia kompilacji dotyczą odpowiedniego użycia metodyki DevSecOps z obrazami kontenerów.

Poważne zagrożenia

Słaba konfiguracja obrazu może prowadzić do luk w zabezpieczeniach w dół potoku. Na przykład możesz mieć kontenery z większymi uprawnieniami, niż są potrzebne. Kontenery mogą być również skonfigurowane tak, aby zezwalały na określony dostęp do sieci, co może stanowić zagrożenie dla systemu. Ograniczenie dozwolonych wywołań systemowych do tych wywołań wymaganych do bezpiecznego działania kontenerów może zwiększyć ryzyko naruszenia zabezpieczeń kontenera.

Inna luka w zabezpieczeniach może umożliwić kontenerowi uzyskanie dostępu do poufnego katalogu hosta lub zezwolenie kontenerom na zmianę lokalizacji kontrolujących podstawową funkcję hosta.

Nieplanowane kontenery są nieplanowane w środowisku. Mogą one być wynikiem testowania kodu przez deweloperów w środowiskach testowych. Te kontenery mogły nie przechodzić rygorystycznego skanowania pod kątem luk w zabezpieczeniach lub być prawidłowo skonfigurowane. Te luki w zabezpieczeniach mogą otwierać punkt wejścia dla osób atakujących.

Używanie obrazów bazowych, które nie pochodzą z zaufanych źródeł lub nie są aktualne w przypadku aktualizacji zabezpieczeń, może również prowadzić do luk w zabezpieczeniach w kontenerach używanych do kompilowania.

Środki zaradcze ryzyka

Zabezpieczenia kompilacji dotyczą implementacji metodyki DevSecOps w celu przesunięcia zabezpieczeń w lewo i skorygowania większości problemów przed rozpoczęciem przechodzenia w dół potoku. Nie chodzi o umieszczenie całej własności na deweloperów, ale udostępnianie własności operacjom. Deweloperzy mogą następnie wyświetlać i korygować luki w zabezpieczeniach i problemy ze zgodnością, które mogą rzeczywiście rozwiązać.

Możesz utworzyć potok, który skanuje kompilacje i kończy się niepowodzeniem, ponieważ ma jedną lub 10 krytycznych luk w zabezpieczeniach. Lepszym podejściem może być przyjrzenie się następnej warstwie w dół. Możesz zacząć segmentować punkt odpowiedzialności na podstawie stanu dostawcy.

Ustaw próg w warstwie stanu luki w zabezpieczeniach. Wszystkie elementy ze stanem Otwórz, Nie rozwiążą problemu lub Odroczone będą nadal przepływać w dół potoku, w którym secOps może uzyskać dostęp do ryzyka, tak jak obecnie. Luka w zabezpieczeniach ze stanem dostępnych poprawek dostawcy to coś, co deweloper może rozwiązać. Korzystanie z okresów prolongaty umożliwia deweloperom korygowanie luk w zabezpieczeniach.

Wraz z oceną luk w zabezpieczeniach jest ocena zgodności. Na przykład zezwolenie obrazowi na uruchamianie jako użytkownik główny lub uwidacznianie protokołu SSH powoduje przerwanie stanu zgodności większości przedsiębiorstw. Rozwiąż ten problem podczas kompilacji zamiast podczas wdrażania.

Zazwyczaj obrazy są skanowane względem testu porównawczego CIS platformy Docker. W przypadku korzystania z tych typów przepływów nie będziesz przerywać opracowywania, wprowadzając korygowanie zabezpieczeń, ale możesz poprawić ogólny stan zabezpieczeń przedsiębiorstwa.

Użycie narzędzia, które umożliwia korzystanie z tych możliwości, ma kluczowe znaczenie dla efektywnego wdrożenia odpowiedniej strategii dla przedsiębiorstwa. Tradycyjne narzędzia często nie mogą wykrywać luk w zabezpieczeniach w kontenerach, co może prowadzić do fałszywego poczucia bezpieczeństwa. Do prawidłowego zabezpieczenia ekosystemu kontenerów potrzebne są narzędzia, które przyjmują podejście oparte na potokach, oraz niezmienny i deklaratywny charakter technologii kontenerów.

Te narzędzia powinny mieć następujące właściwości:

  • Integracja z całym okresem istnienia obrazów od początku procesu kompilacji do rejestru do środowiska uruchomieniowego.
  • Wgląd w luki w zabezpieczeniach we wszystkich warstwach obrazu, w tym podstawową warstwę obrazu, struktury aplikacji i niestandardowe oprogramowanie.
  • Wymuszanie oparte na zasadach z odpowiednim poziomem szczegółowości, które umożliwia organizacji tworzenie bram jakości na każdym etapie procesów kompilacji i wdrażania.

Zabezpieczenia rejestru

Zabezpieczenia rejestru dotyczą:

  • Kontrolka Dryfu z kompilacji.
  • Zapobieganie wypycheniu/ściąganiu zanieczyszczonych obrazów.
  • Podpisywanie obrazów.

Poważne zagrożenia

Obrazy często zawierają zastrzeżone informacje, w tym kod źródłowy organizacji. Jeśli połączenia z rejestrami nie są odpowiednio bezpieczne, zawartość obrazu może stanowić zagrożenie poufności tak poważne, jak każda inna forma danych przesyłanych w organizacji. Nieaktualne obrazy z nieaktualnymi wersjami w rejestrze mogą zwiększyć ryzyko bezpieczeństwa, jeśli zostaną przypadkowo wdrożone.

Inna luka w zabezpieczeniach może obejmować niewystarczające ograniczenia uwierzytelniania i autoryzacji do rejestrów kontenerów. Te rejestry mogą pomieścić poufne zasoby własnościowe na obrazach.

W miarę kompilowania i wdrażania zawartości dystrybucja tej zawartości jest jednym z wielu wektorów ataków. Jak upewnić się, że zawartość przeznaczona do dystrybucji jest tą samą zawartością dostarczaną do zamierzonego punktu końcowego?

Środki zaradcze ryzyka

Skonfiguruj procesy wdrażania, aby upewnić się, że narzędzia programistyczne, sieci i środowiska uruchomieniowe kontenerów są połączone z rejestrami tylko za pośrednictwem zaszyfrowanych kanałów. Upewnij się również, że zawartość pochodzi z zaufanego źródła. Aby zmniejszyć ryzyko związane z używaniem nieaktualnych obrazów:

  • Usuń niebezpieczne, podatne na zagrożenia obrazy, które nie powinny być już używane z rejestrów kontenerów.
  • Wymuszanie uzyskiwania dostępu do obrazów przy użyciu niezmiennych nazw, które określają określone wersje obrazów do użycia. Tę konfigurację można zaimplementować przy użyciu najnowszego tagu lub określonej wersji obrazów. Tag nie gwarantuje świeżości. Z tego powodu należy umieścić proces, aby upewnić się, że orkiestrator Kubernetes używa najnowszych unikatowych liczb lub że najnowszy tag reprezentuje najbardziej aktualne wersje.

Dostęp do rejestrów zawierających poufne obrazy powinien wymagać uwierzytelniania i autoryzacji. Cały dostęp do zapisu powinien również wymagać uwierzytelniania. Na przykład zasady mogą umożliwić deweloperom wypychanie obrazów tylko do określonych repozytoriów, dla których są odpowiedzialni.

Dostęp do tych rejestrów powinien być federacyjny i korzystać z zasad dostępu na poziomie biznesowym. Na przykład potok ciągłej integracji/ciągłego wdrażania można skonfigurować tak, aby wypychał obrazy do repozytoriów dopiero po przekazaniu oceny zgodności i testów kontroli jakości skanowania luk w zabezpieczeniach.

Rejestry kontenerów są teraz uważane za rejestry artefaktów stają się podstawowym sposobem wdrażania dowolnego typu zawartości, a nie tylko obrazów kontenerów. Każda chmura udostępnia rejestr z projektami open source i produktami dostawcy, które są dostępne dla hostingu lokalnego lub prywatnego w ramach dostawców chmury. Zawartość jest promowana w rejestrach i między rejestrami z początkowej kompilacji do wdrożenia produkcyjnego.

Jak można zapewnić integralność zawartości, która trafiła do rejestru, jest tą samą zawartością, która wychodzi z rejestru? Wdrożenie rozwiązania do podpisywania obrazów zapewnia, że wdrożenia pochodzą tylko z zaufanych rejestrów i wdrażają zaufaną zawartość.

Zabezpieczenia klastra

Zabezpieczenia klastra dotyczą:

  • Uwierzytelnianie i autoryzacja.
  • Zabezpieczenia sieci.
  • Zarządzanie lukami w zabezpieczeniach i zgodnością.

Poważne zagrożenia

Czasami pojedynczy klaster Kubernetes może służyć do uruchamiania różnych aplikacji zarządzanych przez różne zespoły z różnymi wymaganiami dotyczącymi poziomu dostępu. Jeśli dostęp jest udostępniany osobom bez ograniczeń lub tylko zgodnie z ich potrzebami, złośliwy lub nieostroszny użytkownik może naruszyć bezpieczeństwo obciążeń, do których mają dostęp i inne zasoby w klastrze.

Inna luka w zabezpieczeniach może wystąpić, gdy własny katalog użytkowników klastra zarządza autoryzacją i uwierzytelnianiem. Katalog uwierzytelniania organizacyjnego jest często bardziej rygorystycznie kontrolowany. Ponieważ te konta są wysoce uprzywilejowane i częściej oddzielone, prawdopodobieństwo naruszenia zabezpieczeń konta zwiększa się.

Ten scenariusz może prowadzić do luk w zabezpieczeniach klastra lub nawet w całym systemie. Dane przechowywane przez woluminy kontenerów są zarządzane przez koordynatorów, które muszą mieć dostęp do danych niezależnie od tego, na którym węźle jest hostowany.

Tradycyjne filtry sieciowe mogą mieć ślepotę z powodu nakładki sieciowej przeznaczonej do szyfrowania danych przesyłanych. Ten projekt utrudnia monitorowanie ruchu w klastrze, dlatego do monitorowania klastrów Kubernetes mogą być wymagane specjalne przepisy.

Ruch z różnych aplikacji, które współużytkowały ten sam klaster, może mieć różne poziomy poufności, takie jak publiczna witryna internetowa i wewnętrzna aplikacja z krytycznymi poufnymi procesami biznesowymi. Udostępnianie tej samej sieci wirtualnej w klastrze może prowadzić do naruszenia zabezpieczeń poufnych danych. Na przykład osoba atakująca może użyć udostępnionej sieci uwidocznionej w Internecie do ataku na aplikacje wewnętrzne.

Chroń składniki uruchamiane w klastrze przed lukami w zabezpieczeniach i problemami ze zgodnością. Upewnij się, że korzystasz z najnowszej możliwej wersji platformy Kubernetes, aby skorzystać z korygowania.

Środki zaradcze ryzyka

Dostęp użytkowników klastra Kubernetes powinien korzystać z modelu dostępu z najmniejszymi uprawnieniami. Przyznaj użytkownikom dostęp tylko do wykonywania określonych akcji na określonych hostach, kontenerach i obrazach, które są wymagane do wykonywania zadań. Członkowie zespołu testowego powinni mieć ograniczony lub brak dostępu do kontenerów w środowisku produkcyjnym. Konta użytkowników z dostępem w całym klastrze powinny być ściśle kontrolowane i używane oszczędnie.

Użyj metod silnego uwierzytelniania, takich jak uwierzytelnianie wieloskładnikowe, aby zabezpieczyć dostęp do tych kont. Katalog użytkowników organizacji powinien służyć do zarządzania klastrami za pośrednictwem logowania jednokrotnego, w przeciwieństwie do kont użytkowników specyficznych dla klastra, które mogą nie mieć tego samego poziomu zasad i mechanizmów kontroli.

Użyj metod szyfrowania, które umożliwiają kontenerom prawidłowy dostęp do danych niezależnie od tego, na którym są uruchomione kontenery. Te narzędzia szyfrowania powinny zapobiegać nieautoryzowanemu dostępowi do danych przez inne kontenery nawet w tym samym węźle, który nie powinien mieć do nich dostępu.

Skonfiguruj klastry Kubernetes, aby oddzielić ruch sieciowy do dyskretnych sieci wirtualnych lub podsieci według poziomu poufności. Segmentacja dla aplikacji może być również możliwa, ale definiowanie sieci według poziomów poufności może być wystarczające. Na przykład sieci wirtualne dla aplikacji przeznaczonych dla klientów oddzielone od tych obsługujących aplikacje wewnętrzne z wrażliwym ruchem powinny być implementowane co najmniej.

Można użyć defektów i tolerancji, aby odizolować wdrożenia do określonych zestawów węzłów według poziomów poufności. Unikaj hostowania wysoce wrażliwych obciążeń w tym samym węźle, co obciążenia o mniejszej poufności. Korzystanie z oddzielnych klastrów zarządzanych jest bezpieczniejszą opcją.

Segmentuj kontenery według przeznaczenia, poufności i stanu wątku, aby zapewnić dodatkową ochronę dla wrażliwych obciążeń. Dzięki segmentowaniu kontenerów jest to trudniejsze dla osoby atakującej, która uzyskała dostęp do jednego segmentu w celu uzyskania dostępu do innych segmentów. Ta konfiguracja ma dodatkową zaletę zapewniania reszt danych, takich jak pamięci podręczne lub instalacja woluminów, są izolowane przez poziom poufności.

Klastry Kubernetes powinny być skonfigurowane w taki sposób, aby:

  • Zapewnij bezpieczne środowisko dla aplikacji uruchamianych na nich.
  • Upewnij się, że węzły są bezpiecznie dodawane do klastra.
  • Mają trwałe tożsamości, aby zapewnić bezpieczeństwo w całym cyklu życia.
  • Podaj aktualne, dokładne informacje na temat stanu klastra, w tym sieci i węzłów w nim.

Należy łatwo odizolować i usunąć węzeł z klastra bez wpływu na wydajność klastra. Usługa AKS sprawia, że jest to proste.

Zdefiniuj standardy konfiguracji środowiska uruchomieniowego kontenera, aby automatycznie zapewnić zgodność. Na platformie Azure istnieje wiele zasad, które ułatwiają ten proces, a użytkownicy mogą również tworzyć własne zasady. Użyj funkcji zabezpieczeń platformy Azure, aby stale oceniać ustawienia konfiguracji w całym środowisku i aktywnie je wymuszać.

Automatycznie upewnij się, że są rozwiązywane luki w zabezpieczeniach składników platformy Kubernetes. Używaj oddzielnych środowisk do tworzenia, testowania i produkcji, z których każdy ma własne mechanizmy kontroli i kontrolę dostępu opartą na rolach (RBAC) na potrzeby zarządzania kontenerami. Skojarz wszystkie tworzenie kontenera z poszczególnymi tożsamościami użytkowników i powinno być rejestrowane na potrzeby inspekcji. Ta konfiguracja pomaga zmniejszyć ryzyko nieautoryzowanych kontenerów.

Zabezpieczenia węzłów

Zabezpieczenia węzłów dotyczą:

  • Ochrona środowiska uruchomieniowego.
  • Zarządzanie lukami w zabezpieczeniach i zgodnością.

Poważne zagrożenia

Węzeł procesu roboczego ma uprzywilejowany dostęp do wszystkich składników w węźle. Osoby atakujące mogą używać dowolnej usługi dostępnej dla sieci jako punktu wejścia, więc zapewnienie dostępu do hosta z wielu punktów może poważnie zwiększyć swoją powierzchnię ataków. Większa powierzchnia ataku, tym większe szanse na uzyskanie dostępu do węzła i jego systemu operacyjnego przez osobę atakującą.

Ponadto systemy operacyjne specyficzne dla kontenera, takie jak używane w węzłach usługi AKS, mają mniejszą powierzchnię ataków, ponieważ nie zawierają bibliotek, które umożliwiają regularne systemy operacyjne bezpośrednie uruchamianie baz danych i serwerów internetowych. Użycie udostępnionego jądra powoduje większy obszar ataków dla kontenerów działających w tym samym środowisku niż kontenery w oddzielnych maszynach wirtualnych. Dzieje się tak nawet wtedy, gdy używane są systemy operacyjne specyficzne dla kontenera w węzłach usługi AKS.

Systemy operacyjne hosta zapewniają podstawowe składniki systemu, które mogą mieć luki w zabezpieczeniach i ryzyko zgodności. Ponieważ są to składniki niskiego poziomu, ich luki w zabezpieczeniach i konfiguracja mogą mieć wpływ na wszystkie hostowane kontenery. Usługa AKS chroni użytkowników, zapewniając, że te luki w zabezpieczeniach są uwzględniane za pośrednictwem regularnych aktualizacji systemu operacyjnego w węzłach uruchomionych w usłudze AKS, a stan zgodności węzła roboczego jest utrzymywany.

Niewłaściwe prawa dostępu użytkowników mogą również prowadzić do zagrożeń bezpieczeństwa, gdy użytkownicy logowali się bezpośrednio do węzłów, aby zarządzać kontenerami, w przeciwieństwie do płaszczyzny sterowania usługi AKS. Zalogowanie się bezpośrednio może umożliwić użytkownikowi wprowadzanie zmian w aplikacjach poza tymi, do których powinni mieć dostęp.

Ponadto złośliwe kontenery mogą prowadzić do naruszenia systemu plików systemu operacyjnego. Jeśli na przykład kontener może zainstalować poufny katalog w systemie operacyjnym hosta, ten kontener może wprowadzać zmiany w plikach. Zmiany mogą mieć wpływ na bezpieczeństwo innych kontenerów uruchomionych na hoście.

Środki zaradcze ryzyka

Ogranicz dostęp do węzła, ograniczając dostęp za pomocą protokołu SSH.

Korzystanie z systemu operacyjnego specyficznego dla kontenera w węzłach usługi AKS zwykle zmniejsza powierzchnie ataków, ponieważ inne usługi i funkcje są wyłączone. Mają również systemy plików tylko do odczytu i domyślnie stosują inne rozwiązania w zakresie wzmacniania zabezpieczeń klastra.

Platforma Azure automatycznie stosuje poprawki zabezpieczeń systemu operacyjnego do węzłów systemów Linux i Windows w nocy. Jeśli aktualizacja zabezpieczeń systemu operacyjnego Linux wymaga ponownego uruchomienia hosta, nie zostanie ona automatycznie uruchomiona ponownie. Usługa AKS udostępnia mechanizmy ponownego uruchamiania w celu zastosowania tych konkretnych poprawek.

Usługa Microsoft Defender dla serwerów nie ma zastosowania w przypadku węzłów AKS Linux i Windows, ponieważ firma Microsoft zarządza swoim systemem operacyjnym. Jeśli żadna inna maszyna wirtualna nie znajduje się w subskrypcji, w której wdrożono usługę AKS, możesz bezpiecznie wyłączyć usługę Microsoft Defender dla serwerów.

Jeśli środowisko zostało wdrożone, w tym zalecane zasady platformy Azure w strefie docelowej w skali przedsiębiorstwa, możesz skonfigurować wykluczenie do przypisania zasad w grupie zarządzania, która automatycznie umożliwia usłudze Microsoft Defender for Servers uniknięcie niepotrzebnych kosztów.

Zabezpieczenia aplikacji

Zabezpieczenia aplikacji dotyczą:

  • Ochrona środowiska uruchomieniowego.
  • Zarządzanie lukami w zabezpieczeniach i zgodnością.

Poważne zagrożenia

Obrazy to pliki zawierające wszystkie składniki wymagane do uruchomienia aplikacji. Gdy najnowsze wersje tych składników są używane do tworzenia obrazów, mogą one być wolne od znanych luk w zabezpieczeniach w tym czasie, ale mogą szybko się zmieniać.

Należy zachować aktualność tych plików z najnowszymi wersjami, ponieważ deweloperzy pakietów regularnie identyfikują luki w zabezpieczeniach. Uaktualnij kontener dalej, aktualizuj obrazy używane do tworzenia kontenerów, w przeciwieństwie do tradycyjnych aplikacji, które są zwykle aktualizowane na hoście.

Złośliwe pliki można również osadzać na obrazie, który może następnie służyć do ataku na inne kontenery lub składniki systemu. Kontenery innych firm mogą być możliwym wektorem ataku. Szczegółowe informacje mogą być nieznane i mogą wyciekać dane. Być może kontenery nie były aktualne z wymaganymi aktualizacjami zabezpieczeń.

Innym wektorem ataku jest użycie osadzania wpisów tajnych, takich jak hasła i parametry połączenia bezpośrednio w systemie plików obrazów. Takie rozwiązanie może spowodować zagrożenie bezpieczeństwa, ponieważ każda osoba mająca dostęp do obrazu może uzyskać dostęp do wpisów tajnych.

W samych aplikacjach mogą występować wady, takie jak aplikacje, które są narażone na wykonywanie skryptów między witrynami lub wstrzyknięcie kodu SQL. Jeśli istnieją wady, luka w zabezpieczeniach może służyć do umożliwienia nieautoryzowanego dostępu do poufnych informacji w innych kontenerach, a nawet systemu operacyjnego hosta.

Środowisko uruchomieniowe kontenera usługi AKS ułatwia monitorowanie luk w zabezpieczeniach przy użyciu różnych narzędzi zabezpieczeń dostępnych na platformie Azure. Aby uzyskać więcej informacji, zobacz Wprowadzenie do usługi Microsoft Defender dla platformy Kubernetes.

Należy również kontrolować ruch sieciowy wychodzący wysyłany do kontenerów, aby upewnić się, że kontenery nie mogą wysyłać ruchu między sieciami o różnych poziomach poufności, takich jak środowiska hostujące bezpieczne dane lub do Internetu. Platforma Azure ułatwia tę kontrolę dzięki różnym funkcjom zabezpieczeń sieci i usługi AKS.

Domyślnie harmonogramy platformy Kubernetes koncentrują się na zwiększaniu skali i maksymalizacji gęstości obciążeń uruchomionych na węzłach. Mogą umieścić zasobniki różnych poziomów poufności w tym samym węźle tylko dlatego, że ten host ma najbardziej dostępne zasoby. Ten scenariusz może potencjalnie prowadzić do zdarzeń zabezpieczeń, gdy osoby atakujące używają dostępu do obciążeń publicznych do atakowania kontenerów działających bardziej wrażliwych procesów na tym samym hoście. Naruszony kontener może być również używany do skanowania sieci w celu znalezienia innych luk w zabezpieczeniach, które może wykorzystać osoba atakująca.

Środki zaradcze ryzyka

Nigdy nie przechowuj wpisów tajnych w kodzie aplikacji lub systemach plików. Wpisy tajne powinny być przechowywane w magazynach kluczy i dostarczane do kontenerów w czasie wykonywania zgodnie z potrzebami. Usługa AKS może zapewnić, że tylko kontenery, które potrzebują dostępu do niektórych kluczy, mają do nich dostęp i że te wpisy tajne nie są utrwalane na dysku. Na przykład usługa Azure Key Vault może bezpiecznie przechowywać te wpisy tajne i udostępniać je klastrowi usługi AKS zgodnie z potrzebami. Jest również proste, aby upewnić się, że te wpisy tajne są szyfrowane zarówno w magazynie, jak i podczas przesyłania.

Unikaj używania niezaufanych obrazów i rejestrów i upewnij się, że w klastrach mogą być uruchamiane tylko obrazy z zaufanych zestawów. W przypadku podejścia wielowarstwowego:

  • Centralnie steruj dokładnie tym, jakie obrazy i rejestry są zaufane.
  • Dyskretnie zidentyfikuj każdy obraz przy użyciu podpisu kryptograficznego.
  • Umieść zasady, które zapewniają, że wszystkie hosty uruchamiają tylko obrazy pochodzące z zatwierdzonego zestawu.
  • Zweryfikuj te podpisy przed wykonaniem.
  • Monitoruj i aktualizuj te obrazy i rejestry w miarę zmiany wymagań dotyczących luk w zabezpieczeniach i konfiguracji.

Profile bezpiecznego przetwarzania powinny służyć do ograniczania kontenerów i przydzielania ich w czasie wykonywania. Profile niestandardowe można tworzyć i przekazywać do środowisk uruchomieniowych kontenerów, aby jeszcze bardziej ograniczyć ich możliwości. Upewnij się co najmniej, że kontenery są uruchamiane z profilami domyślnymi. Rozważ użycie niestandardowych, bardziej ograniczonych profilów dla kontenerów z aplikacjami wysokiego ryzyka.

Narzędzia mogą automatycznie profilować aplikacje przy użyciu uczenia behawioralnego i wykrywania anomalii. Rozwiązania innych firm umożliwiają wykrywanie anomalii w czasie wykonywania. Anomalie mogą obejmować zdarzenia, takie jak:

  • Nieprawidłowe lub nieoczekiwane wykonanie procesu lub wywołania systemowe.
  • Zmiany w chronionych plikach konfiguracji i plikach binarnych.
  • Zapisuje w nieoczekiwanych lokalizacjach i typach plików.
  • Tworzenie nieoczekiwanych odbiorników sieciowych.
  • Ruch wysyłany do nieoczekiwanych miejsc docelowych sieci.
  • Przechowywanie i wykonywanie złośliwego oprogramowania.

Usługa Microsoft Defender dla platformy Kubernetes obecnie inwestuje w ten obszar.

Kontenery powinny działać z głównym systemem plików w trybie tylko do odczytu, aby odizolować zapisy do zdefiniowanych katalogów, które te narzędzia mogą łatwo monitorować. Ta konfiguracja sprawia, że kontenery są bardziej odporne na naruszenia, ponieważ izolujesz manipulowanie tymi konkretnymi lokalizacjami. Można je łatwo oddzielić od pozostałej części aplikacji.

Uwagi dotyczące projektowania

Usługa AKS ma kilka interfejsów dla innych usług platformy Azure, takich jak Microsoft Entra ID, Azure Storage i Azure Virtual Network. Korzystanie z tych usług wymaga szczególnej uwagi podczas fazy planowania. Usługa AKS zwiększa również dodatkową złożoność, która wymaga rozważenia zastosowania tych samych mechanizmów zapewniania ładu i zgodności zabezpieczeń oraz mechanizmów kontroli, co w pozostałej części środowiska infrastruktury.

Poniżej przedstawiono kilka innych zagadnień projektowych dotyczących ładu i zgodności zabezpieczeń usługi AKS:

  • Jeśli utworzysz klaster usługi AKS w subskrypcji wdrożonej zgodnie z najlepszymi rozwiązaniami dotyczącymi strefy docelowej w skali przedsiębiorstwa, zapoznaj się z zasadami platformy Azure, które będą dziedziczone przez klastry. Aby uzyskać więcej informacji, zobacz Zasady zawarte w implementacjach odwołań stref docelowych platformy Azure.
  • Zdecyduj, czy płaszczyzna sterowania klastra powinna być dostępna za pośrednictwem Internetu (zalecamy ograniczenia adresów IP), która jest domyślna, czy tylko z sieci prywatnej na platformie Azure, czy lokalnie jako klaster prywatny. Jeśli Twoja organizacja jest zgodnie z najlepszymi rozwiązaniami dotyczącymi strefy docelowej w skali przedsiębiorstwa, Corp grupa zarządzania ma skojarzona z usługą Azure Policy, która wymusza, aby klastry zostały prywatne. Aby uzyskać więcej informacji, zobacz Zasady zawarte w implementacjach odwołań stref docelowych platformy Azure.
  • Oceń przy użyciu wbudowanego modułu zabezpieczeń systemu Linux AppArmor , aby ograniczyć akcje, które kontenery mogą wykonywać, takie jak odczyt, zapis, wykonywanie lub funkcje systemowe, takie jak instalowanie systemów plików. Na przykład wszystkie subskrypcje mają zasady platformy Azure, które uniemożliwiają zasobnikom we wszystkich klastrach usługi AKS tworzenie uprzywilejowanych kontenerów. Aby uzyskać więcej informacji, zobacz Zasady zawarte w implementacjach odwołań stref docelowych platformy Azure.
  • Oceń użycie seccomp (bezpieczne przetwarzanie) na poziomie procesu, aby ograniczyć wywołania procesu, które kontenery mogą wykonywać. Na przykład usługa Azure Policy zastosowana jako część ogólnej implementacji strefy docelowej w skali przedsiębiorstwa w grupie zarządzania strefami docelowymi, aby zapobiec eskalacji uprawnień kontenera do użycia seccomp głównego za pomocą zasad platformy Azure dla platformy Kubernetes.
  • Zdecyduj, czy rejestr kontenerów jest dostępny za pośrednictwem Internetu, czy tylko w określonej sieci wirtualnej. Wyłączenie dostępu do Internetu w rejestrze kontenerów może mieć negatywny wpływ na inne systemy, które polegają na łączności publicznej w celu uzyskania do niego dostępu. Przykłady obejmują potoki ciągłej integracji lub skanowanie obrazów w usłudze Microsoft Defender. Aby uzyskać więcej informacji, zobacz Połączenie prywatnie do rejestru kontenerów przy użyciu usługi Azure Private Link.
  • Zdecyduj, czy prywatny rejestr kontenerów jest współużytkowany w wielu strefach docelowych, czy też wdrożysz dedykowany rejestr kontenerów w każdej subskrypcji strefy docelowej.
  • Rozważ użycie rozwiązania zabezpieczeń, takiego jak Usługa Microsoft Defender dla platformy Kubernetes na potrzeby wykrywania zagrożeń.
  • Rozważ skanowanie obrazów kontenerów pod kątem luk w zabezpieczeniach.
  • Rozważ wyłączenie usługi Microsoft Defender dla serwerów w subskrypcji usługi AKS, jeśli nie ma maszyn wirtualnych innych niż AKS, aby uniknąć niepotrzebnych kosztów.

Zalecenia dotyczące projektowania

Ważne

Microsoft Defender dla Chmury skanowanie obrazów nie jest zgodne z punktami końcowymi usługi Container Registry. Aby uzyskać więcej informacji, zobacz Połączenie prywatnie do rejestru kontenerów przy użyciu usługi Private Link.