Sichere E-Mail-API

Die Einhaltung des HIPAA für eine E-Mail-API-Integration ist machbar, erfordert aber eine sorgfältige Architektur. HIPAA zertifiziert keine E-Mail-Anbieter, sondern verlangt, dass jedes System, das geschützte Gesundheitsinformationen (Protected Health Information - PHI) verarbeitet, bestimmte technische Schutzmaßnahmen implementiert: Verschlüsselung bei der Übertragung und im Ruhezustand, Audit-Kontrollen, Zugriffskontrollen und automatische Abmeldung bei inaktiven Sitzungen. Für eine E-Mail-API bedeutet dies: Verwendung von OAuth 2.0, so dass keine Kennwörter gespeichert werden, Sicherstellung, dass Token und alle zwischengespeicherten Metadaten im Ruhezustand verschlüsselt werden, keine Protokollierung von E-Mail-Inhalten, die PHI enthalten könnten, und Abschluss eines Business Associate Agreement (BAA) mit Ihrem API-Anbieter. Sowohl Google Mail als auch Outlook bieten im Rahmen von Google Workspace bzw. Microsoft 365 Business Konfigurationen an, die für den HIPAA in Frage kommen, und zwar mit einem vom Anbieter unterzeichneten BAA. Ihre E-Mail-API-Ebene muss ebenfalls ein BAA mit Ihnen unterzeichnen, wenn sie PHI in Ihrem Namen verarbeitet oder überträgt. Aus praktischer Sicht besteht der sicherste HIPAA-Weg darin, E-Mail-Inhalte als flüchtig zu behandeln - lesen Sie sie, verarbeiten Sie sie, zeigen Sie sie an - aber bewahren Sie niemals den Textkörper oder Anhänge in Ihrer eigenen Datenbank auf.

Der Entzug des E-Mail-Zugriffs eines Benutzers erfordert zwei separate Aktionen, die beide durchgeführt werden müssen. Zuerst den Token auf Anbieter-Ebene widerrufen. Für Gmail rufen Sie den Token-Widerruf-Endpunkt von Google auf (https://oauth2.googleapis.com/revokeFür Outlook rufen Sie den Widerrufsendpunkt von Microsoft auf oder entfernen die App aus dem Microsoft-Konto des Benutzers. Es reicht nicht aus, das Token einfach aus Ihrer Datenbank zu löschen – das Token bleibt beim Anbieter gültig, bis es explizit widerrufen wurde. Zweitens, löschen Sie alle lokalen Daten. Löschen Sie den Refresh-Token, alle zwischengespeicherten Zugriffstoken, alle E-Mail-Metadaten, die Sie für dieses verknüpfte Konto gespeichert haben, Webhook-Abonnements und den verknüpften Konto-Datensatz selbst. Mit Unipile, einem einzigen LÖSCHEN /konten/{id} Der Aufruf führt beide Schritte aus – er widerruft den Token beim Anbieter und löscht gleichzeitig alle zugehörigen Daten in der Unipile-Infrastruktur.

E-Mail-Sicherheit bezieht sich typischerweise auf den Schutz der E-Mail-Kommunikation selbst – Spamfilterung, Phishing-Erkennung, DKIM/SPF/DMARC-Authentifizierung und Verschlüsselung der Nachricht während der Übertragung zwischen Mailservern. E-Mail-API-Sicherheit ist eine völlig andere Ebene: Es geht darum, wie eine Drittanbieteranwendung programmatischen Zugriff auf das Postfach eines Benutzers erhält, welche Daten sie dabei verarbeitet und wie sie diesen Zugriff schützt. Sie können eine ausgezeichnete E-Mail-Sicherheit haben (DMARC konfiguriert, TLS zwischen Servern erzwungen) und gleichzeitig eine schlechte E-Mail-API-Sicherheit (Passwörter im Klartext gespeichert, zu breite OAuth-Bereiche). Beides ist unabhängig voneinander wichtig. Dieser Artikel konzentriert sich auf die API-Sicherheitsebene – die architektonischen Entscheidungen, die Ihr Entwicklungsteam bei der Integration mit Gmail, Outlook oder IMAP über eine API trifft.

Unipile speichert E-Mail-Inhalte nicht persistent. Wenn Ihre Anwendung die Unipile-API aufruft, um E-Mails abzurufen, ruft Unipile die Daten in Echtzeit vom Anbieter (Gmail, Outlook oder IMAP-Server) ab und gibt sie an Ihre Anwendung zurück. E-Mail-Texte und Anhänge werden auf der Infrastruktur von Unipile über den Anforderungslebenszyklus hinaus nicht zwischengespeichert oder gespeichert. Was Unipile speichert, sind das OAuth-Token (verschlüsselt im Ruhezustand) und grundlegende verknüpfte Kontometadaten, die zur Aufrechterhaltung der Verbindung erforderlich sind – Anbietertyp, Kontokennung und Verbindungsstatus. Diese Architektur bedeutet, dass der E-Mail-Inhalt zwischen Ihrer Anwendung und dem Anbieter verbleibt, wobei Unipile als sicherer Broker und nicht als Datenspeicher fungiert. Ausführliche Informationen zur Datenverarbeitung durch Unipile finden Sie unter Entwicklerdokumentation und bitten das Unipile-Team um eine Auftragsverarbeitungsvereinbarung.

OAuth 2.0 verbessert die Sicherheit der E-Mail-Integration auf vier konkrete Arten. Keine Offenlegung von Anmeldeinformationen: das Passwort des Benutzers verlässt nie den Server des Anbieters – Ihre Anwendung erhält immer nur ein kurzlebiges Zugriffstoken. Granulare Berechtigungen OAuth-Berechtigungsbereiche ermöglichen es Ihnen, genau den Zugriff anzufordern, den Sie benötigen (nur Lesen, nur Senden), anstatt die vollständige Kontrolle über das E-Mail-Postfach. Widerruflichkeit Ein Nutzer kann den Zugriff Ihrer Anwendung von seinen Google- oder Microsoft-Konto-Einstellungen jederzeit widerrufen, ohne sein Passwort zu ändern, und das Token wird sofort ungültig. Kurzlebige Token Zugriffstoken verfallen (typischerweise nach einer Stunde), was das Zeitfenster für eine potenzielle Gefährdung begrenzt, falls ein Token jemals kompromittiert wird. Diese Eigenschaften machen OAuth 2.0 zum einzig akzeptablen Authentifizierungsmechanismus für Gmail- und Outlook-Integrationen in produktiven SaaS-Anwendungen. Erfahren Sie, wie Sie es für Google OAuth 2.0 und Microsoft OAuth 2.0.