Cu ani în urmă, când serverele Unix locale cu sisteme de fișiere mari erau un lucru, companiile construiau reguli extinse de gestionare a folderelor și strategii pentru administrarea drepturilor de acces la diferite foldere pentru diferiți oameni.
De obicei, platforma unei organizații deservește diferite grupuri de utilizatori cu interese complet distincte, restricții la nivel de confidențialitate sau definiții de conținut. În cazul organizațiilor globale, acest lucru ar putea însemna chiar separarea conținutului în funcție de locație, deci practic, între utilizatorii care aparțin diferitelor țări.
Alte exemple tipice ar putea include:
- separarea datelor între mediile de dezvoltare, testare și producție
- conținut de vânzări nu este accesibil unui public larg
- conținut legislativ specific țării care nu poate fi văzut sau accesat din altă regiune
- conținut legat de proiect în care „date de conducere” trebuie furnizate doar unui grup limitat de persoane etc.
Există o listă potențial nesfârșită de astfel de exemple. Ideea este că există întotdeauna un fel de nevoie de a orchestra drepturile de acces la fișiere și date între toți utilizatorii cărora platforma oferă acces.
În cazul soluțiilor on-premise, aceasta a fost o sarcină de rutină. Administratorul sistemului de fișiere tocmai a stabilit niște reguli, a folosit un instrument la alegere, apoi oamenii au fost mapați în grupuri de utilizatori, iar grupurile de utilizatori au fost mapate într-o listă de foldere sau puncte de montare pe care le vor putea accesa. Pe parcurs, nivelul de acces a fost definit ca acces doar citire sau acces citire și scriere.
Acum, analizând platformele cloud AWS, este evident să ne așteptăm ca oamenii să aibă cerințe similare pentru restricțiile de acces la conținut. Soluția la această problemă trebuie să fie, totuși, acum alta. Fișierele nu mai rezistă pe serverele Unix, ci în cloud (și posibil accesibile nu numai întregii organizații, ci chiar întregii lumi), iar conținutul nu este stocat în foldere, ci în găleți S3.
Mai jos este descrisă o alternativă pentru abordarea acestei probleme. Este construit pe experiența din lumea reală pe care am avut-o în timp ce proiectam astfel de soluții pentru un proiect concret.
Cuprins
Abordare simplă, dar extrem de manuală
O modalitate de a rezolva această problemă fără nicio automatizare este relativ simplă și simplă:
- Creați o găleată nouă pentru fiecare grup distinct de persoane.
- Atribuiți drepturi de acces la compartiment, astfel încât numai acest grup specific să poată accesa compartimentul S3.
Acest lucru este cu siguranță posibil dacă cerința este de a merge cu o rezoluție foarte simplă și rapidă. Există, totuși, anumite limite de care trebuie să fii conștient.
În mod implicit, numai până la 100 de compartimente S3 pot fi create sub un cont AWS. Această limită poate fi extinsă la 1000 prin trimiterea unei creșteri a limitei de serviciu la biletul AWS. Dacă aceste limite nu sunt ceva de care ar fi îngrijorat cazul dvs. de implementare, atunci puteți permite fiecărui utilizator al domeniului dvs. distinct să opereze într-o gapă S3 separată și să o sune pe zi.
Problemele pot apărea dacă există anumite grupuri de persoane cu responsabilități interfuncționale sau pur și simplu unele persoane care au nevoie de acces la conținutul mai multor domenii în același timp. De exemplu:
- Analiștii de date evaluează conținutul datelor pentru mai multe zone, regiuni etc.
- Echipa de testare a partajat servicii pentru diferite echipe de dezvoltare.
- Raportarea utilizatorilor care au nevoie să construiască o analiză a tabloului de bord în partea de sus a diferitelor țări din aceeași regiune.
După cum vă puteți imagina, această listă poate crește din nou atât de mult pe cât vă puteți imagina, iar nevoile organizațiilor pot genera tot felul de cazuri de utilizare.
Cu cât această listă devine mai complexă, cu atât va fi necesară orchestrarea drepturilor de acces mai complexă pentru a acorda tuturor acelor grupuri diferite drepturi de acces diferite la diferite compartimente S3 din organizație. Vor fi necesare instrumente suplimentare și poate chiar și o resursă dedicată (administrator) va trebui să mențină listele de drepturi de acces și să le actualizeze ori de câte ori se solicită orice modificare (ceea ce va fi foarte des, mai ales dacă organizația este mare).
Deci, cum să realizați același lucru într-un mod mai organizat și mai automat?
Dacă abordarea grupului-pe-domeniu nu funcționează, orice altă soluție va ajunge cu compartimente partajate pentru mai multe grupuri de utilizatori. În astfel de cazuri, este necesar să se construiască întreaga logică de atribuire a drepturilor de acces într-o zonă care este ușor de schimbat sau actualizat dinamic.
Una dintre modalitățile de a realiza acest lucru este prin utilizarea etichetelor pe gălețile S3. Se recomandă utilizarea etichetelor în orice caz (dacă pentru nimic altceva decât pentru a permite o clasificare mai ușoară a facturării). Cu toate acestea, eticheta poate fi schimbată oricând în viitor pentru orice găleată.
Dacă întreaga logică este construită pe baza etichetelor găleții, iar restul din spate depinde de configurație de valorile etichetei, proprietatea dinamică este asigurată, deoarece se poate redefini scopul găleții doar prin actualizarea valorilor etichetelor.
Ce fel de etichete să folosiți pentru ca acest lucru să funcționeze?
Acest lucru depinde de cazul dvs. concret de utilizare. De exemplu:
- Poate fi necesară separarea găleților pentru fiecare tip de mediu. Deci, în acest caz, unul dintre numele etichetelor va fi ceva de genul „ENV” și cu posibile valori „DEV”, „TEST”, „PROD”, etc.
- Poate doriți să despărțiți echipa în funcție de țară. În acest caz, o altă etichetă va fi „COUNTRY” și va valorifica un nume de țară.
- Sau poate doriți să separați utilizatorii în funcție de departamentul funcțional din care aparțin, cum ar fi analiștii de afaceri, utilizatorii de depozit de date, oamenii de știință în date etc. Așa că creați o etichetă cu numele „USER_TYPE” și valoarea respectivă.
- O altă opțiune ar putea fi aceea că doriți să definiți în mod explicit o structură fixă de foldere pentru anumite grupuri de utilizatori pe care trebuie să le folosească (pentru a nu-și crea propriul aglomerat de foldere și a se pierde acolo în timp). Puteți face acest lucru din nou cu etichete, unde puteți specifica mai multe directoare de lucru precum: „date/import”, „date/processed”, „date/error”, etc.
În mod ideal, doriți să definiți etichetele astfel încât să poată fi combinate logic și să le faceți să formeze o structură întreagă de foldere pe găleată.
De exemplu, puteți combina următoarele etichete din exemplele de mai sus pentru a construi o structură de foldere dedicată pentru diferite tipuri de utilizatori din diferite țări, cu dosare de import predefinite pe care se așteaptă să le utilizeze:
- /
/ / /<ÎNCĂRCARE>
Doar prin schimbarea valorii
Acest lucru va permite utilizarea aceleiași găleți pentru mulți utilizatori diferiți. Buchetele nu acceptă folderele în mod explicit, dar acceptă „etichete”. Aceste etichete funcționează ca subfoldere în cele din urmă, deoarece utilizatorii trebuie să treacă printr-o serie de etichete pentru a ajunge la datele lor (la fel cum ar face cu subfolderele).
După ce am definit etichetele într-o formă utilizabilă, următorul pas este să construiești politici de grup S3 care să folosească etichetele.
Dacă politicile folosesc numele etichetelor, creați ceva numit „politici dinamice”. Acest lucru înseamnă, practic, politica dvs. se va comporta diferit pentru compartimente cu valori de etichetă diferite la care se referă politica în formă sau substituenți.
Acest pas implică, evident, o codificare personalizată a politicilor dinamice, dar puteți simplifica acest pas folosind instrumentul de editor de politici Amazon AWS, care vă va ghida prin proces.
În politica în sine, veți dori să codificați drepturi de acces concrete care vor fi aplicate găleții și nivelul de acces al acestor drepturi (citire, scriere). Logica va citi etichetele de pe găleți și va construi structura de foldere pe găleată (creând etichete pe baza etichetelor). Pe baza valorilor concrete ale etichetelor vor fi create subfolderele, iar drepturile de acces necesare vor fi atribuite de-a lungul liniei.
Lucrul frumos despre o astfel de politică dinamică este că puteți crea o singură politică dinamică și apoi puteți atribui aceeași politică dinamică mai multor compartimente. Această politică se va comporta diferit pentru compartimente cu valori de etichetă diferite, dar va fi întotdeauna alături de așteptările dvs. pentru o grupă cu astfel de valori de etichetă.
Este o modalitate cu adevărat eficientă de a gestiona atribuirile de drepturi de acces într-un mod organizat, centralizat pentru un număr mare de compartimente, în care se așteaptă ca fiecare grupă să urmeze niște structuri șablon care sunt convenite în avans și vor fi utilizate de utilizatorii dvs. intreaga organizatie.
Automatizați integrarea noilor entități
După definirea politicilor dinamice și atribuirea acestora la compartimentele existente, utilizatorii pot începe să utilizeze aceleași compartimente fără riscul ca utilizatorii din grupuri diferite să nu acceseze conținut (stocat în același compartiment) situat sub o structură de foldere în care nu au acces.
De asemenea, pentru unele grupuri de utilizatori cu acces mai larg, va fi ușor să ajungeți la date, deoarece acestea vor fi toate stocate în același compartiment.
Pasul final este de a face integrarea de noi utilizatori, noi găleți și chiar noi etichete cât mai simplă posibil. Acest lucru a condus la o altă codificare personalizată, care, totuși, nu trebuie să fie prea complexă, presupunând că procesul dvs. de integrare are niște reguli foarte clare care pot fi încapsulate cu o logică simplă și simplă a algoritmului (cel puțin puteți demonstra în acest fel că dvs. procesul are o oarecare logică și nu se face într-un mod prea haotic).
Acest lucru poate fi la fel de simplu ca și crearea unui script executabil prin comanda AWS CLI cu parametrii necesari pentru a integra cu succes o nouă entitate în platformă. Poate fi chiar o serie de scripturi CLI, executabile într-o anumită ordine, cum ar fi, de exemplu:
- create_new_bucket(
, , , , ..) - create_new_tag(
, , ) - update_existing_tag(
, , ) - create_user_group(
,<țară>, ) - etc.
Înțelegi ideea. 😃
Un sfat de profesionist 👨💻
Există un Sfat Pro dacă doriți, care poate fi aplicat cu ușurință peste cele de mai sus.
Politicile dinamice pot fi valorificate nu numai pentru alocarea drepturilor de acces pentru locațiile folderelor, ci și pentru a atribui automat drepturi de serviciu pentru găleți și grupuri de utilizatori!
Tot ceea ce ar fi nevoie este să extinzi lista de etichete de pe găleți și apoi să adaugi drepturi de acces la politici dinamice pentru a utiliza servicii specifice pentru grupuri concrete de utilizatori.
De exemplu, ar putea exista un grup de utilizatori care au nevoie și de acces la serverul cluster al bazei de date. Acest lucru poate fi realizat, fără îndoială, prin politici dinamice care strâng sarcini de tip bucket, cu atât mai mult dacă accesele la servicii sunt conduse de o abordare bazată pe roluri. Doar adăugați la codul de politică dinamică o parte care va procesa etichetele referitoare la specificația clusterului bazei de date și va atribui direct privilegiile de acces la politică acelui cluster DB și grupului de utilizatori.
În acest fel, integrarea unui nou grup de utilizatori va fi executabilă doar prin această politică dinamică unică. În plus, deoarece este dinamică, aceeași politică poate fi reutilizată pentru integrarea mai multor grupuri de utilizatori diferite (se așteaptă să urmeze același șablon, dar nu neapărat aceleași servicii).
De asemenea, puteți arunca o privire asupra acestor comenzi AWS S3 pentru a gestiona compartimentele și datele.