Strategie voor het ontwikkelen van toepassingsmachtigingen

  • Artikel

Als u leert ontwikkelen met behulp van Zero Trust-principes, raadpleegt u dit artikel na het controleren van het verkrijgen van autorisatie voor toegang tot resources en het ontwikkelen van een strategie voor gedelegeerde machtigingen. 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 dezelfde machtigingen krijgt als de specifieke gebruiker van uw toepassing is verleend.

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

    • een certificaat, wat de beste optie is, of
    • een geheim in een geavanceerd geheimbeheersysteem of
    • een geheim wanneer u uw services in Azure ontwikkelt en beheerde identiteiten gebruikt voor Azure-resources. Zie de volgende sectie met toepassingsreferenties beheren.

  • App vereist altijd vooraf beheerderstoestemming. Uw toepassing vraagt deze machtiging aan met het .default bereik. Hiermee wordt de machtigingen aangevraagd die de beheerder aan de toepassing toewijst. Ongeacht de naamgeving voor een bepaald bereik, zijn deze machtigingen standaard van toepassing op alle gebruikers.

  • Transgebruikersfunctionaliteit. User.ReadWrite.All Standaard kan uw toepassing het profiel van elke gebruiker bijwerken, zelfs Calendar.Read. Als toepassingsmachtiging kan uw toepassing de agenda van elke gebruiker in de tenant lezen.

  • 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 Als u voor uw toepassing kiest in plaats van een van de andere machtigingen, heeft uw toepassing standaard geen toegang 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 en downtime voorkomen en legitieme gebruikers beïnvloeden. 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