Een service-principal en -sleutel maken

  • 6 minuten

Nu u het concept van een service-principal begrijpt, vraagt u zich misschien af hoe het zijn identiteit bewijst voor Microsoft Entra ID. In deze les krijgt u informatie over het verificatieproces en de referenties voor service-principals. U leert ook hoe u een service-principal maakt en deze een sleutel geeft.

Begrijpen hoe service-principals worden geverifieerd

Wanneer een service-principal met Azure moet communiceren, meldt deze zich aan bij Microsoft Entra-id. Nadat microsoft Entra-id de identiteit van de service-principal heeft geverifieerd, geeft deze een token uit dat de clienttoepassing opslaat en gebruikt wanneer deze aanvragen naar Azure indient.

Dit proces is in grote lijnen vergelijkbaar met hoe dingen werken wanneer u zich als gebruiker aanmeldt bij Azure. In vergelijking met gebruikers hebben service-principals echter een iets ander type referentie om hun identiteit te bewijzen. Service-principals gebruiken twee hoofdreferenties: sleutels en certificaten.

Notitie

Houd er rekening mee dat beheerde identiteiten speciale service-principals zijn die in Azure werken. Ze hebben een ander type verificatieproces waarvoor u helemaal geen referenties kent of afhandelt.

Toetsen

Sleutels zijn vergelijkbaar met wachtwoorden. Sleutels zijn echter veel langer en complexer. In de meeste gevallen genereert Microsoft Entra ID sleutels zelf om ervoor te zorgen dat:

  • De sleutels zijn cryptografisch willekeurig. Dat wil zeggen, ze zijn extreem moeilijk te raden.
  • Mensen gebruiken niet per ongeluk zwakke wachtwoorden als sleutels.

Service-principals hebben vaak machtigingen met hoge bevoegdheden, dus het is essentieel dat ze veilig zijn. Normaal gesproken hoeft u de sleutel alleen kort af te handelen bij het configureren van de service-principal en uw pijplijn. De sleutel hoeft dus niet gemakkelijk te worden onthouden of gemakkelijk te typen.

Eén service-principal kan meerdere sleutels tegelijk hebben, maar gebruikers kunnen niet meerdere wachtwoorden hebben. Net als wachtwoorden hebben sleutels een vervaldatum. Daar kom je binnenkort meer over te weten.

Notitie

Denk aan sleutels zoals zeer belangrijke wachtwoorden, vergelijkbaar met opslagaccountsleutels. U moet ze behandelen met hetzelfde beveiligings- en zorgniveau.

Certificaten

Certificaten zijn een andere manier om service-principals te verifiëren. Ze zijn erg veilig, maar kunnen moeilijk te beheren zijn. Sommige organisaties vereisen het gebruik van certificaten voor bepaalde typen service-principals.

In deze module worden geen certificaten besproken. Als u echter werkt met een service-principal die gebruikmaakt van certificaatverificatie, werkt deze in principe op dezelfde manier als elke andere service-principal voor het beheren ervan en het verlenen van machtigingen voor uw pijplijn.

Notitie

Certificaten zijn een goede optie wanneer u ze kunt gebruiken. Ze zijn moeilijker voor aanvallers om te stelen. Het is ook moeilijker om aanvragen die gebruikmaken van certificaten te onderscheppen en te wijzigen. Certificaten vereisen echter meer infrastructuur en hebben enige doorlopende onderhoudsoverhead.

Werken met sleutels voor service-principals

Wanneer u een service-principal maakt, vraagt u azure doorgaans om tegelijkertijd een sleutel te maken. Azure genereert doorgaans een willekeurige sleutel voor u.

Notitie

Herinnert u zich nog onze eerdere discussie over hoe service-principals werken? Sleutels worden opgeslagen als onderdeel van het toepassingsregistratieobject. Als u Azure Portal opent, kijkt u in de Configuratie van Microsoft Entra en gaat u vervolgens naar de toepassingsregistraties, dan kunt u daar ook sleutels maken en verwijderen.

Azure toont u de sleutel wanneer u de service-principal maakt. Dit is de enige keer dat Azure u ooit de sleutel laat zien. Daarna kunt u het niet meer ophalen. Het is belangrijk dat u de sleutel veilig kopieert, zodat u deze kunt gebruiken wanneer u uw pijplijn configureert. Deel de sleutel niet via e-mail of een andere niet-beveiligde manier. Als u een sleutel kwijtraakt, moet u deze verwijderen en een nieuwe sleutel maken.

Service-principals voor Azure Pipelines beheren

Wanneer u een sleutel voor de service-principal van een pijplijn maakt, is het een goed idee om de sleutel onmiddellijk te kopiëren naar de configuratie van de pijplijn. Op die manier vermijdt u dat de sleutel onnodig wordt opgeslagen of verzonden.

Pijplijnhulpprogramma's bevatten veilige manieren om de toepassings-id en sleutel van uw service-principal op te geven. Sla nooit referenties van elk type op in broncodebeheer. Gebruik in plaats daarvan serviceverbindingen wanneer u met Azure Pipelines werkt. In deze module bespreken we alleen hoe u een service-principal en -sleutel maakt. In een latere module leert u hoe u uw pijplijn configureert met de sleutel.

Tip

Met Azure Pipelines kunt u automatisch service-principals maken. In deze module maakt en beheert u handmatig uw service-principals om een beter inzicht te krijgen in wat er gebeurt. In andere modules gebruikt u de methode voor automatisch maken om het eenvoudig te maken.

Een service-principal en -sleutel maken

U kunt de Azure CLI gebruiken om service-principals te maken en te beheren.

Notitie

Voor het maken en wijzigen van service-principals moet u beschikken over de bijbehorende machtigingen in Microsoft Entra-id. In sommige organisaties hebt u mogelijk een beheerder nodig om deze stappen voor u uit te voeren.

Gebruik de az ad sp create-for-rbac opdracht om een service-principal en een sleutel te maken. Deze opdracht accepteert verschillende argumenten en kan desgewenst rollen toewijzen aan de service-principal. Verderop in deze module leert u meer over dit onderwerp. Hier volgt een voorbeeld waarin wordt geïllustreerd hoe u een service-principal maakt zonder Azure-roltoewijzingen:

az ad sp create-for-rbac --name MyPipeline

Wanneer u deze opdracht uitvoert, retourneert de Azure CLI een JSON-antwoord met een password eigenschap. Deze eigenschap is de sleutel van de service-principal. U kunt deze sleutel niet opnieuw ophalen, dus zorg ervoor dat u deze onmiddellijk gebruikt of ergens veilig opslaat.

Notitie

Met de az ad sp create-for-rbac opdracht maakt u een toepassingsregistratie in Microsoft Entra-id, voegt u een service-principal toe aan uw Microsoft Entra-tenant en maakt u een sleutel voor de toepassingsregistratie. Met een andere opdracht maakt az ad sp createu alleen de service-principal in uw tenant (niet de registratie van de toepassing). Wanneer u service-principals voor pijplijnen maakt, az ad sp create-for-rbac is dit meestal de beste opdracht die u kunt gebruiken.

U kunt de Azure PowerShell-cmdlets gebruiken om service-principals te maken en te beheren.

Notitie

Voor het maken en wijzigen van service-principals moet u beschikken over de bijbehorende machtigingen in Microsoft Entra-id. In sommige organisaties hebt u mogelijk een beheerder nodig om deze stappen voor u uit te voeren.

Gebruik de New-AzADServicePrincipal cmdlet om een service-principal en een sleutel te maken. Deze cmdlet accepteert verschillende argumenten en kan eventueel rollen toewijzen aan de service-principal. Verderop in deze module leert u meer over dit onderwerp. Hier volgt een voorbeeld waarin wordt geïllustreerd hoe u een service-principal maakt zonder Azure-roltoewijzingen:

$servicePrincipal = New-AzADServicePrincipal -DisplayName MyPipeline

Wanneer u deze opdracht uitvoert, vult Azure PowerShell de servicePrincipal variabele met informatie over de service-principal, inclusief de sleutel:

$servicePrincipalKey = $servicePrincipal.PasswordCredentials.SecretText

U kunt deze sleutel niet meer ophalen, dus zorg ervoor dat u deze onmiddellijk gebruikt of ergens veilig opslaat.

Notitie

De New-AzADServicePrincipal cmdlet maakt een toepassingsregistratie in Microsoft Entra ID, voegt een service-principal toe aan uw Microsoft Entra-tenant en maakt een sleutel voor de toepassingsregistratie.

Een service-principal identificeren

Service-principals hebben verschillende id's en namen die u gebruikt om ze te identificeren en ermee te werken. De id's die u het meest gebruikt, zijn:

  • Toepassings-id: De toepassingsregistratie heeft een unieke id, vaak een toepassings-id of soms een client-id genoemd. Normaal gesproken gebruikt u deze als gebruikersnaam wanneer de service-principal zich aanmeldt bij Azure.
  • Object-id: de registratie van de toepassing en de service-principal hebben hun eigen afzonderlijke object-id's, die unieke id's zijn die zijn toegewezen door Microsoft Entra ID. Af en toe moet u deze object-id's gebruiken wanneer u een service-principal beheert.
  • Weergavenaam: Dit is een door mensen leesbare naam die de service-principal beschrijft.

Tip

Gebruik een duidelijke, beschrijvende weergavenaam voor uw service-principal. Het is belangrijk om uw team te helpen begrijpen waar de service-principal voor is, zodat niemand deze per ongeluk verwijdert of de machtigingen ervan wijzigt.

Let op

Een weergavenaam is niet uniek. Meerdere service-principals kunnen dezelfde weergavenaam delen. Wees voorzichtig wanneer u machtigingen verleent aan een service-principal met behulp van de weergavenaam om deze te identificeren. Mogelijk geeft u per ongeluk machtigingen aan de verkeerde service-principal. Het is een goed idee om in plaats daarvan de toepassings-id te gebruiken.

Wanneer u een service-principal maakt, stelt u doorgaans alleen de weergavenaam in. Azure wijst automatisch de andere namen en id's toe.

Verlopen sleutels verwerken

Service-principals verlopen niet, maar hun sleutels wel. Wanneer u een sleutel maakt, kunt u de verlooptijd ervan configureren. De verlooptijd is standaard ingesteld op één jaar. Na deze verlooptijd werkt de sleutel niet meer en kan de pijplijn zich niet aanmelden bij Microsoft Entra-id. U moet sleutels regelmatig vernieuwen of roteren .

Let op

Het kan verleidelijk zijn om lange verlooptijden in te stellen voor uw sleutels, maar u moet dit niet doen. Service-principals worden alleen beveiligd met hun referenties. Als een aanvaller de sleutel van een service-principal verkrijgt, kan deze veel schade aanrichten. De beste methode om de periode te minimaliseren die een aanval kan duren, is door regelmatig uw sleutels te wijzigen. U moet ook sleutels verwijderen en opnieuw maken als u vermoedt dat ze zijn gelekt.

Als u een sleutel voor een service-principal opnieuw wilt instellen, gebruikt u de az ad sp opdracht met de toepassings-id, zoals in dit voorbeeld:

az ad sp credential reset --id "b585b740-942d-44e9-9126-f1181c95d497"

U kunt de sleutel van de service-principal ook in twee afzonderlijke stappen verwijderen en opnieuw maken met behulp van de az ad sp credential delete en vervolgens de az ad sp credential reset --append opdrachten.

Als u een sleutel voor een service-principal opnieuw wilt instellen, gebruikt u eerst de Remove-AzADServicePrincipalCredential cmdlet om de bestaande referentie te verwijderen. Gebruik vervolgens de New-AzADServicePrincipalCredential cmdlet om een nieuwe referentie toe te voegen. Deze cmdlets gebruiken beide de object-id van de service-principal om deze te identificeren. Voordat u de cmdlets gebruikt, moet u deze id ophalen uit de toepassings-id:

$applicationId = APPLICATION_ID
$servicePrincipalObjectId = (Get-AzADServicePrincipal -ApplicationId $applicationId).Id

Remove-AzADServicePrincipalCredential -ObjectId $servicePrincipalObjectId

$newCredential = New-AzADServicePrincipalCredential -ObjectId $servicePrincipalObjectId
$newKey = $newCredential.SecretText

Tip

Eén service-principal kan meerdere sleutels hebben. U kunt uw toepassing veilig bijwerken om een nieuwe sleutel te gebruiken terwijl de oude sleutel nog steeds geldig is en vervolgens de oude sleutel verwijderen wanneer deze niet meer wordt gebruikt. Met deze techniek voorkomt u downtime van het verlopen van sleutels.

De levenscyclus van uw service-principal beheren

Het is belangrijk om rekening te houden met de volledige levenscyclus van elke service-principal die u maakt. Wat gebeurt er wanneer u een service-principal voor een pijplijn bouwt als de pijplijn uiteindelijk wordt verwijderd of niet meer wordt gebruikt?

Service-principals worden niet automatisch verwijderd, dus u moet oude service-principals controleren en verwijderen. Het is belangrijk om oude service-principals te verwijderen om dezelfde reden dat u oude gebruikersaccounts verwijdert: aanvallers kunnen toegang krijgen tot hun sleutels. Het is raadzaam om geen referenties te hebben die niet actief worden gebruikt.

Het is een goede gewoonte om uw service-principals vast te leggen op een plek waartoe u en uw team eenvoudig toegang hebben. Neem de volgende informatie op voor elke service-principal:

  • Essentiële identificatiegegevens, inclusief de naam en de toepassings-id.
  • Het doel van de service-principal.
  • Wie het gemaakt, wie verantwoordelijk is voor het beheren ervan en de sleutels, en wie misschien antwoorden heeft als er een probleem is.
  • De machtigingen die het nodig heeft en een duidelijke reden waarom ze nodig zijn.
  • Wat de verwachte levensduur is.

Controleer regelmatig uw service-principals om ervoor te zorgen dat ze nog steeds worden gebruikt en dat de machtigingen waaraan ze zijn toegewezen, nog steeds juist zijn.