Udostępnij za pośrednictwem


Zalecenia dotyczące zabezpieczeń sieci

W tym artykule wymieniono wszystkie zalecenia dotyczące zabezpieczeń sieci, które mogą zostać wyświetlone w Microsoft Defender dla Chmury.

Zalecenia wyświetlane w twoim środowisku są oparte na zasobach, które chronisz i na dostosowanej konfiguracji.

Aby dowiedzieć się więcej o akcjach, które można wykonać w odpowiedzi na te zalecenia, zobacz Korygowanie zaleceń w Defender dla Chmury.

Napiwek

Jeśli opis rekomendacji zawiera wartość Brak powiązanych zasad, zwykle jest to spowodowane tym, że zalecenie jest zależne od innej rekomendacji.

Na przykład zalecenie Niepowodzenia kondycji programu Endpoint Protection należy skorygować , opiera się na rekomendacji sprawdzającej, czy jest zainstalowane rozwiązanie ochrony punktu końcowego (należy zainstalować rozwiązanie Endpoint Protection). Rekomendacja bazowa ma zasady. Ograniczenie zasad tylko do podstawowych zaleceń upraszcza zarządzanie zasadami.

Zalecenia dotyczące sieci platformy Azure

Dostęp do kont magazynu z konfiguracją zapory i sieci wirtualnej powinien być ograniczony

Opis: Przejrzyj ustawienia dostępu sieciowego w ustawieniach zapory konta magazynu. Zalecamy skonfigurowanie reguł sieci, aby tylko aplikacje z dozwolonych sieci mogły uzyskiwać dostęp do konta magazynu. Aby zezwolić na połączenia z określonych klientów internetowych lub lokalnych, można udzielić dostępu do ruchu z określonych sieci wirtualnych platformy Azure lub do publicznych zakresów adresów IP internetowych. (Powiązane zasady: Konta magazynu powinny ograniczać dostęp sieciowy).

Ważność: Niska

Zalecenia dotyczące adaptacyjnego wzmacniania zabezpieczeń sieci powinny być stosowane na maszynach wirtualnych z dostępem do Internetu

Opis: Defender dla Chmury przeanalizowała wzorce komunikacji ruchu internetowego maszyn wirtualnych wymienionych poniżej i ustaliła, że istniejące reguły skojarzone z nimi sieciowe grupy zabezpieczeń są nadmiernie permissywne, co powoduje zwiększenie potencjalnego ataku. Zwykle występuje to, gdy ten adres IP nie komunikuje się regularnie z tym zasobem. Alternatywnie adres IP został oznaczony jako złośliwy przez źródła analizy zagrożeń Defender dla Chmury. (Powiązane zasady: Zalecenia dotyczące adaptacyjnego wzmacniania zabezpieczeń sieci powinny być stosowane na maszynach wirtualnych z dostępem do Internetu.

Ważność: Wysoka

Wszystkie porty sieciowe powinny być ograniczone w sieciowych grupach zabezpieczeń skojarzonych z maszyną wirtualną

Opis: Defender dla Chmury zidentyfikował niektóre reguły ruchu przychodzącego sieciowych grup zabezpieczeń, aby być zbyt permissywne. Reguły ruchu przychodzącego nie powinny zezwalać na dostęp z zakresów "Dowolny" ani "Internet". Może to potencjalnie umożliwić osobom atakującym kierowanie zasobów. (Powiązane zasady: Wszystkie porty sieciowe powinny być ograniczone w sieciowych grupach zabezpieczeń skojarzonych z maszyną wirtualną).

Ważność: Wysoka

Należy włączyć usługę Azure DDoS Protection w warstwie Standardowa

Opis: Defender dla Chmury odnaleziono sieci wirtualne z zasobami usługi Application Gateway, które nie są chronione przez usługę ochrony przed atakami DDoS. Te zasoby zawierają publiczne adresy IP. Umożliwia ograniczenie ryzyka ataków typu volumetric i protokołów sieciowych. (Powiązane zasady: Należy włączyć usługę Azure DDoS Protection w warstwie Standardowa).

Ważność: średni rozmiar

Maszyny wirtualne dostępne z Internetu powinny być chronione za pomocą sieciowych grup zabezpieczeń

Opis: Ochrona maszyny wirtualnej przed potencjalnymi zagrożeniami przez ograniczenie dostępu do niej za pomocą sieciowej grupy zabezpieczeń. Sieciowe grupy zabezpieczeń zawierają listę reguł listy kontroli dostępu (ACL), które zezwalają na ruch sieciowy do maszyny wirtualnej z innych wystąpień lub spoza tej samej podsieci lub poza tą samą podsiecią. Aby zapewnić jak największe bezpieczeństwo maszyny, dostęp maszyny wirtualnej do Internetu musi być ograniczony, a sieciowa grupa zabezpieczeń powinna być włączona w podsieci. Maszyny wirtualne o ważności "Wysoka" to maszyny wirtualne połączone z Internetem. (Powiązane zasady: Maszyny wirtualne dostępne z Internetu powinny być chronione za pomocą sieciowych grup zabezpieczeń).

Ważność: Wysoka

Przekazywanie adresów IP na maszynie wirtualnej powinno być wyłączone

Opis: Defender dla Chmury wykrył, że przekazywanie ip jest włączone na niektórych maszynach wirtualnych. Włączenie przekazywania adresów IP na karcie sieciowej maszyny wirtualnej umożliwia maszynie odbieranie ruchu adresowanego do innych miejsc docelowych. Przekazywanie adresów IP jest rzadko wymagane (np. w przypadku korzystania z maszyny wirtualnej jako wirtualnego urządzenia sieciowego), dlatego powinno to zostać przejrzane przez zespół ds. zabezpieczeń sieci. (Powiązane zasady: Przekazywanie adresów IP na maszynie wirtualnej powinno być wyłączone.

Ważność: średni rozmiar

Maszyny powinny mieć zamknięte porty, które mogą uwidaczniać wektory ataków

Opis: Warunki użytkowania platformy Azure uniemożliwiają korzystanie z usług platformy Azure w sposób, który może uszkodzić, wyłączyć, przeciążyć lub osłabić dowolny serwer firmy Microsoft lub sieć. To zalecenie zawiera listę uwidocznionych portów, które należy zamknąć w celu zapewnienia ciągłego zabezpieczeń. Ilustruje również potencjalne zagrożenie dla każdego portu. (Brak powiązanych zasad)

Ważność: Wysoka

Porty zarządzania maszyn wirtualnych powinny być chronione za pomocą kontroli dostępu do sieci just in time

Opis: Defender dla Chmury zidentyfikował pewne nadmiernie permissywne reguły ruchu przychodzącego dla portów zarządzania w sieciowej grupie zabezpieczeń. Włącz kontrolę dostępu just in time, aby chronić maszynę wirtualną przed atakami siłowymi opartymi na Internecie. Dowiedz się więcej w artykule Understanding just-in-time (JIT) VM access (Dostęp just in time) do maszyny wirtualnej. (Powiązane zasady: Porty zarządzania maszyn wirtualnych powinny być chronione za pomocą kontroli dostępu do sieci just in time.

Ważność: Wysoka

Porty zarządzania powinny być zamknięte na maszynach wirtualnych

Opis: Otwieranie portów zdalnego zarządzania uwidacznia maszynę wirtualną na wysokim poziomie ryzyka związanego z atakami internetowymi. Te ataki próbują wymusić na nich poświadczenia, aby uzyskać dostęp administratora do maszyny. (Powiązane zasady: Porty zarządzania powinny być zamknięte na maszynach wirtualnych).

Ważność: średni rozmiar

Maszyny wirtualne bez Internetu powinny być chronione za pomocą sieciowych grup zabezpieczeń

Opis: Chroń maszynę wirtualną, która nie jest dostępna z Internetu przed potencjalnymi zagrożeniami, ograniczając dostęp do niej za pomocą sieciowej grupy zabezpieczeń. Sieciowe grupy zabezpieczeń zawierają listę reguł listy kontroli dostępu (ACL), które zezwalają na ruch sieciowy do maszyny wirtualnej z innych wystąpień, niezależnie od tego, czy znajdują się one w tej samej podsieci. Należy pamiętać, że aby zapewnić bezpieczeństwo maszyny, dostęp maszyny wirtualnej do Internetu musi być ograniczony, a sieciowa grupa zabezpieczeń powinna być włączona w podsieci. (Powiązane zasady: Maszyny wirtualne bez Internetu powinny być chronione za pomocą sieciowych grup zabezpieczeń.

Ważność: Niska

Bezpieczny transfer do kont magazynu powinien być włączony

Opis: Bezpieczny transfer to opcja, która wymusza akceptowanie żądań tylko z bezpiecznych połączeń (HTTPS). Użycie protokołu HTTPS zapewnia uwierzytelnianie między serwerem a usługą i chroni dane przesyłane przed atakami warstwy sieciowej, takimi jak man-in-the-middle, podsłuchiwanie i przejęcie sesji. (Powiązane zasady: Należy włączyć bezpieczny transfer do kont magazynu.

Ważność: Wysoka

Podsieci powinny być skojarzone z sieciową grupą zabezpieczeń

Opis: Ochrona podsieci przed potencjalnymi zagrożeniami przez ograniczenie dostępu do niej za pomocą sieciowej grupy zabezpieczeń. Sieciowe grupy zabezpieczeń zawierają listę reguł listy kontroli dostępu (ACL), które zezwalają lub odmawiają ruchu sieciowego do podsieci. Gdy sieciowa grupa zabezpieczeń jest skojarzona z podsiecią, reguły listy ACL dotyczą wszystkich wystąpień maszyn wirtualnych i zintegrowanych usług w tej podsieci, ale nie mają zastosowania do ruchu wewnętrznego wewnątrz podsieci. Aby zabezpieczyć zasoby w tej samej podsieci między sobą, włącz również sieciową grupę zabezpieczeń bezpośrednio w zasobach. Należy pamiętać, że następujące typy podsieci będą wyświetlane jako nie dotyczy: GatewaySubnet, AzureFirewallSubnet, AzureBastionSubnet. (Powiązane zasady: Podsieci powinny być skojarzone z sieciową grupą zabezpieczeń.

Ważność: Niska

Sieci wirtualne powinny być chronione przez usługę Azure Firewall

Opis: Niektóre sieci wirtualne nie są chronione za pomocą zapory. Użyj usługi Azure Firewall , aby ograniczyć dostęp do sieci wirtualnych i zapobiec potencjalnym zagrożeniom. (Powiązane zasady: Cały ruch internetowy powinien być kierowany za pośrednictwem wdrożonej usługi Azure Firewall.

Zalecenia dotyczące sieci platformy AWS

Usługa Amazon EC2 powinna być skonfigurowana do używania punktów końcowych VPC

Opis: Ta kontrolka sprawdza, czy dla każdego VPC jest tworzony punkt końcowy usługi dla usługi Amazon EC2. Kontrolka kończy się niepowodzeniem, jeśli VPC nie ma punktu końcowego VPC utworzonego dla usługi Amazon EC2. Aby poprawić stan zabezpieczeń maszyny wirtualnej VPC, możesz skonfigurować usługę Amazon EC2 do korzystania z punktu końcowego VPC interfejsu. Punkty końcowe interfejsu są obsługiwane przez usługę AWS PrivateLink, czyli technologię, która umożliwia prywatną dostęp do operacji interfejsu API usługi Amazon EC2. Ogranicza cały ruch sieciowy między VPC i Amazon EC2 do sieci Amazon. Ponieważ punkty końcowe są obsługiwane tylko w tym samym regionie, nie można utworzyć punktu końcowego między serwerem VPC a usługą w innym regionie. Zapobiega to niezamierzonym wywołaniom interfejsu API usługi Amazon EC2 do innych regionów. Aby dowiedzieć się więcej na temat tworzenia punktów końcowych VPC dla usługi Amazon EC2, zobacz Punkty końcowe usługi Amazon EC2 i interfejsu VPC w przewodniku użytkownika usługi Amazon EC2 dla wystąpień systemu Linux.

Ważność: średni rozmiar

Usługi Amazon ECS nie powinny mieć przypisanych automatycznie publicznych adresów IP

Opis: Publiczny adres IP jest adresem IP dostępnym z Internetu. Jeśli uruchomisz wystąpienia usługi Amazon ECS z publicznym adresem IP, wystąpienia usługi Amazon ECS będą dostępne z Internetu. Usługi Amazon ECS nie powinny być publicznie dostępne, ponieważ może to umożliwić niezamierzony dostęp do serwerów aplikacji kontenera.

Ważność: Wysoka

Węzły główne klastra usługi Amazon EMR nie powinny mieć publicznych adresów IP

Opis: Ta kontrolka sprawdza, czy węzły główne w klastrach Amazon EMR mają publiczne adresy IP. Kontrolka kończy się niepowodzeniem, jeśli węzeł główny ma publiczne adresy IP skojarzone z dowolnym z jego wystąpień. Publiczne adresy IP są wyznaczone w polu PublicIp konfiguracji NetworkInterfaces dla wystąpienia. Ta kontrolka sprawdza tylko klastry Amazon EMR, które znajdują się w stanie RUNNING lub WAITING.

Ważność: Wysoka

Klastry Amazon Redshift powinny używać rozszerzonego routingu VPC

Opis: Ta kontrolka sprawdza, czy klaster Amazon Redshift ma włączoną usługę EnhancedVpcRouting. Ulepszony routing VPC wymusza cały ruch COPY i UNLOAD między klastrem a repozytoriami danych w celu przejścia przez VPC. Następnie można użyć funkcji VPC, takich jak grupy zabezpieczeń i listy kontroli dostępu do sieci, aby zabezpieczyć ruch sieciowy. Dzienniki przepływu VPC można również użyć do monitorowania ruchu sieciowego.

Ważność: Wysoka

Moduł równoważenia obciążenia aplikacji należy skonfigurować tak, aby przekierowywał wszystkie żądania HTTP do protokołu HTTPS

Opis: Aby wymusić szyfrowanie podczas przesyłania, należy użyć akcji przekierowania z modułami równoważenia obciążenia aplikacji w celu przekierowania żądań HTTP klienta do żądania HTTPS na porcie 443.

Ważność: średni rozmiar

Moduły równoważenia obciążenia aplikacji należy skonfigurować tak, aby usuwały nagłówki HTTP

Opis: Ta kontrolka ocenia moduły równoważenia obciążenia aplikacji platformy AWS (ALB), aby upewnić się, że są skonfigurowane do upuszczania nieprawidłowych nagłówków HTTP. Kontrolka kończy się niepowodzeniem, jeśli wartość routing.http.drop_invalid_header_fields.enabled jest ustawiona na wartość false. Domyślnie alb nie są skonfigurowane do porzucania nieprawidłowych wartości nagłówka HTTP. Usunięcie tych wartości nagłówka zapobiega atakom desync HTTP.

Ważność: średni rozmiar

Konfigurowanie funkcji lambda do VPC

Opis: Ta kontrolka sprawdza, czy funkcja lambda znajduje się w VPC. Nie ocenia konfiguracji routingu podsieci VPC w celu określenia dostępności publicznej. Należy pamiętać, że jeśli Lambda@Edge zostanie znaleziona na koncie, ta kontrolka generuje wyniki niepowodzenia. Aby zapobiec tym ustaleniam, możesz wyłączyć tę kontrolkę.

Ważność: Niska

Wystąpienia usługi EC2 nie powinny mieć publicznego adresu IP

Opis: Ta kontrolka sprawdza, czy wystąpienia usługi EC2 mają publiczny adres IP. Kontrolka kończy się niepowodzeniem, jeśli pole "publicIp" znajduje się w elemencie konfiguracji wystąpienia usługi EC2. Ta kontrolka dotyczy tylko adresów IPv4. Publiczny adres IPv4 to adres IP dostępny z Internetu. Jeśli uruchomisz wystąpienie przy użyciu publicznego adresu IP, wystąpienie usługi EC2 będzie dostępne z Internetu. Prywatny adres IPv4 to adres IP, który nie jest dostępny z Internetu. Prywatne adresy IPv4 można używać do komunikacji między wystąpieniami usługi EC2 w tej samej sieci VPC lub w połączonej sieci prywatnej. Adresy IPv6 są globalnie unikatowe i dlatego są dostępne z Internetu. Jednak domyślnie wszystkie podsieci mają atrybut adresowania IPv6 ustawiony na wartość false. Aby uzyskać więcej informacji na temat protokołu IPv6, zobacz Adresowanie IP w VPC w podręczniku użytkownika usługi Amazon VPC . Jeśli masz uzasadniony przypadek użycia do obsługi wystąpień USŁUGI EC2 z publicznymi adresami IP, możesz pominąć wyniki tej kontroli. Aby uzyskać więcej informacji na temat opcji architektury frontonu, zobacz blog dotyczący architektury platformy AWS lub serię This Is My Architecture (To jest moja architektura).

Ważność: Wysoka

Wystąpienia usługi EC2 nie powinny używać wielu enI

Opis: Ta kontrolka sprawdza, czy wystąpienie usługi EC2 używa wielu elastycznych interfejsów sieciowych (ENI) lub elastycznych kart sieci szkieletowych (EFA). Ta kontrolka przechodzi w przypadku użycia pojedynczej karty sieciowej. Kontrolka zawiera opcjonalną listę parametrów identyfikującą dozwolone enI. Wiele enI może powodować wystąpienia z dwoma homed, co oznacza, że wystąpienia, które mają wiele podsieci. Może to zwiększyć złożoność zabezpieczeń sieci i wprowadzić niezamierzone ścieżki sieciowe i dostęp.

Ważność: Niska

Wystąpienia usługi EC2 powinny używać usługi IMDSv2

Opis: Ta kontrolka sprawdza, czy wersja metadanych wystąpienia usługi EC2 jest skonfigurowana przy użyciu usługi metadanych wystąpienia w wersji 2 (IMDSv2). Kontrolka przechodzi, jeśli parametr "HttpTokens" jest ustawiony na wartość "required" dla usługi IMDSv2. Kontrolka kończy się niepowodzeniem, jeśli wartość "HttpTokens" jest ustawiona na wartość "optional". Metadane wystąpienia służą do konfigurowania uruchomionego wystąpienia lub zarządzania nim. ImDS zapewnia dostęp do tymczasowych, często obracanych poświadczeń. Te poświadczenia usuwają potrzebę kodowania twardego lub dystrybuowania poufnych poświadczeń do wystąpień ręcznie lub programowo. ImDS jest dołączany lokalnie do każdego wystąpienia usługi EC2. Jest on uruchamiany na specjalnym adresie IP "link lokalny" 169.254.169.254. Ten adres IP jest dostępny tylko przez oprogramowanie, które działa w wystąpieniu. Wersja 2 usługi IMDS dodaje nowe zabezpieczenia dla następujących typów luk w zabezpieczeniach. Te luki w zabezpieczeniach mogą służyć do próby uzyskania dostępu do imDS.

  • Otwieranie zapór aplikacji witryny internetowej
  • Otwieranie odwrotnych serwerów proxy
  • Luki w zabezpieczeniach żądania po stronie serwera (SSRF)
  • Open Layer 3 firewalls and network address translation (NAT) Security Hub zaleca skonfigurowanie wystąpień USŁUGI EC2 za pomocą usługi IMDSv2.

Ważność: Wysoka

Podsieci EC2 nie powinny automatycznie przypisywać publicznych adresów IP

Opis: Ta kontrolka sprawdza, czy przypisanie publicznych adresów IP w podsieciach Amazon Virtual Private Cloud (Amazon VPC) ma ustawioną wartość "MapPublicIpOnLaunch". Kontrolka przechodzi, jeśli flaga jest ustawiona na "FAŁSZ". Wszystkie podsieci mają atrybut określający, czy interfejs sieciowy utworzony w podsieci automatycznie odbiera publiczny adres IPv4. Wystąpienia uruchamiane w podsieciach z włączonym tym atrybutem mają publiczny adres IP przypisany do podstawowego interfejsu sieciowego.

Ważność: średni rozmiar

Upewnij się, że istnieje filtr metryki dziennika i alarm dla zmian konfiguracji konfiguracji platformy AWS

Opis: Monitorowanie wywołań interfejsu API w czasie rzeczywistym można osiągnąć, kierując dzienniki CloudTrail do dzienników CloudWatch i ustanawiając odpowiednie filtry metryk i alarmy. Zaleca się ustanowienie filtru metryki i alarmu w celu wykrywania zmian w konfiguracjach usługi CloudTrail. Monitorowanie zmian w konfiguracji konfiguracji platformy AWS pomaga zapewnić trwały wgląd elementów konfiguracji na koncie platformy AWS.

Ważność: Niska

Upewnij się, że istnieje filtr metryki dziennika i alarm dla błędów uwierzytelniania w konsoli zarządzania platformy AWS

Opis: Monitorowanie wywołań interfejsu API w czasie rzeczywistym można osiągnąć, kierując dzienniki CloudTrail do dzienników CloudWatch i ustanawiając odpowiednie filtry metryk i alarmy. Zaleca się ustanowienie filtru metryki i alarmu w przypadku nieudanych prób uwierzytelniania konsoli. Monitorowanie nieudanych logowań konsoli może skrócić czas realizacji w celu wykrycia próby wymuszenia próby wymuszenia poświadczenia, co może dostarczyć wskaźnik, taki jak źródłowy adres IP, który może być używany w innej korelacji zdarzeń.

Ważność: Niska

Upewnij się, że istnieje filtr metryki dziennika i alarm dla zmian w listach kontroli dostępu do sieci (NACL)

Opis: Monitorowanie wywołań interfejsu API w czasie rzeczywistym można osiągnąć, kierując dzienniki CloudTrail do dzienników CloudWatch i ustanawiając odpowiednie filtry metryk i alarmy. Listy NACLs są używane jako bezstanowy filtr pakietów do kontrolowania ruchu przychodzącego i wychodzącego dla podsieci w ramach VPC. Zaleca się ustanowienie filtru metryki i alarmu dla zmian wprowadzonych w listach NACLs. Monitorowanie zmian w listach NACLs pomaga zagwarantować, że zasoby i usługi platformy AWS nie są przypadkowo uwidocznione.

Ważność: Niska

Upewnij się, że istnieje filtr metryki dziennika i alarm dla zmian w bramach sieci

Opis: Monitorowanie wywołań interfejsu API w czasie rzeczywistym można osiągnąć, kierując dzienniki CloudTrail do dzienników CloudWatch i ustanawiając odpowiednie filtry metryk i alarmy. Bramy sieci są wymagane do wysyłania/odbierania ruchu do miejsca docelowego poza siecią VPC. Zaleca się ustanowienie filtru metryki i alarmu w przypadku zmian w bramach sieci. Monitorowanie zmian w bramach sieciowych pomaga zapewnić, że cały ruch przychodzący/wychodzący przechodzi przez obramowanie VPC za pośrednictwem kontrolowanej ścieżki.

Ważność: Niska

Upewnij się, że istnieje filtr metryki dziennika i alarm dla zmian konfiguracji cloudTrail

Opis: Monitorowanie wywołań interfejsu API w czasie rzeczywistym można osiągnąć, kierując dzienniki CloudTrail do dzienników CloudWatch i ustanawiając odpowiednie filtry metryk i alarmy. Zaleca się ustanowienie filtru metryki i alarmu w celu wykrywania zmian w konfiguracjach usługi CloudTrail.

Monitorowanie zmian w konfiguracji usługi CloudTrail pomaga zapewnić trwały wgląd w działania wykonywane na koncie platformy AWS.

Ważność: Niska

Upewnij się, że istnieje filtr metryki dziennika i alarm dotyczący wyłączania lub zaplanowanego usuwania utworzonych przez klienta zestawów cmKs

Opis: Monitorowanie wywołań interfejsu API w czasie rzeczywistym można osiągnąć, kierując dzienniki CloudTrail do dzienników CloudWatch i ustanawiając odpowiednie filtry metryk i alarmy. Zaleca się ustanowienie filtru metryki i alarmu dla utworzonych przez klienta zestawów CMKs, które zmieniły stan na wyłączone lub zaplanowane usunięcie. Dane zaszyfrowane przy użyciu wyłączonych lub usuniętych kluczy nie będą już dostępne.

Ważność: Niska

Upewnij się, że istnieje filtr metryki dziennika i alarm dla zmian zasad zarządzania dostępem i tożsamościami

Opis: Monitorowanie wywołań interfejsu API w czasie rzeczywistym można osiągnąć, kierując dzienniki CloudTrail do dzienników CloudWatch i ustanawiając odpowiednie filtry metryk i alarmy. Zaleca się ustanowienie zmian filtru metryki i alarmu w zasadach zarządzania tożsamościami i dostępem (IAM). Monitorowanie zmian zasad zarządzania dostępem i tożsamościami pomaga zapewnić, że mechanizmy kontroli uwierzytelniania i autoryzacji pozostaną nienaruszone.

Ważność: Niska

Upewnij się, że istnieje filtr metryki dziennika i alarm dla logowania w konsoli zarządzania bez uwierzytelniania wieloskładnikowego

Opis: Monitorowanie wywołań interfejsu API w czasie rzeczywistym można osiągnąć, kierując dzienniki CloudTrail do dzienników CloudWatch i ustanawiając odpowiednie filtry metryk i alarmy. Zaleca się ustanowienie filtru metryki i alarmu dla identyfikatorów logowania konsoli, które nie są chronione przez uwierzytelnianie wieloskładnikowe (MFA). Monitorowanie logowania do konsoli jednoskładnikowej zwiększa wgląd w konta, które nie są chronione przez usługę MFA.

Ważność: Niska

Upewnij się, że istnieje filtr metryk dziennika i alarm dla zmian tabeli tras

Opis: Monitorowanie wywołań interfejsu API w czasie rzeczywistym można osiągnąć, kierując dzienniki CloudTrail do dzienników CloudWatch i ustanawiając odpowiednie filtry metryk i alarmy. Tabele routingu służą do kierowania ruchu sieciowego między podsieciami i do bram sieciowych. Zaleca się ustanowienie filtru metryki i alarmu dla zmian w tabelach tras. Monitorowanie zmian w tabelach tras pomaga zapewnić, że cały ruch VPC przepływa przez oczekiwaną ścieżkę.

Ważność: Niska

Upewnij się, że istnieje filtr metryk dziennika i alarm dla zmian zasad zasobnika S3

Opis: Monitorowanie wywołań interfejsu API w czasie rzeczywistym można osiągnąć, kierując dzienniki CloudTrail do dzienników CloudWatch i ustanawiając odpowiednie filtry metryk i alarmy. Zaleca się ustanowienie filtru metryki i alarmu dla zmian zasad zasobnika S3. Monitorowanie zmian w zasadach zasobników S3 może skrócić czas wykrywania i poprawiania zasad dotyczących poufnych zasobników S3.

Ważność: Niska

Upewnij się, że istnieje filtr metryki dziennika i alarm dla zmian grupy zabezpieczeń

Opis: Monitorowanie wywołań interfejsu API w czasie rzeczywistym można osiągnąć, kierując dzienniki CloudTrail do dzienników CloudWatch i ustanawiając odpowiednie filtry metryk i alarmy. Grupy zabezpieczeń to stanowy filtr pakietów, który kontroluje ruch przychodzący i wychodzący w ramach VPC. Zaleca się ustanowienie filtru metryki i alarmu w grupach zabezpieczeń. Monitorowanie zmian w grupie zabezpieczeń pomaga zagwarantować, że zasoby i usługi nie są przypadkowo uwidocznione.

Ważność: Niska

Upewnij się, że istnieje filtr metryki dziennika i alarm dla nieautoryzowanych wywołań interfejsu API

Opis: Monitorowanie wywołań interfejsu API w czasie rzeczywistym można osiągnąć, kierując dzienniki CloudTrail do dzienników CloudWatch i ustanawiając odpowiednie filtry metryk i alarmy. Zaleca się ustanowienie filtru metryki i alarmu dla nieautoryzowanych wywołań interfejsu API. Monitorowanie nieautoryzowanych wywołań interfejsu API pomaga ujawnić błędy aplikacji i może skrócić czas wykrywania złośliwych działań.

Ważność: Niska

Upewnij się, że istnieje filtr metryki dziennika i alarm dotyczący użycia konta "root"

Opis: Monitorowanie wywołań interfejsu API w czasie rzeczywistym można osiągnąć, kierując dzienniki CloudTrail do dzienników CloudWatch i ustanawiając odpowiednie filtry metryk i alarmy. Zaleca się ustanowienie filtru metryki i alarmu dla prób logowania głównego.

Monitorowanie identyfikatorów logowania konta głównego zapewnia wgląd w korzystanie z w pełni uprzywilejowanego konta i możliwość zmniejszenia jego użycia.

Ważność: Niska

Upewnij się, że istnieje filtr metryki dziennika i alarm dla zmian VPC

Opis: Monitorowanie wywołań interfejsu API w czasie rzeczywistym można osiągnąć, kierując dzienniki CloudTrail do dzienników CloudWatch i ustanawiając odpowiednie filtry metryk i alarmy. Istnieje możliwość posiadania więcej niż jednego wirtualnego wywołania procedury na koncie, ponadto istnieje również możliwość utworzenia połączenia równorzędnego między 2 wirtualnymi kontrolerami sieciowymi umożliwiającymi kierowanie ruchu sieciowego między wirtualnymi kontrolerami sieci. Zaleca się ustanowienie filtru metryki i alarmu dla zmian wprowadzonych w sieciACH VPN. Monitorowanie zmian zasad zarządzania dostępem i tożsamościami pomaga zapewnić, że mechanizmy kontroli uwierzytelniania i autoryzacji pozostaną nienaruszone.

Ważność: Niska

Upewnij się, że żadne grupy zabezpieczeń nie zezwalają na ruch przychodzący z wersji 0.0.0.0/0 do portu 3389

Opis: Grupy zabezpieczeń zapewniają stanowe filtrowanie ruchu sieciowego ruchu przychodzącego/wychodzącego do zasobów platformy AWS. Zaleca się, aby żadna grupa zabezpieczeń nie zezwalała na nieograniczony dostęp przychodzący do portu 3389. Usunięcie nieskrępowanej łączności z usługami konsoli zdalnej, takich jak RDP, zmniejsza narażenie serwera na ryzyko.

Ważność: Wysoka

Bazy danych i klastry usług pulpitu zdalnego nie powinny używać domyślnego portu aparatu bazy danych

Opis: Ta kontrolka sprawdza, czy klaster usług pulpitu zdalnego lub wystąpienie używa portu innego niż domyślny port aparatu bazy danych. Jeśli używasz znanego portu do wdrożenia klastra lub wystąpienia usług pulpitu zdalnego, osoba atakująca może odgadnąć informacje o klastrze lub wystąpieniu. Osoba atakująca może używać tych informacji w połączeniu z innymi informacjami, aby nawiązać połączenie z klastrem usług pulpitu zdalnego lub wystąpieniem lub uzyskać dodatkowe informacje o aplikacji. Po zmianie portu należy również zaktualizować istniejące parametry połączenia, które zostały użyte do nawiązania połączenia ze starym portem. Należy również sprawdzić grupę zabezpieczeń wystąpienia bazy danych, aby upewnić się, że zawiera regułę ruchu przychodzącego zezwalającą na łączność na nowym porcie.

Ważność: Niska

Wystąpienia usług pulpitu zdalnego powinny być wdrażane w VPC

Opis: VpCs zapewniają szereg mechanizmów kontroli sieci w celu zabezpieczenia dostępu do zasobów usług pulpitu zdalnego. Te kontrolki obejmują punkty końcowe VPC, listy ACL sieci i grupy zabezpieczeń. Aby skorzystać z tych kontrolek, zalecamy przeniesienie wystąpień usług pulpitu zdalnego EC2-Classic do ec2-VPC.

Ważność: Niska

Zasobniki S3 powinny wymagać żądań używania protokołu Secure Socket Layer

Opis: Zalecamy wymaganie od żądań używania protokołu Secure Socket Layer (SSL) we wszystkich zasobnikach usługi Amazon S3. Zasobniki S3 powinny mieć zasady, które wymagają wszystkich żądań ('Action: S3:*'), aby akceptowały tylko przesyłanie danych za pośrednictwem protokołu HTTPS w zasadach zasobów S3, wskazywane przez klucz warunku "aws:SecureTransport".

Ważność: średni rozmiar

Grupy zabezpieczeń nie powinny zezwalać na ruch przychodzący z wersji 0.0.0.0/0 do portu 22

Opis: Aby zmniejszyć narażenie serwera, zaleca się, aby nie zezwalać na nieograniczony dostęp przychodzący do portu "22".

Ważność: Wysoka

Grupy zabezpieczeń nie powinny zezwalać na nieograniczony dostęp do portów z wysokim ryzykiem

Opis: Ta kontrolka sprawdza, czy nieograniczony ruch przychodzący dla grup zabezpieczeń jest dostępny dla określonych portów, które mają największe ryzyko. Ta kontrolka przechodzi, gdy żadna z reguł w grupie zabezpieczeń nie zezwala na ruch przychodzący z 0.0.0.0/0 dla tych portów. Nieograniczony dostęp (0.0.0.0/0) zwiększa możliwości złośliwego działania, takie jak ataki hakerskie, ataki typu "odmowa usługi" i utrata danych. Grupy zabezpieczeń zapewniają stanowe filtrowanie ruchu przychodzącego i wychodzącego ruchu sieciowego do zasobów platformy AWS. Żadna grupa zabezpieczeń nie powinna zezwalać na nieograniczony dostęp przychodzący do następujących portów:

  • 3389 (RDP)
  • 20, 21 (FTP)
  • 22 (SSH)
  • 23 (Telnet)
  • 110 (POP3)
  • 143 (IMAP)
  • 3306 (MySQL)
  • 8080 (serwer proxy)
  • 1433, 1434 (MSSQL)
  • 9200 lub 9300 (Elasticsearch)
  • 5601 (Kibana)
  • 25 (SMTP)
  • 445 (CIFS)
  • 135 (RPC)
  • 4333 (ahsp)
  • 5432 (postgresql)
  • 5500 (fcp-addr-srvr1)

Ważność: średni rozmiar

Grupy zabezpieczeń powinny zezwalać tylko na nieograniczony ruch przychodzący dla autoryzowanych portów

Opis: Ta kontrolka sprawdza, czy grupy zabezpieczeń, które są używane zezwalają na nieograniczony ruch przychodzący. Opcjonalnie reguła sprawdza, czy numery portów są wyświetlane w parametrze "authorizedTcpPorts".

  • Jeśli numer portu reguły grupy zabezpieczeń zezwala na nieograniczony ruch przychodzący, ale numer portu jest określony w "authorizedTcpPorts", kontrolka przechodzi. Wartość domyślna "authorizedTcpPorts" to 80, 443.
  • Jeśli numer portu reguły grupy zabezpieczeń zezwala na nieograniczony ruch przychodzący, ale numer portu nie jest określony w parametrze wejściowym authorizedTcpPorts, kontrolka kończy się niepowodzeniem.
  • Jeśli parametr nie jest używany, kontrolka kończy się niepowodzeniem dla każdej grupy zabezpieczeń, która ma nieograniczoną regułę ruchu przychodzącego. Grupy zabezpieczeń zapewniają stanowe filtrowanie ruchu przychodzącego i wychodzącego do platformy AWS. Reguły grupy zabezpieczeń powinny być zgodne z zasadą najmniej uprzywilejowanego dostępu. Nieograniczony dostęp (adres IP z sufiksem /0) zwiększa możliwość złośliwych działań, takich jak hacking, ataki typu "odmowa usługi" i utrata danych. Jeśli port nie jest w szczególności dozwolony, port powinien blokować nieograniczony dostęp.

Ważność: Wysoka

Należy usunąć nieużywane adresy EIPS EC2

Opis: Elastyczne adresy IP przydzielone do VPC powinny być dołączone do wystąpień usługi Amazon EC2 lub elastycznych interfejsów sieciowych (ENI).

Ważność: Niska

Należy usunąć nieużywane listy kontroli dostępu do sieci

Opis: Ta kontrolka sprawdza, czy istnieją nieużywane listy kontroli dostępu do sieci (ACL). Kontrolka sprawdza konfigurację elementu zasobu "AWS::EC2::NetworkAcl" i określa relacje listy ACL sieci. Jeśli jedyną relacją jest VPC listy ACL sieci, kontrolka kończy się niepowodzeniem. Jeśli zostaną wyświetlone inne relacje, kontrolka przejdzie pomyślnie.

Ważność: Niska

Domyślna grupa zabezpieczeń VPC powinna ograniczać cały ruch

Opis: Grupa zabezpieczeń powinna ograniczyć cały ruch, aby zmniejszyć narażenie na zasoby.

Ważność: Niska

Zalecenia dotyczące sieci GCP

Hosty klastra powinny być skonfigurowane do używania tylko prywatnych, wewnętrznych adresów IP w celu uzyskiwania dostępu do interfejsów API Google

Opis: To zalecenie ocenia, czy właściwość privateIpGoogleAccess podsieci ma wartość false.

Ważność: Wysoka

Wystąpienia obliczeniowe powinny używać modułu równoważenia obciążenia skonfigurowanego do używania docelowego serwera proxy HTTPS

Opis: To zalecenie ocenia, czy właściwość selfLink zasobu targetHttpProxy jest zgodna z atrybutem docelowym w regule przekazywania, a jeśli reguła przekazywania zawiera pole loadBalancingScheme ustawione na Wartość Zewnętrzna.

Ważność: średni rozmiar

Sieci autoryzowane na płaszczyźnie sterowania powinny być włączone w klastrach GKE

Opis: To zalecenie ocenia właściwość masterAuthorizedNetworksConfig klastra dla pary klucz-wartość "enabled": false.

Ważność: Wysoka

Reguła odmowy ruchu wychodzącego powinna być ustawiona na zaporze w celu blokowania niechcianego ruchu wychodzącego

Opis: To zalecenie ocenia, czy właściwość destinationRanges w zaporze ma wartość 0.0.0.0.0/0, a właściwość odmowy zawiera parę klucz-wartość, 'IPProtocol': 'all.'

Ważność: Niska

Upewnij się, że reguły zapory dla wystąpień za serwerem proxy obsługującym tożsamość (IAP) zezwalają tylko na ruch z usługi Google Cloud Loadbalancer (GCLB) kontroli kondycji i adresów proxy

Opis: Dostęp do maszyn wirtualnych powinien być ograniczony przez reguły zapory, które zezwalają tylko na ruch IAP, zapewniając, że dozwolone są tylko połączenia proxied przez protokół IAP. Aby upewnić się, że równoważenie obciążenia działa prawidłowo, należy również zezwolić na sprawdzanie kondycji. Protokół IAP zapewnia, że dostęp do maszyn wirtualnych jest kontrolowany przez uwierzytelnianie żądań przychodzących. Jeśli jednak maszyna wirtualna jest nadal dostępna z adresów IP innych niż IAP, nadal może być możliwe wysyłanie nieuwierzytelnionych żądań do wystąpienia. Należy zadbać o to, aby upewnić się, że testy kondycji modułu równoważenia obciążenia nie są blokowane, ponieważ uniemożliwia to prawidłowe poznanie kondycji maszyny wirtualnej i równoważenia obciążenia.

Ważność: średni rozmiar

Upewnij się, że starsze sieci nie istnieją dla projektu

Opis: Aby zapobiec używaniu starszych sieci, projekt nie powinien mieć skonfigurowanej starszej sieci. Starsze sieci mają jeden zakres prefiksów IPv4 sieci i pojedynczy adres IP bramy dla całej sieci. Sieć jest globalna w zakresie i obejmuje wszystkie regiony chmury. Nie można utworzyć podsieci w starszej sieci i nie można przełączyć się ze starszej wersji na automatyczne lub niestandardowe sieci podsieci. Starsze sieci mogą mieć wpływ na projekty o dużym natężeniu ruchu sieciowego i podlegają pojedynczemu punktowi rywalizacji lub awarii.

Ważność: średni rozmiar

Upewnij się, że flaga bazy danych "log_hostname" dla wystąpienia usługi Cloud SQL PostgreSQL jest odpowiednio ustawiona

Opis: Usługa PostgreSQL rejestruje tylko adres IP hostów łączących. Flaga "log_hostname" kontroluje rejestrowanie "nazw hostów" oprócz zarejestrowanych adresów IP. Osiągnięcie wydajności zależy od konfiguracji środowiska i konfiguracji rozpoznawania nazw hosta. Ten parametr można ustawić tylko w pliku "postgresql.conf" lub w wierszu polecenia serwera. Rejestrowanie nazw hostów może powodować narzut na wydajność serwera, ponieważ dla każdej zarejestrowanej instrukcji rozpoznawanie nazw DNS będzie wymagane do przekonwertowania adresu IP na nazwę hosta. W zależności od konfiguracji może to być nieistotne. Ponadto adresy IP, które są rejestrowane, można rozpoznać ich nazwy DNS później podczas przeglądania dzienników z wyłączeniem przypadków, w których są używane dynamiczne nazwy hostów. To zalecenie dotyczy wystąpień bazy danych PostgreSQL.

Ważność: Niska

Upewnij się, że moduły równoważenia obciążenia https lub SSL nie zezwalają na zasady PROTOKOŁU SSL ze słabymi zestawami szyfrowania

Opis: Zasady protokołu SSL (Secure Sockets Layer) określają, które funkcje protokołu Transport Layer Security (TLS) portów mogą być używane przez klientów podczas nawiązywania połączenia z modułami równoważenia obciążenia. Aby zapobiec użyciu niezabezpieczonych funkcji, zasady SSL powinny używać (a) co najmniej protokołu TLS 1.2 z profilem MODERN; lub (b) profil OGRANICZONY, ponieważ efektywnie wymaga od klientów używania protokołu TLS 1.2 niezależnie od wybranej minimalnej wersji protokołu TLS; lub (3) profil NIESTANDARDOWY, który nie obsługuje żadnej z następujących funkcji: TLS_RSA_WITH_AES_128_GCM_SHA256 TLS_RSA_WITH_AES_256_GCM_SHA384 TLS_RSA_WITH_AES_128_CBC_SHA TLS_RSA_WITH_AES_256_CBC_SHA TLS_RSA_WITH_3DES_EDE_CBC_SHA

Moduły równoważenia obciążenia są używane do efektywnego dystrybuowania ruchu między wieloma serwerami. Zarówno serwer proxy SSL, jak i moduły równoważenia obciążenia HTTPS są zewnętrznymi modułami równoważenia obciążenia, co oznacza, że dystrybuują ruch z Internetu do sieci GCP. Klienci GCP mogą skonfigurować zasady protokołu SSL modułu równoważenia obciążenia z minimalną wersją protokołu TLS (1.0, 1.1 lub 1.2), których klienci mogą używać do nawiązywania połączenia, wraz z profilem (zgodnym, nowoczesnym, ograniczonym lub niestandardowym), który określa dopuszczalne zestawy szyfrowania. Aby zapewnić zgodność z użytkownikami korzystającymi z nieaktualnych protokołów, moduły równoważenia obciążenia GCP można skonfigurować tak, aby zezwalały na niezabezpieczone zestawy szyfrowania. W rzeczywistości domyślne zasady protokołu SSL GCP używają minimalnej wersji protokołu TLS 1.0 i zgodnego profilu, który umożliwia najszerszy zakres niezabezpieczonych zestawów szyfrowania. W związku z tym klienci mogą łatwo skonfigurować moduł równoważenia obciążenia, nawet nie wiedząc, że zezwalają na przestarzałe zestawy szyfrowania.

Ważność: średni rozmiar

Upewnij się, że rejestrowanie dns w chmurze jest włączone dla wszystkich sieci VPC

Opis: Rejestrowanie usługi DNS w chmurze rejestruje zapytania z serwerów nazw w ramach VPC do usługi Stackdriver. Zarejestrowane zapytania mogą pochodzić z maszyn wirtualnych aparatu obliczeniowego, kontenerów GKE lub innych zasobów GCP aprowizowania w ramach VPC. Monitorowanie zabezpieczeń i śledcze nie mogą zależeć wyłącznie od adresów IP z dzienników przepływu VPC, zwłaszcza w przypadku dynamicznego użycia adresów IP zasobów w chmurze, routingu hosta wirtualnego HTTP i innej technologii, która może zasłonić nazwę DNS używaną przez klienta z adresu IP. Monitorowanie dzienników DNS w chmurze zapewnia widoczność nazw DNS żądanych przez klientów w ramach VPC. Te dzienniki można monitorować pod kątem nietypowych nazw domen, ocenianych pod kątem analizy zagrożeń i

W celu pełnego przechwytywania systemu DNS zapora musi blokować ruch wychodzący UDP/53 (DNS) i TCP/443 (DNS za pośrednictwem protokołu HTTPS), aby uniemożliwić klientowi używanie zewnętrznego serwera nazw DNS do rozpoznawania.

Ważność: Wysoka

Upewnij się, że protokół DNSSEC jest włączony dla usługi DNS w chmurze

Opis: System nazw domen w chmurze (DNS) to szybki, niezawodny i ekonomiczny system nazw domen, który obsługuje miliony domen w Internecie. Rozszerzenia zabezpieczeń systemu nazw domen (DNSSEC) w usłudze DNS w chmurze umożliwiają właścicielom domeny wykonywanie prostych kroków w celu ochrony ich domen przed przejęciem DNS i atakami typu man-in-the-middle i innymi atakami. Rozszerzenia zabezpieczeń systemu nazw domen (DNSSEC) dodaje zabezpieczenia do protokołu DNS, umożliwiając weryfikowanie odpowiedzi DNS. Posiadanie wiarygodnego systemu DNS, który tłumaczy nazwę domeny na www.example.com skojarzony z nim adres IP, jest coraz ważniejszym blokiem konstrukcyjnym współczesnych aplikacji internetowych. Osoby atakujące mogą przejąć ten proces wyszukiwania domen/adresów IP i przekierowywać użytkowników do złośliwej witryny za pośrednictwem porwania DNS i ataków typu man-in-the-middle. Protokół DNSSEC pomaga ograniczyć ryzyko takich ataków przez kryptograficzne podpisywanie rekordów DNS. W rezultacie uniemożliwia atakującym wydawanie fałszywych odpowiedzi DNS, które mogą błędnie prowadzić przeglądarki do nikczemnych witryn internetowych.

Ważność: średni rozmiar

Upewnij się, że dostęp za pomocą protokołu RDP jest ograniczony z Internetu

Opis: Reguły zapory GCP są specyficzne dla sieci VPC. Każda reguła zezwala na ruch lub odmawia go w przypadku spełnienia warunków. Jego warunki umożliwiają użytkownikom określenie typu ruchu, takiego jak porty i protokoły, oraz źródło lub miejsce docelowe ruchu, w tym adresy IP, podsieci i wystąpienia. Reguły zapory są definiowane na poziomie sieci VPC i są specyficzne dla sieci, w której są zdefiniowane. Same reguły nie mogą być współużytkowane przez sieci. Reguły zapory obsługują tylko ruch IPv4. W przypadku określenia źródła reguły ruchu przychodzącego lub miejsca docelowego dla reguły ruchu wychodzącego według adresu można użyć adresu IPv4 lub bloku IPv4 w notacji CIDR. Można uniknąć ogólnego ruchu przychodzącego (0.0.0.0/0) z Internetu do wystąpienia VPC lub maszyny wirtualnej przy użyciu protokołu RDP na porcie 3389. Reguły zapory GCP w sieci VPC. Te reguły dotyczą ruchu wychodzącego (wychodzącego) z wystąpień i ruchu przychodzącego (przychodzącego) do wystąpień w sieci. Przepływy ruchu wychodzącego i przychodzącego są kontrolowane nawet wtedy, gdy ruch pozostaje w sieci (na przykład komunikacja między wystąpieniami). Aby wystąpienie miało wychodzący dostęp do Internetu, sieć musi mieć prawidłową trasę bramy internetowej lub trasę niestandardową, której docelowy adres IP jest określony. Ta trasa po prostu definiuje ścieżkę do Internetu, aby uniknąć najbardziej ogólnego (0.0.0.0.0/0) docelowego zakresu adresów IP określonego z Internetu za pośrednictwem protokołu RDP z domyślnym portem 3389. Dostęp ogólny z Internetu do określonego zakresu adresów IP powinien być ograniczony.

Ważność: Wysoka

Upewnij się, że RSASHA1 nie jest używana dla klucza podpisywania kluczy w usłudze DNSSEC w chmurze

Opis: Numery algorytmów DNSSEC w tym rejestrze mogą być używane w rejestrze CERT RRs. Mechanizmy zabezpieczeń strefy (DNSSEC) i transakcji (SIG(0) i TSIG korzystają z określonych podzestawów tych algorytmów. Algorytm używany do podpisywania kluczy powinien być zalecany i powinien być silny. Numery algorytmów algorytmów DNSSEC (Domain Name System Security Extensions) w tym rejestrze mogą być używane w regułach CERT RRs. Mechanizmy zabezpieczeń strefy (DNSSEC) i transakcji (SIG(0) i TSIG korzystają z określonych podzestawów tych algorytmów. Algorytm używany do podpisywania kluczy powinien być zalecany i powinien być silny. Po włączeniu protokołu DNSSEC dla strefy zarządzanej lub utworzeniu strefy zarządzanej z protokołem DNSSEC użytkownik może wybrać algorytmy podpisywania DNSSEC i typ odmowy istnienia. Zmiana ustawień protokołu DNSSEC jest skuteczna tylko dla strefy zarządzanej, jeśli protokół DNSSEC nie jest jeszcze włączony. Jeśli istnieje potrzeba zmiany ustawień strefy zarządzanej, w której została włączona, wyłącz protokół DNSSEC, a następnie ponownie włącz je przy użyciu różnych ustawień.

Ważność: średni rozmiar

Upewnij się, że RSASHA1 nie jest używany dla klucza podpisywania strefy w usłudze DNSSEC w chmurze

Opis: Numery algorytmów DNSSEC w tym rejestrze mogą być używane w rejestrze CERT RRs. Mechanizmy zabezpieczeń strefy (DNSSEC) i transakcji (SIG(0) i TSIG korzystają z określonych podzestawów tych algorytmów. Algorytm używany do podpisywania kluczy powinien być zalecany i powinien być silny. Numery algorytmów DNSSEC w tym rejestrze mogą być używane w rejestrze CERT RRs. Mechanizmy zabezpieczeń strefy (DNSSEC) i transakcji (SIG(0) i TSIG korzystają z określonych podzestawów tych algorytmów. Algorytm używany do podpisywania kluczy powinien być zalecany i powinien być silny. Po włączeniu protokołu DNSSEC dla strefy zarządzanej lub utworzeniu strefy zarządzanej z protokołem DNSSEC można wybrać algorytmy podpisywania DNSSEC i typ odmowy istnienia. Zmiana ustawień protokołu DNSSEC jest skuteczna tylko dla strefy zarządzanej, jeśli protokół DNSSEC nie jest jeszcze włączony. Jeśli istnieje potrzeba zmiany ustawień strefy zarządzanej, w której została włączona, wyłącz protokół DNSSEC, a następnie ponownie włącz je przy użyciu różnych ustawień.

Ważność: średni rozmiar

Upewnij się, że dostęp za pomocą protokołu SSH jest ograniczony z Internetu

Opis: Reguły zapory GCP są specyficzne dla sieci VPC. Każda reguła zezwala na ruch lub odmawia go w przypadku spełnienia warunków. Jego warunki umożliwiają użytkownikowi określenie typu ruchu, takiego jak porty i protokoły, oraz źródło lub miejsce docelowe ruchu, w tym adresy IP, podsieci i wystąpienia. Reguły zapory są definiowane na poziomie sieci VPC i są specyficzne dla sieci, w której są zdefiniowane. Same reguły nie mogą być współużytkowane przez sieci. Reguły zapory obsługują tylko ruch IPv4. W przypadku określenia źródła reguły ruchu przychodzącego lub miejsca docelowego dla reguły ruchu wychodzącego według adresu można użyć tylko adresu IPv4 lub bloku IPv4 w notacji CIDR. Można uniknąć ogólnego ruchu przychodzącego (0.0.0.0/0) z Internetu do wystąpienia VPC lub maszyny wirtualnej przy użyciu protokołu SSH na porcie 22. Reguły zapory GCP w sieci VPC mają zastosowanie do ruchu wychodzącego (wychodzącego) z wystąpień i ruchu przychodzącego (przychodzącego) do wystąpień w sieci. Przepływy ruchu wychodzącego i przychodzącego są kontrolowane nawet wtedy, gdy ruch pozostaje w sieci (na przykład komunikacja między wystąpieniami). Aby wystąpienie miało wychodzący dostęp do Internetu, sieć musi mieć prawidłową trasę bramy internetowej lub trasę niestandardową, której docelowy adres IP jest określony. Ta trasa po prostu definiuje ścieżkę do Internetu, aby uniknąć najbardziej ogólnego (0.0.0.0.0/0) docelowego zakresu adresów IP określonego z Internetu za pośrednictwem protokołu SSH z domyślnym portem "22". Dostęp ogólny z Internetu do określonego zakresu adresów IP musi być ograniczony.

Ważność: Wysoka

Upewnij się, że sieć domyślna nie istnieje w projekcie

Opis: Aby zapobiec używaniu sieci domyślnej, projekt nie powinien mieć "domyślnej" sieci. Sieć domyślna ma wstępnie skonfigurowaną konfigurację sieci i automatycznie generuje następujące niezabezpieczone reguły zapory:

  • default-allow-internal: zezwala na połączenia przychodzące dla wszystkich protokołów i portów między wystąpieniami w sieci.
  • default-allow-ssh: zezwala na połączenia przychodzące na porcie TCP 22 (SSH) z dowolnego źródła do dowolnego wystąpienia w sieci.
  • default-allow-rdp: zezwala na połączenia przychodzące na porcie TCP 3389 (RDP) z dowolnego źródła do dowolnego wystąpienia w sieci.
  • default-allow-icmp: zezwala na ruch przychodzący ICMP z dowolnego źródła do dowolnego wystąpienia w sieci.

Te automatycznie utworzone reguły zapory nie są rejestrowane i nie można ich skonfigurować w celu włączenia rejestrowania reguł zapory. Ponadto sieć domyślna jest siecią w trybie automatycznym, co oznacza, że jej podsieci używają tego samego wstępnie zdefiniowanego zakresu adresów IP, a w związku z tym nie można używać sieci VPN w chmurze ani komunikacji równorzędnej sieci VPC z siecią domyślną. W oparciu o wymagania dotyczące zabezpieczeń i sieci organizacji organizacja powinna utworzyć nową sieć i usunąć sieć domyślną.

Ważność: średni rozmiar

Upewnij się, że istnieje filtr metryk dziennika i alerty dotyczące zmian sieci VPC

Opis: Zaleca się ustanowienie filtru metryki i alarmu dla zmian sieci wirtualnej chmury prywatnej (VPC). W projekcie można mieć więcej niż jedną sieć VPC. Ponadto istnieje również możliwość utworzenia połączenia równorzędnego między dwoma wirtualnymi kontrolerami sieciowymi umożliwiającymi kierowanie ruchu sieciowego między wirtualnymi sieciami sieciowymi. Monitorowanie zmian w VPC pomoże zapewnić, że przepływ ruchu VPC nie będzie mieć wpływu.

Ważność: Niska

Upewnij się, że dla zmian reguły zapory sieciowej VPC istnieją filtry metryk dzienników i alerty

Opis: Zaleca się ustanowienie filtru metryki i alarmu dla zmiany reguły zapory sieciowej wirtualnej chmury prywatnej (VPC). Monitorowanie zdarzeń tworzenia lub aktualizowania reguły zapory zapewnia wgląd w zmiany dostępu do sieci i może skrócić czas potrzebny na wykrywanie podejrzanych działań.

Ważność: Niska

Upewnij się, że istnieje filtr metryk dzienników i alerty dotyczące zmian trasy sieciowej VPC

Opis: Zaleca się ustanowienie filtru metryki i alarmu dla zmian trasy sieciowej wirtualnej chmury prywatnej (VPC). Trasy platformy Google Cloud Platform (GCP) definiują ścieżki ruchu sieciowego pochodzącego z wystąpienia maszyny wirtualnej do innego miejsca docelowego. Inne miejsce docelowe może znajdować się wewnątrz sieci VPC organizacji (np. innej maszyny wirtualnej) lub poza nią. Każda trasa składa się z miejsca docelowego i następnego przeskoku. Ruch, którego docelowy adres IP znajduje się w zakresie docelowym, jest wysyłany do następnego przeskoku na potrzeby dostarczania. Monitorowanie zmian w tabelach tras pomoże zapewnić, że cały ruch VPC przepływa przez oczekiwaną ścieżkę.

Ważność: Niska

Upewnij się, że flaga bazy danych "log_connections" dla wystąpienia usługi Cloud SQL PostgreSQL jest ustawiona na wartość "on"

Opis: Włączenie ustawienia log_connections powoduje, że każde próby nawiązania połączenia z serwerem ma być rejestrowane wraz z pomyślnym ukończeniem uwierzytelniania klienta. Nie można zmienić tego parametru po rozpoczęciu sesji. Program PostgreSQL domyślnie nie rejestruje prób nawiązania połączeń. Włączenie ustawienia log_connections spowoduje utworzenie wpisów dziennika dla każdego próby nawiązania połączenia, a także pomyślnego ukończenia uwierzytelniania klienta, co może być przydatne podczas rozwiązywania problemów i określenia wszelkich nietypowych prób połączenia z serwerem. To zalecenie dotyczy wystąpień bazy danych PostgreSQL.

Ważność: średni rozmiar

Upewnij się, że flaga bazy danych "log_disconnections" dla wystąpienia usługi Cloud SQL PostgreSQL jest ustawiona na wartość "włączone"

Opis: Włączenie ustawienia log_disconnections rejestruje koniec każdej sesji, w tym czas trwania sesji. Usługa PostgreSQL domyślnie nie rejestruje szczegółów sesji, takich jak czas trwania i zakończenie sesji. Włączenie ustawienia log_disconnections spowoduje utworzenie wpisów dziennika na końcu każdej sesji, co może być przydatne w rozwiązywaniu problemów i określenie wszelkich nietypowych działań w danym okresie. Log_disconnections i log_connections pracować ręcznie i ogólnie, para byłaby włączona/wyłączona razem. To zalecenie dotyczy wystąpień bazy danych PostgreSQL.

Ważność: średni rozmiar

Upewnij się, że dzienniki przepływu VPC są włączone dla każdej podsieci w sieci VPC

Opis: Dzienniki przepływu to funkcja, która umożliwia użytkownikom przechwytywanie informacji o ruchu IP przechodzącym do i z interfejsów sieciowych w podsieciach VPC organizacji. Po utworzeniu dziennika przepływu użytkownik może wyświetlać i pobierać swoje dane w usłudze Stackdriver Logging. Zaleca się włączenie dzienników przepływu dla każdej podsieci VPC o krytycznym znaczeniu dla działania firmy. Sieci VPC i podsieci zapewniają logicznie izolowane i bezpieczne partycje sieciowe, w których można uruchamiać zasoby GCP. Gdy dzienniki przepływu są włączone dla podsieci, maszyny wirtualne w tej podsieci rozpoczynają raportowanie na wszystkich przepływach protokołu TCP (Transmission Control Protocol) i protokołu UDP (User Datagram Protocol). Każda maszyna wirtualna próbkuje przepływy TCP i UDP, które widzą, przychodzące i wychodzące, niezależnie od tego, czy przepływ jest do lub z innej maszyny wirtualnej, hosta w lokalnym centrum danych, usłudze Google, czy hoście w Internecie. Jeśli komunikują się dwie maszyny wirtualne GCP i obie znajdują się w podsieciach z włączonymi dziennikami przepływu VPC, obie maszyny wirtualne zgłaszają przepływy. Dzienniki przepływu obsługują następujące przypadki użycia: 1. Monitorowanie sieci. 2. Omówienie użycia sieci i optymalizowanie wydatków na ruch sieciowy. 3. Śledcze sieci. 4. Dzienniki przepływu analizy zabezpieczeń w czasie rzeczywistym zapewniają wgląd w ruch sieciowy dla każdej maszyny wirtualnej wewnątrz podsieci i mogą służyć do wykrywania nietypowego ruchu lub szczegółowych informacji podczas przepływów pracy zabezpieczeń.

Ważność: Niska

Rejestrowanie reguł zapory powinno być włączone

Opis: To zalecenie ocenia właściwość logConfig w metadanych zapory, aby sprawdzić, czy jest ona pusta, czy zawiera parę klucz-wartość "enable": false.

Ważność: średni rozmiar

Zapora nie powinna być skonfigurowana tak, aby był otwarty na dostęp publiczny

Opis: To zalecenie ocenia właściwości sourceRanges i dozwolone dla jednej z dwóch konfiguracji:

Właściwość sourceRanges zawiera wartość 0.0.0.0/0, a dozwolona właściwość zawiera kombinację reguł obejmujących dowolny protokół lub protokół:port, z wyjątkiem następujących:

  • Icmp
  • tcp: 22
  • tcp: 443
  • tcp: 3389
  • udp: 3389
  • sctp: 22

Właściwość sourceRanges zawiera kombinację zakresów adresów IP, która zawiera dowolny nieprivate adres IP, a dozwolona właściwość zawiera kombinację reguł, które zezwalają na wszystkie porty tcp lub wszystkie porty udp.

Ważność: Wysoka

Zapora nie powinna być skonfigurowana tak, aby miała otwarty port CASSANDRA, który zezwala na dostęp ogólny

Opis: To zalecenie ocenia dozwoloną właściwość w metadanych zapory dla następujących protokołów i portów: TCP: 7000-7001, 7199, 8888, 9042, 9160, 61620-61621.

Ważność: Niska

Zapora nie powinna być skonfigurowana tak, aby miała otwarty port CISCOSECURE_WEBSM, który zezwala na dostęp ogólny

Opis: To zalecenie ocenia dozwoloną właściwość w metadanych zapory dla następującego protokołu i portu: TCP: 9090.

Ważność: Niska

Zapora nie powinna być skonfigurowana tak, aby miała otwarty port DIRECTORY_SERVICES, który zezwala na dostęp ogólny

Opis: To zalecenie ocenia dozwoloną właściwość w metadanych zapory dla następujących protokołów i portów: TCP: 445 i UDP: 445.

Ważność: Niska

Zapora nie powinna być skonfigurowana tak, aby miała otwarty port DNS, który zezwala na dostęp ogólny

Opis: To zalecenie ocenia dozwoloną właściwość w metadanych zapory dla następujących protokołów i portów: TCP: 53 i UDP: 53.

Ważność: Niska

Zapora nie powinna być skonfigurowana tak, aby miała otwarty port ELASTICSEARCH, który zezwala na dostęp ogólny

Opis: To zalecenie ocenia dozwoloną właściwość w metadanych zapory dla następujących protokołów i portów: TCP: 9200, 9300.

Ważność: Niska

Zapora nie powinna być skonfigurowana tak, aby miała otwarty port FTP, który zezwala na dostęp ogólny

Opis: To zalecenie ocenia dozwoloną właściwość w metadanych zapory dla następującego protokołu i portu: TCP: 21.

Ważność: Niska

Zapora nie powinna być skonfigurowana tak, aby miała otwarty port HTTP, który zezwala na dostęp ogólny

Opis: To zalecenie ocenia dozwoloną właściwość w metadanych zapory dla następujących protokołów i portów: TCP: 80.

Ważność: Niska

Zapora nie powinna być skonfigurowana tak, aby miała otwarty port LDAP, który zezwala na dostęp ogólny

Opis: To zalecenie ocenia dozwoloną właściwość w metadanych zapory dla następujących protokołów i portów: TCP: 389, 636 i UDP: 389.

Ważność: Niska

Zapora nie powinna być skonfigurowana tak, aby miała otwarty port MEMCACHED, który zezwala na dostęp ogólny

Opis: To zalecenie ocenia dozwoloną właściwość w metadanych zapory dla następujących protokołów i portów: TCP: 11211, 11214-11215 i UDP: 11211, 11214-11215.

Ważność: Niska

Zapora nie powinna być skonfigurowana tak, aby miała otwarty port bazy danych MONGODB, który zezwala na dostęp ogólny

Opis: To zalecenie ocenia dozwoloną właściwość w metadanych zapory dla następujących protokołów i portów: TCP: 27017-27019.

Ważność: Niska

Zapora nie powinna być skonfigurowana tak, aby miała otwarty port MYSQL, który zezwala na dostęp ogólny

Opis: To zalecenie ocenia dozwoloną właściwość w metadanych zapory dla następującego protokołu i portu: TCP: 3306.

Ważność: Niska

Zapora nie powinna być skonfigurowana tak, aby miała otwarty port NETBIOS, który zezwala na dostęp ogólny

Opis: To zalecenie ocenia dozwoloną właściwość w metadanych zapory dla następujących protokołów i portów: TCP: 137-139 i UDP: 137-139.

Ważność: Niska

Zapora nie powinna być skonfigurowana tak, aby miała otwarty port ORACLEDB, który zezwala na dostęp ogólny

Opis: To zalecenie ocenia dozwoloną właściwość w metadanych zapory dla następujących protokołów i portów: TCP: 1521, 2483-2484 i UDP: 2483-2484.

Ważność: Niska

Zapora nie powinna być skonfigurowana tak, aby miała otwarty port POP3, który zezwala na dostęp ogólny

Opis: To zalecenie ocenia dozwoloną właściwość w metadanych zapory dla następującego protokołu i portu: TCP: 110.

Ważność: Niska

Zapora nie powinna być skonfigurowana tak, aby miała otwarty port PostgreSQL, który zezwala na dostęp ogólny

Opis: To zalecenie ocenia dozwoloną właściwość w metadanych zapory dla następujących protokołów i portów: TCP: 5432 i UDP: 5432.

Ważność: Niska

Zapora nie powinna być skonfigurowana tak, aby miała otwarty port REDIS, który zezwala na dostęp ogólny

Opis: To zalecenie ocenia, czy dozwolona właściwość w metadanych zapory zawiera następujący protokół i port: TCP: 6379.

Ważność: Niska

Zapora nie powinna być skonfigurowana tak, aby miała otwarty port SMTP, który zezwala na dostęp ogólny

Opis: To zalecenie ocenia, czy dozwolona właściwość w metadanych zapory zawiera następujący protokół i port: TCP: 25.

Ważność: Niska

Zapora nie powinna być skonfigurowana tak, aby miała otwarty port SSH, który zezwala na dostęp ogólny

Opis: To zalecenie ocenia, czy dozwolona właściwość w metadanych zapory zawiera następujące protokoły i porty: TCP: 22 i SCTP: 22.

Ważność: Niska

Zapora nie powinna być skonfigurowana tak, aby miała otwarty port TELNET, który zezwala na dostęp ogólny

Opis: To zalecenie ocenia, czy dozwolona właściwość w metadanych zapory zawiera następujący protokół i port: TCP: 23.

Ważność: Niska

Klastry GKE powinny mieć włączone zakresy adresów IP aliasów

Opis: To zalecenie ocenia, czy dla pola useIPAliases obiektu ipAllocationPolicy w klastrze ustawiono wartość false.

Ważność: Niska

Klastry GKE powinny mieć włączone klastry prywatne

Opis: To zalecenie ocenia, czy dla pola enablePrivateNodes właściwości privateClusterConfig ustawiono wartość false.

Ważność: Wysoka

Zasady sieciowe powinny być włączone w klastrach GKE

Opis: To zalecenie ocenia pole networkPolicy właściwości addonsConfig dla pary klucz-wartość", "disabled": true.

Ważność: średni rozmiar