Freigeben über

Datenschutz, Berechtigungen und Sicherheit für Outlook-Add-Ins

  • Artikel

Endbenutzer, Entwickler und Administratoren können die mehrstufigen Berechtigungsstufen des Sicherheitsmodells für Outlook-Add-Ins verwenden, um den Datenschutz und die Leistung zu steuern.

In diesem Artikel werden die Berechtigungen beschrieben, die Outlook-Add-Ins anfordern können, und anschließend das Sicherheitsmodell aus den folgenden Blickwinkeln betrachtet.

  • AppSource: Add-In-Integrität

  • Endbenutzer: Überlegungen zu Datenschutz und Leistung

  • Entwickler: Einschränkungen bei der Auswahl von Berechtigungen und der Ressourcennutzung

  • Administratoren: Berechtigungen zum Festlegen von Leistungsschwellenwerten

Hinweis

Dieser Artikel konzentriert sich auf Informationen zu Datenschutz, Berechtigungen und Sicherheit speziell für Outlook-Add-Ins. Falls noch nicht geschehen, empfehlen wir Ihnen, sich zuerst mit Datenschutz und Sicherheit für Office-Add-Ins zu informieren, da derEn Inhalt für alle Office-Add-Ins gilt.

Berechtigungsmodell

Ein mehrstufiges Berechtigungsmodell liefert die Grundlage für Datenschutz und Sicherheit für Benutzer von Outlook-Add-Ins. Ein Mail-Add-in würde die erforderliche Berechtigungsstufe offenlegen und dadurch den möglichen Zugriff und Aktionen identifizieren, die von dem Outlook-Add-In mit den Postfachdaten des Benutzers ausgeführt werden können.

Es gibt vier Stufen von Berechtigungen.

Kanonischer Name der Berechtigungsstufe
 Nur Add-In-Manifestname Einheitliches Manifest für Microsoft 365-Name Zusammenfassungsbeschreibung
eingeschränkt Restricted MailboxItem.Restricted.User Ermöglicht den Zugriff auf Eigenschaften und Methoden, die sich nicht auf bestimmte Informationen zum Benutzer oder E-Mail-Element beziehen.
Element lesen ReadItem MailboxItem.Read.User Zusätzlich zu dem, was in restricted zulässig ist, ist Folgendes möglich:
  • Reguläre Ausdrücke
  • Lesezugriff auf Outlook-Add-in-API
  • Abrufen der Elementeigenschaften und des Rückruftokens
  • Schreiben benutzerdefinierter Eigenschaften
Element lesen/schreiben ReadWriteItem MailboxItem.ReadWrite.User Zusätzlich zu dem, was in einem Leseelement zulässig ist, ist Folgendes möglich:
  • voller Zugriff auf Outlook-Add-In-API mit Ausnahme von makeEwsRequestAsync
  • Festlegen der Elementeigenschaften
Lese-/Schreibpostfach ReadWriteMailbox Mailbox.ReadWrite.User Zusätzlich zu dem, was im Lese-/Schreibzugriff zulässig ist, ist Folgendes möglich:
  • Erstellen, Lesen und Schreiben von Elementen und Ordnern
  • Senden von Elementen
  • Aufrufen von makeEwsRequestAsync

Berechtigungen werden im Manifest deklariert. Das Markup variiert je nach Art des Manifests.

  • Nur Add-In-Manifest: Verwenden Sie das <Permissions-Element> .
  • Einheitliches Manifest für Microsoft 365: Verwenden Sie die Eigenschaft "name" eines Objekts im Array "authorization.permissions.resourceSpecific".

Hinweis

Die vier Berechtigungsstufen sind kumulativ: Die Berechtigung Postfach lesen/schreiben schließt die Berechtigungen Element lesen/schreiben, Element lesen und Eingeschränkt ein, Element lesen/schreiben schließt Element lesen und Eingeschränkt ein, und die Berechtigung Element lesen schließt Eingeschränkt ein.

Die folgende Abbildung zeigt die vier Berechtigungsstufen und gibt einen Überblick darüber, was Endbenutzer, Entwickler und Administratoren auf den einzelnen Stufen jeweils tun können. Weitere Informationen zu diesen Berechtigungen finden Sie unter Endbenutzer: Überlegungen zu Datenschutz und Leistung, Entwickler: Einschränkungen bei der Auswahl von Berechtigungen und der Ressourcennutzung und Grundlegendes zu Berechtigungen bei Outlook-Add-Ins.

Diagramm des Vier-Ebenen-Berechtigungsmodells für Mail-Apps-Schema v1.1.

AppSource: Add-In-Integrität

AppSource hostet Add-Ins, die von Endbenutzern und Administratoren installiert werden können. AppSource setzt die folgenden Maßnahmen zur Erhaltung der Integrität dieser Outlook-Add-Ins durch.

  • Der Hostserver eines Add-Ins muss für die Kommunikation immer Secure Socket Layer (SSL) verwenden.

  • Erfordert, dass Entwickler einen Identitätsnachweis, eine vertragliche Vereinbarung und eine entsprechende Datenschutzrichtlinie vorlegen, um Add-ins einreichen zu können.

  • Add-ins müssen im schreibgeschützten Modus archiviert werden.

  • Unterstützt ein Benutzerüberprüfungssystem für verfügbare Add-Ins zum Fördern einer Community mit eigenen Richtlinien.

Optionale verbundene Erfahrungen

Endbenutzer und IT-Administratoren können die optionalen verbundenen Erfahrungen in Office-Desktop- und mobilen Clients deaktivieren. Bei Outlook-Add-Ins hängt die Auswirkung der Deaktivierung der Einstellung Optional verbundene Erfahrungen vom Client ab. Dies bedeutet jedoch in der Regel, dass vom Benutzer installierte Add-Ins und der Zugriff auf appSource nicht zulässig sind. Add-Ins, die vom IT-Administrator einer Organisation über die zentrale Bereitstellung bereitgestellt werden, sind weiterhin verfügbar.

Client Verhalten, wenn optionale verbundene Erfahrungen deaktiviert sind
Die Verfügbarkeit von Add-Ins und der Zugriff auf AppSource sind davon nicht betroffen, sodass Benutzer ihre Add-Ins weiterhin verwalten können, einschließlich der vom Administrator bereitgestellten Add-Ins .
  • Windows (klassisch)1
  • Mac
 Die Schaltfläche Alle Apps2 oder Add-Ins abrufen wird nicht angezeigt, sodass Benutzer ihre Add-Ins nicht verwalten oder auf AppSource zugreifen können.
  • Android
  • iOS
 Im Dialogfeld Add-Ins abrufen werden nur vom Administrator bereitgestellte Add-Ins angezeigt.

Hinweis

1 Unter Windows ist die Unterstützung für diese Benutzeroberfläche ab Version 2008 (Build 13127.20296) verfügbar. Weitere Informationen zu Ihrer Clientversion finden Sie auf der Seite mit dem Updateverlauf für Microsoft 365 und wie Sie Ihre Office-Clientversion und ihren Updatekanal finden.

2 Ab dem klassischen Outlook unter Windows Version 2303 (Build 16215.10000) wird die Schaltfläche Alle Apps verwendet, um Add-Ins zu verwalten und auf AppSource zuzugreifen.

Allgemeine Informationen zu Add-Ins finden Sie unter Datenschutz und Sicherheit für Office-Add-Ins.

Endbenutzer: Überlegungen zu Datenschutz und Leistung

Das Sicherheitsmodell geht auf folgende Weise auf die Sicherheits-, Datenschutz- und Leistungsbedenken von Endbenutzern ein.

  • Nachrichten von Endbenutzern, die durch die Verwaltung von Informationsrechten (IRM) von Outlook geschützt sind, interagieren nicht mit Add-Ins in den folgenden Instanzen.

    • Wenn von Outlook auf mobilen Geräten auf die IRM-geschützte Nachricht zugegriffen wird.

    • Wenn die IRM-geschützte Nachricht eine Vertraulichkeitsbezeichnung enthält, wobei die Option Programmgesteuerten Zugriff zulassen auf festgelegt ist false.

    Weitere Informationen zur IRM-Unterstützung in Add-Ins finden Sie unter Durch IRM geschützte E-Mail-Elemente.

  • Bevor sie ein Add-In aus AppSource installieren, werden Endbenutzern die Zugriffsmöglichkeiten und Aktionen des Add-Ins für ihre Daten angezeigt, die explizit bestätigt werden müssen, damit die Installation fortgesetzt werden kann. Es wird kein Outlook-Add-In automatisch ohne manuelle Überprüfung durch den Benutzer oder Administrator per Push auf den Clientcomputer übertragen.

  • Die Gewährung der Berechtigung Eingeschränkt beschränkt den Zugriff des Outlook-Add-Ins ausschließlich auf das aktuelle Element. Durch das Erteilen der Berechtigung zum Lesen von Elementen kann das Outlook-Add-In nur auf das aktuelle Element auf personenbezogene Informationen wie Absender- und Empfängernamen und E-Mail-Adressen zugreifen.

  • Ein Endbenutzer kann Outlook-Add-Ins mit niedriger Vertrauenswürdigkeit nur für sich selbst installieren. Outlook-Add-Ins für ein Unternehmen werden von einem Administrator installiert.

  • Endbenutzer können Outlook-Add-Ins installieren, die überzeugende kontextabhängige Szenarien aktivieren und dennoch die Sicherheitsrisiken des Benutzers minimieren.

  • Manifestdateien von installierten Outlook-Add-Ins werden im E-Mail-Konto des Benutzers gesichert.

  • Der Datenaustausch mit Servern, auf denen Office-Add-Ins gehostet werden, ist immer mit dem SSL-Protokoll (Secure Socket Layer) verschlüsselt.

  • Outlook unter Windows (klassisch) und auf Mac überwachen die Leistung installierter Outlook-Add-Ins, üben Governance-Steuerung aus und machen Add-Ins nicht verfügbar, wenn sie die Grenzwerte in den folgenden Bereichen überschreiten.

    • Reaktionszeit für die Aktivierung

    • Anzahl der Fehler bei der Aktivierung oder erneuten Aktivierung

    • Speicherauslastung

    • CPU-Auslastung

    Steuerung verhindert Denial of Service-Angriffe und hält die Leistung des Add-Ins auf einem adäquaten Niveau. Die Geschäftsleiste warnt Endbenutzer über Add-Ins, die Outlook unter Windows (klassisch) und auf Mac basierend auf einer solchen Governancesteuerung nicht verfügbar gemacht haben.

  • Endbenutzer können jederzeit die von installierten Outlook-Add-Ins angeforderten Berechtigungen überprüfen und alle Add-Ins im Exchange Admin Center verfügbar oder nicht verfügbar machen.

Entwickler: Einschränkungen bei der Auswahl von Berechtigungen und der Ressourcennutzung

Das Sicherheitsmodell bietet Entwicklern detaillierte Berechtigungsstufen zur Auswahl sowie zu beachtende strikte Leistungsrichtlinien.

Mehrstufige Berechtigungen erhöhen die Transparenz

Entwickler sollten das mehrstufige Berechtigungsmodell befolgen, damit sie Transparenz bereitstellen können und die Bedenken von Benutzern ausräumen können, welche Add-ins sie für Daten und Ihr Postfach verwenden können, sodass die Add-in-Installation indirekt gefördert wird.

  • Entwickler fordern auf der Grundlage der Anforderungen für das Lesen oder Schreiben bestimmter Eigenschaften eines Elements oder für das Erstellen und Senden eines Elements für ein Outlook-Add-In eine adäquate Berechtigungsstufe an.

  • Wie oben erwähnt, fordern Entwickler die Berechtigung im Manifest an.

    Im folgenden Beispiel wird die Berechtigung zum Lesen von Elementen im reinen Add-In-Manifest angefordert.

    <Permissions>ReadItem</Permissions>

    Im folgenden Beispiel wird die Berechtigung zum Lesen von Elementen im einheitlichen Manifest für Microsoft 365 angefordert.

    "authorization": {
  "permissions": {
    "resourceSpecific": [
      ...
      {
        "name": "MailboxItem.Read.User",
        "type": "Delegated"
      },
    ]
  }
},

  • Entwickler können die eingeschränkte Berechtigung anfordern, wenn das Outlook-Add-In für einen bestimmten Typ von Outlook-Element (Termin oder Nachricht) aktiviert wird.

  • Entwickler sollten die Berechtigung zum Lesen von Elementen anfordern, wenn das Outlook-Add-In Folgendes ausführen muss:

    • Liest die Eigenschaften des aktuellen Elements.
    • Schreiben Sie benutzerdefinierte Eigenschaften, die vom Add-In für das aktuelle Element festgelegt werden, erfordern jedoch kein Lesen oder Schreiben in andere Elemente.
    • Erstellen oder senden Sie eine Nachricht im Postfach des Benutzers.

  • Entwickler fordern die Berechtigung Lese-/Schreibzugriff auf Element an, wenn das Outlook-Add-In in Eigenschaften des erstellten Elements schreiben muss, z. B. die Empfängernamen, E-Mail-Adressen, Textkörper oder Betreff oder Element-Anlagen hinzufügen oder entfernen muss.

  • Entwickler fordern die Berechtigung Postfach lesen/schreiben nur an, wenn das Outlook-Add-In mindestens eine der folgenden Aktionen unter Verwendung der mailbox.makeEWSRequestAsync-Methode ausführen muss.

    • Lesen oder Schreiben von Eigenschaften von Elementen im Postfach.
    • Erstellen, Lesen oder Schreiben von Elementen im Postfach oder Senden von Elementen an dieses
    • Erstellen, Lesen oder Schreiben in Ordnern im Postfach

Optimierung der Ressourcennutzung

Entwickler sollten sich der Ressourcennutzungsgrenzwerte für die Aktivierung bewusst sein und die Leistungsoptimierung in ihren Entwicklungsworkflow integrieren, um die Wahrscheinlichkeit zu verringern, dass ein dienst mit schlechter Leistung von Add-Ins den Host verweigert wird. Entwickler sollten die Richtlinien beim Entwerfen von Aktivierungsregeln befolgen, wie unter Grenzwerte für die Aktivierung und JavaScript-API für Outlook-Add-Ins beschrieben. Wenn ein Outlook-Add-In in Outlook unter Windows (klassisch) oder auf dem Mac ausgeführt werden soll, sollten Entwickler überprüfen, ob das Add-In innerhalb der Ressourcennutzungsgrenzwerte ausgeführt wird.

Weitere Maßnahmen zur Förderung der Benutzersicherheit

Entwickler sollten auch Folgendes vorbereitet sein und entsprechend planen.

  • Entwickler können ActiveX-Steuerelemente nicht in Add-Ins verwenden, da sie nicht unterstützt werden.

  • Entwickler sollten folgendermaßen vorgehen, wenn Sie ein Outlook-Add-In bei AppSource einreichen.

    • Erstellen eines SSL-Zertifikats mit erweiterter Überprüfung als Identitätsnachweis.

    • Hosten des eingereichten Add-ins auf einem Webserver, der SSL unterstützt

    • Erstellen einer adäquaten Datenschutzrichtlinie

    • Vorbereitung auf die Unterzeichnung einer vertraglichen Vereinbarung beim Einreichen des Add-ins

Administratoren: Berechtigungen

Das Sicherheitsmodell gewährt Administratoren die folgenden Rechte und legt ihnen die folgenden Verpflichtungen auf.

  • Sie können verhindern, dass Endbenutzer Outlook-Add-Ins installieren, einschließlich Add-Ins aus AppSource.

  • Kann jedes Outlook-Add-In über das Exchange Admin Center verfügbar machen oder nicht verfügbar machen.

  • Gilt nur für das klassische Outlook unter Windows: Kann Leistungsschwellenwerteeinstellungen durch GPO-Registrierungseinstellungen außer Kraft setzen.

Siehe auch