Röviden: A tárolóhoz való hozzáférést két policy metszete dönti el. A téves feltételezés arról, hogy melyik mit enged, a leggyakoribb adatszivárgási forgatókönyvek egyike.
Az objektumtárolóhoz való hozzáférés az egyik legfélreértettebb téma a felhőben, és nem véletlen, hogy a nyilvános adatszivárgások jó része pont innen ered. A gyökér szinte mindig ugyanaz: valaki azt hitte, hogy egyetlen policy dönt a hozzáférésről, pedig valójában több szabályrendszer metszete határozza meg, ki mit tehet.
Két policy, egy döntés
A tárolóhoz kétféle irányból lehet jogot adni. Az IAM policy az identitáshoz (felhasználóhoz, szerepkörhöz) tartozik, és azt mondja meg, hogy az adott identitás mihez férhet hozzá. A bucket policy magához a tárolóhoz tartozik, és azt mondja meg, ki férhet hozzá ehhez a konkrét erőforráshoz — akár másik fiókból is.
A két policy nem alternatíva. A tényleges hozzáférés a kettő együttes eredménye, és van egy harmadik szereplő is: a szervezeti szintű guardrail.
A kiértékelés logikája
A hozzáférés eldöntése nem az „egyik enged, tehát mehet” elv szerint működik. A lényeg egyszerű, de sokan mégis eltévesztik:
- Egy explicit tiltás mindig felülír minden engedélyt — bárhonnan is jön.
- Engedély kell valahonnan (IAM vagy bucket policy) ahhoz, hogy a művelet egyáltalán szóba jöjjön.
- A szervezeti szintű korlátok (a széles körű tiltó szabályok) a plafont húzzák meg; ezek fölé egyik policy sem emelhet.
Vagyis: tiltás nyer, egyébként kell egy engedély, és minden a szervezeti plafon alatt marad.
A veszélyes félreértés
A klasszikus szivárgási forgatókönyv így néz ki: valaki a bucket policyt akarja megnyitni egy partnernek, és a gyorsaság kedvéért túl tágra veszi — mondjuk mindenkinek enged olvasást. Azt hiszi, ez csak a partnerre vonatkozik, pedig a tárolószintű engedély bárkinek szól, aki eléri. Ha közben nincs szervezeti szintű tiltás vagy a nyilvános hozzáférést blokkoló beállítás, az adat kikerül.
A védőháló, amit ne kapcsolj ki
Van egy fiók- és tárolószintű beállítás, amelynek kifejezetten az a célja, hogy a nyilvános hozzáférést globálisan blokkolja, függetlenül attól, mit ír a bucket policy. Ezt alapból hagyd bekapcsolva. Ha valaki ki akarja kapcsolni, az legyen tudatos, felülvizsgált döntés, nem egy gyors workaround egy hozzáférési hiba megoldására.
Mikor melyiket használd?
| Cél | Eszköz |
|---|---|
| Egy szerepkör hozzáférése több tárolóhoz | IAM policy az identitáson |
| Cross-account hozzáférés egy tárolóhoz | Bucket policy |
| Tárolószintű feltétel (pl. csak titkosított feltöltés) | Bucket policy |
| Globális nyilvánosság-tiltás | A nyilvános hozzáférést blokkoló beállítás |
| Szervezeti szintű plafon | Széles körű tiltó guardrail |
A gyakorlatban a legtöbb belső hozzáférést IAM policyval érdemes kezelni (az identitáshoz kötve), és a bucket policyt a cross-account vagy tárolószintű feltételekre tartogatni.
Hogyan ellenőrizd?
Ne emberi fejben tartott feltételezésekre bízd magad. Az elemzőeszközök meg tudják mondani, mely tárolók érhetők el a fiókodon kívülről, és ezt a listát rendszeresen érdemes átnézni. A cél, hogy a tényleges, effektív hozzáférést lásd, ne azt, amit a policy írójaként gondolsz róla.
A cross-account hozzáférés helyes mintája
A cross-account (fiókok közötti) hozzáférés az egyik leggyakoribb hely, ahol a policy-k összekeverednek. A helyes minta itt jellemzően a bucket policy: a tárolóhoz tartozó szabály engedi meg egy másik, konkrét fiók hozzáférését, jól körülhatárolt jogokkal. Fontos, hogy ez mindig konkrét fiókra vagy szerepkörre szóljon, sose "mindenkire" — a túl tág cross-account engedély a leggyakoribb szivárgási forrás.
Érdemes a hozzáférést szerepkör-átvételen (assume role) keresztül is átgondolni: a másik fiók egy szűk jogú szerepkört vesz fel a te fiókodban, ahelyett hogy közvetlen tárolóhozzáférést kapna. Ez auditálhatóbb és szűkíthetőbb.
A feltételek ereje
A policy-k igazi ereje a feltételekben rejlik. Egy bucket policyval kikényszerítheted például, hogy csak titkosított feltöltés engedélyezett, vagy hogy csak egy adott hálózati útvonalról (VPC endpoint) érhető el a tároló. Ezek a feltételek erős, deklaratív biztonsági határokat húznak, amiket az identitás-alapú policy nem mindig tud.
- Kényszeríts titkosítást feltöltéskor.
- Korlátozd a hozzáférést egy adott hálózati útvonalra, ahol indokolt.
- Zárd ki a nem biztonságos (titkosítatlan) kapcsolatot.
A rendszeres felülvizsgálat
A hozzáférési szabályok idővel tágulnak és elavulnak: egy régi partner, aki már nem aktív; egy ideiglenesnek szánt nyitás, ami bent maradt. Ezért a tároló-hozzáféréseket rendszeresen felül kell vizsgálni, a külső elemzőeszköz findingjeit átnézni, és a feleslegessé vált engedélyeket visszavonni. A hozzáférés-higiénia itt is folyamat, nem egyszeri beállítás.
Mit jelent ez neked?
Az objektumtárolóhoz való hozzáférést az IAM policy, a bucket policy és a szervezeti guardrailek metszete dönti el, és egy explicit tiltás mindent felülír. A belső hozzáférést tartsd az identitáson, a bucket policyt a cross-account esetekre, és soha ne kapcsold ki gondolkodás nélkül a nyilvánosságot blokkoló védőhálót. Ha bizonytalan vagy, ne feltételezz — ellenőrizd az effektív hozzáférést eszközzel.