Kann ein Add-in den Inhalt meiner E-Mails lesen?

Die Berechtigungen eines Add-ins sind in seinem Manifest deklariert und werden bei der Administratorzustimmung angezeigt. Ein Signatur-Add-in fordert Schreibzugriff auf die Nachricht im Entwurf und Lesezugriff auf Verzeichnisattribute an, nicht das Lesen des Postfachs.

Wie prüfe ich, was ein Add-in tatsächlich anfordert?

Der Zustimmungsbildschirm Ihres Identitätsanbieters listet die angeforderten Berechtigungen vor der Freigabe auf. Das ist der direkteste Nachweis des Umfangs: Er stammt von Microsoft oder Google, nicht vom Anbieter.

Laufen meine E-Mails über die Server des Anbieters?

Bei einem Add-in nicht: Die Nachricht geht von Ihrem Tenant direkt an den Empfänger, ohne einen Dritten zu passieren. Bei einem SMTP-Relay schon – und genau diesen Punkt sollten Sie in einer Sicherheitsprüfung zuerst untersuchen.

Was passiert, wenn das Tool kompromittiert wird?

Der Risikoumfang entspricht den gespeicherten Daten. Bei einem Add-in umfasst das das synchronisierte Verzeichnis und die Vorlagen, nicht den Inhalt der Nachrichten, der nie zugänglich war.

Kann ein Signatur-Tool Ihre E-Mails lesen? Die technische Antwort

Je nach Architektur greift ein Signatur-Tool auf den Inhalt Ihrer Nachrichten zu oder nicht. Der Unterschied zwischen clientseitigem Add-in, Transportregel und SMTP-Relay – erklärt für eine Sicherheitsprüfung.

Das ist die erste Frage jeder Sicherheitsprüfung, und sie ist berechtigt: Hat ein Tool, das in Ihre E-Mails eingreift, Zugriff auf deren Inhalt? Die Antwort hängt vollständig von der gewählten Architektur ab – und die drei Architekturen am Markt haben nicht denselben Umfang.

Architektur 1 – Das clientseitige Add-in

Das Add-in läuft im E-Mail-Client, während der Nutzer seine Nachricht verfasst. Es fügt einen HTML-Block in den Text der geöffneten Nachricht ein.

Der Zugriffsumfang entspricht den im Manifest des Add-ins deklarierten Berechtigungen: Schreiben in das Element, das gerade verfasst wird, und Lesen der Verzeichnisattribute, die zum Befüllen der Felder nötig sind.

Daraus ergeben sich zwei Eigenschaften, auf die es in einer Sicherheitsprüfung ankommt:

Die Nachricht läuft nicht über den Anbieter. Das Einfügen geschieht auf dem Gerät, im Verfassen-Fenster. Die Nachricht geht danach über Ihr übliches Routing von Ihrem Microsoft- oder Google-Tenant an den Empfänger, ohne Umweg.

Das Postfach wird nicht gelesen. Das Add-in wirkt auf eine Nachricht im Entwurf, nicht auf den Posteingang, den Verlauf oder die Archive.

Das ist die Architektur von Signally, beschrieben auf der Seite Microsoft-365-Add-in.

Architektur 2 – Die Transportregel

Die Signatur wird von Ihrem eigenen Mailserver – Exchange Online oder dem Compliance-Dienst von Google Workspace – bei der Zustellung angehängt.

Hier ist der Anbieter überhaupt nicht an der Verarbeitung der Nachricht beteiligt: Er liefert den Inhalt der Fußzeile, Ihr Server wendet ihn an. Kein Zugriff, keine Durchleitung.

Im Gegenzug hat diese Architektur erhebliche funktionale Grenzen – der Absender sieht seine Signatur nie, in Verläufen stapeln sich die Blöcke, verschlüsselte Nachrichten entgehen ihr –, beschrieben unter Add-in oder Transportregel.

Architektur 3 – Das SMTP-Relay

Diese Architektur verdient eine genaue Prüfung. Die Nachricht verlässt Ihren Server, läuft über die Infrastruktur des Anbieters, der die Signatur ergänzt, und geht dann weiter an den Empfänger.

Konstruktionsbedingt bedeutet das, dass der vollständige Inhalt Ihrer Nachrichten über einen Dritten läuft – Text, Anhänge, Empfänger. Außerdem erfordert sie eine Änderung Ihres ausgehenden Routings, mit entsprechenden Folgen für die Zustellbarkeit und Ihre SPF- und DKIM-Konfiguration.

An sich ist sie nicht illegitim, und manche Anbieter setzen sie seriös um. Aber sie verändert die Frage an Ihren Informationssicherheitsbeauftragten: Es geht nicht mehr darum, eine Komponente freizugeben, sondern darum, einen Dritten in Ihre Zustellkette einzufügen.

Prüfen statt glauben

Drei konkrete Prüfungen, die nicht auf dem Wort des Anbieters beruhen.

Der Zustimmungsbildschirm. Beim Verbinden des Tenants zeigt Ihr Identitätsanbieter – Microsoft Entra ID oder Google – die genaue Liste der angeforderten Berechtigungen. Diese Liste kommt von Microsoft oder Google, nicht vom Anbieter. Sie ist der direkteste Nachweis des Umfangs.

Die API-Dokumentation. Die angeforderten Berechtigungen entsprechen Scopes, die Microsoft und Google öffentlich dokumentieren. Sie können nachprüfen, was jeder davon umfasst.

Die Routing-Konfiguration. Verlangt die Installation Änderungen an Ihren Connectors, MX-Einträgen oder Ihrem SPF, handelt es sich um eine Relay-Architektur. Bleibt das Routing unberührt, nicht.

Gut zu wissen: Lassen Sie den Zustimmungsbildschirm bei der Installation per Screenshot festhalten und legen Sie ihn der Sicherheitsdokumentation bei. Das ist ein datiertes Beweisstück – mehr wert als eine Zusage des Vertriebs.

Der Umfang des Restrisikos

Kein Tool hat ein Nullrisiko, und es ist ehrlicher, das Risiko abzugrenzen, als es zu leugnen.

Bei einem Add-in erhielte ein Angreifer im Fall einer Kompromittierung des Anbieters die gespeicherten Daten: das synchronisierte Verzeichnis – Namen, Funktionen, geschäftliche Telefonnummern – und die Vorlagen. Nicht den Inhalt der Nachrichten, der nie zugänglich war.

Das ist ein Unterschied der Art, nicht des Grades. Ein abgeflossenes Firmenverzeichnis ist ein ernster Vorfall; der E-Mail-Verlauf einer ganzen Organisation ist ein anderer.

Standort und Rechtsordnung dieser gespeicherten Daten sind der zweite Teil der Prüfung, behandelt im Artikel Datensouveränität bei SaaS.

Die Zusammenfassung für Ihren Informationssicherheitsbeauftragten

Für die Add-in-Architektur genügen vier Zeilen:

Die Signatur wird beim Verfassen clientseitig in die geöffnete Nachricht eingefügt.
Kein E-Mail-Inhalt wird gelesen, analysiert oder gespeichert, und nichts läuft über den Anbieter.
Synchronisiert werden nur die Verzeichnisattribute, die in der Signatur angezeigt werden.
Keine Änderung am ausgehenden Routing: kein Connector, kein Relay, keine SPF-Änderung.

Diese Punkte und die Details dazu, was Signally nicht tut, finden Sie auf unserer Seite Sicherheit und DSGVO, die so gestaltet ist, dass Sie sie unverändert an Ihre IT-Abteilung weitergeben können.