Strategie voor toepassingsmachtigingen ontwikkelen

Als u leert ontwikkelen met behulp van Zero Trust-principes, raadpleegt u dit artikel nadat u autorisatie verkrijgen hebt bekeken voor toegang tot resources en een strategie voor gedelegeerde machtigingen ontwikkelen. Definieer de benadering van uw toepassingsmachtigingen voor referentiebeheer wanneer u het Microsoft Identity Platform gebruikt om uw toepassingen te verifiëren en te autoriseren en machtigingen en toestemming te beheren.

Wanneer er geen gebruiker betrokken is, hebt u geen effectief machtigingsmodel omdat uw toepassing altijd de vooraf toegewezen machtigingen krijgt.

• App bewijst dat het de app is die toestemming aanvraagt. Uw toepassing bewijst zijn eigen identiteit met een van de volgende methoden:

  • een certificaat, wat de beste optie is, of
  • een geheim in een geavanceerd geheimbeheersysteem of
  • Wanneer u uw services in Azure ontwikkelt, gebruikt u Beheerde identiteiten voor Azure-resources en raadpleegt u de volgende sectie Toepassingsreferenties beheren.

• App vereist altijd vooraf beheerderstoestemming. Uw toepassing vraagt deze machtiging aan met het .default bereik. Er worden de machtigingen aangevraagd die de beheerder aan de toepassing toewijst.

• Transgebruikersfunctionaliteit. User.ReadWrite.All Standaard kan uw toepassing het profiel van elke gebruiker bijwerken. Als toepassingsmachtiging kan uw toepassing het profiel van elke gebruiker in de tenant lezen en bijwerken.

• Machtigingen die aan de app zijn verleend, zijn altijd de gebruikte machtigingen. In tegenstelling tot een gedelegeerde machtiging zijn toepassingsmachtigingen niet gebonden aan wat een bepaalde gebruiker kan doen.

Toepassingsmachtigingen beperken

Er zijn drie manieren om een toepassing te beperken tot minder dan globale toegang.

• Microsoft Teams-apps hebben resourcespecifieke toestemming (RSC) waarmee een toepassing toegang heeft tot een specifiek team in plaats van toegang te krijgen tot alle teams in de onderneming. RSC is een Microsoft Teams- en Microsoft Graph API-integratie waarmee uw app API-eindpunten kan gebruiken en specifieke resources kan beheren. Met het machtigingsmodel kunnen Teams- en Chat-eigenaren toestemming verlenen voor uw toepassing om hun Teams- en Chat-gegevens te openen en te wijzigen.

• Microsoft Exchange-beheerders kunnen Exchange-toepassingsbeleid maken om app-toegang tot specifieke postvakken te beperken met een PowerShell-script. Ze kunnen een bepaalde toepassing beperken tot specifieke postvakken met Calendar.Read of Mail.Read toegang. Zo kunt u bijvoorbeeld een automatisering bouwen waarmee slechts één postvak kan worden gelezen of alleen e-mail kan worden verzonden vanuit één postvak en niet van iedereen in de onderneming.

• SharePoint heeft Sites.Selected als een specifiek bereik om gedetailleerde machtigingen toe te staan voor toegang tot SharePoint met een toepassing. Sites.Selected Kiezen voor uw toepassing in plaats van een van de andere machtigingsresultaten, standaard, in uw toepassing die geen toegang hebben tot sharePoint-siteverzamelingen. De beheerder gebruikt het eindpunt voor sitemachtigingen om lees-, schrijf- of lees- en schrijfmachtigingen toe te kennen aan uw toepassing.

Referenties voor toepassingen beheren

Referentiecontroles kunnen ervoor zorgen dat uw toepassing snel herstelt na een mogelijke schending. De volgende aanbevolen procedures helpen u bij het ontwikkelen van toepassingen die detectie en herstel uitvoeren, terwijl downtime wordt vermeden en legitieme gebruikers worden beïnvloed. Deze aanbevelingen ondersteunen het Zero Trust-principe van een inbreuk bij het voorbereiden van het reageren op een beveiligingsincident.

• Verwijder alle geheimen uit code en configuratie. Wanneer u het Azure-platform gebruikt, plaatst u geheimen in Key Vault en opent u deze via beheerde identiteiten voor Azure-resources. Zorg ervoor dat uw code bestand is tegen geheime rotaties als er een inbreuk optreedt. IT-beheerders kunnen geheimen en certificaten verwijderen en roteren zonder uw toepassing te verwijderen of van invloed te zijn op legitieme gebruikers.

• Gebruik certificaten in plaats van clientgeheimen, tenzij er een veilig proces is om geheimen te beheren. Aanvallers weten dat clientgeheimen doorgaans minder veilig worden verwerkt en dat het gebruik van gelekte geheimen moeilijk te volgen is. Certificaten kunnen beter worden beheerd en ingetrokken als er inbreuk is op de certificaten. Wanneer u geheimen gebruikt, bouwt of gebruikt u een veilige no-touch-implementatie en rollover-proces. Gebruik geheimen met een ingestelde verloopperiode (bijvoorbeeld één jaar, twee jaar) en vermijd nooit verlopen.

• Rol regelmatig certificaten en geheimen uit om tolerantie in uw toepassing te bouwen en voorkomt storingen vanwege een noodoverschakeling.

Volgende stappen

• U kunt autorisatie verkrijgen voor toegang tot resources om te begrijpen hoe u Zero Trust het beste kunt garanderen bij het verkrijgen van machtigingen voor toegang tot resources voor uw toepassing.
• Door een strategie voor gedelegeerde machtigingen te ontwikkelen, kunt u de beste aanpak implementeren voor het beheren van machtigingen in uw toepassing en ontwikkelen met behulp van Zero Trust-principes.
• Met best practices voor autorisatie kunt u de beste autorisatie-, machtigings- en toestemmingsmodellen voor uw toepassingen implementeren.
• Aanvragen van machtigingen waarvoor beheerderstoestemming is vereist, beschrijft de machtigings- en toestemmingservaring wanneer toepassingsmachtigingen beheerderstoestemming vereisen.
• API Protection beschrijft aanbevolen procedures voor het beveiligen van uw API via registratie, het definiëren van machtigingen en toestemming en het afdwingen van toegang om uw Zero Trust-doelstellingen te bereiken.
• Geef referenties voor toepassingsidentiteiten op wanneer er geen gebruiker is waarom Beheerde identiteiten voor Azure-resources de beste methode voor clientreferenties zijn voor services (niet-gebruikerstoepassingen) in Azure.