Schaal Identity Access Management: Van Startups tot Enterprise met AWS Oplossingen, deel 1

Als een startup uitgroeit tot een enterprise, is Identity Access Management (IAM) één van de grootste uitdagingen waar een organisatie voor komt te staan.

Als onbevangen nieuwkomer besteedde je niet veel aandacht wie en wat allemaal toegang had tot bedrijfsapplicaties. Er waren toch maar een paar gebruikers. Emailadressen begonnen met John, Lois of Marieke en achter het apenstaartje stond je bedrijfsnaam. Je kende iedereen bij zijn voornaam en je vertrouwde iedereen.

Maar toen je bedrijf succesvoller werd en groeide, nam je een tweede John aan en begon het. Plots moest je gebruikers op een andere manier on-boarden. Er kwamen andere email-adressen, met andere gebruikersnamen. Je wilde de nieuwe John liever geen toegang geven tot allerlei gevoelige financiële bedrijfsinformatie. Dus maakte je securitygroepen, waarbij je data veilig verborg achter je identity access management systeem. Dat systeem dat je tot dan toe links had laten liggen.

We spoelen nu snel een paar jaar vooruit. Je bedrijf is gegroeid en verandert voortdurend. Er is nu een compleet team dat zich bezighoudt met identiteits- en toegangscontrole. Er zijn mensen die een fulltime baan hebben aan het onboarden van nieuwkomers en het offboarden van vertrekkers. Er komen afdelingen bij en bestaande afdelingen worden gereorganiseerd. Dat betekent dat er steeds van alles veranderd als het gaat om security-groepen.

En nu migreert je bedrijf dan naar AWS. Complete afdelingen staan al te popelen om met het nieuwe speelgoed aan de slag te mogen gaan. Hoe kan jouw IAM team in deze nieuwe omgeving in ’s hemelsnaam snel genoeg al die duizenden gebruikers tevreden stellen, en al die groepen managen? Want dat is wel nodig om aan de behoeften van de business te voldoen. Tegelijkertijd mag het securityniveau dat door de jaren heen is opgebouwd niet in het gedrang komen.

Gelukkig is er AWS IAM Identity Center en AWS Organizations met Service Control Policies (SCP). Daarmee beheer je eenvoudig de gebruikers en groepen die je hebt gemaakt met je bestaande oplossing voor identiteitscontrole. Aan de AWS-kant kost het je heel weinig tijd.

Maar laten we, voor we de diepte ingaan, eerst eens wat meer uitleg geven over alle diensten en afkortingen, zodat je ze beter kunt plaatsen. Ken je alle relevante AWS services al, dan kun je meteen doorklikken naar het tweede deel van deze blog.

IAM policy basis principes

Ik vat toegangs- of acces control in AWS vaak samen met dit statement: "Weigeren, tenzij toegestaan, tenzij geweigerd."

Dit betekent dat iets of iemand binnen AWS standaard niet de rechten heeft om iets te doen, tenzij deze rechten zijn gegeven EN niet expliciet zijn ontzegd. Het deel achter ‘en’ is het allerbelangrijkste.

Dus volledig uitgeschreven is het: ‘impliciet geweigerd, tot expliciet toegestaan, tot expliciet geweigerd’.

Wie of wat binnen AWS wordt toegestaan of geweigerd, ligt vast in het Identity Acces Management (IAM) beleid. Deze beleidsregels zijn documenten met JSON-indeling, die heel precies uiteenzetten wat een ‘principal’ in een bepaalde context wel en niet mag.

Deze ‘principal’ (opdrachtgever in het Nederlands) is de initiator van een actie en kan een IAM-gebruiker of een applicatie zijn. Want binnen AWS mag niets of niemand iets doen zonder dat het volgens IAM beleid is toegestaan.

Maar je zit met je beleid niet op een eiland. Regels zijn verbonden met allerlei verschillende ‘dingen’.  

Stel dat je beleid is gebaseerd op identiteit. Dan hangt je beleid dus vast aan IAM-rollen, die op hun beurt kunnen worden aangenomen door een ander AWS-resource of IAM-gebruiker. Het beleid kan ook rechtstreeks worden toegewezen aan IAM-gebruikers of groepen.

Is je beleid gebaseerd op bronnen, dan wordt het rechtstreeks gekoppeld aan een AWS-bron. Die wordt vervolgens gebruikt om te bepalen welke rechten de ‘principal’ heeft op deze bron.

Dit zijn de onderdelen van beleid:

• Version/Versie: Het beleid is gedefinieerd in een taal waarvan twee versies zijn. De ene is van 17-10-2008, de andere van 17-10-2012. AWS moet deze taal correct kunnen ontleden.
• Statement/Verklaring: bevat een of meerdere beleidsverklaringen (statements).

Binnen het statement wordt het beleid als volgt gedefinieerd.

Principal

Definieer hier de ‘principal’/opdrachtgever (initiator van de actie) waar het beleidsstatement op van toepassing is.

Is de initiator gedefinieerd, dan moet die overeenkomen met een IAM-gebruiker, -groep of rol, of met een AWS service. Dit kan zo breed zijn als een compleet AWS-account, of zo smal als een enkele IAM-gebruiker.

Een paar voorbeelden:

• AWS Account: "Principal": {"AWS": "arn:aws:iam::045676890123:root"}
• AWS Service: "Principal": {"Service": "delivery.logs.amazonaws.com"}
• STS Assumed Role: "Principal": {"AWS": "arn:aws:sts::045676890123:assumed-role/{rolename}"}
• AWS Role: "Principal": {"AWS": "arn:aws:iam::045676890123:role/{rolename}"}

Als het beleid met identiteit te maken heeft, hoeft het niet te worden gedefinieerd. Dat is omdat het is afgeleid van de opdrachtgever waaraan het is verbonden.

Wanneer hetgeen waaraan het verbonden is een op bronnen gebaseerd object is, dan is het wel nodig om te definiëren welke ‘principals’ met de bron mogen interacteren.

Effect

Does the policy either "Allow" or "Deny" the action defined in the policy.

Action

Action, of actie definieer een activiteit binnen AWS.

Acties worden aangeduid als “{service}:{action}” waarbij je een deel of het geheel kunt vervangen door een joker (wildcard) *. Voorbeelden zijn:

Zonder beveiliging met een resource- of conditie-statement, zal toegang tot elk onderdeel van een AWS-account of bron worden verleend.

Acties kun je definiëren als “Action” of “NotAction”. Daarmee creëer je respectievelijk een white- of een blacklist. In combinatie met “Effect: Deny” creëer je een ‘dubbele negatieve stijl’. Hier zoomen we later op in.

Resource

Definieer de AWS resource of bron waartoe je de Action wilt beperken. Deze bron moet je definiëren volgens het Amazon Resource Names (ARN) format. Eén of meer jokers (*) kun je inzetten om meer bronnen binnen de beleidsbepalingen te laten vallen.

Enkele voorbeelden:

Condition

Een Condition of voorwaarde, restrictie, is een optioneel statement dat een of meer sub-statements kan bevatten. Op die manier maak je aanvullende toelatingen of beperkingen mogelijk, bovenop Principal/Actie en bron.

Binnen deze voorwaarden kun je logicachecks uitvoeren. Denk aan het vergelijken van waarden van de aanroepende ‘principal’ met de doelbron. Een andere veelgebruikte voorwaarde is dat er wordt gecontroleerd op onversleuteld verkeer. Als dat er is, wordt het geblokkeerd.

Volledig IAM beleid

Breng je nu alles samen dan krijg je beleid als in de twee voorbeelden die je hieronder vindt:

{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "*",
"Resource": "*"
}
] 
}

Dit op identiteit gebaseerde beleid geeft beheerder- of admin-rechten voor het volledige AWS-account:

{
"Version": "2012-10-17",
"Statement": [
{
"Principal": {
"AWS": "arn:aws:iam::045676890123:root"
},
"Effect": "Allow",
"Action": "S3:PutObject",
"Resource": "arn:aws:s3:::accesslogs/*",
"Condition": {
"Bool": {
"aws:SecureTransport": "true"
} 
}
} 
] 
}

Dit op bronnen gebaseerde beleid geeft alle initiators (principals) die horen bij account 045676890123 toestemming om wijzigingen aan te brengen in de ‘’access logs’’ bucket, zolang de verbinding maar versleuteld is:

Samenvattend

Als binnen AWS een verzoek wordt gedaan, worden alle beleidsregels die gekoppeld zijn aan de aanvrager en de opgevraagde bron, gecombineerd tot één enkele beleidsregel. Als dan minstens één mogelijkheid voor ‘’toestaan’’ wordt gevonden en geen voor ‘’weigeren”, dan wordt toegang verleend.

AWS Organizations

AWS Organizations is ontworpen voor gebruik door organisaties die de AWS accounts die hun eigendom zijn, effectiever centraal willen beheren. De dienst wordt ook wel afgekort tot AWS Org.

Je kunt er AWS accounts mee groeperen op een hiërarchische manier. Je kunt zo bijvoorbeeld verschil maken tussen afdelingen binnen je organisatie, op basis van de vereisten die het bedrijf stelt.

Elke laag of organisatie-unit (OU) herbergt een of meer AWS accounts. Er kunnen meerdere beleidsvormen gekoppeld zijn aan de laag of de accounts zodat je toegangsbeheer vergaand kunt verfijnen. Deze mogelijkheden zijn beschikbaar:

• Back-up beleid ­ ‑ Zeker zijn dat AWS back-up strategieën op een consistente manier worden geïmplementeerd
• Tagging-beleid – Standaardiseer tags op alle ondersteunde bronnen
• Beleid voor service controle beleid (SCP) – Controleer IAM-rechten binnen het AWS account
• AI-services opt-out beleid – Controleer wat AI-diensten kunnen opslaan en welke content binnen een account ze kunnen gebruiken om hun werk te doen

Als bepaald beleid op een organisatie-unit wordt toegepast, is dit van invloed op alle onderliggende units en AWS accounts, zoals je ziet in het plaatje hierboven.

Beleid voor servicecontrole (SCP)

Je voegt een extra beveiligingslaag toe aan je AWS accounts met beleid voor servicecontrole. Daarmee verleen je al dan niet toegang tot bronnen.

We hebben het al gehad over hoe IAM beleidsregels in elkaar zitten. Wat op dit punt belangrijk is om te weten, is dat wanneer je AWS Org inschakelt, je een stap toevoegt.

Taggingbeleid

Het laatste onderdeel dat ik wil uitlichten binnen AWS Organizations is het taggingbeleid. Daarmee kun je afdwingen hoe bronnen worden getagd.

Maar ze bepalen niet dat een specifieke tag of label wordt gebruikt.

{
"tags": {
"department": {
"tag_key": {
"@@assign": "Department"
},
"tag_value": {
"@@assign": [
"finance",
"sales",
"security"
]
},
"enforced_for": {
"@@assign": [
"ec2:instance",
"kms:*"
]
}
}
}
}

Het beleid in dit voorbeeld bepaalt dat wanneer de tag “department” wordt gebruikt, het een van de drie waardes moet hebben die gedefinieerd zijn onder ‘’tag_value”. Deze tag wordt bovendien alleen toegepast op ec2:instance en alle kms resources.

Het is belangrijk dat je het doel van taggingbeleid goed begrijpt. Het is bedoeld om aan compliancy eisen te voldoen. Als je de Management console gebruikt of de AWS CLI, dan kun je een rapportage uitdraaien waarin staat welke bronnen niet compliant zijn. Je kunt deze later aanpassen.

Bovendien: niet elke bron kun je taggen. "ec2:*" bijvoorbeeld, wordt niet ondersteund en specifieke bronnen moet je apart definiëren. Een complete lijst vind je hier.

Schakel je AWS Org in, dan schakel je ook andere services in en wordt centraal functioneel beheer van bestaande diensten mogelijk.

Dit zijn voorbeelden van belangrijke services binnen AWS Org en die relevant zijn voor dit blog:

Gecentraliseerde facturering (gratis)

Zodra AWS Org aanstaat, rapporteert elk account in de AWS-omgeving zijn AWS-service verbruik aan het zogeheten master-factureringsaccount. Dat betekent dat je een factureringsdashboard krijgt met daarop één enkele factuur. Dit is een geweldige manier om kosten te analyseren, per service, account of tagging die je hebt ingeschakeld voor factureringsdoeleinden.

AWS IAM Identity Center (gratis)

Deze dienst heette voorheen AWS Single Sign-On. Met Identity Center kan de organisatie de AWS Management Console centraal beheren en controleren. Hetzelfde geldt voor het verlenen van toegang tot API’s aan individuele gebruikers en groepen van alle AWS-accounts binnen de organisatie. Dit is mogelijk door gebruik van ingebouwde functionaliteit van IAM-IC of door verbinding te maken met een externe Identity provider zoals Okta of AzureAD.

In het volgende hoofdstuk gaan we dit gedetailleerder bekijken.

Enterprise support (betaald)

Standaard AWS accounts kennen drie support-niveaus:

• Basic: geldt alleen zaken op het gebied van accounts, facturering en zakelijke ondersteuning
• Developer: opent de mogelijkheid om technische ondersteuningsaanvragen te loggen.
• Business: voegt P1- en P2-urgentie toe aan supportcases, voor snellere actie.

Voor grote bedrijven is er nog een vierde niveau: Enterprise support. Dit bestaat uit de onderdelen ‘Enterprise On-Ramp’ en ‘Enterprise’. Deze worden ingesteld op organisatieniveau, elk afzonderlijk account krijgt de hoogst beschikbare ondersteuning. De eerste drie ondersteuningsopties worden ingesteld op accountniveau.

AWS IAM Identity Center

AWS IAM Identity Center is als gezegd de opvolger van AWS SSO. Het is de single sign-on oplossing voor AWS accounts die zijn samengevoegd in een AWS Org. Met Identity Center krijg je een centraal punt van waaruit je gebruikers en groepen beheert met behulp van machtigingensets. Tot welke accounts krijgen ze toegang, welke rechten hebben ze binnen deze accounts?

Standaard is het root account van de AWS Org de administrator is van Identity Center. Maar je kunt dat ook veranderen en hiervoor een specifiek IAM of securityaccount aanwijzen. Dit voorkomt dat te veel gebruikers toegang hebben tot wat waarschijnlijk het belangrijkste account is binnen de AWS org.

Een machtigingenset bestaat uit een of meer van de volgende IAM beleidsregels:

• Door AWS beheerd beleid
• Door klanten beheerd beleid
• Inline beleid, dus rechtstreeks gedefinieerd in de machtigingenset
• Optioneel, grenzen stellen aan machtigingen

Als een machtigingenset onderdeel is van een ledenaccount, wordt een IAM-rol gemaakt volgens beleid dat overeenkomt met de specifieke rechten die zijn gedefinieerd in deze set. Denk aan een bijgevoegd of een inline beleid. Deze IAM-rollen (en beleidsregels) zijn beschermd, je kunt ze niet wijzigen vanuit een het ledenaccount.

Meldt een gebruiker zich aan via Identity Center, dan kunnen ze de IAM-rol in het ledenaccount op zich nemen, om binnen dit account te werken. Natuurlijk binnen de grenzen die bij deze rol horen.

De kracht van AWS IAM Identity Center zit hem in de mogelijkheid tot integratie met identiteitsproviders die compatible zijn met Security Assertion Markup Language (SAML) 2.0. De meeste organisaties gebruiken al zo’n provider om gebruikers te managen, bijvoorbeeld Okta, Active Directory Federation Service (ADFS) of Ping.

Je kunt nog een stap verder gaan door een systeem te gebruiken voor Cross-Domain Identity Management (SCIM). Daarmee synchroniseer je gebruikers en groepen van SAML Identity providers en IAM Indentity Center.

Het resultaat is dat organisaties een single sign-on omgeving kunnen opzetten, waar gebruikers toegang krijgen tot AWS met dezelfde inloggegevens als die ze gebruiken voor bijvoorbeeld hun desktop, laptop, email en andere werkomgevingen. Een keer inloggen is meestal genoeg.

Attribute based access control

Identity Center kent ook een wat verborgen feature, die niet standaard is ingeschakeld: attribute-based acces control (ABAC). Dit wordt ook wel op kenmerken gebaseerd toegangsbeheer genoemd. Dit stelt je in staat om toegang te verlenen aan gebruikers op een totaal nieuwe manier, met variabelen die door de organisatie zelf zijn ingesteld.

In een eenvoudige Azure AS SAML & SCIM configuratie worden alleen deze gebruikerskenmerken gesynchroniseerd:

Lees meer

Zoals de naam van de dienst al aangeeft, kun je al deze kenmerken gebruiken om toegang binnen AWS te regelen zoals jij wilt.