Architektura klastra regulowanego usługi AKS dla standardu PCI-DSS 3.2.1 (część 2 z 9)

W tym artykule opisano architekturę referencyjną klastra usługi Azure Kubernetes Service (AKS), który uruchamia obciążenie zgodnie z standardem Payment Card Industry Data Security Standard (PCI-DSS 3.2.1). Ta architektura koncentruje się na infrastrukturze, a nie na obciążeniu PCI-DSS 3.2.1.

Ten artykuł jest częścią serii. Przeczytaj wprowadzenie.

Zalecenia i przykłady są wyodrębniane z tej towarzyszącej implementacji referencyjnej:

GitHub: Klaster bazowy usługi Azure Kubernetes Service (AKS) dla obciążeń regulowanych demonstruje uregulowaną infrastrukturę. Ta implementacja zapewnia aplikację mikrousług. Uwzględniono ją w celu ułatwienia korzystania z infrastruktury oraz zilustrowania mechanizmów kontroli sieci i zabezpieczeń. Aplikacja nie reprezentuje ani nie implementuje rzeczywistego obciążenia PCI DSS.

Pobierz plik programu Visio z tą architekturą.

Ta architektura sieci jest oparta na topologii piasty i szprych. Sieć wirtualna piasty zawiera zaporę do kontrolowania ruchu wychodzącego, ruchu bramy z sieci lokalnych oraz trzeciej sieci na potrzeby dostępu do klastra SRE (inżyniera niezawodności lokacji). Istnieją dwie sieci wirtualne będące szprychami. Jedna szprycha zawiera klaster AKS, który jest składnikiem środowiska posiadacza kart (CDE) i hostuje obciążenie PCI DSS. Inne szprychy kompilują obrazy maszyn wirtualnych używane do kontrolowanego dostępu SRE do środowiska.

Składniki

Poniżej przedstawiono główne składniki używane w tej architekturze. Jeśli nie znasz tych usług, zobacz Powiązane usługi platformy Azure, aby uzyskać linki do dokumentacji produktu.

Azure Firewall

Wystąpienie zapory zabezpiecza wychodzący ruch sieciowy. Bez tej warstwy zabezpieczeń przepływ może komunikować się ze złośliwą usługą innej firmy, która może eksfiltrować poufne dane firmy.

Azure Bastion

Architektura punktu odniesienia dostarczyła podsieć dla usługi Azure Bastion, ale nie aprowizować zasobu. Ta architektura dodaje usługę Azure Bastion w podsieci i zapewnia bezpieczny dostęp do serwera przesiadkowego.

Azure Image Builder

Aprowizowana w oddzielnej sieci wirtualnej tworzy obrazy maszyn wirtualnych z podstawowymi zabezpieczeniami i konfiguracją. W tej architekturze jest ona dostosowywana do tworzenia bezpiecznych obrazów węzłów za pomocą narzędzi do zarządzania, takich jak interfejs wiersza polecenia platformy Azure, kubectli wstępnie zainstalowany interfejs wiersza polecenia platformy Flux.

Zestawy skalowania maszyn wirtualnych platformy Azure dla wystąpień serwera przesiadkowego

Sieć szprych ma dodatkowe obliczenia dla skoku. Ten zestaw skalowania ma być zarządzanym punktem dostępu do uruchamiania narzędzi względem klastra usługi AKS, takiego jak kubectl, zgodnie z potrzebami.

aplikacja systemu Azure Gateway ze zintegrowaną zaporą aplikacji internetowej (WAF)

aplikacja systemu Azure równoważenie obciążenia bramy w warstwie 7. Zapora aplikacji internetowej zabezpiecza ruch przychodzący z typowych ataków na ruch internetowy. Wystąpienie ma publiczną konfigurację adresu IP frontonu, która odbiera żądania użytkowników.

Azure Kubernetes Service (AKS)

Infrastruktura hostingu, która jest kluczową częścią środowiska danych posiadaczy kart (CDE). Klaster usługi AKS jest wdrażany jako klaster prywatny. Dlatego serwer interfejsu API Kubernetes nie jest uwidoczniony w publicznym Internecie, a ruch do serwera interfejsu API jest ograniczony do sieci prywatnej.

Zadania usługi ACR

Zapewnia zautomatyzowany sposób tworzenia i obsługi obrazów kontenerów.

Azure Key Vault

Przechowuje wpisy tajne potrzebne do wykonywania operacji klastra, takich jak certyfikaty i klucze szyfrowania, oraz zarządza nimi.

Konfiguracja klastra

Poniżej przedstawiono kilka znaczących zmian w architekturze punktu odniesienia:

Segmentacja puli węzłów

W tej architekturze klaster ma dwie pule węzłów użytkownika i jedną pulę węzłów systemowych. Wybór zasobów obliczeniowych dla pul węzłów pozostaje taki sam. Każda pula węzłów znajduje się w dedykowanej podsieci, aby zapewnić dodatkową granicę izolacji sieciowej między warstwami obliczeniowymi.

Pci-DSS 3.2.1 wymaga izolacji obciążenia PCI od innych obciążeń pod względem operacji i łączności.

• Zakres: obciążenie PCI, środowisko, w którym się znajduje, i operacje.

• Poza zakresem: inne obciążenia, które mogą współużytkować usługi, ale są odizolowane od składników w zakresie.

Kluczową strategią jest zapewnienie wymaganego poziomu separacji. Preferowanym sposobem jest wdrożenie składników w zakresie i poza zakresem w oddzielnych klastrach. Strona po awarii zwiększa koszty dodatkowej infrastruktury i nakładu pracy konserwacyjnych. Ta implementacja współlokuje wszystkie składniki w udostępnionym klastrze dla uproszczenia. Jeśli zdecydujesz się postępować zgodnie z tym modelem, użyj rygorystycznej strategii segmentacji w klastrze. Bez względu na sposób utrzymania separacji należy pamiętać, że w miarę rozwoju rozwiązania niektóre składniki poza zakresem mogą stać się w zakresie.

W implementacji referencyjnej drugie podejście jest pokazane przy użyciu aplikacji mikrousług wdrożonej w jednym klastrze. Obciążenia w zakresie i poza zakresem są podzielone na dwie oddzielne pule węzłów użytkownika. Aplikacja ma dwa zestawy usług; jeden zestaw ma zasobniki w zakresie, a drugi jest poza zakresem. Oba zestawy są rozłożone na dwie pule węzłów użytkownika. W przypadku używania defektów platformy Kubernetes zasobniki w zakresie i poza zakresem są wdrażane w oddzielnych węzłach i nigdy nie współużytkują maszynę wirtualną węzła lub przestrzeń adresów IP sieci.

Kontroler ruchu przychodzącego

Kontroler ruchu przychodzącego Kubernetes w klastrze został zmieniony na NGINX. W architekturze bazowej użyto traefika. Ta zmiana ilustruje, że ten składnik można zmienić na podstawie wymagań obciążeń.

Prywatny serwer interfejsu API Kubernetes

Architektura punktu odniesienia wdrożyła klaster usługi AKS w trybie publicznym. Oznacza to, że cała komunikacja z serwerem interfejsu API Kubernetes zarządzanym przez usługę AKS odbywa się za pośrednictwem publicznego Internetu. Nie jest to dopuszczalne w tej architekturze, ponieważ PCI-DSS 3.2.1 zabrania publicznego narażenia na wszelkie składniki systemu. W tej regulowanej architekturze klaster jest wdrażany jako klaster prywatny. Ruch sieciowy do serwera interfejsu API Kubernetes jest ograniczony do sieci prywatnej. Serwer interfejsu API jest udostępniany za pośrednictwem prywatnego punktu końcowego w sieci klastra. Zabezpieczenia są dodatkowo ulepszone dzięki użyciu sieciowych grup zabezpieczeń i innych wbudowanych funkcji. Opisano je w temacie Konfiguracja sieci.

Zabezpieczenia zasobników

Podczas opisywania potrzeb związanych z zabezpieczeniami obciążenia użyj odpowiednich securityContext ustawień dla kontenerów. Obejmuje to ustawienia podstawowe, takie jak fsGroup,runAsGrouprunAsUser / i allowPrivilegeEscalation na wartość false (chyba że jest to wymagane). Jasne informacje na temat definiowania i usuwania możliwości systemu Linux oraz definiowania opcji SELinux w programie seLinuxOptions.

Unikaj odwoływania się do obrazów według ich tagów w manifestach wdrożenia. Zamiast tego użyj rzeczywistego identyfikatora obrazu. Dzięki temu można niezawodnie mapować wyniki skanowania kontenera przy użyciu rzeczywistej zawartości uruchomionej w klastrze. Możesz wymusić to za pomocą usługi Azure Policy, aby nazwa obrazu zawierała wzorzec identyfikatora obrazu w dozwolonym wyrażeniu regularnym. Postępuj zgodnie z poniższymi wskazówkami, gdy używasz instrukcji Dockerfile FROM .

Konfiguracja sieci

Wszystkie szprychy są wdrażane w oddzielnych sieciach wirtualnych, z których każda znajduje się w prywatnej przestrzeni adresowej. Domyślnie żaden ruch między dwiema sieciami wirtualnymi nie jest dozwolony. W sieci segmentacja jest stosowana przez tworzenie podsieci.

Kombinacja różnych usług i funkcji platformy Azure oraz natywnych konstrukcji kubernetes zapewnia wymagany poziom kontroli. Poniżej przedstawiono niektóre opcje używane w tej architekturze.

Zabezpieczenia podsieci za pośrednictwem sieciowych grup zabezpieczeń

Istnieje kilka sieciowych grup zabezpieczeń, które kontrolują przepływ w klastrze i poza nim. Oto kilka przykładów:

• Pule węzłów klastra są umieszczane w dedykowanych podsieciach. Dla każdej podsieci istnieją sieciowe grupy zabezpieczeń, które blokują dostęp SSH do maszyn wirtualnych węzłów i zezwalają na ruch z sieci wirtualnej. Ruch z pul węzłów jest ograniczony do sieci wirtualnej.

• Cały ruch przychodzący z Internetu jest przechwytywane przez usługę aplikacja systemu Azure Gateway. Na przykład reguły sieciowej grupy zabezpieczeń upewnij się, że:

  • Dozwolony jest tylko ruch HTTPS.
  • Ruch z płaszczyzny sterowania platformy Azure jest dozwolony. Aby uzyskać więcej informacji, zobacz Zezwalanie na dostęp do kilku źródłowych adresów IP.

• W podsieciach, które mają agentów usługi Azure Container Registry, sieciowe grupy zabezpieczeń zezwalają tylko na wymagany ruch wychodzący. Na przykład ruch jest dozwolony do usługi Azure Key Vault, Microsoft Entra ID, Azure Monitor i innych usług, z którymi rejestr kontenerów musi komunikować się.

• Podsieć z serwerem przesiadkowym jest przeznaczona do operacji zarządzania. Reguła sieciowej grupy zabezpieczeń zezwala tylko na dostęp SSH z usługi Azure Bastion w centrum i ograniczone połączenia wychodzące. Pola przesiadkowe nie mają uniwersalnego dostępu do Internetu i są kontrolowane zarówno w sieciowej grupie zabezpieczeń podsieci, jak i w usłudze Azure Firewall.

W miarę wdrażania obciążeń agenci zabezpieczeń systemu i inne składniki dodaj więcej reguł sieciowej grupy zabezpieczeń, które ułatwiają definiowanie typu ruchu, który powinien być dozwolony. Ruch nie powinien przechodzić przez te granice podsieci. Ponieważ każda pula węzłów znajduje się we własnej podsieci, obserwuj wzorce ruchu, a następnie zastosuj bardziej szczegółowe reguły.

Zabezpieczenia zasobnika z zasadami sieciowymi

Ta architektura próbuje zaimplementować zasady "zero trust" firmy Microsoft, jak to możliwe.

Przykłady sieci Zero Trust jako koncepcji przedstawiono w implementacji w a0005-i przestrzeniach nazw i a0005-o udostępnionych przez użytkownika. Wszystkie przestrzenie nazw obciążeń powinny mieć zastosowane restrykcyjne zasady networkPolicy. Definicje zasad będą zależeć od zasobników uruchomionych w tych przestrzeniach nazw. Upewnij się, że uwzględniasz gotowość, linie na żywo i sondy uruchamiania, a także zasiłek dla metryk zebranych przez agenta usługi Log Analytics. Rozważ standaryzację portów w ramach obciążeń, aby zapewnić spójne zasady sieci i usługę Azure Policy dla dozwolonych portów kontenerów.

W niektórych przypadkach nie jest to praktyczne rozwiązanie do komunikacji w klastrze. Nie wszystkie przestrzenie nazw udostępniane przez użytkownika mogą używać sieci zerowej zaufania (na przykład cluster-baseline-settings nie można jej użyć).

Szyfrowanie TLS

Architektura bazowa zapewnia ruch szyfrowany przy użyciu protokołu TLS do momentu, gdy kontroler ruchu przychodzącego w klastrze, ale komunikacja między zasobnikami jest jasna. W tej architekturze protokół TLS jest rozszerzany na ruch zasobników do zasobników z weryfikacją urzędu certyfikacji. Ten protokół TLS jest dostarczany przez siatkę usług, która wymusza połączenia mTLS i weryfikację przed zezwoleniem na komunikację.

Implementacja używa biblioteki mTLS. Obsługa biblioteki mTLS można zaimplementować z siatką usług lub bez jej użycia. Jeśli używasz siatki, upewnij się, że jest ona zgodna z wybranym wystawcą certyfikatu. Ta implementacja używa usługi Open Service Mesh.

Kontroler ruchu przychodzącego w tej implementacji używa certyfikatu wieloznacznych do obsługi ruchu domyślnego, gdy zasób ruchu przychodzącego nie zawiera określonego certyfikatu. Może to być akceptowalne, ale jeśli zasady organizacji nie zezwalają na używanie certyfikatów z symbolami wieloznacznymi, może być konieczne dostosowanie kontrolera ruchu przychodzącego, aby nie używać certyfikatu z symbolami wieloznacznymi.

Ograniczenia sieci usługi Azure Key Vault

Wszystkie wpisy tajne, klucze i certyfikaty są przechowywane w usłudze Azure Key Vault. Usługa Key Vault obsługuje zadania zarządzania certyfikatami, takie jak rotacja. Komunikacja z usługą Key Vault odbywa się za pośrednictwem usługi Azure Private Link. Rekord DNS skojarzony z usługą Key Vault znajduje się w prywatnej strefie DNS, aby nie można było rozpoznać go z Internetu. Chociaż zwiększa to bezpieczeństwo, istnieją pewne ograniczenia.

aplikacja systemu Azure Gateway nie obsługuje określania źródła certyfikatów TLS dla odbiornika HTTP z wystąpień usługi Key Vault, które są uwidocznione za pomocą usługi Private Link. Dlatego implementacja wdraża usługę Key Vault w modelu hybrydowym. Nadal używa usługi Private Link dla połączeń, które go obsługują, ale także umożliwia publiczny dostęp do integracji z usługą Application Gateway. Jeśli takie podejście hybrydowe nie jest odpowiednie dla danego wdrożenia, przenieś proces zarządzania certyfikatami do usługi Application Gateway. Spowoduje to dodanie obciążenia związanego z zarządzaniem, ale następnie wystąpienie usługi Key Vault zostanie całkowicie odizolowane. Aby uzyskać więcej informacji, zobacz:

• integracja bramy aplikacja systemu Azure i usługi Key Vault
• Utwórz bramę aplikacji z zakończeniem protokołu TLS przy użyciu interfejsu wiersza polecenia platformy Azure.

Ochrona przed atakami DDoS

Włącz usługę Azure DDoS Network Protection dla sieci wirtualnych z podsiecią zawierającą usługę Application Gateway z publicznym adresem IP. Dzięki temu infrastruktura i obciążenie są chronione przed masowymi fałszywymi żądaniami. Takie żądania mogą powodować przerwy w działaniu usługi lub maskować kolejny współbieżny atak. Usługa Azure DDoS wiąże się ze znacznymi kosztami i jest zwykle amortyzowana w wielu obciążeniach obejmujących wiele adresów IP. Współpracuj z zespołem ds. sieci, aby koordynować pokrycie obciążenia.

Zarządzanie dostępem do tożsamości

Zdefiniuj role i ustaw kontrolę dostępu zgodnie z wymaganiami roli. Mapowanie ról na akcje kubernetes o określonym zakresie tak wąsko, jak praktyczne. Unikaj ról obejmujących wiele funkcji. Jeśli wiele ról jest wypełnianych przez jedną osobę, przypisz tej osobie wszystkie role, które są istotne dla równoważnych funkcji zadań. Dlatego nawet jeśli jedna osoba jest bezpośrednio odpowiedzialna zarówno za klaster, jak i obciążenie, utwórz platformę Kubernetes ClusterRoles tak, jakby istniały oddzielne osoby. Następnie przypisz tej pojedynczej osobie wszystkie odpowiednie role.

Zminimalizuj stały dostęp, szczególnie w przypadku kont o dużym wpływie, takich jak interakcje SRE/Ops z klastrem. Płaszczyzna sterowania usługi AKS obsługuje zarówno usługę Microsoft Entra ID Privileged Access Management (PAM) just in time (JIT) i zasady dostępu warunkowego, które zapewniają dodatkowe warstwy wymaganej weryfikacji uwierzytelniania na potrzeby dostępu uprzywilejowanego na podstawie reguł, które są kompilowane.

Aby uzyskać więcej informacji na temat konfigurowania dostępu warunkowego przy użyciu programu PowerShell, zobacz New-MgIdentityConditionalAccessPolicy, Get-MgIdentityConditionalAccessPolicy i Remove-MgIdentityConditionalAccessPolicy.

Szyfrowanie dysków

Podczas projektowania szyfrowania danych magazynowanych należy wziąć pod uwagę dyski magazynu, maszyny wirtualne węzła agenta usługi AKS, inne maszyny wirtualne i wszelkie tymczasowe i dyski systemu operacyjnego.

Dyski magazynu

Domyślnie dyski usługi Azure Storage są szyfrowane w spoczynku przy użyciu kluczy zarządzanych przez firmę Microsoft. Jeśli używasz nie efemerycznych dysków systemu operacyjnego lub dodajesz dyski danych, zalecamy użycie kluczy zarządzanych przez klienta w celu kontrolowania kluczy szyfrowania. Szyfruj poza warstwą magazynu i zapisuj tylko zaszyfrowane dane na nośniku magazynu. Upewnij się również, że klucze nigdy nie sąsiadują z warstwą magazynu.

Aby uzyskać więcej informacji, zobacz Bring your own keys (BYOK) with Azure disks (Bring your own keys) with Azure disks (Używanie własnych kluczy (BYOK) z dyskami platformy Azure.

Rozważ użycie funkcji BYOK dla innych dysków, które mogą współdziałać z klastrem, takich jak pola przesiadkowe z przodu usługi Azure Bastion. W przypadku wybrania opcji BYOK wybór jednostki SKU dla maszyn wirtualnych i dostępności regionalnej będzie ograniczony, ponieważ ta funkcja nie jest obsługiwana we wszystkich jednostkach SKU lub regionach.

Hosty maszyn wirtualnych

Zalecamy włączenie funkcji szyfrowania na hoście. Spowoduje to zaszyfrowanie hosta maszyny wirtualnej i dowolnego tymczasowego systemu operacyjnego lub dysków danych, które są buforowane na hoście maszyny wirtualnej. Dowiedz się więcej o obsłudze maszyn wirtualnych na potrzeby szyfrowania opartego na hoście.

Ta funkcja została rozszerzona do danych przechowywanych na maszynie wirtualnej na hoście węzłów agenta usługi AKS za pomocą funkcji szyfrowania opartego na hoście. Podobnie jak w przypadku funkcji BYOK ta funkcja może ograniczyć wybór jednostki SKU i regionu maszyny wirtualnej.

Te funkcje można wymusić za pomocą usługi Azure Policy.

Kopie zapasowe klastra (stan i zasoby)

Jeśli obciążenie wymaga magazynu w klastrze, należy mieć niezawodny i bezpieczny proces tworzenia kopii zapasowych i odzyskiwania. Rozważ usługi, takie jak Azure Backup (dla dysków platformy Azure i usługi Azure Files), do tworzenia kopii zapasowych i odzyskiwania dowolnego PersistantVolumeClaimelementu . Istnieją zalety, jeśli system kopii zapasowych obsługuje natywne zasoby Kubernetes. Możesz uzupełnić podstawową metodę, która uzgadnia klaster z dobrze znanym stanem, przy użyciu systemu kopii zapasowych dla krytycznych technik odzyskiwania systemu. Może na przykład pomóc w wykrywaniu dryfu i katalogowaniu zmian stanu systemu w czasie na poziomie zasobu Kubernetes.

Procesy tworzenia kopii zapasowych muszą klasyfikować dane w kopii zapasowej w klastrze lub poza nimi. Jeśli dane znajdują się w zakresie pci DSS 3.2.1, rozszerz granice zgodności, aby uwzględnić cykl życia i miejsce docelowe kopii zapasowej, które będą poza klastrem. Kopie zapasowe mogą być wektorem ataku. Podczas projektowania kopii zapasowej rozważ ograniczenia geograficzne, szyfrowanie magazynowane, mechanizmy kontroli dostępu, role i obowiązki, inspekcję, czas wygaśnięcia i zapobieganie manipulacjom.

Systemy kopii zapasowych w klastrze powinny działać z wysokimi uprawnieniami podczas wykonywania operacji. Oceń ryzyko i korzyści wynikające z wprowadzenia agenta kopii zapasowej do klastra. Czy możliwości agenta nakładają się na inne rozwiązanie do zarządzania w klastrze? Jaki jest minimalny zestaw narzędzi potrzebnych do wykonania tego zadania bez rozszerzania obszaru ataków?

Zagadnienia dotyczące usługi Azure Policy

Zazwyczaj stosowane zasady platformy Azure nie mają ustawień dostosowanych do obciążenia. W implementacji stosujemy standardy z ograniczeniami zabezpieczeń zasobników klastra Kubernetes dla inicjatywy obciążeń opartych na systemie Linux, która nie zezwala na dostrajanie ustawień. Rozważ wyeksportowanie tej inicjatywy i dostosowanie jej wartości dla określonego obciążenia. Wszystkie zasady platformy Azure gatekeeper deny można uwzględnić w ramach jednej inicjatywy niestandardowej i wszystkie audit zasady platformy Azure w ramach innej inicjatywy. W ten sposób kategoryzuje akcje bloku z zasad tylko do informacji.

Rozważ uwzględnienie kube-system przestrzeni nazw i gatekeeper-system do zasad w zasadach inspekcji w celu uzyskania dodatkowej widoczności. Uwzględnienie tych przestrzeni nazw w zasadach odmowy może spowodować niepowodzenie klastra z powodu nieobsługiwanej konfiguracji.

Szyfrowanie danych można wymusić, ustawiając niektóre alerty usługi Azure Policy. Można na przykład wymusić użycie funkcji BYOK za pomocą alertu, który wykrywa klastry, które nie mają diskEncryptionSetID zasobu klastra. Inne zasady mogą wykryć, czy szyfrowanie oparte na hoście jest włączone w systemie agentPoolProfiles. Implementacja referencyjna nie używa żadnych dysków w klastrze, a dysk systemu operacyjnego jest efemeryczny. Obie te przykładowe zasady są dostępne jako przypomnienie funkcji zabezpieczeń. Zasady są ustawione na audit, a nie block.

Zarządzanie obrazami

Używaj obrazów bazowych bez dystrybucji dla obciążeń. W przypadku tych obrazów obszar powierzchni zabezpieczeń jest zminimalizowany, ponieważ obrazy dodatkowe, takie jak powłoki i menedżerowie pakietów, są usuwane. Obniżona korzyść dotyczy liczby trafień CVE.

Usługa Azure Container Registry obsługuje obrazy spełniające specyfikację formatu obrazu Open Container Initiative (OCI). W połączeniu z kontrolerem wpływu, który obsługuje weryfikowanie podpisów, można upewnić się, że uruchamiasz tylko obrazy, które zostały podpisane przy użyciu kluczy prywatnych. Istnieją rozwiązania typu open source, takie jak SSE Connaisseur lub IBM Portieris, które integrują te procesy.

Chroń obrazy kontenerów i inne artefakty OCI, ponieważ zawierają one własność intelektualną organizacji. Użyj kluczy zarządzanych przez klienta i zaszyfruj zawartość rejestrów. Domyślnie dane są szyfrowane w spoczynku przy użyciu kluczy zarządzanych przez usługę, ale klucze zarządzane przez klienta są czasami wymagane do spełnienia standardów zgodności z przepisami. Przechowuj klucz w zarządzanym magazynie kluczy, takim jak usługa Azure Key Vault. Ponieważ tworzysz i posiadasz klucz, odpowiadasz za operacje związane z cyklem życia klucza, w tym rotacją i zarządzaniem. Aby uzyskać więcej informacji, zobacz Szyfrowanie rejestru przy użyciu klucza zarządzanego przez klienta.

Dostęp operacyjny serwera interfejsu API Kubernetes

Polecenia wykonywane względem klastra można ograniczyć bez konieczności tworzenia procesu operacyjnego opartego na polach przesiadkowych. Jeśli masz platformę automatyzacji IT z dostępem i tożsamościami, użyj wstępnie zdefiniowanych akcji w celu kontrolowania i inspekcji typu akcji.

Kompilowanie agentów

Agenci potoku powinni być poza zakresem klastra regulowanego, ponieważ procesy kompilacji mogą być wektorami zagrożeń. Chociaż często używasz platformy Kubernetes jako elastycznej infrastruktury agenta kompilacji, nie uruchamiaj tego procesu w granicach regulowanego środowiska uruchomieniowego obciążenia. Agenci kompilacji nie powinni mieć bezpośredniego dostępu do klastra. Na przykład umożliwianie agentom kompilacji dostępu sieciowego do usługi Azure Container Registry w celu wypychania obrazów kontenerów, wykresów helm itd. Następnie wdróż za pomocą metodyki GitOps. Typowym rozwiązaniem jest to, że przepływy pracy kompilacji i wydawania nie powinny mieć bezpośredniego dostępu do interfejsu API klastra Kubernetes (lub jego węzłów).

Operacje monitorowania

Działania w klastrze

Zasobniki w klastrze uruchomione w programie omsagent kube-system to agent kolekcji usługi Log Analytics. Zbierają dane telemetryczne, złomują kontener stdout i stderr dzienniki oraz zbierają metryki Rozwiązania Prometheus. Ustawienia kolekcji można dostosować, aktualizując container-azm-ms-agentconfig.yaml plik ConfigMap. W tej implementacji referencyjnej rejestrowanie jest włączone we kube-system wszystkich obciążeniach. Domyślnie kube-system jest wykluczony z rejestrowania. Upewnij się, że dostosowujesz proces zbierania dzienników, aby osiągnąć cele związane z kosztami, wydajność SRE podczas przeglądania dzienników i potrzeb związanych ze zgodnością.

Monitorowanie zabezpieczeń

Użyj usługi Defender for Containers w Microsoft Defender dla Chmury, aby wyświetlić i skorygować zalecenia dotyczące zabezpieczeń oraz wyświetlić alerty zabezpieczeń dotyczące zasobów kontenera. Włącz plany usługi Microsoft Defender w miarę ich stosowania do różnych składników środowiska danych posiadaczy kart.

Integrowanie dzienników w celu wydajnego przeglądania, analizowania i wykonywania zapytań dotyczących danych. Platforma Azure oferuje kilka opcji. Możesz włączyć dzienniki diagnostyczne usługi AKS i wysłać je do obszaru roboczego usługi Log Analytics, który jest częścią usługi Azure Monitor. Inną opcją jest zintegrowanie danych z rozwiązaniami do zarządzania informacjami i zdarzeniami zabezpieczeń (SIEM), takimi jak Microsoft Sentinel.

Zgodnie ze standardem wszystkie obszary robocze usługi Log Analytics są ustawione na 90-dniowy okres przechowywania. Rozważ skonfigurowanie eksportu ciągłego dla magazynu długoterminowego. Nie przechowuj poufnych informacji w danych dziennika i upewnij się, że dostęp do zarchiwizowanych danych dziennika podlega tym samym poziomom kontroli dostępu co ostatnie dane dziennika.

Aby uzyskać pełną perspektywę, zobacz przewodnik dołączania Microsoft Defender dla Chmury Enterprise. Ten przewodnik dotyczy rejestracji, eksportów danych do rozwiązań SIEM, reagowania na alerty i tworzenia automatyzacji przepływu pracy.

Pokrewne usługi platformy Azure

Oto linki do dokumentacji funkcji niektórych kluczowych składników tej architektury.

• Azure Kubernetes Service (AKS)
• Azure Firewall
• Azure Bastion
• Azure Image Builder
• Zestawy skalowania maszyn wirtualnych Azure
• aplikacja systemu Azure Gateway ze zintegrowaną zaporą aplikacji internetowej (WAF)
• Zadania usługi Azure Container Registry
• Azure Key Vault

Następne kroki

Instalowanie i obsługa konfiguracji zapory w celu ochrony danych posiadaczy kart. Nie używaj wartości domyślnych dostarczonych przez dostawcę dla haseł systemowych i innych parametrów zabezpieczeń.