Datenschutz und Sicherheit bei Office-Add-Ins

Artikel
10/10/2023

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.

Hinweis

In einigen Szenarien werden verschiedene Features eines Add-Ins in separaten Runtimes ausgeführt. Der Einfachheit halber verwendet dieser Artikel die singulare "Runtime". Weitere Informationen finden Sie unter Runtimes in Office-Add-Ins.

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 Tablet-Geräte wie Excel unter Windows und Outlook unter Windows 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 im 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.

Diagramm der Laufzeitumgebung für Office-Add-Ins auf Windows-Desktop- und Tablet-Clients.

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

Diagramm der Office-Add-Ins-Laufzeitumgebung auf macOS-Desktopclients.

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.

Diagramm der Infrastruktur, die Office-Add-Ins in Office im Web Clients unterstützt.

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 eines organization ü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 extern zu einem organization (wenn Sie das Add-In von AppSource beziehen) oder intern (wenn Sie das Add-In aus einem Exchange Server Add-In-Katalog, SharePoint-App-Katalog oder Dateifreigabe im Netzwerk eines organization abrufen). 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.

Hinweis

Benutzern wird möglicherweise eine Sicherheitsaufforderung angezeigt, um der Domäne beim ersten Laden eines Add-Ins zu vertrauen. Dies geschieht, wenn sich der Domänenhost des Add-Ins außerhalb der Domäne von Exchange lokal oder Office Online Server befindet.

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.
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.

Berechtigungsoptionen

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.

SOP-Richtlinie (Same Origin Policy)

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&amp;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.

Tipps zum Verhindern von bösartigem websiteübergreifendem Skripting

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 zur browserübergreifenden 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.

Tipps zur Verhinderung von „Clickjacking“

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 Dialogfeld-API, um ein neues Dialogfeld 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.

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 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.

Name der Einstellung	Beschreibung
Unsichere Web-Add-Ins und Kataloge zulassen	Ermöglicht Benutzern das Ausführen nicht sicherer Office-Add-Ins, bei denen es sich um Office-Add-Ins handelt, die Webseiten- oder Katalogspeicherorte aufweisen, die nicht sslgesichert (https://) sind und sich nicht in den Internetzonen der Benutzer befinden.
Web-Add-Ins blockieren	Ermöglicht es Ihnen, zu verhindern, dass Benutzer Office-Add-Ins ausführen, die Webtechnologien verwenden.
Office Store blockieren	Ermöglicht es Ihnen, zu verhindern, dass Benutzer Office-Add-Ins aus AppSource abrufen oder ausführen.