2025-01-02

Het twee-gelaagde authenticatie en autorisatie-systeem in AWS

Bij AWS is de IAM-service een van de eerste diensten die je leert kennen. Het systeem controleert wie je bent en verleent toegang tot AWS-diensten. Authenticatie en autorisatie zijn gescheiden, maar om IAM volledig te benutten, gebruik je vaak een derde laag: het aannemen van een rol.

Stappen in het AWS-beveiligingsproces

Stap 1: Authenticatie

Authenticatie bepaalt of je bent wie je beweert te zijn. Dit kan via een gebruikersnaam en wachtwoord, API-aanroepen met access keys, of externe identiteitsproviders zoals SSO. Two-factor-authenticatie en andere checks versterken dit proces. Authenticatie bewijst je identiteit, maar verleent nog geen toegang tot resources.

Stap 2: Rolaanname (Switch Role)

Naast authenticatie en autorisatie speelt rolaanname een sleutelrol in AWS. Na authenticatie kun je een specifieke rol aannemen, wat je toegang geeft tot de benodigde resources.

Stel, je werkt met meerdere AWS-accounts. Via een centrale identiteitsprovider log je in en neem je een rol aan die specifiek rechten verleent binnen een account. Dit scheidt authenticatie van autorisatie en biedt flexibiliteit. Binnen één account kun je ook meerdere rollen gebruiken, afhankelijk van je taak.

Een voorbeeld: een SRE of Ops-engineer heeft vaak een read-only rol nodig voor inspectie in de console, terwijl geautomatiseerde processen een rol met read-write rechten vereisen. Zo blijft het beheer efficiënt én veilig. Rolaanname werkt ook over meerdere accounts heen, wat het beheer van complexe omgevingen vereenvoudigt.

Stap 3: Autorisatie

Met een actieve rol bepaalt AWS wat je mag doen via policies. Deze specificeren toegestane acties en resources.


Configuratie van Policies en Rollen

Policies en rollen worden als volgt geconfigureerd in AWS:

  • Policies worden gemaakt in JSON-formaat en bevatten statements die acties en resources specificeren
  • Rollen zijn identiteiten met gekoppelde policies. Ze hebben geen gebruikersnaam/wachtwoord.
  • Rollen worden aangenomen na authenticatie om toegang te krijgen tot resources.
  • Policies worden aan rollen gekoppeld, niet aan gebruikers of groepen, voor consistentie en veiligheid.

Bij rol-aannames moeten policies altijd aan rollen worden gekoppeld, niet aan gebruikers of groepen. Dit bevordert consistentie en veiligheid.

Voorbeelden van Rolgebruik

Een duidelijk voorbeeld van rolaanname komt naar voren in de manier waarop verschillende rollen binnen één account worden gebruikt:

  • Data-engineer: Deze rol heeft leesrechten op opslag en beheersrechten op AI-services, wat essentieel is voor het uitvoeren van analyses en beheren van modellen. Wanneer we er even van uit gaan dat de AI diensten door een derde bedrijf geleverd worden, kan de authenticatie van de persoon die dit doet extern gebeuren. Wat toegestaan is voor deze externe gebruikers wordt wel degelijk in de eigen AWS account gedaan.
  • ETL-ingenieur: Deze rol biedt schrijf- en bewerkingsrechten op opslag om data efficiënt te kunnen verwerken binnen de ETL-pipeline. Dit maakt het mogelijk om grote datasets te transformeren en op te slaan. De ingenieur maakt deel uit van het bedrijf zelf, en dus de authorisatie verloopt via de interne kanalen. Dit kan rechtstreeks in AWS zijn, of via bvb een Active Directory koppeling. 
  • Automatisatie voor backups: Een geautomatiseerd proces neemt een specifieke backup-rol aan, waarmee het alleen toegang krijgt tot het lezen van kritieke gegevens en het wegschrijven van backups naar een veilige opslaglocatie. De authorisatie verloopt hier via interne systemen van AWS, waar processen rechten hebben om rollen aan te nemen zonder menselijke tussenkomst.

Deze voorbeelden illustreren hoe rollen specifiek kunnen worden afgestemd op taken, wat zorgt voor een veilig en doelgericht toegangsbeheer.

Rolaanname als basis voor geavanceerde AWS-concepten

Rolaanname is niet alleen voor gebruikers. Het vormt ook de basis voor diensten zoals Pod Identity in EKS en rechtenbeheer voor Lambda-functies. Hier nemen applicaties tijdelijke rollen aan, waardoor beveiliging en flexibiliteit worden gewaarborgd zonder vaste inloggegevens.


Krane Labs en AWS IAM Best Practices

Bij Krane Labs passen we niet alleen IAM best practices toe, maar helpen we klanten ook om hun AWS IAM gebruik te optimaliseren door:

  • Advisering over het opzetten van een geoptimaliseerde multi-account structuur
  • Implementatie van least-privilege toegangsmodellen met rollen en policies
  • Integratie van IAM met identity providers voor centraal gebruikersbeheer
  • Best practices voor het beheer van access keys en tijdelijke credentials
  • Monitoring en alerting configuratie voor beveiligingsrisico's

Belangrijk om te vermelden is dat wij bij Krane Labs via rollen toegang krijgen van onze eigen AWS-account naar de accounts van klanten die we beheren. Dit stelt ons in staat om efficiënt en veilig te werken in de omgevingen van onze klanten, zonder dat we directe toegang tot hun credentials nodig hebben, of zonder dat er extra gebruikers aangemaakt worden in het account van onze klanten. Deze aanpak is een voorbeeld van de IAM best practices die we hanteren.

Voordelen van dubbele authenticatie

Dubbele authenticatie biedt meer beveiliging, schaalbaarheid, flexibiliteit en traceerbaarheid. Het laat organisaties meerdere AWS-accounts beheren en maakt de scheiding tussen authenticatie en autorisatie duidelijk.

Conclusie

IAM is de kern van authenticatie en autorisatie in AWS. Door gebruik te maken van rolaanname en dubbele authenticatie kunnen organisaties hun beveiliging en flexibiliteit drastisch verbeteren. Bij Krane Labs hebben we uitgebreide ervaring met het opzetten en optimaliseren van IAM in AWS. Bij Krane Labs maken we dagelijks gebruik van rolaanname om efficiënt en veilig verschillende klanten te bedienen. Dit systeem geeft ons de flexibiliteit om probleemloos in complexe multi-accountomgevingen te werken. We ondersteunen onze klanten ook actief in het verbeteren van hun gebruik van AWS-accounts en rolwisselingen. We staan klaar om je te helpen je AWS-omgeving veilig en schaalbaar te maken.

Onze laatste blogposts