Keeper ist fanatisch in Bezug auf die Sicherheit von Anmeldeinformationen und Datenschutz

Überblick

Keeper Security, Inc. ist es sehr daran gelegen, die Informationen unserer Kunden, mit Keepers mobiler und Desktop-Sicherheitssoftware, zu schützen. Millionen von Kunden und Unternehmen vertrauen Keeper die Sicherung und den Zugriff auf Ihre Passwörter und privaten Informationen an.

Keepers Software wird kontinuierlich verbessert, um den Kunden stets die neusten Technologien und Schutzmaßnahmen anbieten zu können. Diese Seite soll einen Überblick über Keepers Sicherheitsarchitektur, Verschlüsselungsmethoden und die Hosting-Umgebung der aktuellen Version bieten. Eine Übersicht, der technischen Details unserer Verschlüsselungs- und Sicherheitsmethoden, wird aufgeführt.

Unsere Datenschutzrichtlinien und Nutzungsbedingungen sind auf unserer Website über den folgenden Link erreichbar:

Zero-Trust-Plattform

Keeper nutzt die Zero-Trust-Sicherheitsarchitektur. Dieses Verfahren erfordert, dass jeder Nutzer verifiziert und angemeldet werden muss, bevor sie auf Webseiten, Anwendungen oder das System zugreifen können.

Die Keeper Enterprise Password Management-Plattform (EPM) erlaubt Unternehmen umfassende Einblicke in und Kontrolle über die Passwortnutzungspraktiken der Mitarbeitenden und ermöglicht IT-Admins die Überwachung der Passwortnutzung und Umsetzung von bewährten Sicherheitspraktiken.

Der Keeper Secrets Manager (KSM) liefert Entwicklungs- und Technikteams eine Plattform für die Verwaltung sämtlicher Zugangsdaten, einschließlich von IT-Infrastrukturgeheimnissen, SSH-Schlüsseln, API-Schlüsseln und Zertifikaten und bietet SDK und CI/CD-Integration.

Der Keeper Connection Manager (KCM) ist ein Gateway für den Desktop-Fernzugriff und bietet DevOps und IT-Teams reibungslosen Zero-Trust-Netzwerkzugriff (ZTNA) auf RDP-, SSH-Anwendungen, Datenbanken, Intranetanwendungen und Kubernetes-Anwendungen – alles über einen normalen Internetbrowser und ganz ohne Agents.

Keepers branchenführende Sicherheit im Detail

Verschlüsselung der Tresordaten

Keeper bietet mehrschichtige Verschlüsselungsmodelle, die auf dem Mindestzugriffsrechteprinzip basieren. Die 256-Bit-AES-Verschlüsselung auf Datensatz- und Ordnerebene erstellt Schlüssel auf den Endgeräten, die jeden einzelnen Datensatz im Tresor verschlüsseln. Sämtliche Inhalte (einschließlich Zugangsdaten, Dateianhänge, TOTP-Codes, Zahlungsinformationen, URL und eigene Datenfelder) der Tresordatensätze sind vollständig verschlüsselt.

Verschlüsselungsschlüssel werden lokal auf den Geräten erstellt, um das Zero-Knowledge-Prinzip zu wahren, und sie unterstützen erweiterte Funktionen wie die Datensatz- und Ordnerfreigabe. Zero-Knowledge bedeutet, dass die Endnutzer die volle Kontrolle über die Ver- und Entschlüsselung sämtlicher persönlicher Daten in ihren Keeper-Tresoren haben. Niemand sonst kann auf die Daten zugreifen, nicht einmal Keeper-Mitarbeitende.

Datensatz- und Ordnerschlüssel werden mit 256-Bit-AES-Datenschlüsseln kodiert, die für jeden Benutzer individuell auf dem Benutzergerät erstellt werden.

Auf dem Benutzergerät wird ein weiterer 256-Bit-AES-Client-Schlüssel erstellt, mit dem der lokal gespeicherte Offline-Cache verschlüsselt wird (wenn der Unternehmensadministrator Offline-Zugriff erlaubt). Und schließlich wird der 256-Bit-AES-Datenschlüssel noch mit einer weiteren Verschlüsselungsebene kodiert, auf die der nächste Absatz näher eingeht.

Methoden zur Tresorverschlüsselung

Keeper verschlüsselt Daten je nach Anmeldeverfahren der Benutzer auf unterschiedlichen Arten. Für Kunden und Mitglieder eines Family-Abos wird ein Master-Passwort und biometrische Authentifizierung genutzt. Für Unternehmens- und Konzernnutzer, die sich per SSO anmelden, verwendet Keeper das Elliptic-Curve-Verschlüsselungsverfahren, um eine sichere, passwortlose Anmeldung zu ermöglichen.

Für Master-Passwort-Benutzer: Der Schlüssel zur Ver- und Entschlüsselung des Datenschlüssel wird aus dem Master-Passwort des Benutzers abgeleitet. Dazu kommt das Verfahren "Password-based Key Variation Function (PBKDF2)" mit 1.000.000 Iterationen zum Einsatz. Nach der Eingabe des Master-Passworts wird der Schlüssel lokal erstellt und entpackt dann den Datenschlüssel. Der Datenschlüssel wird entschlüsselt und zum Entpacken der individuellen Datensatz- und Ordnerschlüssel genutzt. Mit der Entschlüsselung eines solchen Schlüssels werden die jeweiligen Daten auf dem Benutzergerät gespeichert.

Für die Anmeldung mit SSO oder passwortlosen Technologien: Hier kommt die Elliptic-Curve-Kryptographie zum Einsatz. Damit werden alle Daten auf Geräteebene ver- und entschlüsselt. Ein lokaler privater ECC-256-Schlüssel (secp256r) wird eingesetzt, um den Datenschlüssel zu dekodieren. Nach der Dekodierung des Datenschlüssels werden damit die individuellen Datensatz- und Ordnerschlüssel entschlüsselt. Mit dem Datensatzschlüssel wird dann der Inhalt der individuellen gespeichert Daten entschlüsselt. Der kodierte Datenschlüssel wird mittels eines Push-Systems oder eines Schlüsselaustauschdients, der sogenannten Gerätebestätigung, unter den verschiedenen Benutzergeräten ausgetauscht. Zur Wahrung von Zero-Knowledge wird die Gerätebestätigung lokal vom Endnutzer durchgeführt.

SSO-Verschlüsselungsmodell

Verfahren bei Erstgeräten (Onboarding für neue Benutzer)

1. Der Datenschlüssel, das Freigabe-Schlüsselpaar und das öffentliche/private EC-Geräteschlüsselpaar werden erstellt.
2. Der Datenschlüssel wird mit dem öffentlichen EC-Geräteschlüssel kodiert und in der Cloud gespeichert.
3. Der Benutzer meldet sich mit dem Identitätsanbieter (IdP) an.
4. Nach der IdP-Anmeldung wird die signierte SAML-Zusicherung von Keeper verifiziert.
5. Der Tresor wird erstellt und der Benutzer eingepflegt.

Verfahren bei bestehenden Geräten

1. Der Benutzer meldet sich mit dem Identitätsanbieter (IdP) an.
2. Nach der IdP-Anmeldung wird die signierte SAML-Zusicherung von Keeper verifiziert.
3. Keeper übermittelt den geräteverschlüsselten Datenschlüssel (device-encrypted data key, DEDK) an den Benutzer.
4. Der Datenschlüssel wird mit dem privaten EC-Geräteschlüssel entschlüsselt.
5. Der Datenschlüssel entschlüsselt die Ordner- und Datensatzschlüssel.
6. Die Datensatzschlüssel entschlüsseln die Datensatzinhalte.

Verfahren bei neuen oder nicht erkannten Geräten

1. Auf jedem neuen Gerät wird ein neues öffentliches/privates EC-Schlüsselpaar erstellt.
2. Der Benutzer meldet sich mit dem Identitätsanbieter (IdP) an.
3. Nach der IdP-Anmeldung wird die signierte SAML-Zusicherung von Keeper verifiziert.
4. Das Gerät wird per Keeper Push, Bestätigung durch einen Admin oder den Keeper-Automator-Dienst "bestätigt" (siehe Gerätebestätigung weiter unten).
5. Im Bestätigungsprozess wird der Datenschlüssel mit dem öffentlichen Schlüssel des neuen Geräts verschlüsselt.
6. Der geräteverschlüsselte Datenschlüssel (DEDK) wird an den Benutzer geschickt.

Gerätegenehmigung

• Die Gerätebestätigung ist ein Mechanismus zur sicheren Übertragung des Datenschlüssels des Benutzers auf ein neues Gerät, wobei das Zero-Knowledge-Prinzip gewahrt bleibt.
• Ein Benutzer kann ein Gerät mit der Verschlüsselung des Datenschlüssels mit dem öffentlichen Schlüssel des neuen Geräts bestätigen.
• Ein Admin kann ein Gerät über die Admin-Konsole, Commander oder den Keeper-Automator-Dienst bestätigen.
• Der Admin entschlüsselt den Datenschlüssel des Benutzers und verschlüsselt ihn wieder mit dem öffentlichen Schlüssel des neuen Geräts.
• Der Keeper-Automator-Dienst kann Gerätebestätigungen automatisch in der Kundeninfrastruktur durchführen.
• Keeper Automator überprüft die SAML-Signatur, entpackt den Datenschlüssel und kodiert ihn wieder mit dem öffentlichen Schlüssel des neuen Geräts.

Hier erfahren Sie mehr zum Keeper Automator.

Sicherheit auf Geräteebene für SSO Connect Cloud

Für Benutzer von SSO Connect Cloud wird ein privater Elliptic-Curve-Schlüssel erzeugt und lokal auf jedem Gerät gespeichert. Moderne Webbrowser und die Electron-basierte Keeper Desktop-App speichert der Keeper-Tresor den lokalen privaten EC-Geräteschlüssel (DPRIV) als nicht exportierbaren CryptoKey. Auf iOS- und Mac-Geräten wird der Schlüssel im Schlüsselbund des Geräts gespeichert. Auf Android-Geräten wird der Schlüssel im Android Keystore verschlüsselt. Dabei kommt Encrypted Shared Preferences zum Einsatz. Keeper nutzt soweit verfügbar sichere Speichermechanismen.

Der private Geräteschlüssel wird nicht direkt zum Verschlüsseln oder Entschlüsseln von Tresordaten verwendet. Nach erfolgreicher Authentifizierung durch den Identitätsanbieter wird ein separater (nicht gespeicherter) Schlüssel zur Entschlüsselung der Tresordaten verwendet. Die Offline-Extraktion des lokalen privaten Geräteschlüssels kann den Tresor eines Benutzers nicht entschlüsseln.

Verschlüsselung von ruhenden Daten

Keeper hostet die Plattform und Architektur mit AWS. Unsere AWS-Datenzentren befinden sich in mehreren geografischen Regionen und unsere Kunden können ihre Keeper-Infrastruktur in einer bevorzugten Region hosten. Damit ist die Isolation der Daten und Zugriffe auf die Plattform auf eine bestimmte Region beschränkt.

Die gespeicherten Tresordaten auf dem Benutzergerät werden mit AES-256 GCM lokal verschlüsselt. Bei der Übertragung der Daten kommt eine TLS-1.3-Verschlüsselung als zusätzliche Kodierungsebene zum Einsatz. Kundendaten werden durch den Einsatz der Datensatzverschlüsselung isoliert.

Das Keeper-Verschlüsselungsmodell hält folgende Struktur ein:

• Alle Tresore werden mit einem einzigartigen, Client-seitige erstellten 256-Bit-AES-Schlüssel im GCM-Modus verschlüsselt.
• Alle Datensatzschlüssel in freigegebenen Ordnern werden von einem geteilten 256-Bit-AES-Ordnerschlüssel geschützt.
• Die Datensatz- und Ordnerschlüssel der Tresornutzer werden mit einem weiteren 256-Bit-AES-Schlüssel kodiert, dem Datenschlüssel.
• Für den Keeper Secrets Manager (KSM) werden die Datensatz- und Ordnerschlüssel mit einem 256-Bit-AES-Anwendungsschlüssel kodiert.
• Für Benutzer, die sich mit ihrem Master-Passwort anmelden, werden die Schlüssel zur Ver- und Entschlüsselung der Daten aus dem Master-Passwort abgeleitet.
• Bei der Anmeldung per SSO oder passwortloser Technologien kommt Elliptic-Curve-Kryptographie zum Einsatz, um die Daten auf dem Gerät zu ver- und entschlüsseln.
• Alle verschlüsselten Daten werden zu einem Keeper-Server geschickt und mit einem 256-Bit-AES-Übertragungsschlüssel mit TLS verschlüsselt. So werden Man-in-the-Middle-Angriffe (MITM) unterbunden. Der Schlüssel wird auf dem Client-Gerät erstellt und mittels ECIES-Verschlüsselung durch den öffentlichen Elliptic-Curve-Schlüssel des Servers kodiert.
• Die sichere Freigabe von IT-Geheimnissen zwischen mehreren Benutzern verwendet Elliptic-Curve-Kryptographie-Schlüsselübertragung.

Datensatzversionierung

Keeper erhält den vollständigen verschlüsselten Versionsverlauf jedes Datensatzes, der im Tresor des Benutzers gespeichert ist, und stellt sicher, dass keine kritischen Daten jemals verloren gehen. Von der Keeper-Client-Anwendung können Benutzer den Datensatzverlauf untersuchen und eine Wiederherstellung eines einzelnen Tresor-Datensatzes durchführen. Wenn ein gespeichertes Passwort oder eine Datei in Keeper geändert oder gelöscht wird, haben die Benutzer immer die Möglichkeit, eine punktuelle Wiederherstellung durchzuführen.

Keeper Business

Kunden, die Keeper Business erwerben, erhalten zusätzliche Kontrolle über Ihre Benutzer und Geräte. Keeper-Administratoren erhalten Zugriff auf eine Cloud-basierte Administrationskonsole, die die volle Kontrolle über das On-Boarding und Off-Boarding von Benutzern, rollenbasierte Berechtigungen, delegierte Administration, Teams, Active Directory/LDAP-Integration, Zwei-Faktor-Authentifizierung, Single Sign-On und Sicherheitsrichtlinien hat. Die rollenbasierten Durchsetzungsrichtlinien von Keeper sind für jedes Unternehmen völlig anpassbar und skalierbar.

Super-Verschlüsselung von ruhenden Daten

Zusätzlich zur Speicherung von Chiffretexten der auf Endbenutzergeräten verschlüsselten Daten auf AWS-Servern nutzt Keeper auch Superverschlüsselung mit überregionalen Hardware-Sicherheitsmodulen (HSM) mit nicht exportierbaren Schlüsseln.

Verschlüsselung und Schutz von Backups

Auf Produkt-/Benutzerebene führt die Keeper-Software einen vollständigen Versionsverlauf für jeden einzelnen Datensatz. Sollte einmal die Wiederherstellung von Daten nötig sein, können Benutzer diese ohne Einschränkungen jederzeit in der Benutzeroberfläche einsehen und auf frühere Versionen zurücksetzen.

Auf Systemebene werden die Keeper-Datenbanken und Datenobjekte vervielfältigt und in mehreren geografischen Regionen für die Notfallwiederherstellung im Katastrophenfall gesichert. Alle Datensicherungen sind mit AES-256 und zusätzlich mit der Superverschlüsselung der auf den Geräten erstellten Chiffretexten verschlüsselt.

Benötigen Kunden Hilfe bei der Wiederherstellung (zum Beispiel nach der versehentlichen Löschung eines Tresor oder freigegebenen Ordners) steht Ihnen der Keeper-Kundendienst zur Verfügung, um Daten für beliebige Zeitpunkte (minutengenau) in den letzten 30 Tagen wiederherzustellen. Der Keeper-Kundendienst kann sie auch bei der Wiederherstellung von Benutzern, Tresoren oder ganzen Unternehmensstrukturen in Keeper unterstützen.

Kontowiederherstellung

Mit einem 24-Worte-langen Wiederherstellungssatz können Keeper-Kunden wieder Zugriff auf ihren Keeper-Tresor erlangen, sollten sie mal ihr Master-Passwort verloren oder vergessen haben.

Keepers Implementierung des Wiederherstellungssatzes basiert auf der BIP39-Wörterliste, mit der auch Kryptokonten geschützt werden. Die bei BIP39 eingesetzte Wörterliste besteht aus 2048 Wörtern, aus denen ein Verschlüsselungsschlüssel mit 256-Bit-Entropie erstellt wird. Diese Wiederherstellungsmethode wird üblicherweise von beliebten Bitcoin- und anderen Krytowährungskonten genutzt. Jedes Wort in der BIP39-Liste wurden sorgfältig ausgewählt, um die Erkennbarkeit zu gewährleisten und den Wiederherstellungsprozess weniger fehleranfällig zu machen. Benutzer sollten sich ihren Wiederherstellungssatz aufschreiben und an einem sicheren Ort (z. B. einem Safe) aufbewahren.

Der Wiederherstellungssatz erzeugt einen 256-Bit-AES-Schlüssel, mit dem eine Kopie des Datenschlüssels des Benutzers kodiert wird. Zur Wiederherstellung und Rücksetzung des Master-Passworts benötigen Benutzer den Wiederherstellungssatz und zusätzlich wird eine E-Mail-Verifizierung und Zwei-Faktor-Authentifizierung (2FA) durchgeführt.

Unternehmen können die Kontowiederherstellung in den Rollenrichtlinien deaktivieren.

Verschlüsselungsschlüssel für Unternehmen

Kunden von Keeper Enterprise und Business können die unterschiedlichen Funktionen der Keeper-Plattform individuell anpassen, darunter rollenbasierte Zugriffsrichtlinien, Bereitstellung, Authentifizierung und Verwaltung.

Admin-Funktionen der Keeper-Plattform sind mittels Verschlüsselung und Authentifizierung geschützt. Durch die Authentifizierung können die Funktionen nur von Benutzern verwendet werden, die dafür autorisiert sind. Mit der Verschlüsselung können designierte Administratoren nur physische und kryptographische Aktionen durchführen, die sich auf die Tresordaten oder vom Unternehmen kontrollieren Schlüssel beziehen. Einige Beispiel dazu sind:

• Die Keeper-Plattform ist faktisch eine Schlüsselverwaltungsplattform, auf der die Benutzer und Administratoren die volle Kontrolle über ihre privaten Schlüssel haben.
• Die Schlüsselpaare aus öffentlichen und privaten Schlüsseln werden bei der Erstellung von Geräten, Benutzern und Teams eingesetzt.
• Rollenrichtlinien für die Tresorübertragung und Durchführen der Gerätebestätigung mit öffentliche und private Verschlüsselungsschlüssel.
• Elliptic-Curve-Schlüsselpaare (EC) werden für die Datenfreigabe zwischen Benutzern und von Einzelnutzern zu Admins auf der Unternehmensebene genutzt.
• Sensible Benutzerdaten (etwa die Passwortstärke eines Datensatzes) wird mit dem öffentlichen Unternehmensschlüssel kodiert, den nur ein Admin entschlüsseln kann.
• Datensatztitel, URL, Datensatzfeldtypen eines jeden Datensatzes von Benutzern werden mit dem öffentlichen Unternehmensschlüssel kodiert und können in der Keeper Admin-Konsole von Administratoren entschlüsselt werden, die über die nötigen Konformitätsberichtsbefugnisse verfügen.

Geräteverifizierung

Ehe ein Benutzer überhaupt versuchen kann, sich bei einem Konto anzumelden, müssen sie im ersten Schritt die Gerätebestätigung und Verifizierung bestehen. Durch die Gerätebestätigung werden Aufzählungsangriffe oder Brute-Force-Angriffe gegen Konten verhindert.

Kunden, die sich mit dem Master-Passwort anmelden, können die Gerätebestätigung auf verschiedenen Wegen durchführen, z. B.:

• E-Mail-Verifizierungscode
• 2FA-Code aus TOTP oder Textnachricht
• Nutzt Keeper Push^™ für das Senden der Benachrichtigung an bestätigte Geräte.

Kunden, die sich bei Keeper mit SSO Connect Cloud anmelden, führen die Gerätebestätigung bei der Schlüsselübertragung durch. Dabei wird der verschlüsselte Datenschlüssel des Benutzers an das Gerät geschickt, wo er lokal mit dem privaten Elliptic-Curve-Schlüssel dekodiert wird. Gerätebestätigungsverfahren sind unter anderem:

• Keeper Push (mit Push-Benachrichtigungen) an bestehende Nutzergeräte
• Admin-Bestätigung über die Keeper Admin-Konsole
• Automatische Bestätigung über Keeper Automator
• Automatische Admin-Bestätigung über die Commander CLI

Hier erfahren Sie mehr zur Gerätebestätigung.

Datenschutz

Keeper ist DSGVO-konform und stellt sicher, dass die Prozesse und Produkte von Keeper die Bestimmungen der DSGVO für unsere Kunden in der Europäischen Union und auf der ganzen Welt einhalten. We comply with the EU-U.S. Data Privacy Framework ("EU-U.S. DPF"), the UK Extension to the EU-U.S. DPF, the German Federal Data Protection Act (BDSG) and the Swiss-U.S. Data Privacy Framework ("Swiss-U.S. DPF") as set forth by the U.S. Department of Commerce.

Lesen Sie sich die Keeper DSGVO-Datenschutzhinweise durch.

Keine Keeper-Anwendung enthält Tracker-Software oder Befehlsbibliotheken von Drittanbietern, die Datentracking durchführen. In diesem Bericht zur Android-App von Keeper sehen Sie zum Beispiel, dass keinerlei Trackersoftware installiert wird.

Datenisolierung

Keeper ist eine vollständig verwaltete SaaS-Plattform und hostet seine Daten in mehreren, geografisch isolierten AWS-Rechenzentren. Organisationen können ihren Keeper-Mandanten in ihrer bevorzugten primären Region hosten. Die Kundendaten und der Zugriff auf die Plattform sind für diese bestimmte Region isoliert.

Verfügbare Regionen:

• Vereinigte Staaten von Amerika (USA)
• Government-Cloud der US-Regierung (US_GOV)
• Europa (EU)
• Australien (AU)
• Japan (JP)
• Kanada (CA)

Verschlüsselung bei Datenübertragung

Der Keeper-Tresor wird von API geschützt, die durch die Autorisierung auf den Benutzergerät validiert werden.

• Der Benutzer ruft bei der Anmeldung einen Sitzungstoken ab und übermittelt ihn mit jedem API-Abruf.
• Der Sitzungstoken wird auf dem Server im Hintergrund verwaltet und kontrolliert.
• Die Anmeldung wird per Master-Passwort, biometrischen Merkmalen, Sitzungsfortsetzung oder SAML-2.0-konformer SSO-Authentifizierung durchgeführt.

Bei der Verwendung des Master-Passworts wird auf den Benutzergeräten wird mittels PBKDF2-HMAC-SHA256 und einem zufälligen Salt aus dem Master-Passwort ein 256-Bit-Authentifizierungsschlüssel generiert. Der Authentifizierungs-Hash wird durch Hashing des Authentifizierungsschlüssels mittels SHA-256 generiert. Zur Anmeldung wird dieser Authentifizierungs-Hash mit dem Authentifizierungs-Hash verglichen, der im Cloud Security Vault hinterlegt ist. Nach der Anmeldung wird ein Sitzungstoken erstellt und vom Benutzergerät für weitere API-Anfragen verwendet. Für die dauerhafte Client-zu-Server-Kommunikation muss die Sitzung aktiv bleiben.

• Keeper verwendet 256-Bit- und 128-Bit-TLS zur Verschlüsselung von absolut allen Daten, die in der Benutzeranwendung und im sicheren Keeper-Datenspeicher aufbewahrt werden.
• Keeper setzt TLS-Zertifikate ein, die mit einem SHA2-Algorithmus signiert wurden. SHA2 ist der momentan sicherste Signaturalgorithmus, den kommerzielle Zertifizierungsstellen anbieten können. Keepers Einsatz von SHA2 schützt vor gefälschten Zertifikaten, die Angreifer einsetzen könnten, um eine Webseite nachzuahmen.

Cloud-Authentifizierung

Keeper hat ein hoch entwickeltes Cloud-Authentifizierungs- und -Netzwerkkommunikationsmodell entwickelt, das höchste Standards an Datenschutz, Sicherheit, Vertrauen und Transparenz erfüllt. Einige Schlüsselfunktionen des Authentifizierungsmodells sind:

Integration mit beliebigen SAML-2.0-Anbietern

Keeper kann mit allen Identitätsanbietern integriert werden, die SAML 2.0 unterstützen: Okta, Microsoft Entra ID (Azure), AD FS, Google Workspace, Centrify, OneLogin, Ping Identity, JumpCloud, Duo, Auth0 und viele mehr.

Unsere Produkte bieten zwei SSO-Verfahren: SSO Connect Cloud und SSO Connect On-Prem. Beide Verfahren verbinden die bewährte Zero-Knowledge-Architektur mit einer reibungslosen Authentifizierung für die Benutzer.

Master-Passwörter der Benutzer werden nie über die Netzwerkebene übertragen

Anders als bei den meisten SaaS-Diensten verlassen Zugangsdaten bei Keeper nie das Gerät. Wenn Sie sich bei Keeper mit Ihrem Master-Passwort anmelden, wird PBKDF2 auf dem Gerät genutzt, um einen 256-Bit-AES-Schlüssel für die Entschlüsselung zu erstellen. Auf dem Gerät wird ein weiterer PBKDF2-Schlüssel erstellt und mit HMAC_SHA256 gehasht, um einen Authentifizierungstoken zu erstellen. Keeper hat somit keinerlei Kenntnis über die Entschlüsselungscodes der Benutzer.

Datenverkehr zwischen Client-Gerät und Keeper Cloud kann nicht abgefangen oder entschlüsselt werden

All Daten, die an Keepers Server übertragen werden, sind mit einem 256-Bit-AES-Übertragungsschlüssel und TLS verschlüsselt, um sie gegen Man-in-the-Middle-Angriffe (MITM) zu schützen. Der Übertragungsschlüssel wird auf dem Gerät erstellt und mit dem öffentlichen EC-Schlüssel per ECIES-Verfahren verschlüsselt und erst dann an den Server übertragen.

Neue Geräte können sich ohne vorherige Verifizierung nicht bei einem Konto anmelden

Benutzer können sich mit neuen Geräten nicht einfach so bei ihrem Keeper-Konto anmelden, ohne zusätzliche Verifizierungsverfahren zu durchlaufen. Keeper unterstützt verschiedene Verifizierungsmodelle, die sich am Authentifizierungsverfahren orientieren.

Multifaktor-Authentifizierung (MFA) erfolgt nach der Verifizierung, vor der Eingabe des Master-Passworts

Hat ein Benutzer MFA aktiviert oder wurde es vom Admin aktiviert, muss dieser Schritt erst durchgeführt werden, bevor das Master-Passwort eingegeben werden kann.

Die Eingabe des Master-Passworts ist erst möglich, wenn die Schritte zur Geräteverifizierung und MFA erfolgreich sind

Wurde kein Verifizierungsmodell eingerichtet, kann ein Benutzer das Master-Passwort nicht eingeben. Diese erweiterte Authentifizierung schützt vor häufigen Cyberangriffsarten, darunter Brute-Force-Angriffe, Passwort-Spraying, Aufzählungsangriffe und MITM.

Multifaktor-Authentifizierung (MFA)

Zum Schutz vor nicht autorisierten Zugriffen auf die Konten unserer Kunden bietet Keeper Mehr-Faktor-Authentifizierung (MFA) an. Bei diesem Authentifizierungsansatz ist die Eingabe mehrerer Authentifizierungsfaktoren nötig: ein Wissensfaktor, ein Besitzfaktor und/oder ein Inhärenzfaktor. Hier erfahren Sie mehr über die Einrichtung von MFA in Keeper.

Keeper nutzt Ihr Master-Passwort und das Gerät in Ihrem Besitz, um eine zusätzliche Sicherheitsebene einzurichten, sollte Ihr Master-Passwort oder Gerät einmal kompromittiert sein. Keeper unterstützt FIDO2-WebAuthn-Hardwareschlüssel und softwarebasierte Lösungen wie TOTP- und SMS-Codes.

Wenn Sie die TOTP-Methode für MFA/2FA nutzen, generiert Keeper einen geheimen 10-Byte-Schlüssel mithilfe eines sicheren, kryptografischen Zufallszahlengenerators. Dieser Code ist etwa eine Minute lang gültig und kann nach einer erfolgreichen Anmeldung nicht noch einmal genutzt werden. Keeper unterstützt beliebige TOTP-Anwendungen, darunter Google Authenticator und Microsoft Authenticator. Keeper kann auch direkt mit beliebten MFA-Diensten wie DUO oder RSA SecurID integriert werden.

Beim Einsatz eines MFA-Authenticators wie Google Authenticator, Microsoft Authenticator oder anderen TOTP-Anwendungen auf ihrem Mobilgerät erstellt ein Keeper-Server intern einen QR-Code mit dem geheimen Schlüssel. Bei jeder Aktivierung von MFA wird ein neuer Schlüssel erstellt.

MFA können Sie in den Einstellungen der Keeper Web-App, Desktop-App oder iOS-/Android-App aktivieren. Admins für Keeper Business können in der Keeper Admin-Konsole den Einsatz von MFA für alle Benutzer auch erzwingen und die unterstützten MFA-Verfahren festlegen.

Die Unterstützung des FIDO2-kompatiblen WebAuthn bietet Keeper mit Hardware-Sicherheitsschlüsseln wie YubiKey oder Google Titan-Schlüsseln, die als zusätzliche Authentifizierungsfaktoren dienen. Passkeys werden ebenfalls als 2FA-Methode von physischen Geräten oder im Webbrowser unterstützt. Sicherheitsschlüssel sind eine sichere Methode zur MFA-Durchführung, bei der keine manuelle Codeeingabe erforderlich ist.

Android Smart Watch Apple Smart Watch DUO Entrust Google Authenticator Microsoft Authenticator RSA SecureID SMS-Textnachricht Titan Security Key TOTP Yubico

Keeper Active Directory/LDAP Bridge

Die Keeper Bridge lässt sich mit Active Directory und LDAP-Servern zur Bereitstellung und Eingliederung von Benutzern integrieren. Die Keeper Bridge-Kommunikation wird zunächst von einem Administrator mit dem Recht zur Verwaltung der Bridge genehmigt. Ein Übertragungsschlüssel wird erstellt und für jegliche zukünftige Kommunikation mit Keeper geteilt. Die Verwendung des Übertragungsschlüssels stellt die Autorisierung für alle von der Bridge ausgeführten Funktionen dar, abgesehen von der Initialisierung der Bridge. Der Übertragungsschlüssel kann jederzeit wiederhergestellt werden und ändert sich alle 30 Tage.

Der Übertragungsschlüssel dient ausschließlich zur Übertragung, was bedeutet, dass ein beeinträchtigter Schlüssel ohne Datenverlust oder Genehmigung reinitialisiert oder widerrufen werden kann.

Die Keeper Bridge erteilt keine Rechte an bestimmte Rollen oder Benutzer. Sie kann einem Benutzer einer privilegierten Rolle zuordnen, solange keine Durchsetzungsschlüssel benötigt werden. Die Keeper Bridge kann jedoch weder sich selbst noch einen anderen Benutzer eine Rolle zuweisen, die über der eigenen Hierarchieebene liegt. Nicht alle Funktionen sind für die Bridge verfügbar, d.h. die Bridge kann aktive Benutzer deaktivieren, diese jedoch nicht löschen. Der Admin kann dann entscheiden, ob der Benutzer gelöscht oder übertragen werden soll.

SSO-Authentifizierung mit MFA

Wenn Keeper mit einer SSO-Lösung wie Entra ID / Azure AD, Okta, Ping, Google Workspace oder einem anderen SAML-2.0-Identitätsanbieter bereitgestellt wird, kann MFA während des IdP-Anmeldeprozesses vollständig verwaltet werden. Keeper unterstützt außerdem Azure-Richtlinien für bedingten Zugriff über alle Gerätetypen und Anwendungen hinweg.

MFA kann sowohl auf der Identitätsanbieterseite wie auch der Keeper-Seite erzwungen werden. Führt ein Benutzer zum Beispiel eine erfolgreiche MFA-Authentifizierung mit dem Identitätsanbieter durch, kann eine weitere MFA-Authentifizierung im Keeper-Interface angefordert werden. Dieses Verfahren kann vom Keeper-Administrator eingerichtet werden.

Amazon Web Services CAS Centrify DUO F5 Google Workplace IBM Security JumpCloud Microsoft ADFS Onelogin Okta Ping Identity

SAML-2.0-Authentifizierung mit SSO Connect Cloud

Keeper SSO Connect Cloud ermöglicht es Unternehmenskunden, Keeper mit beliebigen SAML-2.0-kompatiblen Identitätsanbietern zu integrieren und Benutzern vollständig verschlüsselte Datentresore bereitzustellen.

SAML implementation with Keeper allows a user to authenticate through their SSO IdP and then decrypt their vault ciphertext on their device. Every user device has an individual Elliptic Curve (EC) key pair and encrypted data key. In addition, each user has their own 256-bit AES data key. When signing in to Keeper using a new device, the user must utilize existing devices to perform an approval or, alternatively, an admin with privileges can approve their device.

This capability is essential so a user can decrypt their vault locally, on their device, without the requirement of a master password or password key derivation. Zero knowledge is maintained because the cloud cannot decrypt the user's data key. Instead, the device-encrypted data key (DEDK) is provided to the user upon successful authentication of the IdP (e.g., Okta, Azure, Google Workspace, AD FS, Ping, Duo, Jumpcloud, etc.). The data key for the user is decrypted locally on the device with the elliptic curve device private key. Keeper holds US Utility Patents on this technology, which has been in production since 2015.

Keeper Automator ist ein optionaler Service, der nach erfolgreicher Anmeldung beim SSO-Identitätsanbieter sofortige Teamfreigaben, Gerätefreigaben und Teambenutzerzuweisungen durchführt.

Sobald Automator ausgeführt wird, können Benutzer nach erfolgreicher Authentifizierung bei Ihrem Identitätsanbieter ohne weitere Genehmigungsschritte nahtlos mit neuen Geräten (noch nicht vorher genehmigt) auf Keeper zugreifen.

Keeper SSO Connect On-Prem

Während die meisten Kunden Keeper SSO Connect Cloud einsetzen, können Kunden, die eine On-Prem-Lösung benötigen, SSO Connect On-Prem einsetzen, eine selbst gehostete Integration, die entweder einen von Windows oder Linux gehosteten Anwendungsserver erfordert. Um die Zero-Knowledge-Sicherheit aufrechtzuerhalten und eine nahtlose SSO-Erfahrung für die Benutzer zu gewährleisten, muss Keeper SSO Connect auf dem Server des Kunden installiert werden. Windows-, Mac- und Linux-Umgebungen werden mit Hochverfügbarkeit (HA) im Lastenausgleichsmodus und Super-Encryption mit Hardware-Sicherheitsmodulen vollständig unterstützt.

Keeper SSO Connect erstellt und verwaltete automatisch das Master-Passwort, dem zufällig generierten 256-Bit Schlüssel, für alle zugelassenen Benutzer. Dieses Master-Passwort ist mit dem SSO-Schlüssel verschlüsselt. Der SSO-Schlüssel ist mit dem Baumschlüssel verschlüsselt. Der SSO-Schlüssel wird vom Server abgerufen, nachdem Keeper SSO Connect gestartet wurde, und wird dann mit Hilfe des Baumschlüssel entschlüsselt, der lokal auf dem Server gespeichert ist, um den automatischen Systemstart zu unterstützen. Die Kommunikation zwischen SSO Connect und Keepers Cloud Security Vault wird durch einen Übertragungsschlüssel geschützt. Die SAML-Kommunikation ist kryptographisch signiert und wird mit einem RSA-SHA256- oder ECDSA-SHA256-Signaturalgorithmus geschützt. Das jeweilige Verfahren hängt vom Verschlüsselungsschlüssel (RSA oder ECC) ab, den der Kunde bereitstellt.

Teilen

Keeper unterstützt die sichere Freigabe von Datensätzen zwischen Benutzern, für interne Teams oder auch an Benutzer außerhalb der Organisation (sofern vom Keeper-Administrator erlaubt).

Freigabe von Datensätzen

Keeper-Benutzer können Datensätze direkt untereinander freigeben. Dafür fordert Keeper zuerst den öffentlichen Elliptic-Curve-Schlüssel für den Tresor des Benutzers an. Jeder Datensatz hat einen Datensatzschlüssel, der mit dem öffentlichen Elliptic-Curve-Schlüssel kodiert ist, und der mit dem Keeper-Tresor des Benutzers synchronisiert wird.

Der Besitzer des verschlüsselten freigegebenen Datensatzes entschlüsselt den Datensatzschlüssel mit dem eigenen privaten Elliptic-Curve-Schlüssel. Der Datensatzschlüssel wird dann mit dem Datenschlüssel des Benutzers wieder verschlüsselt und der Chiffretext wird im Empfängertresor gespeichert.

Einmalige Freigabe

Über Keepers einmal gültige Freigabe können Sie Daten (Passwörter, Zugangsdaten, IT-Geheimnisse, Verbindungsdaten, Dokumente und andere vertrauliche Daten) zeitlich begrenzt und auf sichere Weise teilen. Auch wenn die gewünschte Person kein Keeper-Konto besitzt. Die Keeper-Funktion "Einmal gültige Freigabe" nutzt für die Verschlüsselung dieselbe Technologie wie der Keeper Secrets Manager (KSM), der Zero-Knowledge- und Zero-Trust-Plattform zur Sicherung von Cloud-Infrastruktur.

1. Im Keeper-Tresor erstellt der Sender mit einem Klick auf "Einmalige Freigabe" eine einmal gültige Freigabe. Der 256-Bit-AES-Datensatzschlüssel wird mit einem einmal gültigen Zugriffstoken verschlüsselt und der verschlüsselte Wert wird im Keeper-Tresor gespeichert.
2. Der Benutzer kann den einmal gültigen Freigabetoken einfach per URL oder QR-Code an den Empfänger weitergeben. Der Fragmentidentifikator der URL enthält den Zugriffstoken. Dieser wird niemals an einen Keeper-Server geschickt. Somit kann Keeper nicht auf die Informationen zugreifen oder sie entschlüsseln und Zero-Knowledge bleibt gewahrt.
3. Die URL wird im Browser des Benutzers geöffnet und die Tresor-Anwendung wird auf dem Gerät geöffnet. Der Token wird direkt in den lokalen Tresor geladen und nicht an den Server geschickt.
4. Der Empfänger nutzt dann das eigene Gerät für die Erstellung eines benutzerseitigen EC-Schlüsselpaars. Der private Schlüssel wird lokal auf dem Gerät im CrytoKey-Speicher aufbewahrt.
5. Bei der ersten Verwendung durch den Empfänger authentifiziert sich die SDK-Bibliothek mit dem Hash-Wert des einmal gültigen Zugriffstoken. Danach antwortet der Keeper-Server mit dem verschlüsselten Datensatz-Chiffretext und verschlüsselten Datensatzschlüssel.
6. Das Gerät dekodiert den Datensatzschlüssel mit dem einmal gültigen Zugriffstoken und nun werden die Inhalte entschlüsselt. Der Schlüssel wird auf dem Client-Gerät im CryptoKey-Speicher des Browsers oder einem anderen Speicherort aufbewahrt.
7. Der verschlüsselte Datensatzschlüssel für das Gerät wird gelöscht, damit der Token nicht erneut verwendet werden kann. Danach muss die Client-Anfrage mit einem privaten Schlüssel signiert werden.
8. Weitere Anfragen vom selben Gerät werden mit einem Identifikator, der das Gerät eindeutig identifiziert, und einer Anfrage, die mit dem privaten Schlüssel signiert wurde. Die Anfrage für einen bestimmten Geräteidentifikator (mittels ECDSA-Signatur) nutzt den öffentlichen Client-Schlüssel des Geräts und wird vom Server überprüft. Keeper verarbeitet die Anfrage und der Server schickt den verschlüsselten Datensatz als Chiffretext an das Benutzergerät.
9. Neben der Verschlüsselung auf Datensatzebene erzeugt das Client-Gerät auch einen zufallsgenerierten 256-Bit-AES-Übertragungsschlüssel, der mit dem öffentlichen Schlüssel der Keeper-Cloud-API kodiert wird. Das Client-Gerät dekodiert die Antwort vom Server mit dem Übertragungsschlüssel und entschlüsselt danach den vom Server erhaltenen Chiffretext mit dem Datensatzschlüssel, womit die Datensatzinhalte dekodiert werden.

Admin-Freigabe

Keepers Freigabe-Admins sind eine rollenbasierte Zugriffsberechtigung (Role-based Access Control, RBAC), die Admins erhöhte Privilegien für die freigegebenen Ordner und Datensätze der Organisation geben. Freigabe-Admins haben komplette Benutzer- und Datensatzprivilegien für sämtliche freigegebene Datensätze, auf die sie Zugriff haben.

Verschlüsselungsmodell von Secrets Manager

Der Keeper Secrets Manager ist eine Zero-Knowledge-Plattform für IT- und DevOps-Fachkräfte. Mit dieser Plattform können Teams IT-Geheimnisse über den gesamten Software-Lebenszyklus und Entwicklungsprozess hinweg verwalten.

Der Secrets Manager nutzt folgendes Verschlüsselungsmodell:

• Die Ver- und Entschlüsselung findet lokal auf dem Endgerät statt, nicht auf dem Server.
• Klartext wird niemals auf dem Gerät gespeichert.
• Klartext wird niemals vom Server empfangen.
• Niemand, auch nicht Keeper-Mitarbeitende, Dritte oder Mittelsleute, können die IT-Geheimnisse entschlüsseln.
• Das Client-Gerät verwaltet die Schlüssel für die Ver- und Entschlüsselung der IT-Geheimnisse, die sich so unter der vollen Kontrolle des Benutzers befinden.
• Jedes IT-Geheimnis ist mit einem client-seitig erstellten 256-Bit-AES-Verschlüsselungscode im GCM-Modus verschlüsselt.
• Befindet sich das IT-Geheimnis in einem freigegebenen Ordner, wird der Datensatzschlüssel mit einem Freigabeordnerschlüssel kodiert.
• Ein 256-Bit-AES-Anwendungsschlüssel wird client-seitig erstellt und zur Entschlüsselung des freigegebenen Ordners und der Datensatzschlüssel verwendet. Der Datensatzschlüssel dekodiert dann die individuellen IT-Geheimnisse.
• Die Keeper-Server sind mit einem 256-Bit-AES-Schlüssel mit TLS gegen MITM-Angriffe geschützt.
• Der Übertragungsschlüssel wird auf dem Client-Gerät erstellt und mit ECIES-Verschlüsselung basierend auf dem öffentlichen EC-Schlüssel des Servers an diesen übertragen.
• Elliptic-Curve-Kryptographie wird genutzt, um IT-Geheimnisse zwischen Benutzern sicher freizugeben.
• Mehrere Verschlüsselungsebenen erlauben die Zugriffsteuerung auf Benutzer-, Gruppen- und Adminebene.
• Im Tresor verwaltete IT-Geheimnisse werden separiert und auf bestimmte Secrets-Manager-Geräten isoliert, die die Zugriffsberechtigung für den Datensatz oder Ordner haben.

Das Modell von Keeper Secrets Manager für die Passwortrotation

• Ein einzigartiger Keeper Secrets Manager-Client, das sogenannte Gateway, wird in der IT-Umgebung des Kunden installiert.
• Das Gateway stellt eine sichere Verbindung nach draußen zum Keeper-Router her.
• Beim Router handelt es sich um einen Cloud-Dienst, der in Keepers AWS-Umgebung gehostet wird. Er ermöglicht die Kommunikation zwischen der Hintergrund-API von Keeper, den Endnutzeranwendungen (Web-Tresor, Desktop-App usw.) und in den Benutzerumgebungen installierten Gateways.
• Websockets werden zwischen dem Endnutzergerät (z. B. dem Web-Tresor) und dem Keeper-Router unter Verwendung des aktuellen Sitzungstokens eingerichtet.
• Der Keeper-Router verifiziert den Sitzungstoken und authentifiziert die Sitzung. Alle verschlüsselten Daten, die an den Keeper-Router geschickt werden, sind mit einem 256-Bit-AES-Schlüssel und zusätzlich mit TLS kodiert, um sie gegen MITM-Angriffe zu schützen.
• Der 256-Bit-AES-Schlüssel wird auf dem Endnutzergerät erstellt und mit ECIES-Verschlüsselung basierend auf dem öffentlichen EC-Schlüssel des Routers an den Server übertragen.
• Rotations- und Erkennungsanfragen werden zwischen dem Endnutzergerät (oder Keeper Scheduler) und dem Gateway über die bestehenden Websocket-Kommunikationskanäle durchgeführt.
• Benötigt das Gateway während der Rotation ein IT-Geheimnis aus dem Keeper-Tresor, authentifiziert und entschlüsselt das Gateway das IT-Geheimnis mit der Keeper-Secrets-Manager-API, um Zero-Knowledge zu wahren.
• Wie bei anderen Secrets-Manager-Diensten kann der Zugriff neben Verschlüsselungs- und Signaturprozessen auch per IP-Adresssperre eingeschränkt werden.

Zero-Trust-Verbindung und Tunnelsicherheit

Zero-Trust KeeperPAM bietet die Möglichkeit, privilegierte Cloud- und On-Premise-Sitzungen einzurichten, Tunnel zu erstellen, einen direkten Infrastrukturzugang einzurichten und den Remote-Datenbankzugriff ohne VPN zu sichern.

Eine Verbindung ist eine visuelle Remote-Sitzung über einen Webbrowser. Die Interaktion zwischen dem Benutzer und dem Zielgerät erfolgt über ein Webbrowser-Fenster oder innerhalb der Keeper Desktop-Anwendung.

Ein Tunnel ist eine TCP/IP-Verbindung, die zwischen dem lokalen Vault Client über das Keeper Gateway und dem Zielendpunkt hergestellt wird. Der Benutzer kann eine beliebige native Anwendung für die Kommunikation mit dem Zielendpunkt verwenden, z. B. das Befehlszeilenterminal, eine GUI-Anwendung oder eine Datenbankverwaltungsanwendung wie MySQL Workbench.

Wenn der Benutzer eine Verbindung oder einen Tunnel herstellt:

1. Die Anwendung „Vault Client“ kommuniziert mit der Router-Infrastruktur von Keeper, um eine WebRTC-Verbindung zu initiieren, die durch einen symmetrischen ECDH-Schlüssel geschützt ist, der im entsprechenden Datensatz von Keeper gespeichert ist.
2. Das Keeper Gateway kommuniziert mit dem Keeper Router über nur ausgehende WebSockets. Dies wird unter diesem Link ausführlich beschrieben.
3. Das Keeper Gateway nutzt die APIs des Keeper Secrets Managers, um die erforderlichen Geheimnisse aus dem Tresor abzurufen, einschließlich des symmetrischen ECDH-Schlüssels.
4. Für Verbindungen leitet der Vault Client (unter Verwendung des Apache Guacamole-Protokolls) Daten über die WebRTC-Verbindung an das Keeper-Gateway weiter, das dann Guacd verwendet, um sich mit dem im Keeper-Datensatz gefundenen Ziel zu verbinden.
5. Für Tunneling-Funktionen (Port-Weiterleitung) wird ein lokaler Port auf dem lokalen Gerät geöffnet, auf dem die Keeper Desktop-Software ausgeführt wird. Die an den lokalen Port gesendeten Daten werden über die WebRTC-Verbindung an das Keeper Gateway übertragen und anschließend an den im Datensatz von Keeper definierten Zielendpunkt weitergeleitet.
6. Sitzungsaufzeichnungen von Verbindungen werden durch einen AES-256-Verschlüsselungsschlüssel („Aufzeichnungsschlüssel“) geschützt, der bei jeder Sitzung auf dem Keeper Gateway generiert wird. Der Aufzeichnungsschlüssel wird zusätzlich von einem von HKDF abgeleiteten AES-256-Ressourcenschlüssel umhüllt.

Sicherheit durch Remote Browser Isolation

Die Technologie der Keeper Remote Browser Isolation schützt den Zugriff auf interne Webanwendungen oder andere webbasierte Ressourcen über den Keeper Connection Manager Docker-Container oder über das Keeper Gateway.

Verwendung der Docker-Container-Methode von Connection Manager:

1. Der Benutzer authentifiziert sich beim Keeper Connection Manager-Webdienst, der vom Kunden in einem Docker-Container gehostet wird.
2. Der Benutzer startet eine Sitzung mit Remote Browser Isolation für die Ziel-Webanwendung. Zwischen dem Browser des Benutzers und dem gehosteten Keeper Connection Manager-Webdienst wird die Kommunikation über HTTPS durch Let's Encrypt oder das vom Kunden angegebene Zertifikat geschützt.
3. Auf dem Keeper Connection Manager Docker-Container wird eine eingebettete Version von Chromium in einer Sandbox ausgeführt. Die Ziel-Website wird mithilfe eines lokalen Anzeigetreibers gerendert, der den sichtbaren Inhalt der Seite in Echtzeit über das Apache-Guacamole-Protokoll an den Webbrowser des Benutzers streamt.

Verwendung des Keeper Gateway mit dem Keeper Web-Tresor oder der Desktop-App:

1. Die Anwendung „Vault Client“ kommuniziert mit der Router-Infrastruktur von Keeper, um eine WebRTC-Verbindung zu initiieren, die durch einen symmetrischen ECDH-Schlüssel geschützt ist, der im entsprechenden Datensatz von Keeper gespeichert ist.
2. Das Keeper Gateway kommuniziert mit dem Keeper Router über nur ausgehende WebSockets. Dies wird unter diesem Link ausführlich beschrieben.
3. Das Keeper Gateway nutzt die APIs des Keeper Secrets Managers, um die erforderlichen Geheimnisse aus dem Tresor abzurufen, einschließlich des symmetrischen ECDH-Schlüssels.
4. Der Vault Client (unter Verwendung des Apache-Guacamole-Protokolls) leitet die Daten über die WebRTC-Verbindung an das Keeper-Gateway weiter, das sich dann durch HTTP oder HTTPS mit dem im Keeper-Datensatz gefundenen Ziel verbindet.
5. Sitzungsaufzeichnungen von Verbindungen werden durch einen AES-256-Verschlüsselungsschlüssel („Aufzeichnungsschlüssel“) geschützt, der bei jeder Sitzung auf dem Keeper Gateway generiert wird. Der Aufzeichnungsschlüssel wird zusätzlich von einem von HKDF abgeleiteten AES-256-Ressourcenschlüssel umhüllt.

Schutz durch Browser Isolation

Durch die Verwendung des Remote Browser Isolation Protokolls werden mehrere Sicherheitsmaßnahmen aktiviert:

1. Der zu schützende Endpunkt der Webanwendung wird vom Keeper Connection Manager-Gateway bis zum lokalen Gerät des Benutzers mit einer TLS-Verschlüsselungsschicht umhüllt, unabhängig davon, ob TLS zwischen Gateway und Endpunkt verwendet wird – zum Schutz vor MITM-Angriffen oder Paketinspektionen im lokalen Netzwerk des Benutzers.
2. Die Remote-Browsing-Sitzung projiziert die Interaktion visuell auf das lokale Gerät des Benutzers, wobei eine Leinwand und grafisches Rendering verwendet werden. Auf dem lokalen Rechner des Benutzers wird kein JavaScript-Code oder HTML von der Ziel-Website ausgeführt.
3. Da kein Website-Code des Ziels lokal ausgeführt wird und der lokale Browser nicht direkt auf den zugrunde liegenden Anwendungscode zugreifen kann, ist die isolierte Webanwendung gegen Angriffsvektoren wie reflektierte Cross-Site-Scripting-Schwachstellen, Cross-Site-Request-Forgery und API-Missbrauch geschützt.
4. Der Endbenutzer kann durch die Filterung von URL- und Ressourcenanfragen daran gehindert werden, eine Datenexfiltration vom Zielendpunkt aus durchzuführen. Datei-Uploads und -Downloads werden eingeschränkt, auch wenn die Ziel-Webanwendung die Aktion ansonsten zulassen würde.
5. Die Browsing-Sitzung und die Tastatureingaben können zu Prüfungs- und Compliance-Zwecken aufgezeichnet werden, was die Möglichkeit bietet, eine forensische Analyse webbasierter Sitzungen durchzuführen.
6. Anmeldeinformationen, die automatisch vom Gateway in die Ziel-Webanwendung eingegeben werden, werden niemals an das Gerät des Benutzers übertragen und sind für den Benutzer auf seinem lokalen Gerät nicht zugänglich. Der Schutz vor der Preisgabe von Geheimnissen ist somit gewährleistet.
7. Durch Firewall-Richtlinien kann der Benutzer verpflichtet werden, nur über die Sitzung der Remote Browser Isolation auf die Ziel-Webanwendung zuzugreifen, wodurch die Bedrohung durch einen kompromittierten Browser oder lokale Geräte-Malware reduziert wird.
8. Die Ziel-Webanwendung wird durch Single Sign-On und/oder MFA-Authentifizierung geschützt, auch wenn die Anwendung dies nicht nativ unterstützt. Keeper schützt den Zugriff auf den Tresor und alle Sitzungen mit Remote Browser Isolation durch die in diesem Dokument beschriebenen erweiterten Authentifizierungsmethoden.

BreachWatch^®

Keeper betreibt eine verwaltete, in sich geschlossene Architektur auf AWS, die sich BreachWatch nennt. BreachWatch ist physisch getrennt von der Keeper-API und den Benutzerdatensätzen.

Ein physisches Hardware-Sicherheitsmodul (HSM) auf den BreachWatch-Servern verarbeitet, hasht und speichert Milliarden einzigartiger Passwörter aus Datendiebstählen, die im Darknet aufgetaucht sind. Alle Passwörter werden auf den Keeper-Servern mit dem HMAC_SHA512-Hash-Verfahren verarbeitet und im HSM mit einem nicht-exportierbaren Schlüssel gehasht.

Mit der Aktivierung von BreachWatch auf dem Client-Gerät wird ein HMAC_SHA512-Hash erstellt, der allen Datensätzen umfasst. Der Hash-Wert wird dann an den Server geschickt. Auf dem Server wird ein zweiter Hash-Wert erstellt, wofür HMAC_SHA512 im HSM mit dem nicht-exportierbare Schlüssel zum Einsatz kommt. Diese "Hashes-der-Hashes" werden verglichen, um zu ermitteln, ob Datensätze kompromittiert sind.

Die BreachWatch-Architektur wurde so angelegt, um eine Korrelation kompromittierter Passwörter mit Passwörtern aus Benutzertresoren zu verhindern, egal wie umfangreich der Datendiebstahl ist. Die Erkennung kompromittierter Passwörter nutzt ein physisches HSM, um zu gewährleisten, dass das Hashen nur Online durchgeführt werden kann. So werden Brute-Force-Angriffe auf die Daten verhindert.

• Die Passwörter werden mit HMAC_512 doppelt gehasht: Einmal auf dem Client-Gerät mit einem "Pepper" und einmal im AWS CloudHSM mit dem nicht-exportierbaren Schlüssel im Hardware-Sicherheitsmodul.
• HMAC_512 kommt zum Einsatz, da es eine starke Hashing-Funktion und einen geheimen, nicht-extrahierbaren Schlüssel bietet. Offline-Angriffe gegen die Hashes sind somit nicht praktikabel.
• Der Message Authentication Code (MAC) mit dem Ergebnis der kryptographischen Hash-Funktion erweitert die Nutzung von Hash-Funktionen. Die Ergebnisse des Codes basieren nicht nur auf der Nachricht, sondern auch auf einer zweiten Eingabe, bei der es sich um einen geheimen Schlüssel handeln kann.

BreachWatch wird zu 100 % von Keeper entwickelt und nutzt SpyCloud-Datenfeeds. Keeper sendet jedoch niemals Daten an Drittanbieter.

Domain-Überprüfung

BreachWatch-Kunden laden eine Domain-Liste herunter, bei denen Datendiebstähle stattgefunden haben, und führen eine Überprüfung lokal durch.

Überprüfung von Benutzernamen und Passwörtern

Geräte von Kunden sind mit den BreachWatch-Servern verbunden und laden eine Liste von gehashten Benutzernamen (oder Passwörtern) sowie vom Programm festgelegten, zufälligen Identifikatoren (getrennte Identifikatoren jeweils für Passwort- und Benutzernamen-Überprüfungsdienst) hoch. Diese Benutzernamen-Hashes werden nach dem Hochladen verarbeitet. Die Verarbeitung findet mit einem Keyed-Hash Message Authentication Code (HMAC) statt, für den ein Hardware-Sicherheitsmodul (HSM) und ein geheimer Schlüssel verwendet werden. Der Schlüssel ist im HSM als nicht-exportierbar markiert. Damit kann das HSM den HMAC nur lokal verarbeiten und der Schlüssel kann nicht extrahiert werden. Die HMAC-gesicherten Daten (Benutzernamen oder Passwörter) werden dann mit der Datenbank der gestohlenen Datensets verglichen, die ebenfalls mit einem HMAC und Sicherheitsschlüssel gesichert wurden. Über sämtliche Funde wird anschließend auf dem Gerät des Kunden informiert. Alle Werte, für die keine Übereinstimmungen gefunden wurden, werden mit der anonymisierten Programm-ID gespeichert.

Wenn neue gestohlene Benutzernamen und Passwörter in das System aufgenommen werden, werden diese ebenfalls mit dem HMAC im HSM verarbeitet, dann in die BreachWatch-Datenbank aufgenommen und mit den gespeicherten Kundendaten verglichen. Bei Treffern wird eine Benachrichtigung für die entsprechende Programm-ID veranlasst.

Die Programme stellen regelmäßig eine Verbindung zu BreachWatch her und übermitteln die IDs. Alle veranlassten Nachrichten werden heruntergeladen und neue oder geänderte Benutzernamen und Passwörter werden hochgeladen und auf dieselbe Art und Weise verarbeitet.

Die Sicherheitsvorkehrungen von BreachWatch-Diensten basieren auf dem Trust-On-First-Use-Prinzip (TOFU). Das bedeutet, dass das Programm annehmen muss, dass die BreachWatch-Server keine Schadserver sind (also nicht aktiv von Angreifern kompromittiert werden), wenn das Programm die Hash-Werte hochlädt. Sobald die Werte mit einem HSM verarbeitet wurden, sind sie gesichert gegen Offline-Cracking-Versuche. Mit anderen Worten: Wenn Angreifer Datensets mit gespeicherten Programmwerten stehlen, können sie diese Werte offline nicht aufbrechen, ohne den HMAC-Schlüssel des HSM zu kennen.

Wird ein gestohlenes Passwort entdeckt, sendet das Gerät eine Hash-Kombination für Benutzername+Passwort an die BreachWatch-Server, wo derselbe Vergleich des HMAC-Hash-Werts durchgeführt wird, um festzustellen, ob diese Kombination von Benutzername+Passwort beeinträchtigt ist. Ist dies der Fall, werden die Domains aus dem Datendiebstahl an das Gerät zurückgesendet, damit auf diesem überprüft werden kann, ob es eine Übereinstimmung für die Kombination Benutzername+Passwort+Domain gibt. Stimmen alle drei Parameter auf dem Gerät überein, wird der Benutzer über die Schwere des Datendiebstahls informiert.

BreachWatch für Business- und Enterprise-Kunden

Wird BreachWatch für Unternehmen aktiviert, werden die Passworttresore der Benutzer automatisch jedes Mal gescannt, wenn sich die Benutzer bei ihren Tresoren anmelden. Eine Zusammenfassung der BreachWatch-Daten zu den gescannten Benutzergeräten wird mit dem öffentlichen Schlüssel des Unternehmens verschlüsselt und vom Unternehmensadministrator entschlüsselt, wenn sich dieser bei der Keeper-Admin-Konsole anmeldet. Die verschlüsselten Daten enthalten E-Mail-Adressen, Anzahl riskanter Datensätze, Anzahl behobener Problemfälle und Anzahl ignorierter Problemfälle. Der Keeper-Administrator ist in der Lage, über die Admin-Konsole detaillierte Zusammenfassungen zu einzelnen Benutzern einzusehen.

Ereigniserfassung und Berichterstattung

Mit der Integration mit dem Modul "Erweiterte Berichte und Warnungen" können Keeper-Endbenutzergeräte optional so eingerichtet werden, dass sie detaillierte Daten zu Ereignissen in Echtzeit an SIEM-Lösungen von Drittanbietern und an die Keeper-Admin-Konsole übertragen. Die Ereignisdaten enthalten E-Mail-Adressen, einzigartige IDs von Datensätzen, IP-Adressen und Geräteinformationen. Ereignisse enthalten aber keinerlei verschlüsselte Datensätze, da Keeper auf die Zero-Knowledge-Sicherheitsarchitektur setzt und Benutzerdaten nicht entschlüsseln kann.

Standardmäßig werden detaillierte BreachWatch-Ereignisdaten nicht an das Modul "Erweiterte Berichte und Warnungen" oder externe Datenerfassungsdienste gesendet. Um deren Übertragung an das Modul "Erweiterte Berichte und Warnungen" zu aktivieren, müssen Sie die Rollendurchsetzungseinstellungen unter der entsprechenden Rolle aktivieren. Gehen Sie dazu zu Rolle > Durchsetzungseinstellungen > Tresor-Funktionen. Nachdem die Einstellung aktiviert wurde, beginnt das Endbenutzergerät mit der Übertragung von Ereignisdaten. Da Daten bei der Integration mit SIEM-Lösungen von Drittanbietern von den Keeper-Diensten an diese SIEM-Lösungen übertragen werden, können die Ereignisdaten von diesen gelesen werden und können dazu verwendet werden, um herauszufinden, welche Benutzer und Datensätze in der Organisation riskante Passwörter enthalten. Möchte der Keeper-Administrator keine Ereignisdaten an das Modul "Erweiterte Berichte und Warnungen" übertragen, kann die Einstellung auch deaktiviert bleiben.

Splunk Sumo Logic LogRhythm Syslog Push IBM QRadar Azure Sentinel AWS S3 Bucket Devo Datadog Logz.io Elastic

Offline-Modus

Der Offline-Modus erlaubt es Benutzern, auf ihren Tresor zuzugreifen, obwohl sie keine Verbindung zu Keeper oder ihrem SSO-Identitätsanbieter herstellen können. Die Funktion steht in der Mobil-App, Desktop-App von Keeper und im Web-Tresor auf allen Browsern zur Verfügung.

Das funktioniert, indem Keeper eine Kopie des Tresors auf einem lokalen Speichermedium anlegt. Die so gespeicherten Daten sind AES-GCM-verschlüsselt mit einer 256-Bit-Client-Verschlüsselung, die zufällig erstellt wird und durch PBKDF2-HMAC-SHA512 mit bis zu 1.000.000 Iterationen und zufälligem Salt geschützt ist. Das Salt und die Iterationen werden lokal gespeichert. Mit der Eingabe des Master-Passworts durch Benutzer wird ein Schlüssel aus dem Salt und den Iterationen abgeleitet und es wird versucht, die Client-Verschlüsselung zu entschlüsseln. Die Client-Verschlüsselung wird dann zur Entschlüsselung der lokal gespeicherten Datensätze verwendet. Sollte der Selbstzerstörungsschutz für den Tresor des Benutzers aktiviert sein, werden nach 5 Anmeldungsfehlversuchen alle lokal gespeicherten Tresordaten gelöscht. Für Unternehmenskunden können Keeper-Administratoren den Offline-Zugriff rollenbasiert einschränken.

Notfallzugriff (digitales Erbe)

In den persönlichen und Family-Abonnements von Keeper ist auch die Möglichkeit inbegriffen, bis zu fünf Notfallkontakte zu unterlegen, denen Zugriff auf den Tresor gewährt werden kann, wenn der Benutzer stirbt oder ein anderer Notfall eintritt. Der Nutzer legt eine Wartezeit fest und sobald diese abgelaufen ist, werden die Notfallkontakte darüber informiert, dass sie Zugriff auf den Tresor des Benutzers haben. Die Freigabe des Tresors für einen Notfallkontakt hält das Zero-Knowledge-Prinzip ein, da das Master-Passwort des Benutzers nicht weitergegeben wird. Zudem kommt eine 2048-Bit-RSA-Verschlüsselung mit einem 256-Bit-AES-Schlüssel zum Einsatz. Der Notfallkontakt muss ebenfalls ein Keeper-Konto besitzen, um die Daten annehmen zu können.

Netzwerkarchitektur

KSI benutzt Amazon AWS in Nordamerika (Kommerziell und GovCloud), Europa, Australien, Japan und Kanada für lokalisierten Datenschutz und geographische Trennung, um die Keeper-Lösung und deren Architektur zu hosten und zu betreiben. Keeper nutzt Amazon AWS für das Hosting und den Betrieb der Keeper-Lösung und deren Architektur. Amazon AWS ermöglicht Keeper die nahtlose Skalierung von Ressourcen anhand der jeweiligen Nachfrage und bietet Keeper-Kunden die schnellste und sicherste der verfügbaren Cloud-Speicherumgebungen. Keeper betreibt sowohl Multizonen- als auch Multiregionen-Umgebungen, um Verfügbarkeitszeiten zu maximieren und schnellstmögliche Reaktionszeiten zu gewährleisten. Kundendaten und Zugriffe auf die Plattform sind auf eine bestimmte Region beschränkt.

Cloud-Authentifizierung

Keeper hat ein hoch entwickeltes Cloud-Authentifizierungs- und -Netzwerkkommunikationsmodell entwickelt, das höchste Standards an Datenschutz, Sicherheit, Vertrauen und Transparenz erfüllt. Einige Schlüsselfunktionen des Authentifizierungsmodells sind:

• Master-Passwort wird nie über die Netzwerkebene übertragen. Anders als bei den meisten SaaS-Diensten verlassen Zugangsdaten bei Keeper nie das Gerät. PBKDF2 wird auf dem Gerät genutzt, um einen 256-Bit-AES-Schlüssel für die Entschlüsselung zu erstellen. Ein zweiter PBKDF2-Schlüssel wird lokal erstellt und mit HMAC_SHA256 gehasht, um einen Authentifizierungstoken zu erstellen. Keeper hat somit keinerlei Kenntnis über die Entschlüsselungscodes der Benutzer.
• Datenverkehr zwischen Client-Geräten und der Keeper-Cloud nicht abfangbar oder entschlüsselbar. Keeper verwendet Key-Pinning und zusätzliche Netzwerkverschlüsselung (Übertragungsschlüssel) für die Datenübertragung zwischen Gerät und Keeper-Servern, um MITM-Angriffe auszuschließen.
• Keine Anmeldung mit neuen Geräten ohne vorherige Verifizierung. Es kann kein Anmelde.ersuch für ein Konto gestartet werden, ohne diese anfängliche Verifizierung erfolgreich zu durchlaufen. Keeper unterstützt verschiedene Gerätebestätigungsverfahren, die sich am verwendeten Authentifizierungsverfahren orientieren.
• 2FA-Authentifizierung vor Master-Passwort-Eingabe. Hat ein Benutzer 2FA aktiviert oder wurde es vom Admin aktiviert, muss dieser Schritt erst durchgeführt werden, bevor das Master-Passwort eingegeben werden kann.
• Master-Passwort-Eingabe erst möglich nach erfolgreicher Geräteverifizierung und 2FA. Der Benutzer gelangt erst dann zur Master-Passwort-Eingabe, wenn zuvor die Gerätebestätigung und 2FA-Authentifizierung erfolgreich war. Dieses erweiterte Authentifizierungsverfahren schützt zuverlässig gegen häufige Cyberangriffsarten wie Brute-Force-Angriffe, Passwort-Spraying, Aufzählungsangriffe und MITM.

Verschlüsselung bei Datenübertragung

Der Keeper Cloud Security Vault wird durch API geschützt, die über die Autorisierung durch das Client-Gerät validiert werden. Der Client ruft bei der Anmeldung einen Sitzungstoken ab und überträgt ihn bei jeder API-Abfrage. Der Sitzungstoken wird vom Server überwacht. Die Anmeldung wird per Master-Passwort, Sitzungsfortsetzung oder SAML-2.0-konformer SSO-Authentifizierung durchgeführt.

Bei der Verwendung des Master-Passworts wird auf den Benutzergeräten wird mittels PBKDF2-HMAC-SHA256 und einem zufälligen 128-Bit-Salt aus dem Master-Passwort ein 256-Bit-Authentifizierungsschlüssel generiert. Der Authentifizierungs-Hash wird durch Hashing des Authentifizierungsschlüssels mittels SHA-256 generiert. Zur Anmeldung wird dieser Authentifizierungs-Hash mit dem Authentifizierungs-Hash verglichen, der im Cloud Security Vault hinterlegt ist. Nach der Anmeldung wird ein Sitzungstoken erstellt und vom Benutzergerät für weitere API-Anfragen verwendet. Für die dauerhafte Client-zu-Server-Kommunikation muss die Sitzung aktiv bleiben.

Keeper nutzt 256-Bit- und 128-Bit- TLS zur Verschlüsselung des gesamten Datentransports zwischen der Benutzeranwendung und Keeper-Cloudspeicherung.

Keeper nutzt TLS-Zertifikate, die von DigiCert mittels SHA2-Algorithmen signiert wurden. SHA2 ist der aktuell sicherste, von kommerziellen Signaturanbietern erhältliche Signatur-Algorithmus. SHA2 bietet beträchtlich mehr Sicherheit als das noch weit verbreitete SHA1, das mathematische Schwachstellen aufwies, die ausgenutzt werden konnten. SHA2 unterstützt Sie dabei, sich gegen die Ausstellung gefälschter Zertifikate zu schützen, mit denen Angreifer vorgeben könnten, eine bestimmte Webseite zu sein.

Keeper unterstützt Zertifikatstransparenz (Certificate Transparency, CT). Dabei handelt es sich um eine neue Initiative von Google, das eine öffentlich überprüfbare Datenbank aller von Zertifikatsanbietern signierten Zertifikate unterhält. CT verbessert den Schutz gegen die Ausstellung von Zertifikaten durch nicht autorisierte Organisationen. CT wird aktuell in der neuesten Version der Browser Chrome, Safari und Brave unterstützt. Weitere Informationen zu Zertifikatstransparenz erhalten Sie unter: http://www.certificate-transparency.org. Keeper unterstützt folgende TLS-Cipher-Suiten:

• TLS_AES_128_GCM_SHA256
• TLS_AES_256_GCM_SHA384
• TLS_CHACHA20_POLY1305_SHA256
• ECDHE-ECDSA-AES128-GCM-SHA256
• ECDHE-RSA-AES128-GCM-SHA256
• ECDHE-ECDSA-AES128-SHA256
• ECDHE-RSA-AES128-SHA256
• ECDHE-ECDSA-AES256-GCM-SHA384
• ECDHE-RSA-AES256-GCM-SHA384
• ECDHE-ECDSA-AES256-SHA384
• ECDHE-RSA-AES256-SHA384

Keeper Client-Geräte auf iOS und Android nutzen zudem Key Pinning, ein Sicherheitsmechanismus, der Nachahmungen durch Angreifer mithilfe von gefälschten Zertifikaten verhindern soll.

Verhinderung von Cross-Scripting-Angriffen (XSS)

Der Keeper-Webtresor bietet eine strikte Inhaltssicherheitsregel, die alle von außen kommenden Anfragen einschränkt und die Ausführung von Scripten blockiert, sofern sie nicht direkt von Keeper stammen. Zu den blockierten Script-Arten zählen Inline-Scripte und Event-Handler-HTML-Attribute. Mit diesen Vorkehrungen minimieren Sie das Risiko eines Cross-Site-Scripting-Angriffs.

Der Zugriff auf die Keeper-Domänen ist beschränkt auf HTTPS mit TLS 1.3, was durch HTTP Strict Transport Security umgesetzt wird. So wird eine große Bandbreite an Paket-Sniffing-, Datenmodifizierungs- und Man-In-The-Middle-Angriffen verhindert.

In der Keeper-Browsererweiterung wird Sie Keeper niemals auffordern, sich innerhalb eines Seiten-Frames beim Keeper-Tresor anzumelden. Die Anmeldung erfolgt ausschließlich in der Toolbar der Keeper-Browsererweiterung. Die Anmeldung bei Ihrem Tresor erfolgt im Browser entweder nur auf den Domänen keepersecurity.com, keepersecurity.eu, keepersecurity.com.au, keepersecurity.jp, keepersecurity.ca oder govcloud.keepersecurity.us oder in der Toolbar der Keeper-Browsererweiterung, die sich außerhalb des Inhaltsanzeigebereich des Browsers befindet.

Die Keeper-Browsererweiterung verwendet iFrames für die Injektion von Datensätzen auf den Anmeldeseiten von Webseiten. Somit soll verhindert werden, dass bösartige Webseiten Zugriff auf die eingefügten Daten erhalten. Per iFrame eingefügte Daten sind zudem auf die im Datensatz im Tresor gespeicherten Domänen der Zielwebseite beschränkt. Keeper wird AutoFill nur dann anbieten, wenn die Webseitendomäne mit den Daten im Tresordatensatz übereinstimmt. Die Erweiterung wird keine Datensätze anzeigen, wenn die Webseiten-Root-Domäne nicht mit den im Datensatz gespeicherten Informationen übereinstimmt.

Erweiterungen von Drittanbietern verfügen möglicherweise über höhere Berechtigungen im Browser und können auf Daten in einer Webseite zugreifen. Wir empfehlen daher, dass Keeper-Administratoren die Installation von nicht genehmigten Erweiterungen im Browser aus den Erweiterungsbibliotheken der Browseranbieter durch Benutzer verhindern.

Biometrische Daten

Keeper unterstützt nativ Windows Hello, Touch ID, Face ID und biometrische Anmeldung bei Android. Kunden, die sich sonst mit ihrem Master-Passwort oder per Enterprise SSO-Login (SAML 2.0) in ihrem Keeper-Tresor anmelden, können sich auch mit einem biometrischen Merkmal bei ihren Geräten anmelden. Der Keeper-Administrator muss diese Anmeldeform in der Rollenrichtlinie aktivieren. Sofern die Funktion aktiviert ist, kann der Offline-Zugriff sowohl für Master-Passwort- als auch für SSO-aktivierte Benutzer auch mittels einer Biometrie ermöglicht werden.

Wenn die biometrische Anmeldung auf einem Gerät aktiviert ist, wird lokal ein zufallsgenerierter Schlüssel erzeugt und in der Secure Enclave (z. B. Schlüsselbund, KeyStore) des Geräts gespeichert. Der Datenschlüssel des Benutzers wird mit dem biometrischen Schlüssel kodiert. Nach erfolgreicher biometrischer Authentifizierung wird der Schlüssel abgerufen und der Benutzer kann seinen Tresor entschlüsseln.

iOS-Schlüsselbund, Touch ID und Face ID

Touch ID und Face ID für iOS-Geräte erlauben es Ihnen, mittels biometrischer Merkmale auf Ihren Keeper-Tresor zuzugreifen. Für die Nutzung dieser komfortablen Funktion wird ein zufallsgenerierter biometrischer 256-Bit-Schlüssel in Ihrem iOS-Schlüsselbund gespeichert. Dieser besondere Schlüssel in Ihrem iOS-Schlüsselbund wird nicht mit dem iCloud-Schlüsselbund synchronisiert und verlässt somit nie ihr iOS-Gerät.

Wir empfehlen Ihnen dringlichst ein komplexes Master-Passwort zu verwenden und Mehr-Faktor-Authentifizierung zu aktivieren, um die höchstmögliche Sicherheit für Ihren Keeper-Datentresor zu garantieren. Touch ID und Face ID machen die Verwendung eines komplexen Master-Passwortes auf Ihrem mobilen iOS-Gerät noch einfacher. Darüber hinaus empfehlen wir zur Verschlüsselung des iOS-Schlüsselbundes die Verwendung eines Codes, der mehr als die vorgeschriebenen vier Ziffern enthält.

Der iOS-Schlüsselbund wird von iOS und anderen Anwendungen genutzt, um Anmeldedaten sicher zu speichern. iOS-Apps nutzen den Schlüsselbund, um verschiedene sensible Informationen zu speichern, darunter Webseitenpasswörter, Kreditkartendaten und Apple Pay-Informationen. Keeper nutzt den iOS-Schlüsselbund nicht, um Ihre Keeper-Datensätze dort zu speichern. Alle Ihre Keeper-Datensätze werden mit einer 256-Bit-AES-Verschlüsselung geschützt und sicher im Keeper-Tresor gespeichert. Der iOS-Schlüsselbund wird ebenfalls mit einer auf dem Passcode basierenden 256-Bit-AES-Verschlüsselung geschützt. Sollten Sie Ihr Gerät verlieren oder sollte es gestohlen werden oder sollten Angreifer physisch Zugriff auf Ihr Gerät erhalten, können Sie trotzdem nicht auf Ihre gespeicherten Keeper-Daten zugreifen. Der iOS-Schlüsselbund kann nicht ohne den Passcode entschlüsselt werden und Ihr Keeper-Tresor kann nicht ohne Ihr Master-Passwort für Keeper entschlüsselt werden.

Apple Watch^®

Die Apple Watch Favoriten-Funktion ermöglicht die Darstellung ausgewählter Datensätze auf einer gekoppelten Apple Watch. Die Keeper-Datensätze müssen ausdrücklich zur Ansicht auf der Apple Watch freigegeben sein. Eine gekoppelte Apple Watch kommuniziert mit der Keeper Uhren-Erweiterung, die separat in einem von der iOS Keeper App abgetrennten Bereich ausgeführt wird. Die Keeper Uhren-Erweiterung verwendet ebenfalls den iOS-Schlüsselbund zur sicheren Speicherung und Zugriff auf Schlüssel, um reibungslos und sicher mit der iOS Keeper App zu kommunizieren.

Keeper DNA^®

Keeper DNA ist ein Mehr-Faktor-Authentifizierungsverfahren, für das eine Smartwatch zum Einsatz kommt. Keeper DNA verwendet sichere im Keeper-Datentresor gespeicherte Token, um zeitbasierte Codes zur Mehr-Faktor-Authentifizierung zu erstellen. Diese zeitbasierten Authentifizierungsanfragen können mit einem Fingertippen auf den Bildschirm von der Apple Watch oder Android Wear-Geräten aus bestätigt und automatisch gesendet oder vom Benutzer manuell eingegeben werden.

Mitarbeiter-Offboarding (Tresorübertragung)

Bei der Aktivierung eines Kontoübertragungsprotokolls für einen Knoten wird eine Knotenrichtlinie für ein Öffentlich/Privates-Schlüsselpaar in der Admin-Konsole des Benutzergeräts erstellt. Der Endbenutzer-Datenschlüssel (für Benutzer, für die die Rollendurchsetzung angewendet wird) wird mit den öffentlichen Schlüssel der Richtlinie kodiert, wenn sich ein Benutzer im Tresor anmeldet. Der private Schlüssel wird mit dem öffentlichen Schlüssel des Admins verschlüsselt. Der Admin kann den Rollendurchsetzungsschlüssel bei der Tresorübertragung entschlüsseln.

Für die Tresorübertragung muss der Admin zuerst das betreffende Benutzerkonto sperren. Danach kann die Tresorübertragung sofort durchgeführt und das Benutzerkonto gelöscht werden. Damit ist sichergestellt, dass die Aktion nicht im Geheimen ausgeführt werden kann. Bei einer Übertragung wird der Benutzer-Datenschlüssel abgerufen, indem zuerst der Rollendurchsetzungsschlüssel entpackt und anschließend der Benutzer-Datenschlüssel entpackt werden. Mit dem Datenschlüssel werden die Datensatzschlüssel, Teamschlüssel und Ordnerschlüssel entpackt.

Die Verschlüsselung findet ausschließlich auf dem Gerät in der Admin-Konsole statt und Keeper hat zu keiner Zeit die Möglichkeit, die freigegebenen oder übertragenen Daten zu entschlüsseln. Weiterhin wird der Benutzer-Datenschlüssel niemals weitergegeben. Ein aus einem Team, einem freigegebenen Ordner oder einer Direktfreigabe entfernter Benutzer erhält keine neuen Daten von dem Team, freigegebenen Ordner oder Datensatz. Obwohl die Datensatz-, Ordner- und Teamschlüssel für den Admin während des Vorgangs lokal verschlüsselt werden, können sie nicht genutzt werden, um Zugriff auf die jeweiligen Datensätze oder Ordnerdaten zu erlangen.

Während der Ordnerübertragung erhält der Admin nur den verschlüsselten Datenschlüssel und die verschlüsselten Datensatz- und Ordnerschlüssel. Der Admin dekodiert diese Schlüssel und kodiert sie danach mit dem öffentlichen Tresorschlüssel. Dabei erhalten Sie nie Zugriff auf tatsächliche Datensatzdaten. Keeper verschlüsselt keine gespeicherten Daten im Datenschlüssel. Das geschieht ausschließlich auf dem Benutzergerät.

Zertifizierungen und Compliance

Keeper ist regelrecht fanatisch, wenn es um Sicherheit geht. Keeper ist die zertifizierte, getestete und geprüfte Passwort-Sicherheitslösung und Privileged-Access-Management-Plattform mit der höchsten Sicherheit der Welt. Es verfügt über die am längsten erhaltenen SOC 2- und ISO-Zertifizierungen der Branche und ist nach ISO 27001, 27017 und 27018 zertifiziert. Keeper ist regelkonform mit der DSGVO, CCPA und HIPAA und zudem von der FedRAMP und StateRAMP autorisiert sowie nach PCI DSS zertifiziert und von TrustArc für Datenschutz zertifiziert.

• Die Keeper-Entwicklerteams bestehen aus festangestellten Mitarbeitenden in den USA.
• Keeper speichert keine Passwörter, Zugangsdaten oder IT-Geheimnisse im Quellcode. Wir überprüfen unseren Programmcode dahingehend regelmäßig.
• Der Keeper-Quellcode wird privat in GitHub Enterprise verwahrt. Er enthält keinerlei Informationen, um auf einen Benutzertresor zugreifen zu können. Sämtliche Datenverschlüsselungsvorgänge finden auf den Geräten selbst statt. Große Teile des Quellcodes sind in unserm öffentlichen GitHub-Repository einsehbar, etwa die Produkte Keeper Commander und Secrets Manager.
• Keeper bindet keine MFA-Drittanbieterprodukte in seinen Apps ein. Keeper Partner sind noch nie Opfer von Datenpannen gewesen, von denen Keeper betroffen wäre.
• Keeper erlaubt Drittanbietern keinen Zugriff auf unser AWS-Datenzentren. Sämtliche Arbeiten dort werden von festangestellten Mitarbeitenden von Keeper Security durchgeführt, bei denen es sich um US-Bürger handelt, die in den USA arbeiten und leben.

Gemäß FIPS 140-3 zertifiziert

Keeper verwendet nach FIPS 140-3 validierte Verschlüsselungsmodule, um die strengen Sicherheitsanforderungen von Regierungsbehörden und anderen Ämtern zu erfüllen. Die Verschlüsselungsverfahren von Keeper wurden im Rahmen des NIST Cryptographic Module Validation Program (CMVP) zertifiziert und durch akkreditierte Labore für den Standard FIPS 140-3 validiert.

Keeper verwendet eine nach FIPS 140-3 validierte Verschlüsselung, die mit dem Zertifikat Nr. 4743 des NIST CMVP ausgezeichnet wurde.

ITAR-konform

Keeper Security Government Cloud (KSGC) erfüllt die Bestimmungen der United States International Traffic in Arms Regulations (ITAR). Unternehmen, die den ITAR-Exportbestimmungen unterliegen, müssen unbeabsichtigte Exporte kontrollieren, indem sie den Zugriff auf geschützte Daten auf US-Personen beschränken und geschützte Daten nur an US-Standorten aufbewahren.

Die FedRAMP-Moderate-Umgebung von KSGC unterstützt ITAR-Anforderungen mit folgenden Merkmalen:

• Vollständig konformer Datenspeicher, der auf AWS GovCloud gehostet wird und auf die USA beschränkt ist.
• KSGC bietet sichere Datenverschlüsselung für gespeicherte und übertragene Daten.
• Mittels Zero-Knowledge- und Zero-Trust-Sicherheit in Verbindung mit granularen Berechtigungen können Organisationen sicherstellen, dass nur autorisiertes Personal auf sensible Daten zugreifen kann.
• Robuste Konformitätsüberprüfungsfunktionen bieten eine nachvollziehbare elektronische Prüfmethode aller durchgeführten Aktionen und eingegebenen Daten.
• Das Sequestered Customer Success Team besteht aus US-Personen, die speziell im sicheren Umgang mit exportbeschränkten und ITAR-kontrollierten Daten geschult sind. Unterstützung von Nicht-US-Personen gibt es nicht.

Die Keeper-FedRAMP-Umgebung wurde von einem unabhängigen, externen Überprüfungsunternehmen (3PAO) dahingehend geprüft und validiert, dass angemessene Kontrollen durchgeführt werden, um Exportbestimmungseinhaltung bei Kunden zu gewährleisten. Keeper wird jährlich geprüft, um die Einhaltung der Bestimmungen zu validieren.

Hier finden Sie weitere Informationen zu ITAR.

FedRAMP-geprüft

KSGC ist die Passwortverwaltungs- und Cybersicherheitsplattform von Keeper Security für Behörden und die öffentliche Verwaltung. KSGC ist ein FedRAMP-autorisierter Anbieter für das Moderate Impact Level und wird in den USA auf AWS GovCloud gehostest. KSGC finden Sie im FedRAMP Marketplace.

Das Federal Risk and Authorization Management Program (FedRAMP) ist ein Programm der US-Bundesregierung, das einen standardisierten Ansatz für die Sicherheitsbewertung, Autorisierung und kontinuierliche Überwachung von Cloud-Produkten und -Diensten bietet. Mit FedRAMP soll die Nutzung und Einführung moderner Cloud-Anwendungen in Regierungsbehörden vorangetrieben werden. Dabei liegt der Schwerpunkt auf der Sicherheit und dem Schutz von Bundesinformationen. Hier erfahren Sie mehr zu FedRAMP.

Autorisiert für StateRAMP

StateRAMP wurde etwa zehn Jahre nach FedRAMP entwickelt und sollte die Nutzung und Einführung von sicheren Cloud-Produkten auf bundesstattlicher und regionaler Verwaltungsebene fördern. Der Autorisierungsprozess für StateRAMP dauert in der Regel zwei Jahre, konnte bei Keeper dank der bereits bestehenden FedRAMP-Autorisierung aber beschleunigt werden.

Mit SOC 2 konform

Die Tresordaten von Kunden bleiben mittels strenger und umfassend überwachter interner Kontrollmethoden geschützt. Keeper besitzt seit über 10 Jahren die Zertifizierung für SOC 2 Typ 2-konform gemäß den Vorschriften der AICPA Service Organization. Die SOC-2-Einhaltung hilft dabei, Datentresore von Benutzern anhand der Implementierung standardisierter Kontrollen zu sichern, wie sie im Rahmen der AICPA Trust Service Principles vorgegeben werden.

ISO-Zertifizierungen

Keeper ist nach ISO 27001, 27017 und 27018 zertifiziert und deckt das Keeper Security Information Management System und die Cloud-Infrastruktur ab, die die Keeper Enterprise Platform unterstützt. Zu den ISO-Zertifizierungen von Keeper gehören die Verwaltung und der Betrieb des digitalen Tresors und der Cloud-Dienste, Cloud-Sicherheitskontrollen, Datenschutzkontrollen, Software- und Anwendungsentwicklung sowie der Schutz digitaler Vermögenswerte sowohl für den digitalen Tresor als auch für die Cloud-Dienste.

Nach FDA 21 CFR Part 11 zertifiziert

Keeper ist nach FDA 21 CFC Part 11 zertifiziert. Dieser Standard gilt für Wissenschaftler, die in stark regulierten Umgebungen arbeiten, etwa bei klinischen Studien. Der Standard spezifiziert FDA-Kriterien, die elektronische Aufzeichnungen und Signaturen erfüllen müssen, um als vertrauenswürdig, zuverlässig und Äquivalent zu Papierdokumenten mit handschriftlichen Unterschriften zu gelten. Wissenschaftler müssen insbesondere gewährleisten, dass alle Software die Regulierungen als 21 CFR Part 11 einhalten. Diese umfassen:

Sicherheitskontrollen bei der Benutzeridentifikation: Keeper erfüllt die Anforderungen von 21 CFR Part 11 für Sicherheitsfunktionen, die den Benutzerzugriff und ihre Berechtigungen einschränken. Dazu zählt die Sicherstellung, dass alle Benutzer einzigartige Benutzernamen und Passwörter haben müssen; die Möglichkeit, nicht autorisierte Systemzugriffe zu erkennen und zu verhindern; und die Möglichkeit, kompromittierte Konten zu sperren.

Detaillierter Prüfpfad

Bei einer FDA-Inspektion verlangen Prüfer der Behörde von Wissenschaftlern lückenlose Überprüfungsaufzeichnungen mit chronologischen Daten zu allen Operationen. Keepers Überprüfungsberichtsfunktion ermöglicht es Wissenschaftlern, unkompliziert leicht nachverfolgbare elektronische Überprüfungsprotokolle anzufertigen.

Elektronische Signaturen

Erfordert ein Dokument eine rechtsverbindliche elektronische Unterschrift, muss diese Unterschrift nach 21 CFR Part 11 an eine einzigartige Anmeldename-Passwort-Kombination oder biometrische Identifikation gebunden sein. Keeper ermöglicht die Erfüllung dieser Anforderung, in dem Wissenschaftler für alle Benutzer einzigartige Benutzernamen und Passwörter vergeben können, die sicher im digitalen Tresor gespeichert werden, auf den nur die Benutzer selbst Zugriff haben.

Weitere Informationen rund um 21 CFR Part 11 finden Sie hier.

Schutz der medizinischen Daten von Patienten

Die Keeper-Software entspricht den globalen Standards zum Schutz medizinischer Daten und deckt ohne Beschränkung den HIPAA (Health Insurance Portability and Accountability Act) und DPA (Data Protection Act) mit ab.

HIPAA-Konformität und Partnervereinbarungen

Keeper ist eine nach SOC2 und ISO 27001 zertifizierte und HIPAA-konforme Zero-Knowledge-Sicherheitsplattform. Dank strenger Einhaltung und Kontrolle bei Datenschutz werden Vertraulichkeit, Integrität und Verfügbarkeit der Daten stets sichergestellt. Aufgrund unserer Sicherheitsarchitektur hat Keeper selbst keine Möglichkeit, Daten (einschließlich geschützter elektronischer Gesundheitsdaten), die in den Keeper-Tresoren der Benutzer gespeichert sind, zu entschlüsseln, anzusehen oder darauf Zugriff zu erlangen. Aus diesen genannten Gründe ist Keeper kein Geschäftspartner im Sinne der Definition des HIPAA-Gesetzes (Health Insurance Portability and Accountability Act) und unterliegt deswegen keiner Partnervereinbarung.

Wenn Sie mehr über weitere Vorzüge für Gesundheitsdienstleister und Krankheitsversicherungen erfahren möchten, lesen Sie sich unsere gesamte Sicherheitsmitteilung durch und schauen Sie in unseren Enterprise-Anleitung.

FSQS-NL-zertifiziert

Keeper Security EMEA Limited ist zertifiziert nach Hellios Financial Services Qualification System-Netherlands (FSQS-NL). Das Zertifikat erkennt die höchsten Standards bei Sicherheit, Qualität und Innovationen in den Niederlanden an. Der Standard bezeugt Konformität mit Vorgaben der Finanzdienstleistungsaufsicht und Finanzaufsichtsbehörde, die die Vertrauenswürdigkeit von Keeper-Enterprise-Software für große Banken und Finanzinstitute garantieren.

Lizenzierte Ausfuhr unter EAR des US-Handelsministeriums

Keeper ist durch das U.S. Department of Commerce Bureau of Industry and Security unter der Export Commodity Classification Control Number 5D992 und unter Einhaltung der Export Administration Regulations (EAR) zertifiziert.
Mehr Informationen zu EAR finden Sie unter https://www.bis.doc.gov.

Remote-Überwachung rund um die Uhr

Keeper wird gas ganze Jahr über rund um die Uhr von DevOps-Mitarbeitern und einem externen, globalen Monitoringnetzwerk überwacht. Dadurch wird sichergestellt, dass unsere Website und der Cloud Security Vault weltweit verfügbar sind.

Sollten Sie Fragen bezüglich dieser Sicherheitsinformationen haben, bitten wir Sie uns zu kontaktieren.

Phishing- oder gefälschte E-Mails

Wenn Sie eine E-Mail, die angeblich von Keeper Security gesendet wurde, erhalten und unsicher sind, ob das tatsächlich der Fall ist, könnte es sich dabei um eine "Phishing-E-Mail" handeln, bei der die Absender-Adresse gefälscht oder manipuliert wurde. In diesem Fall könnte die E-Mail Links zu einer Website enthalten, die wie KeeperSecurity.com aussieht, aber nicht ist. Die Website könnte Sie nach Ihrem Keeper Security-Master-Passwort fragen oder versuchen unerwünschte Software auf Ihrem Computer zu installieren, um persönliche Daten zu stehlen oder auf Ihren Computer zuzugreifen. Andere E-Mails könnten Links enthalten, die Sie auf andere, potentiell gefährliche Websites weiterleiten. Der Nachricht könnten ebenfalls Anhänge beigefügt sein, die in der Regel unerwünschte Software, sogenannte "Schadsoftware", enthalten. Falls Sie sich bei einer E-Mail in Ihrem Posteingang nicht sicher sind, sollten Sie diese löschen, ohne vorher auf enthaltene Links zu klicken oder Anhänge zu öffnen.

Wenn Sie eine E-Mail, die angeblich von Keeper ist, von der Sie aber denken, dass es sich um eine Fälschung handelt, melden möchten oder weitere Sicherheitsfragen zu anderen Themen haben, bitte wir Sie uns zu kontaktieren.

Zertifizierte Hosting-Infrastruktur mit höchsten Branchenstandards

Die Keeper Website und Cloudspeicherung läuft auf der sicheren Cloudcomputing-Infrastruktur von Amazon Web Services (AWS). Die AWS Cloud-Infrastruktur, auf der Keepers Systemarchitektur aufbaut, erhielt die folgenden Bescheinigungen, Prüfberichte und Zertifizierungen:

Meldung von Schwachstellen und Bug-Bounty-Programm

Keeper hat das Ziel, die weltweit sichersten Passwort- und Privilegienzugriffs- und -verwaltungsanwendungen zu entwickeln. Keeper nimmt die Sicherheit und den Schutz Ihrer Daten äußerst ernst und ist dem Schutz Ihrer persönlichen Daten verpflichtet. Die Mission von Keeper ist die Schaffung der weltweit am besten geschützten und innovativsten Sicherheits-Apps. Aus diesem Grund glauben wir, dass Fehlerberichte unserer weltweiten Gemeinschaft von Sicherheitsforschern einen wertvollen Beitrag zur Gewährleistung der Sicherheit von Keeper-Produkten und -Diensten leisten kann.

Keeper führt rigorose interne Überprüfungen durch und kooperiert mit externen Sicherheitsexperten wie der NCC Group, CyberTest und unabhängigen Sicherheitsfachleuten, um alle Anwendungen und Systeme periodisch etwa mit Penetrationstests überprüfen zu lassen. Keeper unterhält sein eigenes Schwachstellenveröffentlichungsprogramm und Bug-Bounty-Programm in Kooperation mit Bugcrowd. Zusammengenommen unterstützt das die ganze Branche und wirkt sich positiv auf die Gesellschaft aus.

Richtlinien

In unseren Schwachstellen-Bekanntmachungsrichtlinien führen wir unsere Erwartungen auf, die wir an verantwortungsvolle Hacker stellen, und was Sie als verantwortungsvolle Hacker von uns erwarten können.

Werden Sicherheitstests und -überprüfungen unter Einhaltung dieser Richtlinien durchgeführt, dann:

• Betrachten wir diese im Rahmen des Computer Fraud and Abuse Act als autorisiert.
• Sind sie von den Bestimmungen des DMCA ausgenommen und es werden keine Forderungen wegen Verstößen gegen oder Umgebung von Sicherheits- und Technologiebeschränkungen gegen Sie geltend gemacht.
• Betrachten wir sie als legalen Vorgang und werden keine rechtlichen Schritte im Rahmen des Programms gegen Sie einleiten.
• Arbeiten wir mit Ihnen zusammen, um eventuelle Probleme besser zu verstehen und schnell zu beheben.
• Erkennen wir Ihre Beiträge öffentlich an, wenn Sie ein Problem als erstes melde und eine Code- oder Konfigurationsänderung zur Behebung des Problems vorschlagen.

Sollten Sie Bedenken oder Unsicherheiten zum Testvorgang haben, der diesen Testrichtlinien folgt, kontaktieren Sie uns bitte unter security@keepersecurity.com, bevor Sie fortfahren.

Um das verantwortungsvolle Testen und Veröffentlichen von Sicherheitsschwachstellen zu ermöglichen, bitten wir Sie,

• Vermeiden Sie es, die Privatsphäre oder das Benutzungserlebnis anderer Nutzer oder Produktions- und Unternehmenssysteme zu stören und/oder zu zerstören.
• Forschungsaktivitäten werden ausschließlich im Rahmen des Bugcrowd-Schwachstellen-Offenlegungsprogramms (Link unten) durchgeführt. Systeme und Aktivitäten außerhalb dieses Rahmens werden nicht berührt,
• Kontaktieren Sie uns umgehend unter security@keepersecurity.com, falls Sie auf irgendwelche Benutzerdaten während Ihres Tests zugreifen können.
• Geben Sie uns bitte einen angemessenen Zeitraum, in dem wir Ihren Fund analysieren, bestätigen und beheben können, bevor Sie diesen öffentlich bekannt machen.

Melden Sie Fehler bitte über https://bugcrowd.com/keepersecurity

Transparenz

Keeper ist Sicherheit nicht nur wichtig, es ist ein geradezu fanatisches Anliegen von uns. Deshalb geben wir sämtliche Details zu unserem Verschlüsselungsverfahren öffentlich bekannt. Wir glauben daran, dass unsere Kunden wissen sollten, wie ihre Daten in einer sich stetig verändernden Cybersicherheitswelt geschützt werden.

Keepers Zero-Knowledge- und Zero-Trust-Verschlüsselungsverfahren gewährleistet, dass Ihr Keeper-Tresor selbst im schlimmstmöglichen Fall geschützt bleibt. Wir führen dazu kontinuierlich Sicherheitstests durch, um garantieren zu können, dass wir die sicherste Lösung zum Schutz Ihrer wertvollen Daten sind.

Produktdokumentation

Das Dokumentationsportal von Keeper mit Produkthandbüchern, technischen Daten, Versionshinweisen und Guides für Endnutzer finden Sie hier.

Versionshinweise zum Produkt

Zur Steigerung der Transparenz veröffentlicht Keeper umfassende Versionshinweise für jede Plattform.

Systemstatus

Echtzeit-Statusdaten finden Sie hier.