Autorisatie met Azure AD

  • Artikel
  • 6 minuten om te lezen

Autorisatie is een proces waarbij toegang tot een systeem wordt verleend of wordt ontnomen door te controleren of de accessoires de machtigingen hebben om de aangevraagde actie uit te voeren. De accessoires in deze context zijn de workload (cloudtoepassing) of de gebruiker van de workload. De actie kan operationeel zijn of betrekking hebben op resourcebeheer. Er zijn twee hoofdmethoden voor autorisatie: op rollen gebaseerd en op basis van resources. Beide kunnen worden geconfigureerd met Azure AD.

Belangrijkste punten

  • Gebruik een combinatie van op rollen gebaseerde en op resources gebaseerde autorisatie. Begin met het principe van de minste bevoegdheden en voeg meer acties toe op basis van uw behoeften.
  • Definieer duidelijke regels van verantwoordelijkheid en scheiding van taken voor toepassingsrollen en de resources die verantwoordelijk zijn voor het beheer ervan. Houd rekening met de toegangsniveaus van elke operationele functie, zoals machtigingen die nodig zijn om de productie-release te publiceren, toegang te krijgen tot klantgegevens, databaserecords te bewerken.
  • Geef geen permanente toegang voor kritieke accounts. Toegangsmachtigingen verhogen die zijn gebaseerd op goedkeuring en tijdsgebonden zijn met behulp van Azure AD Privileged Identity Management (Azure AD PIM).|

Autorisatie op basis van rollen

Deze aanpak autoreert een actie op basis van de rol die is toegewezen aan een gebruiker. Voor sommige acties is bijvoorbeeld een beheerdersrol vereist.

Een rol is een set machtigingen. De beheerdersrol heeft bijvoorbeeld machtigingen om alle lees-, schrijf- en verwijderbewerkingen uit te voeren. De rol heeft ook een bereik. Het bereik geeft de beheergroepen, abonnementen of resourcegroepen aan waarin de rol mag worden gebruikt.

Het toepassen van consistente machtigingen op resources via beheergroepen of resourcegroepen vermindert het toenemen van aangepaste, specifieke machtigingen per resource. Aangepaste machtigingen op basis van resources zijn vaak niet nodig en kunnen verwarring veroorzaken omdat ze hun intentie niet naar nieuwe vergelijkbare resources dragen. Dit proces kan zich opstapelen in een complexe verouderde configuratie die moeilijk te onderhouden of te wijzigen is zonder dat u bang bent iets te verbreken en negatieve gevolgen heeft voor zowel de beveiliging als de flexibiliteit van de oplossing.

Houd bij het toewijzen van een rol aan een gebruiker rekening met welke acties de rol kan uitvoeren en wat het bereik van deze bewerkingen is. Hier zijn enkele overwegingen voor roltoewijzing:

  • Gebruik ingebouwde rollen voordat u aangepaste rollen maakt om de juiste machtigingen te verlenen aan VM's en andere objecten. U kunt ingebouwde rollen toewijzen aan gebruikers, groepen, service-principals en beheerde identiteiten. Zie Ingebouwde rollen in Azure voor meer informatie.

  • Als u aangepaste rollen moet maken, verleent u rollen met de juiste actie. Acties worden gecategoriseerd in operationele acties en gegevensacties. Om overbeperk te voorkomen, begint u met acties met de minste bevoegdheden en voegt u meer toe op basis van uw operationele of gegevenstoegangsbehoeften. Bied uw technische teams die machtigingen implementeren duidelijke richtlijnen. Zie Aangepaste Azure-rollen voor meer informatie.

  • Als u een segmentatiestrategie hebt, wijst u machtigingen toe met een bereik. Als u bijvoorbeeld beheergroep gebruikt ter ondersteuning van uw strategie, stelt u het bereik in op de groep in plaats van de afzonderlijke abonnementen. Dit zorgt voor consistentie en zorgt voor een toepassing voor toekomstige abonnementen. Bij het toewijzen van machtigingen voor een segment moet u consistentie overwegen en tegelijkertijd flexibiliteit bieden voor verschillende organisatiemodellen. Deze modellen kunnen variëren van één gecentraliseerde IT-groep tot voornamelijk onafhankelijke IT- en DevOps-teams. Zie AssignableScopesvoor meer informatie over het toewijzen van een bereik.

  • U kunt beveiligingsgroepen gebruiken om machtigingen toe te wijzen. Er zijn echter nadelen. Het kan complex worden omdat de workload moet bijhouden welke beveiligingsgroepen overeenkomen met welke toepassingsrollen, voor elke tenant. Toegangstokens kunnen ook aanzienlijk toenemen en Azure AD bevat een claim voor uitval om de tokengrootte te beperken. Zie Microsoft identity platform toegangstokens.

  • Wijs toegang tot Azure AD-groepen toe in plaats van machtigingen te verlenen aan specifieke gebruikers. Bouw daarnaast een uitgebreid delegeringsmodel met beheergroepen, abonnementen of resourcegroepen RBAC. Zie Op rollen gebaseerd toegangsbeheer van Azure (Azure RBAC)voor meer informatie.

Zie Autorisatie op basis van rollen voor meer informatie over het implementeren van ASP.NET op rollen gebaseerde autorisatiein een toepassing.

Meer informatie

Op resources gebaseerde autorisatie

Met op rollen gebaseerde autorisatie krijgt een gebruiker hetzelfde niveau van controle over een resource op basis van de rol van de gebruiker. Er kunnen echter situaties zijn waarin u per resource toegangsrechten moet definiëren. In een resourcegroep wilt u bijvoorbeeld toestaan dat sommige gebruikers de resource verwijderen; andere gebruikers kunnen dit niet. In dergelijke situaties gebruikt u op resources gebaseerde autorisatie die een actie op basis van een bepaalde resource autorisaties. Elke resource heeft een Eigenaar. De eigenaar kan de resource verwijderen. Inzenders kunnen lezen en bijwerken, maar niet verwijderen.

Notitie

De rollen Eigenaar en Inzender voor een resource zijn niet hetzelfde als toepassingsrollen.

U moet aangepaste logica implementeren voor autorisatie op basis van resources. Deze logica kan een toewijzing zijn van resources, Een Azure AD-object (zoals rol, groep, gebruiker) en machtigingen.

Zie Op resources gebaseerde autorisatie voor informatie en codevoorbeelden over het implementeren van op resources gebaseerde autorisatie in een ASP.NET-toepassing.

Autorisatie voor kritieke accounts

Het kan zijn dat u activiteiten moet uitvoeren waarvoor toegang tot belangrijke resources is vereist. Deze resources zijn mogelijk al toegankelijk voor kritieke accounts, zoals een beheerdersaccount. Of mogelijk moet u de toegangsmachtigingen verhogen totdat de activiteiten zijn voltooid. Beide benaderingen kunnen aanzienlijke risico's met zich meebrengen.

Kritieke accounts zijn accounts die een bedrijfskritiek resultaat kunnen opleveren, of het nu gaat om cloudbeheerders of workloadspecifieke gebruikers met bevoegdheden. Gecompromitteerd of misbruik van een dergelijk account kan een nadelig effect hebben op het bedrijf en de informatiesystemen. Het is belangrijk om deze accounts te identificeren en processen te gebruiken, waaronder bewaking in de buurt en levenscyclusbeheer, inclusief pensioen.

Het beveiligen van bevoegde toegang is een kritieke eerste stap om beveiliging van de bedrijfsassets in een moderne organisatie te garanderen. De beveiliging van de meeste of alle zakelijke activa in een IT-organisatie is afhankelijk van de integriteit van de bevoegde accounts die worden gebruikt voor het beheren, beheren en ontwikkelen. Cyberattackers richten zich vaak op deze accounts en andere elementen van bevoegde toegang om toegang te krijgen tot gegevens, en systemen die gebruikmaken van aanvallen met referentiediefstal, zoals Pass-the-Hash en Pass-the-Ticket.

Voor het beveiligen van bevoegde toegang tegen aanvallers moet u een volledige en zorgvuldige benadering gebruiken om deze systemen te isoleren van risico's.

Worden er processen en hulpprogramma's gebruikt om bevoegde activiteiten te beheren?

Geef geen permanente toegang voor kritieke accounts en lagere machtigingen wanneer toegang niet meer vereist is. Enkele strategieën zijn:

  • Bevoegde Just-In-Time-toegang tot Azure AD- en Azure-resources.
  • Tijdsgebonden toegang.
  • Toegang op basis van goedkeuring.
  • Break glass voor het toegangsproces in noodgevallen om toegang te krijgen.

Beperk schrijftoegang tot productiesystemen tot service-principals. Gebruikersaccounts mogen geen normale schrijftoegang hebben.

Zorg ervoor dat er een proces is voor het uitschakelen of verwijderen van niet-gebruikte beheerdersaccounts.

U kunt native opties en opties van derden gebruiken om toegangsmachtigingen uit te voeren voor ten minste zeer bevoegde, zo niet alle activiteiten. Azure AD Privileged Identity Management (Azure AD PIM) is de aanbevolen native oplossing in Azure.

Zie Wat is Azure AD Privileged Identity Management? voor meer informatie over PIM.

Lees meer

Levenscyclusbeheer voor accounts met kritieke gevolgen vaststellen

Terug naar het hoofdartikel: Overwegingen voor Identiteits- en toegangsbeheer van Azure