Datenschutz und Sicherheit bei Office-Add-Ins

Prozesssicherheit

Office-Add-Ins werden durch eine Add-In-Laufzeitumgebung, ein mehrstufiges Berechtigungsmodell sowie Leistungskontrollen geschützt. Dieses Framework schützt die Benutzerfreundlichkeit auf folgende Weise.

• Der Zugriff auf den Benutzeroberflächenframe der Office-Clientanwendung wird verwaltet.

• Nur indirekter Zugriff auf den Ui-Thread der Office-Clientanwendung ist zulässig.

• Modale Interaktionen sind nicht zulässig. Beispielsweise sind Aufrufe der Methoden JavaScript alert, confirmund prompt nicht zulässig, da sie modal sind.

Darüber hinaus bietet das Laufzeitframework die folgenden Vorteile, um sicherzustellen, dass ein Office-Add-In die Umgebung des Benutzers nicht beschädigen kann.

• Der Prozess, über den das Add-In ausgeführt wird, wird isoliert.

• DLL- oder EXE-Ersetzung oder ActiveX-Komponenten sind nicht erforderlich.

• Einfache Installation und Deinstallation von Add-Ins.

Darüber hinaus kann die Verwendung von Arbeitsspeicher, CPU und Netzwerkressourcen durch Office-Add-Ins gesteuert werden, um optimale Leistung und Zuverlässigkeit sicherzustellen.

In den folgenden Abschnitten wird kurz beschrieben, wie die Laufzeitarchitektur die Ausführung von Add-Ins in Office-Clients auf Windows-basierten Geräten, auf Mac OS X-Geräten und in Webbrowsern unterstützt.

Clients unter Windows- und OS X-Geräte

In unterstützten Clients für Desktop- und Tabletgeräte wie Excel unter Windows und Outlook unter Windows (klassisch) und auf Mac werden Office-Add-Ins durch die Integration einer prozessinternen Komponente, der Office-Add-Ins-Runtime, unterstützt, die den Add-In-Lebenszyklus verwaltet und die Interoperabilität zwischen dem Add-In und der Clientanwendung ermöglicht. Die Add-in-Webseite selbst wird außerhalb des Prozesses gehostet. Auf einem Windows-Desktop- oder Tablet-Gerät wird die Add-In-Webseite in einem Internet Explorer- oder Microsoft Edge-Steuerelement gehostet , das wiederum in einem Add-In-Laufzeitprozess gehostet wird, der Sicherheit und Leistungsisolation bietet.

Auf Windows-Desktops muss der geschützte Modus in Internet Explorer für die eingeschränkte Websitezone aktiviert sein. Dieser ist normalerweise standardmäßig aktiviert. Wenn er deaktiviert ist, tritt ein Fehler auf, wenn Sie versuchen, ein Add-In zu starten.

Auf einem macOS-Desktop wird die Add-In-Webseite in einem Sandkasten-WebKit-Laufzeithostprozess gehostet, der ein ähnliches Maß an Sicherheit und Leistungsschutz bietet.

Die Office-Add-Ins-Laufzeit verwaltet die Kommunikation zwischen Prozessen, die Übersetzung von JavaScript-API-Aufrufen und -Ereignissen in systemeigene Aufrufe und Ereignisse sowie die Unterstützung von UI-Remoting, um das Rendern des Add-Ins innerhalb des Dokuments, in einem Aufgabenbereich oder neben einer E-Mail-Nachricht, einer Besprechungsanfrage oder einem Termin zu ermöglichen.

Webclients

In unterstützten Webclients werden Office-Add-Ins in einem iframe gehostet, der mit dem HTML5-Sandbox-Attribut ausgeführt wird. ActiveX-Komponenten oder das Navigieren auf der Hauptseite der Web App sind nicht zulässig. Die Unterstützung von Office-Add-Ins wird von den Web Apps durch die Integration der JavaScript-API für Office ermöglicht. Ähnlich wie bei den Desktopclientanwendungen verwaltet die JavaScript-API den Add-in-Lebenszyklus und die Interoperabilität zwischen dem Add-in und der Web-App. Diese Interoperabilität wird mithilfe einer speziellen frameübergreifenden Nachrichtenkommunikationsinfrastruktur implementiert. Die gleiche JavaScript-Bibliothek (Office.js), die auf Desktopclients verwendet wird, ist für die Interaktion mit der Web App verfügbar. Die folgende Abbildung zeigt die Infrastruktur, die im Browser ausgeführte Add-Ins in Office unterstützt, und die relevanten Komponenten (Webclient, iframe, Office-Add-Ins-Runtime und JavaScript-API für Office), die für deren Unterstützung erforderlich sind.

Add-In-Integrität in AppSource

Sie können Ihre Office-Add-Ins der Öffentlichkeit zur Verfügung stellen, indem sie diese in AppSource veröffentlichen. AppSource erzwingt die folgenden Measures, um die Integrität von Add-Ins aufrechtzuerhalten.

• Erfordert, dass der Hostserver eines Office-Add-Ins für die Kommunikation stets SSL (Secure Sockets Layer) verwendet.

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

• 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. Für Office-Add-Ins hat die Deaktivierung der Einstellung Optional verbundene Erfahrungen die Auswirkung, dass Benutzer nicht mehr über diese Clients auf Add-Ins oder den Microsoft 365- und Copilot-Store zugreifen können. Bestimmte Microsoft-Add-Ins, die als wichtig oder unternehmenskritisch gelten, und Add-Ins, die vom IT-Administrator einer Organisation über die zentrale Bereitstellung bereitgestellt werden, sind jedoch weiterhin verfügbar. Darüber hinaus bleiben Add-Ins und der Microsoft 365- und Copilot-Store in Outlook im Web verfügbar, unabhängig vom Status der Einstellung.

Weitere Informationen zum Outlook-spezifischen Verhalten finden Sie unter Datenschutz, Berechtigungen und Sicherheit für Outlook-Add-Ins.

Beachten Sie: Wenn ein IT-Administrator die Verwendung verbundener Erfahrungen in Office deaktiviert, hat dies die gleiche Auswirkung auf Add-Ins wie das Deaktivieren nur optionaler verbundener Erfahrungen.

Auseinandersetzen mit den Bedenken von Endbenutzern hinsichtlich des Datenschutzes

Dieser Abschnitt beschreibt den von der Office-Add-In-Plattform bereitgestellten Schutz aus der Sicht der Kunden (Endbenutzer) und enthält Richtlinien, wie diese Auffassung unterstützt werden kann und die personenbezogenen Informationen sicher verarbeitet werden können.

Sicht der Endbenutzer

Office-Add-Ins werden mithilfe von Webtechnologien entwickelt, die in einem Browsersteuerelement oder iframe ausgeführt werden. Das Verwenden von Add-Ins entspricht dem Durchsuchen von Websites im Internet oder Intranet. Add-Ins können außerhalb einer Organisation (wenn Sie das Add-In von AppSource erwerben) oder intern (wenn Sie das Add-In aus einem Exchange Server-Add-In-Katalog, sharePoint-App-Katalog oder einer Dateifreigabe im Netzwerk einer Organisation beziehen) sein. Vor diesem Hintergrund haben Add-Ins Zugriff auf das Netzwerk, und die meisten Add-Ins lesen oder schreiben Daten im aktiven Dokument oder E-Mail-Element. Die Add-In-Plattform aktiviert eine Reihe von Sicherheitsmaßnahmen, ehe ein Benutzer oder Administrator ein Add-In installiert oder startet. Doch wie bei jedem erweiterungsfähigen Modell müssen Benutzer vorsichtig sein, bevor sie ein unbekanntes Add-In starten.

Die Add-In-Plattform behandelt die Datenschutzbedenken von Endbenutzern auf folgende Weise.

• Daten, die mit einem Webserver ausgetauscht werden, der ein Inhalts-, Outlook- oder Aufgabenbereich-Add-in und die Kommunikation zwischen dem Add-in und einem Webdienst hostet, werden stets durch das SSL-Protokoll (Secure Socket Layer) geschützt.

• Bevor ein Benutzer ein Add-In aus AppSource installiert, kann er die Datenschutzrichtlinie und die Anforderungen dieses Add-Ins anzeigen. Darüber hinaus werden in Outlook-Add-Ins, die mit den Postfächern der Benutzer interagieren, die spezifischen Berechtigungen angezeigt, die sie benötigen. Der Benutzer kann die Nutzungsbedingungen, die angeforderten Berechtigungen und die Datenschutzrichtlinie überprüfen, bevor er ein Outlook-Add-In installiert.

• Beim Freigeben eines Dokuments können Benutzer auch Add-ins freigeben, die in das Dokument eingefügt oder damit verknüpft wurden. Wenn ein Benutzer ein Dokument öffnet, das ein Add-In enthält, das der Benutzer noch nicht verwendet hat, fordert die Office-Clientanwendung den Benutzer auf, dem Add-In die Berechtigung für die Ausführung im Dokument zu erteilen. In einer Organisationsumgebung fordert die Office-Clientanwendung den Benutzer außerdem auf, wenn das Dokument aus einer externen Quelle stammt.

• Add-Ins, die in den folgenden Office-Anwendungen ausgeführt werden, können nicht auf die Gerätefunktionen eines Benutzers zugreifen.

  • Office im Web (Excel, Outlook, PowerPoint und Word) wird in Chromium-basierten Browsern wie Microsoft Edge oder Google Chrome ausgeführt

  • neues Outlook unter Windows

  Zu den Gerätefunktionen eines Benutzers gehören kamera, geolocation und mikrofon. Weitere Informationen finden Sie unter Anzeigen, Verwalten und Installieren von Add-Ins für Excel, PowerPoint und Word.

• Benutzer können den Zugriff auf AppSource aktivieren oder deaktivieren. Für Inhalts- und Aufgabenbereich-Add-Ins verwalten Benutzer den Zugriff auf vertrauenswürdige Add-Ins und Kataloge über das Trust Center auf dem Office-Hostclient (geöffnet über Dateioptionen>>Trust CenterTrust Center> Einstellungen >Vertrauenswürdige Add-In-Kataloge).

  In Outlook hängt der Zugriff zum Verwalten von Add-Ins vom Outlook-Client des Benutzers ab. Weitere Informationen finden Sie unter Verwenden von Add-Ins in Outlook.

  Administratoren können den Zugriff auf AppSource auch über das Admin Center verwalten.

• Der Entwurf der Add-In-Plattform bietet Den Endbenutzern sicherheit und Leistung auf folgende Weise.

  • Ein Office-Add-In wird in einem Webbrowsersteuerelement ausgeführt, das in einer von der Office-Clientanwendung getrennten Add-In-Laufzeitumgebung gehostet wird. Dieser Entwurf bietet sowohl Sicherheits- als auch Leistungsisolation von der Clientanwendung.

  • Das Ausführen in einem Webbrowser-Steuerelement ermöglicht dem Add-in nahezu alle Vorgänge, die einer herkömmlichen in einem Browser ausgeführten Webseite möglich sind. Zugleich hält das Add-in dadurch die SOP-Richtlinie (Same Origin Policy) für Domänenisolierung und Sicherheitszonen ein.

Outlook-Add-Ins bieten durch eine Outlook-Add-In-spezifische Überwachung der Ressourcennutzung zusätzliche Sicherheits- und Leistungsfunktionen. Weitere Informationen finden Sie unter Privacy, permissions, and security for Outlook add-ins.

Richtlinien für Entwickler zum Umgang mit personenbezogenen Informationen

Im Folgenden finden Sie einige spezifische Richtlinien zum Schutz von PERSONENBEZOGENen Informationen für Sie als Entwickler von Office-Add-Ins.

• Auch wenn das Objekt Settings zum Beibehalten dokumentspezifischer Daten für ein Inhalts- oder Aufgabenbereich-Add-In bestimmt ist, sollten Sie im Objekt Settings keine personenbezogenen Informationen speichern. Die Daten im Objekt Settings sind für Endbenutzer nicht sichtbar, sondern Teil des Dateiformats des Dokuments, das frei zugänglich ist. Speichern Sie personenbezogene Informationen als geschützte Benutzerressource auf dem Server.

• Die Nutzung einiger Anwendungen kann zur Offenlegung von personenbezogenen Informationen führen. Stellen Sie sicher, dass Sie die Daten zu Benutzeridentität, Standort, Zugriffszeiten und anderen Anmeldeinformationen sicher speichern, damit die Daten nicht für andere Benutzer des Add-ins zugänglich sind.

• Wenn Ihr Add-In in AppSource erhältlich ist, sind personenbezogene Informationen, die zwischen Ihrem Webserver und dem Clientcomputer oder -gerät übertragen werden, durch die AppSource-Anforderung zur Verwendung von HTTPS geschützt. Falls Sie diese Daten jedoch an andere Server übertragen, sollten Sie sicherstellen, dass dabei der gleiche Schutz gilt.

• Wenn Sie personenbezogene Informationen von Benutzern speichern, sollten Sie dies offenlegen, damit Benutzer die Daten bei Bedarf prüfen und löschen können. Falls Sie Ihr Add-In über AppSource bereitstellen, können Sie in der Datenschutzerklärung angeben, welche Daten gesammelt und wie diese verwendet werden.

Berechtigungsoptionen und Sicherheitsmaßnahmen von Entwicklern

Sie können die folgenden allgemeinen Richtlinien zur Unterstützung des Sicherheitsmodells von Office-Add-Ins befolgen. Zudem stehen zu jedem Add-In-Typ weitere Detailinformationen zur Verfügung.

Anfordern der erforderlichen Berechtigungen

Die Add-In-Plattform stellt ein Berechtigungsmodell bereit, das Ihr Add-In verwendet, um die Zugriffsebene auf Benutzerdaten zu deklarieren, die für seine Funktionen erforderlich ist. Jede Berechtigungsstufe entspricht der Untergruppe der JavaScript-API für Office, die Ihr Add-In für die entsprechenden Funktionen verwenden darf. Beispielsweise ermöglicht die WriteDocument-Berechtigung für Inhalts- und Aufgabenbereich-Add-Ins den Zugriff auf die Document.setSelectedDataAsync-Methode , mit der ein Add-In in das Dokument des Benutzers schreiben kann, aber keinen Zugriff auf eine der Methoden zum Lesen von Daten aus dem Dokument zulässt. Diese Berechtigungsstufe ist sinnvoll für Add-Ins, die nur in ein Dokument schreiben müssen, wie z. B. ein Add-In, in dem der Benutzer Daten abfragen kann, die in sein Dokument eingefügt werden sollen.

Als bewährte Methode sollten Sie Berechtigungen nach dem Prinzip der geringsten Rechte anfordern. Das heißt, die angeforderten Berechtigungen sollten Zugriff auf lediglich die minimale Teilmenge der API gewähren, die Ihr Add-in für eine ordnungsgemäße Funktion benötigt. Wenn Ihr Add-In zum Funktionieren beispielsweise nur Daten im Dokument eines Benutzers lesen muss, sollten Sie keine Berechtigung anfordern, die über ReadDocument hinausgeht. (Bedenken Sie jedoch, dass das Anfordern von unzureichenden Berechtigungen dazu führt, dass die Add-In-Plattform die Verwendung einiger APIs durch Ihr Add-In blockiert und zur Laufzeit Fehler erzeugt.)

Sie geben Berechtigungen im Manifest Ihres Add-Ins an, wie im Beispiel in diesem Abschnitt unten gezeigt, und Endbenutzer können die angeforderte Berechtigungsstufe eines Add-Ins sehen, bevor sie sich entscheiden, das Add-In zum ersten Mal zu installieren oder zu aktivieren. Darüber hinaus benötigen Outlook-Add-Ins, die die ReadWriteMailbox-Berechtigung anfordern, explizite Administratorrechte für die Installation.

Das folgende Beispiel zeigt, wie ein Aufgabenbereich-Add-In die ReadDocument-Berechtigung im Manifest angibt. Der Schwerpunkt soll auf Berechtigungen liegen, daher werden andere Elemente im Manifest nicht angezeigt.

<?xml version="1.0" encoding="utf-8"?>
<OfficeApp xmlns="http://schemas.microsoft.com/office/appforoffice/1.0"
           xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
           xmlns:ver="http://schemas.microsoft.com/office/appforoffice/1.0"
           xsi:type="TaskPaneApp">

... <!-- To keep permissions as the focus, not displaying other elements. -->
  <Permissions>ReadDocument</Permissions>
...
</OfficeApp>

Weitere Informationen zu Berechtigungen für Aufgabenbereich- und Inhalts-Add-Ins finden Sie unter Anfordern von Berechtigungen für API-Verwendung in Add-Ins.

Weitere Informationen zu Berechtigungen für Outlook-Add-Ins finden Sie in den folgenden Themen.

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

• Grundlegendes zu Berechtigungen bei Outlook-Add-Ins

Befolgen Sie die Richtlinie für denselben Ursprung.

Da Es sich bei Office-Add-Ins um Webseiten handelt, die in einem Webbrowsersteuerelement ausgeführt werden, müssen sie der vom Browser erzwungenen Richtlinie für denselben Ursprung folgen. Standardmäßig kann eine Webseite in einer Domäne keine XmlHttpRequest-Webdienstaufrufe an eine andere Domäne als die, in der sie gehostet wird, durchführen.

Eine Möglichkeit, diese Einschränkung zu umgehen, besteht darin, JSON/P zu verwenden. Stellen Sie einen Proxy für den Webdienst bereit, indem Sie ein Skripttag mit einem src-Attribut hinzufügen, das auf ein Skript verweist, das in einer anderen Domäne gehostet wird. Sie können die Skripttags programmgesteuert erstellen, dynamisch die URL erstellen, auf die das src-Attribut verweist, und Parameter über URI-Abfrageparameter an die URL übergeben. Webdienstanbieter erstellen und hosten JavaScript-Code an spezifischen URLs und geben je nach URI-Abfrageparametern unterschiedliche Skripts zurück. Diese Skripts werden anschließend an der Stelle ausgeführt, an der sie eingefügt wurden, und funktionieren wie erwartet.

Es folgt ein Beispiel von JSON/P imOutlook-Add-In-Beispiel.

// Dynamically create an HTML SCRIPT element that obtains the details for the specified video.
function loadVideoDetails(videoIndex) {
    // Dynamically create a new HTML SCRIPT element in the webpage.
    const script = document.createElement("script");
    // Specify the URL to retrieve the indicated video from a feed of a current list of videos,
    // as the value of the src attribute of the SCRIPT element. 
    script.setAttribute("src", "https://gdata.youtube.com/feeds/api/videos/" + 
        videos[videoIndex].Id + "?alt=json-in-script&callback=videoDetailsLoaded");
    // Insert the SCRIPT element at the end of the HEAD section.
    document.getElementsByTagName('head')[0].appendChild(script);
}

Exchange und SharePoint bieten clientseitige Proxys zum Ermöglichen des domänenübergreifenden Zugriffs. In der Regel ist die SOP-Richtlinie in einem Intranet nicht so streng wie im Internet. Weitere Informationen finden Sie unter SOP-Richtlinie Teil 1: kein Einsehen und Addressing same-origin policy limitations in Office Add-ins.

Verhindern von böswilligen websiteübergreifenden Skripts

Ein böswilliger Akteur könnte den Ursprung eines Add-Ins angreifen, indem er schädliche Skripts über das Dokument oder felder im Add-In eingibt. Entwickler sollten Benutzereingaben entsprechend verarbeiten, um die Ausführung schädlicher JavaScript-Elemente in ihrer Domäne zu verhindern. Im Folgenden sind einige bewährte Methoden aufgeführt, um Benutzereingaben aus einem Dokument oder einer E-Mail-Nachricht oder über Felder in einem Add-In zu verarbeiten.

• Verwenden Sie, wo möglich, anstatt der DOM-Eigenschaft innerHTML die innerText- und die textContent-Eigenschaft. Gehen Sie für browserübergreifende Unterstützung von Internet Explorer und Firefox wie folgt vor.

   var text = x.innerText || x.textContent
  

  Informationen zu den Unterschieden zwischen innerText und textContent finden Sie unter Node.textContent. Weitere Informationen zur DOM-Kompatibilität auf gängigen Browsern finden Sie unter W3C-DOM-Kompatibilität – HTML.

• Wenn Sie innerHTML verwenden müssen, stellen Sie sicher, dass die Eingabe des Benutzers keine schädlichen Inhalte enthält, bevor Sie sie an innerHTML übergeben. Weitere Informationen und ein Beispiel für die sichere Verwendung von innerHTML finden Sie unter innerHTML-Eigenschaft .

• Wenn Sie jQuery verwenden, verwenden Sie die Methode .text() statt der Methode .html().

• Verwenden Sie die toStaticHTML-Methode zum Entfernen jeglicher dynamischer HTML-Elemente und -Attribute in den Benutzereingaben, bevor Sie sie an innerHTML weitergeben.

• Verwenden Sie die encodeURIComponent- oder die encodeURI-Funktion zum Codieren von Text, der eine URL sein soll, die von Benutzereingaben stammt oder solche enthält.

• Weitere bewährte Methoden zum Erstellen sicherer Weblösungen finden Sie unter Entwickeln sicherer Add-Ins.

"Clickjacking" verhindern

Da Office-Add-Ins in einem iframe gerendert werden, wenn sie in einem Browser mit Office-Clientanwendungen ausgeführt werden, verwenden Sie die folgenden Tipps, um das Risiko von Clickjacking zu minimieren– eine Technik, die von Hackern verwendet wird, um Benutzer dazu zu bringen, vertrauliche Informationen offenzulegen.

Ermitteln Sie zuerst sicherheitsrelevante Aktionen, die Ihr Add-in ausführen kann. Dazu zählen Aktionen, die ein nicht autorisierter Benutzer mit böswilliger Absicht verwenden könnte, etwa das Initiieren einer finanziellen Transaktion oder das Veröffentlichen vertraulicher Daten. So kann Ihr Add-in dem Benutzer z. B. erlauben, an einen vom Benutzer definierten Empfänger eine Zahlung zu senden.

Zweitens sollte Ihr Add-in sicherheitsrelevante Aktionen vom Benutzer bestätigen lassen, bevor die Aktionen ausgeführt werden. Diese Bestätigung sollte die Auswirkung der Aktion angeben. Außerdem sollte sie angeben, wie der Benutzer die Aktion, falls erforderlich, verhindern kann, was durch Auswahl einer Schaltfläche mit „Nicht zulassen“ oder durch Ignorieren der Bestätigung erfolgen kann.

Drittens: Um sicherzustellen, dass kein Bedrohungsakteur die Bestätigung ausblenden oder maskieren kann, sollten Sie sie außerhalb des Kontexts des Add-Ins (also nicht in einem HTML-Dialogfeld) anzeigen.

Im Folgenden finden Sie einige Beispiele dafür, wie Sie eine Bestätigung erhalten können.

• Senden Sie an den Benutzer eine E-Mail mit einem Link zur Bestätigung.

• Senden Sie an den Benutzer eine SMS mit einem Bestätigungscode, den er in das Add-In eingeben kann.

• Öffnen Sie in einem neuen Browserfenster ein Bestätigungsdialogfeld für die Weiterleitung auf eine Seite, die nicht in einem iFrame geöffnet werden kann. Das ist das Muster, das für die meisten Anmeldeseiten verwendet wird. Verwenden Sie die Dialog-API , um einen neuen Dialog zu erstellen.

Stellen Sie außerdem sicher, dass die Adresse, die Sie für die Kontaktaufnahme mit dem Benutzer verwenden, nicht von einem Bedrohungsakteur hätte angegeben werden können. Verwenden Sie z. B. für Zahlungsbestätigungen die für das Konto des autorisierten Benutzers hinterlegte Adresse.

Anfordern der Berechtigung für den Zugriff auf Gerätefunktionen (gilt für Office im Web und neues Outlook unter Windows)

Wenn ein Add-In Zugriff auf die Gerätefunktionen eines Benutzers benötigt, z. B. die Kamera, geolocation oder das Mikrofon, muss der Entwickler es so konfigurieren, dass die Berechtigung des Benutzers angefordert wird. Dies gilt für die folgenden Office-Anwendungen.

• Office im Web (Excel, Outlook, PowerPoint und Word) wird in Chromium-basierten Browsern wie Microsoft Edge oder Google Chrome ausgeführt
• neues Outlook unter Windows

Um die Berechtigung anzufordern, muss das Add-In die Geräteberechtigungs-API implementieren.

Informationen dazu, wie der Benutzer zur Berechtigung aufgefordert wird, finden Sie unter Anzeigen, Verwalten und Installieren von Add-Ins für Excel, PowerPoint und Word.

Andere Sicherheitsmaßnahmen

Entwickler sollten auch die folgenden Sicherheitsmethoden beachten.

• Entwickler dürfen in Office-Add-Ins keine ActiveX-Steuerelemente verwenden, da ActiveX-Steuerelemente nicht die plattformübergreifende Architektur der Add-In-Plattform unterstützen.

• Inhalts- und Aufgabenbereich-Add-Ins setzen die gleichen SSL-Einstellungen voraus, die der Browser standardmäßig verwendet, und ermöglichen die Übermittlung der meisten Inhalte nur über SSL. Outlook-Add-Ins erfordern, dass alle Inhalte per SSL übermittelt werden. Entwickler müssen im <SourceLocation-Element> des Add-In-Manifests eine URL angeben, die HTTPS verwendet, um den Speicherort der HTML-Datei für das Add-In zu identifizieren.

  Um sicherzustellen, dass Add-Ins keine Inhalte mithilfe von HTTP bereitstellen, sollten Entwickler beim Testen von Add-Ins sicherstellen, dass die folgenden Einstellungen unter Internetoptionen in der Systemsteuerung ausgewählt sind und in ihren Testszenarien keine Sicherheitswarnungen angezeigt werden.

  • Legen Sie die Einstellung Gemischte Inhalte anzeigen für die Zone Internet auf Bestätigen fest. Wählen Sie dazu unter Internetoptionen Folgendes aus: Wählen Sie auf der Registerkarte Sicherheit die Internetzone aus, wählen Sie Benutzerdefinierte Ebene aus, scrollen Sie, um nach Gemischten Inhalt anzeigen zu suchen, und wählen Sie Eingabeaufforderung aus, wenn sie noch nicht ausgewählt ist.

  • Aktivieren Sie außerdem im Dialogfeld Internetoptionen auf der Registerkarte Erweitert die Option Beim Wechsel zwischen sicherem und nicht sicherem Modus warnen.

• Um sicherzustellen, dass Add-ins auf einem Clientcomputer nicht zu viel CPU- oder Arbeitsspeicherressourcen belegen, was zu einem Dienstausfall führen könnte, gelten für die Add-in-Plattform Grenzwerte für die Ressourcenbelegung. Im Rahmen von Tests müssen Entwickler prüfen, ob ein Add-in mit den Grenzwerten für die Ressourcenbelegung zurechtkommt.

• Vor der Veröffentlichung eines Add-ins müssen Entwickler sicherstellen, dass persönlich identifizierbare Informationen, die sie in ihren Add-in-Dateien offenlegen, sicher sind.

• Entwickler sollten Schlüssel, die sie für den Zugriff auf APIs oder Dienste von Microsoft und anderen Benutzern (z. B. Bing, Google oder Facebook) verwenden, nicht direkt in die HTML-Seiten ihres Add-Ins einbetten. Stattdessen sollten sie einen benutzerdefinierten Webdienst erstellen oder die Schlüssel beispielsweise in einem sicheren Webspeicher speichern, den sie dann zum Weitergeben des Schlüssels an das Add-in aufrufen können.

• Entwickler sollten folgendes tun, wenn sie ein Add-In an AppSource übermitteln.

  • Hosten des eingereichten Add-Ins auf einem Webserver, der SSL unterstützt
  • Eine Erklärung mit einer Beschreibung einer bindenden Datenschutzrichtlinie erstellen.
  • Vorbereitung auf die Unterzeichnung einer vertraglichen Vereinbarung beim Einreichen des Add-ins

Zusätzlich zu den Ressourcennutzungsregeln sollten Entwickler von Outlook-Add-Ins dafür sorgen, dass ihre Add-Ins Grenzwerte für das Angeben von Aktivierungsregeln und Verwenden der JavaScript-API einhalten. Weitere Informationen finden Sie unter Limits for activation and JavaScript API for Outlook add-ins.

Kontrolle durch IT-Administratoren

In einer Unternehmensumgebung haben IT-Administrator letztlich die Kontrolle über die Aktivierung bzw. Deaktivierung des Zugriffs auf AppSource und private Kataloge.

Die Verwaltung und Durchsetzung der Office-Einstellungen erfolgt über Gruppenrichtlinieneinstellungen. Diese sind über das Office-Bereitstellungstool in Verbindung mit dem Office-Anpassungstool konfigurierbar.

Siehe auch

• Anfordern von Berechtigungen für API-Verwendung in Add-Ins
• Datenschutz, Berechtigungen und Sicherheit für Outlook-Add-Ins
• Grundlegendes zu Berechtigungen bei Outlook-Add-Ins
• Einschränkungen für die Aktivierung und die JavaScript-API für Outlook-Add-Ins
• Behandeln von Richtlinieneinschränkungen aufgrund desselben Ursprungs in Office-Add-Ins
• SOP-Richtlinie
• SOP-Richtlinie Teil 1: Kein Einsehen
• SOP-Richtlinie für JavaScript
• IE-Schutzmodus
• Datenschutzsteuerung für Microsoft 365 Apps