Polityki IAM, Bucket oraz ACL! (Kontrolowanie dostępu do zasobów S3)
W poprzednich postach AWS wyjaśnił, jak pisać polityki S3 dla konsoli i jak używać zmiennych zasad do przyznawania dostępu do folderów S3 specyficznych dla użytkownika.
W tym tygodniu omówimy inny często poruszany temat: rozróżnienie między politykami IAM, politykami kontenerów S3, listami kontroli dostępu S3 ACL oraz kiedy należy ich używać. Wszystkie są częścią zestawu narzędzi kontroli dostępu AWS, ale różnią się sposobem ich używania.
Polityki IAM vs. polityki kontenerów S3
Polityki IAM określają, jakie akcje są dozwolone lub zabronione na danych zasobach AWS. Polityki IAM możemy dołączać do uprawnień użytkowników, grup lub ról, które następnie podlegają zdefiniowanym uprawnieniom. Innymi słowy, polityki IAM określają, co zleceniodawca może zrobić w środowisku AWS.
Z drugiej strony polityki dotyczące bucketów S3 są dołączane tylko do zasobów S3. Polityki kontenera S3 określają, jakie akcje są dozwolone lub zabronione dla których podmiotów (np. zezwalaj użytkownikowi Alice na WSTAWIANIE, ale nie na USUWANIE obiektów w buckecie). Polityki bucketów S3 są rodzajem listy kontroli dostępu lub ACL („ACL” w sensie ogólnym, którego nie należy mylić z listami ACL S3, która jest osobną funkcją S3 omówioną w dalszej części tego postu).
Uwaga: Polityki kontenerów S3 dołącza się na poziomie bucketu (tj. Nie można dołączyć polityk kontera do obiektu S3), ale uprawnienia określone w polityce kontera dotyczą wszystkich obiektów w zasobniku.
Polityki IAM oraz polityki kontenerów S3 są używane do kontroli dostępu i są napisane w formacie JSON przy użyciu języka polityk dostępu AWS, więc można je pomylić. Przykładowe polityki każdego typu:
Przykład polityki S3
This S3 bucket policy enables the root account 111122223333 and the IAM user Alice under that account to perform any S3 operation on the bucket named “my_bucket”, as well as that bucket’s contents.
Ta polityka kontenera S3 umożliwia kontu głównemu 111122223333 i użytkownikowi Alice w ramach tego konta wykonywanie dowolnej operacji S3 na buckecie o nazwie „my_bucket”, a także na jego zawartości.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": ["arn:aws:iam::111122223333:user/Alice",
"arn:aws:iam::111122223333:root"]
},
"Action": "s3:*",
"Resource": ["arn:aws:s3:::my_bucket",
"arn:aws:s3:::my_bucket/*"]
}
]
}
Przykład polityki IAM
Ta polityka uprawnień przyznaje jednostce uprawnień IAM (użytkownikowi, grupie lub roli), do której jest dołączona, uprawnienie do wykonywania dowolnej operacji S3 na kontenerze o nazwie „my_bucket”, a także na jego zawartości.
{
"Version": "2012-10-17",
"Statement":[{
"Effect": "Allow",
"Action": "s3:*",
"Resource": ["arn:aws:s3:::my_bucket",
"arn:aws:s3:::my_bucket/*"]
}
]
}
Należy zauważyć, że polityka kontenera S3 zawiera element „Principal”, który zawiera listę podmiotów głównych, dla których polityka kontenera kontroluje dostęp. Element „Principal” jest niepotrzebny w polityce IAM, ponieważ podmiot jest domyślnie jednostką, do której jest dołączona polityka IAM.
Polityki kontenera S3 (jak sugeruje nazwa) kontrolują tylko dostęp do kontenerów S3, podczas gdy polityki IAM mogą określać prawie każdą akcję AWS. Jedną z przydatnych rzeczy w AWS jest to, że w rzeczywistości można jednocześnie stosować zarówno polityki IAM, jak i polityki zasobów S3, przy czym ostateczną autoryzacją jest połączenie wszystkich uprawnień o najniższych uprawnieniach (więcej na ten temat w sekcji poniżej zatytułowanej „Jak działa autoryzacja z wieloma mechanizmami kontroli dostępu?”).
Kiedy używać polityk IAM, a kiedy polityk S3
Można użyć polityk IAM, jeśli:
- Należy kontrolować dostęp do usług AWS innych niż S3. Polityki IAM będą łatwiejsze w zarządzaniu, ponieważ można centralnie zarządzać wszystkimi uprawnieniami w IAM, zamiast rozdzielać je między IAM i S3.
- Istnieje wiele kontenerów S3, z których każdy ma inne wymagania dotyczące uprawnień. Polityki IAM będą łatwiejsze w zarządzaniu, ponieważ nie trzeba definiować dużej liczby polityk S3 i możesz zamiast tego polegać na mniejszej liczbie bardziej szczegółowych polityk IAM.
- Preferowane jest zachowanie polityki kontroli dostępu w środowisku IAM.
Można użyć polityki kontenerów S3, jeśli:
- Potrzebny jest prosty sposób na przyznanie dostępu typu cross-account access do środowiska S3 bez używania ról IAM.
- Polityki IAM przekraczają limit rozmiaru (do 2 KB dla użytkowników, 5 KB dla grup i 10 KB dla ról). S3 obsługuje polityki kontenerów do 20 kb.
- Preferowanie jest zachowanie polityki kontroli dostępu w środowisku S3.
Jeśli nadal istnieje niepewność, którego użyć, warto zastanowić się, które pytanie kontrolne jest najważniejsze:
- Jeśli istnieje większe zainteresowanie „Co ten użytkownik może zrobić w AWS?” w takim razie polityki IAM są prawdopodobnie najlepszym rozwiązaniem. Można łatwo odpowiedzieć na to pytanie, wyszukując uprawnienia użytkownika, a następnie sprawdzając jego polityki IAM, aby sprawdzić, jakie ma uprawnienia.
- Jeśli pytanie „Kto może uzyskać dostęp do tego kontenera S3?” jest ważniejsze, wtedy polityka kontenera S3 prawdopodobnie będzie bardziej odpowiednia. Można łatwo odpowiedzieć na to pytanie, wyszukując bucket i analizując jego polityki.
Niezależnie od wybranej metody, AWS zaleca zachowanie możliwie największej spójności. Uprawnienia do inspekcji stają się trudniejsze, gdy rośnie liczba polityk IAM i polityk kontenerów S3.
A co z listami ACL S3?
Z zasady AWS zaleca używanie polityk S3 lub polityk IAM do kontroli dostępu. Listy ACL S3 to starszy mechanizm kontroli dostępu, który jest starszy niż IAM. Jeśli jednak jest już używana lista kontrolna ACL S3 i uznawana jest za wystarczającą, nie ma potrzeby jej zmiany.
Lista kontrolna ACL S3 to zasób podrzędny, który jest dołączony do każdego kontenera i obiektu S3. Określa, którym kontom lub grupom AWS udzielany jest dostęp oraz typ dostępu. Podczas tworzenia bucketu lub obiektu, Amazon S3 tworzy domyślną listę ACL, która przyznaje właścicielowi zasobu pełną kontrolę nad zasobem.
Można dołączyć listy ACL S3 do poszczególnych obiektów w kontenerze, aby zarządzać uprawnieniami do tych obiektów. Polityki S3 bucket i polityki IAM definiują uprawnienia na poziomie obiektu, wskazując te obiekty w elemencie Resource w instrukcjach polityki. Reguła będzie miała zastosowanie do tych obiektów w kontenerze. Konsolidacja uprawnień specyficznych dla obiektu w jedną politykę (w przeciwieństwie do wielu list ACL S3) ułatwia określenie efektywnych uprawnień dla użytkowników i ról.
Jak działa autoryzacja z wieloma mechanizmami kontroli dostępu?
Za każdym razem, gdy podmiot AWS wysyła żądanie do S3, decyzja dotycząca autoryzacji zależy od sumy wszystkich polityk IAM, polityk S3 i list ACL S3.
Zgodnie z zasadą uprzywilejowania typu least-privilege, decyzja domyślna ustawiona jest na DENY (odmowa), a wyraźna ODMOWA zawsze ma pierwszeństwo przed ALLOW (zezwoleniem). Na przykład, jeśli polityka IAM przyznaje dostęp do obiektu, polityki S3 odmawiają dostępu do tego obiektu, a dodatkowo nie ma listy ACL S3, wówczas dostęp zostanie odmówiony. Podobnie, jeśli żadna metoda nie określa ZEZWOLENIA, żądanie zostanie domyślnie odrzucone. Żądanie będzie dozwolone tylko wtedy, gdy żadna metoda nie określa DENY, a co najmniej jedna metoda określa ALLOW.
Diagram poniżej ilustruje proces autoryzacji.
Mamy nadzieję, że ten post wyjaśnia niektóre nieporozumienia związane z różnymi sposobami kontrolowania dostępu do środowiska S3.
Dodatkowe źródła
źródło: AWS
44-200 Rybnik
Poland
REGON: 240692928
KRS: 275333
