Hvordan holder man styr på sine cloud-miljøer, og kan man sætte nogle regler op som garderer mod de værste bommerter? Det vil vi give jer et bud på – baseret på vores egne erfaringer og AWS-standard anbefalinger. Vi vil komme ind på de typiske anvendte begreber, organisering af miljøer, adgangskontrol, sikring af compliance, samt de tilhørende værktøjer. 

New servers? No problem!

Opsætning af miljøer til forskellige formål er nemt i AWS. Skal I bruge servere og database til en forretningsapplikation? Tjek. Brug for testmiljø til det? Done. Skal I eksperimentere med noget nyt? Ikke noget problem.

Det er nemt, og hvis man ovenikøbet kan finde ud af at kode lidt for at automatisere processen, får man lynhurtigt bygget en masse infrastruktur. Og det er naturligt at flere medarbejdere (f.eks. Anne, Frank og Arne) får adgang til at kunne arbejde og eksperimentere – hele idéen er jo at folk skal være selvhjulpne. 

Når hvedebrødsdagene slutter

Men så er der bagsiden af medaljen. For måske har Anne godt styr på AWS og er meget sikkerhedsbevidst. Og hun har også fortalt Frank og Arne hvordan man gør det “rigtigt”. Men i kampens hede er det meget nemmere for Arne “bare lige” at gå ind i konsollen og spinne et par test-servere op. Og måske gøre dem “X-Large” for en sikkerheds skyld. Og måske er det hurtigere lige at enable brugernavn/password på serveren i stedet for det der certifikat, som er lidt besværligt at hente ned fra fællesdrevet (hvor det i øvrigt aldrig bør ligge), bare som en tjeneste for Frank, som aldrig kan huske hvor det ligger.

Og så er der det med lige at huske at få slettet de servere igen, når de ikke skal bruges længere… 

What to do?

Lad os få styr på det basale

AWS definerer nogle abstraktioner som er nyttige at kende til, når man sætter sine miljøer op. De mest basale er Accounts, Organizations og Organizational Units (OUs). Desuden anvendes begrebet workload, som dækker over en kollektion af ressourcer (f.eks. servere og databaser) og applikationskode, som understøtter et system der bringer forretningsværdi (f.eks. en kundevendt web-applikation eller et internt CRM-system).
Workloads og tilhørende infrastruktur anbefales at blive provisioneret og administreret i forskellige konti (accounts). En account er en administrativ enhed, hvortil der kan gives differentieret adgang. Accounts kan organiseres i Organizations, hvortil man kan benytte OUs til at gruppere og administrere accounts som en samlet enhed.

Puha, det var mange nye begreber… Lad os se på hvordan det rent praktisk kan implementeres:

Eksempel på organisering af accounts med Organizations og Organizational Units

Som vist på diagrammet ovenfor, er der oprettet en account og en OU per applikationsmiljø (udvikling, test og produktion) for hvert givet system/workload. Hovedårsagerne til at lave denne opdeling er for at skærpe adgangene til de specifikke applikationsmiljøer og for at minimere “blast radius”, som definerer den maksimale skade der kan opstå i tilfælde af en systemfejl eller en menneskelig fejl. For eksempel skal et fejlklik i konsollen i et udviklingsmiljø, som Arne uagtsomt kan forårsage, ikke påvirke test- eller produktionsmiljøet. Mere generelt mindskes chancen for tværgående fejl i de forskellige miljøer ved at minimere blast radius til de enkelte workloads i isolerede accounts.

En Organization har også en root account, hvor det er muligt at konsolidere fakturering, så man kan få et overblik over hvad man har forbrugt i alle accounts. Man kan få én faktura for de services der bruges i hele organisationen, som dermed også kan bruges til procurement og intern afregning i virksomheden. Da det ikke koster noget at åbne en account, er det oplagt at bruge dem til opdeling af workloads.

AWS Control Tower

Organiseringen beskrevet i forrige afsnit kan ved første øjekast virke kompliceret, og måske tænker I, at det er svært at administrere og vedligeholde alle accounts. Så hvordan holder man styr på dem alle? Og hvordan styrer man brugeradgange til den enkelte account? Og hvordan kan man sikre alle accounts er compliant med påkrævede regler til f.eks. kryptering af data og logging? Her kommer AWS til undsætning med deres AWS Control Tower service.

AWS Control Tower er et utroligt kraftfuldt værktøj, der sikrer at miljøer opbygges og vedligeholdes med best practices indenfor sikkerhed og compliance. Nedenfor er de essentielle features opridset:

• Brugerstyring og adgangskontrol til de forskellige accounts styres ved hjælp af AWS Single Sign-On (AWS SSO) og Identity Access Management (IAM). Der er både mulighed for at integrere denne service med Microsoft Active Directory, Google Workspaces, m.fl., så eksisterende brugerkonti og adgangsstyringsgrupper kan benyttes i AWS.
• Et centraliseret og tværgående audit logning system sikrer, at brugeraktivitet, API-brug, og konfigurationen af ressourcer i alle accounts bliver logget og opbevaret ved hjælp af AWS CloudTrail og AWS Config.
• Et tværgående adgangssystem opsættes ved hjælp af IAM og AWS SSO, så sikkerhedsrevisioner kan opføres på tværs af accounts.
• AWS Control Tower kommer pakket med mange standard governance regler (såkaldte “guardrails”), der har til formål at håndhæve politikker og rapportere overtrædelser. Det kan f.eks. være at sikre at audit logning er slået til på alle accounts, og logs ikke kan slettes.
  Derudover er det muligt at udvide dette setup med egne regler ved brug af Service control policies (SCPs) og AWS Config. Det kan f.eks. være, at man ønsker at håndhæve at data på alle servere er krypteret på alle accounts i en OU for et produktions workload.

Key takeaways

Vi håber ovenstående har givet et overblik over basale begreber og tjenester som sikrer miljøerne. Det vigtigste takeaway bør være at AWS har investeret meget i at gøre det muligt for kunderne at bygge velorganiserede strukturer som understøtter en høj grad af gennemsigtighed og muliggør automatiseret kontrol af compliance med de regler I selv som virksomhed (eller jeres kunder) stiller op.