Inzicht in workloadidentiteiten

7 minuten

Implementatiewerkstromen, toepassingen en software vereisen een speciale manier om te verifiëren. In deze les leert u waarom workloadidentiteiten belangrijk zijn voor implementatiewerkstromen, hoe ze passen in het beveiligingsmodel van Azure en hoe ze werken.

Waarom moet een werkstroom worden geverifieerd?

Wanneer u een Bicep-bestand implementeert, vraagt u Azure Resource Manager effectief om uw Azure-resources te maken of te wijzigen. In het voorbeeldscenario hebt u een Bicep-bestand gemaakt om de website van uw speelgoedbedrijf te implementeren. Het Bicep-bestand declareert resources die een Azure-app Service-plan, een app en een Application Insights-exemplaar bevatten.

Wanneer u het bestand implementeert, controleert Resource Manager of de resources bestaan. Als ze dat niet doen, maakt Resource Manager ze. Als er al resources bestaan, zorgt Resource Manager ervoor dat de configuratie overeenkomt met de configuratie die u hebt opgegeven in het Bicep-bestand.

Voor al deze bewerkingen is een machtiging vereist, omdat ze uw Azure-resources openen en wijzigen. De specifieke machtigingen die nodig zijn voor implementatie, zijn afhankelijk van wat het Bicep-bestand bevat. Als u het voorbeeldbestand voor de website van uw speelgoedbedrijf wilt implementeren, moet u de volgende machtigingen hebben binnen de resourcegroep waarnaar u implementeert:

De mogelijkheid om implementaties te maken. Implementaties zijn resources met een type Microsoft.Resources/deployments.
De mogelijkheid om App Service-plannen en -apps te maken en te wijzigen.
De mogelijkheid om Application Insights-exemplaren te maken en te wijzigen.

Tot nu toe hebt u uw Bicep-bestanden waarschijnlijk zelf geïmplementeerd met behulp van de Azure CLI of Azure PowerShell. Wanneer u deze hulpprogramma's gebruikt, gebruikt u normaal gesproken uw eigen gebruikersaccount en verifieert u zich met behulp van uw browser. Dit wordt aangeroepen met uw eigen identiteit. Wanneer u een implementatie verzendt, controleert Azure of uw identiteit over de benodigde machtigingen beschikt om te doen wat uw Bicep-sjabloon aangeeft.

Nadat u naar een Implementatiewerkstroom van GitHub Actions bent overgekomen, moet u een ander type identiteit gebruiken, omdat de werkstroom implementaties uitvoert zonder dat u er direct bij betrokken bent.

Typen identiteiten

Microsoft Entra ID is de service waarmee identiteiten voor Azure worden beheerd. Enkele van de belangrijkste typen identiteiten zijn:

Gebruikersidentiteiten: een gebruiker vertegenwoordigt een mens die zich meestal interactief aanmeldt met behulp van een browser. Gebruikers hebben vaak extra beveiligingscontroles die moeten worden uitgevoerd wanneer ze zich aanmelden, zoals meervoudige verificatie (MFA) en voorwaardelijke toegang op basis van hun locatie of netwerk.
Groepen: Een groep vertegenwoordigt een verzameling gebruikers. Groepen verifiëren niet rechtstreeks, maar ze bieden een handige manier om machtigingen aan een set gebruikers samen toe te wijzen.
Identiteiten van workloads: een workload is een geautomatiseerd proces of systeem dat meestal niet rechtstreeks door een persoon wordt uitgevoerd. Een workload kan zich aanmelden bij Microsoft Entra ID, maar er is geen mens om zich aan te melden en te communiceren met het verificatieproces. Workloadidentiteiten hebben geen MFA- of vergelijkbare beveiligingen, omdat voor deze functies iemand iets moet doen om hun identiteit te bewijzen.

Deze module is gericht op workloadidentiteiten.

Beheerde identiteiten

Een beheerde identiteit is gekoppeld aan een Azure-resource. Azure beheert de referenties automatisch. Wanneer de resource toegang nodig heeft tot iets, meldt Azure zich automatisch aan met behulp van de referenties.

Beheerde identiteiten zijn beschikbaar voor door Azure gehoste resources, zoals virtuele machines en App Service-apps. Ze zijn een uitstekende manier voor Azure-resources om zichzelf te verifiëren voor situaties zoals het automatiseren van uw Azure-beheer, het maken van verbinding met databases en het lezen van geheime gegevens uit Azure Key Vault. U kunt ook beheerde identiteiten gebruiken met Azure Arc voor andere scenario's.

Wanneer u met implementatiewerkstromen werkt, gebruikt u meestal geen beheerde identiteiten. Voor beheerde identiteiten moet u de Azure-resources beheren die uw implementaties uitvoeren. Wanneer u met GitHub Actions werkt, bent u meestal afhankelijk van een gedeelde infrastructuur die Microsoft of GitHub biedt. Wanneer u echter een workloadidentiteit gebruikt met GitHub Actions, kunt u het belangrijkste voordeel krijgen van beheerde identiteiten: u hoeft geen referenties te beheren.

Tip

Als u in andere delen van uw oplossing een keuze hebt tussen het gebruik van een beheerde identiteit of het gebruik van een normale service-principal, kunt u het beste een beheerde identiteit gebruiken. Beheerde identiteiten zijn gemakkelijker te gebruiken en zijn meestal veiliger.

Waarom kunt u niet alleen uw gebruikersaccount gebruiken?

U vraagt zich misschien af waarom u dit hele nieuwe type object moet maken om een implementatiewerkstroom te verifiëren wanneer u gebruikersaccounts hebt die perfect werken.

Gebruikersaccounts zijn niet ontworpen voor gebruik zonder toezicht. Het verificatieproces voor een gebruikersaccount controleert vaak of een persoon de entiteit is die zich probeert aan te melden. Organisaties gebruiken steeds vaker extra beveiligingscontroles tijdens verificatie. Deze controles omvatten MFA, CAPTCHA-controles en het inspecteren van het apparaat en het netwerk dat de gebruiker gebruikt, zodat ze de geldigheid van een verzoek om zich aan te melden kunnen verifiëren.

Werkstromen zijn ontworpen om uw implementaties uit te voeren, zelfs wanneer niemand ze actief uitvoert. De meeste voordelen van implementatiewerkstromen zijn zelfs afkomstig van het feit dat ze geautomatiseerd zijn en geen menselijke interactie vereisen.

Als u uw gebruikersnaam en wachtwoord opslaat in een werkstroom en deze probeert te gebruiken om u aan te melden, werken ze waarschijnlijk niet. Zelfs als ze lijken te werken, kunnen ze in de toekomst eenvoudig breken als Microsoft Entra-id of uw organisatiebeheerder meer beveiligingscontroles toevoegt aan uw gebruikersverificatieproces.

Waarschuwing

Het is ook een slecht idee om uw gebruikersnaam en wachtwoord overal op te slaan, omdat iemand anders er toegang toe krijgt en deze vervolgens gebruikt om u te imiteren.

Om deze redenen kunt u met de ingebouwde GitHub Actions-taken die communiceren met Azure niet de referenties van een gebruikersaccount opgeven. Hiervoor moet u een workloadidentiteit gebruiken.

Hoe werken workloadidentiteiten?

Workloadidentiteiten zijn een functie van Microsoft Entra-id, een globale identiteitsservice. Veel bedrijven gebruiken Microsoft Entra ID en elk bedrijf wordt een tenant genoemd.

Microsoft Entra ID heeft een concept van een toepassing, die een systeem, stuk software, proces of een andere niet-menselijke agent vertegenwoordigt. U kunt ook een implementatiewerkstroom beschouwen als een toepassing.

Wanneer u een toepassing maakt en microsoft Entra-id hierover vertelt, maakt u een object met de naam een toepassingsregistratie. Een toepassingsregistratie vertegenwoordigt de toepassing in Microsoft Entra-id.

Aan een toepassingsregistratie kunnen federatieve referenties zijn gekoppeld. Federatieve referenties vereisen niet dat u geheimen opslaat. In plaats daarvan schakelen ze een ondersteunde service zoals GitHub in om een Microsoft Entra-toepassing te gebruiken.

Wanneer uw GitHub Actions-werkstroom moet worden geverifieerd, neemt deze contact op met de Microsoft Entra-id via GitHub. GitHub vertelt Microsoft Entra ID de naam van de GitHub-organisatie en opslagplaats, en eventueel andere informatie. Als u een federatieve referentie hebt geconfigureerd die overeenkomt met de gegevens van de opslagplaats, verifieert Microsoft Entra uw implementatiewerkstroom. De werkstroom kan de machtigingen gebruiken die u aan de toepassing hebt toegewezen.

Tip

Wanneer u een toepassingsregistratie bekijkt in Azure Portal, ziet u veel andere functionaliteit en configuratie die mogelijk niet relevant lijken. Dat komt doordat toepassingen veel dingen kunnen doen in Microsoft Entra ID die buiten het bereik van verificatie- en werkstroomimplementaties vallen.

U kunt ook een service-principal-object maken in uw Microsoft Entra-tenant. Een service-principal is vergelijkbaar met een kopie van de toepassing voor uw eigen Microsoft Entra-tenant die moet worden gebruikt. Service-principals en toepassingen zijn nauw gekoppeld. Verderop in deze module gebruikt u een service-principal wanneer u uw werkstroommachtigingen verleent voor toegang tot Azure.

Notitie