Service-principals beveiligen

Een Azure Active Directory (Azure AD) service-principal is de lokale weergave van een toepassingsobject in één tenant of directory. Het fungeert als de identiteit van het toepassingsexemplaar. Service-principals definiëren wie toegang heeft tot de toepassing en tot welke resources de toepassing toegang heeft. Er wordt een service-principal gemaakt in elke tenant waarin de toepassing wordt gebruikt en verwijst naar het wereldwijd unieke toepassingsobject. De tenant beveiligt de aanmelding van de service-principal en de toegang tot resources.

Relaties tussen tenant-service-principals

Een toepassing met één tenant heeft één service-principal in de eigen tenant. Voor een webtoepassing of API met meerdere tenants is een service-principal vereist in elke tenant. Er wordt een service-principal gemaakt wanneer een gebruiker van die tenant toestemming krijgt voor het gebruik van de toepassing of API. Met deze toestemming wordt een een-op-veel-relatie gemaakt tussen de toepassing met meerdere tenants en de bijbehorende service-principals.

Een toepassing met meerdere tenants bevindt zich in één tenant en heeft exemplaren in andere tenants. De meeste SaaS-toepassingen (Software-as-a-Service) bieden ondersteuning voor meerdere tenants. Gebruik service-principals om de benodigde beveiligingspostuur voor de toepassing en de gebruikers ervan te garanderen in scenario's met één tenant en meerdere tenants.

ApplicationID en ObjectID

Een toepassingsexemplaar heeft twee eigenschappen: de ApplicationID (ook wel ClientID genoemd) en de ObjectID.

Notitie

Het is mogelijk dat de termen toepassing en service-principal door elkaar worden gebruikt bij het verwijzen naar een toepassing in de context van verificatiegerelateerde taken. Het zijn echter twee representaties van toepassingen in Azure AD.

De ApplicationID vertegenwoordigt de globale toepassing en is hetzelfde voor toepassingsexemplaren in tenants. De ObjectID is een unieke waarde voor een toepassingsobject. Net als bij gebruikers, groepen en andere resources helpt de ObjectID bij het identificeren van een toepassingsexemplaar in Azure AD.

Zie Relatie tussen toepassings- en service-principals voor meer informatie.

U kunt een toepassing en het bijbehorende ObjectID (Service Principal Object) in een tenant maken met behulp van Azure PowerShell, Azure CLI, Microsoft Graph, de Azure Portal en andere hulpprogramma's.

Schermopname mvan een nieuwe toepassingsregistratie met de velden Toepassings-id en Object-id gemarkeerd.

Verificatie van service-principal

Bij het gebruik van service-principals( clientcertificaten en clientgeheimen), zijn er twee mechanismen voor verificatie.

 Schermopname van de pagina Nieuwe app met de Certificaten en clientgeheimen gemarkeerd.

Certificaten zijn veiliger, dus gebruik ze, indien mogelijk. In tegenstelling tot clientgeheimen kunnen clientcertificaten niet per ongeluk worden ingesloten in code. Gebruik indien mogelijk Azure Key Vault voor certificaat- en geheimenbeheer om de volgende assets te versleutelen met sleutels die worden beveiligd door hardwarebeveiligingsmodules:

  • Verificatiesleutels

  • Opslagaccountsleutels

  • Gegevensversleutelingssleutels

  • .pfx-bestanden

  • Wachtwoorden

Raadpleeg Over Azure Key Vault en Een Key Vault toegangsbeleid toewijzen met behulp van de Azure Portal voor meer informatie over Azure Key Vault en het gebruik voor het beheer van certificaten en geheimen.

Uitdagingen en oplossingen

Gebruik de volgende tabel om uitdagingen en oplossingen te vinden bij het gebruik van service-principals.

Uitdagingen Oplossingen
Toegangsbeoordelingen voor service-principals die zijn toegewezen aan bevoorrechte rollen Deze functionaliteit is in preview en niet algemeen beschikbaar
Controleert de toegang van de service-principal Handmatige controle van de toegangsbeheerlijst voor resources met behulp van de Azure Portal
Service-principals met te veel machtigingen Wanneer u Automation-serviceaccounts of service-principals maakt, moet u machtigingen opgeven die vereist zijn voor de taak. Service-principals evalueren om bevoegdheden te verminderen
Wijzigingen in referenties van service-principals of verificatiemethoden identificeren Gebruik de werkmap Rapport gevoelige bewerkingen om het probleem te verhelpen. Zie ook het Tech Community-blogbericht Azure AD werkmap om u te helpen bij het beoordelen van solorigate-risico's.

Accounts zoeken met behulp van service-principals

Voer de volgende opdrachten uit om accounts te vinden met behulp van service-principals met Azure CLI of PowerShell.

Azure CLI:

az ad sp list

PowerShell:

Get-AzureADServicePrincipal -All:$true

Zie Get-AzureADServicePrincipal voor meer informatie.

De beveiliging van service-principals beoordelen

Als u de beveiliging van uw service-principals wilt evalueren, moet u de bevoegdheden en referentieopslag evalueren.

Beperk potentiële uitdagingen met behulp van de volgende informatie.

Uitdagingen Oplossingen
De gebruiker detecteren die toestemming heeft gegeven voor een app met meerdere tenants en illegale toestemmingsverlening aan een app met meerdere tenants detecteren Voer de volgende PowerShell uit om apps met meerdere tenants te vinden.
Get-AzureADServicePrincipal -All:$true ? {$_.Tags -eq WindowsAzureActiveDirectoryIntegratedApp"}
Gebruikerstoestemming uitschakelen.
Toestaan dat gebruikers toestemming geven voor apps van geverifieerde uitgevers, voor geselecteerde machtigingen (aanbevolen)
Configureer ze in de gebruikerscontext. Gebruik hun tokens om de service-principal te activeren.
Gebruik van een in code vastgelegd gedeeld geheim in een script met behulp van een service-principal Een certificaat gebruiken
Bijhouden wie het certificaat of het geheim gebruikt De aanmeldingen van de service-principal bewaken met behulp van de Azure AD aanmeldingslogboeken
Kan aanmelding van service-principals met voorwaardelijke toegang niet beheren Aanmeldingen onderzoeken met behulp van de Azure AD-aanmeldingslogboeken
Inzender is de standaardrol op basis van op rollen gebaseerd toegangsbeheer (RBAC) van Azure Evalueer de behoeften en pas de rol toe met de minst mogelijke machtigingen

Overstappen van een gebruikersaccount naar een service-principal

Als u een Azure-gebruikersaccount als service-principal gebruikt, moet u evalueren of u kunt overstappen op een beheerde identiteit of een service-principal. Als u een beheerde identiteit niet kunt gebruiken, richt u een service-principal in met voldoende machtigingen en bereik om de vereiste taken uit te voeren. U kunt een service-principal maken door een Toepassing te registreren of met PowerShell.

Wanneer u Microsoft Graph gebruikt, raadpleegt u de API-documentatie. Zie Een Azure-service-principal maken. Zorg ervoor dat het machtigingstype voor de toepassing wordt ondersteund.

Volgende stappen

Meer informatie over service-principals:

Een service-principal maken

Service-principal-aanmeldingen bewaken

Meer informatie over het beveiligen van serviceaccounts:

Inleiding tot Azure-serviceaccounts

Beheerde identiteiten beveiligen

Azure-serviceaccounts beheren

Inleiding tot on-premises serviceaccounts

Voorwaardelijke toegang:

Gebruik voorwaardelijke toegang om service-principals van niet-vertrouwde locaties te blokkeren. Zie Een beleid voor voorwaardelijke toegang op basis van locatie maken.