For mange år siden, da lokale Unix-servere med store filsystemer var en ting, bygde selskaper omfattende mappeadministrasjonsregler og strategier for å administrere tilgangsrettigheter til forskjellige mapper for forskjellige personer.
Vanligvis betjener en organisasjons plattform forskjellige grupper av brukere med helt forskjellige interesser, begrensninger på konfidensialitetsnivå eller innholdsdefinisjoner. Når det gjelder globale organisasjoner, kan dette til og med bety å skille innhold basert på plassering, så i utgangspunktet mellom brukere som tilhører forskjellige land.
Ytterligere typiske eksempler kan omfatte:
- dataskille mellom utviklings-, test- og produksjonsmiljøer
- salgsinnhold som ikke er tilgjengelig for et bredt publikum
- landsspesifikt lovgivende innhold som ikke kan sees eller åpnes fra en annen region
- prosjektrelatert innhold der «lederdata» kun skal gis til en begrenset gruppe mennesker mv.
Det er en potensielt uendelig liste over slike eksempler. Poenget er at det alltid er et slags behov for å organisere tilgangsrettigheter til filer og data mellom alle brukerne som plattformen gir tilgang til.
Ved lokale løsninger var dette en rutineoppgave. Administratoren av filsystemet satte bare opp noen regler, brukte et valgfritt verktøy, og deretter ble folk kartlagt i brukergrupper, og brukergrupper ble kartlagt til en liste over mapper eller monteringspunkter de skal ha tilgang til. Underveis ble tilgangsnivået definert som skrivebeskyttet eller lese- og skrivetilgang.
Når man ser på AWS-skyplattformer, er det åpenbart å forvente at folk har lignende krav til restriksjoner for innholdstilgang. Løsningen på dette problemet må imidlertid være annerledes nå. Filer er ikke lenger motstandsdyktige på Unix-servere, men i skyen (og potensielt tilgjengelige ikke bare for hele organisasjonen, men til og med hele verden), og innholdet lagres ikke i mapper, men i S3-bøtter.
Nedenfor er beskrevet et alternativ for å nærme seg dette problemet. Det er bygget på den virkelige opplevelsen jeg hadde mens jeg utformet slike løsninger for et konkret prosjekt.
Innholdsfortegnelse
Enkel, men svært manuell tilnærming
En måte å løse dette problemet uten automatisering er relativt grei og enkel:
- Opprett en ny bøtte for hver distinkte gruppe mennesker.
- Tildel tilgangsrettigheter til bøtten slik at bare denne spesifikke gruppen kan få tilgang til S3-bøtten.
Dette er absolutt mulig hvis kravet er å gå med en veldig enkel og rask løsning. Det er imidlertid noen grenser å være klar over.
Som standard kan bare opptil 100 S3-bøtter opprettes under én AWS-konto. Denne grensen kan utvides til 1000 ved å sende inn en tjenestegrenseøkning til AWS-billetten. Hvis disse grensene ikke er noe din spesielle implementeringssak ville være bekymret for, kan du la hver av dine distinkte domenebrukere operere på en separat S3-bøtte og kalle det en dag.
Problemene kan oppstå hvis det er noen grupper mennesker med tverrfunksjonelt ansvar eller bare noen personer som trenger tilgang til innholdet på flere domener samtidig. For eksempel:
- Dataanalytikere evaluerer datainnholdet for flere forskjellige områder, regioner osv.
- Testteamet delte tjenester som betjente forskjellige utviklingsteam.
- Rapportere brukere som trenger å bygge opp dashbordanalyse på toppen av forskjellige land i samme region.
Som du kanskje forestiller deg, kan denne listen igjen vokse så mye du kan forestille deg, og organisasjoners behov kan generere alle slags brukstilfeller.
Jo mer kompleks denne listen blir, jo mer kompleks tilgangsrettighetsorkestrering vil være nødvendig for å gi alle de forskjellige gruppene forskjellige tilgangsrettigheter til forskjellige S3-bøtter i organisasjonen. Det vil være nødvendig med tilleggsverktøy, og kanskje til og med en dedikert ressurs (administrator) vil trenge å vedlikeholde tilgangsrettighetslistene og oppdatere dem når det blir bedt om endringer (noe som vil være veldig ofte, spesielt hvis organisasjonen er stor).
Så hvordan oppnå det samme på en mer organisert og automatisert måte?
Hvis bøtte-per-domene-tilnærmingen ikke fungerer, vil enhver annen løsning ende opp med delte bøtter for flere brukergrupper. I slike tilfeller er det nødvendig å bygge hele logikken for å tildele tilgangsrettigheter i et område som er enkelt å endre eller oppdatere dynamisk.
En av måtene å oppnå dette på er ved å bruke Tags på S3-bøttene. Taggene anbefales å brukes uansett (om ikke for noe annet enn for å muliggjøre enklere faktureringskategorisering). Merket kan imidlertid endres når som helst i fremtiden for en hvilken som helst bøtte.
Hvis hele logikken er bygget basert på bøtte-taggene og resten bak er konfigurasjon avhengig av tag-verdiene, er den dynamiske egenskapen sikret da man kan omdefinere formålet med bøtte bare ved å oppdatere tag-verdiene.
Hva slags tagger skal du bruke for å få dette til å fungere?
Dette avhenger av din konkrete brukssituasjon. For eksempel:
- Det kan være nødvendig å skille bøtter per miljøtype. Så i så fall skal ett av tag-navnene være noe sånt som «ENV» og med mulige verdier «DEV», «TEST», «PROD», etc.
- Kanskje du ønsker å skille laget ut fra landet. I så fall vil en annen kode være «COUNTRY» og verdsette et landnavn.
- Eller du vil kanskje skille brukerne basert på funksjonsavdelingen de tilhører, som forretningsanalytikere, datavarehusbrukere, dataforskere osv. Så du lager en tag med navnet «USER_TYPE» og den respektive verdien.
- Et annet alternativ kan være at du eksplisitt vil definere en fast mappestruktur for spesifikke brukergrupper som de er pålagt å bruke (for ikke å lage sitt eget rot av mapper og gå seg vill der over tid). Du kan gjøre det igjen med tagger, der du kan spesifisere flere arbeidskataloger som: «data/import», «data/behandlet», «data/feil», etc.
Ideelt sett vil du definere kodene slik at de kan kombineres logisk og få dem til å danne en hel mappestruktur på bøtta.
Du kan for eksempel kombinere følgende tagger fra eksemplene ovenfor for å konstruere en dedikert mappestruktur for ulike typer brukere fra ulike land med forhåndsdefinerte importmapper de forventes å bruke:
- /
/ / /
Bare ved å endre
Dette vil muliggjøre bruk av samme bøtte for mange forskjellige brukere. Bøtter støtter ikke mapper eksplisitt, men de støtter «etiketter». Disse etikettene fungerer som undermapper til slutt fordi brukerne må gå gjennom en serie etiketter for å nå dataene deres (akkurat som de ville gjort med undermapper).
Etter å ha definert kodene i en brukbar form, er neste trinn å bygge S3-bøttepolicyer som vil bruke kodene.
Hvis policyene bruker tagnavnene, lager du noe som kalles «dynamiske retningslinjer». Dette betyr i utgangspunktet at policyen din vil oppføre seg annerledes for buckets med ulike tag-verdier som policyen refererer til i form eller plassholdere.
Dette trinnet involverer åpenbart noe tilpasset koding av de dynamiske retningslinjene, men du kan forenkle dette trinnet ved å bruke Amazon AWS-policyredigeringsverktøyet, som vil veilede deg gjennom prosessen.
I selve policyen vil du ønske å kode konkrete tilgangsrettigheter som skal brukes på bøtten og tilgangsnivået til slike rettigheter (lese, skrive). Logikken vil lese taggene på bøttene og vil bygge opp mappestrukturen på bøtten (opprette etiketter basert på taggene). Basert på de konkrete verdiene til taggene vil undermappene bli opprettet, og nødvendige tilgangsrettigheter vil bli tildelt langs linjen.
Det fine med en slik dynamisk policy er at du kan lage bare én dynamisk policy og deretter tilordne den samme dynamiske policyen til mange verdier. Denne retningslinjen vil oppføre seg annerledes for bøtte med forskjellige tag-verdier, men den vil alltid være sammen med forventningene dine til en bøtte med slike tag-verdier.
Det er en veldig effektiv måte å administrere tilgangsrettighetstildelinger på en organisert, sentralisert måte for et stort antall bøtter, hvor det er forventningen at hver bøtte vil følge noen malstrukturer som er avtalt på forhånd og vil bli brukt av brukerne dine innenfor hele organisasjonen.
Automatiser innføringen av nye enheter
Etter å ha definert dynamiske retningslinjer og tilordnet dem til de eksisterende bøttene, kan brukerne begynne å bruke de samme bøttene uten risiko for at brukere fra forskjellige grupper ikke får tilgang til innhold (lagret i samme bøtte) som ligger under en mappestruktur der de ikke har adgang.
For noen brukergrupper med bredere tilgang vil det også være enkelt å nå ut for dataene fordi alt vil bli lagret i samme bøtte.
Det siste trinnet er å gjøre introduksjon av nye brukere, nye bøtter og til og med nye tagger så enkelt som mulig. Dette førte til en annen tilpasset koding, som imidlertid ikke trenger å være altfor komplisert, forutsatt at onboardingsprosessen din har noen veldig klare regler som kan innkapsles med enkel, grei algoritmelogikk (i det minste kan du bevise på denne måten at prosessen har en viss logikk og den er ikke gjort på den altfor kaotiske måten).
Dette kan være så enkelt som å lage et skript som kan kjøres av AWS CLI-kommando med parametere som trengs for å lykkes med en ny enhet på plattformen. Det kan til og med være en serie CLI-skript, kjørbare i en bestemt rekkefølge, som for eksempel:
- create_new_bucket(
, , , , ..) - create_new_tag(
, , ) - update_existing_tag(
, , ) - create_user_group(
, , ) - etc.
Du skjønner poenget. 😃
Et profftips 👨💻
Det er ett Pro-tips hvis du vil, som enkelt kan brukes på toppen av det ovennevnte.
De dynamiske policyene kan utnyttes ikke bare for å tildele tilgangsrettigheter for mappeplasseringer, men også for å tildele tjenesterettigheter for bøttene og brukergruppene automatisk!
Alt som trengs er å utvide listen over tagger på bøttene og deretter legge til dynamiske policytilgangsrettigheter for å bruke spesifikke tjenester for konkrete brukergrupper.
For eksempel kan det være en gruppe brukere som også trenger tilgang til den spesifikke databaseklyngeserveren. Dette kan utvilsomt oppnås ved dynamiske retningslinjer som utnytter bøtteoppgaver, mer hvis tilgangen til tjenestene er drevet av en rollebasert tilnærming. Bare legg til den dynamiske policykoden en del som vil behandle tagger angående databaseklyngespesifikasjonen og tildele policytilgangsrettighetene til den bestemte DB-klyngen og brukergruppen direkte.
På denne måten vil introduksjonen av en ny brukergruppe være kjørbar bare av denne ene dynamiske policyen. I tillegg, siden den er dynamisk, kan den samme policyen gjenbrukes for onboarding av mange forskjellige brukergrupper (forventes å følge samme mal, men ikke nødvendigvis de samme tjenestene).
Du kan også ta en titt på disse AWS S3-kommandoene for å administrere bøtter og data.