Von allen Datenbanken, die snapADDY zum produktiven Betrieb seiner Produkte verwendet, werden täglich automatisch Backups via RDS Snapshots erstellt. Zudem werden regelmäßig Snapshots der Transaktionslogs erstellt, wodurch wir unsere Datenbanken auf einen bestimmten Zeitpunkt (wenige Minuten vor einem etwaigen Absturz) wiederherstellen können. Die RDS Snapshots und Transaktionslogs werden in Amazon S3 gespeichert und 30 Tage aufbewahrt.

Bei den von snapADDY verwendete S3 Buckets ist eine Objekt-Versionierung aktiviert. Alte Versionen und gelöschte Objekte können damit innerhalb eines Zeitraums von 30 Tagen wiederhergestellt werden.

Gelöschte Daten werden zuerst zur Löschung markiert und nach 30 Tagen endgültig gelöscht. Innerhalb dieses Zeitraums können unsere Support-Mitarbeiter versehentlich gelöschte Daten wiederherstellen.

Alle Anfragen an und zwischen unseren Servern sind mit Transportverschlüsselung geschützt. Durch HSTS und die Weiterleitung von HTTP auf HTTPS wird die Verschlüsselung von externem Traffic sichergestellt. Unsere Server unterstützen TLS 1.2 und 1.3 mit starken Cipher-Suites. Bei internen Verbindungen zwischen unseren Servern wird mTLS 1.3 verwendet. Mit diesen Maßnahmen erreichen wir eine A+ Bewertung beim SSL Server Test von SSL Labs (https://www.ssllabs.com/ssltest/analyze.html?d=app.snapaddy.com).

Alle Datenbanken und S3 Buckets mit Kundendaten sind mit AES-256 verschlüsselt. Die Verschlüsselungsschlüssel der Datenbanken werden mit Masterschlüsseln verschlüsselt, die von AWS im Key Management Service (KMS) verwaltet werden. Die KMS-Masterschlüssel sind auf Hardware-Sicherheitsmodulen (HSMs), validiert mit FIPS-140-2 Level 2 (Level 3 in einigen Kategorien), gespeichert. Weitere Details finden Sie in ISMS (Kapitel 3.2).

Zur Authentifizierung bei snapADDY stehen Ihnen verschiedene Möglichkeiten zur Verfügung. Einerseits können Sie einen klassischen Login via Usernamen und Passwort nutzen, welcher optional mittels 2-Faktor-Authenfizierung geschützt werden kann. Andererseits bieten wir unseren Kunden einen Single-Sign-On entweder über OAuth (OpenID-Connect; für die drei Identity Provider Microsoft, Google und Apple) oder eine SAML-Integration mit dem Identify Provider Ihrer Wahl an. Weitere Informationen zur Einrichtung von SAML finden Sie unter: How to set up SAML 2.0 Single Sign-On

Administratoren einer snapADDY-Organisation können Ihren Benutzern Rollen zuweisen, auf deren Grundlage Benutzerrechte definiert sind. Diese Rolle schränken den Zugriff auf bestimmte Ressourcen ein und können granular vergeben werden.

Eine Übersicht über die verfügbaren Rollen finden Sie hier:

https://help.snapaddy.com/en/articles/2547674-what-do-the-user-roles-reporter-user-template-curator-template-manager-and-admin-mean

Um die Funktion der E-Mail-Kontaktvorschläge nutzen zu können, muss eine Verbindung zwischen snapADDY und Ihrem E-Mail-Postfach hergestellt werden. Hierbei stehen Ihnen zwei Verbindungsarten zur Verfügung. Entweder Sie stellen die Verbindung mittels einer snapADDY-OAuth-Applikation zu einem Microsoft-Postfach her oder Sie nutzen eine klassische Verbindung via IMAP. Da sich diese beiden Verbindungsarten technisch voneinander unterscheiden, werden die jeweiligen Sicherheitsaspekte im Folgenden separat betrachtet.

Verbindung via snapADDY-OAuth-Applikation

Zur Verbindung Ihres Microsoft-E-Mail-Postfaches müssen Sie der snapADDY Suggestions OAuth-Applikation Zugriff auf die Berechtigungen Mail.Read, User.Read und offline_access erteilen. Gegebenenfalls muss dieser Zugriff durch den Azure-Administrator Ihrer Organisation bestätigt werden. Anschließend registriert snapADDY in Ihrem Namen eine Subscription über die Microsoft Graph API, welche snapADDY per Webhook informiert, sobald eine neue E-Mail zur Verarbeitung in Ihrem Postfach eintrifft. Wenn snapADDY eine solche Benachrichtigung erhält, rufen wir die E-Mail aus Ihrem Postfach ab und extrahieren mögliche Signaturen. Der Inhalt der E-Mail wird von uns dabei zu keiner Zeit gespeichert oder geloggt. Alle Daten liegen grundsätzlich nur flüchtig und nur im Moment der Verarbeitung (parsing) vor.

Verbindung via IMAP

Die Verbindung via IMAP erfolgt mit Hilfe der regulären Zugangsdaten zu Ihrem IMAP-Postfach. Das Passwort wird dabei, zusätzlich zu unserer generellen Verschlüsselung der Datenbank, mit Hilfe eines 256bit AES-CBC Secrets mit einem randomisierten Vektor initialisiert. Der Verschlüsselungs-Schlüssel wird mittels PBKD2 von einem internen Secret und einem randomisierten Salt abgeleitet. Das gespeicherte Passwort ist durch einen Nutzer nicht mehr abrufbar und wird lediglich für die serverseitige Verbindung zu Ihrem Postfach benötigt. Falls Sie die Möglichkeit haben, sogenannte App-Passwörter zu verwenden, welche ein separates Passwort für Drittanbieter-Integrationen Ihres IMAP-Postfachs zulässt, empfehlen wir Ihnen, diesen Weg zu wählen. Siehe hierzu beispielsweise: https://support.google.com/mail/answer/185833?hl=de

Für beide Fälle gilt, dass niemals der Inhalt Ihrer E-Mails gespeichert oder geloggt wird. Die E-Mails liegen lediglich für den Moment der Verarbeitung im Arbeitsspeicher vor und werden anschließend von unserer Seite verworfen. Zusätzlich können E-Mails mit bestimmten Absender-Domains komplett von der Verarbeitung durch dieses Features ausgeschlossen werden.

Außerdem werden Kontaktvorschläge, die auf eingehenden E-Mails basieren, ausschließlich in der vom Nutzer selbst gewählte snapADDY-Kontaktliste hinterlegt. Jeder Nutzer kann eigenständig festlegen, wer Zugriff auf diese Liste hat.

Warum sollte ich meinen (ausgehenden) E-Mail-Server verbinden?

Einige Funktionen von snapADDY VisitReport benötigen für den Versand von E-Mails einen von Ihnen hinterlegten, ausgehenden E-Mail-Server. Dazu zählt der automatische Versand von sogenannten „Notification-E-Mails“ beim Export von Besuchsberichten aus der VisitReport-App sowie der Versand von Dankes-Mails an die erfassten Gesprächspartner.

Wie kann ich die Verbindung herstellen?

Wir empfehlen für den Versand von E-Mails über snapADDY einen eigenen SMTP-Benutzer (im Folgenden: „technischer Nutzer“) einzurichten. Dieser technische Nutzer sollte mit einem sicheren Passwort versehen werden, das an keiner anderen Stelle verwendet wird und damit wie ein API-Token behandelt werden kann.

Je nach Funktionsumfang Ihres E-Mail-Servers können die Berechtigungen des technischen Nutzers auch erheblich eingeschränkt werden (z.B. im Fall von Notification-E-Mails auf den Versand von E-Mails innerhalb Ihrer eigenen Domäne beschränkt etc.).

Ist die Verbindung über SMTP sicher?

Der Verbindungsaufbau von snapADDY zu Ihrem E-Mail-Server über SMTP ist durch moderne Verschlüsslungsverfahren abgesichert: snapADDY unterstützen alle gängigen Standards für verschlüsselte SMTP-Verbindungen (SSL/TLS und STARTTLS) und die von Ihnen hinterlegten SMTP-Zugangsdaten werden ebenfalls verschlüsselt gespeichert.

Wenn Sie den verwendeten SMTP-Benutzer wie oben empfohlen als „technischen Nutzer“ einrichten, müssen Sie kein anderweitig verwendetes Passwort an snapADDY weitergeben und haben außerdem die volle Kontrolle darüber, an welche Empfänger E-Mails versendet werden dürfen. Auch über beim E-Mail-Versand möglicherweise auftretende Fehler (wie z.B. Bounces) haben Sie mit Ihrem eigenen E-Mail-Server volle Transparenz.

Werden auch Verfahren wie SPF oder DKIM angeboten?

Aktuell werden diese Verfahren nicht angeboten, da snapADDY keine eigene E-Mail-Server-Infrastruktur betreibt. Für das Einsatzszenario im Kontext von snapADDY VisitReport bieten SPF und DKIM auch keine zusätzliche Sicherheit, sondern würden im Gegenteil nur die pauschale Freigabe von snapADDY-IP-Adressen als legitimen Absender für alle E-Mail-Adressen in Ihrer Domain zulassen.

Die genannten Verfahren würden also wesentlich mehr Rechte einräumen als benötigt (insbesondere den Versand von E-Mails im Namen jeder möglichen Absenderadresse in Ihrer Domain). Mit dem oben beschriebenen Vorgehen via SMTP-Benutzer ist eine sehr viel restriktivere und damit potenziell sicherere Konfiguration möglich.

Sollten Sie dennoch keine SMTP-Zugangsdaten an snapADDY weitergeben wollen, sondern stattdessen SPF oder DKIM verwenden, so empfehlen wir die Konfiguration eines SMTP-Relay-Servers über einen externen Anbieter.

Zur Überwachung der Netzwerkaktivtäten in unserer Infrastruktur setzen wir das Intrusion Detection System (IDS) Amazon GuardDuty ein. GuardDuty analysiert Audit, DNS und Netzwerk-Logs und benachrichtigt bei verdächtigen Aktivitäten. Mehr Informationen zu GuardDuty finden Sie hier: https://aws.amazon.com/guardduty/

Daneben lassen wir unsere System regelmäßig extern durch sogenannte Penetrationstests prüfen. Dafür arbeiten wir mit dem renommierten Dienstleister CRISEC zusammen.

Auf Infrastruktur-Ebene hat nur eine sehr kleine Gruppe von langjährigen snapADDY-Mitarbeitern vollen Zugriff auf die Produktionsumgebungen. Dieser Zugang ist über das AWS Rechte- und Rollenkonzept geregelt und kann transparent über Audit Logs nachvollzogen werden.

Auf Applikationsebene hat ein weiterer Teil von Mitarbeitern für Supportprozesse eingeschränkten Zugang zu Kundenorganisationen. Diese Accounts sind zusätzlich durch Zweifaktorauthentifizierung abgesichert. Aktivitäten können über Audit Logs nachverfolgt werden.