📟Verwendung der Application Permissions

Application Permissions vs. delegierte Berechtigungen für SharePoint, OneDrive, Outlook und Teams

Um eine zuverlässige Verbindung zu SharePoint und OneDrive zu gewährleisten, verwendet amber Application Permissions (Anwendungsberechtigungen) anstelle von delegierten Berechtigungen. Diese Entscheidung ist grundlegend dafür, dass der SharePoint- und OneDrive-Connector wie vorgesehen funktioniert, und folgt den Microsoft-Richtlinien für die App-Entwicklung hinsichtlich der Verwendung von reinem App-Zugriff. Kurz gesagt empfiehlt Microsoft den reinen App-Zugriff, wenn eine Anwendung ohne Benutzereingriff ausgeführt werden muss, auf Daten vieler Benutzer zugreift oder risikobehaftete Muster wie die lokale Speicherung von Benutzeranmeldedaten und die Imitation von Benutzern vermeiden soll. Zu diesen Mustern gehören beispielsweise automatisierte Jobs, die nach Zeitplan ausgeführt werden, sowie Dienste, die Inhalte von vielen verschiedenen Benutzern oder Kanälen lesen müssen.

Overview of Microsoft Graph permissions - Microsoft Graph | Microsoft Learn
Graphic from https://learn.microsoft.com/en-us/graph/permissions-overview?tabs=http

Warum amber Anwendungsberechtigungen verwendet

  • Autonomer Betrieb über den Mandanten hinweg
    amber läuft kontinuierlich und unabhängig von einer bestimmten Benutzersitzung. Es muss regelmäßig Inhalte, Berechtigungsstrukturen und Aktivitätssignale in SharePoint und OneDrive crawlen, um den Index genau und aktuell zu halten. Dieser systematische Betrieb erfordert ein Berechtigungsmodell, das nicht davon abhängt, dass eine Person angemeldet ist.

  • Umfassender, benutzerunabhängiger Zugriff
    Delegierte Berechtigungen agieren „als Benutzer“ und übernehmen die Einschränkungen dieses Benutzers. Im Gegensatz dazu ermöglichen Anwendungsberechtigungen amber, alle relevanten Bereiche zu durchlaufen – unabhängig davon, wer angemeldet ist –, sodass Inhalte ermittelt, Berechtigungen beachtet und Aktualisierungen konsistent in der gesamten Umgebung erfasst werden können.

  • Effizienz und Skalierbarkeit im Unternehmensmaßstab
    Große, verteilte Umgebungen erfordern eine asynchrone, weitreichende Datenerfassung. Der Rückgriff auf delegierte Berechtigungen würde das Crawling an einzelne Benutzerkontexte und Sitzungen binden und so Engpässe und operative Lücken verursachen. Anwendungsberechtigungen beseitigen diese Einschränkungen, sodass amber mit Ihren Inhalten und der Komplexität Ihrer Organisation skalieren kann.

  • Mandantenweite Ausfallsicherheit bei
    Ratenbegrenzungen Microsoft Graph erzwingt Ratenbegrenzungen auf Mandantenebene pro registrierter Anwendung. Bei Verwendung delegierter Berechtigungen müsste amber für jede Anfrage separate Graph-API-Aufrufe im Namen jedes Benutzers durchführen, was schnell zu einer Überschreitung der Ratenbegrenzungen führen würde. Anwendungsberechtigungen reduzieren diesen Aufwand erheblich, indem sie Duplikate pro Benutzer vermeiden und so den Durchsatz sowie die allgemeine Plattformstabilität gewährleisten.

Einschränkungen delegierter Berechtigungen

  • Abhängigkeit vom Benutzerkontext
    Delegierte Berechtigungen beschränken amber auf das, worauf ein aktuell angemeldeter Benutzer Zugriff hat, was die Abdeckung fragmentiert und die Indizierung verzögern kann. Diese Abhängigkeit birgt das Risiko einer veralteten Sichtbarkeit sensibler oder neu eingeschränkter Inhalte, da Aktualisierungen erst erfasst werden, wenn der betreffende Benutzer wieder aktiv ist.

  • Annahmen zur Interaktivität
    Delegierte Berechtigungen eignen sich für Anwendungsfälle, in denen eine App agiert, während ein Benutzer interagiert. Die Crawling-Jobs von amber laufen jedoch unbeaufsichtigt und Asset für Asset ab. Dieser nicht-interaktive, auf den Hintergrund ausgerichtete Ansatz steht von Natur aus im Widerspruch zu delegierten Berechtigungen und deren sitzungszentriertem Modell.

Token-Sicherheit und Authentifizierung

Die Crawler von amber authentifizieren sich bei Microsoft Graph und SharePoint-REST-APIs mithilfe eines Service Principal (App-Registrierung). Der Service Principal ist mit einem Client-Secret konfiguriert, das für API-Anfragen verwendet wird. Das Sicherheitsmodell ist darauf ausgelegt, dieses Secret im Ruhezustand, während der Übertragung und bei der Verwendung zu schützen.

Sichere Speicherung

  • Das Client-Secret, das Sie amber zur Verfügung stellen, wird im dedizierten Secret Store Ihres Mandanten gespeichert, demselben geschützten Repository, das auch für andere Connector-Anmeldedaten verwendet wird.

  • Jeder amber-Mandant verfügt über einen eigenen, isolierten Secret Store, um eine mandantenübergreifende Offenlegung zu verhindern.

  • Geheimnisse werden zweimal verschlüsselt – einmal vor dem Speichern und erneut im Ruhezustand.

Sicherer Zugriff

  • Bei jedem Crawl verwenden Amber-Konnektoren ein dafür vorgesehenes Dienstkonto, um das Client-Secret aus dem Secret Store abzurufen.

  • Der Secret wird während des Crawls nur im verschlüsselten Speicher gehalten und unmittelbar danach gelöscht.

  • Es wird niemals im Crawler gespeichert, niemals in Code eingebettet und niemals in einer Amber-Komponente außer dem Secret Store auf die Festplatte geschrieben.

Zusätzliche Kontrollen

  • Für erhöhte Sicherheit können Sie über Entra ID Conditional Access IP-Beschränkungen durchsetzen und die Nutzung des Client-Secrets auf die spezifischen IP-Bereiche beschränken, die mit den Crawlern Ihres Amber-Tenants verknüpft sind. Dies fügt zusätzlich zum Schutz der Anmeldedaten eine Netzwerkgrenze hinzu und reduziert das Risiko weiter.