Deweloperzy używają instancji Linux EC2 jako hostów bastionowych z dostępem SSH ograniczonym przez reguły grup bezpieczeństwa do określonych adresów IP. Zespół bezpieczeństwa musi zostać powiadomiony, jeśli te reguły grup bezpieczeństwa zostaną zmienione, aby zezwolić na SSH z dowolnego adresu IP (0.0.0.0/0). Co inżynier DevOps powinien wdrożyć, aby spełnić ten wymóg?

Prawidłowa odpowiedź to utworzenie reguły AWS Config z zarządzaną regułą restricted-ssh. Ta reguła jest specjalnie zaprojektowana do wykrywania grup bezpieczeństwa, które zezwalają na nieograniczony ruch SSH (0.0.0.0/0), co jest dokładnie wymaganiem w scenariuszu. AWS Config monitoruje zmiany w zasobach i ocenia je pod kątem zgodności z regułami. Gdy reguła zostanie naruszona, AWS Config może wywołać akcję, taką jak wysłanie powiadomienia do tematu Amazon SNS, co spełnia wymóg zespołu bezpieczeństwa. Pozostałe opcje są nieprawidłowe: Amazon EventBridge ze źródłem aws.cloudtrail i nazwą zdarzenia AuthorizeSecurityGroupIngress powiadomi o każdej zmianie reguł, a nie tylko o tej konkretnej niezgodności z 0.0.0.0/0. Wymagałoby to dodatkowej logiki do filtrowania zdarzeń. Amazon GuardDuty koncentruje się na wykrywaniu zagrożeń i nietypowych zachowań, a nie na ocenie zgodności konfiguracji grup bezpieczeństwa. Wyniki GuardDuty nie obejmują bezpośrednio oceny reguł 0.0.0.0/0 dla SSH. Amazon Inspector służy do oceny podatności i niezgodności z najlepszymi praktykami na instancjach EC2, a nie do monitorowania konfiguracji grup bezpieczeństwa pod kątem konkretnych reguł dostępu.