У давна времена, када су локални Unix serveri sa ogromnim sistemima datoteka bili uobičajeni, kompanije su razvijale složena pravila za upravljanje direktorijumima i strategije za kontrolu prava pristupa različitim direktorijumima za različite korisnike.
Tipično, platforma organizacije opslužuje raznolike grupe korisnika sa potpuno različitim interesovanjima, ograničenjima u pogledu poverljivosti ili definicijama sadržaja. U globalnim organizacijama, ovo može uključivati i razdvajanje sadržaja na osnovu geografske lokacije, odnosno, između korisnika koji se nalaze u različitim zemljama.
Dodatni uobičajeni primeri mogu uključivati:
- razdvajanje podataka između razvojnog, testnog i produkcionog okruženja
- prodajni materijal nedostupan široj publici
- zakonski sadržaj specifičan za određenu državu, kojem se ne može pristupiti iz druge regije
- sadržaj povezan sa projektima gde „podaci o upravljanju“ trebaju biti dostupni samo odabranoj grupi ljudi, itd.
Postoji potencijalno beskonačan broj ovakvih primera. Poenta je da uvek postoji potreba za upravljanjem pravima pristupa datotekama i podacima između svih korisnika koji imaju pristup platformi.
Kod lokalnih rešenja, ovo je bio standardni zadatak. Administrator sistema datoteka je samo postavio određena pravila, koristio odgovarajući alat, a zatim su korisnici grupisani, a grupe korisnika su povezane sa listom direktorijuma ili tačaka montiranja kojima su mogli pristupiti. Uz to, nivo pristupa je bio definisan kao pristup samo za čitanje ili pristup za čitanje i pisanje.
Sada, razmatrajući AWS platforme u oblaku, sasvim je logično očekivati da ljudi imaju slične zahteve za kontrolu pristupa sadržaju. Rešenje ovog problema sada mora biti drugačije. Datoteke se više ne nalaze na Unix serverima, već u oblaku (i potencijalno su dostupne ne samo celoj organizaciji već i celom svetu), a sadržaj se ne čuva u direktorijumima, već u S3 bucket-ima.
U nastavku je opisana alternativa za pristup ovom izazovu. Zasnovana je na iskustvu iz stvarnog sveta koje sam stekao dizajnirajući ovakva rešenja za konkretan projekat.
Jednostavan, ali izrazito manuelni pristup
Jedan od načina da se reši ovaj problem bez automatizacije je relativno jednostavan:
- Napravite novi bucket za svaku posebnu grupu ljudi.
- Dodelićete prava pristupa grupi tako da samo ta određena grupa može pristupiti S3 bucket-u.
Ovo je svakako moguće ako se traži vrlo jednostavno i brzo rešenje. Međutim, postoje određena ograničenja kojih treba biti svestan.
Podrazumevano, pod jednim AWS nalogom može se kreirati najviše 100 S3 bucket-a. Ovo ograničenje se može povećati na 1000 podnošenjem zahteva za povećanje ograničenja usluge putem AWS tiketa. Ako ova ograničenja ne predstavljaju problem za vašu specifičnu implementaciju, onda možete dozvoliti svakom korisniku vašeg domena da radi na zasebnom S3 bucket-u i da se time pozabavite.
Problemi mogu nastati ako postoje grupe ljudi sa višefunkcionalnim odgovornostima, ili jednostavno ljudi kojima je potreban pristup sadržaju iz više domena istovremeno. Na primer:
- Analitičari podataka koji obrađuju podatke iz nekoliko različitih oblasti, regiona itd.
- Tim za testiranje koji deli usluge koje koriste različiti razvojni timovi.
- Korisnici koji generišu izveštaje i prave analize na osnovu podataka iz različitih zemalja u istom regionu.
Kao što možete pretpostaviti, ova lista se može beskonačno širiti, a potrebe organizacije mogu generisati razne slučajeve upotrebe.
Što je lista složenija, biće potrebno kompleksnije upravljanje pravima pristupa kako bi se različitim grupama dodelila različita prava pristupa različitim S3 bucket-ima unutar organizacije. Biće potrebni dodatni alati, a možda čak i posvećeni resurs (administrator) koji bi održavao liste prava pristupa i ažurirao ih kad god se zahteva bilo kakva promena (što će biti vrlo često, pogotovo ako je organizacija velika).
Kako onda postići isto na organizovaniji i automatizovaniji način?
Ako pristup „bucket po domenu“ ne funkcioniše, svako drugo rešenje će koristiti deljene bucket-e za više grupa korisnika. U takvim slučajevima, potrebno je implementirati logiku dodeljivanja prava pristupa na mestu koje se lako menja ili dinamički ažurira.
Jedan od načina da se ovo postigne je korišćenje tagova na S3 bucket-ima. Preporučuje se da se tagovi koriste u svakom slučaju (ako ni zbog čega drugog, onda radi lakše kategorizacije troškova). Međutim, tag se može promeniti u bilo kom trenutku u budućnosti za bilo koji bucket.
Ako je celokupna logika zasnovana na tagovima bucket-a, a sve ostalo je konfiguracija koja zavisi od vrednosti tagova, onda je dinamička promenljivost osigurana jer se namena bucket-a može redefinisati samo ažuriranjem vrednosti tagova.
Koje tagove koristiti da bi ovo funkcionisalo?
To zavisi od vašeg konkretnog slučaja upotrebe. Na primer:
- Možda je potrebno razdvojiti bucket-e prema tipu okruženja. U tom slučaju, jedan od naziva tagova bi bio nešto poput „ENV“ sa mogućim vrednostima „DEV“, „TEST“, „PROD“ itd.
- Možda želite da razdvojite tim na osnovu zemlje. U tom slučaju, drugi tag bi bio „COUNTRY“ sa vrednostima koje predstavljaju imena država.
- Ili biste mogli razdvojiti korisnike na osnovu funkcionalnog odeljenja kojem pripadaju, kao što su poslovni analitičari, korisnici skladišta podataka, stručnjaci za analizu podataka, itd. Dakle, kreirate tag sa nazivom „USER_TYPE“ i odgovarajućom vrednošću.
- Druga opcija bi mogla biti da želite eksplicitno definisati fiksnu strukturu direktorijuma za određene grupe korisnika koje su obavezne da je koriste (da ne prave sopstveni nered u direktorijumima i da se u njima ne izgube vremenom). To možete ponovo uraditi pomoću tagova, gde možete navesti nekoliko radnih direktorijuma kao što su: „podaci/uvoz“, „podaci/obrađeni“, „podaci/greška“ itd.
U idealnom slučaju, želite da definišete tagove na način da se mogu logički kombinovati i formirati celu strukturu direktorijuma na bucket-u.
Na primer, možete kombinovati sledeće tagove iz gornjih primera da biste kreirali namensku strukturu direktorijuma za različite tipove korisnika iz različitih zemalja sa unapred definisanim direktorijumima za uvoz koje se od njih očekuje da koriste:
- /<ENV>/<USER_TYPE>/<COUNTRY>/<UPLOAD>
Samo promenom vrednosti <ENV>, možete redefinisati svrhu tag-a (da li će biti dodeljen testnom okruženju, dev, prod itd.).
Ovo će omogućiti korišćenje istog bucket-a za mnogo različitih korisnika. Bucket-i ne podržavaju eksplicitno direktorijume, ali podržavaju „tagove“. Ovi tagovi funkcionišu kao poddirektorijumi, jer korisnici moraju da prođu kroz niz tagova da bi došli do svojih podataka (baš kao što bi to uradili sa poddirektorijumima).
Nakon što smo definisali tagove u upotrebljivom obliku, sledeći korak je kreiranje S3 bucket politike koja koristi tagove.
Ako politike koriste nazive tagova, kreirate nešto što se zove „dinamičke politike“. To u osnovi znači da će se vaša politika ponašati drugačije za bucket-e sa različitim vrednostima tagova, u zavisnosti od toga kako su te politike formirane.
Ovaj korak očigledno podrazumeva određeno prilagođeno kodiranje dinamičkih politika, ali ovaj korak možete pojednostaviti pomoću alata za uređivanje politika kompanije Amazon AWS, koji će vas voditi kroz proces.
U samoj politici ćete želeti da kodirate konkretna prava pristupa koja će se primenjivati na bucket i nivo pristupa tih prava (čitanje, pisanje). Logika će pročitati tagove na bucket-u i izgraditi strukturu direktorijuma na bucket-u (kreirajući tagove na osnovu tagova). Na osnovu konkretnih vrednosti tagova kreiraće se poddirektorijumi i dodeliti neophodna prava pristupa.
Dobra stvar kod ovakve dinamičke politike je što možete kreirati samo jednu dinamičku politiku, a zatim dodeliti istu dinamičku politiku mnogim bucket-ima. Te politike će se ponašati drugačije za bucket-e sa različitim vrednostima tagova, ali će uvek biti u skladu sa vašim očekivanjima za bucket sa tim vrednostima tagova.
To je zaista efikasan način upravljanja dodeljivanjem prava pristupa na organizovan i centralizovan način za veliki broj grupa, gde se očekuje da svaki bucket prati strukturu šablona koje su dogovorene i koje će korisnici koristiti u celoj organizaciji.
Automatizujte uvođenje novih entiteta
Nakon definisanja dinamičkih politika i dodeljivanja istih postojećim bucket-ima, korisnici mogu početi da koriste iste bucket-e bez rizika da korisnici iz različitih grupa pristupe sadržaju (sačuvanom u istom bucket-u) koji se nalazi u strukturi direktorijuma kojoj nemaju pristup.
Takođe, za neke grupe korisnika sa širim pristupom, biće lako doći do podataka jer će svi biti sačuvani u istom bucket-u.
Poslednji korak je da se uvođenje novih korisnika, novih grupa, pa čak i novih tagova, učini što jednostavnijim. Ovo zahteva dodatno prilagođeno kodiranje, koje ne mora da bude previše složeno, pod pretpostavkom da vaš proces uvođenja ima vrlo jasna pravila koja se mogu obuhvatiti jednostavnom algoritamskom logikom (barem možete dokazati na ovaj način da vaš proces ima logiku i da nije haotičan).
Ovo može biti jednostavno kao kreiranje izvršne skripte pomoću AWS CLI komande sa parametrima potrebnim za uspešno uvođenje novog entiteta na platformu. To može biti i niz CLI skripti, izvršenih određenim redosledom, kao što je, na primer:
- create_new_bucket(<ENV>,<ENV_VALUE>,<COUNTRY>,<COUNTRY_VALUE>..)
- create_new_tag(<id_bucket_id>,<tag_name>,<tag_value>)
- update_existing_tag(<id_bucket_id>,<tag_name>,<tag_value>)
- create_user_group(<user_type>,<country>,<env>)
- itd.
Shvatili ste poentu.😃
Profesionalni savet 👨💻
Postoji jedan profesionalni savet, ako želite, koji se lako može primeniti na gore navedeno.
Dinamičke politike se mogu koristiti ne samo za dodeljivanje prava pristupa lokacijama direktorijuma, već i za automatsko dodeljivanje prava na usluge za grupe i korisničke grupe!
Sve što bi bilo potrebno je da se proširi lista tagova na bucket-ima i da se doda odobrenje pristupa dinamičkim politikama za korišćenje specifičnih usluga za određene grupe korisnika.
Na primer, možda postoji grupa korisnika kojoj je potreban pristup određenom serveru baze podataka. To se može postići dinamičkim politikama koje koriste agregatne zadatke, posebno ako je pristup uslugama vođen pristupom zasnovanim na ulogama. Samo dodajte kod u dinamičku politiku koji će obrađivati tagove povezane sa specifikacijom servera baze podataka i dodelite privilegije pristupa politici direktno tom određenom serveru baze podataka i korisničkoj grupi.
Na ovaj način, uvođenje nove grupe korisnika će se izvršavati samo pomoću ove jedinstvene dinamičke politike. Štaviše, pošto je dinamička, ista politika se može ponovo koristiti za uvođenje mnogih različitih grupa korisnika (očekuje se da će pratiti isti šablon, ali ne nužno i iste usluge).
Možete pogledati i ove AWS S3 komande za upravljanje bucket-ima i podacima.