Entwickeln einer Strategie für Anwendungsberechtigungen

  • Artikel

Während Sie lernen, mithilfe von Zero Trust-Grundsätzen zu entwickeln, lesen Sie diesen Artikel nach der Überprüfung der Autorisierung für den Zugriff auf Ressourcen und die Entwicklung delegierter Berechtigungen. Definieren Sie Ihren Anwendungsberechtigungsansatz für die Anmeldeinformationsverwaltung, wenn Sie die Microsoft Identity Platform verwenden, um Ihre Anwendungen zu authentifizieren und zu autorisieren und Berechtigungen und Einwilligung zu verwalten.

Wenn kein Benutzer beteiligt ist, verfügen Sie nicht über ein effektives Berechtigungsmodell, da Ihrer Anwendung immer dieselben Berechtigungen gewährt werden, die dem spezifischen Benutzer Ihrer Anwendung erteilt wurden.

  • Die App beweist, dass die App die Berechtigung anfordert. Ihre Anwendung beweist ihre eigene Identität mit einer der folgenden Methoden:

  • Die App erfordert immer eine vorherige Administratoreinwilligung. Ihre Anwendung fordert diese Berechtigung mit dem .default Bereich an. Es werden die Berechtigungen angefordert, die der Administrator der Anwendung zuweist. Unabhängig von der Benennung für einen bestimmten Bereich gelten diese Berechtigungen standardmäßig für alle Benutzer.

  • Trans-Benutzerfunktionalität. Standardmäßig ermöglicht User.ReadWrite.All Ihre Anwendung, das Profil jedes Benutzers zu aktualisieren, auch Calendar.Read. Als Anwendungsberechtigung kann Ihre Anwendung den Kalender jedes Benutzers im Mandanten lesen.

  • Berechtigungen, die der App gewährt werden, sind immer die verwendeten Berechtigungen. Im Gegensatz zu einer delegierten Berechtigung sind Anwendungsberechtigungen nicht an die Aktionen eines bestimmten Benutzers gebunden.

Begrenzen der Anwendungsberechtigungen

Es gibt drei Möglichkeiten, eine Anwendung auf weniger als den globalen Zugriff zu beschränken.

  • Microsoft Teams-Apps verfügen über ressourcenspezifische Zustimmung (RSC), die es einer Anwendung ermöglicht, auf ein bestimmtes Team zuzugreifen, anstatt auf alle Teams im Unternehmen zuzugreifen. RSC ist eine API-Integration für Microsoft Teams und Microsoft Graph, mit der Ihre App API-Endpunkte verwenden und bestimmte Ressourcen verwalten kann. Das Berechtigungsmodell ermöglicht es Teams- und Chatbesitzern, Ihrer Anwendung die Zustimmung zu erteilen, auf ihre Teams- und Chatdaten zuzugreifen und diese zu ändern.

  • Microsoft Exchange-Administratoren können Exchange-Anwendungsrichtlinien erstellen, um den App-Zugriff auf bestimmte Postfächer mit einem PowerShell-Skript zu beschränken. Sie können eine bestimmte Anwendung auf bestimmte Postfächer mit Calendar.Read oder Mail.Read Zugriff beschränken. Auf diese Weise können Sie beispielsweise eine Automatisierung erstellen, die nur ein Postfach lesen oder nur E-Mails aus einem Postfach und nicht von allen Benutzern im Unternehmen senden kann.

  • SharePoint verfügt über Sites.Selected as a specific scope to allow granular permissions for accessing SharePoint with an application. Wenn Sie Sites.Selected für Ihre Anwendung anstelle einer der anderen Berechtigungen auswählen, hat Ihre Anwendung standardmäßig keinen Zugriff auf SharePoint-Websitesammlungen. Der Administrator verwendet den Endpunkt für Websiteberechtigungen, um Ihrer Anwendung Lese-, Schreib- oder Lese- und Schreibberechtigungen zu erteilen.

Verwalten von Anwendungsanmeldeinformationen

Die Hygiene von Anmeldeinformationen kann sicherstellen, dass Ihre Anwendung schnell von einer potenziellen Verletzung wiederhergestellt wird. Die folgenden bewährten Methoden leiten Sie bei der Entwicklung von Anwendungen, die Erkennung und Wartung durchführen, während Ausfallzeiten vermieden und legitime Benutzer beeinträchtigt werden. Diese Empfehlungen unterstützen das Zero Trust-Prinzip der Annahme von Sicherheitsverletzungen bei der Vorbereitung, auf einen Sicherheitsvorfall zu reagieren.

  • Entfernen Sie alle geheimen Schlüssel aus Code und Konfiguration. Wenn Sie die Azure-Plattform verwenden, platzieren Sie geheime Schlüssel im Key Vault , und greifen Sie über verwaltete Identitäten für Azure-Ressourcen darauf zu. Sorgen Sie dafür, dass Ihr Code widerstandsfähig ist, damit er im Falle einer Kompromittierung mit dem Wechsel des Geheimnisses umgehen kann. IT-Administratoren können geheime Schlüssel und Zertifikate entfernen und wechseln, ohne Ihre Anwendung zu beeinträchtigen oder legitime Benutzer zu beeinträchtigen.

  • Verwenden Sie Zertifikate anstelle geheimer Clientschlüssel, es sei denn, ein sicherer Prozess ist vorhanden, um geheime Schlüssel zu verwalten. Angreifer wissen, dass geheime Clientschlüssel tendenziell weniger sicher verarbeitet werden und die geheime Nutzung durch Lecks schwer zu verfolgen ist. Bei einer Kompromittierung können Zertifikate besser verwaltet und widerrufen werden. Wenn Sie geheime Schlüssel verwenden, erstellen oder verwenden Sie dafür einen sicheren No-Touch-Bereitstellungs- und Rollover-Prozess. Verwenden Sie geheime Schlüssel mit einem festgelegten Ablaufzeitraum (z. B. ein Jahr, zwei Jahre) und vermeiden Sie „läuft nie ab“.

  • Stellen Sie regelmäßig Zertifikate und geheime Schlüssel bereit, um Resilienz in Ihrer Anwendung zu erstellen und den Ausfall durch einen Notfall-Rollover zu vermeiden.

Nächste Schritte