Zespół ds. bezpieczeństwa tworzy rozwiązanie alertowania oparte na Amazon EventBridge, aby wykrywać nowe obiekty Amazon S3 z publicznym dostępem oraz wszelkie zmiany w politykach lub ustawieniach zasobników S3, które sprawiają, że dane stają się publiczne. EventBridge nasłuchuje określonych zdarzeń API AWS CloudTrail i natychmiast wysyła szczegóły do zespołu za pośrednictwem Amazon Simple Notification Service (Amazon SNS). Zespół skonfigurował EventBridge tak, aby dopasowywał zdarzenia s3:PutObjectAcl, s3:DeleteBucketPolicy i s3:PutBucketPolicy. Podczas testów (z włączonymi zdarzeniami zarządzania CloudTrail w tym samym regionie i zweryfikowanym wzorcem zdarzeń) EventBridge wyzwala się dla s3:DeleteBucketPolicy i s3:PutBucketPolicy, ale nie dla s3:PutObjectAcl. Zespół musi zapewnić, że s3:PutObjectAcl generuje zdarzenie EventBridge bez powodowania fałszywych powiadomień. Co powinien zrobić?

Poprawna odpowiedź to włączenie logowania zdarzeń danych CloudTrail dla operacji odczytu i zapisu obiektów S3. Domyślnie CloudTrail rejestruje tylko zdarzenia zarządzania, takie jak s3:DeleteBucketPolicy i s3:PutBucketPolicy, które dotyczą zasobnika. Operacja s3:PutObjectAcl jest zdarzeniem na poziomie obiektu, które CloudTrail rejestruje jako zdarzenie danych. Aby EventBridge mógł wykryć to zdarzenie, CloudTrail musi być skonfigurowany do rejestrowania zdarzeń danych. Pozostałe opcje są nieprawidłowe: Aktualizacja reguły EventBridge w celu użycia źródła zdarzeń Amazon S3 i wybranie All Events lub Bucket Level Operations jako typu zdarzenia nie rozwiąże problemu, ponieważ EventBridge nadal będzie polegać na CloudTrail w celu dostarczania zdarzeń, a CloudTrail nie będzie rejestrować s3:PutObjectAcl bez włączonych zdarzeń danych. Włączenie AWS CloudTrail Insights jest przeznaczone do wykrywania nietypowej aktywności API, a nie do rejestrowania konkretnych zdarzeń na poziomie obiektu.