Kontrola dostępu S3: zasady bucketów i ACL

S3 oferuje kilka nakładających się mechanizmów kontroli dostępu: zasady IAM (oparte na tożsamości, określające działania dozwolone podmiotom), zasady bucketu (oparte na zasobach zasady JSON dotyczące bucketa), listy kontroli dostępu (ACL) (starszy mechanizm przyznawania uprawnień dla poszczególnych obiektów lub bucketów) oraz S3 Block Public Access (nadpisanie na poziomie konta lub bucketa, które blokuje cały publiczny dostęp niezależnie od innych zasad). Obecnie w większości przypadków zalecanym rozwiązaniem jest połączenie zasad bucketu z funkcją Block Public Access — listy ACL są uznawane za mechanizm starszego typu.

Polityka bucketu to dokument JSON dołączony bezpośrednio do bucketu S3. Określa, które podmioty (użytkownicy IAM, role, konta AWS, usługi lub użytkownicy publiczni) mogą wykonywać które działania na których zasobach (bucketu lub określonych prefiksach kluczy). Polityki bucketów obsługują dostęp między kontami bez konieczności używania ról IAM: można bezpośrednio w polityce bucketu przyznać roli IAM z innego konta AWS dostęp do odczytu określonych obiektów. Każdy bucket może mieć jedną politykę, której maksymalny rozmiar wynosi 20 KB.

Aby udostępniać publiczne treści (np. zasoby statycznej witryny internetowej lub publiczne zestawy danych), można udostępnić obiekty do odczytu publicznego za pomocą polityki bucketu. Najpierw należy wyłączyć Block Public Access na poziomie bucketu, a następnie dodać do polityki bucketu instrukcję z elementami Principal: '*' i Action: s3:GetObject. Wymagane jest zarówno wyłączenie ustawienia Block Public Access, jak i użycie zezwolenia Allow w polityce bucketu — włączenie tylko jednego z nich nie zadziała. Zasób Resource należy zawsze ograniczać do określonego prefiksu, zamiast obejmować nim cały bucket, chyba że celowo chcą Państwo udostępnić publicznie wszystkie obiekty.

S3 Block Public Access to mechanizm ochronny z czterema ustawieniami, które zastępują polityki bucketów i listy ACL: BlockPublicAcls (odrzuca żądania ustawienia publicznych list ACL), IgnorePublicAcls (ignoruje istniejące publiczne listy ACL), BlockPublicPolicy (odrzuca polityki bucketów przyznające dostęp publiczny) oraz RestrictPublicBuckets (ogranicza dostęp na podstawie publicznej polityki). Wszystkie cztery ustawienia są domyślnie włączone. Block Public Access można także włączyć na poziomie konta, blokując dostęp publiczny dla wszystkich bucketów niezależnie od ich indywidualnych ustawień — jest to idealne rozwiązanie zapobiegające przypadkowemu ujawnieniu danych.

Listy ACL S3 to pierwotny mechanizm kontroli dostępu, starszy od IAM. Lista ACL przyznaje wstępnie zdefiniowane uprawnienia (READ, WRITE, FULL_CONTROL) kontom AWS lub predefiniowanym grupom (wszyscy użytkownicy, uwierzytelnieni użytkownicy AWS, usługa dostarczania logów). Listy ACL można stosować na poziomie bucketu lub pojedynczego obiektu. Obecnie AWS zaleca wyłączenie list ACL (ustawienie S3 „Bucket Owner Enforced” sprawia, że właściciel bucketu staje się właścicielem wszystkich obiektów, wyłączając listy ACL) oraz używanie zamiast nich polityk bucketów i IAM. Listy ACL nadal są sprawdzane na egzaminie SAA-C03 jako koncepcja starszego typu.

Podczas udostępniania treści S3 za pośrednictwem CloudFront bucket powinien pozostać prywatny, a CloudFront musi mieć możliwość pobierania obiektów. Należy użyć Origin Access Control (OAC) — nowoczesnego zamiennika Origin Access Identity (OAI). OAC tworzy tożsamość CloudFront, której w polityce bucketu przyznają Państwo uprawnienie s3:GetObject, pozostawiając włączoną funkcję Block Public Access. Dzięki temu użytkownicy muszą korzystać z CloudFront (w celu buforowania, użycia WAF i HTTPS) i nie mogą uzyskiwać bezpośredniego dostępu do bucketu. Jest to typowy bezpieczny wzorzec architektury omawiany na egzaminie SAA-C03.

Istnieją dwa sposoby przyznania innemu kontu AWS dostępu do bucketu S3. Opcja 1 — polityka bucketu: należy dodać instrukcję z ARN zewnętrznego konta jako elementem Principal oraz wymaganymi działaniami S3. Użytkownicy i role IAM zewnętrznego konta nadal potrzebują uprawnień IAM do wywoływania S3, a polityka bucketu musi dodatkowo przyznać im zezwolenie Allow. Opcja 2 — rola IAM z polityką zaufania: należy utworzyć na swoim koncie rolę, której ufa zewnętrzne konto; tożsamości zewnętrznego konta przyjmują tę rolę i uzyskują uprawnienia do bucketu. Polityka bucketu jest prostsza w scenariuszach dostępu tylko do odczytu, natomiast role lepiej sprawdzają się w dostępie operacyjnym.

Cross-Origin Resource Sharing (CORS) umożliwia aplikacji internetowej hostowanej w jednej domenie wykonywanie żądań JavaScript fetch do bucketu S3 znajdującego się w innej domenie. Bez konfiguracji CORS przeglądarki blokują takie żądania ze względów bezpieczeństwa. Do bucketu należy dodać konfigurację CORS określającą dozwolone źródła, metody HTTP i nagłówki. CORS jest często potrzebny, gdy aplikacja React SPA hostowana w domenie example.com pobiera obrazy lub pliki bezpośrednio z adresu URL bucketu S3.

Wstępnie podpisany adres URL zapewnia ograniczony czasowo dostęp do prywatnego obiektu S3 (w celu wykonania operacji GET lub PUT) bez zmiany uprawnień bucketu ani obiektu. Adres URL zawiera poświadczenia i czas wygaśnięcia — każda osoba posiadająca ten adres może uzyskać dostęp do obiektu do chwili jego wygaśnięcia. Wstępnie podpisanych adresów URL należy używać, aby umożliwić uwierzytelnionym użytkownikom aplikacji pobieranie prywatnych plików, pozwolić klientom przesyłać pliki bezpośrednio do S3 z pominięciem backendu lub tymczasowo udostępniać raporty. Okres ważności może wynosić od 1 sekundy do 7 dni (w przypadku używania tymczasowych poświadczeń STS maksymalny czas wynosi 12 godzin).

Warunki polityki bucketu pozwalają dodać zabezpieczenia zależne od kontekstu. Typowe wzorce to: aws:SourceIp ogranicza dostęp do określonych zakresów adresów IP (np. punktów końcowych VPC lub sieci firmowych); aws:SecureTransport: true wymusza używanie HTTPS, odrzucając żądania przesyłane przez HTTP (jest to najlepsza praktyka dla wszystkich bucketów przechowujących poufne dane); s3:x-amz-server-side-encryption wymusza szyfrowanie po stronie serwera podczas przesyłania obiektów; a aws:PrincipalOrgID ogranicza dostęp do podmiotów w obrębie organizacji AWS, zapobiegając eksfiltracji danych do zewnętrznych kont.

Domyślnie instancje EC2 w prywatnej podsieci uzyskują dostęp do S3 przez internet (za pośrednictwem bramy NAT), co generuje koszty NAT i naraża ruch na dostęp przez publiczny internet. Bramy S3 Gateway Endpoints zapewniają prywatną łączność z S3 z poziomu VPC bez bramy NAT i bez dodatkowych opłat. Bramę Gateway Endpoint należy dodać do tabeli routingu; ruch do S3 jest automatycznie kierowany przez prywatną sieć AWS. Można również dodać do polityki bucketu warunki z użyciem aws:SourceVpce, aby ograniczyć dostęp wyłącznie do żądań przechodzących przez ten punkt końcowy.

Sprawdź swoją znajomość zagadnień AWS Solutions Architect (SAA-C03) omówionych w tej lekcji.

W tej lekcji nauczyli się Państwo, że: polityki bucketów to dokumenty JSON oparte na zasobach, które kontrolują dostęp między kontami i dostęp usług do S3, S3 Block Public Access to mechanizm ochronny zastępujący inne ustawienia i zapobiegający przypadkowemu ujawnieniu danych, a wstępnie podpisane adresy URL, punkty końcowe VPC i konfiguracje CORS obsługują określone wzorce dostępu w bezpieczny sposób. W następnej części omówimy przechowywanie wersji w S3, MFA Delete i replikację.