Keeper is zeer enthousiast als het gaat over de beveiliging van inloggegevens en gegevensbescherming

Overzicht

Keeper Security, Inc. vindt de bescherming van de informatie van haar klanten met de mobiele en desktopbeveiligingssoftware van Keeper enorm belangrijk. Miljoenen consumenten en bedrijven vertrouwen op Keeper voor de beveiliging van en toegang tot hun wachtwoorden en privégegevens.

De software van Keeper wordt voortdurend verbeterd en bijgewerkt om onze klanten de nieuwste technologie en bescherming te bieden. Deze pagina biedt een overzicht van de beveiligingsarchitectuur, coderingsmethoden en hostingomgeving van Keeper vanaf de huidige gepubliceerde versie. In dit document wordt een overzicht gegeven van de technische details met betrekking tot onze coderings- en beveiligingsmethoden.

Ons Privacybeleid en onze Gebruiksvoorwaarden zijn beschikbaar op onze website via de volgende links:

Zero-trust platform

Keeper maakt gebruik van een zero-trust architectuur, die ervoor zorgt dat elke gebruiker moet worden geverifieerd en geauthentiseerd voordat ze toegang krijgen tot een website, applicatie of systeem.

Keeper Enterprise Password Management (EPM) geeft bedrijven totale zichtbaarheid en controle over de wachtwoordpraktijken van hun werknemers, zodat IT-beheerders het wachtwoordgebruik kunnen controleren en best practices op het gebied van beveiliging kunnen afdwingen.

Keeper Secrets Manager (KSM) biedt engineeringteams een platform voor het beheren van alle aanmeldingsgegevens (inclusief infrastructuurgeheimen, SSH-sleutels, API-sleutels en certificaten met SDK's en CI/CD-integratie).

Keeper Connection Manager (KCM) is een remote desktop gateway die DevOps- en IT-teams moeiteloze Zero-Trust Network Access (ZTNA) biedt tot RDP, SSH, databases, interne webapplicaties en Kubernetes-eindpunten via een webbrowser – geen agent vereist.

Keeper's beste beveiliging in detail

Versleuteling van kluisgegevens

Keeper biedt een meerlaags versleutelingsmodel op basis van de laagste rechten. Er worden 256-bits AES-sleutels op recordniveau en sleutels op mapniveau gegenereerd op het clientapparaat, waarmee elke opgeslagen kluisrecord wordt versleuteld. De kluisrecords en alle inhoud zijn volledig versleuteld, inclusief aanmeldingen, bestandsbijlagen, TOTP-codes, betalingsinformatie, URL's en aangepaste velden.

Coderingssleutels worden lokaal op het apparaat gegenereerd om 'zero knowledge' te behouden en geavanceerde functies zoals het delen van bestanden en mappen te ondersteunen. 'Zero-knowlegde' oftewel nulkennis, houdt in dat alle gebruikers volledige controle hebben over de versleuteling en ontcijfering van alle persoonlijke informatie in hun Keeper Vault en dat geen van de opgeslagen informatie toegankelijk is voor anderen, zelfs niet voor Keeper-medewerkers.

Recordsleutels en mapsleutels worden versleuteld met een 256-bits AES-gegevenssleutel die uniek is voor elke gebruiker en wordt gegenereerd op het apparaat van de gebruiker.

Op het apparaat van de gebruiker wordt nog een 256-bits AES-clientsleutel gegenereerd voor het versleutelen van een lokale offline cache (als de bedrijfsbeheerder offline toegang toestaat). Tot slot wordt de 256-bits AES-gegevenssleutel versleuteld met een andere sleutel, zoals beschreven in de volgende sectie.

Kluisversleutelingsmethoden

Keeper versleutelt gegevens op verschillende manieren, afhankelijk van hoe gebruikers zich aanmelden. Voor consumenten en leden van een gezinsabonnement worden een hoofdwachtwoord en biometrische verificatie gebruikt. Voor zakelijke gebruikers die zich aanmelden met SSO, gebruikt Keeper elliptische curveversleuteling voor een veilige ervaring zonder wachtwoord.

Voor gebruikers die zich aanmelden met een hoofdwachtwoord: De sleutel voor het ontcijferen en versleutelen van de gegevenssleutel wordt afgeleid van het hoofdwachtwoord van de gebruiker met behulp van de wachtwoordgebaseerde sleutelvariatiefunctie (PBKDF2), met 1.000.000 iteraties. Nadat gebruikers hun hoofdwachtwoord hebben getypt, wordt de sleutel lokaal afgeleid en wordt de gegevenssleutel uitgepakt. De gegevenssleutel wordt ontcijferd en gebruikt om de individuele record- en mapsleutels uit te pakken. De ontcijfering van elke sleutel slaat de recordinhoud lokaal op het apparaat van de gebruiker op.

Voor gebruikers die inloggen met SSO of wachtwoordloze technologie: Elliptic Curve Cryptography wordt gebruikt om gegevens op apparaatniveau te versleutelen en te ontcijferen. Een lokale ECC-256 (secp256r1) privésleutel wordt gebruikt om de gegevenssleutel te ontcijferen. Nadat de gegevenssleutel is ontcijferd, wordt deze gebruikt om de individuele record- en mapsleutels uit te pakken. De recordsleutel ontcijfert dan elk van de opgeslagen recordinhoud. De versleutelde gegevenssleutel wordt tussen de apparaten van de gebruiker verzonden via een pushsysteem of sleuteluitwisselingsservice, wat apparaatgoedkeuring wordt genoemd. Om zero-knowledge te behouden, wordt apparaatgoedkeuring lokaal beheerd door de eindgebruiker.

SSO-versleutelingsmodel

Eerste apparaatstroom (toevoegen van nieuwe gebruiker)

1. De gegevenssleutel, het sleutelpaar voor delen en het openbaar/privé EC sleutelpaar van het apparaat worden gegenereerd
2. De gegevenssleutel wordt versleuteld met de openbare sleutel van de EC van het apparaat en opgeslagen in de cloud (DEDK)
3. Gebruikers melden zich aan bij hun identiteitsprovider (IdP)
4. Na aanmelding bij de IdP wordt de ondertekende SAML-bevestiging geverifieerd door Keeper
5. De kluis wordt aangemaakt en de gebruiker wordt toegevoegd

Bestaande apparaatstroom

1. Gebruikers melden zich aan bij hun identiteitsprovider (IdP)
2. Na aanmelding bij de IdP wordt de ondertekende SAML-bevestiging geverifieerd door Keeper
3. Keeper levert de door het apparaat versleutelde gegevenssleutel (DEDK) aan de gebruiker
4. De gegevenssleutel wordt ontcijferd met de privé-EC-sleutel van het apparaat
5. De gegevenssleutel ontcijfert de map- en recordsleutels
6. Recordsleutels ontcijferen de recordinhoud

Nieuwe of onbekende apparaatstroom

1. Op elk nieuw apparaat wordt een privé/openbaar EC-sleutelpaar gegenereerd
2. Gebruikers melden zich aan bij hun identiteitsprovider (IdP)
3. Na aanmelding bij de IdP wordt de ondertekende SAML-bevestiging geverifieerd door Keeper
4. Het apparaat is 'goedgekeurd' via Keeper Push, goedkeuring door de beheerder of de Keeper Automator-service (*zie Apparaatgoedkeuring hieronder)
5. Tijdens het goedkeuringsproces wordt de gegevenssleutel versleuteld met de openbare sleutel van het nieuwe apparaat
6. De door het apparaat versleutelde gegevenssleutel (DEDK) wordt naar de gebruiker gestuurd

Apparaatgoedkeuring

• Een apparaatgoedkeuring is een mechanisme om de gegevenssleutel van de gebruiker veilig af te leveren op hun nieuwe apparaat met behoud van zero-knowledge.
• Gebruikers kunnen hun apparaat goedkeuren door de gegevenssleutel te versleutelen met de openbare sleutel van het nieuwe apparaat
• Een beheerder kan het apparaat goedkeuren vanuit de Beheerdersconsole, Commander of de Keeper Automator-service
• De beheerder ontcijfert de gegevenssleutel van de gebruiker en versleutelt de gegevenssleutel opnieuw met de openbare sleutel van het nieuwe apparaat
• De Keeper Automator-service kan geautomatiseerde apparaatgoedkeuringen uitvoeren op de infrastructuur van de klant
• Keeper Automator controleert de SAML-handtekening, pakt de gegevenssleutel uit en versleutelt de gegevenssleutel met de openbare sleutel van het nieuwe apparaat

Lees meer over de Keeper Automator-service.

Beveiliging op apparaatniveau voor SSO Connect Cloud

Voor gebruikers van SSO Connect Cloud wordt een Elliptic Curve-privésleutel gegenereerd en lokaal opgeslagen op elk apparaat. Voor moderne webbrowsers en op Electron gebaseerde Keeper Desktop-applicatie slaat de Keeper-kluis de privé-EC-sleutel van het lokale apparaat 'DPRIV' op als een CryptoKey die niet kan worden geëxporteerd. Op iOS- en Mac-apparaten wordt de sleutel opgeslagen in de Keychain van het apparaat. Op Android-apparaten wordt de sleutel versleuteld met de Android Keystore, gebruikmakend van Encrypted Shared Preferences. Waar beschikbaar gebruikt Keeper veilige opslagmechanismen op elk besturingssysteem.

De Device Private Key (DPRIV) wordt niet rechtstreeks gebruikt om kluisgegevens te versleutelen of ontcijferen. Na succesvolle authenticatie van de identiteitsprovider wordt een afzonderlijke sleutel (die niet is opgeslagen) gebruikt voor ontcijfering van de kluisgegevens. Door een Device Private Key (DPRIV) lokaal uit te pakken, kan een gebruikerskluis niet worden ontcijferd.

Versleuteling van gegevens in rusttoestand

Keeper gebruikt AWS om het platform en de architectuur van Keeper te hosten. Onze AWS-datacentra bevinden zich op meerdere geografische locaties en onze klanten kunnen hun Keeper-tenant hosten in elke gewenste primaire regio. Dit zorgt ervoor dat klantgegevens en toegang tot het platform worden geïsoleerd voor die specifieke regio.

Kluisgegevens in ruste worden lokaal op het apparaat van de gebruiker versleuteld met AES-256 GCM, en versleutelde gegevens die onderweg zijn worden versleuteld met TLS 1.3 met een extra versleutelingslaag in de payload. Klantgegevens worden geïsoleerd door het gebruik van versleuteling op recordniveau.

Het versleutelingsmodel van Keeper volgt de volgende structuur:

• Alle kluizen worden versleuteld met een unieke, door de client gegenereerde 256-bits AES-sleutel in GCM-modus.
• Alle sleutels op recordniveau in gedeelde mappen worden omwikkeld door een 256-bits AES-sleutel voor gedeelde mappen.
• De record- en mapsleutels voor kluisgebruikers zijn versleuteld met een andere 256-bits AES-sleutel, de zogenaamde gegevenssleutel.
• Voor Keeper Secrets Manager (KSM) worden de record- en mapsleutels van de gebruiker versleuteld met een 256-bits AES-applicatiesleutel.
• Voor gebruikers die zich aanmelden met een hoofdwachtwoord, worden de sleutels om gegevens te ontcijferen en versleutelen afgeleid van het hoofdwachtwoord.
• Aanmelden met SSO of wachtwoordloze technologie maakt gebruik van Elliptic Curve-cryptografie om gegevens op het apparaat te versleutelen en te ontcijferen.
• Elke versleutelde payload wordt naar Keeper-servers verzonden en wordt omwikkeld door een 256-bits AES-verzendsleutel met TLS – ter bescherming tegen Man in the Middle (MITM)-aanvallen. De sleutel wordt gegenereerd op de client en verzonden met ECIES-versleuteling via de openbare Elliptic Curve-sleutel van de server.
• Voor het veilig delen van geheimen tussen gebruikers wordt sleuteldistributie op basis van Elliptic Curve-cryptografie toegepast.

Recordversiebeheer

Keeper bewaart een volledig versleuteld versieoverzicht van elke record die is opgeslagen in de kluis, om te garanderen dat belangrijke gegevens nooit verloren gaan. Vanuit de Keeper-clientapp kunnen gebruikers de recordgeschiedenis onderzoeken en elke losse kluisrecord herstellen. Als een opgeslagen wachtwoord of bestand in Keeper wordt gewijzigd of verwijderd, hebben gebruikers altijd de mogelijkheid om te herstellen naar een bepaald punt in de tijd.

Keeper Business

Klanten die Keeper Business aanschaffen krijgen een extra controlelaag over hun gebruikers en apparaten. Keeper-beheerders krijgen toegang tot een cloudgebaseerde administratieve console die volledige controle biedt over het toevoegen en verwijderen van gebruikers, op rollen gebaseerde machtigingen, gedelegeerd beheer, teams, Active Directory/LDAP-integratie, twee-factor-authenticatie, Single Sign-On en beleidsregels voor beveiligingsafdwinging. Keeper's op rollen gebaseerde afdwingingsbeleidsregels zijn volledig aanpasbaar en schaalbaar op organisaties van alle formaten.

Superversleuteling van gegevens in rusttoestand

Naast het opslaan van alleen apparaatversleutelde cijfertekst in de AWS-infrastructuur, voert Keeper ook superversleuteling uit met multiregionale hardwarebeveiligingsmodules (HSM) met behulp van niet-exporteerbare sleutels.

Versleuteling en bescherming van back-ups

Op product-/gebruikersniveau houdt de software van Keeper een volledige revisiegeschiedenis bij van elke record. Als een gebruiker herstel nodig heeft, kan deze dus op elk moment en onbeperkt via de gebruikersinterface eerdere versies van de opgeslagen Keeper-records bekijken en herstellen.

Op systeemniveau worden de versleutelde databases en bestandsobjecten van Keeper gerepliceerd en wordt er een back-up van gemaakt in meerdere geografische regio's voor rampherstel. Alle back-ups worden versleuteld met AES-256 naast superversleuteling van apparaatgegenereerde cijfertekst.

Klanten die hulp nodig hebben bij herstel (bijvoorbeeld omdat een klant per ongeluk een kluis of gedeelde map heeft verwijderd), kan het supportteam van Keeper helpen bij een herstel naar elk willekeurig moment (tot op de minuut) binnen 30 dagen. Keeper Support kan helpen bij elk herstel, zoals gebruikersherstel, kluisherstel of volledig Enterprise-herstel.

Accountherstel

Met een herstelzin van 24 woorden kunnen Keeper-klanten opnieuw toegang krijgen tot hun Keeper-kluis als ze hun hoofdwachtwoord kwijtraken of vergeten.

Keeper heeft herstelzinnen geïmplementeerd met dezelfde BIP39-woordenlijst die wordt gebruikt om cryptowallets te beschermen. De woordenlijst die wordt gebruikt in BIP39 is een set van 2048 woorden die worden gebruikt om een coderingssleutel met 256 bits entropie te genereren. Deze herstelmethode wordt vaak gebruikt in populaire bitcoin- en cryptovaluta-wallets. Elk woord in de BIP39-lijst is zorgvuldig geselecteerd om de zichtbaarheid te verbeteren en het herstelproces minder foutgevoelig te maken. Gebruikers moeten hun herstelzin opschrijven en op een veilige plaats bewaren, zoals een kluis.

De herstelzin genereert een 256-bits AES-sleutel die een kopie van de gegevenssleutel van de gebruiker versleutelt. Om het account te herstellen en het hoofdwachtwoord opnieuw in te stellen, hebben gebruikers de herstelzin nodig, samen met een e-mailverificatie en twee-factor-authenticatie (2FA).

Enterprise-beheerders kunnen accountherstel uitschakelen op het niveau van het beleid voor rolhandhaving.

Coderingssleutels voor bedrijven

Keeper Enterprise- en Business-klanten kunnen veel verschillende mogelijkheden van het Keeper-platform beheren, zoals rolgebaseerd toegangsbeleid, toevoeging, authenticatie en beheer.

Beheerdersfuncties worden beschermd door het Keeper-platform met zowel versleuteling als autorisatie. Autorisatie zorgt ervoor dat alleen aangewezen gebruikers bepaalde functies kunnen uitvoeren. Versleuteling zorgt ervoor dat aangewezen beheerders alleen op fysieke en cryptografische wijze functies kunnen uitvoeren waarbij kluisgegevens of enterprise-beheerde sleutels betrokken zijn. Enkele voorbeelden hiervan zijn:

• Het platform van Keeper is een de facto sleutelbeheerplatform, waar gebruikers en beheerders volledige controle hebben over hun privésleutels.
• Openbare en privé versleutelingsparen worden gebruikt bij het aanmaken van apparaten, gebruikers en teams.
• Rolbeleid voor het overzetten van kluizen en het goedkeuren van apparaten maakt gebruik van openbare en privé coderingssleutels.
• Elliptic Curve (EC)-sleutelparen worden gebruikt voor het delen van gegevens tussen gebruikers en van de individuele gebruiker naar de beheerder op bedrijfsniveau.
• Gevoelige gebruiksgegevens, zoals de wachtwoordsterkte van records, worden versleuteld met openbare sleutels voor bedrijven die alleen de beheerder kan ontcijferen.
• De velden met recordtitel, URL en recordtype van de kluisrecord van elke zakelijke gebruiker worden versleuteld met de openbare sleutel voor bedrijven en kunnen worden ontcijferd in de Keeper-beheerdersconsole door een beheerder met rechten voor nalevingsrapportage.

Apparaatverificatie

Voordat een gebruiker zich zelfs maar kan aanmelden bij een account, moet deze eerst langs een goedkeurings- en verificatiestap van het apparaat. Apparaatverificatie voorkomt het opsommen van accounts en beschermt tegen brute force-aanvallen.

Klanten die zich aanmelden met een hoofdwachtwoord kunnen het apparaat op verschillende manieren verifiëren:

• E-mail verificatiecode
• Invoer van 2FA-code vanuit een TOTP of SMS-bericht
• Keeper Push^™ gebruiken om een bericht te sturen naar een erkend apparaat

Voor klanten die zich authenticeren met Keeper SSO Connect Cloud wordt goedkeuring van het apparaat gedaan met een sleuteloverdracht, waarbij de versleutelde gegevenssleutel van de gebruiker wordt geleverd aan het apparaat, dat lokaal wordt ontcijferd met de Elliptic Curve-privésleutel van de gebruiker. Apparaatgoedkeuringsmethoden zijn onder andere de volgende:

• Keeper-pushmeldingen naar bestaande gebruikersapparaten
• Beheerdersgoedkeuring via de Keeper-beheerdersconsole
• Automatische goedkeuring via Keeper Automator-service
• Automatische beheerdersgoedkeuring via Commander CLI

Meer informatie over apparaatgoedkeuringen.

Gegevensprivacy

Keeper houdt zich aan de AVG en is erop gericht onze processen en producten conform de AVG te laten zijn in de Europese Unie en wereldwijd. 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.

Raadpleeg het AVG-privacybeleid van Keeper.

Geen van de Keeper-apps bevat trackers of bibliotheken van derden die tracking uitvoeren. Als voorbeeld geeft dit rapport informatie over de Android-app van Keeper, waaruit blijkt dat er nul trackers zijn geïnstalleerd.

Gegevensisolatie

Keeper is een volledig beheerd SaaS-platform en host de gegevens in meerdere, geografisch geïsoleerde AWS-datacenters. Organisaties kunnen hun Keeper-gebruiker hosten in hun favoriete regio. Klantgegevens en toegang tot het platform zijn alleen mogelijk voor die specifieke regio.

Beschikbare regio's:

• Verenigde Staten (US)
• Regeringscloud van de Verenigde Staten (US_GOV)
• Europa (EU)
• Australië (AU)
• Japan (JP)
• Canada (CA)

Versleuteling onderweg

De Keeper-kluis wordt beschermd door API's, die worden gevalideerd door middel van autorisatie op het apparaat van de gebruiker.

• Gebruikers vragen een sessietoken op bij hun aanmelding en versturen deze bij elke API-aanroep.
• Het sessietoken wordt beheerd en gecontroleerd op de backend server.
• Aanmelden gebeurt met een hoofdwachtwoord, biometrie, sessiehervatting of SAML 2.0 SSO-authenticatie.

Bij gebruik van een hoofdwachtwoord leidt het gebruikersapparaat een 256-bits authenticatiesleutel af met PBKDF2-HMAC_SHA256 met 1.000.000 iteraties en een willekeurige salt. Er wordt een authenticatiehash gemaakt door de authenticatiesleutel te hashen met SHA-256. Bij het aanmelden wordt de authenticatiehash vergeleken met een opgeslagen authenticatiehash in de Keeper-kluis. Nadat de gebruiker zich heeft aangemeld, wordt een sessietoken gemaakt op de server en naar de gebruiker verzonden om door het apparaat te worden gebruikt voor daaropvolgende API-verzoeken. Om doorlopend gebruik van client-naar-servercommunicatie mogelijk te maken, moet de sessie actief zijn.

• Keeper gebruikt 256-bits en 128-bits TLS om 100% van de gegevens te versleutelen die zijn opgeslagen in de gebruikersapp en veilige bestandsopslag van Keeper.
• Keeper gebruikt TLS-certificaten die zijn ondertekend met het SHA2-algoritme. SHA2 is het veiligste handtekeningalgoritme dat momenteel beschikbaar is bij commerciële certificaatautoriteiten. Het gebruik van SHA2 door Keeper beschermt tegen vervalste certificaten die een aanvaller zou kunnen gebruiken om zich voor te doen als een website.

Cloudauthenticatie

Keeper heeft een geavanceerd cloudauthenticatie- en netwerkcommunicatiemodel ontwikkeld met de hoogste niveaus van privacy, veiligheid, vertrouwen en transparantie. Enkele belangrijke kenmerken van dit verificatiemodel zijn:

Integratie met elke SAML 2.0-provider

Keeper integreert met alle SAML 2.0-compatibele identiteitsproviders, inclusief Okta, Microsoft Entra ID (Azure), AD FS, Google Workspace, Centrify, OneLogin, Ping Identity, JumpCloud, Duo, Auth0 en meer.

Onze producten bieden twee verschillende SSO-types: SSO Connect Cloud en SSO Connect On-Prem. Beide implementaties bieden een zero-knowledge architectuur met naadloze authenticatie voor gebruikers.

Hoofdwachtwoorden van gebruikers worden nooit verzonden via de netwerklaag

In tegenstelling tot de meeste SaaS-services verlaten de aanmeldingsgegevens van Keeper-gebruikers nooit hun apparaat. Wanneer gebruikers zich aanmelden bij Keeper met een hoofdwachtwoord, wordt PBKDF2 gebruikt op het lokale apparaat om een 256-bits AES-sleutel af te leiden voor ontcijfering. Een extra PBKDF2-sleutel wordt gegenereerd op apparaatniveau en vervolgens gehasht met HMAC_SHA256 om een verificatietoken te maken. Keeper heeft geen kennis (zero-knowlegde) van de ontcijferingssleutel van de gebruiker.

Verkeer tussen het clientapparaat en Keeper Cloud kan niet worden onderschept of ontcijfert

Alle versleutelde payloads die naar de servers van Keeper worden verzonden, worden omhuld door een 256-bits AES-verzendsleutel en TLS ter bescherming tegen man-in-the-middle (MITM)-aanvallen. De transmissiesleutel wordt gegenereerd op het clientapparaat en verzonden naar de server met ECIES-versleuteling via de openbare EC-sleutel van de server.

Nieuwe apparaten kunnen niet worden gebruikt om u aan te melden bij een account zonder extra verificatie

Gebruikers kunnen geen nieuwe apparaten gebruiken om zich aan te melden bij hun Keeper-accounts zonder een verificatiemethode te gebruiken. Keeper ondersteunt verschillende soorten verificatiemethoden, afhankelijk van het verificatieschema.

Multi-factor-authenticatie (MFA) wordt uitgevoerd na verificatie, voordat gebruikers hun hoofdwachtwoord invoeren.

Als een gebruiker MFA heeft ingesteld of afgedwongen, moet eerst deze stap worden doorlopen voordat het hoofdwachtwoord kan worden ingevoerd.

Hoofdwachtwoordinvoer kan niet worden uitgevoerd totdat de verificatie van het apparaat en MFA is geslaagd

Als er geen verificatiemethode is ingesteld, kan de gebruiker niet doorgaan met het invoeren van het hoofdwachtwoord. Deze geavanceerde authenticatie beschermt tegen verschillende veelvoorkomende aanvalsmethoden, waaronder brute force-aanvallen, password spraying, numerieke aanvallen en MITM.

Multi-factor-authenticatie (MFA)

Ter bescherming tegen ongeautoriseerde toegang tot het account van een klant, biedt Keeper multi-factor-authenticatie (MFA) - een benadering van authenticatie waarbij twee of meer authenticatiefactoren nodig zijn, namelijk een kennisfactor, een bezitsfactor en/of een aanmeldingsfactor. Meer informatie over het instellen van MFA in Keeper.

Keeper gebruikt uw hoofdwachtwoord en het apparaat dat in uw bezit is om een extra beveiligingslaag te bieden als uw hoofdwachtwoord of apparaat gecompromitteerd is. Keeper ondersteunt FIDO2 WebAuthn hardwaresleutels en softwarematige oplossingen zoals TOTP en sms.

Bij gebruik van een TOTP MFA/2FA-methode genereert Keeper een geheime sleutel van 10 bytes met behulp van een cryptografisch veilige willekeurige getallengenerator. Deze code is ongeveer een minuut geldig en kan niet opnieuw worden gebruikt zodra een succesvolle authenticatie is uitgevoerd. Keeper ondersteunt elke TOTP-app, inclusief Google Authenticator en Microsoft Authenticator. Keeper integreert ook rechtstreeks met populaire MFA-services zoals Duo en RSA SecurID.

Bij gebruik van MFA-authenticators, zoals Google Authenticator, Microsoft Authenticator of andere TOTP-apps op uw mobiele apparaat, genereert de Keeper-server intern een QR-code met uw geheime sleutel. Elke keer dat een gebruiker MFA activeert, wordt een nieuwe sleutel gegenereerd.

Om MFA te activeren, bezoekt u het instellingenscherm van de Keeper-webapp, Desktop-app of iOS-/Android-app. Keeper Business-beheerders kunnen het gebruik van MFA en ondersteunde MFA-methoden ook afdwingen via de Keeper-beheerdersconsole.

Ondersteuning voor FIDO2-compatibele WebAuth wordt geboden via Keeper, met hardware-gebaseerde beveiligingssleutelapparaten zoals de YubiKey en Google Titan-sleutels als extra factor. Passkeys worden ook ondersteund als een 2FA-methode met behulp van fysieke apparaten of webbrowsers. Beveiligingssleutels bieden een veilige manier om MFA uit te voeren zonder dat de gebruiker handmatig codes hoeft in te voeren.

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

Keeper Active Directory / LDAP Bridge

De Keeper Bridge integreert met Active Directory- en LDAP-servers voor toevoegen en verwelkomen van gebruikers. Keeper Bridge-communicatie wordt eerst geautoriseerd door een beheerder met de bevoegdheid om de bridge te beheren. Er wordt een transmissiesleutel gegenereerd en gedeeld met Keeper voor alle daaropvolgende communicatie. Het gebruik van de transmissiesleutel is de autorisatie voor alle bewerkingen die door de bridge worden uitgevoerd, behalve de initialisatie van de bridge. De transmissiesleutel kan op elk moment opnieuw worden gegenereerd en wordt elke 30 dagen automatisch vernieuwd.

De transmissiesleutel is alleen voor transmissie, wat betekent dat een gecompromitteerde sleutel opnieuw geïnitialiseerd of ingetrokken kan worden zonder verlies van gegevens of toestemming.

Keeper Bridge mag geen privileges verlenen aan een rol of gebruiker. Het mag een gebruiker toevoegen aan een geprivilegieerde rol, zolang er geen handhavingssleutels nodig zijn. Keeper Bridge mag zichzelf of een gebruiker niet verheffen boven het deel van de structuur die het beheert. Niet alle bewerkingen zijn beschikbaar voor de bridge, bijvoorbeeld de bridge kan een actieve gebruiker uitschakelen maar mag de gebruiker niet verwijderen. De beheerder moet kiezen of de gebruiker verwijderd of overgedragen moet worden.

SSO-authenticatie met MFA

Wanneer Keeper wordt geïmplementeerd met een SSO-oplossing zoals Entra ID / Azure AD, Okta, Ping, Google Workspace of een andere SAML 2.0-identiteitsprovider, kan MFA volledig worden beheerd tijdens het IdP-aanmeldingsproces. Keeper ondersteunt ook het beleid van Azure voor beperkte toegang voor alle apparaattypen en applicaties.

MFA kan zowel aan de kant van de identiteitsprovider als aan de kant van Keeper worden afgedwongen. Als gebruikers bijvoorbeeld eenmaal de MFA-stap bij de identiteitsprovider hebben doorlopen, kunnen zij daarnaast worden gedwongen om een tweede MFA-stap op de Keeper-interface te doorlopen. Dit beleid kan worden afgedwongen door de Keeper-beheerder.

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

SAML 2.0-authenticatie met SSO Connect Cloud

Keeper SSO Connect Cloud stelt zakelijke klanten in staat om Keeper volledig te integreren met elke SAML 2.0-compatibele identiteitsprovider en versleutelde kluizen te implementeren voor hun gebruikers.

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 is een optionele service waarmee directe teamgoedkeuringen, apparaatgoedkeuringen en teamgebruikersaanmeldingen worden uitgevoerd na een succesvolle aanmelding van de SSO-identiteitsprovider.

Zodra Automator actief is, hebben gebruikers naadloos toegang tot Keeper op nieuwe apparaten (die niet eerder zijn goedgekeurd) na een succesvolle authenticatie met uw identiteitsprovider, zonder verdere goedkeuringsstappen.

Keeper SSO Connect op locatie

Terwijl de meeste klanten Keeper SSO Connect Cloud implementeren, kunnen klanten die een plaatselijke oplossing vereisen SSO Connect On-Prem implementeren. Dit is een zelfgehoste integratie waarvoor een door Windows of Linux gehoste applicatieserver nodig is. Om de zero knowledge-beveiliging te behouden en een naadloze SSO-ervaring voor gebruikers te garanderen, moet Keeper SSO Connect op de server van de klant worden geïnstalleerd. Windows-, Mac- en Linux-omgevingen worden volledig ondersteund met High Availability (HA)-werklastbalanceringsmodi en superversleuteling met hardwarebeveiligingsmodules.

Keeper SSO Connect genereert en onderhoudt automatisch het hoofdwachtwoord voor elke gebruiker. Dit is een willekeurig gegenereerde 256-bits sleutel. Dit hoofdwachtwoord wordt versleuteld met de SSO-sleutel. De SSO-sleutel is versleuteld met de overzichtssleutel. De SSO-sleutel wordt opgehaald van de server bij het opstarten van Keeper SSO Connect-service en vervolgens ontcijfert met behulp van de overzichtssleutel, die lokaal op de server is opgeslagen om het automatisch opstarten van de service te ondersteunen. Communicatie tussen SSO Connect en Keeper's Cloud Security Vault wordt beschermd met een transmissiesleutel. SAML-communicatie is cryptografisch ondertekend en wordt beschermd door het RSA-SHA256- of ECDSA-SHA256-handtekeningalgoritme, afhankelijk van het type coderingssleutel (RSA of ECC) dat door de klant is verstrekt.

Delen

Keeper ondersteunt de mogelijkheid om records veilig te delen tussen gebruikers, naar een intern team of zelfs buiten de organisatie (indien toegestaan door de Keeper-beheerder).

Sharing records

Keeper-gebruikers kunnen records direct met elkaar delen. Hiervoor vraagt Keeper in eerste instantie de openbare Elliptic Curve-sleutel van gebruikers op in hun kluis. Elke record heeft een recordsleutel die is versleuteld met de openbare Elliptic Curve-sleutel van de ontvanger en wordt gesynchroniseerd met de Keeper-kluis van de gebruiker.

Eigenaren van versleutelde gedeelde records ontcijferen de recordsleutel met hun Elliptic Curve-privésleutel. De recordsleutel wordt ook opnieuw versleuteld met de gegevenssleutel van de gebruiker en de cijfertekst wordt opgeslagen in de kluis van de ontvanger.

Eenmalig delen

Keeper's eenmalige deelactie biedt beperkte tijd, veilig delen van een record (zoals een wachtwoord, aanmeldingsgegevens, geheim, verbinding, document of andere vertrouwelijke informatie) met iedereen, zelfs als ze geen Keeper-account hebben. Het Keeper One-Time Share-versleutelingsmodel maakt gebruik van dezelfde technologie als Keeper Secrets Manager (KSM) – een zero-knowledge en zero-trust platform voor het beveiligen van cloudinfrastructuur.

1. In de Keeper-kluis van de gebruiker genereert de originator eenmalige toegang door op eenmalig deelactie te klikken. De 256-bits AES-recordsleutel wordt versleuteld met een eenmalig toegangstoken en de versleutelde waarde wordt opgeslagen in de Keeper-kluis.
2. De gebruiker die het eenmalige toegangstoken deelt met een ontvanger, gebruikt een eenvoudige URL of QR-code. Het gedeelte van de URL dat het toegangstoken bevat, wordt bewaard in het 'fragment identifier'-gedeelte van de URL – dat nooit naar de servers van Keeper wordt verzonden. Daarom kan Keeper de informatie niet openen of ontcijferen en wordt zero-knowledge in stand gehouden.
3. De URL wordt geopend in de browser van de gebruiker en de kluisapp wordt geladen op het apparaat. Het token wordt direct doorgegeven aan de lokale kluisapp en wordt niet naar de server gestuurd.
4. Ontvangers gebruiken vervolgens hun apparaat om een EC-sleutelpaar aan de eindgebruikerszijde te genereren en de privésleutel wordt lokaal opgeslagen op het apparaat, in de CryptoKey-opslag van de browser.
5. Bij het eerste gebruik door de ontvanger verifieert de SDK-bibliotheek met de hash van het eenmalige toegangstoken. Vervolgens antwoordt de server van Keeper met de versleutelde recordtekst en de versleutelde recordsleutel.
6. Het apparaat ontcijfert de recordsleutel met het eenmalige toegangstoken en de inhoud wordt ontcijfert. De sleutel wordt op het clientapparaat opgeslagen in de CryptoKey-opslag van de browser of op een andere opslaglocatie.
7. De versleutelde recordsleutel voor het desbetreffende apparaat wordt verwijderd, zodat het token niet opnieuw kan worden gebruikt. Vervolgens moet het clientverzoek worden ondertekend met de privésleutel.
8. Meer oproepen op hetzelfde apparaat worden verzonden met een identifier die het apparaat definieert en een verzoek dat is ondertekend met de privésleutel van de cliënt. Het verzoek voor de desbetreffende apparaatidentifier (via de ECDSA-handtekening) maakt gebruik van de openbare sleutel van het apparaat en wordt gecontroleerd door de server. Keeper verwerkt het verzoek en de server stuurt een versleutelde record in cijfertekst terug naar het apparaat van de gebruiker.
9. Naast de versleuteling op recordniveau maakt het clientapparaat een willekeurig gegenereerde AES-256 bits transmissiesleutel aan, die is versleuteld met de openbare sleutel van de Keeper cloud-API. Het clientapparaat ontcijfert het antwoord van de server met de transmissiesleutel en ontcijfert vervolgens de payload van het cijfertekstantwoord met de recordsleutel, waarmee de inhoud van het record wordt ontcijferd.

Beheer delen

De gedeeld beheer-functie van Keeper is een op rollen gebaseerde toegangscontrole (RBAC) die beheerders verhoogde privileges geeft over de gedeelde mappen en records van een organisatie. Gedeelde beheerders hebben volledige gebruikers- en dossierprivileges voor elk gedeeld dossier waartoe ze toegang hebben.

Secrets Manager-versleutelingsmethode

Keeper Secrets Manager is een zero-knowledge platform voor IT- en DevOps-professionals. Het stelt teams in staat om geheimen te beheren gedurende de gehele levenscyclus van softwareontwikkeling en -implementatie.

Secrets Manager gebruikt het volgende versleutelingsmodel

• Versleuteling en ontcijfering gebeurt lokaal op het apparaat (niet op de server).
• Platte tekst wordt nooit opgeslagen op het apparaat.
• De server ontvangt nooit platte tekst.
• Niemand, ook niet Keeper-medewerkers, derden of tussenpersonen, kan geheimen ontcijferen.
• Het clientapparaat beheert de sleutels om geheimen te versleutelen en te ontcijferen, onder controle van de gebruiker.
• Elk geheim wordt versleuteld met een door de client gegenereerde 256-bits AES-coderingssleutel in GCM-modus.
• Als het geheim in een gedeelde map staat, wordt de recordsleutel omwikkeld door een gedeelde mapsleutel.
• Een 256-bits AES-toepassingssleutel wordt aan de clientzijde gegenereerd en gebruikt om de gedeelde map- en recordsleutels te ontcijferen. De recordsleutel zal vervolgens het individuele geheim ontcijferen.
• Keeper-servers worden omwikkeld door een 256-bits AES-sleutel met TLS om ze te beveiligen tegen MITM-aanvallen.
• De transmissiesleutel wordt gegenereerd op het clientapparaat en verzonden naar de server met ECIES-versleuteling via de openbare EC-sleutel van de server.
• Elliptic Curve-cryptografie wordt gebruikt om geheimen tussen gebruikers te delen voor een veilige sleuteldistributie.
• Meerlaagse versleuteling biedt toegangscontrole op gebruikers-, groeps- en beheerdersniveau.
• Geheimen die in de kluis worden beheerd, worden gesegmenteerd en geïsoleerd naar gedefinieerde Secrets Manager-apparaten die toegang krijgen tot het record en de map.

Keeper Secrets Manager's model voor wachtwoordrotatie

• Een unieke Keeper Secrets Manager (KSM)-client, een zogenaamde gateway, wordt geïnstalleerd in de omgeving van de klant.
• De gateway maakt een beveiligde uitgaande verbinding met de Keeper-router.
• De router is een cloudservice die wordt gehost in de AWS-omgeving van Keeper waarmee communicatie mogelijk is tussen de back-end API van Keeper, eindgebruikertoepassingen (webkluis, desktop-app, enz.) en gateways die zijn geïnstalleerd in de omgeving van de gebruiker.
• Websockets worden tot stand gebracht tussen het eindgebruikersapparaat (bijv. Webkluis) en de Keeper-router met behulp van het huidige sessietoken.
• De Keeper-router verifieert het sessietoken en authenticeert de sessie. Alle versleutelde payloads die naar de Keeper-router worden verzonden, worden omwikkeld met een 256-bits AES-sleutel, naast TLS, ter bescherming tegen MITM-aanvallen.
• De 256-bits AES-sleutel wordt aangemaakt op het apparaat van de eindgebruiker en via de openbare EC-sleutel van de router overgebracht naar de server met behulp van ECIES-versleuteling.
• Roulatie- en ontdekkingsverzoeken worden verzonden tussen het apparaat van de eindgebruiker (of Keeper Scheduler) en de gateway via het gevestigde websocket-communicatiekanaal.
• Tijdens de roulatie, wanneer de gateway een geheim nodig heeft van de Keeper-kluis, wordt het geheim geauthenticeerd en versleuteld met behulp van de API's van Keeper Secrets Manager om zero-knowledge te behouden.
• Net als elk ander Secrets Manager-apparaat kan de toegang ook worden beperkt op basis van IP-adres, naast het versleutelings- en ondertekeningsproces.

Zero-trust verbinding en tunnelbeveiliging

Zero-Trust KeeperPAM biedt de mogelijkheid om geprivilegieerde cloudsessies en lokale sessies tot stand te brengen, tunnels te maken en verzorgt directe toegang tot de infrastructuur en veilige externe toegang tot de database zonder een VPN.

Een verbinding is een visuele externe sessie met behulp van de webbrowser. Interactie tussen de gebruiker en het bestemmingsapparaat verloopt via een webbrowservenster of binnen de Keeper Desktop-applicatie.

Een tunnel is een TCP/IP-verbinding die tot stand wordt gebracht tussen de lokale kluisclient via de Keeper Gateway naar het bestemmingseindpunt. De gebruiker kan elke eigen applicatie gebruiken om te communiceren met het bestemmingseindpunt, zoals de opdrachtregelterminal, GUI-applicatie of databasebeheerapplicatie zoals MySQL Workbench.

Wanneer de gebruiker een verbinding of tunnel tot stand brengt:

1. Communiceert de kluisclientapplicatie met de Keeper Router-infrastructuur om een WebRTC-verbinding te initiëren die wordt beschermd met een symmetrische ECDH-sleutel die wordt opgeslagen in de relevante Keeper-record.
2. The Keeper Gateway communicates with the Keeper Router through outbound-only WebSockets. This is described in detail at this link.
3. De Keeper Gateway gebruikt Keeper Secrets Manager-API's om de benodigde geheimen uit de kluis op te halen, waaronder de symmetrische ECDH-sleutel.
4. Voor verbindingen draagt de kluisclient (met behulp van het Apache Guacamole-protocol) gegevens over via de WebRTC-verbinding naar de Keeper Gateway, die vervolgens Guacd gebruikt om verbinding te maken met de bestemming in de Keeper-record.
5. Voor tunnelfuncties (poortdoorschakeling) wordt een lokale poort geopend op het lokale apparaat met Keeper Desktop-software. Gegevens die naar de lokale poort worden verzonden, worden eerst via de WebRTC-verbinding naar de Keeper Gateway verzonden en vervolgens doorgestuurd naar het bestemmingseindpunt in de Keeper-record.
6. Sessieregistraties van verbindingen worden beschermd met een AES-256-versleutelingssleutel ('opnamesleutel') die bij elke sessie op de Keeper Gateway wordt gegenereerd. De registratiesleutel wordt daarbij ook nog eens beschermd door een HKDF-afgeleide AES-256 bronsleutel.

Beveiliging met Remote Browser Isolation

Keeper Remote Browser Isolation-technologie beschermt de toegang tot interne webapplicaties of een andere webgebaseerde set via de Keeper Connection Manager Docker-container of via de Keeper Gateway.

Gebruik van de Connection Manager Docker-containermethode:

1. De gebruiker verifieert zich bij de Keeper Connection Manager-webservice, die door de klant wordt gehost in een Docker-container.
2. De gebruiker start een Remote Browser Isolation-sessie naar de bestemde webapplicatie. Communicatie tussen de browser van de gebruiker en de gehoste Keeper Connection Manager-webservice wordt via HTTPS beschermd met Let's Encrypt of het opgegeven certificaat van de klant.
3. Op de Keeper Connection Manager Docker-container wordt een ingesloten versie van Chromium uitgevoerd binnen een sandbox. De bestemmingswebsite wordt gerenderd met behulp van een lokaal weergavestuurprogramma dat de zichtbare inhoud van de pagina in realtime naar de webbrowser van de gebruiker streamt met behulp van het Apache Guacamole-protocol.

Gebruik van de Keeper Gateway met de Keeper Web Vault of Desktop App:

1. Communiceert de kluisclientapplicatie met de Keeper Router-infrastructuur om een WebRTC-verbinding te initiëren die wordt beschermd met een symmetrische ECDH-sleutel die wordt opgeslagen in de relevante Keeper-record.
2. The Keeper Gateway communicates with the Keeper Router through outbound-only WebSockets. This is described in detail at this link.
3. De Keeper Gateway gebruikt Keeper Secrets Manager-API's om de benodigde geheimen uit de kluis op te halen, waaronder de symmetrische ECDH-sleutel.
4. De kluisclient (met behulp van het Apache Guacamole-protocol) draagt gegevens over via de WebRTC-verbinding naar de Keeper Gateway, die vervolgens HTTP of HTTPS gebruikt om verbinding te maken met de bestemming in de Keeper-record.
5. Sessieregistraties van verbindingen worden beschermd met een AES-256-versleutelingssleutel ('opnamesleutel') die bij elke sessie op de Keeper Gateway wordt gegenereerd. De registratiesleutel wordt daarbij ook nog eens beschermd door een HKDF-afgeleide AES-256 bronsleutel.

Bescherming van browserisolatie

Er worden verschillende beveiligingsmaatregelen geactiveerd met behulp van het Remote Browser Isolation-protocol:

1. Het beschermde webapplicatie-eindpunt wordt beveiligd aan de hand van een TLS-versleutelingslaag van de Keeper Connection Manager-poort naar het lokale apparaat van de gebruiker, ongeacht of TLS wordt gebruikt tussen de poort en het eindpunt, waardoor er bescherming wordt geboden tegen een MITM-aanval of pakketinspectie op het lokale netwerk van de gebruiker.
2. De externe browsersessie projecteert de interactie op visuele wijze op het lokale apparaat van de gebruiker aan de hand van een canvas en grafische rendering. Er wordt geen JavaScript-code of HTML van de bestemmingswebsite uitgevoerd op het lokale apparaat van de gebruiker.
3. Omdat er geen websitecode van de bestemming lokaal wordt uitgevoerd en de lokale browser geen rechtstreekse toegang heeft tot de onderliggende applicatiecode, wordt de geïsoleerde webapplicatie beschermd tegen aanvalsvectoren zoals gereflecteerde kwetsbaarheden voor cross-site scripting, vervalsing van cross-site verzoeken en API-misbruik.
4. De eindgebruiker kan worden beperkt in het uitvoeren van gegevensexfiltratie vanaf het bestemmingseindpunt via URL- en bronaanvraagfiltering. Het uploaden en downloaden van bestanden is beperkt, zelfs als de bestemde webapplicatie normaalgesproken de actie zou toestaan.
5. De browsersessie en toetsaanslagen kunnen worden geregistreerd voor auditings- en nalevingsdoeleinden, waardoor u forensische analyses van webgebaseerde sessies kunt uitvoeren.
6. Inloggegevens die automatisch worden ingevuld vanuit de poort naar de bestemde webapplicatie, worden nooit naar het apparaat van de gebruiker verzonden en zijn niet toegankelijk voor de gebruiker op hun lokale apparaat, waardoor geheimen worden beschermd tegen lekkage.
7. Via een firewallbeleid kan de gebruiker alleen toegang krijgen tot de bestemde webapplicatie via de externe browserisolatiesessie, waardoor er minder risico ontstaat op een gecompromitteerde browser of lokale apparaatmalware.
8. De bestemde webapplicatie wordt beschermd met Single Sign-On en/of MFA-authenticatie, zelfs als de applicatie deze niet standaard ondersteunt. Keeper beschermt de toegang tot de kluis en eventuele Remote Browser Isolation-sessies aan de hand van de geavanceerde authenticatiemethoden die in dit document worden besproken.

BreachWatch^®

Keeper gebruikt een beheerde, op zichzelf staande architectuur op AWS genaamd BreachWatch. BreachWatch is fysiek gescheiden van de Keeper API en gebruikersrecords.

Een fysieke hardwarebeveiligingsmodule (HSM) op BreachWatch-servers wordt gebruikt voor het verwerken, hashen en opslaan van miljarden unieke wachtwoorden uit inbreuken op dark web-gegevens. Alle wachtwoorden worden verwerkt op de servers van Keeper met behulp van de HMAC_SHA512-hashmethode en gehasht met de HSM met behulp van een niet-exporteerbare sleutel.

Wanneer BreachWatch op het clientapparaat wordt geactiveerd, wordt op basis van elke record een HMAC_SHA512 hash gegenereerd en naar de server gestuurd. Op de server wordt een tweede hash gemaakt met HMAC_SHA512 via de HSM met een niet-exporteerbare sleutel. De 'Hashes-of-Hashes' worden vergeleken om te zien of aanmeldingsgegevens zijn geschonden.

De BreachWatch-architectuur is gebouwd om de correlatie van een gelekt wachtwoord met een wachtwoord in de kluis van de gebruiker te voorkomen, ongeacht de omvang van het datalek. De detectie van gelekte wachtwoorden maakt gebruik van een fysieke HSM om ervoor te zorgen dat hashing alleen online kan worden uitgevoerd – om brute force-aanvallen op de gegevens te voorkomen.

• De wachtwoorden worden tweemaal gehasht met HMAC_512: eenmaal op het clientapparaat met behulp van een 'pepper' en eenmaal in de AWS CloudHSM met behulp van een hardware beveiligingsmodule met een niet-exporteerbare sleutel.
• HMAC_512 wordt toegepast omdat het gebruikmaakt van een sterke hashingfunctie plus een geheime sleutel, die niet exporteerbaar is. Daarom is een offline aanval op de hashes niet mogelijk.
• Message Authentication Code (MAC) met het resultaat van een cryptografische hashfunctie breidt het gebruik van hashfuncties uit. De resultaten zijn niet alleen afhankelijk van het bericht, maar ook van een tweede invoer die een geheime sleutel kan zijn.

BreachWatch is 100% gebouwd door Keeper met behulp van SpyCloud-datafeeds, maar Keeper stuurt nooit gegevens naar derden.

Scannen van domeinen

BreachWatch-klanten downloaden een lijst met domeinen die zijn gelekt en voeren lokaal een controle uit.

Scannen van gebruikersnamen en wachtwoorden

Clientapparaten maken verbinding met BreachWatch en uploaden een lijst met gehashte gebruikersnamen (of wachtwoorden) samen met een door de client geselecteerde, willekeurige identificatie (afzonderlijke identificaties voor de gebruikersnaam- en wachtwoordcontrolerende services). Deze wachtwoord-hashes worden verwerkt bij het uploaden met HMAC via een Hardware Security Module (HSM) en een geheime sleutel die is opgeslagen in HSM en gemarkeerd als niet-exporteerbaar (wat inhoudt dat de HSM de HMAC uitsluitend lokaal verwerkt en de sleutel niet kan worden geëxtraheerd). Deze HMAC-ingangen (gebruikersnamen en wachtwoorden) worden vergeleken met de gelekte datasets die zijn verwerkt met dezelfde HMAC en sleutel. Eventuele matches worden gemeld bij het clientapparaat. Waarden die niet overeenkomen, worden opgeslagen naast de anonieme ID van de client.

Naarmate nieuw gelekte gebruikersnamen en wachtwoorden worden toegevoegd aan het systeem, worden deze verwerkt met HMAC op de HSM, toegevoegd aan de BreachWatch-dataset en vergeleken met de opgeslagen clientwaarden. Eventuele matches leveren een alarm op voor deze client-ID.

Klanten melden zich regelmatig aan bij BreachWatch en presenteren hun BreachWatch-ID's. Eventuele berichten in de wachtrij worden gedownload en klanten uploaden eventuele nieuwe of gewijzigde gebruikersnamen en wachtwoorden die op dezelfde manier worden verwerkt.

De beveiliging van de BreachWatch-services is trust-on-first-use (TOFU). Dat betekent dat klanten moeten aannemen dat de BreachWatch-server niet kwaadwillend is (niet actief gecompromitteerd door een aanvaller) wanneer de klant zijn gehashte waarden uploadt. Zodra deze waarden zijn verwerkt met een HSM, worden ze veiliggesteld tegen offline kraakpogingen. Met andere woorden: als een aanvaller de dataset steelt met bewaarde klantwaarden, kan hij of zij deze waarden niet offline kraken zonder de HMAC-sleutel die is opgeslagen in de HSM.

Als een lek van een wachtwoord wordt gedetecteerd, stuurt het clientapparaat een gebruikersnaam+wachtwoord-combinatiehash naar de BreachWatch-servers. De server voert vervolgens dezelfde HMAC-hashvergelijking uit om te bepalen of een combinatie van gebruikersnaam+wachtwoord is gelekt, en als dat het geval is, of de domeinen gerelateerd aan die lekken worden geretourneerd zodat het clientapparaat kan controleren of gebruikersnaam+wachtwoord+domein overeenkomt. Als alle drie de parameters overeenkomen op het clientapparaat, wordt de gebruiker op de hoogte gesteld van de ernst van het lek

BreachWatch voor leden van Business en Enterprise

Wanneer BreachWatch wordt geactiveerd voor zakelijke klanten, worden de kluizen van de eindgebruikers automatisch gescand telkens wanneer een gebruiker zich aanmeldt met Keeper. De BreachWatch-overzichtsgegevens die worden gescand op het apparaat van de gebruiker, worden versleuteld met de zakelijke openbare sleutel en ontcijferd door de zakelijke beheerder bij aanmelding bij de Keeper-beheerdersconsole. De versleutelde informatie bevat het e-mailadres, aantal records met een hoog risico, het aantal opgeloste records en het aantal genegeerde records. De Keeper-beheerder kan het statistiekenoverzicht op gebruikersniveau bekijken via de gebruikersinterface van de beheerdersconsole.

Registreren en rapporteren van evenementen

Bij integratie met de Geavanceerde rapportage- en alarmmodule, kunnen apparaten van Keeper-eindgebruikers ook optioneel worden geconfigureerd om gedetailleerde real-time gebeurtenissen te sturen naar SIEM-oplossingen van externe providers en naar de rapportage-interface van de Keeper-beheerdersconsole. De gebeurtenisgegevens bevatten e-mailadres, record-UID, IP-adres en apparaatinformatie (gebeurtenissen bevatten geen ontcijferde recordgegevens aangezien Keeper een zero-knowledge platform is en geen gebruikersgegevens kan ontcijferen).

Standaard worden de gedetailleerde BreachWatch-gebeurtenisgegevens niet naar de Geavanceerde rapportage- en alarmmodule gestuurd, evenmin als naar eventuele verbonden externe loggingsystemen. Om rapportage op gebeurtenisniveau van BreachWatch-gegevens naar de Geavanceerde rapportage- en alarmmodule te activeren, moet u het rolafdwingingsbeleid voor gebeurtenissen inschakelen voor de specifieke rol > Afdwingingsinstellingen > Kluisfuncties. Na inschakeling sturen de clientapparaten deze gebeurtenisgegevens. Aangezien integratie met SIEM-oplossingen van externe partijen wordt verzonden van de Keeper-back-end naar de doel-SIEM, is deze gebeurtenisinformatie daardoor leesbaar door de doel-SIEM en kan worden gebruikt om te identificeren welke records en welke gebruikers binnen de organisatie zwakke wachtwoorden hebben. Als de Keeper-beheerder gebeurtenisgegevens op recordniveau niet wil overdragen aan de Keeper Geavanceerde rapportage- en alarmmodule, kunt u deze instelling uitgeschakeld laten.

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

Offline-modus

Via de offline-modus hebben gebruikers toegang tot hun kluis wanneer ze online geen verbinding kunnen maken met Keeper of met hun SSO-identiteitsprovider. Deze mogelijkheid is beschikbaar op Keeper's mobiele app, desktop-app en webkluis in alle browsers.

Deze functie werkt door een kopie van de kluis te maken op het lokale apparaat van de gebruiker. De kluisgegevens die offline worden opgeslagen, worden AES-GCM-versleuteld met een 256-bits 'client-sleutel' die willekeurig wordt gegenereerd en beschermd door PBKDF2-HMAC-SHA512 met tot wel 1.000.000 iteraties en een willekeurige salt. De salt en iteraties worden lokaal opgeslagen. Wanneer de gebruiker het hoofdwachtwoord invoert, wordt er een sleutel afgeleid door gebruik te maken van de salt en iteraties, en wordt er een poging gedaan om de client-sleutel te ontcijferen. De client-sleutel wordt vervolgens gebruikt om de opgeslagen recordcache te ontcijferen. Als zelfvernietigingsbescherming wordt ingeschakeld in de kluis van de gebruiker, worden na 5 mislukte aanmeldingspogingen automatisch alle lokaal opgeslagen kluisgegevens gewist. Voor zakelijke klanten kan offline toegang worden beperkt op basis van het rolhandhavingsbeleid van de Keeper-beheerder.

Toegang in noodgevallen (digitale veroudering)

Met de abonnementen voor individuen en gezinnen van Keeper kunnen gebruikers maximaal vijf contactpersonen voor noodgevallen toevoegen om toegang tot de kluis te verlenen in geval van overlijden van de gebruiker of een ander noodgeval. De gebruiker geeft een wachttijd op en zodra deze wachttijd is verstreken, heeft de contactpersoon in noodgevallen toegang tot de kluis van de gebruiker. Het delen van de kluis met een contactpersoon in noodgevallen is zero-knowlegde en het hoofdwachtwoord van de gebruiker wordt nooit gedeeld. Daarnaast wordt er 2048-bits RSA-versleuteling gebruikt met een 256-bits AES-sleutel. De contactpersoon voor noodgevallen moet een Keeper-account hebben om de informatie te accepteren.

Netwerkarchitectuur

Keeper gebruikt AWS in Noord-Amerika (Commercial of GovCloud), Europa, Australië, Japan en Canada voor gelokaliseerde gegevensprivacy en geografische isolatie voor het hosten en uitvoeren van de Keeper-oplossing en -architectuur. Door gebruik te maken van AWS kan Keeper naadloos bronnen on-demand schalen en klanten de snelste en veiligste cloudopslagomgeving bieden. Keeper werkt met omgevingen met meerdere zones en meerdere regio's om de uptime te maximaliseren en klanten de snelste reactietijd te bieden. Enterprise-klanten kunnen hun Keeper-tenant hosten in elke gewenste primaire regio. Klantgegevens en toegang tot het platform zijn geïsoleerd tot die specifieke regio.

Cloudauthenticatie

Keeper heeft een geavanceerd cloudauthenticatie- en netwerkcommunicatiemodel gecreëerd dat is gebouwd voor de hoogste niveaus van privacy, veiligheid en vertrouwen. Enkele belangrijke kenmerken van het authenticatiemodel zijn:

• Het hoofdwachtwoord wordt nooit overgedragen via de netwerklaag. In tegenstelling tot de meeste SaaS-services verlaten de aanmeldingsgegevens nooit het apparaat. PBKDF2 wordt gebruikt op het lokale apparaat om een 256-bits AES-sleutel af te leiden voor ontcijfering. Een extra PBKDF2-sleutel wordt lokaal gegenereerd en vervolgens gehasht met HMAC_SHA256 om een authenticatietoken te maken. Cloud Security Vault van Keeper heeft geen kennis (zero-knowlegde) van de ontcijferingssleutel van de gebruiker.
• Verkeer tussen het clientapparaat en de Keeper-cloud kan niet worden onderschept of ontcijfert. Keeper gebruikt Key Pinning (sleutel vastmaken) en extra versleutelingslagen op netwerkniveau (transmissiesleutels) tussen het apparaat en de Keeper-servers om ervoor te zorgen dat MITM-aanvallen worden voorkomen.
• Nieuwe apparaten kunnen zich niet aanmelden bij een account zonder een apparaatverificatiestap. Er kunnen geen aanmeldingspogingen worden gedaan op een account zonder deze stap te doorlopen. Keeper ondersteunt verschillende soorten apparaatverificatiemethoden die afhankelijk zijn van het gebruikte authenticatieschema
• 2FA wordt uitgevoerd na apparaatverificatie, voorafgaand aan het invoeren van het hoofdwachtwoord. Als een gebruiker 2FA heeft geconfigureerd of afgedwongen, moet deze stap worden uitgevoerd voordat het hoofdwachtwoord wordt ingevoerd.
• Hoofdwachtwoordinvoer kan niet worden uitgevoerd totdat de apparaatverificatie- en 2FA-stap is geslaagd. De gebruiker kan niet doorgaan naar stap voor het invoeren van het hoofdwachtwoord zonder eerst een apparaatverificatie en 2FA-authenticatie uit te voeren. Deze geavanceerde authenticatiestroom biedt bescherming tegen verschillende aanvalsvectoren, waaronder brute force-aanvallen, password spraying, numerieke aanvallen en MITM.

Versleuteling onderweg

De Keeper Cloud Security Vault wordt beschermd door API's die worden gevalideerd via autorisatie door het clientapparaat. De client vraagt een sessietoken op bij het aanmelden en verzendt dit bij elke API-aanroep. Het sessietoken wordt bijgehouden op de server. Aanmelding gebeurt via een hoofdwachtwoord, sessiehervatting of SAML 2.0 SSO-authenticatie.

Bij gebruik van een hoofdwachtwoord leidt het gebruikersapparaat een 256-bits 'authenticatiesleutel' af met PBKDF2-HMAC-SHA256 met 1.000.000 iteraties en een willekeurige salt. Er wordt een 'authenticatiehash' gemaakt door de authenticatiesleutel te hashen met SHA-256. Bij het aanmelden wordt de authenticatiehash vergeleken met een opgeslagen authenticatiehash op de Cloud Security Vault. Na het aanmelden wordt een sessietoken gemaakt op de server en naar de client verzonden om door het clientapparaat te worden gebruikt voor daaropvolgende API-verzoeken. Om doorlopend gebruik van client-naar-servercommunicatie mogelijk te maken, moet de sessie actief zijn.

Keeper ondersteunt 256-bits en 128-bits TLS om alle gegevenstransport tussen de client-app en de cloudopslag van Keeper te versleutelen.

Keeper gebruikt TLS-certificaten die zijn ondertekend door DigiCert met het SHA2-algoritme, het veiligste handtekeningalgoritme dat momenteel wordt aangeboden door commerciële certificaatautoriteiten. SHA2 is aanzienlijk veiliger dan het meer gebruikte SHA1, dat misbruikt zou kunnen worden vanwege een geïdentificeerde wiskundige zwakte in het algoritme. SHA2 helpt beschermen tegen de uitgifte van vervalste certificaten die door een aanvaller kunnen worden gebruikt om zich voor te doen als een website.

Keeper ondersteunt ook Certificate Transparency (CT), een initiatief van Google om een openbaar controleerbaar overzicht te maken van certificaten die zijn ondertekend door certificaatautoriteiten. CT helpt te beschermen tegen de uitgifte van certificaten door onbevoegde entiteiten. CT wordt momenteel ondersteund in de nieuwste versies van de webbrowsers Chrome, Safari en Brave. Meer informatie over Certificate Transparency is te vinden op: https://certificate.transparency.dev/. Keeper ondersteunt de volgende TLS versleutelingssuites:

• 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-clientapparaten op iOS en Android implementeren ook Key Pinning, een beveiligingsmechanisme dat voorkomt dat aanvallers zich voordoen met frauduleuze digitale certificaten.

Voorkomen van Cross-Site Scripting (XSS)-aanvallen

De Keeper-webkluis hanteert een streng contentbeveiligingsbeleid dat de oorsprong van uitgaande verzoeken beperkt en voorkomt dat alle scripts worden uitgevoerd, behalve die uitdrukkelijk afkomstig zijn van Keeper. Dit is inclusief in-line scripts en evenementverwerkende HTML-attributen, waarbij de meeste vectoren voor cross-site scriptingaanvallen worden beperkt of uitgeschakeld.

Toegang tot de domeinnamen van Keeper is beperkt tot HTTPS met TLS 1.3 en wordt afgedwongen door HTTP Strict Transport Security. Dit voorkomt een breed scala aan packet sniffing, gegevensaanpassing en man-in-the-middle-aanvallen.

Binnen de Keeper-browserextensie vraagt Keeper gebruikers niet om hun aanmeldingsgegevens voor hun kluis vanuit het gebied van het paginakader. Het aanmelden op de extensie gebeurt in de werkbalk Browseruitbreiding van de browser. Aanmelden op de kluis in de webbrowser gebeurt altijd in het domein keepersecurity.com, keepersecurity.eu, keepersecurity.com.au, keepersecurity.jp, keepersecurity.ca of govcloud.keepersecurity.us, of vanuit de taakbalk van de Keeper-browserextensie die buiten de inhoudspagina bestaat.

De Keeper-browserextensie plaatst een iFrame voor inde aanmeldingsformulieren van een webpagina om ervoor te zorgen dat kwaadwillende websites geen toegang krijgen tot geïnjecteerde inhoud. De recordinhoud die wordt geïnjecteerd in iFrames is ook beperkt tot de kluisrecords zoals opgeslagen in de kluis van de gebruiker, die overeenkomt met het domein van de doelwebsite. Keeper biedt geen automatisch invullen van aanmeldings- of wachtwoordgegevens aan, tenzij het websitedomein overeenkomt met het websitedomeinveld van de Keeper-kluisrecord. De extensie geeft geen records weer, tenzij de records overeenkomen met het hoofddomein van het website-adres.

Browserextensies van externe partijen hebben mogelijk hogere machtigingen in browsers en toegang tot informatie binnen de pagina. Het wordt daarom aangeraden dat Keeper-beheerders voorkomen dat gebruikers niet-goedgekeurde browserextensies van externe partijen installeren vanuit de betreffende app store van de browser.

Biometrische gegevens

Keeper ondersteunt Windows Hello, Touch ID, Face ID en Android biometrische gegevens. Klanten die normaal gesproken zich aanmelden bij hun Keeper-kluis met een hoofdwachtwoord of Enterprise SSO Login (SAML 2.0) kunnen zich ook aanmelden bij hun apparaten via biometrische gegevens. Biometrische gegevens moeten worden ingeschakeld door de Keeper-beheerder volgens het rollenbeleid. Offline toegang kan ook mogelijk worden gemaakt met biometrische gegevens voor zowel het hoofdwachtwoord als SSO-ingeschakelde gebruikers wanneer deze functie is geactiveerd.

Wanneer biometrische aanmelding is ingeschakeld op een apparaat, wordt er lokaal willekeurig een sleutel gegenereerd en opgeslagen in de veilige enclave (bijv. Keychain of Keystore) van het apparaat. De gegevenssleutel van de gebruiker wordt versleuteld met de biometrische sleutel. Na succesvolle biometrische authenticatie, wordt de sleutel opgehaald en kunnen gebruikers hun kluis ontcijferen.

iOS-sleutelhanger, Touch ID en Face ID

Touch ID en Face ID op iOS-apparaten bieden gebruikers toegang tot uw Keeper-kluis via biometrie. Voor deze handige functie wordt een willekeurig gegenereerde 256-bits 'biometrische sleutel' opgeslagen in de iOS-sleutelhanger. De iOS-sleutelhanger die voor deze functionaliteit is gemaakt, is niet aangewezen om te synchroniseren met de iCloud-sleutelhanger en zal uw iOS mobiele apparaat dus niet verlaten.

Het wordt ten zeerste aanbevolen een complex hoofdwachtwoord te gebruiken en Multi-factor authenticatie in te schakelen om uw versleutelde Keeper-kluis maximaal te beveiligen. Als u Touch ID en Face ID gebruikt, is het handiger om een complex hoofdwachtwoord te gebruiken op uw mobiele iOS-apparaat. Het wordt ook aanbevolen om een wachtwoord in te stellen dat langer is dan de minimale 4 cijfers om de iOS-sleutelhanger te beveiligen.

De iOS-sleutelhanger wordt door iOS en apps gebruikt om veilig aanmeldingsgegevens op te slaan. iOS-apps gebruiken de iOS-sleutelhanger om verschillende vertrouwelijke gegevens op te slaan, waaronder wachtwoorden voor websites, sleutels, creditcardnummers en Apple Pay™-informatie. Keeper gebruikt de iOS-sleutelhanger niet om uw Keeper-records op te slaan (alle Keeper-records worden beschermd met 256-bits AES versleuteling en worden veilig opgeslagen in de Keeper-kluis). De iOS-sleutelhanger wordt ook versleuteld met 256-bits AES versleuteling via de toegangscode van het apparaat. Zelfs als het apparaat verloren gaat of wordt gestolen, of als een aanvaller fysieke toegang verkrijgt tot het mobiele apparaat, kan deze geen toegang krijgen tot eventuele opgeslagen Keeper-informatie. De iOS-sleutelhanger kan niet worden ontcijferd zonder de toegangscode en de Keeper-kluis kan niet worden ontcijferd zonder het hoofdwachtwoord voor Keeper van de gebruiker.

Apple Watch^®

Met de favorietenfunctie van Apple Watch kunt u de geselecteerde records op een gekoppelde Apple Watch bekijken. Keeper-records moeten specifiek ingeschakeld zijn voor weergave op de Apple Watch. Een gekoppelde Apple Watch communiceert met de Keeper Watch-extensie die overzichtelijk wordt uitgevoerd in een sandbox-ruimte los van de iOS Keeper-app. De Keeper Watch-extensie maakt ook gebruik van iOS Sleutelhanger om sleutels veilig op te slaan en toegankelijk te maken, om het zo naadloos en veilig te laten communiceren met de iOS Keeper-app.

Keeper DNA^®

Keeper DNA biedt een multi-factor-authenticatiemethode met behulp van een smartwatch. Keeper DNA gebruikt veilige tokens die zijn opgeslagen in de Keeper Vault om tijdgebaseerde codes te genereren voor multi-factor-authenticatie. Deze op tijd gebaseerde verificatieverzoeken kunnen automatisch worden goedgekeurd en verzonden vanaf de Apple Watch (of het Android Wear-apparaat) met een tik op het scherm van het horloge of handmatig worden ingevoerd door de gebruiker.

Verwijderen van werknemers (kluisoverdracht)

Wanneer een beleid voor accountoverdracht wordt geactiveerd voor een knooppunt, wordt het knooppuntbeleid voor een openbaar/privé sleutelpaar aangemaakt in de beheerconsole op het apparaat van de gebruiker. De gegevenssleutel van de eindgebruiker (voor gebruikers in een rol waarop handhaving wordt toegepast) wordt versleuteld met de openbare sleutel van het beleid wanneer de gebruiker zich aanmeldt bij de kluis. De privésleutel wordt versleuteld met de publieke sleutel van de beheerder en de beheerder kan vervolgens de sleutel voor de handhaving van de rol ontcijferen met een kluisoverdracht.

Als u een kluisoverdracht uitvoert, moet de beheerder eerst het account van de gebruiker vergrendelen. De kluisoverdracht kan dan onmiddellijk plaatsvinden, gevolgd door het verwijderen van het gebruikersaccount. Dit zorgt ervoor dat de handeling niet in het geheim wordt uitgevoerd. Bij het uitvoeren van de overdracht wordt de gegevenssleutel van de gebruiker opgehaald door eerst de privésleutel van de rolhandhaving uit te pakken en daarna de gegevenssleutel van de gebruiker. De gegevenssleutel wordt gebruikt om de recordsleutels, teamsleutels en mapsleutels uit te pakken.

Alle versleuteling wordt uitgevoerd aan de clientzijde binnen de beheerdersconsole en Keeper heeft op geen enkel moment de mogelijkheid om de informatie die wordt gedeeld of overgedragen te ontcijferen. Bovendien wordt de clientsleutel van een gebruiker op geen enkel moment gedeeld. Een gebruiker die uit een team, gedeelde map of direct share wordt verwijderd, ontvangt geen nieuwe gegevens van het team, de gedeelde map of het record. Hoewel de record-, map- en teamsleutels lokaal worden ontcijferd voor de beheerder tijdens de transactie, kunnen de sleutels niet worden gebruikt om toegang te krijgen tot de onderliggende record- of mapgegevens.

Tijdens de kluisoverdracht ontvangt de beheerder alleen de versleutelde gegevenssleutel, de versleutelde recordsleutels en de versleutelde mapsleutels. Ze ontcijferen deze sleutels, die vervolgens opnieuw worden versleuteld met de openbare sleutel van de doelkluis. Ze krijgen nooit toegang tot de feitelijke recordgegevens. Keeper versleutelt gegevens die op de client zijn opgeslagen niet rechtstreeks met de gegevenssleutel – dit wordt op het apparaat gedaan.

Certificering en naleving

Keeper is gepassioneerd over veiligheid. Keeper is de veiligste, meest gecertificeerde, meest geteste en geauditeerde wachtwoordbeveiligingsoplossing en PAM-platform ter wereld. Keeper heeft de langstlopende SOC 2- en ISO-certificeringen in de branche. Keeper is ISO 27001, 27017 en 27018 gecertificeerd. Keeper houdt zich aan de AVG, CCPA en HIPAA, en is FedRAMP en StateRAMP Authorized, PCI DSS gecertificeerd en gecertificeerd door TrustArc voor privacy.

• De softwareontwikkelingsteams van Keeper bestaan uit fulltime werknemers in de VS.
• Keeper slaat geen wachtwoorden, aanmeldingsgegevens of geheimen zoals toegangssleutels op in de broncode. We scannen de broncode regelmatig op deze informatie.
• De broncode van Keeper, die privé wordt bewaard in GitHub Enterprise, biedt niet de informatie die nodig is om toegang te krijgen tot de kluis van een gebruiker, aangezien de versleuteling van gegevens plaatsvindt op apparaatniveau. Een groot deel van deze code wordt gepubliceerd in onze openbare GitHub-opslag als onderdeel van de producten Commander en Secrets Manager van Keeper.
• Keeper sluit geen MFA-providercode van derden in onze apps in. De leveranciers van Keeper zijn niet betrokken geweest bij lekken waarbij Keeper betrokken was.
• Keeper biedt derden geen beheer of toegang tot onze AWS-datacentra. Al het beheer wordt uitgevoerd door fulltime werknemers van Keeper Security die Amerikaanse staatsburgers zijn en zich in de VS bevinden.

FIPS 140-3-gevalideerd

Keeper maakt gebruik van FIPS 140-3 gevalideerde versleutelingsmodules om te voldoen aan robuuste overheidsvereisten en vereisten van de publieke sector. De versleuteling van Keeper is gecertificeerd door het NIST CMVP (Cryptographic Module Validation Program) en gevalideerd volgens de FIPS 140-norm door geaccrediteerde externe laboratoria.

Keeper uses FIPS 140-3 validated encryption that has been issued certificate #4743 under the NIST CMVP.

ITAR-compliant

Keeper Security Government Cloud (KSGC) ondersteunt naleving van de International Traffic in Arms Regulations (ITAR) van de Verenigde Staten. Bedrijven die zich dienen zich te houden aan ITAR-exportregels moeten onbedoelde uitvoer voorkomen door de toegang tot beschermde gegevens van Amerikaanse burgers te beperken en door de fysieke locatie van beschermde gegevens voor te behouden aan de VS.

KSGC’s FedRAMP Moderate-omgeving ondersteunt ITAR-vereisten via het volgende:

• Gegevensopslag met volledige naleving, gehost op AWS GovCloud en beperkt tot de VS.
• KSGC biedt veilige gegevensversleuteling onderweg en in ruste.
• Met zero-knowledge en zero-trust beveiliging, in combinatie met granulaire machtigingen, kunnen organisaties ervoor zorgen dat alleen goedgekeurd personeel toegang heeft tot gevoelige gegevens.
• Robuuste nalevingsrapportages met een traceerbaar, elektronisch auditspoor van alle uitgevoerde acties en ingevoerde gegevens.
• Het Sequestered Customer Success-team bestaat uit Amerikaanse burgers die speciaal zijn getraind in de veilige verwerking van gegevens die worden gecontroleerd voor export en onderhevig zijn aan ITAR, zonder ondersteuning buiten de VS.

De Keeper FedRAMP-omgeving wordt gecontroleerd door een onafhankelijke externe beoordelingsorganisatie (3PAO) om te verifiëren dat de juiste controlemechanismen worden gebruikt om de exportnalevingsprogramma's van klanten te ondersteunen en wordt nog steeds jaarlijks gecontroleerd zoals vereist om naleving te handhaven.

Meer informatie over ITAR.

Geautoriseerd door FedRAMP

KSGC is het wachtwoordbeheer- en cyberbeveiligingsplatform van Keeper Security voor organisaties in de publieke sector. KSGC is een door FedRAMP geautoriseerde provider op het Moderate Impact Level, gehost in AWS GovCloud (US). KSGC vindt u op de FedRAMP-marketplace.

Het Federal Risk & Authorization Management Program (FedRAMP) is een Amerikaans federaal overheidsprogramma dat een gestandaardiseerde benadering biedt voor beveiligingsbeoordeling, autorisatie en doorlopende monitoring voor cloudproducten en services. FedRAMP helpt de implementatie van veilige cloudoplossingen door overheidsinstanties te versnellen met de nadruk op beveiliging en bescherming van federale informatie. Meer informatie over FedRAMP.

StateRAMP geautoriseerd

StateRAMP is ongeveer tien jaar na FedRAMP ontwikkeld, met als doel de invoering van veilige cloudoplossingen op staats- en lokaal overheidsniveau aan te moedigen. Het verkrijgen van een StateRAMP-autorisatie is normaal gesproken een proces van twee jaar dat werd gestroomlijnd door middel van een wederkerigheidsprogramma dankzij Keeper's FedRAMP-autorisatie.

SOC 2-naleving

Kluisrecords van klanten worden beschermd met strikte en streng gecontroleerde interne controlemaatregelen. Keeper is al meer dan tien jaar gecertificeerd en in naleving van SOC 2 Type 2, in overeenstemming met het AICPA Service Organization Controle-framework. Met SOC 2-naleving zorgen we ervoor dat gebruikerskluizen veilig blijven via de implementatie van gestandaardiseerde controles en gedefinieerd in het AICPA Trust Service Principles-framework.

ISO-certificeringen

Keeper is ISO 27001, 27017 en 27018 gecertificeerd, en biedt het Keeper Security-informatiesysteem en cloudinfrastructuur, wat het Keeper Enterprise-platform ondersteunt. Keeper's ISO-certificeringen zijn inclusief het beheer en de werking van de digitale kluis en cloudservices, controlemiddelen voor beveiliging van de cloud, controlemiddelen voor gegevensprivacy, software- en appontwikkeling en bescherming van digitale middelen voor zowel de digitale kluis als cloudservices.

In overeenstemming met FDA 21 CFR Part 11

Keeper is in overeenstemming met 21 CFR Part 11, wat van toepassing is op wetenschappers die in sterk gereguleerde omgevingen werken, waaronder onderzoekers die klinische proeven uitvoeren. Deze regulering specificeert de FDA-criteria waaronder elektronische records en handtekeningen als betrouwbaar en equivalent aan papieren records met handgeschreven handtekeningen worden beschouwd. Meer specifiek: wetenschappers moeten ervoor zorgen dat alle software die ze gebruiken in overeenstemming is met de regels van 21 CFR Part 11, betreffende:

Beveiligingscontroles voor gebruikersidentificatie - Keeper voldoet aan de vereisten van 21 CFR Part 11 voor beveiligingskenmerken die de gebruikerstoegang en bijbehorende privileges beperken, waaronder ervoor zorgen dat alle gebruikers unieke gebruikersnamen en wachtwoorden hebben, de mogelijkheid om onbevoegde toegang tot het systeem te detecteren en voorkomen, en de mogelijkheid om gecompromitteerde accounts te vergrendelen.

Gedetailleerd auditspoor

Tijdens FDA-inspecties moeten onderzoekers een gedetailleerd auditspoor overleggen, met een chronologisch overzicht van alle operaties. Met Keeper's functies voor nalevingsrapportage kunnen onderzoekers eenvoudig traceerbare elektronische auditsporen produceren.

Elektronische handtekeningen

Wanneer een document een wettelijk bindende elektronische handtekening vereist, verzoekt 21 CFR Part 11 u om de handtekening te koppelen aan een unieke aanmeldings- en wachtwoord- of biometrische identificatie.

Meer informatie over 21 CFR Part 11 vindt u hier.

Bescherming van medische patiëntgegevens

Keeper-software voldoet aan internationale medische gegevensbeschermingsnormen, waaronder, zonder beperking de HIPAA (Health Insurance Portability and Accountability Act) en DPA (Data Protection Act).

HIPAA-naleving en zakenpartnersovereenkomsten

Keeper is een SOC2-gecertificeerd en ISO 27001-gecertificeerd zero-knowledge beveiligingsplatform dat voldoet aan HIPAA. Zorgverleners en zorgverzekeraars gebruiken Keeper om elektronische patiëntendossiers met volledige versleuteling veilig te bewaren. Daarnaast zijn er strenge nalevings- en controleregels met betrekking tot de privacy, vertrouwelijkheid, integriteit en beschikbaarheid. Met deze beveiligingsarchitectuur kan Keeper geen informatie, waaronder elektronische patiëntendossiers, ontcijferen, bekijken of laden als deze zijn opgeslagen in de Keeper-kluis. Hierdoor is Keeper geen zakenpartner zoals gedefinieerd in de Health Insurance Portability and Accountability Act (HIPAA) en derhalve niet onderhevig aan een zakenpartnerovereenkomst.

Voor meer informatie over de aanvullende voordelen voor zorgverleners en zorgverzekeraars leest u de volledige beveiligingsverklaring en bezoekt u onze gids voor grote ondernemingen.

FSQS-NL-gecertificeerd

Keeper Security EMEA Limited is gecertificeerd volgens het Hellios Financial Services Qualification System-Netherlands (FSQS-NL), wat de hoogste normen op het gebied van beveiliging, kwaliteit en innovatie erkent in Nederland. Deze norm staat voor naleving van de Financial Conduct Authority en de Prudential Regulation Authority om de betrouwbaarheid van Keeper Enterprise-software voor grote banken en financiële instituten te waarborgen.

U.S. Department of Commerce Export Licensed Under EAR

Keeper is gecertificeerd door het Bureau of Industry and Security van het Amerikaanse Ministerie van Handel onder Export Commodity Classification Control Number 5D992, conform de Export Administration Regulations (EAR).
Voor meer informatie over EAR: https://www.bis.doc.gov

Permanente bewaking op afstand

Keeper wordt dag en nacht, alle dagen van het jaar, gemonitord door fulltime DevOps-personeel en een internationaal extern netwerk om ervoor te zorgen dat onze website en Cloud Security Vault wereldwijd beschikbaar zijn.

ij vragen over deze beveiligingsverklaring kunt u contact met ons opnemen.

Phishing- of gespoofde e-mails

Als u een e-mail ontvangt die schijnbaar afkomstig is van Keeper Security en u niet zeker weet of dit wel echt zo is, is het mogelijk een 'phishing-mail' waarbij het e-mailadres niet klopt of 'spoofed' is. In dat geval kan een e-mail koppelingen bevatten naar een website die lijkt op KeeperSecurity.com, maar niet onze site is. De website vraagt mogelijk naar uw hoofdwachtwoord voor Keeper Security of probeert ongewenste software op uw computer te installeren in een poging om uw persoonlijke gegevens te stelen of toegang te krijgen tot uw computer. Andere e-mails bevatten koppelingen die u doorsturen naar andere, potentieel gevaarlijke, websites. Het bericht bevat mogelijk ook bijlagen met ongewenste software, oftewel 'malware'. Als u twijfelt over een e-mail die u in uw inbox hebt ontvangen, moet u deze verwijderen zonder op koppelingen te klikken of zonder bijlagen te openen.

Als u een e-mail ontvangt die schijnbaar van Keeper is maar waarvan u denkt dat deze vals is of als u andere zorgen heeft over beveiliging, kunt u contact opnemen met ons.

Gecertificeerde hostinginfrastructuur volgens de strengste industrienormen

De Keeper-website en opslag in de cloud werkt via de veilige Amazon Web Services (AWS) cloudcomputing-infrastructuur. De AWS-cloudinfrastructuur die Keeper's systeemarchitectuur host is gecertificeerd en voldoet aan de volgende attesten, rapporten en certificeringen van derde partijen:

Kwetsbaarheidsrapportage en Bug Bounty-programma

Keeper Security is toegewijd aan het ontwikkelen van de meest veilige oplossing voor het beheren van wachtwoorden en bevoorrechte toegang op de markt. Wij zetten ons in om de privacy en persoonlijke gegevens van onze klanten te beschermen. Het is onze missie om 's werelds veiligste en meest innovatieve beveiligingsapps te bouwen, en we zijn van mening dat bugrapporten van de wereldwijde gemeenschap van beveiligingsonderzoekers een waardevol onderdeel zijn om de beveiliging van Keepers producten en services te garanderen.

Keeper voert uitgebreide interne en externe tests uit, waaronder pentests door NCC Group en CyberTest met volledige toegang tot de broncode. Keeper beheert haar programma voor het openbaar maken van kwetsbaarheden in samenwerking met Bugcrowd. Alles bij elkaar komt dit de hele branche ten goede en ondersteunt het bovendien het maatschappelijk welzijn.

Richtlijnen

In het ontsluitingsbeleid van kwetsbaarheden van Keeper worden onze verwachtingen uiteengezet bij het werken met goedwillende hackers, plus wat u van ons kunt verwachten.

Wanneer beveiligingstests en -rapporten worden uitgevoerd binnen de richtlijnen van dit beleid:

• Beschouwen we deze als geautoriseerd in overeenstemming met de Computer Fraud and Abuse Act,
• Beschouwen we deze als uitgesloten van de DMCA en spannen we geen rechtszaak tegen u aan voor het omzeilen van enige beveiligings- of technologische controles,
• Beschouwen we deze als legaal en nemen of ondersteunen wij geen strafrechtelijke stappen in verband met dit programma jegens u,
• Werken we samen met u om de kwestie te begrijpen en snel te verhelpen.
• Erkennen we uw bijdragen publiekelijk als u de eerste bent die de kwestie rapporteert, en voeren we een code- of configuratiewijziging door op basis van de kwestie.

Als u zich op welk moment dan ook zorgen maakt of onzeker bent over testen op deze manier, of dit wel consistent is met de richtlijnen en de reikwijdte van dit beleid, kunt u contact met ons opnemen via security@keepersecurity.com voordat u verdergaat.

Om goedwillende beveiligingstests te stimuleren, evenals de ontsluiting van ontdekte kwetsbaarheden, vragen we u:

• Vermijden we het schenden van de privacy, evenals het negatief beïnvloeden van de gebruikerservaring, het storen van de productie of bedrijfssystemen, en/of het vernietigen van gegevens,
• Voeren we onderzoek uitsluitend binnen het bereik uit zoals bepaald door het Bugcrowd-kwetsbaarheidsontsluitingsprogramma zoals hieronder gelinkt, en respecteren we systemen en activiteiten die buiten bereik vallen.
• Neem onmiddellijk contact met ons op via security@keepersecurity.com als u gebruikersgegevens aantreft tijdens het testen.
• Geef ons redelijk de tijd om de gemelde kwestie te analyseren, bevestigen en herstellen voordat u enige kwetsbaarheid die u hebt gevonden openbaar maakt.

Stuur rapporten in via: https://bugcrowd.com/keepersecurity

Transparantie

Keeper is niet alleen toegewijd aan beveiliging; we zijn er gepassioneerd over. Daarom maken we elk detail van ons versleutelingsmodel openbaar. Wij zijn van mening dat onze klanten het verdienen om te weten welke stappen we nemen om ervoor te zorgen dat hun gegevens veilig zijn in een steeds veranderend cyberbeveiligingslandschap.

Het zero-trust en zero-knowledge versleutelingsmodel van Keeper zorgt ervoor dat uw Keeper-kluis zelfs in het ergste geval beschermd is, en we voeren voortdurend beveiligingstests uit om ervoor te zorgen dat we de beste oplossing blijven om uw meest waardevolle gegevens te beschermen.

Productdocumentatie

Keeper’s documentatieportal met producthandleidingen, technische informatie, release-opmerkingen en gidsen voor de eindgebruiker is beschikbaar via deze link.

Opmerkingen over productreleases

Voor een betere transparantie publiceert Keeper gedetailleerde release-opmerkingen voor elk platform.

Systeemstatus

Een realtime systeemstatus vindt u hier.