Ontdek onze cloud services
Optimaliseer jouw reis naar de cloud met SoftwareOne.
Ontdek onze cloud services
Optimaliseer jouw reis naar de cloud met SoftwareOne.
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.
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:
Binnen het statement wordt het beleid als volgt gedefinieerd.
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:
"Principal": {"AWS": "arn:aws:iam::045676890123:root"}
"Principal": {"Service": "delivery.logs.amazonaws.com"}
"Principal": {"AWS": "arn:aws:sts::045676890123:assumed-role/{rolename}"}
"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.
Does the policy either "Allow
" or "Deny
" the action defined in the policy.
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:
Action | Definition |
---|---|
s3:PutObject |
Maakt het schrijven van een object naar S3 mogelijk. |
kms:* |
Staat elke actie binnen de Key Management Service (KMS) toe. |
* |
Staat alles toe |
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.
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:
Action | Definition |
---|---|
arn:aws:s3:::accesslogs/* |
Which defines all objects within an S3 bucket called “accesslogs” |
arn:aws:kms:eu-west-1:045676890123:key/87132241-9a03-4c89-a723-af0b43aea2bc7 |
Definieert een specifieke KMS-sleutel binnen account 045676890123 in AWS-regio eu-west-1 |
* |
Definieert alle bronnen |
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.
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:
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.
Maar, als er binnen de policy een “Deny” wordt aangetroffen, dan gaat de deur dicht. Dus ook als ergens een regel met “Allow” bestaat.
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:
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.
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.
Waar eerst alleen een check op bronnen- en identiteitsbeleid werd gedaan, komt daar dus de servicecontrole bij.
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:
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.
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.
Standaard AWS accounts kennen drie support-niveaus:
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 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:
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.
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:
User attribute in IAM Identity Center | Maps to this attribute in your Microsoft AD directory |
---|---|
AD_GUID |
${dir:guid} |
email |
${dir:windowsUpn} |
Achternaam (familyName) |
${dir:lastname} |
Voornaam (givenName) |
${dir:firstname} |
Voorletters (MiddleName) |
${dir:initials} |
Naam (name) |
${dir:displayname} |
Gewenste gebruikersnaam (preferredUsername) |
${dir:displayname} |
Onderwerp (subject) |
${dir:windowsUpn} |
Dit zijn de kenmerken die je minimaal nodig hebt om aanmeldingen bij AWS succesvol uit te voeren. Wat ABAC mogelijk maakt is om meer kenmerken van AAD met Identity Center te synchroniseren. Voorbeelden hiervan zijn afdeling en kostenplaats, kantoorlocatie en functietitel.
Door deze gegevens door te geven aan AWS en te koppelen in ABAC, kan de Identity Provider hier direct naar verwijzen.
Zoals de naam van de dienst al aangeeft, kun je al deze kenmerken gebruiken om toegang binnen AWS te regelen zoals jij wilt.
Laten we nu al deze onderdelen samenvoegen, om op een gemakkelijke, veilige en flexibele manier toegang te bieden tot AWS. Lees verder in deel 2 van deze blog.
Optimaliseer jouw reis naar de cloud met SoftwareOne.
Optimaliseer jouw reis naar de cloud met SoftwareOne.