Zalecenia dotyczące zabezpieczeń zasobów platformy Google Cloud Platform (GCP)

W tym artykule wymieniono wszystkie zalecenia, które można zobaczyć w Microsoft Defender dla Chmury, jeśli połączysz konto platformy Google Cloud Platform (GCP) przy użyciu strony Ustawienia środowiska. 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.

Wskaźnik bezpieczeństwa jest oparty na liczbie ukończonych zaleceń dotyczących zabezpieczeń. Aby zdecydować, które zalecenia należy rozwiązać jako pierwsze, przyjrzyj się ważności poszczególnych rekomendacji i jej potencjalnemu wpływowi na wskaźnik bezpieczeństwa.

Zalecenia dotyczące obliczeń GCP

Maszyny wirtualne aparatu obliczeniowego powinny używać systemu operacyjnego zoptymalizowanego pod kątem kontenera

Opis: To zalecenie ocenia właściwość konfiguracji puli węzłów dla pary klucz-wartość", "imageType": "COS".

Ważność: Niska

Problemy z konfiguracją EDR należy rozwiązać na maszynach wirtualnych GCP

Opis: Aby chronić maszyny wirtualne przed najnowszymi zagrożeniami i lukami w zabezpieczeniach, rozwiąż wszystkie zidentyfikowane problemy z konfiguracją zainstalowanego rozwiązania wykrywania i reagowania na punkty końcowe (EDR).
Uwaga: obecnie to zalecenie dotyczy tylko zasobów z włączonym Ochrona punktu końcowego w usłudze Microsoft Defender (MDE).

Ważność: Wysoka

Rozwiązanie EDR powinno być zainstalowane na maszynach wirtualnych GCP

Opis: Aby chronić maszyny wirtualne, zainstaluj rozwiązanie do wykrywania i reagowania na punkty końcowe (EDR). EDR pomagają zapobiegać, wykrywać, badać i reagować na zaawansowane zagrożenia. Wdrażanie Ochrona punktu końcowego w usłudze Microsoft Defender za pomocą usługi Microsoft Defender dla serwerów. Jeśli zasób jest klasyfikowany jako "W złej kondycji", nie ma zainstalowanego obsługiwanego rozwiązania EDR [Link posiadacza miejsca — Dowiedz się więcej]. Jeśli masz zainstalowane rozwiązanie EDR, które nie jest wykrywalne przez to zalecenie, możesz je wykluczyć.

Ważność: Wysoka

Upewnij się, że opcja "Blokuj klucze SSH dla całego projektu" jest włączona dla wystąpień maszyn wirtualnych

Opis: Zaleca się używanie kluczy SSH specyficznych dla wystąpienia zamiast używania wspólnych/udostępnionych kluczy SSH dla całego projektu w celu uzyskania dostępu do wystąpień. Klucze SSH dla całego projektu są przechowywane w obszarze Compute/Project-meta-data. Klucze SSH szerokiego projektu mogą służyć do logowania się do wszystkich wystąpień w projekcie. Użycie kluczy SSH dla całego projektu ułatwia zarządzanie kluczami SSH, ale w przypadku naruszenia zabezpieczeń stanowi zagrożenie bezpieczeństwa, które może mieć wpływ na wszystkie wystąpienia w projekcie. Zaleca się użycie kluczy SSH specyficznych dla wystąpienia, które mogą ograniczyć obszar ataków w przypadku naruszenia zabezpieczeń kluczy SSH.

Ważność: średni rozmiar

Upewnij się, że wystąpienia obliczeniowe są uruchamiane z włączoną osłoną maszyny wirtualnej

Opis: Aby bronić przed zaawansowanymi zagrożeniami i upewnić się, że moduł ładujący rozruchu i oprogramowanie układowe na maszynach wirtualnych są podpisane i nieoznaczone, zaleca się uruchomienie wystąpień obliczeniowych z włączoną osłoną maszyn wirtualnych. Chronione maszyny wirtualne to maszyny wirtualne (maszyny wirtualne) na platformie Google Cloud Platform wzmocnione przez zestaw mechanizmów kontroli zabezpieczeń, które pomagają chronić przed zestawami rootkit i zestawami bootkit. Chroniona maszyna wirtualna oferuje weryfikowalną integralność wystąpień maszyn wirtualnych aparatu obliczeniowego, dzięki czemu możesz mieć pewność, że wystąpienia nie zostały naruszone przez złośliwe oprogramowanie lub zestawy root na poziomie jądra. Integralność weryfikowalnej maszyny wirtualnej z osłoną jest osiągana za pomocą bezpiecznego rozruchu, wirtualnego modułu zaufanej platformy (vTPM) z włączoną obsługą mierzonego rozruchu i monitorowania integralności. Wystąpienia maszyn wirtualnych z osłoną uruchamiają oprogramowanie układowe podpisane i zweryfikowane przy użyciu urzędu certyfikacji firmy Google, zapewniając, że oprogramowanie układowe wystąpienia jest niezmodyfikowane i ustanawia katalog główny zaufania bezpiecznego rozruchu. Monitorowanie integralności pomaga zrozumieć i podejmować decyzje dotyczące stanu wystąpień maszyn wirtualnych, a maszyna wirtualna z osłoną umożliwia mierzony rozruch, wykonując pomiary wymagane do utworzenia znanego dobrego punktu odniesienia rozruchu, nazywanego punktem odniesienia zasad integralności. Punkt odniesienia zasad integralności jest używany do porównania z pomiarami z kolejnych rozruchów maszyn wirtualnych w celu określenia, czy coś się zmieniło. Bezpieczny rozruch pomaga zagwarantować, że system uruchamia tylko autentyczne oprogramowanie, weryfikując podpis cyfrowy wszystkich składników rozruchu i zatrzymując proces rozruchu, jeśli weryfikacja podpisu zakończy się niepowodzeniem.

Ważność: Wysoka

Upewnij się, że opcja "Włącz nawiązywanie połączenia z portami seryjnymi" nie jest włączona dla wystąpienia maszyny wirtualnej

Opis: Interakcja z portem szeregowym jest często określana jako konsola szeregowa, która jest podobna do okna terminalu, w tym wejściu i danych wyjściowych jest całkowicie w trybie tekstowym i nie ma interfejsu graficznego ani obsługi myszy. Jeśli włączysz interaktywną konsolę szeregową w wystąpieniu, klienci będą mogli próbować nawiązać połączenie z tym wystąpieniem z dowolnego adresu IP. W związku z tym należy wyłączyć obsługę interakcyjnej konsoli szeregowej. Wystąpienie maszyny wirtualnej ma cztery wirtualne porty szeregowe. Interakcja z portem szeregowym jest podobna do korzystania z okna terminalu, w tym wejściu i danych wyjściowych jest całkowicie w trybie tekstowym i nie ma interfejsu graficznego ani obsługi myszy. System operacyjny wystąpienia, SYSTEM BIOS i inne jednostki na poziomie systemu często zapisują dane wyjściowe na portach szeregowych i mogą akceptować dane wejściowe, takie jak polecenia lub odpowiedzi na monity. Zazwyczaj te jednostki na poziomie systemu używają pierwszego portu szeregowego (portu 1), a port szeregowy 1 jest często określany jako konsola szeregowa. Interaktywna konsola szeregowa nie obsługuje ograniczeń dostępu opartych na adresach IP, takich jak listy dozwolonych adresów IP. Jeśli włączysz interaktywną konsolę szeregową w wystąpieniu, klienci będą mogli próbować nawiązać połączenie z tym wystąpieniem z dowolnego adresu IP. Dzięki temu każda osoba może nawiązać połączenie z tym wystąpieniem, jeśli zna prawidłowy klucz SSH, nazwę użytkownika, identyfikator projektu, strefę i nazwę wystąpienia. W związku z tym należy wyłączyć obsługę interakcyjnej konsoli szeregowej.

Ważność: średni rozmiar

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

Opis: włączenie ustawienia log_hostname powoduje zarejestrowanie czasu trwania każdej ukończonej instrukcji. Nie rejestruje to tekstu zapytania i zachowuje się inaczej niż flaga log_min_duration_statement. Nie można zmienić tego parametru po rozpoczęciu sesji. Monitorowanie czasu potrzebnego do wykonania zapytań może mieć kluczowe znaczenie podczas identyfikowania zapytań hogging zasobów i oceny wydajności serwera. Aby zapewnić wydajność i stabilność serwera, można wykonać dalsze kroki, takie jak równoważenie obciążenia i użycie zoptymalizowanych zapytań. To zalecenie dotyczy wystąpień bazy danych PostgreSQL.

Ważność: Niska

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

Opis: Funkcja wykonawcza postgreSQL jest odpowiedzialna za wykonanie planu przekazanego przez planistę PostgreSQL. Funkcja wykonawcza przetwarza plan cyklicznie w celu wyodrębnienia wymaganego zestawu wierszy. Flaga "log_executor_stats" steruje dołączeniem statystyk wydajności funkcji wykonawczej PostgreSQL w dziennikach postgreSQL dla każdego zapytania. Flaga "log_executor_stats" umożliwia metodę profilowania ropy na potrzeby rejestrowania statystyk wydajności funkcji wykonawczej PostgreSQL, która mimo że może być przydatna do rozwiązywania problemów, może znacznie zwiększyć ilość dzienników i mieć obciążenie wydajności. To zalecenie dotyczy wystąpień bazy danych PostgreSQL.

Ważność: Niska

Upewnij się, że flaga bazy danych "log_min_error_statement" dla wystąpienia usługi Cloud SQL PostgreSQL jest ustawiona na wartość "Błąd" lub jest bardziej rygorystyczna

Opis: flaga "log_min_error_statement" definiuje minimalny poziom ważności komunikatu, który jest traktowany jako instrukcja błędu. Komunikaty dotyczące instrukcji błędów są rejestrowane za pomocą instrukcji SQL. Prawidłowe wartości obejmują "DEBUG5", "DEBUG4", "DEBUG3", "DEBUG2", "DEBUG1", "INFO", "NOTICE", "WARNING", "ERROR", "LOG", "FATAL" i "PANIC". Każdy poziom ważności obejmuje kolejne poziomy wymienione powyżej. Upewnij się, że ustawiono wartość ERROR lub stricter. Inspekcja pomaga w rozwiązywaniu problemów operacyjnych, a także umożliwia analizę kryminalistyczną. Jeśli wartość "log_min_error_statement" nie jest ustawiona na poprawną, komunikaty mogą nie być odpowiednio klasyfikowane jako komunikaty o błędach. Biorąc pod uwagę ogólne komunikaty dziennika, ponieważ komunikaty o błędach byłyby trudne do znalezienia rzeczywistych błędów i biorąc pod uwagę tylko ostrzejsze poziomy ważności, ponieważ komunikaty o błędach mogą pominąć rzeczywiste błędy, aby rejestrować instrukcje SQL. Flaga "log_min_error_statement" powinna być ustawiona na wartość "BŁĄD" lub bardziej rygorystyczna. To zalecenie dotyczy wystąpień bazy danych PostgreSQL.

Ważność: Niska

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

Opis: Planista/optymalizator PostgreSQL jest odpowiedzialny za analizowanie i weryfikowanie składni każdego zapytania odebranego przez serwer. Jeśli składnia jest poprawna, zostanie skompilowane "drzewo analizy", w przeciwnym razie zostanie wygenerowany błąd. Flaga "log_parser_stats" steruje dołączeniem statystyk wydajności analizatora w dziennikach postgreSQL dla każdego zapytania. Flaga "log_parser_stats" umożliwia metodę profilowania ropy dla statystyk wydajności analizatora rejestrowania, która mimo że może być przydatna do rozwiązywania problemów, może znacznie zwiększyć ilość dzienników i mieć obciążenie wydajności. To zalecenie dotyczy wystąpień bazy danych PostgreSQL.

Ważność: Niska

Upewnij się, że flaga bazy danych "log_planner_stats" dla wystąpienia usługi Cloud SQL PostgreSQL jest ustawiona na "wyłączone"

Opis: To samo zapytanie SQL można wykonać na wiele sposobów i nadal generować różne wyniki. Planista/optymalizator postgreSQL jest odpowiedzialny za utworzenie optymalnego planu wykonania dla każdego zapytania. Flaga "log_planner_stats" kontroluje włączenie statystyk wydajności planisty PostgreSQL w dziennikach postgreSQL dla każdego zapytania. Flaga "log_planner_stats" umożliwia metodę profilowania ropy na potrzeby rejestrowania statystyk wydajności planisty PostgreSQL, która mimo że może być przydatna do rozwiązywania problemów, może znacznie zwiększyć ilość dzienników i mieć obciążenie wydajności. To zalecenie dotyczy wystąpień bazy danych PostgreSQL.

Ważność: Niska

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

Opis: flaga "log_statement_stats" steruje dołączeniem statystyk wydajności end to end performance zapytania SQL w dziennikach postgreSQL dla każdego zapytania. Nie można włączyć tej funkcji z innymi statystykami modułów (log_parser_stats, log_planner_stats, log_executor_stats). Flaga "log_statement_stats" umożliwia metodę profilowania ropy naftowej na potrzeby rejestrowania statystyk końcowych wydajności zapytania SQL. Może to być przydatne w przypadku rozwiązywania problemów, ale może znacznie zwiększyć ilość dzienników i mieć obciążenie wydajności. To zalecenie dotyczy wystąpień bazy danych PostgreSQL.

Ważność: Niska

Upewnij się, że wystąpienia obliczeniowe nie mają publicznych adresów IP

Opis: Wystąpienia obliczeniowe nie powinny być skonfigurowane tak, aby miały zewnętrzne adresy IP. Aby zmniejszyć obszar ataków, wystąpienia obliczeniowe nie powinny mieć publicznych adresów IP. Zamiast tego wystąpienia należy skonfigurować za modułami równoważenia obciążenia, aby zminimalizować narażenie wystąpienia na Internet. Wystąpienia utworzone przez GKE należy wykluczyć, ponieważ niektóre z nich mają zewnętrzne adresy IP i nie można ich zmienić, edytując ustawienia wystąpienia. Te maszyny wirtualne mają nazwy rozpoczynające się od gke- i mają etykietę goog-gke-node.

Ważność: Wysoka

Upewnij się, że wystąpienia nie są skonfigurowane do używania domyślnego konta usługi

Opis: Zaleca się skonfigurowanie wystąpienia tak, aby nie używało domyślnego konta usługi Compute Engine, ponieważ ma rolę Edytor w projekcie. Domyślne konto usługi Compute Engine ma rolę Edytor w projekcie, co umożliwia dostęp do odczytu i zapisu w większości usług Google Cloud Services. Aby bronić przed eskalacjami uprawnień w przypadku naruszenia zabezpieczeń maszyny wirtualnej i uniemożliwić atakującemu uzyskanie dostępu do całego projektu, zaleca się, aby nie używać domyślnego konta usługi Compute Engine. Zamiast tego należy utworzyć nowe konto usługi i przypisać tylko uprawnienia wymagane przez wystąpienie. Domyślne konto usługi Compute Engine nosi nazwę [PROJECT_NUMBER]- compute@developer.gserviceaccount.com. Należy wykluczyć maszyny wirtualne utworzone przez GKE. Te maszyny wirtualne mają nazwy rozpoczynające się od gke- i mają etykietę goog-gke-node.

Ważność: Wysoka

Upewnij się, że wystąpienia nie są skonfigurowane do używania domyślnego konta usługi z pełnym dostępem do wszystkich interfejsów API chmury

Opis: Aby zapewnić obsługę zasady najniższych uprawnień i zapobiec potencjalnemu podwyższeniu poziomu uprawnień, zaleca się, aby wystąpienia nie zostały przypisane do domyślnego konta usługi "Domyślne konto usługi aparatu obliczeniowego" z zakresem "Zezwalaj na pełny dostęp do wszystkich interfejsów API chmury". Oprócz możliwości opcjonalnego tworzenia, zarządzania i używania niestandardowych kont usług zarządzanych przez użytkownika aparat obliczeniowy Google udostępnia domyślne konto usługi "Domyślne konto usługi aparatu obliczeniowego" dla wystąpienia w celu uzyskania dostępu do niezbędnych usług w chmurze. Rola "Edytor projektu" jest przypisywana do domyślnego konta usługi aparatu obliczeniowego, dlatego to konto usługi ma prawie wszystkie możliwości dla wszystkich usług w chmurze z wyjątkiem rozliczeń. Jednak po przypisaniu domyślnego konta usługi aparatu obliczeniowego do wystąpienia może on działać w trzech zakresach.

1. Zezwalaj na dostęp domyślny: zezwala tylko na minimalny dostęp wymagany do uruchomienia wystąpienia (najmniej uprawnień).
2. Zezwalaj na pełny dostęp do wszystkich interfejsów API chmury: zezwalaj na pełny dostęp do wszystkich interfejsów API/usług w chmurze (za dużo dostępu).
3. Ustaw dostęp dla każdego interfejsu API: umożliwia administratorowi wystąpienia wybranie tylko tych interfejsów API, które są wymagane do wykonania określonych funkcji biznesowych oczekiwanych przez wystąpienie Gdy wystąpienie jest skonfigurowane przy użyciu "Domyślne konto usługi aparatu obliczeniowego" z zakresem "Zezwalaj na pełny dostęp do wszystkich interfejsów API w chmurze", na podstawie ról IAM przypisanych do użytkowników, którzy uzyskują dostęp do wystąpienia, może umożliwić użytkownikowi wykonywanie operacji w chmurze/wywołań interfejsu API, których użytkownik nie powinien wykonywać, co prowadzi do pomyślnej eskalacji uprawnień. Należy wykluczyć maszyny wirtualne utworzone przez GKE. Te maszyny wirtualne mają nazwy rozpoczynające się od "gke-" i mają etykietę "goog-gke-node".

Ważność: średni rozmiar

Upewnij się, że przekazywanie adresów IP nie jest włączone w wystąpieniach

Opis: Wystąpienie aparatu obliczeniowego nie może przekazać pakietu, chyba że źródłowy adres IP pakietu jest zgodny z adresem IP wystąpienia. Podobnie GCP nie dostarczy pakietu, którego docelowy adres IP różni się od adresu IP wystąpienia odbierającego pakiet. Jednak obie możliwości są wymagane, jeśli chcesz używać wystąpień, aby ułatwić kierowanie pakietów. Przekazywanie pakietów danych powinno być wyłączone, aby zapobiec utracie danych lub ujawnieniu informacji. Wystąpienie aparatu obliczeniowego nie może przekazać pakietu, chyba że źródłowy adres IP pakietu jest zgodny z adresem IP wystąpienia. Podobnie GCP nie dostarczy pakietu, którego docelowy adres IP różni się od adresu IP wystąpienia odbierającego pakiet. Jednak obie możliwości są wymagane, jeśli chcesz używać wystąpień, aby ułatwić kierowanie pakietów. Aby włączyć tę źródłową i docelową kontrolę adresu IP, wyłącz pole canIpForward, które umożliwia wystąpieniu wysyłanie i odbieranie pakietów z niezgodnymi docelowymi lub źródłowymi adresami IP.

Ważność: średni rozmiar

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

Opis: upewnij się, że flaga bazy danych log_checkpoints dla wystąpienia usługi Cloud SQL PostgreSQL jest włączona. Włączenie log_checkpoints powoduje zalogowanie punktów kontrolnych i punktów ponownego uruchomienia w dzienniku serwera. Niektóre statystyki są uwzględniane w komunikatach dziennika, w tym liczbę zapisanych buforów i czas spędzony na ich zapisaniu. Ten parametr można ustawić tylko w pliku postgresql.conf lub w wierszu polecenia serwera. To zalecenie dotyczy wystąpień bazy danych PostgreSQL.

Ważność: Niska

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

Opis: Włączenie flagi "log_lock_waits" dla wystąpienia bazy danych PostgreSQL powoduje utworzenie dziennika dla wszystkich oczekujących sesji, które trwa dłużej niż przydzielony czas "deadlock_timeout" na uzyskanie blokady. Limit czasu zakleszczenia definiuje czas oczekiwania na blokadę przed sprawdzeniem wszelkich warunków. Częste przekroczenia limitu czasu zakleszczenia mogą wskazywać na podstawowy problem. Rejestrowanie takich oczekiwań na blokadach przez włączenie flagi log_lock_waits może służyć do identyfikowania niskiej wydajności z powodu opóźnień blokowania lub jeśli specjalnie spreparowany program SQL próbuje głodować zasoby przez przechowywanie blokad przez nadmierne ilości czasu. To zalecenie dotyczy wystąpień bazy danych PostgreSQL.

Ważność: Niska

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

Opis: flaga "log_min_duration_statement" definiuje minimalny czas wykonywania instrukcji w milisekundach, w których jest rejestrowany całkowity czas trwania instrukcji. Upewnij się, że wartość "log_min_duration_statement" jest wyłączona, czyli ustawiono wartość -1. Rejestrowanie instrukcji SQL może zawierać poufne informacje, które nie powinny być rejestrowane w dziennikach. To zalecenie dotyczy wystąpień bazy danych PostgreSQL.

Ważność: Niska

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

Opis: flaga "log_min_error_statement" definiuje minimalny poziom ważności komunikatu, który jest uznawany za instrukcję błędu. Komunikaty dotyczące instrukcji błędów są rejestrowane za pomocą instrukcji SQL. Prawidłowe wartości obejmują "DEBUG5", "DEBUG4", "DEBUG3", "DEBUG2", "DEBUG1", "INFO", "NOTICE", "WARNING", "ERROR", "LOG", "FATAL" i "PANIC". Każdy poziom ważności obejmuje kolejne poziomy wymienione powyżej. Uwaga: Aby skutecznie wyłączyć rejestrowanie instrukcji zakończonych niepowodzeniem, ustaw ten parametr na WARTOŚĆ PANIC. Błąd jest uważany za ustawienie najlepszych rozwiązań. Zmiany powinny być wprowadzane tylko zgodnie z zasadami rejestrowania organizacji. Inspekcja pomaga w rozwiązywaniu problemów operacyjnych, a także umożliwia analizę kryminalistyczną. Jeśli wartość "log_min_error_statement" nie jest ustawiona na poprawną, komunikaty mogą nie być odpowiednio klasyfikowane jako komunikaty o błędach. Biorąc pod uwagę ogólne komunikaty dziennika jako komunikaty o błędach, trudno byłoby znaleźć rzeczywiste błędy, biorąc pod uwagę tylko ostrzejsze poziomy ważności, ponieważ komunikaty o błędach mogą pomijać rzeczywiste błędy, aby rejestrować instrukcje SQL. Flaga "log_min_error_statement" powinna być ustawiona zgodnie z zasadami rejestrowania organizacji. To zalecenie dotyczy wystąpień bazy danych PostgreSQL.

Ważność: Niska

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

Opis: Program PostgreSQL może utworzyć plik tymczasowy dla akcji, takich jak sortowanie, tworzenie skrótów i tymczasowe wyniki zapytania, gdy te operacje przekraczają wartość "work_mem". Flaga "log_temp_files" steruje nazwami rejestrowania i rozmiarem pliku po jego usunięciu. Skonfigurowanie wartości "log_temp_files" na wartość 0 powoduje zarejestrowanie wszystkich tymczasowych informacji o pliku, podczas gdy wartości dodatnie rejestrują tylko pliki, których rozmiar jest większy lub równy określonej liczbie kilobajtów. Wartość "-1" wyłącza tymczasowe rejestrowanie informacji o plikach. Jeśli wszystkie pliki tymczasowe nie są rejestrowane, może być trudniej zidentyfikować potencjalne problemy z wydajnością, które mogą być spowodowane złym kodowaniem aplikacji lub celowymi próbami głodu zasobów.

Ważność: Niska

Upewnij się, że dyski maszyn wirtualnych o krytycznym znaczeniu są szyfrowane przy użyciu klucza szyfrowania dostarczonego przez klienta

Opis: Klucze szyfrowania dostarczone przez klienta (CSEK) to funkcja usługi Google Cloud Storage i Google Compute Engine. Jeśli podasz własne klucze szyfrowania, firma Google używa klucza do ochrony kluczy wygenerowanych przez firmę Google używanych do szyfrowania i odszyfrowywania danych. Domyślnie aparat obliczeniowy Google szyfruje wszystkie dane magazynowane. Aparat obliczeniowy obsługuje to szyfrowanie i zarządza nim bez żadnych dodatkowych akcji. Jeśli jednak chcesz samodzielnie kontrolować to szyfrowanie i zarządzać nim, możesz podać własne klucze szyfrowania. Domyślnie aparat obliczeniowy Google szyfruje wszystkie dane magazynowane. Aparat obliczeniowy obsługuje to szyfrowanie i zarządza nim bez żadnych dodatkowych akcji. Jeśli jednak chcesz samodzielnie kontrolować to szyfrowanie i zarządzać nim, możesz podać własne klucze szyfrowania. Jeśli podasz własne klucze szyfrowania, aparat obliczeniowy używa klucza do ochrony kluczy wygenerowanych przez firmę Google używanych do szyfrowania i odszyfrowywania danych. Tylko użytkownicy, którzy mogą podać prawidłowy klucz, mogą używać zasobów chronionych przez klucz szyfrowania dostarczony przez klienta. Firma Google nie przechowuje kluczy na swoich serwerach i nie może uzyskać dostępu do chronionych danych, chyba że podasz klucz. Oznacza to również, że jeśli zapomnisz lub utracisz klucz, nie ma możliwości odzyskania klucza przez firmę Google ani odzyskania jakichkolwiek danych zaszyfrowanych przy użyciu utraconego klucza. Co najmniej krytyczne dla działania firmy maszyny wirtualne powinny mieć dyski maszyn wirtualnych zaszyfrowane przy użyciu klucza CSEK.

Ważność: średni rozmiar

Projekty GCP powinny mieć włączoną automatyczną aprowizację usługi Azure Arc

Opis: Aby uzyskać pełną widoczność zawartości zabezpieczeń z usługi Microsoft Defender dla serwerów, wystąpienia maszyn wirtualnych GCP powinny być połączone z usługą Azure Arc. Aby upewnić się, że wszystkie kwalifikujące się wystąpienia maszyn wirtualnych automatycznie otrzymują usługę Azure Arc, włącz automatyczne aprowizowanie z Defender dla Chmury na poziomie projektu GCP. Dowiedz się więcej o usługach Azure Arc i Microsoft Defender for Servers.

Ważność: Wysoka

Wystąpienia maszyn wirtualnych GCP powinny być połączone z usługą Azure Arc

Opis: Połączenie maszyn wirtualnych GCP do usługi Azure Arc, aby zapewnić pełną widoczność zawartości zabezpieczeń usługi Microsoft Defender for Servers. Dowiedz się więcej o usłudze Azure Arc i usłudze Microsoft Defender dla serwerów w środowisku chmury hybrydowej.

Ważność: Wysoka

Wystąpienia maszyn wirtualnych GCP powinny mieć zainstalowanego agenta konfiguracji systemu operacyjnego

Opis: Aby uzyskać pełne możliwości usługi Defender for Servers przy użyciu automatycznego aprowizowania usługi Azure Arc, maszyny wirtualne GCP powinny mieć włączonego agenta konfiguracji systemu operacyjnego.

Ważność: Wysoka

Funkcja automatycznego naprawiania klastra GKE powinna być włączona

Opis: To zalecenie ocenia właściwość zarządzania puli węzłów dla pary klucz-wartość, "key": "autoRepair", "value": true.

Ważność: średni rozmiar

Funkcja automatycznego uaktualniania klastra GKE powinna być włączona

Opis: To zalecenie ocenia właściwość zarządzania puli węzłów dla pary klucz-wartość, "key": "autoUpgrade", "value": true.

Ważność: Wysoka

Monitorowanie w klastrach GKE powinno być włączone

Opis: To zalecenie ocenia, czy właściwość monitoringService klastra zawiera lokalizację Monitorowanie w chmurze, która powinna służyć do pisania metryk.

Ważność: średni rozmiar

Zalecenia dotyczące kontenera GCP

[Wersja zapoznawcza] Obrazy kontenerów w rejestrze GCP powinny mieć rozwiązane problemy z lukami w zabezpieczeniach

Opis: Defender dla Chmury skanuje obrazy rejestru pod kątem znanych luk w zabezpieczeniach (CVE) i zawiera szczegółowe wyniki dla każdego zeskanowanego obrazu. Skanowanie i korygowanie luk w zabezpieczeniach obrazów kontenerów w rejestrze pomaga zachować bezpieczny i niezawodny łańcuch dostaw oprogramowania, zmniejsza ryzyko zdarzeń związanych z bezpieczeństwem i zapewnia zgodność ze standardami branżowymi.

Ważność: Wysoka

Typ: Ocena luk w zabezpieczeniach

[Wersja zapoznawcza] Kontenery uruchomione na platformie GCP powinny mieć rozwiązane problemy z lukami w zabezpieczeniach

Opis: Defender dla Chmury tworzy spis wszystkich obciążeń kontenerów aktualnie uruchomionych w klastrach Kubernetes i udostępnia raporty luk w zabezpieczeniach dla tych obciążeń, pasując do używanych obrazów i raportów o lukach w zabezpieczeniach utworzonych dla obrazów rejestru. Skanowanie i korygowanie luk w zabezpieczeniach obciążeń kontenerów ma kluczowe znaczenie dla zapewnienia niezawodnego i bezpiecznego łańcucha dostaw oprogramowania, zmniejszenia ryzyka zdarzeń bezpieczeństwa i zapewnienia zgodności ze standardami branżowymi.

Ważność: Wysoka

Typ: Ocena luk w zabezpieczeniach

Zaawansowana konfiguracja kontenerów usługi Defender for Containers powinna być włączona w łącznikach GCP

Opis: Usługa Microsoft Defender for Containers zapewnia natywne dla chmury funkcje zabezpieczeń platformy Kubernetes, w tym zabezpieczenia środowiska, ochronę obciążeń i ochronę w czasie wykonywania. Aby upewnić się, że rozwiązanie jest prawidłowo aprowidowane, a pełny zestaw funkcji jest dostępny, włącz wszystkie zaawansowane ustawienia konfiguracji.

Ważność: Wysoka

Klastry GKE powinny mieć zainstalowane rozszerzenie usługi Microsoft Defender dla usługi Azure Arc

Opis: Rozszerzenie klastra usługi Microsoft Defender zapewnia możliwości zabezpieczeń klastrów GKE. Rozszerzenie zbiera dane z klastra i jego węzłów w celu identyfikowania luk w zabezpieczeniach i zagrożeń. Rozszerzenie współpracuje z platformą Kubernetes z obsługą usługi Azure Arc. Dowiedz się więcej o funkcjach zabezpieczeń Microsoft Defender dla Chmury dla środowisk konteneryzowanych.

Ważność: Wysoka

Klastry GKE powinny mieć zainstalowane rozszerzenie usługi Azure Policy

Opis: Rozszerzenie usługi Azure Policy dla platformy Kubernetes rozszerza usługę Gatekeeper w wersji 3, element webhook kontrolera dostępu dla agenta open policy ( OPA), aby zastosować wymuszania i zabezpieczenia na dużą skalę w klastrach w sposób scentralizowany i spójny. Rozszerzenie współpracuje z platformą Kubernetes z obsługą usługi Azure Arc.

Ważność: Wysoka

Usługa Microsoft Defender for Containers powinna być włączona w łącznikach GCP

Opis: Usługa Microsoft Defender for Containers zapewnia natywne dla chmury funkcje zabezpieczeń platformy Kubernetes, w tym zabezpieczenia środowiska, ochronę obciążeń i ochronę w czasie wykonywania. Włącz planowanie kontenerów w łączniku GCP, aby wzmocnić bezpieczeństwo klastrów Kubernetes i rozwiązać problemy z zabezpieczeniami. Dowiedz się więcej o usłudze Microsoft Defender for Containers.

Ważność: Wysoka

Funkcja automatycznego naprawiania klastra GKE powinna być włączona

Opis: To zalecenie ocenia właściwość zarządzania puli węzłów dla pary klucz-wartość, "key": "autoRepair", "value": true.

Ważność: średni rozmiar

Funkcja automatycznego uaktualniania klastra GKE powinna być włączona

Opis: To zalecenie ocenia właściwość zarządzania puli węzłów dla pary klucz-wartość, "key": "autoUpgrade", "value": true.

Ważność: Wysoka

Monitorowanie w klastrach GKE powinno być włączone

Opis: To zalecenie ocenia, czy właściwość monitoringService klastra zawiera lokalizację Monitorowanie w chmurze, która powinna służyć do pisania metryk.

Ważność: średni rozmiar

Rejestrowanie dla klastrów GKE powinno być włączone

Opis: To zalecenie ocenia, czy właściwość loggingService klastra zawiera lokalizację Rejestrowanie w chmurze, która powinna służyć do zapisywania dzienników.

Ważność: Wysoka

Pulpit nawigacyjny sieci Web GKE powinien być wyłączony

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

Ważność: Wysoka

Starsza wersja autoryzacji powinna być wyłączona w klastrach GKE

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

Ważność: Wysoka

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

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

Zalecenia dotyczące płaszczyzny danych

Wszystkie zalecenia dotyczące zabezpieczeń płaszczyzny danych platformy Kubernetes są obsługiwane dla platformy GCP po włączeniu usługi Azure Policy dla platformy Kubernetes.

Zalecenia dotyczące danych GCP

Upewnij się, że flaga bazy danych "3625 (flaga śledzenia)" dla wystąpienia usługi Cloud SQL Server jest ustawiona na wartość "off"

Opis: Zaleca się ustawienie flagi bazy danych "3625 (flaga śledzenia)" dla wystąpienia usługi Cloud SQL Server na wartość "off". Flagi śledzenia są często używane do diagnozowania problemów z wydajnością lub debugowania procedur składowanych lub złożonych systemów komputerowych, ale mogą być również zalecane przez pomoc techniczna firmy Microsoft w celu rozwiązania problemów, które negatywnie wpływają na określone obciążenie. Wszystkie udokumentowane flagi śledzenia i zalecane przez pomoc techniczna firmy Microsoft są w pełni obsługiwane w środowisku produkcyjnym, gdy są używane zgodnie z zaleceniami. "3625(dziennik śledzenia)" ogranicza ilość informacji zwracanych do użytkowników, którzy nie są członkami stałej roli serwera sysadmin, maskując parametry niektórych komunikatów o błędach przy użyciu polecenia "******". Może to pomóc zapobiec ujawnieniu poufnych informacji. Dlatego zaleca się wyłączenie tej flagi. To zalecenie dotyczy wystąpień bazy danych programu SQL Server.

Ważność: średni rozmiar

Upewnij się, że flaga bazy danych "włączone skrypty zewnętrzne" dla wystąpienia usługi Cloud SQL Server jest ustawiona na "wyłączone"

Opis: Zaleca się ustawienie flagi bazy danych "włączone skrypty zewnętrzne" dla wystąpienia programu SQL Server w chmurze na wartość wyłączone. "Włączone skrypty zewnętrzne" umożliwiają wykonywanie skryptów z określonymi rozszerzeniami języka zdalnego. Ta właściwość jest domyślnie wyłączona. Po zainstalowaniu usług Advanced Analytics Services instalator może opcjonalnie ustawić tę właściwość na wartość true. Ponieważ funkcja "Włączone skrypty zewnętrzne" umożliwia wykonywanie skryptów zewnętrznych dla języka SQL, takich jak pliki znajdujące się w bibliotece języka R, co może niekorzystnie wpłynąć na bezpieczeństwo systemu, dlatego powinno to zostać wyłączone. To zalecenie dotyczy wystąpień bazy danych programu SQL Server.

Ważność: Wysoka

Upewnij się, że flaga bazy danych dostępu zdalnego dla wystąpienia programu SQL Server w chmurze jest ustawiona na wartość "wyłączone"

Opis: Zaleca się ustawienie flagi bazy danych "dostęp zdalny" dla wystąpienia usługi Cloud SQL Server na wartość "wyłączone". Opcja "dostęp zdalny" kontroluje wykonywanie procedur składowanych z lokalnych lub zdalnych serwerów, na których działają wystąpienia programu SQL Server. Ta wartość domyślna dla tej opcji to 1. Daje to uprawnienie do uruchamiania lokalnych procedur składowanych z serwerów zdalnych lub zdalnych procedur składowanych z serwera lokalnego. Aby zapobiec uruchamianiu lokalnych procedur składowanych z serwera zdalnego lub zdalnych procedur składowanych na serwerze lokalnym, należy to wyłączyć. Opcja Dostęp zdalny kontroluje wykonywanie lokalnych procedur składowanych na serwerach zdalnych lub zdalnych procedurach składowanych na serwerze lokalnym. Funkcja "Dostęp zdalny" może być nadużywana w celu uruchomienia ataku typu "odmowa usługi" (DoS) na serwery zdalne przez odciążanie przetwarzania zapytań do obiektu docelowego, dlatego powinno to być wyłączone. To zalecenie dotyczy wystąpień bazy danych programu SQL Server.

Ważność: Wysoka

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

Opis: Zaleca się ustawienie flagi bazy danych "skip_show_database" dla wystąpienia usługi Cloud SQL Mysql na wartość "on". Flaga bazy danych "skip_show_database" uniemożliwia użytkownikom korzystanie z instrukcji SHOW DATABASES, jeśli nie mają uprawnień SHOW DATABASES. Może to poprawić bezpieczeństwo, jeśli masz obawy dotyczące możliwości wyświetlenia baz danych należących do innych użytkowników. Jego wpływ zależy od uprawnień SHOW DATABASES: jeśli wartość zmiennej jest WŁĄCZONa, instrukcja SHOW DATABASES jest dozwolona tylko dla użytkowników, którzy mają uprawnienia SHOW DATABASES, a instrukcja wyświetla wszystkie nazwy baz danych. Jeśli wartość jest wyłączona, opcja SHOW DATABASES jest dozwolona dla wszystkich użytkowników, ale wyświetla nazwy tylko tych baz danych, dla których użytkownik ma uprawnienia SHOW DATABASES lub inne uprawnienia. To zalecenie dotyczy wystąpień bazy danych Mysql.

Ważność: Niska

Upewnij się, że dla wszystkich zestawów danych BigQuery określono domyślny klucz szyfrowania zarządzany przez klienta (CMEK)

Opis: Funkcja BigQuery domyślnie szyfruje dane jako pozostałe, stosując szyfrowanie kopert przy użyciu zarządzanych przez firmę Google kluczy kryptograficznych. Dane są szyfrowane przy użyciu kluczy szyfrowania danych, a same klucze szyfrowania danych są dalej szyfrowane przy użyciu kluczy szyfrowania kluczy. Jest to bezproblemowe i nie wymaga żadnych dodatkowych danych wejściowych od użytkownika. Jeśli jednak chcesz mieć większą kontrolę, klucze szyfrowania zarządzane przez klienta (CMEK) mogą być używane jako rozwiązanie do zarządzania kluczami szyfrowania dla zestawów danych BigQuery. Funkcja BigQuery domyślnie szyfruje dane jako pozostałe, stosując szyfrowanie kopert przy użyciu zarządzanych przez firmę Google kluczy kryptograficznych. Jest to bezproblemowe i nie wymaga żadnych dodatkowych danych wejściowych od użytkownika. Aby uzyskać większą kontrolę nad szyfrowaniem, klucze szyfrowania zarządzane przez klienta (CMEK) mogą być używane jako rozwiązanie do zarządzania kluczami szyfrowania dla zestawów danych BigQuery. Ustawienie domyślnego klucza szyfrowania zarządzanego przez klienta (CMEK) dla zestawu danych zapewnia, że wszystkie tabele utworzone w przyszłości będą używać określonego klucza CMEK, jeśli nie podano żadnego innego. Uwaga: Firma Google nie przechowuje kluczy na swoich serwerach i nie może uzyskać dostępu do chronionych danych, chyba że podasz klucz. Oznacza to również, że jeśli zapomnisz lub utracisz klucz, nie ma możliwości odzyskania klucza przez firmę Google ani odzyskania jakichkolwiek danych zaszyfrowanych przy użyciu utraconego klucza.

Ważność: średni rozmiar

Upewnij się, że wszystkie tabele BigQuery są szyfrowane przy użyciu klucza szyfrowania zarządzanego przez klienta (CMEK)

Opis: Funkcja BigQuery domyślnie szyfruje dane jako pozostałe, stosując szyfrowanie kopert przy użyciu zarządzanych przez firmę Google kluczy kryptograficznych. Dane są szyfrowane przy użyciu kluczy szyfrowania danych, a same klucze szyfrowania danych są dalej szyfrowane przy użyciu kluczy szyfrowania kluczy. Jest to bezproblemowe i nie wymaga żadnych dodatkowych danych wejściowych od użytkownika. Jeśli jednak chcesz mieć większą kontrolę, klucze szyfrowania zarządzane przez klienta (CMEK) mogą być używane jako rozwiązanie do zarządzania kluczami szyfrowania dla zestawów danych BigQuery. Jeśli klucz CMEK jest używany, klucz CMEK jest używany do szyfrowania kluczy szyfrowania danych zamiast przy użyciu kluczy szyfrowania zarządzanych przez firmę Google. Funkcja BigQuery domyślnie szyfruje dane jako pozostałe, stosując szyfrowanie kopert przy użyciu zarządzanych przez firmę Google kluczy kryptograficznych. Jest to bezproblemowe i nie wymaga żadnych dodatkowych danych wejściowych od użytkownika. Aby uzyskać większą kontrolę nad szyfrowaniem, klucze szyfrowania zarządzane przez klienta (CMEK) mogą być używane jako rozwiązanie do zarządzania kluczami szyfrowania dla tabel BigQuery. Klucz CMEK służy do szyfrowania kluczy szyfrowania danych zamiast używania kluczy szyfrowania zarządzanych przez firmę Google. BigQuery przechowuje tabelę i skojarzenie CMEK, a szyfrowanie/odszyfrowywanie odbywa się automatycznie. Zastosowanie domyślnych kluczy zarządzanych przez klienta w zestawach danych BigQuery gwarantuje, że wszystkie nowe tabele utworzone w przyszłości będą szyfrowane przy użyciu klucza CMEK, ale istniejące tabele muszą zostać zaktualizowane w celu indywidualnego używania klucza CMEK. Uwaga: Firma Google nie przechowuje kluczy na swoich serwerach i nie może uzyskać dostępu do chronionych danych, chyba że podasz klucz. Oznacza to również, że jeśli zapomnisz lub utracisz klucz, nie ma możliwości odzyskania klucza przez firmę Google ani odzyskania jakichkolwiek danych zaszyfrowanych przy użyciu utraconego klucza.

Ważność: średni rozmiar

Upewnij się, że zestawy danych BigQuery nie są anonimowe ani publicznie dostępne

Opis: Zaleca się, aby zasady zarządzania dostępem i tożsamościami w zestawach danych BigQuery nie zezwalały na dostęp anonimowy i/lub publiczny. Udzielanie uprawnień wszystkimUżytkownikom lub wszystkimUżytkownikomAuthenticatedUsers umożliwia każdemu dostęp do zestawu danych. Taki dostęp może nie być pożądany, jeśli dane poufne są przechowywane w zestawie danych. W związku z tym upewnij się, że dostęp anonimowy i/lub publiczny do zestawu danych nie jest dozwolony.

Ważność: Wysoka

Upewnij się, że wystąpienia bazy danych SQL w chmurze są skonfigurowane z automatycznymi kopiami zapasowymi

Opis: Zaleca się, aby wszystkie wystąpienia bazy danych SQL zostały ustawione w celu włączenia automatycznych kopii zapasowych. Kopie zapasowe umożliwiają przywrócenie wystąpienia sql w chmurze w celu odzyskania utraconych danych lub odzyskania po wystąpieniu problemu z tym wystąpieniem. Automatyczne kopie zapasowe należy ustawić dla dowolnego wystąpienia zawierającego dane, które powinny być chronione przed utratą lub uszkodzeniem. To zalecenie dotyczy wystąpień programów SQL Server, PostgreSql, MySql 1 i MySql 2. generacji.

Ważność: Wysoka

Upewnij się, że wystąpienia bazy danych SQL w chmurze nie są otwarte dla świata

Opis: Serwer bazy danych powinien akceptować połączenia tylko z zaufanych sieci/adresów IP i ograniczać dostęp ze świata. Aby zminimalizować obszar ataków w wystąpieniu serwera bazy danych, należy zatwierdzić tylko zaufane/znane i wymagane adresy IP w celu nawiązania z nim połączenia. Autoryzowana sieć nie powinna mieć skonfigurowanych adresów IP/sieci "0.0.0.0/0", co umożliwi dostęp do wystąpienia z dowolnego miejsca na świecie. Należy pamiętać, że autoryzowane sieci mają zastosowanie tylko do wystąpień z publicznymi adresami IP.

Ważność: Wysoka

Upewnij się, że wystąpienia bazy danych SQL w chmurze nie mają publicznych adresów IP

Opis: Zaleca się skonfigurowanie wystąpienia Sql drugiej generacji do używania prywatnych adresów IP zamiast publicznych adresów IP. Aby zmniejszyć obszar ataków organizacji, bazy danych SQL w chmurze nie powinny mieć publicznych adresów IP. Prywatne adresy IP zapewniają lepsze zabezpieczenia sieci i mniejsze opóźnienia aplikacji.

Ważność: Wysoka

Upewnij się, że zasobnik magazynu w chmurze nie jest anonimowo ani publicznie dostępny

Opis: Zalecane jest, aby zasady zarządzania dostępem i tożsamościami w zasobniku magazynu w chmurze nie zezwalały na dostęp anonimowy ani publiczny. Zezwalanie na dostęp anonimowy lub publiczny przyznaje każdemu użytkownikowi uprawnienia dostępu do zawartości zasobnika. Taki dostęp może nie być wymagany, jeśli przechowujesz jakiekolwiek poufne dane. W związku z tym upewnij się, że dostęp anonimowy lub publiczny do zasobnika nie jest dozwolony.

Ważność: Wysoka

Upewnij się, że zasobniki magazynu w chmurze mają włączony jednolity dostęp na poziomie zasobnika

Opis: Zaleca się włączenie dostępu na poziomie jednolitego zasobnika w zasobnikach usługi Cloud Storage. Zaleca się stosowanie jednolitego dostępu na poziomie zasobnika w celu ujednolicenia i uproszczenia sposobu udzielania dostępu do zasobów usługi Cloud Storage. Usługa Cloud Storage oferuje dwa systemy udzielania użytkownikom uprawnień dostępu do zasobników i obiektów: Zarządzanie tożsamościami w chmurze i dostępem (Cloud IAM) oraz listami kontroli dostępu (ACL).
Te systemy działają równolegle — aby użytkownik uzyskiwał dostęp do zasobu usługi Cloud Storage, tylko jeden z systemów musi udzielić użytkownikowi uprawnień. Zarządzanie dostępem i tożsamościami w chmurze w chmurze w usłudze Google Cloud umożliwia przyznawanie różnych uprawnień na poziomach zasobnika i projektu. Listy ACL są używane tylko przez usługę Cloud Storage i mają ograniczone opcje uprawnień, ale umożliwiają przyznawanie uprawnień dla poszczególnych obiektów.

Aby obsługiwać jednolity system uprawnień, usługa Cloud Storage ma jednolity dostęp na poziomie zasobnika. Użycie tej funkcji wyłącza listy ACL dla wszystkich zasobów magazynu w chmurze: dostęp do zasobów usługi Cloud Storage, a następnie jest udzielany wyłącznie za pośrednictwem funkcji Zarządzania dostępem i tożsamościami w chmurze. Włączenie dostępu na poziomie jednolitego zasobnika gwarantuje, że jeśli zasobnik magazynu nie jest publicznie dostępny, żaden obiekt w zasobniku jest publicznie dostępny.

Ważność: średni rozmiar

Upewnij się, że wystąpienia obliczeniowe mają włączone poufne przetwarzanie

Opis: Usługa Google Cloud szyfruje dane magazynowane i przesyłane, ale dane klientów muszą być odszyfrowywane do przetwarzania. Poufne przetwarzanie to przełomowa technologia, która szyfruje dane w użyciu podczas ich przetwarzania. Poufne środowiska obliczeniowe przechowują dane zaszyfrowane w pamięci i w innych miejscach poza centralną jednostką przetwarzania (CPU). Poufne maszyny wirtualne korzystają z funkcji Secure Encrypted Virtualization (SEV) procesorów AMD EPYC. Dane klienta pozostaną zaszyfrowane, gdy będą używane, indeksowane, odpytywane lub wytrenowane. Klucze szyfrowania są generowane na sprzęcie, na maszynę wirtualną i nie można eksportować. Dzięki wbudowanym optymalizacjom sprzętowym zarówno wydajności, jak i zabezpieczeń nie ma znaczącej kary dla obciążeń poufnego przetwarzania. Poufne przetwarzanie umożliwia klientom poufny kod i inne dane zaszyfrowane w pamięci podczas przetwarzania. Firma Google nie ma dostępu do kluczy szyfrowania. Poufne maszyny wirtualne mogą pomóc złagodzić obawy dotyczące ryzyka związanego z zależnością od infrastruktury Google lub dostępu niejawnych testerów firmy Google do danych klientów w przejrzysty sposób.

Ważność: Wysoka

Upewnij się, że zasady przechowywania w zasobnikach dziennika są skonfigurowane przy użyciu blokady zasobnika

Opis: Włączenie zasad przechowywania w zasobnikach dziennika spowoduje ochronę dzienników przechowywanych w zasobnikach magazynu w chmurze przed zastąpieniem lub przypadkowym usunięciem. Zaleca się skonfigurowanie zasad przechowywania i skonfigurowanie blokady zasobnika na wszystkich zasobnikach magazynu, które są używane jako ujścia dzienników. Dzienniki można wyeksportować, tworząc co najmniej jeden ujścia, który zawiera filtr dziennika i miejsce docelowe. Gdy rejestrowanie usługi Stackdriver odbiera nowe wpisy dziennika, są porównywane z każdym ujściem. Jeśli wpis dziennika pasuje do filtru ujścia, kopia wpisu dziennika jest zapisywana w miejscu docelowym. Ujścia można skonfigurować do eksportowania dzienników w zasobnikach magazynu. Zaleca się skonfigurowanie zasad przechowywania danych dla tych zasobników magazynu w chmurze i zablokowanie zasad przechowywania danych; w ten sposób trwale uniemożliwia zmniejszenie lub usunięcie zasad. W ten sposób, jeśli system kiedykolwiek zostanie naruszony przez osobę atakującą lub złośliwego insidera, który chce zakryć swoje ślady, dzienniki aktywności są zdecydowanie zachowywane w przypadku dochodzeń kryminalistycznych i śledczych.

Ważność: Niska

Upewnij się, że wystąpienie bazy danych SQL w chmurze wymaga wszystkich połączeń przychodzących do korzystania z protokołu SSL

Opis: zaleca się wymuszanie wszystkich połączeń przychodzących z wystąpieniem bazy danych SQL w celu używania protokołu SSL. Połączenia z bazą danych SQL, jeśli zostały pomyślnie uwięzione (MITM); może ujawniać poufne dane, takie jak poświadczenia, zapytania bazy danych, dane wyjściowe zapytań itp. W przypadku zabezpieczeń zaleca się zawsze używanie szyfrowania SSL podczas nawiązywania połączenia z wystąpieniem. To zalecenie dotyczy wystąpień Postgresql, MySql 1. generacji i MySql 2. generacji.

Ważność: Wysoka

Upewnij się, że flaga bazy danych "zawarte uwierzytelnianie bazy danych" dla usługi Cloud SQL w wystąpieniu programu SQL Server jest ustawiona na wartość "off"

Opis: Zaleca się ustawienie flagi bazy danych "zawarte uwierzytelnianie bazy danych" dla usługi Cloud SQL w wystąpieniu programu SQL Server na wartość "wyłączone". Zawarta baza danych zawiera wszystkie ustawienia bazy danych i metadane wymagane do zdefiniowania bazy danych i nie ma zależności konfiguracji od wystąpienia aparatu bazy danych, w którym zainstalowano bazę danych. Użytkownicy mogą łączyć się z bazą danych bez uwierzytelniania logowania na poziomie aparatu bazy danych. Izolowanie bazy danych z aparatu bazy danych umożliwia łatwe przenoszenie bazy danych do innego wystąpienia programu SQL Server. Zawarte bazy danych mają pewne unikatowe zagrożenia, które powinny być zrozumiałe i ograniczane przez administratorów aparatu bazy danych programu SQL Server. Większość zagrożeń jest związanych z procesem uwierzytelniania USER WITH PASSWORD, który przenosi granicę uwierzytelniania z poziomu aparatu bazy danych do poziomu bazy danych, dlatego zaleca się wyłączenie tej flagi. To zalecenie dotyczy wystąpień bazy danych programu SQL Server.

Ważność: średni rozmiar

Upewnij się, że flaga bazy danych "cross db ownershiping" dla wystąpienia usługi Cloud SQL Server jest ustawiona na wartość "off"

Opis: Zaleca się ustawienie flagi bazy danych "łączenie łańcuchów własności między bazami danych" dla wystąpienia programu SQL Server w chmurze na wartość "off". Użyj opcji "własność między bazami danych", aby skonfigurować łańcuch własności między bazami danych dla wystąpienia programu Microsoft SQL Server. Ta opcja serwera umożliwia kontrolowanie łańcucha własności między bazami danych na poziomie bazy danych lub zezwalanie na łańcuch własności między bazami danych dla wszystkich baz danych. Włączenie "własności między bazami danych" nie jest zalecane, chyba że wszystkie bazy danych hostowane przez wystąpienie programu SQL Server muszą uczestniczyć w łańcuchu własności między bazami danych i wiesz, jakie są implikacje zabezpieczeń tego ustawienia. To zalecenie dotyczy wystąpień bazy danych programu SQL Server.

Ważność: średni rozmiar

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

Opis: zaleca się ustawienie flagi bazy danych local_infile dla wystąpienia usługi Cloud SQL MySQL na wyłączone. Flaga local_infile steruje funkcją LOCAL po stronie serwera dla instrukcji LOAD DATA. W zależności od ustawienia local_infile serwer odmawia lub zezwala na lokalne ładowanie danych przez klientów, którzy mają włączone lokalne po stronie klienta. Aby jawnie spowodować, że serwer odmówi instrukcji LOAD DATA LOCAL (niezależnie od tego, jak programy klienckie i biblioteki są skonfigurowane w czasie kompilacji lub w czasie wykonywania), uruchom program mysqld z wyłączoną local_infile. local_infile można również ustawić w czasie wykonywania. Ze względu na problemy z zabezpieczeniami skojarzone z flagą local_infile zaleca się jego wyłączenie. To zalecenie dotyczy wystąpień bazy danych MySQL.

Ważność: średni rozmiar

Upewnij się, że istnieje filtr metryk dzienników i alerty dotyczące zmian uprawnień zarządzanie dostępem i tożsamościami w usłudze Cloud Storage

Opis: Zaleca się ustanowienie filtru metryki i alarmu dla zmian IAM zasobnika magazynu w chmurze. Monitorowanie zmian uprawnień zasobnika magazynu w chmurze może skrócić czas potrzebny do wykrywania i poprawiania uprawnień do poufnych zasobników i obiektów magazynu w chmurze w zasobniku.

Ważność: Niska

Upewnij się, że dla zmian konfiguracji wystąpienia SQL istnieją filtry metryk dzienników i alerty

Opis: Zaleca się ustanowienie filtru metryki i alarmu dla zmian konfiguracji wystąpienia SQL. Monitorowanie zmian konfiguracji wystąpienia SQL może skrócić czas potrzebny na wykrywanie i poprawianie błędów konfiguracji na serwerze SQL. Poniżej przedstawiono kilka konfigurowalnych opcji, które mogą mieć wpływ na stan zabezpieczeń wystąpienia SQL:

• Włączanie automatycznych kopii zapasowych i wysokiej dostępności: Nieprawidłowa konfiguracja może mieć negatywny wpływ na ciągłość działania, odzyskiwanie po awarii i wysoką dostępność
• Autoryzowanie sieci: Błędna konfiguracja może zwiększyć narażenie na niezaufane sieci

Ważność: Niska

Upewnij się, że istnieją tylko klucze konta usługi zarządzane przez usługę GCP dla każdego konta usługi

Opis: Konta usług zarządzanych przez użytkownika nie powinny mieć kluczy zarządzanych przez użytkownika. Każda osoba, która ma dostęp do kluczy, będzie mogła uzyskiwać dostęp do zasobów za pośrednictwem konta usługi. Klucze zarządzane przez GCP są używane przez usługi platformy w chmurze, takie jak App Engine i Compute Engine. Nie można pobrać tych kluczy. Google będzie przechowywać klucze i automatycznie obracać je w przybliżeniu co tydzień. Klucze zarządzane przez użytkownika są tworzone, pobierane i zarządzane przez użytkowników. Wygasają 10 lat od utworzenia. W przypadku kluczy zarządzanych przez użytkownika użytkownik musi przejąć własność działań związanych z zarządzaniem kluczami, które obejmują:

• Magazyn kluczy
• Dystrybucja kluczy
• Odwołanie klucza
• Wymiana kluczy
• Ochrona kluczy przed nieautoryzowanymi użytkownikami
• Odzyskiwanie klucza

Nawet przy użyciu środków ostrożności właściciela klucza klucze można łatwo wyciekać przez typowe błędy programistyczne, takie jak sprawdzanie kluczy w kodzie źródłowym lub pozostawienie ich w katalogu Pobrane lub przypadkowe pozostawienie ich na blogach/kanałach pomocy technicznej. Zaleca się zapobieganie kluczom konta usługi zarządzanej przez użytkownika.

Ważność: Niska

Upewnij się, że flaga bazy danych "połączenia użytkownika" dla wystąpienia programu SQL Server w chmurze jest ustawiona zgodnie z potrzebami

Opis: Zaleca się ustawienie flagi bazy danych "połączenia użytkownika" dla wystąpienia usługi Cloud SQL Server zgodnie z wartością zdefiniowaną przez organizację. Opcja "Połączenia użytkownika" określa maksymalną liczbę równoczesnych połączeń użytkowników dozwolonych w wystąpieniu programu SQL Server. Rzeczywista dozwolona liczba dozwolonych połączeń użytkowników zależy również od używanej wersji programu SQL Server, a także limitów aplikacji lub aplikacji i sprzętu. Program SQL Server umożliwia maksymalnie 32 767 połączeń użytkowników. Ponieważ połączenia użytkowników są opcją dynamiczną (samozastawialną), program SQL Server dostosowuje maksymalną liczbę połączeń użytkowników automatycznie zgodnie z potrzebami, nawet do dozwolonej maksymalnej wartości. Jeśli na przykład tylko 10 użytkowników jest zalogowanych, przydzielono 10 obiektów połączenia użytkownika. W większości przypadków nie trzeba zmieniać wartości dla tej opcji. Wartość domyślna to 0, co oznacza, że dozwolone są maksymalne (32 767) połączenia użytkowników. To zalecenie dotyczy wystąpień bazy danych programu SQL Server.

Ważność: Niska

Upewnij się, że flaga bazy danych "opcje użytkownika" dla wystąpienia usługi Cloud SQL Server nie jest skonfigurowana

Opis: Zaleca się, aby flaga bazy danych "opcje użytkownika" dla wystąpienia usługi Cloud SQL Server programu SQL Server nie była skonfigurowana. Opcja "opcje użytkownika" określa globalne wartości domyślne dla wszystkich użytkowników. Lista domyślnych opcji przetwarzania zapytań jest ustanawiana na czas trwania sesji roboczej użytkownika. Opcja opcji użytkownika umożliwia zmianę wartości domyślnych opcji ZESTAWU (jeśli ustawienia domyślne serwera nie są odpowiednie). Użytkownik może zastąpić te wartości domyślne przy użyciu instrukcji SET. Opcje użytkownika można konfigurować dynamicznie dla nowych logowań. Po zmianie ustawienia opcji użytkownika nowe sesje logowania używają nowego ustawienia; Nie ma to wpływu na bieżące sesje logowania. To zalecenie dotyczy wystąpień bazy danych programu SQL Server.

Ważność: Niska

Rejestrowanie dla klastrów GKE powinno być włączone

Opis: To zalecenie ocenia, czy właściwość loggingService klastra zawiera lokalizację Rejestrowanie w chmurze, która powinna służyć do zapisywania dzienników.

Ważność: Wysoka

Przechowywanie wersji obiektów powinno być włączone w zasobnikach magazynu, w których skonfigurowano ujścia

Opis: To zalecenie ocenia, czy włączone pole we właściwości przechowywania wersji zasobnika ma wartość true.

Ważność: Wysoka

W celu zmniejszenia indeksu pełzania uprawnień (PCI) należy zbadać nadmierną aprowizację tożsamości w projektach

Opis: Należy zbadać nadmierną aprowizację tożsamości w projektach w celu zmniejszenia indeksu pełzania uprawnień (PCI) i ochrony infrastruktury. Zmniejsz pci, usuwając nieużywane przypisania uprawnień wysokiego ryzyka. Wysoka wartość PCI odzwierciedla ryzyko związane z tożsamościami z uprawnieniami, które przekraczają normalne lub wymagane użycie.

Ważność: średni rozmiar

Projekty z kluczami kryptograficznymi nie powinny mieć użytkowników z uprawnieniami właściciela

Opis: To zalecenie ocenia zasady zezwalania na zarządzanie dostępem i tożsamościami w metadanych projektu dla przypisanych ról podmiotów zabezpieczeń/właściciela.

Ważność: średni rozmiar

Zasobniki magazynu używane jako ujście dziennika nie powinny być publicznie dostępne

Opis: To zalecenie ocenia zasady zarządzania dostępem i tożsamościami zasobnika dla podmiotów zabezpieczeń allUsers lub allAuthenticatedUsers, które udzielają dostępu publicznego.

Ważność: Wysoka

Zalecenia dotyczące funkcji GCP IdentityAndAccess

Klucze kryptograficzne nie powinny mieć więcej niż trzech użytkowników

Opis: To zalecenie ocenia zasady zarządzania dostępem i tożsamościami dla pierścieni kluczy, projektów i organizacji oraz pobiera podmioty z rolami, które umożliwiają szyfrowanie, odszyfrowywanie lub podpisywanie danych przy użyciu kluczy kms w chmurze: roles/owner, roles/cloudkms.cryptoKeyEncrypterDecrypter, roles/cloudkms.cryptoKeyEncrypter, roles/cloudkms.cryptoKeyDecrypter, roles/cloudkms.signer i roles/cloudkms.signerVerifier.

Ważność: średni rozmiar

Upewnij się, że klucze interfejsu API nie są tworzone dla projektu

Opis: Klucze są niezabezpieczone, ponieważ mogą być wyświetlane publicznie, na przykład z poziomu przeglądarki, lub mogą być dostępne na urządzeniu, na którym znajduje się klucz. Zaleca się zamiast tego używanie standardowego przepływu uwierzytelniania.

Poniżej przedstawiono zagrożenia bezpieczeństwa związane z używaniem kluczy INTERFEJSu API:

1. Klucze interfejsu API to proste zaszyfrowane ciągi
2. Klucze interfejsu API nie identyfikują użytkownika ani aplikacji wysyłającej żądanie interfejsu API
3. Klucze interfejsu API są zwykle dostępne dla klientów, co ułatwia odnajdywanie i kradzież klucza interfejsu API

Aby uniknąć ryzyka związanego z zabezpieczeniami przy użyciu kluczy interfejsu API, zaleca się zamiast tego użycie standardowego przepływu uwierzytelniania.

Ważność: Wysoka

Upewnij się, że klucze interfejsu API są ograniczone tylko do interfejsów API, do których aplikacja potrzebuje dostępu

Opis: klucze interfejsu API są niezabezpieczone, ponieważ mogą być wyświetlane publicznie, na przykład z poziomu przeglądarki, lub mogą być dostępne na urządzeniu, na którym znajduje się klucz. Zaleca się ograniczenie kluczy interfejsu API do używania (wywołania) tylko interfejsów API wymaganych przez aplikację.

Poniżej przedstawiono zagrożenia bezpieczeństwa związane z używaniem kluczy INTERFEJSu API:

1. Klucze interfejsu API to proste zaszyfrowane ciągi
2. Klucze interfejsu API nie identyfikują użytkownika ani aplikacji wysyłającej żądanie interfejsu API
3. Klucze interfejsu API są zwykle dostępne dla klientów, co ułatwia odnajdywanie i kradzież klucza interfejsu API

W świetle tych potencjalnych zagrożeń firma Google zaleca użycie standardowego przepływu uwierzytelniania zamiast kluczy interfejsu API. Istnieją jednak ograniczone przypadki, w których klucze interfejsu API są bardziej odpowiednie. Jeśli na przykład istnieje aplikacja mobilna, która musi używać interfejsu API tłumaczenia w chmurze Google, ale w przeciwnym razie nie wymaga serwera zaplecza, klucze interfejsu API są najprostszym sposobem uwierzytelniania w tym interfejsie API.

Aby zmniejszyć powierzchnie ataków, zapewniając najmniejsze uprawnienia, klucze interfejsu API mogą być ograniczone do używania (wywołania) tylko interfejsów API wymaganych przez aplikację.

Ważność: Wysoka

Upewnij się, że klucze interfejsu API są ograniczone do użycia tylko przez określone hosty i aplikacje

Opis: Nieograniczone klucze są niezabezpieczone, ponieważ mogą być wyświetlane publicznie, na przykład z poziomu przeglądarki, lub mogą być dostępne na urządzeniu, na którym znajduje się klucz. Zaleca się ograniczenie użycia klucza interfejsu API do zaufanych hostów, odwołań HTTP i aplikacji.

Poniżej przedstawiono zagrożenia bezpieczeństwa związane z używaniem kluczy INTERFEJSu API:

1. Klucze interfejsu API to proste zaszyfrowane ciągi
2. Klucze interfejsu API nie identyfikują użytkownika ani aplikacji wysyłającej żądanie interfejsu API
3. Klucze interfejsu API są zwykle dostępne dla klientów, co ułatwia odnajdywanie i kradzież klucza interfejsu API

W świetle tych potencjalnych zagrożeń firma Google zaleca użycie standardowego przepływu uwierzytelniania zamiast kluczy interfejsu API. Istnieją jednak ograniczone przypadki, w których klucze interfejsu API są bardziej odpowiednie. Jeśli na przykład istnieje aplikacja mobilna, która musi używać interfejsu API tłumaczenia w chmurze Google, ale w przeciwnym razie nie wymaga serwera zaplecza, klucze interfejsu API są najprostszym sposobem uwierzytelniania w tym interfejsie API.

Aby zmniejszyć wektory ataków, klucze API-Keys mogą być ograniczone tylko do zaufanych hostów, odwołań HTTP i aplikacji.

Ważność: Wysoka

Upewnij się, że klucze interfejsu API są obracane co 90 dni

Opis: Zaleca się obracanie kluczy interfejsu API co 90 dni.

Poniżej wymieniono zagrożenia bezpieczeństwa związane z używaniem kluczy INTERFEJSu API:

1. Klucze interfejsu API to proste zaszyfrowane ciągi
2. Klucze interfejsu API nie identyfikują użytkownika ani aplikacji wysyłającej żądanie interfejsu API
3. Klucze interfejsu API są zwykle dostępne dla klientów, co ułatwia odnajdywanie i kradzież klucza interfejsu API

Ze względu na potencjalne zagrożenia firma Google zaleca użycie standardowego przepływu uwierzytelniania zamiast kluczy interfejsu API. Istnieją jednak ograniczone przypadki, w których klucze interfejsu API są bardziej odpowiednie. Jeśli na przykład istnieje aplikacja mobilna, która musi używać interfejsu API tłumaczenia w chmurze Google, ale w przeciwnym razie nie wymaga serwera zaplecza, klucze interfejsu API są najprostszym sposobem uwierzytelniania w tym interfejsie API.

Gdy klucz zostanie skradziony, nie wygaśnie, co oznacza, że może być używany przez czas nieokreślony, chyba że właściciel projektu odwoła lub ponownie wygeneruje klucz. Obracanie kluczy interfejsu API spowoduje zmniejszenie możliwości użycia klucza dostępu skojarzonego z naruszonym lub zakończonym kontem.

Klucze interfejsu API należy obrócić, aby upewnić się, że nie można uzyskać dostępu do danych przy użyciu starego klucza, który mógł zostać utracony, złamany lub skradziony.

Ważność: Wysoka

Upewnij się, że klucze szyfrowania usługi KMS są obracane w ciągu 90 dni

Opis: Usługa Google Cloud usługa zarządzania kluczami przechowuje klucze kryptograficzne w strukturze hierarchicznej przeznaczonej do przydatnego i eleganckiego zarządzania kontrolą dostępu. Format harmonogramu rotacji zależy od używanej biblioteki klienta. W przypadku narzędzia wiersza polecenia gcloud następny czas rotacji musi być w formacie "ISO" lub "RFC3339", a okres rotacji musi być w postaci "INTEGER[UNIT],", gdzie jednostki mogą być jedną z sekund (s), minut (m), godzin (h) lub dni (d). Ustaw okres rotacji kluczy i czas rozpoczęcia. Klucz można utworzyć przy użyciu określonego "okresu rotacji", czyli czasu między automatycznym wygenerowaniem nowych wersji kluczy. Klucz można również utworzyć przy użyciu określonego czasu następnego obrotu. Klucz to nazwany obiekt reprezentujący "klucz kryptograficzny" używany do określonego celu. Materiał klucza, rzeczywiste bity używane do "szyfrowania", mogą zmieniać się wraz z upływem czasu, gdy tworzone są nowe wersje kluczy. Klucz służy do ochrony niektórych "corpus of data". Kolekcja plików może być zaszyfrowana przy użyciu tego samego klucza, a osoby z uprawnieniami "odszyfrowywania" tego klucza będą mogły odszyfrować te pliki. W związku z tym należy upewnić się, że "okres rotacji" jest ustawiony na określony czas.

Ważność: średni rozmiar

Upewnij się, że istnieje filtr metryk dzienników i alerty dla przypisań własności projektu/zmian

Opis: Aby zapobiec niepotrzebnym przypisaniom własności projektu do użytkowników/kont usług i dalszemu niewłaściwemu używaniu projektów i zasobów, należy monitorować wszystkie przypisania "role/właściciel". Członkowie (użytkownicy/konta usługi) z przypisaniem roli do roli pierwotnej "role/właściciel" są właścicielami projektów. Właściciel projektu ma wszystkie uprawnienia do projektu, do którego należy rola. Poniżej przedstawiono podsumowanie:

• Wszystkie uprawnienia przeglądarki dla wszystkich usług GCP w projekcie
• Uprawnienia do akcji modyfikujących stan wszystkich usług GCP w projekcie
• Zarządzanie rolami i uprawnieniami dla projektu i wszystkich zasobów w projekcie
• Skonfigurowanie rozliczeń dla projektu Udzielanie roli właściciela członkowi (użytkownik/konto usługi) umożliwi tym członkom modyfikowanie zasad zarządzania tożsamościami i dostępem (IAM). W związku z tym przyznaj rolę właściciela tylko wtedy, gdy członek ma uzasadniony cel zarządzania zasadami IAM. Jest to spowodowane tym, że zasady zarządzania dostępem i tożsamościami projektu zawierają poufne dane kontroli dostępu. Posiadanie minimalnego zestawu użytkowników, którzy mogą zarządzać zasadami zarządzania dostępem i tożsamościami, uprości wszelkie inspekcje, które mogą być konieczne. Własność projektu ma najwyższy poziom uprawnień w projekcie. Aby uniknąć nieuprawnionego użycia zasobów projektu, należy monitorować i otrzymywać alerty dla zainteresowanych adresatów za pomocą przypisywania/zmieniania własności projektu.
• Wysyłanie zaproszeń własności projektu
• Akceptacja/odrzucenie zaproszenia własności projektu przez użytkownika
• Dodawanie role\Owner do użytkownika/konta usługi
• Usuwanie użytkownika/konta usługi z role\Owner

Ważność: Niska

Upewnij się, że program Oslogin jest włączony dla projektu

Opis: Włączanie logowania systemu operacyjnego wiąże certyfikaty SSH z użytkownikami IAM i ułatwia efektywne zarządzanie certyfikatami SSH. Włączenie protokołu osLogin gwarantuje, że klucze SSH używane do nawiązywania połączenia z wystąpieniami są mapowane z użytkownikami usługi IAM. Odwołanie dostępu do użytkownika IAM spowoduje odwołanie wszystkich kluczy SSH skojarzonych z tym konkretnym użytkownikiem. Ułatwia scentralizowane i zautomatyzowane zarządzanie parami kluczy SSH, co jest przydatne w przypadku obsługi przypadków, takich jak reagowanie na naruszone pary kluczy SSH i/lub odwołanie użytkowników zewnętrznych/innych firm/dostawców. Aby dowiedzieć się, które wystąpienie powoduje złą kondycję projektu, zobacz zalecenie "Upewnij się, że usługa Oslogin jest włączona dla wszystkich wystąpień".

Ważność: średni rozmiar

Upewnij się, że program oslogin jest włączony dla wszystkich wystąpień

Opis: Włączanie logowania systemu operacyjnego wiąże certyfikaty SSH z użytkownikami IAM i ułatwia efektywne zarządzanie certyfikatami SSH. Włączenie protokołu osLogin gwarantuje, że klucze SSH używane do nawiązywania połączenia z wystąpieniami są mapowane z użytkownikami usługi IAM. Odwołanie dostępu do użytkownika IAM spowoduje odwołanie wszystkich kluczy SSH skojarzonych z tym konkretnym użytkownikiem. Ułatwia scentralizowane i zautomatyzowane zarządzanie parami kluczy SSH, co jest przydatne w przypadku obsługi przypadków, takich jak reagowanie na naruszone pary kluczy SSH i/lub odwołanie użytkowników zewnętrznych/innych firm/dostawców.

Ważność: średni rozmiar

Upewnij się, że rejestrowanie inspekcji w chmurze jest prawidłowo skonfigurowane we wszystkich usługach i wszystkich użytkowników z projektu

Opis: Zaleca się skonfigurowanie rejestrowania inspekcji w chmurze w celu śledzenia wszystkich działań administracyjnych i odczytu, zapisu dostępu do danych użytkownika.

Rejestrowanie inspekcji w chmurze obsługuje dwa dzienniki inspekcji dla każdego projektu, folderu i organizacji: Administracja aktywność i dostęp do danych.

1. Administracja Dzienniki aktywności zawierają wpisy dziennika dla wywołań interfejsu API lub innych akcji administracyjnych, które modyfikują konfigurację lub metadane zasobów. Administracja dzienniki inspekcji aktywności są włączone dla wszystkich usług i nie można ich skonfigurować.
2. Wywołania interfejsu API rekordów dzienników inspekcji dostępu do danych, które tworzą, modyfikują lub odczytują dane dostarczone przez użytkownika. Są one domyślnie wyłączone i powinny być włączone. Istnieją trzy rodzaje informacji dziennika inspekcji dostępu do danych:

• Administracja odczytu: operacje rekordów odczytujące metadane lub informacje o konfiguracji. Administracja dzienniki inspekcji aktywności rejestrują zapisy metadanych i informacji o konfiguracji, których nie można wyłączyć.
• Odczyt danych: rejestruje operacje odczytujące dane dostarczone przez użytkownika.
• Zapis danych: rejestruje operacje zapisujące dane dostarczone przez użytkownika.

Zaleca się skonfigurowanie efektywnej domyślnej konfiguracji inspekcji w taki sposób, aby:

1. wartość logtype jest ustawiona na DATA_READ (w celu rejestrowania śledzenia aktywności użytkowników) i DATA_WRITES (w celu rejestrowania zmian/manipulowania danymi użytkownika).
2. Konfiguracja inspekcji jest włączona dla wszystkich usług obsługiwanych przez funkcję dzienników inspekcji dostępu do danych.
3. Dzienniki powinny być przechwytywane dla wszystkich użytkowników, czyli nie ma wykluczonych użytkowników w żadnej z sekcji konfiguracji inspekcji. Zapewni to zastąpienie konfiguracji inspekcji nie będzie sprzeczne z wymaganiem.

Ważność: średni rozmiar

Upewnij się, że klucz kryptograficzny usługi KmS w chmurze nie jest anonimowy ani publicznie dostępny

Opis: Zaleca się, aby zasady zarządzania dostępem i tożsamościami w usłudze Cloud KMS "cryptokeys" ograniczały dostęp anonimowy i/lub publiczny. Przyznawanie uprawnień "allUsers" lub "allAuthenticatedUsers" umożliwia każdemu użytkownikowi dostęp do zestawu danych. Taki dostęp może nie być pożądany, jeśli poufne dane są przechowywane w lokalizacji. W takim przypadku upewnij się, że dostęp anonimowy i/lub publiczny do chmury KMS "cryptokey" nie jest dozwolony.

Ważność: Wysoka

Upewnij się, że używane są poświadczenia logowania firmowego

Opis: Użyj poświadczeń logowania firmowego zamiast kont osobistych, takich jak konta Gmail. Zaleca się używanie w pełni zarządzanych firmowych kont Google w celu zwiększenia widoczności, inspekcji i kontrolowania dostępu do zasobów platformy Cloud Platform. Konta Gmail oparte poza organizacją użytkownika, takie jak konta osobiste, nie powinny być używane do celów biznesowych.

Ważność: Wysoka

Upewnij się, że użytkownicy IAM nie mają przypisanych ról twórcy tokenu konta usługi lub konta usługi na poziomie projektu

Opis: Zaleca się przypisanie ról "Użytkownik konta usługi (iam.serviceAccountUser)" i "Twórca tokenu konta usługi (iam.serviceAccountTokenCreator)" do użytkownika dla określonego konta usługi, a nie przypisywania roli do użytkownika na poziomie projektu. Konto usługi to specjalne konto Google, które należy do aplikacji lub maszyny wirtualnej, zamiast do pojedynczego użytkownika końcowego. Aplikacja/wystąpienie maszyny wirtualnej używa konta usługi do wywoływania interfejsu API Google usługi, aby użytkownicy nie byli bezpośrednio zaangażowani. Oprócz tożsamości konto usługi jest zasobem, do którego są dołączone zasady zarządzania dostępem i tożsamościami. Te zasady określają, kto może używać konta usługi. Użytkownicy z rolami zarządzania dostępem i tożsamościami w celu zaktualizowania wystąpień aparatu aplikacji i aparatu obliczeniowego (takich jak narzędzie wdrażania aparatu aplikacji lub wystąpienie obliczeniowe Administracja) mogą skutecznie uruchamiać kod jako konta usług używane do uruchamiania tych wystąpień i pośrednio uzyskiwać dostęp do wszystkich zasobów, do których mają dostęp konta usług. Podobnie dostęp SSH do wystąpienia aparatu obliczeniowego może również zapewnić możliwość wykonywania kodu jako tego wystąpienia/konta usługi. W zależności od potrzeb biznesowych może istnieć wiele kont usług zarządzanych przez użytkownika skonfigurowanych dla projektu. Przyznawanie ról "iam.serviceAccountUser" lub "iam.serviceAserviceAccountTokenCreatorccountUser" użytkownikowi projektu daje użytkownikowi dostęp do wszystkich kont usług w projekcie, w tym kont usług, które mogą zostać utworzone w przyszłości. Może to spowodować podniesienie uprawnień przy użyciu kont usług i odpowiadających im "wystąpień aparatu obliczeniowego". Aby zaimplementować najlepsze rozwiązania dotyczące "najmniejszych uprawnień", użytkownicy IAM nie powinni mieć przypisanych ról "Użytkownik konta usługi" ani "Twórca tokenu konta usługi" na poziomie projektu. Zamiast tego te role powinny być przypisane do użytkownika dla określonego konta usługi, co daje użytkownikowi dostęp do konta usługi. "Użytkownik konta usługi" umożliwia użytkownikowi powiązanie konta usługi z długotrwałą usługą zadań, natomiast rola "Twórca tokenu konta usługi" umożliwia użytkownikowi bezpośrednie personifikację (lub potwierdzenie) tożsamości konta usługi.

Ważność: średni rozmiar

Upewnij się, że separacja obowiązków jest wymuszana podczas przypisywania ról powiązanych z usługą KMS do użytkowników

Opis: Zaleca się, aby zasada "Separacja obowiązków" była wymuszana podczas przypisywania ról powiązanych z usługą KMS do użytkowników. Wbudowana/wstępnie zdefiniowana rola IAM "Cloud KMS Administracja" umożliwia użytkownikowi/tożsamości tworzenie, usuwanie kont usług i zarządzanie nimi. Wbudowana/wstępnie zdefiniowana rola IAM "Cloud KMS CryptoKey Encrypter/Decrypter" umożliwia użytkownikowi/tożsamości (z odpowiednimi uprawnieniami do odpowiednich zasobów) szyfrowanie i odszyfrowywanie danych magazynowanych przy użyciu kluczy szyfrowania. Wbudowana/wstępnie zdefiniowana rola IAM Cloud KMS CryptoKey Encrypter umożliwia użytkownikowi/tożsamości (z odpowiednimi uprawnieniami do odpowiednich zasobów) szyfrowanie danych magazynowanych przy użyciu kluczy szyfrowania. Wbudowana/wstępnie zdefiniowana rola IAM "Cloud KMS CryptoKey Decrypter" umożliwia użytkownikowi/tożsamości (z odpowiednimi uprawnieniami do odpowiednich zasobów) odszyfrowywanie danych magazynowanych przy użyciu kluczy szyfrowania. Rozdzielenie obowiązków jest pojęciem zapewnienia, że jedna osoba nie ma wszystkich niezbędnych uprawnień, aby móc wykonać złośliwe działania. W usłudze KMS w chmurze może to być akcja, taka jak użycie klucza do uzyskiwania dostępu do danych i odszyfrowywania danych, do których użytkownik zwykle nie powinien mieć dostępu. Rozdzielenie obowiązków to kontrola biznesowa zwykle używana w większych organizacjach, która pomaga uniknąć zdarzeń i błędów związanych z bezpieczeństwem lub prywatnością. Jest to uważane za najlepsze rozwiązanie. Żaden użytkownik nie powinien mieć Administracja usługi KmS w chmurze i dowolnego z ról "Cloud KMS CryptoKey Encrypter/Decrypter", "Cloud KMS CryptoKey Encrypter", "Cloud KMS CryptoKey Decrypter" przypisanych w tym samym czasie.

Ważność: Wysoka

Upewnij się, że separacja obowiązków jest wymuszana podczas przypisywania ról powiązanych z kontem usługi do użytkowników

Opis: Zaleca się, aby zasada "Separacja obowiązków" była wymuszana podczas przypisywania ról związanych z kontem usługi do użytkowników. Wbudowana/wstępnie zdefiniowana rola IAM "Administrator konta usługi" umożliwia użytkownikowi/tożsamości tworzenie, usuwanie kont usług i zarządzanie nimi. Wbudowana/wstępnie zdefiniowana rola IAM "Użytkownik konta usługi" umożliwia użytkownikowi/tożsamości (z odpowiednimi uprawnieniami w usłudze Compute i App Engine) przypisywanie kont usług do aplikacji/wystąpień obliczeniowych. Rozdzielenie obowiązków jest pojęciem zapewnienia, że jedna osoba nie ma wszystkich niezbędnych uprawnień, aby móc wykonać złośliwe działania. W usłudze Cloud IAM — konta usług mogą być akcją, taką jak używanie konta usługi do uzyskiwania dostępu do zasobów, do których użytkownik zwykle nie powinien mieć dostępu. Rozdzielenie obowiązków to kontrola biznesowa zwykle używana w większych organizacjach, która pomaga uniknąć zdarzeń i błędów związanych z bezpieczeństwem lub prywatnością. Jest to uważane za najlepsze rozwiązanie. Żaden użytkownik nie powinien mieć przypisanych ról "Konto usługi Administracja" i "Użytkownik konta usługi".

Ważność: średni rozmiar

Upewnij się, że konto usługi nie ma Administracja uprawnień

Opis: Konto usługi to specjalne konto Google, które należy do aplikacji lub maszyny wirtualnej, a nie do pojedynczego użytkownika końcowego. Aplikacja używa konta usługi do wywoływania interfejsu API Google usługi, aby użytkownicy nie byli bezpośrednio zaangażowani. Zaleca się, aby nie używać dostępu administratora do usługi ServiceAccount. Konta usług reprezentują zabezpieczenia na poziomie usługi zasobów (aplikacji lub maszyny wirtualnej), które mogą być określane przez przypisane do niej role. Rejestrowanie konta usługi przy użyciu praw Administracja zapewnia pełny dostęp do przypisanej aplikacji lub maszyny wirtualnej. Właściciel dostępu usługi ServiceAccount może wykonywać krytyczne akcje, takie jak usuwanie, aktualizowanie ustawień zmiany itp. bez interwencji użytkownika. Z tego powodu zaleca się, aby konta usług nie miały Administracja praw.

Ważność: średni rozmiar

Upewnij się, że ujścia są skonfigurowane dla wszystkich wpisów dziennika

Opis: Zaleca się utworzenie ujścia, które spowoduje wyeksportowanie kopii wszystkich wpisów dziennika. Może to pomóc agregować dzienniki z wielu projektów i eksportować je do zarządzania informacjami i zdarzeniami zabezpieczeń (SIEM). Wpisy dziennika są przechowywane w rejestrowaniu usługi Stackdriver. Aby zagregować dzienniki, wyeksportuj je do rozwiązania SIEM. Aby zachować je dłużej, zaleca się skonfigurowanie ujścia dziennika. Eksportowanie obejmuje napisanie filtru, który wybiera wpisy dziennika do wyeksportowania i wybiera miejsce docelowe w usłudze Cloud Storage, BigQuery lub Cloud Pub/Sub. Filtr i miejsce docelowe są przechowywane w obiekcie nazywanym ujściem. Aby upewnić się, że wszystkie wpisy dziennika są eksportowane do ujścia, upewnij się, że nie skonfigurowano filtru dla ujścia. Ujścia można tworzyć w projektach, organizacjach, folderach i kontach rozliczeniowych.

Ważność: Niska

Upewnij się, że istnieje filtr metryki dziennika i alerty dotyczące zmian konfiguracji inspekcji

Opis: Usługi Google Cloud Platform (GCP) zapisują wpisy dziennika inspekcji w dziennikach Administracja aktywność i dostęp do danych, aby uzyskać odpowiedzi na pytania, "kto zrobił co, gdzie i kiedy?" w projektach GCP. Informacje dotyczące rejestrowania inspekcji w chmurze obejmują tożsamość obiektu wywołującego interfejs API, czas wywołania interfejsu API, źródłowy adres IP obiektu wywołującego interfejs API, parametry żądania i elementy odpowiedzi zwracane przez usługi GCP. Rejestrowanie inspekcji w chmurze zapewnia historię wywołań interfejsu API GCP dla konta, w tym wywołań interfejsu API wykonanych za pośrednictwem konsoli, zestawów SDK, narzędzi wiersza polecenia i innych usług GCP. Administracja dzienniki aktywności i dostępu do danych generowane przez rejestrowanie inspekcji w chmurze umożliwiają analizę zabezpieczeń, śledzenie zmian zasobów i inspekcję zgodności. Skonfigurowanie filtru metryki i alertów dotyczących zmian konfiguracji inspekcji zapewnia utrzymanie zalecanego stanu konfiguracji inspekcji, dzięki czemu wszystkie działania w projekcie są w stanie inspekcji w dowolnym momencie.

Ważność: Niska

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

Opis: Zaleca się ustanowienie filtru metryki i alarmu w przypadku zmian w tworzeniu, usuwaniu i aktualizowaniu działań związanych z tworzeniem, usuwaniem i aktualizowaniem ról zarządzania tożsamościami i dostępem. Zarządzanie dostępem i tożsamościami w chmurze Firmy Google udostępnia wstępnie zdefiniowane role, które zapewniają szczegółowy dostęp do określonych zasobów platformy Google Cloud Platform i uniemożliwiają niepożądany dostęp do innych zasobów. Jednak w celu zaspokojenia potrzeb specyficznych dla organizacji zarządzanie dostępem i tożsamościami w chmurze zapewnia również możliwość tworzenia ról niestandardowych. Właściciele i administratorzy projektu z rolą Administracja istratora organizacji lub rola Administracja istratora IAM mogą tworzyć role niestandardowe. Monitorowanie działań związanych z tworzeniem, usuwaniem i aktualizowaniem ról pomoże zidentyfikować dowolną rolę z nadmiernymi uprawnieniami na wczesnym etapie.

Ważność: Niska

Upewnij się, że klucze zewnętrzne/zarządzane przez użytkownika dla kont usług są obracane co 90 dni lub mniej

Opis: Klucze konta usługi składają się z identyfikatora klucza (Private_key_Id) i klucza prywatnego, które są używane do podpisywania żądań programowych wysyłanych do usług w chmurze Google dostępnych dla tego konkretnego konta usługi. Zaleca się regularne obracanie wszystkich kluczy konta usługi. Rotacja kluczy konta usługi spowoduje zmniejszenie możliwości użycia klucza dostępu skojarzonego z naruszonym lub zakończonym kontem. Klucze konta usługi powinny być obracane w celu zapewnienia, że nie można uzyskać dostępu do danych przy użyciu starego klucza, który mógł zostać utracony, złamany lub skradziony. Każde konto usługi jest skojarzone z parą kluczy zarządzaną przez platformę Google Cloud Platform (GCP). Jest ona używana do uwierzytelniania między usługami w usłudze GCP. Google codziennie obraca klucze. GCP udostępnia opcję tworzenia co najmniej jednej pary kluczy zarządzanych przez użytkownika (nazywanej również parami kluczy zewnętrznych) do użycia spoza GCP (na przykład do użycia z domyślnymi poświadczeniami aplikacji). Po utworzeniu nowej pary kluczy użytkownik musi pobrać klucz prywatny (który nie jest zachowywany przez firmę Google).

W przypadku kluczy zewnętrznych użytkownicy są odpowiedzialni za zabezpieczanie klucza prywatnego i inne operacje zarządzania, takie jak rotacja kluczy. Klucze zewnętrzne można zarządzać za pomocą interfejsu API zarządzania dostępem i tożsamościami, narzędzia wiersza polecenia usługi gcloud lub strony Konta usług w konsoli Google Cloud Platform Console.

GCP ułatwia do 10 kluczy kont usług zewnętrznych na konto usługi w celu ułatwienia rotacji kluczy.

Ważność: średni rozmiar

Pulpit nawigacyjny sieci Web GKE powinien być wyłączony

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

Ważność: Wysoka

Starsza wersja autoryzacji powinna być wyłączona w klastrach GKE

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

Ważność: Wysoka

Rola IAM usługi Redis nie powinna być przypisana na poziomie organizacji lub folderu

Opis: To zalecenie ocenia zasady zezwalania na zarządzanie dostępem i tożsamościami w metadanych zasobów dla podmiotów zabezpieczeń przypisanych ról/redis.admin, roles/redis.editor, roles/redis.viewer na poziomie organizacji lub folderu.

Ważność: Wysoka

Konta usług powinny mieć ograniczony dostęp do projektu w klastrze

Opis: To zalecenie ocenia właściwość konfiguracji puli węzłów, aby sprawdzić, czy nie określono konta usługi lub czy jest używane domyślne konto usługi.

Ważność: Wysoka

Użytkownicy powinni mieć dostęp do najniższych uprawnień z szczegółowymi rolami zarządzania dostępem i tożsamościami

Opis: To zalecenie ocenia zasady zarządzania dostępem i tożsamościami w metadanych zasobów dla wszystkich podmiotów zabezpieczeń przypisanych ról/właściciela, ról/składnika zapisywania lub ról/czytelnika.

Ważność: Wysoka

Super Tożsamości w środowisku GCP powinny zostać usunięte (wersja zapoznawcza)

Opis: Super tożsamość ma zaawansowany zestaw uprawnień. Superadministratorzy to tożsamości człowieka lub obciążenia, które mają dostęp do wszystkich uprawnień i wszystkich zasobów. Mogą tworzyć i modyfikować ustawienia konfiguracji w usłudze, dodawać lub usuwać tożsamości oraz uzyskiwać dostęp do danych, a nawet je usuwać. Niemonitorowane tożsamości te stanowią poważne ryzyko nieprawidłowego użycia uprawnień w przypadku naruszenia zabezpieczeń.

Ważność: Wysoka

Nieużywane tożsamości w środowisku GCP powinny zostać usunięte (wersja zapoznawcza)

Opis: Konieczne jest zidentyfikowanie nieużywanych tożsamości, ponieważ stanowią one znaczne zagrożenie bezpieczeństwa. Te tożsamości często obejmują złe rozwiązania, takie jak nadmierne uprawnienia i niezarządzane klucze, które pozostawiają organizacje otwarte na niewłaściwe użycie poświadczeń lub wykorzystanie i zwiększa obszar ataków zasobu. Nieaktywne tożsamości to ludzkie i nieludzkie jednostki, które nie wykonały żadnej akcji na żadnym zasobie w ciągu ostatnich 90 dni. Klucze konta usługi mogą stać się zagrożeniem bezpieczeństwa, jeśli nie są starannie zarządzane.

Ważność: średni rozmiar

Tożsamości z nadmierną aprowizowaną usługą GCP powinny mieć tylko niezbędne uprawnienia (wersja zapoznawcza)

Opis: Zaaprowizowana aktywna tożsamość to tożsamość, która ma dostęp do uprawnień, które nie zostały użyte. Zaaprowizowane aktywne tożsamości, zwłaszcza w przypadku kont nieludzkich, które mają bardzo zdefiniowane akcje i obowiązki, mogą zwiększyć promień wybuchu w przypadku naruszenia bezpieczeństwa użytkownika, klucza lub zasobu Zasada najniższych uprawnień stwierdza, że zasób powinien mieć dostęp tylko do dokładnych zasobów, których potrzebuje w celu funkcjonowania. Ta zasada została opracowana w celu rozwiązania ryzyka naruszenia zabezpieczeń tożsamości, które udzielają atakującemu dostępu do szerokiego zakresu zasobów.

Ważność: średni rozmiar

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 Uwaga: Aby w pełni przechwycić system DNS, zapora musi blokować ruch wychodzący UDP/53 (DNS) i TCP/443 (DNS za pośrednictwem protokołu HTTPS), aby zapobiec używaniu 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. Podczas określania ź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. Podczas włączania protokołu DNSSEC dla strefy zarządzanej lub tworzenia strefy zarządzanej przy użyciu protokołu 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. Podczas włączania protokołu DNSSEC dla strefy zarządzanej lub tworzenia 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. Podczas określania ź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 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

Powiązana zawartość

• Połączenie projektów GCP do Microsoft Defender dla Chmury
• Co to są zasady zabezpieczeń, inicjatywy i zalecenia?
• Przegląd rekomendacji dotyczących zabezpieczeń