Meer informatie over service-principals
Service-principals bieden een manier om pijplijnen, toepassingen en software te verifiëren. In deze les leert u waarom service-principals belangrijk zijn voor implementatiepijplijnen, hoe ze in het beveiligingsmodel van Azure passen en hoe ze werken.
Waarom moet een pijplijn worden geverifieerd?
Wanneer u een Bicep-sjabloon implementeert, vraagt u Azure Resource Manager effectief om uw Azure-resources te maken of te wijzigen. In dit voorbeeldscenario hebt u een Bicep-sjabloon gemaakt om de website van uw speelgoedbedrijf te implementeren. De Bicep-sjabloon declareert resources die een Azure-app Service-plan, een app en een Application Insights-exemplaar bevatten.
Wanneer u de sjabloon implementeert, controleert Resource Manager of de resources bestaan. Als ze dat niet doen, maakt Resource Manager ze. Als er al bestaan, zorgt Resource Manager ervoor dat de configuratie overeenkomt met de configuratie die u in de sjabloon opgeeft.
Voor al deze bewerkingen zijn machtigingen vereist, omdat ze uw Azure-resources openen en wijzigen. De specifieke machtigingen die nodig zijn voor implementatie, zijn afhankelijk van wat de sjabloon bevat. Als u het voorbeeld van de Bicep-sjabloon 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 worden beschouwd als 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-sjablonen 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 bent overgelopen naar een pijplijn, moet u een ander type identiteit gebruiken, omdat de pijplijn zelf implementaties uitvoert, zonder dat u direct betrokken bent.
Typen beveiligingsprinciplen
Microsoft Entra ID is de service waarmee identiteiten voor Azure worden beheerd. Microsoft Entra ID heeft meerdere typen identiteiten, die ook wel beveiligingsprinciplen worden genoemd:
- 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.
- 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.
- Een service-principal vertegenwoordigt een geautomatiseerd proces of systeem dat meestal niet rechtstreeks door een persoon wordt uitgevoerd.
- Een beheerde identiteit is een speciaal type service-principal dat is ontworpen voor situaties waarin een mens niet betrokken is bij het verificatieproces.
Service-principals
Een service-principal is een type account. Het kan zich aanmelden bij Microsoft Entra ID, maar er is geen mens om zich aan te melden en te communiceren met het verificatieproces. Service-principals hebben geen MFA- of vergelijkbare beveiligingen, omdat personen iets moeten doen om hun identiteit te bewijzen.
In Microsoft Entra-id wordt een service-principal geïdentificeerd door een toepassings-id en een referentie. De toepassings-id is een GUID (Globally Unique Id). Voor pijplijnen is de referentie meestal een sterk wachtwoord, een sleutel genoemd. U kunt ook een certificaat als referentie gebruiken.
Beheerde identiteiten
In tegenstelling tot de andere typen service-principals is voor een beheerde identiteit niet vereist dat u de referenties kent of onderhoudt. 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 pijplijnen werkt, kunt u meestal geen beheerde identiteiten gebruiken. Dit komt doordat beheerde identiteiten vereisen dat u de eigenaar bent van de Azure-resources die uw implementaties uitvoeren. Wanneer u met Azure Pipelines werkt, bent u meestal afhankelijk van een gedeelde infrastructuur van Microsoft.
Notitie
Er zijn enkele situaties waarin pijplijnen beheerde identiteiten kunnen gebruiken. In Azure Pipelines kunt u een zelf-hostende agent maken om de scripts en code van uw pijplijn uit te voeren met behulp van uw eigen virtuele machine op basis van Azure. Omdat u eigenaar bent van de virtuele machine, kunt u deze toewijzen aan een beheerde identiteit en deze gebruiken vanuit uw pijplijn.
Meestal worden uw pijplijnen echter uitgevoerd met behulp van een gehoste agent, een server die door Microsoft wordt beheerd. Gehoste agents zijn momenteel niet compatibel met beheerde identiteiten.
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. Ze zijn gemakkelijker te werken 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 alleen een pijplijn 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 maken steeds vaker gebruik van 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.
Pijplijnen zijn ontworpen om uw implementaties uit te voeren, zelfs wanneer niemand deze actief uitvoert. In feite zijn de meeste voordelen van pijplijnen afkomstig van het feit dat ze volledig geautomatiseerd zijn en geen menselijke interactie vereisen. Als u uw gebruikersnaam en wachtwoord opslaat in een pijplijn 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 pijplijntaken die communiceren met Azure niet de referenties van een gebruikersaccount opgeven. Hiervoor moet u een service-principal gebruiken.
Hoe werken service-principals?
Mogelijk ziet u een aantal verschillende termen die worden gebruikt wanneer u met service-principals werkt, of met hulpprogramma's zoals Azure Portal of de Microsoft Graph API. Hoewel het niet essentieel is om deze termen alleen te begrijpen om service-principals in een pijplijn te gebruiken, is het handig om wat te weten te komen over de concepten.
Service-principals zijn een functie van Microsoft Entra-id. Microsoft Entra ID is 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 een implementatiepijplijn beschouwen als een toepassing.
In Microsoft Entra ID kunnen toepassingen veel dingen doen die buiten het bereik van verificatie- en pijplijnimplementaties vallen. 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.
Service-principals en toepassingen zijn nauw gekoppeld. Wanneer een toepassingsregistratie wordt toegevoegd aan een Microsoft Entra-tenant, wordt er een service-principalobject gemaakt in die Microsoft Entra-tenant. Wanneer u een service-principal bekijkt in Azure Portal, ziet u veel andere functionaliteit en configuratie die mogelijk niet relevant lijken. Veel hiervan komt doordat service-principals zijn gekoppeld aan toepassingen.
Wanneer u een service-principal maakt, maken de meeste hulpprogramma's die u gebruikt ook tegelijkertijd een toepassingsregistratie. U ziet dus misschien niet dat er twee verschillende objecten zijn.
Eén type service-principal is niet gekoppeld aan een toepassingsregistratie: een beheerde identiteit. Zoals eerder vermeld, beheert Azure de configuratie en referenties voor een beheerde identiteit.
Notitie
Een service-principal wordt ook wel een bedrijfstoepassing genoemd. Sommige hulpprogramma's gebruiken één naam en andere hulpprogramma's gebruiken de andere. Mogelijk ziet u ook service-principals die beheerde toepassingen worden genoemd in uw lokale directory, maar deze zijn niet hetzelfde als beheerde identiteiten.
Als u wilt samenvatten wanneer u een service-principal maakt, maakt u eerst een toepassingsregistratie en vervolgens maakt u een service-principal voor die toepassingsregistratie die moet worden gebruikt. De meeste hulpprogramma's waarmee u werkt, doen dit voor u, dus u bent er niet eens van op de hoogte. Mogelijk gebruikt u niet alle functies van Microsoft Entra-toepassingen wanneer u met implementatiepijplijnen werkt. Omdat service-principals gerelateerd zijn aan toepassingen, is dezelfde Microsoft Entra-objectstructuur van toepassing.