Delen via

Aanbevolen beveiligingsprocedures voor toepassingseigenschappen in Microsoft Entra ID

Beveiliging is een belangrijk concept bij het registreren van een toepassing in Microsoft Entra ID en is een essentieel onderdeel van het bedrijfsgebruik in de organisatie. Elke onjuiste configuratie van een toepassing kan leiden tot downtime of inbreuk. Afhankelijk van de machtigingen die aan een toepassing zijn toegevoegd, kunnen er organisatiebrede effecten zijn.

Omdat beveiligde toepassingen essentieel zijn voor de organisatie, kan downtime vanwege beveiligingsproblemen van invloed zijn op het bedrijf of een kritieke service waarvan het bedrijf afhankelijk is. Het is dus belangrijk om tijd en resources toe te wijzen om ervoor te zorgen dat toepassingen altijd in een goede en veilige status blijven. Voer een periodieke beveiligings- en statusbeoordeling uit van toepassingen, net zoals een Security Threat Model-evaluatie voor code. Zie de Levenscyclus voor beveiligingsontwikkeling (SDL) voor een breder perspectief op beveiliging voor organisaties.

In dit artikel worden aanbevolen beveiligingsprocedures beschreven voor de volgende toepassingseigenschappen en -scenario's:

  • Identiteitstype
  • Inloggegevens
  • Omleidings-URI's
  • Impliciete stroomconfiguratie
  • URI van applicatie-ID (ook wel identificatie-URI genoemd)
  • Versie van toegangstoken
  • Vergrendeling van applicatie-instantie
  • Toepassingseigendom

Identiteitstype

U vindt hier waarschijnlijk meer informatie over aanbevolen beveiligingsprocedures voor Microsoft Entra-toepassingen , ook wel app-registraties of app-objecten genoemd. Er is echter een ander identiteitstype dat kan worden gebruikt voor toegang tot met Entra beveiligde resources, ook wel beheerde identiteiten voor Azure-resources genoemd.

Door Azure beheerde identiteiten zijn standaard beveiligd en vereisen weinig tot geen doorlopend onderhoud of overhead. Overweeg om een beheerde identiteit te gebruiken in plaats van een Microsoft Entra-toepassing voor uw app-identiteit als alle volgende waar zijn:

  • De service wordt uitgevoerd in de Azure-cloud
  • De app hoeft zich niet aan te melden bij gebruikers
  • De app hoeft niet te fungeren als de resource in een tokenstroom (is geen web-API)
  • De app hoeft niet in meerdere tenants te werken

Houd er rekening mee dat beheerde identiteiten kunnen worden gebruikt voor toegang tot resources buiten Azure, waaronder Microsoft Graph.

De rest van dit artikel bevat aanbevolen beveiligingsprocedures voor eigenschappen van Entra-app-registraties.

Referenties (inclusief certificaten en wachtwoorden)

Referenties zijn een essentieel onderdeel van een toepassing wanneer deze wordt gebruikt als een vertrouwelijke client. Op de pagina Certificaten en geheimen voor de toepassing in Azure Portal kunnen referenties worden toegevoegd of verwijderd.

Schermopname die laat zien waar de certificaten en geheimen zich bevinden.

Houd rekening met de volgende richtlijnen met betrekking tot certificaten en geheimen:

  • Gebruik waar mogelijk een beheerde identiteit als referentie. Dit wordt sterk aanbevolen, omdat beheerde identiteiten zowel de veiligste optie zijn als u geen doorlopend referentiebeheer nodig hebt. Volg deze aanwijzingen om een beheerde identiteit als referentiegegevens te configureren. Deze optie is echter alleen mogelijk als de service die door de app wordt gebruikt, wordt uitgevoerd in Azure.
  • Als de service waarin de app wordt gebruikt niet wordt uitgevoerd in Azure, maar wel wordt uitgevoerd op een ander platform dat geautomatiseerd referentiebeheer biedt, kunt u overwegen een identiteit van dat platform als referentie te gebruiken. Een Werkstroom voor GitHub-acties kan bijvoorbeeld worden geconfigureerd als referentie, waardoor u geen referenties meer hoeft te beheren en beveiligen voor de GitHub-actiespijplijn. Wees voorzichtig met deze aanpak en configureer alleen federatieve referenties van platforms die u vertrouwt. Een app is alleen zo veilig als het identiteitsplatform dat is geconfigureerd als inloggegevens.
  • Als het gebruik van een beheerde identiteit of een andere beveiligde externe id-provider niet mogelijk is, gebruikt u certificaatreferenties. Gebruik geen wachtwoordreferenties, ook wel bekend als geheimen. Hoewel het handig is om wachtwoordgeheimen als referentie te gebruiken, worden wachtwoordreferenties vaak verkeerd beheerd en kunnen ze gemakkelijk worden aangetast.
  • Als een certificaat moet worden gebruikt in plaats van een beheerde identiteit, slaat u dat certificaat op in een beveiligde sleutelkluis, zoals Azure Key Vault.
  • Als een certificaat moet worden gebruikt in plaats van een beheerde identiteit, gebruikt u een certificaat van een vertrouwde certificeringsinstantie (CA) in plaats van een zelfondertekend certificaat. Configureer een beleid om af te dwingen dat certificaten afkomstig zijn van vertrouwde verleners. Als het gebruik van een vertrouwde CA echter niet mogelijk is, hebben zelfondertekende certificaten nog steeds de voorkeur boven wachtwoorden.
  • Configureer beleidsregels voor toepassingsbeheer om het gebruik van geheimen te beheren door hun levensduur te beperken of het gebruik ervan helemaal te blokkeren.
  • Als een toepassing alleen wordt gebruikt als een openbare of geïnstalleerde client (bijvoorbeeld mobiele of desktop-apps die op de computer van de eindgebruiker zijn geïnstalleerd), moet u ervoor zorgen dat er geen referenties zijn opgegeven voor het toepassingsobject.
  • Controleer de referenties die worden gebruikt in toepassingen voor nieuw gebruik en de vervaldatum. Een ongebruikte referentie in een toepassing kan leiden tot een beveiligingsschending. Rollover-referenties worden vaak gebruikt en delen geen referenties in verschillende toepassingen. Gebruik niet meerdere referenties voor één toepassing.
  • Bewaak uw productiepijplijnen om te voorkomen dat referenties van elk type worden doorgevoerd in codeopslagplaatsen. Referentiescanner is een hulpprogramma voor statische analyse dat kan worden gebruikt om referenties (en andere gevoelige inhoud) te detecteren in de broncode en uitvoer te bouwen.

Omleidings-URI's

Het is belangrijk om omleidings-URI's van uw toepassing up-to-date te houden. Onder Verificatie voor de toepassing in de Azure Portal moet een platform worden geselecteerd voor de toepassing. Vervolgens kan de omleidings-URI-eigenschap worden gedefinieerd.

Schermopname die weergeeft waar de URI-eigenschap voor de doorverwijzing zich bevindt.

Houd rekening met de volgende richtlijnen voor omleidings-URI's:

  • Het eigendom van alle URI's behouden. Een onderbreking in het eigendom van een van de omleidings-URI's kan leiden tot inbreuk op toepassingen.
  • Zorg ervoor dat alle DNS-records regelmatig worden bijgewerkt en gecontroleerd op wijzigingen.
  • Gebruik geen antwoord-URL's met jokertekens of onveilige URI-schema's zoals http of URN.
  • Houd de lijst klein. Verwijder eventuele onnodige URI's. Werk, indien mogelijk, URL's bij van Http naar Https.

Impliciete stroomconfiguratie

Scenario's die impliciete stroom vereisen, kunnen nu de Auth-codestroom gebruiken om het risico op inbreuk op impliciete stroommisbruik te verminderen. In de Azure Portal moet onder Verificatie voor de toepassing een platform worden geselecteerd voor de toepassing. Vervolgens kan de eigenschap Toegangstokens (gebruikt voor impliciete stromen) worden ingesteld.

Schermopname die weergeeft waar de eigenschap voor de impliciete stroom zich bevindt.

Houd rekening met de volgende richtlijnen met betrekking tot impliciete stroom:

  • Begrijp of een impliciete stroom is vereist. Gebruik geen impliciete stroom tenzij dit expliciet vereist is.
  • Als de toepassing is geconfigureerd voor het ontvangen van toegangstokens met behulp van impliciete stroom, maar deze ze niet actief gebruikt, schakelt u de instelling uit om misbruik te voorkomen.
  • Gebruik afzonderlijke toepassingen voor geldige scenario’s met impliciete stromen.

Toepassing-ID-URI (ook wel Identifier-URI genoemd)

De eigenschap URI van toepassings-id voor de toepassing geeft de wereldwijd unieke URI aan die wordt gebruikt om de web-API te identificeren. Het is het voorvoegsel voor de scope-waarde in aanvragen voor Microsoft Entra. Het is ook de waarde van de audience (aud) claim in v1.0-toegangstokens. Voor multitenant-toepassingen moet de waarde ook wereldwijd uniek zijn. Het wordt ook wel een id-URIgenoemd. Onder Een API beschikbaar maken voor de toepassing in de Azure Portal, kan de eigenschap URI van toepassings-id worden gedefinieerd.

Schermopname die aangeeft waar de URI van de toepassings-id zich bevindt.

Aanbevolen werkwijzen voor het definiëren van de URI van de application-ID veranderen afhankelijk van of de app v1.0- of v2.0-toegangstokens uitgeeft. Als u niet zeker weet of er v1.0-toegangstokens zijn uitgegeven voor een app, controleert u de requestedAccessTokenVersion van het app-manifest. Een waarde van null of 1 geeft aan dat de app v1.0-toegangstokens ontvangt. Een waarde van 2 geeft aan dat de app v2.0-toegangstokens ontvangt.

Voor toepassingen die v1.0-toegangstokens hebben uitgegeven, moeten alleen de standaard-URI's worden gebruikt. De standaard-URI's zijn api://<appId> en api://<tenantId>/<appId>. - Configureer de nonDefaultUriAddition beperking in het beleid voor toepassingsbeheer om deze best practice af te dwingen voor toekomstige updates voor toepassingen in uw organisatie.

Voor toepassingen die v2.0-toegangstokens hebben uitgegeven, gebruikt u de volgende richtlijnen bij het definiëren van de app-id-URI:

  • De api- of https-URI-schema's worden aanbevolen. Stel de eigenschap in de ondersteunde indelingen in om URI-conflicten in uw organisatie te voorkomen. Gebruik geen jokertekens.
  • Gebruik een geverifieerd domein van uw organisatie.
  • Houd een inventaris van de URI's in uw organisatie bij om de beveiliging te handhaven.

De volgende URI-indelingen voor toepassings-id's op basis van API- en HTTP-schema’s worden ondersteund. Vervang de waarden van de tijdelijke aanduidingen zoals beschreven in de lijst onder de tabel.

Ondersteunde toepassings-id
URI-indelingen		 Voorbeelden van URI’s van toepassings-id’s
<api:// appId> api://00001111-aaaa-2222-bbbb-3333cccc4444
<api:// tenantId>/<appId> api://aaaabbbb-0000-cccc-1111-dddd2222eeee/00001111-aaaa-2222-bbbb-3333cccc4444
<api:// tenantId>/<tekenreeks> api://aaaabbbb-0000-cccc-1111-dddd2222eeee/api
<api:// tekenreeks>/<appId> api://productapi/00001111-aaaa-2222-bbbb-3333cccc4444
<https:// tenantInitialDomain.onmicrosoft.com/>< string> https://contoso.onmicrosoft.com/productsapi
<https:// verifiedCustomDomain>/<string> https://contoso.com/productsapi
<https:// tekenreeks>.<verifiedCustomDomain> https://product.contoso.com
<https:// tekenreeks>.<verifiedCustomDomain>/<string> https://product.contoso.com/productsapi
<api:// tekenreeks>.<verifiedCustomDomainOrInitialDomain>/<string> api://contoso.com/productsapi
  • <appId>: de eigenschap van de toepassings-id (appId) van het toepassingsobject.
  • <string>: de tekenreekswaarde voor de host of het API-padsegment.
  • <tenantId>: een GUID die door Azure wordt gegenereerd om de tenant in Azure weer te geven.
  • <tenantInitialDomain> - <tenantInitialDomain.onmicrosoft.com>, waarbij <tenantInitialDomain> de initiële domeinnaam is die de maker van de tenant heeft opgegeven bij het maken van de tenant.
  • <verifiedCustomDomain> : een geverifieerd aangepast domein dat is geconfigureerd voor uw Microsoft Entra-tenant.

Notitie

Als u het api://-schema gebruikt, voegt u direct na api:// een tekenreekswaarde toe. Bijvoorbeeld: api://<tekenreeks>. Deze tekenreekswaarde kan een GUID of een willekeurige tekenreeks zijn. Als u een GUID-waarde toevoegt, moet deze overeenkomen met de app-id of de tenant-id. Als u een tekenreekswaarde gebruikt, moet deze een geverifieerd aangepast domein of een oorspronkelijk domein van uw tenant gebruiken. De aanbeveling is om api://< appId> te gebruiken.

Belangrijk

De URI-waarde van de toepassings-id mag niet eindigen met een slash "/"-teken.

Belangrijk

De URI-waarde van de toepassings-id moet uniek zijn binnen uw tenant.

Versie van toegangstoken

Deze sectie is alleen van toepassing op resourcetoepassingen, dat wil zeggen toepassingen die fungeren als het doelpubliek in toegangstokens. Resourcetoepassingen zijn doorgaans web-API's. Als een toepassing alleen fungeert als een client (wat betekent dat deze tokens verkrijgt om te verzenden naar resources zoals Microsoft Graph), is deze sectie niet van toepassing.

Resourcetoepassingen die aangepaste id-URI's hebben geconfigureerd, moeten de v2.0-toegangstokenindeling gebruiken. Als u wilt controleren of een app v2.0-toegangstokens moet gebruiken, bekijkt u de identifierUris eigenschap op de manifestpagina app-registraties voor de app.

Schermopname van de ervaring voor het wijzigen van id-URI's in de manifesteditor.

Als er waarden zijn geconfigureerd die daar niet in de indeling api://{appId} staan of api://{tenantId}/{appId}, moet de app v2.0-toegangstokens gebruiken.

Als u een upgrade wilt uitvoeren naar v2.0-toegangstokens, moet u eerst controleren of de app v2.0-tokenclaims kan verwerken. Werk vervolgens de versie van het toegangstoken bij die aan de toepassing is uitgegeven, met behulp van de manifesteditor.

Schermopname van de versie-ervaring van het updatetoken.

Nadat de toepassingsconfiguratie is bijgewerkt voor het gebruik van v2.0-tokens, moet u ervoor zorgen dat de validatielogica van de toepassing wordt gewijzigd om alleen zijn appId te accepteren.

Eigenschapsvergrendeling van toepassingsexemplaren

Wanneer een toepassing een service-principal heeft ingericht in een tenant, kan die service-principal worden aangepast door een tenantbeheerder. Dit geldt ongeacht of die tenant de thuistenant van de toepassing of een buitenlandse tenant is. Deze aanpassingsmogelijkheden kunnen wijzigingen mogelijk maken die de eigenaar van de app niet had verwacht, wat leidt tot beveiligingsrisico's. Referenties kunnen bijvoorbeeld worden toegevoegd aan de service-principal, ook al moeten referenties doorgaans eigendom zijn van en worden beheerd door de app-ontwikkelaar en -eigenaar.

Om dit risico te verminderen, moeten toepassingen het exemplaarvergrendeling van de app configureren. Bij het configureren van app-exemplaarvergrendeling vergrendelt u altijd elke gevoelige eigenschap die beschikbaar is. Het configureren van deze eigenschap is met name essentieel voor toepassingen met meerdere tenants, wat betekent dat toepassingen die in meerdere tenants of organisaties worden gebruikt, maar wel door alle toepassingen kunnen en moeten worden ingesteld.

Machtigingen

Uw toepassing moet mogelijk machtigingen krijgen voor toegang tot beveiligde resources of API's. Wanneer u machtigingen aanvraagt, moet u altijd het volgende controleren:

Configuratie van app-eigendom

Eigenaren kunnen alle aspecten van een geregistreerde toepassing beheren. Het is belangrijk dat u regelmatig het eigendom van alle toepassingen in de organisatie controleert. Zie Microsoft Entra-toegangsbeoordelingen voor meer informatie. Onder Eigenaren voor de toepassing in de Azure Portal kunnen de eigenaren van de toepassing worden beheerd.

Schermopname waarop zichtbaar is waar eigenaren van de toepassing worden beheerd.

Houd rekening met de volgende richtlijnen met betrekking tot het opgeven van toepassingseigenaren:

  • Toepassingseigendom moet worden beperkt tot een minimale set personen binnen de organisatie.
  • Een beheerder moet elke paar maanden de lijst met eigenaren bekijken om ervoor te zorgen dat eigenaren nog steeds deel uitmaken van de organisatie en nog steeds eigenaar zijn van een toepassing.

Entra-aanbevelingen controleren

Met de functie Microsoft Entra-aanbevelingen kunt u de status van uw tenant controleren, zodat u dat niet hoeft te doen. Deze aanbevelingen helpen ervoor te zorgen dat uw tenant een veilige en gezonde status heeft, terwijl u ook de waarde kunt maximaliseren van de functies die beschikbaar zijn in Microsoft Entra ID. Controleer regelmatig alle actieve Microsoft Entra-aanbevelingen die betrekking hebben op app-eigenschappen of app-configuratie om uw app-ecosysteem in een goede staat te houden.