Keeper se toma muy en serio la seguridad de las credenciales y la protección de datos

Descripción general

Keeper Security, Inc. se preocupa por proteger la información de sus clientes con software de seguridad de Keeper para celular y escritorio. Millones de clientes y negocios ya confían en Keeper para proteger y acceder a sus contraseñas e información privada.

El software de Keeper se mejora y actualiza de forma constante para ofrecer a nuestros clientes lo último en tecnología y protección. Esta página ofrece un resumen de la arquitectura de seguridad de Keeper, de las metodologías de cifrado y del entorno de alojamiento a partir de la versión actual publicada. En este documento se describen los detalles técnicos de nuestros métodos de cifrado y seguridad.

Puede acceder a las condiciones de uso y a la política de privacidad en nuestro sitio web desde los siguientes enlaces:

Plataforma de confianza cero

Keeper utiliza una arquitectura de confianza cero que asegura que cada usuario se verifica y autentica antes de que pueda acceder a un sitio web, aplicación o sistema.

Enterprise Password Management (EPM) de Keeper ofrece a las empresas visibilidad y control totales sobre las prácticas que los empleados tienen con sus contraseñas, lo que permite a los administradores de TI supervisar el uso de las contraseñas y aplicar las mejores prácticas de seguridad.

Keeper Secrets Manager (KSM) ofrece a los equipos de ingeniería una plataforma para gestionar todas las credenciales, incluidos los secretos de infraestructura, las claves SSH, las claves API y certificados con SDK e integración CI/CD.

Keeper Connection Manager (KCM) es una puerta de enlace de escritorio remoto que ofrece a los equipos de DevOps y TI un acceso de red de confianza cero y sin esfuerzos al RDP, al SSH, a bases de datos, a aplicaciones web internas y a los puntos de conexión de Kubernetes a través de un navegador y sin necesidad de un agente.

La mejor seguridad del sector de Keeper al detalle

Cifrado de los datos de la bóveda

Keeper ofrece un modelo de cifrado de varias capas basado en el principio de mínimo privilegio. Las claves AES de 256 bits a nivel de registro y carpeta se generan en el dispositivo cliente, que cifra cada registro guardado en la bóveda. Los registros de la bóveda y todo su contenido se cifran por completo, incluidos los inicios de sesión, los archivos adjuntos, los códigos TOTP, la información de pagos, las URL y los campos personalizados.

Las claves de cifrado se generan localmente en el dispositivo para conservar el conocimiento cero y asistir a las funciones avanzadas, como el uso compartido de registros y carpetas. El conocimiento cero significa que cada usuario tiene un control completo sobre el cifrado y descifrado de toda la información personal en su Keeper Vault y que nadie puede acceder a esa información almacenada, ni siquiera los empleados de Keeper.

Las claves de registro y carpeta se cifran con una clave de datos AES de 256 bits única para cada usuario y generada en su dispositivo.

En el dispositivo del usuario, se genera otra clave de cliente AES de 256 bits para cifrar una caché local sin conexión (si el administrador de su empresa permite el acceso sin conexión). Finalmente, la clave de datos AES de 256 bits se cifra con otra clave, tal y como se describe en la siguiente sección.

Métodos de cifrado de la bóveda

Keeper cifra los datos de diferentes maneras en función de cómo acceden los usuarios. Para consumidores y miembros del plan familiar, se usa una contraseña maestra y la autenticación con biometría. Para los usuarios de negocios y empresas que acceden con SSO, Keeper utiliza el cifrado de curva elíptica para ofrecer una experiencia segura y sin contraseñas.

Para aquellos usuarios que acceden con contraseña maestra: la clave para descifrar y cifrar la clave de datos se deriva de la contraseña maestra del usuario utilizando la función de variación de clave basada en contraseña (PBKDF2), con 1 millón de iteraciones. Cuando el usuario introduce su contraseña maestra, la clave se deriva localmente y después desenvuelve la clave de datos. Esta clave se descifra y se utiliza para desenvolver las claves de carpeta y registro individuales. El descifrado de cada clave almacena el contenido del registro localmente en el dispositivo del usuario.

Para usuarios que inician sesión con SSO o con una tecnología sin contraseñas: la criptografía de curva elíptica se usa para cifrar y descifrar datos a nivel de dispositivo. Se usa una clave privada local ECC 256 (secp256r1) para descifrar la clave de datos. Cuando se descifra la clave de datos, se usa para desenvolver las claves de registro y carpeta individuales. Después, la clave de registro descifra cada uno de los contenidos de registro almacenados. La clave de datos cifrada se transmite entre los dispositivos del usuario a través de un sistema push o servicio de intercambio de claves, llamado aprobación de dispositivos. Para conservar el conocimiento cero, la aprobación de dispositivos la realiza el usuario final de forma local.

Modelo de cifrado del SSO

Flujo del primer dispositivo (incorporación de usuarios nuevos)

1. Se generan la clave de datos, el par de claves para compartir y el par de claves privada/pública de CE del dispositivo
2. La clave de datos se cifra con la clave pública de CE del dispositivo y se almacena en la nube (DEDK)
3. El usuario inicia sesión con su proveedor de identidades (IdP)
4. Tras iniciar sesión con el IdP, se verifica la aserción SAML firmada por Keeper
5. Se crea la bóveda y se da de alta al usuario

Flujo del dispositivo existente

1. El usuario inicia sesión con su proveedor de identidades (IdP)
2. Tras iniciar sesión con el IdP, se verifica la aserción SAML firmada por Keeper
3. Keeper entrega al usuario la clave de datos cifrada del dispositivo (DEDK)
4. La clave de datos se cifra con la clave privada de curva elíptica del dispositivo
5. La clave de datos descifra las claves de carpetas y registros
6. Las claves de registros descifran el contenido de los registros

Flujo del dispositivo nuevo o no reconocido

1. En cada dispositivo nuevo, se genera un par de claves pública/privada de curva elíptica
2. El usuario inicia sesión con su proveedor de identidades (IdP)
3. Tras iniciar sesión con el IdP, se verifica la aserción SAML firmada por Keeper
4. El dispositivo se "aprueba" mediante Keeper Push, por el administrador o con el servicio de Keeper Automator (*ver Aprobación de dispositivos)
5. Durante el proceso de aprobación, la clave de datos se cifra con la clave pública del dispositivo nuevo
6. La clave de datos cifrada en el dispositivo (DEDK) se envía al usuario

Aprobación de dispositivos

• La aprobación de dispositivos es un mecanismo para enviar de forma segura la clave de datos del usuario al dispositivo nuevo mientras se conserva el conocimiento cero
• El usuario puede aprobar su dispositivo cifrando la clave de datos con la clave pública del dispositivo nuevo
• El administrador puede aprobar el dispositivo desde la consola de administración, el servicio de Keeper Commander o Keeper Automator
• El administrador descifra la clave de datos del usuario y la vuelve a cifrar con la clave pública del dispositivo nuevo.
• El servicio de Keeper Automator puede realizar aprobaciones automáticas de dispositivos en la infraestructura del cliente
• Keeper Automator comprueba la firma SAML, desenvuelve la clave de datos y la cifra con la clave pública del dispositivo nuevo

Descubra más sobre el servicio de Keeper Automator.

Seguridad a nivel de dispositivo para SSO Connect Cloud

Para los usuarios de SSO Connect Cloud, se genera una clave privada de curva elíptica que se almacena localmente en cada dispositivo. En navegadores web modernos y en la aplicación de Keeper Desktop basada en Electron, el Keeper Vault guarda la clave privada CE del dispositivo local (“DPRIV”) como una clave criptográfica no exportable. En dispositivos iOS y macOS, la clave se almacena en el llavero del dispositivo. En dispositivos Android, la clave se cifra con Android Keystore, utilizando las preferencias compartidas cifradas. Si están disponibles, Keeper utiliza mecanismos de almacenamiento seguros en cada sistema operativo.

La clave privada del dispositivo no se utiliza directamente para cifrar o descifrar los datos de la bóveda. Después de autenticar correctamente desde el proveedor de identidades, se utiliza una clave distinta (no almacenada) para descifrar los datos de la bóveda. Por lo tanto, la extracción sin conexión de la clave privada del dispositivo local no puede descifrar la bóveda de un usuario.

Cifrado de datos en reposo

Keeper utiliza AWS para alojar la plataforma y la arquitectura de Keeper. Nuestros centros de datos AWS se encuentran en diferentes ubicaciones geográficas y nuestros clientes pueden alojar a su inquilino de Keeper en la región primaria que prefieran. Esto asegura que los datos del cliente y el acceso a la plataforma se aislarán en esa región específica.

Los datos de la bóveda en reposo se cifran en el dispositivo del usuario de forma local usando el método GCM AES de 256 bits. Los datos cifrados en tránsito se cifran con TLS 1.3 con una capa adicional de cifrado en la carga de datos. Los datos del cliente se aíslan usando el cifrado a nivel de registro.

El modelo de cifrado de Keeper se adhiere a la siguiente estructura:

• Todas las bóvedas se cifran con una clave AES de 256 bits única y generada en el lado del cliente en el modo GCM.
• Todas las claves a nivel de registro en carpetas compartidas se envuelven con una clave de carpeta compartida AES de 256 bits.
• Las claves de registro y carpeta para los usuarios de bóvedas se cifran con otra clave AES de 256 bits denominada clave de datos.
• Para Keeper Secrets Manager (KSM), las claves de registro y carpeta del usuario se cifran con una clave de aplicación AES de 256 bits.
• Para aquellos usuarios que inician sesión con una contraseña maestra, las claves para cifrar y descifrar se derivan de la contraseña maestra.
• El inicio de sesión con tecnología SSO o sin contraseñas utiliza la criptografía de curva elíptica para cifrar y descifrar los datos en el dispositivo.
• Cada carga de datos cifrada se envía a los servidores de Keeper y se envuelve con una clave de transmisión AES de 256 bits con TLS para proteger contra los ataques de intermediario (MITM). La clave se genera en el cliente y se transfiere usando el cifrado ECIES a través de la clave pública de curva elíptica del servidor.
• El intercambio seguro de secretos entre usuarios utiliza la distribución de claves de criptografía de curva elíptica.

Control de versiones de los registros

Keeper conserva un historial de versiones cifrado de cada registro guardado en la bóveda del usuario, lo que asegura que nunca se pierden datos importantes. Desde la aplicación cliente de Keeper, los usuarios pueden examinar el historial del registro y restablecer cualquier registro individual de la bóveda. Si se cambia o elimina un archivo o contraseña almacenado en Keeper, el usuario siempre tiene la opción de hacer una restauración puntual.

Keeper Business

Los clientes que compran Keeper Business cuentan con una capa de control adicional sobre sus usuarios y dispositivos. A los administradores de Keeper se les facilita acceso a la consola de administración basada en la nube con la que pueden controlar por completo el alta y baja de usuarios, los permisos basados en roles, la administración delegada, los equipos, la integración Active Directory/LDAP, la autenticación de dos factores, el inicio de sesión único (SSO) y las políticas de aplicación de la seguridad. Las políticas de aplicación basadas en roles de Keeper son completamente personalizables y ampliables al tamaño de cualquier organización.

Supercifrado de los datos en reposo

Además de almacenar únicamente el texto cifrado en el dispositivo en la infraestructura de AWS, Keeper también realiza un supercifrado con módulos de seguridad de hardware (HSM) multirregión utilizando claves no exportables.

Cifrado y protección de copias de seguridad

A nivel de producto/usuario, el software de Keeper conserva un historial completo de revisiones de cada registro. Por lo tanto, si un usuario quiere recuperarlo, puede ver y revertir a las versiones anteriores de los registros almacenados en Keeper en cualquier momento sin límites a través de la interfaz de usuario.

A nivel de sistema, las bases de datos cifradas y los objetos de archivo de Keeper se replican y se realizan copias de seguridad en varias regiones geográficas con fines de recuperación en caso de desastre. Todas las copias de seguridad se cifran con AES-256 además del supercifrado del texto cifrado generado por el dispositivo.

En el caso de aquellos clientes que necesitan ayuda con la recuperación (por ejemplo, debido a que un cliente ha borrado accidentalmente una bóveda o una carpeta compartida), el equipo de asistencia de Keeper puede ayudarles en cualquier momento en un plazo de 30 días, ya sea para restablecer un usuario, una bóveda o una empresa completa.

Recuperación de cuentas

Una frase de recuperación de 24 palabras permite a los clientes de Keeper recuperar el acceso a sus Keeper Vault en caso de perder u olvidar su contraseña maestra.

Keeper ha implementado frases de recuperación usando la misma lista de palabras BIP39 utilizada para proteger las criptobilleteras. La lista de palabras usada en BIP39 es un conjunto de 2048 palabras empleadas para generar una clave de cifrado con 256 bits de entropía. Este método de recuperación se usa habitualmente en las billeteras de bitcoins y criptomonedas más populares. Cada palabra de la lista BIP39 se selecciona cuidadosamente para mejorar la visibilidad y conseguir que el proceso de recuperación sea menos propenso a los errores. Los usuarios deben anotar su frase de recuperación y guardarla en un lugar seguro, como un almacén.

La frase de recuperación genera una clave AES de 256 bits que cifra una copia de la clave de datos del usuario. Para recuperar la cuenta y restablecer la contraseña maestra, el usuario necesitará una frase de recuperación junto con una verificación por correo electrónico y la autenticación de dos factores (2FA).

Los administradores empresariales pueden deshabilitar la recuperación de cuentas en el nivel de la política de aplicación de roles.

Claves de cifrado empresarial

Los clientes de Keeper Enterprise y Business pueden gestionar diferentes funciones de la plataforma de Keeper, como las políticas del acceso basado en roles, el aprovisionamiento, la autenticación y la gestión.

Las funciones de administración están protegidas por la plataforma de Keeper con cifrado y autorización. La autorización asegura que solo los usuarios designados pueden realizar ciertas funciones. El cifrado asegura que los administradores designados solo pueden llevar a cabo, de forma física y criptográfica, las funciones relacionadas con los datos de la bóveda o las claves controladas por la empresa. Estos son algunos ejemplos:

• La plataforma de Keeper es una plataforma de gestión de claves propiamente dicha, en la que usuarios y administradores tienen pleno control sobre sus claves privadas.
• Los pares de clave de cifrado pública y privada se utilizan para crear dispositivos, usuarios y equipos.
• Las políticas de roles para transferir bóvedas y aprobar dispositivos utilizan claves de cifrado privadas y públicas.
• Los pares de claves de curva elíptica (CE) se utilizan para compartir datos entre usuarios y desde el usuario individual hasta el administrador a nivel empresarial.
• Los datos de uso confidenciales, como la fortaleza de la contraseña de acceso, se cifran con claves públicas de la empresa que solo el administrador puede descifrar.
• Los campos de título de registro, URL y tipo de registro de cada registro de la bóveda del usuario empresarial se cifra con la clave pública empresarial y se puede descifrar en Keeper Admin Console por un administrador con privilegios para elaborar informes de conformidad.

Verificación de dispositivos

Antes de que el usuario pueda incluso intentar acceder a una cuenta, primero debe pasar por la verificación y aprobación del dispositivo. La verificación de dispositivos impide la enumeración de cuentas y protege contra los ataques de fuerza bruta.

Los clientes que inician sesión con una contraseña maestra pueden verificar dispositivos usando varios métodos, incluidos:

• Código de verificación por correo electrónico
• Entrada de código 2FA para una TOTP o mensaje de texto
• Usar Keeper Push^™ para enviar un mensaje a un dispositivo reconocido

Para aquellos clientes que se autentican con KeeperSSO Connect Cloud, la aprobación del dispositivo se hace con la transferencia de una clave, en la que se entrega al dispositivo la clave de datos cifrada del usuario, que se descifra localmente utilizando la clave privada de curva elíptica del usuario. Los métodos de aprobación de dispositivos incluyen los siguientes:

• Keeper Push (mediante notificaciones push) a los dispositivos de usuarios existentes
• Aprobación por administrador a través Keeper Admin Console
• Aprobación automática mediante el servicio Keeper Automator
• Aprobación automática del administrador mediante Commander CLI

Descubra más sobre la aprobación de dispositivos.

Privacidad de los datos

Keeper cumple con el RGPD y se compromete a garantizar que nuestros procesos y productos mantengan el cumplimiento del RGPD para nuestros clientes en la Unión Europea y en todo el mundo. 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.

Consulte la política de privacidad del RGPD de Keeper.

Ninguna de las aplicaciones de Keeper contiene rastreadores o librerías de terceros que rastreen. A modo de ejemplo, este informe ofrece información sobre la aplicación de Keeper para Android, en el que se muestra que no se ha instalado ningún rastreador.

Aislamiento de datos

Keeper es una plataforma SaaS totalmente gestionada y aloja sus datos en varios centros de datos de AWS aislados geográficamente. Las organizaciones pueden alojar a su inquilino de Keeper en su región principal preferida. Los datos de los clientes y el acceso a la plataforma quedan aislados en esa región específica.

Regiones disponibles:

• Estados Unidos (EE. UU.)
• Nube gubernamental de Estados Unidos (US_GOV)
• Europa (UE)
• Australia (AU)
• Japón (JP)
• Canadá (CA)

Cifrado en tránsito

La Keeper Vault está protegida con varias API, que se validan mediante autorización en el dispositivo del usuario.

• El usuario recupera un token de sesión con su acceso y lo envía con cada llamada a la API.
• El token de sesión se gestiona y controla en el servidor back-end.
• Se inicia sesión con una contraseña maestra, biometría, reanudación de sesión o autenticación SAML 2.0 SSO.

Cuando se utiliza una contraseña maestra, el dispositivo del usuario deriva una clave de autenticación de 256 bits usando PBKDF2-HMAC_SHA256 con 1.000.000 de iteraciones y una sal criptográfica aleatoria. Se crea un hash de autenticación mediante un resumen criptográfico de la clave de autenticación utilizando SHA-256. Al iniciar sesión, el hash de autenticación se compara con un hash de autenticación guardado en la Keeper Vault. Cuando el usuario inicia sesión, se crea un token de sesión en el servidor y se envía al usuario para que el dispositivo lo utilice en solicitudes posteriores a la API. Para permitir el uso continuado de las comunicaciones cliente-servidor, la sesión debe permanecer activa.

• Keeper utiliza el protocolo TLS de 256 bits y 128 bits para cifrar el 100 % de los datos almacenados en la aplicación del usuario y en el almacenamiento seguro de archivos de Keeper.
• Keeper utiliza certificados TLS firmados usando el algoritmo SHA2. El SHA2 es el algoritmo de firma más seguro actualmente disponible por las autoridades de certificación comerciales. El uso del SHA2 por parte de Keeper protege frente a los certificados falsificados que un atacante podría utilizar para suplantar la identidad de un sitio web.

Autenticación en la nube

Keeper ha creado un modelo avanzado de autenticación en la nube y comunicaciones en red con los más altos niveles de privacidad, seguridad, confianza y transparencia. Algunas características clave del modelo de autenticación son:

Integración con cualquier proveedor de SAML 2.0

Keeper se integra con todos los proveedores de identidad compatibles con SAML 2.0, como Okta, Microsoft Entra ID (Azure), AD FS, Google Workspace, Centrify, OneLogin, Ping Identity, JumpCloud, Duo, Auth0 y muchos más.

Nuestros productos ofrecen dos tipos de SSO diferentes: SSO Connect Cloud y SSO Connect On-Prem. Ambas implementaciones ofrecen una arquitectura de conocimiento cero con una autenticación sin complicaciones para los usuarios.

Las contraseñas maestras del usuario nunca se transmiten por la capa de red

A diferencia de los servicios SaaS, las credenciales de inicio de sesión de los usuarios de Keeper nunca salen de sus dispositivos. Cuando acceden a Keeper con contraseña maestra, se utiliza PBKDF2 en el dispositivo local para derivar una clave AES de 256 bits para el descifrado. Se genera una clave PBKDF2 adicional a nivel de dispositivo y después se resume con HMAC_SHA256 para crear un token de autenticación. Keeper no tiene ningún conocimiento sobre las claves de descifrado de los usuarios.

El tráfico entre el dispositivo del cliente y Keeper Cloud no se puede interceptar ni descifrar

Todas las cargas de datos cifradas enviadas a los servidores de Keeper se desenvuelven con una clave de transmisión AES de 256 bits y TLS para proteger frente a los ataques de intermediario (MITM). La clave de transmisión se genera en el dispositivo cliente y se transfiere al servidor usando el cifrado ECIES a través de la clave pública de curva elíptica del servidor.

Los dispositivos nuevos no pueden iniciar sesión en una cuenta sin superar el paso de verificación

Los usuarios no pueden utilizar dispositivos nuevos para acceder a sus cuentas de Keeper sin usar un método de verificación. Keeper es compatible con varios tipos de métodos de verificación, en función del esquema de autenticación.

La autenticación multifactor (MFA) se realiza después de la verificación, antes de que el usuario introduzca la contraseña maestra

Si el usuario tiene configurada la MFA, primero debe superar este primer paso antes de introducir su contraseña maestra.

No se puede introducir la contraseña maestra hasta que no se verifique el dispositivo y se realice el paso de la MFA correctamente.

Si no se ha configurado ningún método de verificación, el usuario no puede introducir su contraseña maestra. Esta avanzada autenticación protege frente a varios métodos de ataque comunes, como los ataques por fuerza bruta, la pulverización de contraseñas, la enumeración y los ataques MITM.

Autenticación multifactor (MFA)

Para impedir los ataques no autorizados a la cuenta de un cliente, Keeper ofrece la autenticación multifactor (MFA), un enfoque de la autenticación que requiere dos o más factores de autenticación, como un factor de conocimiento, otro de posesión y otro inherente. Descubra más sobre cómo configurar la MFA en Keeper.

Keeper utiliza su contraseña maestra y el dispositivo que posee para ofrecer una capa de seguridad adicional en caso de que la contraseña maestra o el dispositivo se vean vulnerados. Keeper es compatible con las claves de hardware WebAuthn de FIDO2 y las soluciones basadas en software como las TOTP y los SMS.

Cuando se utiliza un método TOTP MFA/2FA, Keeper genera una clave secreta de 10 bytes usando un generador de números aleatorios criptográficamente seguro. El código es válido durante alrededor de un minuto y no se puede reutilizar una vez que se ha realizado la autenticación correctamente. Keeper es compatible con cualquier aplicación TOTP, como Google Authenticator y Microsoft Authenticator. Keeper también se integra directamente con servicios MFA conocidos, como Duo y RSA SecurID.

Al utilizar autenticadores MFA, como Google Authenticator, Microsoft Authenticator y otras aplicaciones TOTP en su dispositivo móvil, el servidor de Keeper genera de forma interna un código QR que contiene su clave secreta. Cada vez que el usuario activa la MFA, se genera una clave nueva.

Para activar la MFA, acceda a la pantalla de ajustes en la Aplicación web de Keeper, de escritorio o para iOS/Android de Keeper. Los administradores de Keeper Business también pueden exigir el uso de la MFA y los métodos MFA compatibles a través de Keeper Admin Console

La compatibilidad con WebAuth de FIDO2 se facilita a través de Keeper, con dispositivos de llave de seguridad de hardware, como YubiKey y las llaves Google Titan, como factor adicional. Las claves de seguridad también se admiten como método 2FA utilizando dispositivos físicos o navegadores web. Las claves de seguridad proporcionan una forma segura de realizar la MFA sin necesidad de que el usuario introduzca códigos manualmente.

Android Smart Watch Apple Smart Watch DUO Entrust Google Authenticator Microsoft Authenticator RSA SecureID Mensaje de texto SMS Titan Security Key TOTP Yubico

Puente de Active Directory/LDAP de Keeper

Keeper Bridge se integra con Active Directory y los servidores LDAP para aprovisionar y dar de alta a usuarios. La comunicación de Keeper Bridge la autoriza primero un administrador con el privilegio para gestionar el puente. Se genera una clave de transmisión que se comparte con Keeper en todas las comunicaciones subsiguientes. El uso de la clave de transmisión es la autorización para todas las operaciones realizadas por el puente, excepto su inicialización. La clave de transmisión se puede regenerar en cualquier momento y se rotará automáticamente cada 30 días.

La clave de transmisión se usa solo para la transmisión, lo que significa que una clave vulnerada puede reinicializarse o revocarse sin ninguna pérdida de datos o permiso.

Keeper Bridge no puede dar privilegios a un rol o usuario. Puede añadir a un usuario a un rol privilegiado, siempre que no se necesiten claves de aplicación. Keeper Bridge no puede elevarse a sí mismo ni a un usuario por encima de la parte del árbol que está gestionando. No todas las operaciones están disponibles en el puente (por ejemplo, el puente puede desactivar a un usuario activo, pero no puede eliminarlo). El administrador tendrá que elegir si el usuario se va a eliminar o transferir.

Autenticación SSO con MFA

Cuando Keeper se implementa con una solución de SSO como Entra ID / Azure AD, Okta, Ping, Google Workspace o cualquier otro proveedor de identificación de SAML 2.0, la MFA se puede gestionar por completo durante el proceso de inicio de sesión de IdP. Keeper también admite las políticas de acceso de Azureen todos los tipos de dispositivos y aplicaciones.

La MFA se puede aplicar tanto en el lado del proveedor de identidades como en el lado de Keeper. Por ejemplo, cuando el usuario supera el paso de la MFA con el proveedor de identidades, puede que también tenga que superar un segundo paso en la interfaz de Keeper. Esta política la puede aplicar el administrador de Keeper.

Servicios web de Amazon CAS Centrify DUO F5 Google Workplace IBM Security JumpCloud Microsoft ADFS Onelogin Okta Ping Identity

Autenticación SAML 2.0 con SSO Connect Cloud

Keeper SSO Connect Cloud permite a los clientes empresariales integrar Keeper por completo con cualquier proveedor de identidad conforme con SAML 2.0 e implementar las bóvedas cifradas a sus usuarios.

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 es un servicio opcional que realiza aprobaciones instantáneas de equipos, aprobaciones de dispositivos y asignaciones de usuarios de equipos tras un inicio de sesión exitoso desde el proveedor de identificación SSO.

Una vez que Automator está en funcionamiento, los usuarios pueden acceder a Keeper sin problemas en los nuevos dispositivos (no aprobados previamente) tras una autenticación correcta con su proveedor de identificación, sin necesidad de seguir los pasos de aprobación.

Keeper SSO Connect On-Prem

Mientras que la mayoría de los clientes implementan Keeper SSO Connect Cloud, los clientes que requieren una solución local pueden implementar SSO Connect On-Prem, una integración autohospedada que requiere un servidor de aplicaciones alojado en Windows o Linux. Para poder mantener la seguridad de conocimiento cero y garantizar una experiencia de SSO sin problemas para los usuarios, Keeper SSO Connect debe instalarse en el servidor del cliente. Los entornos Windows, Mac y Linux son totalmente compatibles con los modos operativos de equilibrio de carga de alta disponibilidad (HA) y el supercifrado con los módulos de seguridad de hardware.

Keeper SSO Connect genera y mantiene la contraseña maestra de forma automática para cada usuario aprovisionado, que es una clave de 256 bits generada aleatoriamente. Esta contraseña maestra está cifrada con la clave de SSO. La clave de SSO está cifrada con la clave de árbol. La clave de SSO se recupera del servidor al iniciar el servicio de Keeper SSO Connect y, a continuación, se descifra mediante la clave de árbol, que se almacena de manera local en el servidor para permitir el inicio automático del servicio. La comunicación entre SSO Connect y Keeper's Cloud Security Vault está protegida con una clave de transmisión. Las comunicaciones SAML se firman criptográficamente y se protegen mediante el algoritmo de firma RSA-SHA256 o ECDSA-SHA256 en función del tipo de clave de cifrado (RSA o ECC) facilitado por el cliente.

Uso compartido

Keeper permite compartir registros de forma segura entre usuarios, con un equipo interno o incluso fuera de la organización (si el administrador de Keeper lo permite).

Compartir registros

Los usuarios de Keeper pueden compartir registros de forma directa entre ellos. Para ello, primero Keeper solicita la clave pública de curva elíptica del usuario desde su bóveda. Cada registro tiene una clave de registro que se cifra con la clave pública de curva elíptica del destinatario y se sincroniza con el Keeper Vault del usuario.

El propietario del registro compartido cifrado descifra la clave de registro con su clave privada de curva elíptica. La clave de registro también se volverá a cifrar con la clave de datos del usuario y el texto cifrado se guarda en la bóveda del destinatario.

Uso compartido único

El uso compartido único de Keeper permite compartir registros por tiempo limitado y de forma segura, como una contraseña, credencial, secreto, conexión, documento u otra información confidencial, con cualquier persona, incluso si esta última no tiene una cuenta de Keeper. El modelo de cifrado de uso compartido único de Keeper utiliza la misma tecnología que Keeper Secrets Manager (KSM), una plataforma de seguridad de conocimiento cero y confianza cero para proteger la infraestructura en la nube.

1. En el Keeper Vault del usuario, el originador genera un acceso único haciendo clic en Uso compartido único. La clave de registro AES de 256 bits se cifra con un token de acceso único y el valor cifrado se guarda en el Keeper Vault.
2. El usuario que comparte el token de acceso único con un destinatario utiliza una simple URL o un código QR. La parte de la URL que contiene el token de acceso se encuentra en la parte "indicador de fragmento" de la URL, que nunca se envía a los servidores de Keeper. Por lo tanto, Keeper no puede descifrar ni acceder a la información y así se conserva el conocimiento cero.
3. La URL se abre en el navegador del usuario y la aplicación de la bóveda se carga en el dispositivo. El token se entrega directamente a la aplicación de la bóveda local y no se envía al servidor.
4. Después, el destinatario utiliza su dispositivo para generar un par de claves CE en el lado del usuario final y la clave privada se almacena localmente, en el dispositivo, en el almacenamiento de claves criptográficas del navegador.
5. En el primer uso por parte del destinatario, la biblioteca SDK se autentica con el hash del token de acceso de un solo uso. Después, el servidor de Keeper responde con el texto cifrado del registro y la clave del registro cifrado.
6. El dispositivo descifra la clave de registro con el token de acceso único y el contenido se descifra. La clave se guarda en el dispositivo cliente en el almacenamiento de claves criptográficas del navegador o en otra ubicación de almacenamiento.
7. La clave del registro cifrado para ese dispositivo se elimina para que el token no se pueda volver a usar. Después, la solicitud del cliente debe firmarse con la clave privada.
8. Más llamadas al mismo dispositivo se envían con un identificador que define al dispositivo y una solicitud firmada con la clave privada del cliente. La solicitud para el identificador del dispositivo dado (a través de la firma ECDSA) utiliza la clave pública de cliente del dispositivo y el servidor la comprueba. Keeper procesa la solicitud y el servidor devuelve un registro en texto cifrado al dispositivo del usuario.
9. Además del cifrado a nivel de registro, el dispositivo cliente crea una clave de transmisión AES de 256 bits generada aleatoriamente que se cifra con la clave pública de la API de la nube de Keeper. El dispositivo cliente descifra la respuesta desde el servidor con la clave de transmisión y después descifra la carga útil de respuesta del texto cifrado con la clave de registro, que descifra el contenido del registro.

Compartir privilegios de administrador

La función de administrador con control de accesos de Keeper es un permiso de control de accesos basados en roles (RBAC) que otorga a los administradores privilegios elevados sobre las carpetas compartidas y los registros de una organización. Estos administradores tienen todos los privilegios de usuario y registro para cualquier registro compartido al que tengan acceso.

Modelo de cifrado de Secrets Manager

Keeper Secrets Manager es una plataforma de conocimiento cero para profesionales de TI y DevOps que permite a los equipos gestionar los secretos a lo largo del ciclo de vida de desarrollo e implementación del software.

Secrets Manager usa el siguiente modelo de cifrado:

• El cifrado y el descifrado se realizan de manera local en el dispositivo (no en el servidor).
• Nunca se almacena texto plano en el dispositivo.
• El servidor nunca recibe texto plano.
• Nadie puede descifrar los secretos, ni los empleados de Keeper, ni terceros, ni intermediarios.
• El dispositivo cliente gestiona las claves para cifrar y descifrar secretos con el control del usuario.
• Cada secreto se cifra con un cifrado AES de 256 bits generado en el lado del cliente en el modo GCM.
• Si el secreto se contiene en una carpeta compartida, la clave de registro se envuelve con una clave de carpeta compartida.
• Se genera una clave de aplicación AES de 256 bits en el lado del cliente y se utiliza para descifrar las claves de registro y carpeta compartida. Después, la clave de registro descifra el secreto individual.
• Los servidores de Keeper se envuelven con una clave AES de 256 bits con TLS para proteger frente a los ataques MITM.
• La clave de transmisión se genera en el dispositivo cliente y se transfiere al servidor usando el cifrado ECIES a través de la clave pública de curva elíptica del servidor.
• La criptografía de curva elíptica se utiliza para compartir secretos entre usuarios y distribuir las claves de forma segura.
• El cifrado de varias capas ofrece control de acceso a nivel de usuario, grupo y administrador.
• Los secretos gestionados en la bóveda se segmentan y aíslan en dispositivos Secrets Manager definidos a los que se concede acceso al registro y a la carpeta.

Modelo de Keeper Secrets Manager para la rotación de contraseñas

• Se instala un cliente Keeper Secrets Manager (KSM) único, denominado puerta de enlace, en el entorno del cliente.
• La puerta de enlace establece una conexión de salida segura al enrutador de Keeper.
• El enrutador es un servicio en la nube alojamientoado en el entorno AWS de Keeper, lo que facilita la comunicación entre la API backend de Keeper, las aplicaciones de usuario final (almacén web, aplicación de escritorio, etc.) y las puertas de enlace instaladas en el entorno del usuario.
• Los websockets se establecen entre el dispositivo del usuario final (p. ej., el almacén web) y el enrutador de Keeper usando el token de sesión actual.
• El enrutador de Keeper verifica el token de la sesión y la autentica. Todas las cargas de datos cifradas enviadas al enrutador de Keeper se envuelven con una clave AES de 256 bits, además del TLS, para protegerlas de los ataques MITM.
• La clave AES de 256 bits se crea en el dispositivo del usuario final y se transfiere al servidor usando el cifrado ECIES a través de la clave pública de curva elíptica del enrutador.
• Las solicitudes de rotación y descubrimiento se emiten entre el dispositivo del usuario final (o Keeper Scheduler) y la puerta de enlace a través del canal de comunicaciones websocket establecido.
• Durante la rotación, cuando la puerta de enlace requiere un secreto de Keeper Vault, autentica y descifra el secreto usando las API de Keeper Secrets Manager para preservar el conocimiento cero.
• Como en cualquier otro dispositivo Secrets Manager, el acceso también se puede restringir en función de la dirección IP, además de los procesos de cifrado e inicio de sesión.

Conexión de confianza cero y seguridad de túneles

KeeperPAM de confianza cero proporciona la capacidad para establecer sesiones privilegiadas en la nube y en las instalaciones, crear túneles, establecer accesos directos a la infraestructura y acceder a la base de datos remota segura sin necesidad de una VPN.

Una conexión consiste en una sesión remota visual que utiliza el navegador web. La interacción entre el usuario y el dispositivo de destino se realiza con una ventana del navegador web o dentro de la aplicación Keeper Desktop.

Un túnel consiste en una conexión TCP/IP que se establece entre el cliente de la bóveda local a través de Keeper Gateway hasta el terminal de destino. El usuario puede utilizar cualquier aplicación nativa para comunicarse con el terminal de destino, como el terminal de línea de comandos, la aplicación GUI o la aplicación de gestión de bases de datos como MySQL Workbench.

Cuando el usuario establece una conexión o un túnel:

1. La aplicación cliente de Vault se comunica con la infraestructura de Keeper Router para iniciar una conexión WebRTC protegida por una clave simétrica ECDH que se almacena en el registro de Keeper correspondiente.
2. Keeper Gateway se comunica con el Keeper Router a través de WebSockets salientes solamente. Esto queda descrito en detalle en este enlace.
3. Keeper Gateway utiliza las API de Keeper Secrets Manager para recuperar los secretos necesarios de la bóveda, incluida la clave simétrica ECDH.
4. De cara a las conexiones, el cliente de Vault (que utiliza el protocolo Guacamole de Apache) pasa los datos a través de la conexión WebRTC a Keeper Gateway que luego utiliza Guacd para conectarse al destino que se encuentra en el registro de Keeper.
5. Para las funciones de túnel (reenvío de puertos), se abre un puerto local en el dispositivo local que ejecuta el software de Keeper Desktop. Los datos enviados al puerto local se transmiten a través de la conexión WebRTC a Keeper Gateway y posteriormente se reenvían al punto final de destino definido en el registro de Keeper.
6. Las grabaciones de las sesiones de las conexiones están protegidas por una clave de cifrado AES-256 ("clave de grabación") que se genera en Keeper Gateway en cada sesión. La clave de grabación se envuelve adicionalmente con una clave de recurso AES-256 derivada de HKDF.

Seguridad por aislamiento remoto del navegador

La tecnología de aislamiento remoto del navegador de Keeper protege el acceso a las aplicaciones web internas o a cualquier otro conjunto basado en la web a través del contenedor Docker de Keeper Connection Manager o a través de Keeper Gateway.

Uso del método del contenedor de Docker de Connection Manager:

1. El usuario se autentica en el servicio web de Keeper Connection Manager, alojado por el cliente en un contenedor Docker.
2. El usuario inicia una sesión de aislamiento remoto del navegador en la aplicación web de destino. Entre el navegador del usuario y el servicio web alojado de Keeper Connection Manager, la comunicación a través de HTTPS está protegida por Let's Encrypt o el certificado especificado por el cliente.
3. En el contenedor Docker de Keeper Connection Manager, se ejecuta una versión incrustada de Chromium en un entorno aislado, el sitio web de destino se representa con un controlador de pantalla local que transmite el contenido visible de la página en tiempo real al navegador web del usuario mediante el protocolo Guacamole de Apache.

Uso de Keeper Gateway con la Keeper Web Vault o la aplicación de escritorio:

1. La aplicación cliente de Vault se comunica con la infraestructura de Keeper Router para iniciar una conexión WebRTC protegida por una clave simétrica ECDH que se almacena en el registro de Keeper correspondiente.
2. Keeper Gateway se comunica con el Keeper Router a través de WebSockets salientes solamente. Esto queda descrito en detalle en este enlace.
3. Keeper Gateway utiliza las API de Keeper Secrets Manager para recuperar los secretos necesarios de la bóveda, incluida la clave simétrica ECDH.
4. El cliente de Vault (que utiliza el protocolo Guacamole de Apache) pasa los datos a través de la conexión WebRTC a Keeper Gateway que luego utiliza HTTP o HTTPS para conectarse al destino encontrado en el registro de Keeper.
5. Las grabaciones de las sesiones de las conexiones están protegidas por una clave de cifrado AES-256 ("clave de grabación") que se genera en Keeper Gateway en cada sesión. La clave de grabación se envuelve adicionalmente con una clave de recurso AES-256 derivada de HKDF.

Protección por aislamiento del navegador

Al utilizar el protocolo de aislamiento remoto del navegador se activan varias medidas de seguridad:

1. El terminal de la aplicación web protegido se envuelve con una capa de cifrado TLS desde la puerta de enlace de Keeper Connection Manager hasta el dispositivo local del usuario. independientemente de si se utiliza TLS entre la puerta de enlace y el punto final, lo que protege contra los ataques MITM o la inspección de paquetes en la red local del usuario.
2. La sesión de navegación remota proyecta visualmente la interacción al dispositivo local del usuario mediante un lienzo y una representación gráfica. No se ejecuta ningún código JavaScript ni HTML del sitio web de destino en la máquina local del usuario.
3. Dado que no se ejecuta localmente ningún código del sitio web del destino y el navegador local no puede acceder directamente al código de la aplicación subyacente, la aplicación web aislada está protegida contra los vectores de ataque, como las vulnerabilidades de secuencias de comandos entre sitios reflejadas, la falsificación de solicitudes entre sitios y el abuso de las API.
4. Se puede restringir al usuario final para que no pueda realizar ninguna filtración de datos desde el terminal de destino mediante el filtrado de solicitudes de recursos y URL. Las cargas y descargas de archivos están restringidas, incluso si la aplicación web de destino permite la acción.
5. La sesión de navegación y las pulsaciones de teclas pueden ser registradas con fines de auditoría y cumplimiento, lo que proporciona la capacidad de realizar análisis forenses de las sesiones basadas en la web.
6. Las credenciales que se completan automáticamente desde la puerta de enlace a la aplicación web de destino nunca se transmiten al dispositivo del usuario y el usuario no puede acceder a ellas en su dispositivo local, lo que protege contra filtraciones de secretos.
7. A través de las políticas del cortafuegos, se puede exigir al usuario que acceda a la aplicación web de destino solo a través de la sesión de aislamiento remoto del navegador, lo que reduce la amenaza de que el navegador pueda ser vulnerado o del malware en el dispositivo local.
8. La aplicación web de destino queda protegida por el inicio de sesión único o la autenticación MFA, incluso si la aplicación no la admite de forma nativa. Keeper protege el acceso a la bóveda y a cualquier sesión de aislamiento remoto del navegador a través de los métodos de autenticación avanzados descritos en este documento.

BreachWatch^®

Keeper opera una arquitectura gestionada y autónoma en AWS denominada BreachWatch. BreachWatch es una función físicamente separada de la API de Keeper y los registros de los usuarios.

Se utiliza un modelo de seguridad de hardware físico (HSM) en los servidores de BreachWatch para procesar, convertir en hash y almacenar miles de millones de contraseñas únicas procedentes de violaciones de datos de la dark web. Todas las contraseñas se procesan en los servidores de Keeper usando el método hash HMAC_SHA512 y se convierten en hash con HSM usando una clave no exportable.

Cuando BreachWatch se activa en el lado del cliente, se genera un hash HMAC_SHA512 basado en cada registro y se envía al servidor. Ahí, se crea un segundo hash usando HMAC_SHA512 a través del HSM usando una clave no exportable. Los hashes de hashes se comparan para comprobar si una credencial ha sido violada.

La arquitectura de BreachWatch se creó para evitar la correlación de una contraseña violada con una contraseña contenida en la bóveda del usuario, sin importar el tamaño de la violación de datos. La detección de la contraseña violada utiliza un HSM físico para asegurar que el resumen solo se puede realizar en línea y para evitar cualquier ataque por fuerza bruta sobre los datos.

• Las contraseñas se convierten en hash dos veces con HMAC_512: una vez en el dispositivo cliente usando "pimienta" y otra en el CloudHSM de AWS usando un módulo de seguridad de hardware con una clave no exportable.
• El HMAC_512 se utiliza porque aprovecha una potente función hash más una clave secreta, que no es exportable. Por lo tanto, un ataque sin conexión contra los hashes no es factible.
• El código de autenticación de mensajes (MAC) con el resultado de una función hash criptográfica amplía el uso de las funciones hash. Sus resultados dependen no solo del mensaje, sino de una segunda entrada que puede ser una clave secreta.

Keeper ha construido BreachWatch al 100 % con el uso de fuentes de datos de SpyCloud, pero Keeper nunca envía datos a terceros.

Escaneo de dominios

Los clientes de BreachWatch descargan una lista de los dominios que han sido violados y realizan la comprobación de forma local.

Escaneo de nombre de usuario y contraseña

Los dispositivos cliente se conectan a BreachWatch y suben una lista de hashes de nombres de usuario (o contraseñas) junto con un identificador aleatorio elegido por el cliente (identificadores separados para los servicios de comprobación de nombres de usuario y contraseñas). Estos hashes de contraseñas se procesan en la subida con HMAC usando un módulo de seguridad de hardware (HSM) y una clave secreta almacenada en el HSM marcada como no exportable (es decir, que el HSM solo procesará el HMAC localmente y la clave no se puede extraer). Estas entradas HMAC (nombres de usuario o contraseñas) se comparan con los conjuntos de datos de la violación que se han procesado con el mismo HMAC y clave. Las coincidencias se comunican al dispositivo cliente. Los valores que no coincidan se almacenan junto con el ID anónimo del cliente.

A medida que se añaden nuevos nombres de usuario y contraseñas violados al sistema, estos se procesan con HMAC en el HSM, se añaden al conjunto de datos de BreachWatch y se compara con los valores almacenados del cliente. Cualquier coincidencia pone en cola una alerta para ese ID de cliente.

Los clientes acceden de forma periódica a BreachWatch e introducen sus identificadores de BreachWatch. Los mensajes en espera se descargan y los clientes cargan los nombres de usuario y las contraseñas nuevos o modificados, que se procesan de la misma manera.

La seguridad de los servicios de BreachWatch se basan en el sistema TOFU (Trust on First Use o Confianza en el primer uso). Es decir, los clientes deben asumir que el servidor de BreachWatch no es malicioso (es decir, que no está siendo activamente vulnerado por un hacker) cuando el cliente carga sus valores hash. Una vez que estos valores se procesan con un HSM, están seguros frente a intentos de descifrado fuera de línea. En otras palabras, si un hacker roba el conjunto de datos de los valores almacenados de un cliente, no podrá descifrar esos valores fuera de línea sin la clave HMAC almacenada en el HSM.

Si se detecta la violación de una contraseña, el dispositivo cliente envía una combinación hash de nombre de usuario y contraseña a los servidores de BreachWatch, que después realiza la misma comparación hash HMAC para determinar si una combinación de nombre de usuario y contraseña se ha violado. Si es así, los dominios relacionados con esas violaciones se devuelven para que el dispositivo cliente pueda determinar si coinciden el nombre de usuario, la contraseña y el dominio. Si los tres parámetros coinciden en el dispositivo cliente, se avisa al usuario de la gravedad de la violación.

BreachWatch para clientes de negocios y empresas

Cuando se activa BreachWatch para clientes de negocios y empresas, las bóvedas de los usuarios finales se analizan automáticamente cada vez que un usuario accede con Keeper. Los datos resumidos de BreachWatch analizados en el dispositivo del usuario se cifran con la clave pública de la empresa y el administrador de la empresa los descifra al iniciar sesión en Keeper Admin Console. Esta información cifrada incluye la dirección de correo electrónico, el número de registros de alto riesgo, el número de registros resueltos y el número de registros ignorados. El administrador de Keeper puede ver las estadísticas resumidas a nivel de usuario dentro de la interfaz de usuario de la consola de administración.

Registro de eventos e informes

Cuando se integra con el módulo de alertas e informes avanzados, los dispositivos de usuarios finales de Keeper también se pueden configurar de forma opcional para transmitir eventos detallados en tiempo real a soluciones SIEM de terceros y a la interfaz de informes de la Keeper Admin Console. Los datos del evento contienen la dirección de correo electrónico, el UID del registro, la dirección IP y la información del dispositivo (los eventos no incluyen ningún dato de registro descifrado, ya que Keeper es una plataforma de conocimiento cero y no puede descifrar los datos de los usuarios).

De manera predeterminada, los datos de eventos detallados de BreachWatch no se envían al módulo de alertas e informes avanzados ni a ningún sistema de registro externo conectado. Para activar los informes a nivel de evento de los datos de BreachWatch en el módulo de alertas e informes avanzados, debe activar la política de aplicación de roles de eventos en la pantalla Rol específico > Políticas de aplicación > Funciones de la bóveda. Una vez activados, los dispositivos cliente del usuario final comenzarán a enviar estos datos de eventos. Dado que la integración con soluciones SIEM de terceros se transmite desde el backend de Keeper al SIEM de destino, esta información de eventos es, por tanto, legible por el SIEM de destino y podría utilizarse para identificar qué registros y qué usuarios de la organización tienen contraseñas de alto riesgo. Si el administrador de Keeper no desea transmitir datos de eventos a nivel de registro al módulo de alertas e informes avanzados de Keeper, ese ajuste se puede dejar desactivado.

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

Modo sin conexión

El modo sin conexión permite a los usuarios acceder a sus bóvedas cuando no pueden conectarse a Keeper o a su proveedor de identidades SSO. Esta función está disponible en la aplicación móvil de Keeper, la aplicación de escritorio y el almacén web en todos los navegadores.

Esta función consiste en hacer una copia de la bóveda en el dispositivo local del usuario. Los datos de la bóveda guardados sin conexión se cifran con AES-GCM con una clave de cliente de 256 bits que se genera aleatoriamente y se protege con PBKDF2-HMAC-SHA512 con 1.000.000 de iteraciones y una sal criptográfica aleatoria. La sal y las iteraciones se almacenan localmente. Cuando el usuario introduce su contraseña maestra o usa la biometría, se deriva una clave usando la sal y las iteraciones, y se intenta descifrar la clave de cliente. Después, esta clave se usa para descifrar la caché del registro almacenado. Si la protección de autodestrucción está habilitada en la bóveda del usuario, todos los datos guardados en la bóveda localmente se eliminarán tras intentar iniciar sesión cinco veces sin éxito. Para los clientes de negocios, el administrador de Keeper puede restringir el acceso sin conexión en función de las políticas de aplicación de los roles.

Acceso de emergencia (legado digital)

Los planes familiares y personales de Keeper permiten a los usuarios añadir hasta cinco contactos de emergencia para conceder acceso a la bóveda en caso de fallecimiento del usuario o cualquier otra emergencia. El usuario especifica un tiempo de espera y cuando ese tiempo se acaba, el contacto de emergencia podrá acceder a la bóveda. Compartir la bóveda con un contacto de emergencia preserva el conocimiento cero y la contraseña maestra del usuario nunca se comparte. Además, el cifrado RSA de 2048 bits se utiliza con una clave AES de 256 bits. El contacto de emergencia debe tener una cuenta de Keeper para aceptar la información.

Arquitectura de red

Keeper utiliza AWS en Norteamérica (comercial o GovCloud), Europa, Australia, Japón y Canadá para la privacidad localizada de los datos y el aislamiento geográfico con el fin de alojar y operar la solución y arquitectura de Keeper. Utilizar AWS permite a Keeper ampliar los recursos bajo demanda y ofrecer a los clientes el entorno de almacenamiento en la nube más rápido y seguro. Keeper opera tanto en entornos multizona como multirregión para maximizar el tiempo de actividad y ofrecer el tiempo de respuesta más rápido a los clientes. Los clientes empresariales pueden alojar su inquilino de Keeper en la región principal preferida. Los datos de los clientes y el acceso a la plataforma se aíslan en esa región específica.

Autenticación en la nube

Keeper ha creado un modelo avanzado de autenticación en la nube y comunicaciones en red que ha sido construido para los más altos niveles de privacidad, seguridad y confianza. Algunas características clave del modelo de autenticación son:

• La contraseña maestra nunca se transmite por la capa de red. A diferencia de la mayoría de los servicios SaaS, las credenciales de inicio de sesión nunca salen del dispositivo. El PBKDF2 se utiliza en el dispositivo local para derivar una clave AES de 256 bits usada para el descifrado. Una segunda clave PBKDF2 se genera localmente y después se convierte en hash con HMAC_SHA256 para derivar un token de autenticación. El Cloud Security Vault de Keeper tiene un conocimiento cero sobre la clave de descifrado del usuario.
• El tráfico entre el dispositivo cliente y la nube de Keeper no se puede interceptar ni descifrar. Keeper utiliza la fijación de claves y capas adicionales de cifrado a nivel de red (claves de transmisión) entre el dispositivo y los servidores de Keeper para evitar los ataques MITM.
• Los dispositivos nuevos no pueden iniciar sesión en una cuenta sin el paso de verificación del dispositivo. No se puede intentar acceder a una cuenta sin superar este paso. Keeper es compatible con varios tipos de métodos de verificación de dispositivos que dependen del esquema de autenticación que se utilice.
• La 2FA se realiza después de verificar el dispositivo, antes de introducir la contraseña maestra. Si un usuario tiene configurada o aplicada la 2FA, este paso debe superarse antes de introducir la contraseña maestra.
• La contraseña maestra no se puede introducir hasta que se verifica el dispositivo y se realiza la 2FA correctamente. El usuario no puede proceder a introducir la contraseña maestra sin primero verificar el dispositivo y pasar la autenticación 2FA. Este flujo de autenticación avanzado protege frente a varios vectores de ataque, como los ataques por fuerza bruta, la pulverización de contraseñas, la enumeración y los ataques MITM.

Cifrado en tránsito

El Cloud Security Vault de Keeper está protegido con varias API, que se validan a través de la autorización del dispositivo cliente. El cliente recupera un token de sesión tras iniciar sesión y lo envía con cada llamada a la API. El token de sesión se rastrea en el servidor. El inicio de sesión se realiza con una contraseña maestra, la reanudación de la sesión o la autenticación SAML 2.0 SSO.

Al usar una contraseña maestra, el dispositivo cliente deriva una "clave de autenticación" de 256 bits usando PBKDF2-HMAC-SHA256 con 1 millón de iteraciones y una sal criptográfica aleatoria de 128 bits. Entonces, se genera un “hash de autenticación” convirtiendo en hash la clave de autenticación con el conjunto de funciones hash criptográficas SHA-256. Para iniciar sesión, el hash de autenticación se compara con el hash de autenticación almacenado en el Cloud Security Vault. Tras el inicio de la sesión, se genera un token de sesión en el servidor y se envía al cliente para que lo utilice el dispositivo cliente en posteriores solicitudes a la API. La sesión debe estar activa para permitir el uso continuado de las comunicaciones de cliente a servidor.

Keeper es compatible con el TLS de 256 bits y 128 bits para cifrar todo el transporte de datos entre la aplicación cliente y el almacenamiento en la nube de Keeper.

Keeper despliega certificados TLS firmados por DigiCert usando el algoritmo SHA2, el algoritmo de firma más seguro ofrecido actualmente por las autoridades de certificación comercial. El SHA2 es significativamente más seguro que el más utilizado SHA1, que podría explotarse debido a la debilidad matemática identificada en el algoritmo. El SHA2 ayuda a proteger contra la emisión de certificados falsificados que podrían ser utilizados por un atacante para suplantar la identidad de un sitio web.

Keeper también apoya el Certificado de Transparencia (CT), una iniciativa de Google para crear un registro público auditable de certificados firmados por autoridades de certificación. El CT protege contra la emisión de certificados falsos de entidades no autorizadas. El CT es compatible en las últimas versiones del navegador web de Chrome, Safari y Brave. Puede encontrar más información sobre el Certificado de Transparencia en https://certificate.transparency.dev/. Keeper es compatible con los siguientes conjuntos de cifrado TLS:

• 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

Los dispositivos cliente de Keeper en iOS y Android también implementan la fijación de claves, un mecanismo de seguridad que impide la suplantación de la identidad por parte de atacantes que utilizan certificados digitales fraudulentos.

Protección contra ataques XSS (secuencias de comandos en sitios cruzados)

Keeper Web Vault aplica una política de seguridad de contenidos estricta que restringe el origen de las solicitudes salientes e impide que se ejecuten todas las secuencias de comandos, excepto las que provienen explícitamente de Keeper, incluidas las secuencias de comandos en línea y los atributos HTML de gestión de eventos, lo que reduce o elimina la mayoría de los vectores en los ataques de scripting entre sitios.

El acceso a los nombres de los dominios de Keeper está restringido a HTTPS con TLS 1.3 y es aplicado por HTTP con Seguridad de Transporte Estricta. Esto evita una amplia gama de ataques de rastreo de paquetes, modificación de datos y ataques de intermediario.

Dentro de la extensión para el navegador de Keeper, Keeper no pedirá a los usuarios las credenciales de sus bóvedas desde el área del marco de la página. El inicio de sesión en la extensión ocurre en el área de la barra de herramientas de la extensión del navegador. El inicio de sesión en la bóveda desde el navegador web siempre ocurrirá o bien en el dominio keepersecurity.com, keepersecurity.eu, keepersecurity.com.au, keepersecurity.jp, keepersecurity.ca o govcloud.keepersecurity.us o bien desde la barra de herramientas de la extensión del navegador de Keeper existente fuera del contenido de la página.

La extensión para el navegador de Keeper coloca un iFrame en los formularios de acceso de un sitio web para garantizar que ninguna sitio web maliciosa tenga acceso al contenido inyectado. El contenido de registro inyectado en iFrames también se limita a los registros de Keeper Vault guardados en la bóveda del usuario que coinciden con el dominio del sitio web de destino. Keeper no ofrecerá la opción de Autocompletar para el inicio de sesión o la información de la contraseña, a menos que el dominio del sitio web coincida con el campo correspondiente en el registro de Keeper Vault. La extensión no mostrará los registros a menos que estos coincidan con el dominio raíz de la dirección del sitio web.

Las extensiones de navegador de terceros pueden tener permisos elevados en los navegadores web y pueden acceder a la información dentro de la página. Por lo tanto, se recomienda que los administradores de Keeper eviten que los usuarios instalen extensiones de navegador de terceros desde la respectiva tienda de aplicaciones del navegador.

Biometría

Keeper es compatible de forma nativa con la biometría de Windows Hello, Touch ID, Face ID y Android. Aquellos clientes que normalmente inician sesión en sus Keeper Vault usando una contraseña maestra o el inicio SSO empresarial (SAML 2.0) también pueden iniciar sesión en sus dispositivos usando la biometría. El administrador de Keeper debe habilitar la biometría en la política de roles. El acceso sin conexión también se puede lograr con una biometría tanto para la contraseña maestra como para los usuarios con el SSO habilitado cuando esta función está activada.

Cuando se activa en un dispositivo el inicio de sesión con biometría, se genera aleatoriamente una clave de manera local que se almacena en un enclave seguro del dispositivo (p. ej., Keychain o Keystore). La clave de datos del usuario se cifra con la clave biométrica. Si la autenticación biométrica es correcta, la clave se recupera y el usuario puede descifrar su bóveda.

Llavero iOS, Touch ID y Face ID

Touch ID y Face ID en dispositivos iOS permite a los usuarios acceder a sus Keeper Vault con biometría. Para facilitar esta conveniente función, se almacena en el llavero de iOS una "clave biométrica" de 256 bits generada aleatoriamente. El elemento del llavero de iOS creado para esta funcionalidad no está designado para sincronizarse con el llavero de iCloud y, por lo tanto, no saldrá de su dispositivo móvil iOS.

Le recomendamos encarecidamente que utilice una contraseña maestra compleja y que active la autenticación multifactor para disfrutar de la máxima seguridad en su bóveda cifrada de Keeper Vault. Al activar Touch ID o Face ID, es más práctico utilizar una contraseña maestra compleja en su dispositivo móvil iOS. También es recomendable que establezca un código de acceso más largo que el mínimo de 4 dígitos para asegurar el llavero de iOS.

El llavero de iOS se utiliza en iOS y en aplicaciones para almacenar credenciales de forma segura. Las aplicaciones de iOS utilizan este llavero para almacenar una gran variedad de información sensible, incluidas las contraseñas de sitios webs, claves, números de tarjetas de crédito y la información de Apple Pay. Keeper no utiliza el llavero de iOS para almacenar sus registros de Keeper. Todos los registros de Keeper están protegidos con un cifrado AES de 256 bits y se guardan de forma segura en Keeper Vault. El llavero de iOS también está protegido con un cifrado AES de 256 bits usando el código de acceso del dispositivo. Incluso si pierde o le roban su dispositivo o si un atacante consigue acceso físico a él, no podrá acceder a ningún tipo de información almacenada en Keeper. El llavero de iOS no se puede descifrar sin el código de acceso y tampoco el Keeper Vault sin la contraseña maestra de Keeper.

Apple Watch ^®

La función de favoritos para Apple Watch permite la visualización de determinados registros en un Apple Watch emparejado. Los registros de Keeper se deben activar de forma explícita para permitir su visualización en un Apple Watch. Un Apple Watch emparejado se comunica con la extensión de Keeper para Apple Watch que se ejecuta de forma transparente en un espacio aislado e independiente de la app de Keeper para iOS. La extensión de Keeper para Apple Watch también usa el llavero de iOS para almacenar y acceder a las claves de forma segura, así como para permitir una comunicación óptima y segura con la app de Keeper para iOS.

KeeperDNA^®

KeeperDNA ofrece un método de autenticación multifactor usando un reloj inteligente. KeeperDNA utiliza tokens seguros guardados en Keeper Vault para generar códigos temporales para la autenticación multifactor. Estas solicitudes de autenticación temporales se pueden aprobar y enviar automáticamente desde el Apple Watch (o un dispositivo de Android Wear) con un toque en la pantalla del reloj o introducidas manualmente por el usuario.

Baja de empleados (transferencia de bóvedas)

Cuando la política de transferencia de una cuenta se activa para un nodo, la política de nodos para un par de claves pública/privada se crea en la consola de administración en el dispositivo del usuario. La clave de datos del usuario final (para usuarios en un rol al que se aplique) se cifra con la clave pública de la política cuando el usuario inicia sesión en la bóveda. La clave privada se cifra con la clave pública del administrador y el administrador puede entonces descifrar la clave de aplicación del rol con una transferencia de la bóveda.

Cuando se transfiere una bóveda, el administrador de Keeper debe bloquear primero la cuenta del usuario. La transferencia de la bóveda puede ocurrir de forma inmediata tras eliminar la cuenta del usuario. Esto asegura que la operación no se realiza en secreto. Cuando se hace la transferencia, la clave de datos del usuario se recupera desenvolviendo primero la clave privada de aplicación del rol y después la clave de datos del usuario. La clave de datos se utiliza para desenvolver las claves de registro, equipo y carpeta.

Todo el cifrado se realiza en el lado del cliente dentro de la consola de administración y en ningún momento Keeper puede descifrar la información que se comparte o transfiere. Además, la clave de datos de cliente de un usuario no se comparte nunca. El usuario que se elimine de un equipo, de una carpeta compartida o de un uso compartido directo no recibirá datos nuevos del equipo, de la carpeta compartida o del registro. Aunque las claves de registro, carpeta y equipo las descifra localmente el administrador durante la transacción, las claves no se pueden utilizar para acceder a los datos subyacentes del registro o carpeta.

Durante la transferencia de la bóveda, el administrador solo recibe las claves cifradas de datos, registros y carpetas. Estas claves se descifran y después se vuelven a cifrar con la clave de datos pública de la bóveda de destino. Los administradores nunca pueden acceder a los datos reales de los registros. Keeper no cifra directamente los datos almacenados por los clientes con la clave de datos, todo ocurre en el dispositivo.

Certificaciones y conformidad

Para Keeper, lo más importante es la seguridad. Keeper cuenta con la solución de seguridad de contraseñas y la plataforma gestión del acceso privilegiado más seguras, certificadas, probadas y auditadas del mundo. Keeper tiene las certificaciones SOC 2 e ISO más antiguas del sector. Cuenta con los certificados ISO 27001, 27017 y 27018. Además, es conforme con el RGPD, la CCPA y la HIPAA, está autorizado por el FedRAMP y el GovRAMP y cuenta con el certificado PCI DSS y el certificado de TrustArc para la privacidad.

• Los equipos de desarrollo de software de Keeper están compuestos por personal a tiempo completo ubicado en EE. UU.
• Keeper no almacena contraseñas, credenciales o secretos, como claves de acceso en sus códigos fuente. Analizamos regularmente el código fuente en busca de esta información.
• El código fuente de Keeper, aunque se mantiene de forma privada en GitHub Enterprise, no proporciona la información necesaria para acceder a la bóveda de un usuario, ya que el cifrado de los datos se produce a nivel de dispositivo. Gran parte de este código se publica en nuestro repositorio público de GitHub como parte de los productos Commander y Secrets Manager de Keeper.
• Keeper no incrusta código de proveedores de MFA de terceros en sus aplicaciones. Los proveedores de Keeper no han sido objeto de ninguna violación de datos relacionada con Keeper.
• Keeper no proporciona a terceros la gestión o el acceso a sus centros de datos de AWS. Toda la gestión la realizan empleados a tiempo completo de Keeper Security, que son ciudadanos estadounidenses ubicados en EE. UU.

FIPS 140-3 validado

Keeper utiliza los módulos de cifrado validados según la norma FIPS 140-3 para cumplir con los rigurosos requisitos del gobierno y del sector público. El cifrado de Keeper ha sido certificado por el Programa de validación de módulos criptográficos (CMVP) de NIST y validado según la norma FIPS 140 por laboratorios acreditados de terceros.

Keeper utiliza el cifrado validado por FIPS 140-3 que se ha emitido el certificado n.º 4743 bajo el CMVP de NIST.

Conforme con el ITAR

Keeper Security Government Cloud (KSG) es conforme con el Reglamento estadounidense sobre el tráfico internacional de armas (ITAR, por sus siglas en inglés). Las empresas sujetas a la normativa de exportación ITAR deben controlar las exportaciones involuntarias restringiendo el acceso a los datos protegidos a los ciudadanos estadounidenses y limitando la ubicación física de los datos protegidos a EE. UU.

El entorno FedRAMP moderado de KSGC es compatible con los requisitos del ITAR a través de lo siguiente:

• El almacenamiento de datos completamente conforme se alojamientoa en la GovCloud de AWS y se restringe a EE. UU.
• KSGC ofrece un cifrado de datos seguro tanto en tránsito como en reposo.
• La seguridad de conocimiento cero y confianza cero, junto con los permisos granulares, permite a las organizaciones asegurar que solo el personal autorizado puede acceder a los datos sensibles.
• Las sólidas funciones de generación de informes sobre el cumplimiento de la normativa ofrecen una ruta de auditoría electrónica y rastreable para todas las acciones realizadas y todos los datos introducidos.
• El equipo de satisfacción del cliente aislado está formado por ciudadanos de EE. UU. específicamente formados en el manejo seguro de datos controlados por la exportación y regulados por el ITAR, sin apoyo fuera de EE. UU.

El entorno FedRAMP de Keeper ha sido auditado por una organización independiente de evaluación de terceros (3PAO) para validar que existen los controles adecuados para apoyar los programas de cumplimiento de las exportaciones de los clientes y sigue siendo objeto de las auditorías anuales necesarias para mantener la conformidad.

Más información sobre ITAR.

Autorizado por FedRAMP

KSGC es la plataforma de seguridad cibernética y gestión de contraseñas de Keeper Security para las organizaciones del sector público. KSGC es un proveedor autorizado por el FedRAMP al nivel de impacto moderado y alojamientoado en AWS GovCloud (EE. UU). Puede encontrar KSGC en el FedRAMP Marketplace.

El programa federal sobre la gestión de riesgos y autorizaciones (FedRAMP) es un programa del gobierno federal de Estados Unidos que proporciona un enfoque estandarizado para la evaluación de la seguridad, la autorización y la supervisión continua de los productos y servicios en la nube. El FedRAMP busca acelerar la adopción de soluciones modernas basadas en la nube por parte de las agencias gubernamentales, con énfasis en la seguridad y la protección de la información federal. Descubra más sobre el FedRAMP.

Autorizado por GovRAMP

El GovRAMP fue desarrollado una década después del FedRAMP, con el objetivo de fomentar la adopción de soluciones seguras basado en la nube en las administraciones estatales y locales. Conseguir la autorización GovRAMP suele ser un proceso de dos años que se agilizó mediante un programa de reciprocidad gracias a la autorización FedRAMP de Keeper.

Conforme con el SOC 2

Los registros de las bóvedas de los clientes están protegidos mediante prácticas de control internas estrictas y rigurosamente supervisadas. Keeper cuenta desde hace más de diez años con el certificado SOC 2 Tipo 2 de conformidad con el marco de control de las organizaciones de servicios del AICPA. El cumplimiento de la norma SOC 2 permite asegurar que las bóvedas de los usuarios están protegidos a través de la implementación de controles estandarizados tal y como se definen en el marco de los Principios de servicios fiduciarios del AICPA.

Certificaciones ISO

Keeper cuenta con los certificados ISO 27001, 27017 y 27018, que cubren la infraestructura en la nube y el sistema de gestión de la información de Keeper Security, lo que sostiene la plataforma de Keeper Enterprise. Las certificaciones ISO de Keeper incluyen la gestión y el funcionamiento de bóveda digital y los servicios en la nube, los controles de seguridad de la nube, los controles de privacidad de los datos, el desarrollo de aplicaciones y del software y la protección de los activos digitales tanto para la bóveda digital como para los servicios en la nube.

Conforme con la Parte 11 del Título 21 del CFR de la FDA

Keeper es conforme con lo dispuesto en la Parte 11 del Título 21 del Código de Regulaciones Federales (CFR) de la Administración de Alimentos y Medicamentos de Estados Unidos (FDA), que se aplica a los científicos que trabajan en entornos muy regulados, incluidos los investigadores que realizan ensayos clínicos. Esta regulación especifica los criterios de la FDA según los cuales los registros y firmas electrónicos se consideran fidedignos, fiables y equivalentes a los registros en papel con firmas manuscritas. En concreto, los científicos deben asegurarse de que todos los programas que utilizan son conformes con lo establecido en la Parte 11 del Título 21 del CFR en lo que respecta a:

Controles de seguridad para la identificación de usuarios: Keeper cumple los requisitos de la Parte 11 del Título 21 del CFR relativos a las funciones de seguridad que limitan el acceso de los usuarios y sus privilegios, incluida la garantía de que todos los usuarios tienen nombres de usuario y contraseñas únicos, la capacidad de detectar y evitar accesos no autorizados al sistema y la posibilidad de bloquear las cuentas vulneradas.

Registro de auditoría detallado

Durante las inspecciones de la FDA, los organismos reguladores exigen a los investigadores que proporcionen una pista de auditoría que detalle un registro cronológico de todas las operaciones. Las funciones de informes de conformidad de Keeper permiten a los investigadores producir fácilmente pistas rastreables de auditorías electrónicas.

Firmas electrónicas

Cuando un documento requiere una firma electrónica legalmente vinculante, la Parte 11 del Título 21 del CFR exige que la firma vaya unida a un nombre de usuario y contraseña únicos o a una identificación biométrica. Keeper es compatible con este requisito porque permite a los investigadores asegurar que todos los usuarios tienen nombres de usuario y contraseñas únicos que se almacenan de forma segura en una bóveda digital al que solo puede acceder el usuario en cuestión.

Puede encontrar más información sobre el Título 21 CFR Parte 11 aquí.

Protección de los datos médicos de los pacientes

El software de Keeper cumple con los estándares globales de protección de datos médicos que cubren, por ejemplo, la Ley de Portabilidad y Contabilidad de los Seguros de Salud (HIPAA) y la Ley de Protección de Datos (DPA).

Cumplimiento de la Ley HIPAA y contratos de asociación comercial

Keeper es una plataforma de seguridad de conocimiento cero (con los certificados SOC2 e ISO 27001) que cumple con la Ley HIPAA (ley estadounidense sobre la portabilidad y contabilidad de los seguros de la salud). Se mantienen unos controles estrictos y un respeto riguroso en todo lo relacionado con la privacidad, confidencialidad, integridad y disponibilidad de los datos. Con esta arquitectura de seguridad, Keeper no puede descifrar, ver o acceder a ningún tipo de información (incluida la información clínica protegida) ubicada en el Keeper Vault de cualquier usuario. Por todos estos motivos, a Keeper no se le considera un asociado comercial tal y como se define en la Ley HIPAA y, por lo tanto, no está sujeto a ningún acuerdo de asociación comercial.

Para saber más sobre los beneficios adicionales disponibles para los profesionales sanitarios y las aseguradoras, lea al completo esta divulgación de seguridad y nuestra Guía empresarial.

Con certificado FSQS-NL

Keeper Security EMEA Limited está certificado por el Sistema de Calificación de Servicios Financieros de Hellios-Países Bajos (FSQS-NL), el cual reconoce los más altos estándares en seguridad, calidad e innovación en Países Bajos. Este estándar demuestra la conformidad de la Financial Conduct Authority (autoridad de conducta financiera) y la Prudential Regulation Authority (autoridad de regulación prudencial) para garantizar la fiabilidad del software de Keeper Enterprise para grandes bancos e instituciones financieras.

Licencia de Exportación del Departamento de Comercio de EE. UU. en virtud de las Normas de la Administración de Exportaciones (EAR)

Keeper está certificado por la Oficina de Industria y Seguridad del Departamento de Comercio de EE. UU. con el número de control de clasificación de mercancías de exportación 5D992, en conformidad con el Reglamento de Administración de Exportaciones (EAR).
Para más información sobre EAR: https://www.bis.doc.gov

Monitoreo Remoto permanente

Un equipo DevOps a tiempo completo y una red global de supervisión de terceros supervisa Keeper las 24 horas del día durante los 365 días del año para garantizar que nuestro sitio web y el Cloud Security Vault estén disponibles en todo el mundo.

Si tiene alguna pregunta relacionada con esta divulgación de seguridad, contacte con nosotros.

Mensajes falsificados o de phishing

Si recibe un correo electrónico en el que se afirme que el remitente es Keeper Security y no está seguro de si es legítimo, puede tratarse de un correo electrónico de suplantación de identidad en el que la dirección de correo electrónico del remitente se haya falsificado. En ese caso, el correo electrónico puede contener enlaces a sitios web que se parecen a KeeperSecurity.com, pero no lo son. El sitio web puede pedirle su contraseña maestra de Keeper Security o intentar instalar software no deseado en su computadora con el objetivo de robarle información personal o acceder a su dispositivo. Otros correos electrónicos contienen enlaces que pueden redirigirle a otros sitios web potencialmente peligrosos. El mensaje puede incluir también archivos adjuntos, que normalmente incluyen software no deseado denominado "malware". Si tiene dudas sobre algún correo electrónico que haya recibido, elimínelo sin hacer clic en ningún enlace ni abrir ningún archivo adjunto.

Si desea denunciar un correo electrónico que supuestamente procede de Keeper, pero cree que es una falsificación o tiene otras dudas sobre seguridad, póngase en contacto con nosotros.

Infraestructura de alojamiento certificada de acuerdo con los estándares más estrictos del sector

El sitio web de Keeper y el almacenamiento se ejecutan por medio de la infraestructura de Amazon Web Services (AWS). La infraestructura de nube de AWS que aloja la arquitectura del sistema de Keeper ha sido certificada para cumplir con los siguientes informes, atestaciones y certificaciones externos:

Programa de recompensas por notificación de vulnerabilidades y errores

Keeper Security se dedica a desarrollar la solución de gestión de contraseñas y gestión del acceso privilegiado más segura del mercado. Nos comprometemos a proteger la privacidad y los datos personales de nuestros clientes. La misión de Keeper es crear la plataforma de seguridad más innovadora y segura del mundo, y creemos que los informes de errores de la comunidad mundial de investigadores de seguridad son cruciales para garantizar la seguridad de los productos y servicios de Keeper.

Keeper lleva a cabo extensas pruebas internas y externas, incluidas las pruebas de penetración realizadas por NCC Group y CyberTest con acceso total al código fuente. Keeper gestiona su programa de divulgación de vulnerabilidades en colaboración con Bugcrowd. En conjunto, esto beneficia a toda la industria y, además, contribuye al interés social.

Directrices

En la política de divulgación de vulnerabilidades de Keeper se estipulan las expectativas a la hora de colaborar con hackers de buena fe, así como también lo que puede esperar de nosotros.

Si las pruebas e informes de seguridad se realizan dentro de las directrices de esta política, nosotros:

• Se considerarán como actividades autorizadas de acuerdo con la Ley de Fraude y Abuso de Computadoras.
• Se considerarán como actividades exentas de DMCA y no presentaremos ninguna reclamación contra usted por eludir los controles tecnológicos o de seguridad.
• Se considerarán como actividades legales y no emprenderemos ni apoyaremos ninguna acción legal relacionada con este programa en su contra.
• Se trabajará con usted para comprender y resolver el problema rápidamente.
• Se reconocerán sus contribuciones de forma pública si usted es el primero en notificar el problema y realizaremos un cambio en el código o en la configuración basado en el problema.

Si en algún momento le preocupa o tiene dudas sobre la realización de pruebas acordes con las directrices y el ámbito de aplicación de esta política, póngase en contacto con nosotros en security@keepersecurity. com antes de proceder.

Para fomentar las pruebas de seguridad de buena fe y la divulgación de las vulnerabilidades detectadas, le pedimos que:

• Evite violar la privacidad de los usuarios, dañar su experiencia, interrumpir la producción o los sistemas corporativos o destruir datos.
• Realice investigaciones únicamente dentro del ámbito establecido por el programa de divulgación de vulnerabilidades de Bugcrowd enlazado más abajo y respete los sistemas y actividades que queden fuera de ese ámbito.
• Si encuentra datos de usuario durante la prueba, póngase en contacto con nosotros de inmediato en security@keepersecurity.com.
• Concédanos un tiempo razonable para analizar, confirmar y resolver el problema notificado antes de divulgar públicamente cualquier vulnerabilidad encontrada.

Envíe los informes a través de https://bugcrowd.com/keepersecurity

Transparencia

Keeper no solo se preocupa por la seguridad, es una obsesión. Por ello, hacemos que cada detalle de nuestro modelo de cifrado esté disponible para el público. Creemos que nuestros clientes merecen saber que cada paso que damos es para asegurar que sus datos están protegidos frente a un panorama de seguridad cibernética en constante cambio.

El modelo de cifrado conocimiento cero y confianza cero de Keeper asegura que, incluso en el peor escenario, su Keeper Vault permanezca protegido. Realizamos de forma habitual exámenes de seguridad para asegurarnos de que seguimos siendo la mejor solución para proteger sus datos más valiosos.

Declaración sobre la esclavitud moderna

Documentación de productos

El portal de documentación de Keeper, con manuales sobre productos, información técnica, notas de versiones y guías de usuario final, está disponible en este enlace.

Notas de versiones de productos

Para una mayor transparencia, Keeper publica notas de versiones detalladas en cada plataforma.

Estado del sistema

Puede encontrar el estado del sistema en tiempo real aquí.