Para Keeper, la protección de los datos y la seguridad de las credenciales es fundamental

Keeper utiliza una seguridad de primera categoría con una arquitectura de confianza y conocimiento cero para proteger su información y evitar que los ciberdelincuentes accedan a sus datos.

Para Keeper, la protección de los datos y la seguridad de las credenciales es fundamental

La seguridad de primera categoría de Keeper de un vistazo

Cifrado más potente

Cifrado más potente

Keeper protege sus contraseñas, secretos e información personal con un cifrado AES de 256 bits y una criptografía de curva elíptica (CE), considerado como el cifrado más sólido del sector de la ciberseguridad.

Keeper es un proveedor de seguridad de conocimiento cero. El conocimiento cero es una arquitectura de sistemas que garantiza los más altos niveles de seguridad y privacidad. El cifrado y descifrado de los datos siempre ocurre de forma local en el dispositivo del usuario.

Programa de localización de errores y vulnerabilidades

Programa de localización de errores y vulnerabilidades

En Keeper, estamos comprometidos con la protección de los datos personales y la privacidad de nuestros clientes. Nuestra misión es crear las aplicaciones de seguridad más seguras e innovadoras del mundo y creemos que los informes de errores de nuestra comunidad internacional de investigadores de seguridad son un componente valioso para asegurar la seguridad de los productos y servicios de Keeper. Por todo ello, nos hemos asociado con Bugcrowd para gestionar el Programa de divulgación de vulnerabilidades (VDP) y el Programa de recompensas por fallos.

Validado por la norma FIPS 140

Validado por la norma FIPS 140

Keeper está certificado por el Programa de verificación de módulos criptográficos de NIST (CMVP) para la norma FIPS 140.

Pruebas de penetración

Pruebas de penetración

Keeper se asocia con expertos de terceros, como NCC Group, CyberTest e investigadores de seguridad independientes para realizar pruebas de penetración trimestrales contra todas las soluciones y sistemas.

Almacén en la nube seguro y fiable

Almacén en la nube seguro y fiable

Keeper utiliza AWS en varias regiones (como EE. UU., US GovCloud, EU, AU, CA y JP) para hospedar y operar la plataforma y arquitectura de Keeper. Esto ofrece a los clientes el almacenamiento en la nube más seguro disponible. Los datos se aíslan completamente, tanto en tránsito como en reposo, en la región de AWS preferida por el cliente.

Alta disponibilidad

Alta disponibilidad

La infraestructura global de Keeper se hospeda en varios centros de datos de alta disponibilidad de AWS. Estos centros de datos se distribuyen en varias regiones de AWS para asegurar la disponibilidad del servicio en caso de un corte regional de internet.

Autenticación con múltiples factores

Autenticación con múltiples factores

Keeper es compatible con la autenticación de varios factores (MFA), la autenticación SSO, las políticas de acceso condicional (CAP), las claves de seguridad de hardware WebAuthn de FIDO2, las claves de acceso, el inicio de sesión con biometría (como Face ID, Touch ID y Windows Hello) y Keeper DNA®, que usa relojes inteligentes para confirmar la identidad.

Cifrado de conocimiento cero

Cifrado de conocimiento cero

Los datos de los usuarios finales se cifran y descifran a nivel de dispositivo y registro, nunca en la nube o en los servidores de Keeper. El cifrado a nivel de registro reduce el "radio de explosión" de la información guardada en los almacenes de los usuarios y es la base de muchas funciones de mínimo privilegio de la plataforma, como el uso compartido de registros.

Resumen

Keeper Security, Inc. se preocupa por proteger la información de sus clientes con programas de seguridad para móviles y escritorios. Millones de clientes y empresas 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 hospedaje 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 nuestra página web desde los siguientes enlaces:

Privacy Policy Términos & Condiciones

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 una página 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.

A diagram showing how Keeper's solutions integrate with various identity and access management platforms.

Usuarios finales

Usuarios de Keeper en cualquier dispositivo cliente, incluidos escritorio, móvil, navegador y línea de comandos.

Proveedor de identidades

Un IdP es un servicio que almacena y gestiona las identidades de usuario.

Aplicaciones SAML

Permite que el SSO se extienda por los dominios de seguridad para hacer posible el SSO en el navegador web.

SecOps, DevOps y TI

Usuarios privilegiados con acceso a cuentas, inicios de sesión y secretos altamente sensibles.

Consola de administración de Keeper

Use esta plataforma para configurar y aplicar la política empresarial a los usuarios finales.

Keeper Connection Manager (KCM)

Permite el acceso de red de confianza cero a su infraestructura sin una VPN.

Keeper Secrets Manager (KSM)

Proteja los secretos de infraestructura como las claves API, las contraseñas de bases de datos, las claves de acceso, los certificados y cualquier tipo de dato confidencial.

Gestor de contraseñas de Keeper Enterprise (EPM)

Protege sus contraseñas e información personal frente a los ciberdelincuentes.

Navegadores, equipos y dispositivos cliente

Dispositivos de usuario final que acceden a los almacenes de contraseñas seguros.

Windows, Linux, MySQL, SQL Server, PostgreSQL

Varios puntos de conexión a los que los usuarios privilegiados acceden frecuentemente.

Jenkins, GitHub, Terraform, PowerShell

Herramientas DevOps y de desarrollador que automatizan la creación de aplicaciones y el proceso de desarrollo.

Aplicaciones basadas en contraseñas

Páginas web, aplicaciones y sistemas que requieren inicios de sesión.

Ver vídeo sobre confianza cero

Marco de ciberseguridad de confianza cero de Keeper
Cómo funciona la plataforma de confianza cero de Keeper
Modelo de seguridad y cifrado de Keeper

La mejor seguridad de Keeper en detalle

Cifrado de los datos del almacén

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 el almacén. Los registros del almacén 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 almacén de Keeper 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 del almacén

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 principal 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 principal: La clave para descifrar y cifrar la clave de datos se deriva de la contraseña principal del usuario utilizando la función de variación de clave basada en contraseña (PBKDF2), con 1.000.000 de iteraciones. Cuando el usuario introduce su contraseña principal, 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.

Modelo de cifrado de Keeper: Inicio de sesión con contraseña principal Modelo de cifrado de Keeper: Inicio de sesión con contraseña principal

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 sistemas 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.

SSO Connect Cloud: Modelo de cifrado de varias capas SSO Connect Cloud: Modelo de cifrado de varias capas

Modelo de cifrado 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 el almacén 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 del dispositivo

  • 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 o 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

Lea 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 escritorio de Keeper basada en Electron, el almacén de Keeper guarda la clave privada CE del dispositivo local (“DPRIV”) como una criptoclave 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 del almacén. Después de autenticar correctamente desde el proveedor de identidades, se utiliza una clave distinta (no almacenada) para descifrar los datos del almacén. Por lo tanto, la extracción sin conexión de la clave privada del dispositivo local no puede descifrar el almacén de un usuario.

Cifrado de los datos en reposo

Keeper utiliza AWS para hospedar la plataforma y la arquitectura de Keeper. Nuestros centros de datos AWS se encuentran en diferentes ubicaciones geográficas y nuestros clientes pueden hospedar 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 del almacén 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 usado el cifrado a nivel de registro.

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

  • Todos los almacenes 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 almacenes 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 principal, las claves para cifrar y descifrar se derivan de la contraseña principal.
  • 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.
Diagrama del cifrado de registros Diagrama del cifrado de registros

Control de versiones de los registros

Keeper conserva un historial completo de versiones cifradas de cada registro guardado en el almacén 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 del almacén. 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.

Control de versiones de los registros

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 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.

Keeper Business

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 un almacén 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, un almacén o una empresa completa.

Recuperación de cuenta

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

Keeper ha implementado frases de recuperación usando la misma lista de palabras BIP39 utilizada para proteger las criptocarteras. 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 los monederos 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 una caja fuerte.

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 principal, 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.

Configuración de la frase de recuperación Configuración de la frase de recuperación

Claves de cifrado empresariales

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 del almacén 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 almacenes y aprobar dispositivos utilizan las claves de cifrado públicas y privadas.
  • 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 del almacén del usuario empresarial se cifra con la clave pública empresarial y se puede descifrar en la consola de administración de Keeper 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.

Los clientes que inician sesión con una contraseña principal 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 la SSO Connect Cloud de Keeper, 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 de la consola de administración
  • Aprobación automática mediante el servicio de 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 es conforme 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. Cumplimos con el Marco de Privacidad de Datos UE-EE. UU. ("DPF UE-EE. UU."), la Extensión del Reino Unido al DPF UE-EE. UU. y el Marco de Privacidad de Datos Suizo-EE. UU. ("DPF Suizo-EE. UU.") según lo establecido por el Departamento de Comercio de EE. UU.

Vea 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 los datos

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

Regiones disponibles:

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

Cifrado en tránsito

El almacén de Keeper está protegido 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 backend.
  • Se inicia sesión con una contraseña principal, biometría, reanudación de sesión o autenticación SAML 2.0 SSO.

Cuando se utiliza una contraseña principal, 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 el almacén de Keeper. 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 una página 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 Azure, AD FS, Google Workspace, Centrify, OneLogin, Ping Identity, JumpCloud, Duo, Auth0 y 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.

La contraseña principal del usuario nunca se transmite 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 principal, 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 cliente y la nube de Keeper no puede interceptarse ni descifrarse

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 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 de varios factores (MFA) se realiza después de la verificación, antes de que el usuario introduzca la contraseña principal

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

No se puede introducir la contraseña principal 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 principal. 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 de varios factores (MFA)

Para impedir los ataques no autorizados a la cuenta de un cliente, Keeper ofrece la autenticación de varios factores (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 principal y el dispositivo que posee para ofrecer una capa de seguridad adicional en caso de que la contraseña principal o el dispositivo se vean comprometidos. 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 escritorio o para iOS/Android de Keeper. Los administradores de Keeper también pueden exigir el uso de la MFA y los métodos MFA compatibles a través de la consola de administración.

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 WatchAndroid Smart Watch Apple Smart WatchApple Smart Watch DUODUO EntrustEntrust Google AuthenticatorGoogle Authenticator Microsoft Authenticator Microsoft Authenticator RSA SecureIDRSA SecureID Mensaje de texto SMSMensaje de texto SMS TOTPTOTP YubicoYubico

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 comprometida 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.

Puente de Active Directory/LDAP de Keeper

Autenticación SSO con MFA

Cuando Keeper se despliega con una solución SSO como Azure AD, Okta, Ping, Google Workspace o cualquier otro proveedor de identidades SAML 2.0, la MFA se puede gestionar por completo durante el proceso de inicio de sesión del IdP. Keeper también es compatible con las políticas de acceso condicional de Azure en 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.

Amazon Web ServicesAmazon Web Services CASCAS CentrifyCentrify DUODUO F5F5 Google WorkplaceGoogle Workplace IBM SecurityIBM Security JumpCloudJumpCloud MicrosoftMicrosoft OneloginOnelogin OktaOkta Ping IdentityPing 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 y desplegar los almacenes cifrados a sus usuarios.

La implementación de SAML con Keeper permite al usuario autenticarse a través de su IdP con SSO y después descifrar el texto cifrado del almacén en su dispositivo. Cada dispositivo de usuario tiene un par de claves individual de curva elíptica (CE) y una clave de datos cifrada. Además, cada usuario tiene su propia clave de datos AES de 256 bits. Cuando se inicia sesión en Keeper desde un dispositivo nuevo, el usuario debe utilizar los dispositivos existentes para aprobar el nuevo o, de forma alternativa, a través de un administrador con privilegios.

Esta función es esencial para que el usuario pueda descifrar su almacén de forma local en su dispositivo sin requerir una contraseña principal ni una derivación de clave de contraseña. El conocimiento cero se conserva porque la nube no puede descifrar la clave de datos del usuario. En su lugar, la clave de datos cifrada por el dispositivo (DEDK) se facilita al usuario tras la autenticación correcta del IdP (p. ej., Okta, Azure, Google Workspace, AD FS, Ping, Duo, JumpCloud, etc.). La clave de datos para el usuario se descifra localmente en el dispositivo con la clave privada del dispositivo de curva elíptica. Keeper es titular de patentes de utilidad estadounidenses sobre esta tecnología, en producción desde 2015.

Autenticación SAML 2.0 con SSO Connect Cloud

Keeper SSO Connect On-Prem

SSO Connect On-Prem es una integración autohospedada que requiere un servidor de aplicaciones hospedado en Windows o Linux. Para conservar la seguridad de conocimiento cero y asegurar una experiencia SSO sin complicaciones para los usuarios, Keeper SSO Connect debe instalarse en el servidor del cliente. Los entornos de Windows, Mac y Linux son totalmente compatibles con los modos de funcionamiento de equilibrio de carga de alta disponibilidad (HA).

Keeper SSO Connect genera y mantiene la contraseña principal de forma automática para cada usuario aprovisionado, que es una clave de 256 bits generada aleatoriamente. Esta contraseña principal 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 el Cloud Security Vault de Keeper 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.

Keeper SSO Connect On-Prem

Compartir

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).

Compartición de 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 almacén. 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 almacén de Keeper 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 el almacén del destinatario.

Diseñado para compartir registros Diseñado para compartir registros

Compartir una sola vez

Los enlaces para compartir válidos una sola vez de Keeper permiten compartir registros por tiempo limitado y de forma segura, como una contraseña, credencial, 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 este tipo de enlace usa la misma tecnología que Keeper Secrets Manager (KSM), una plataforma de seguridad de conocimiento y confianza cero para proteger la infraestructura en la nube.

  1. En el almacén de Keeper del usuario, el originador genera un acceso único haciendo clic en enlace para compartir válido una sola vez. La clave de registro AES de 256 bits se cifra con un token de acceso único y el valor cifrado se guarda en el almacén de Keeper.
  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 del almacén se carga en el dispositivo. El token se entrega directamente a la aplicación del almacén 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 llaves 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 una sola vezCompartir una sola vez

Compartir privilegios de admin.

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.

Compartir privilegios de admin.Compartir privilegios de admin.

Modelo de cifrado de Secrets Manager

Keeper Secrets Manager (KSM) es una plataforma de conocimiento cero para profesionales de TI y DevOps. La solución permite a los equipos gestionar los secretos a lo largo del ciclo de vida de desarrollo e implantación del software.

Modelo de cifrado de Secrets Manager Modelo de cifrado de Keeper Secrets Manager

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 registros 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 el almacén se segmentan y aíslan en dispositivos Secrets Manager definidos a los que se concede acceso al registro y a la carpeta.

Modelo de rotación de contraseñas de Keeper Secrets Manager:

  • Se instala un cliente de 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 hospedado 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 del almacén de Keeper, 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.
Diagrama de la infraestructura de la rotación de contraseñas Diagrama de la infraestructura de la rotación de contraseñas

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 filtraciones 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 filtrada.

La arquitectura de BreachWatch se creó para evitar la correlación de una contraseña filtrada con una contraseña contenida en el almacén del usuario, sin importar el tamaño de la filtración de datos. La detección de la contraseña filtrada utiliza un HSM físico para asegurar que el resumen solo se puede realizar en línea, 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.

Modelo de BreachWatch de Keeper Modelo de BreachWatch de Keeper

Escaneo del dominio

Los clientes de BreachWatch descargan una lista de los dominios que se han filtrado 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 filtración que se han procesado con el mismo HMAC y clave. Las coincidencias se comunican al dispositivo cliente. Los valores que no coinciden se almacenan junto con el ID anónimo del cliente.

A medida que se añaden nuevos nombres de usuario y contraseñas filtrados 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 cola se descargan y los clientes cargan sus nombres de usuario y contraseñas nuevos o modificados que se procesarán 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). Esto quiere decir que los clientes deben asumir que el servidor de BreachWatch no es malicioso (es decir, que no está siendo atacado de forma activa) 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 atacante 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 filtración de una contraseña, el dispositivo cliente envía una combinación hash de nombre de usuario más 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 más contraseña se ha filtrado. Si es así, los dominios relacionados con esas filtraciones 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 filtración.

BreachWatch para clientes Business y Enterprise

Cuando se activa BreachWatch para clientes de negocios y empresas, los almacenes 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 la consola de administración de Keeper. 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 e informes de eventos

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 consola de administración de Keeper. 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).

Por defecto, los datos de eventos detallados de BreachWatch no se envían al módulo de alertas e informes avanzados o 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 del almacén. 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.

SplunkSplunk Sumo LogicSumo Logic LogRhythmLogRhythm Syslog PushSyslog Push IBM QRadarIBM QRadar Azure SentinelAzure Sentinel AWS S3 BucketAWS S3 Bucket DevoDevo DatadogDatadog Logz.ioLogz.io ElasticElastic

Modo sin conexión

El modo sin conexión permite a los usuarios acceder a sus almacenes 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.

Modo sin conexión

Esta función consiste en hacer una copia del almacén en el dispositivo local del usuario. Los datos del almacén 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 principal 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 el almacén del usuario, todos los datos guardados en el almacén localmente se eliminarán tras intentar iniciar sesión cinco veces sin éxito. Para los clientes empresariales, 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 al almacén 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 al almacén. Compartir el almacén con un contacto de emergencia preserva el conocimiento cero y la contraseña principal 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.

Función de acceso de emergencia Función de acceso de emergencia

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 hospedar 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.

Arquitectura de red

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 principal 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 principal. Si un usuario tiene configurada o aplicada la 2FA, este paso debe superarse antes de introducir la contraseña principal.
  • La contraseña principal 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 principal sin primero verificar el dispositivo y pasar la 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 principal, la reanudación de la sesión o la autenticación SAML 2.0.

Al usar una contraseña principal, el dispositivo cliente 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 de 128 bits. Un "hash de autenticación" se genera convirtiendo en hash la clave de autenticación con 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 entre cliente y 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 una página web.

KSI 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)

El almacén web de Keeper 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 XSS.

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 almacenes 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 el almacén 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 una página web para garantizar que ninguna página web maliciosa tenga acceso al contenido inyectado. El contenido de registro inyectado en iFrames también se limita a los registros del almacén guardados en el almacén del usuario que coinciden con el dominio de la página web de destino.

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 almacenes de Keeper usando una contraseña principal 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 principal 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 almacén.

Llavero iOS, Touch ID y Face ID

Touch ID y Face ID en dispositivos iOS permite a los usuarios acceder a sus almacenes de Keeper 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 principal compleja y que active la autenticación de varios factores para disfrutar de la máxima seguridad en su almacén cifrado de Keeper. Al activar Touch ID o Face ID, es más práctico utilizar una contraseña principal 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 páginas 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 el almacén de Keeper. 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 su móvil, 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 almacén de Keeper sin la contraseña principal de Keeper.

Llavero iOS, Touch ID y Face ID

Apple Watch®

La función de favoritos para Apple Watch permite la visualización de determinados registros en un Apple Watch que se haya emparejado. Los registros de Keeper se deben activar de forma explícita para permitir su visualización en un Apple Watch. Un Apple Watch que se haya 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 aplicación 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 y para permitir una comunicación óptima y segura con la aplicación de Keeper para iOS.

Keeper DNA®

Keeper DNA ofrece un método de autenticación de varios factores usando un reloj inteligente. Keeper DNA utiliza tokens seguros guardados en el almacén de Keeper para generar códigos temporales para la autenticación de varios factores. 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 almacenes)

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 el almacén. 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 del almacén.

Cuando se transfiere un almacén, el administrador de Keeper debe bloquear primero la cuenta del usuario. La transferencia del almacén 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 del almacén, 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 del almacén 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.

Cese de cuentas de empleados Cese de cuentas de empleados

Certificados y conformidad

Para Keeper, lo más importante es la seguridad. Keeper es la solución de seguridad de contraseñas y la plataforma de gestión de accesos privilegiados más segura, certificada, probada y auditada del mundo. Cuenta con la plataforma de gestión de accesos privilegiados y con los certificados SOC 2 e ISO 27001 más antiguos del sector. Keeper cumple con el RGPD, la CCPA y la HIPAA; está autorizado por el FedRAMP y el StateRAMP y cuenta con la certificación PCI DSS y la certificación TrustArc de 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 al almacén 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 filtración 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.
ISO 27001 SOC2 FedRAMP StateRAMP HIPAA Compliant GDPR Compliant PCI DDS Level 1 TRUSTe Level 1 FIPS-140-2

FIPS 140-2 validado

Keeper utiliza los módulos de cifrado validados según la norma FIPS 140-2 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 ha obtenido el certificado n.º 3976 de acuerdo con el CMVP de NIST

Conforme con el ITAR

Keeper Security Government Cloud (KSGC) promueve la conformidad del Reglamento sobre el tráfico internacional de armas (ITAR) de EE. UU. 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 hospeda 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 y confianza cero, junto con los permisos granulares, permite a las organizaciones asegurar que solo el personal autorizado puede acceder a los datos confidenciales.
  • 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 el ITAR.

Autorizado por FedRAMP

KSGC es la plataforma de ciberseguridad 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 hospedado en AWS GovCloud (US). 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 StateRAMP

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

Certificado SOC 2

Los registros de los almacenes de los clientes están protegidos mediante prácticas de control internas estrictas y rigurosamente supervisadas. Keeper cuenta desde hace 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 certificado SOC 2 permite asegurar que los almacenes de los usuarios están protegidos a través de la puesta en funcionamiento de controles estandarizados tal y como se definen en el marco de los Principios de servicios fiduciarios del AICPA.

Certificado ISO 27001

Keeper tiene el certificado ISO 27001, el cual cubre el Sistema de Gestión de la Información de Keeper Security que respalda la plataforma de Keeper Enterprise. El certificado ISO 27001 de Keeper se extiende a la gestión y al funcionamiento del almacén digital y de los servicios en la nube, al desarrollo de programas y aplicaciones, y a la protección de los activos digitales para el almacén digital y 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 comprometidas.

Traza de auditoría detallada

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 un almacén 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 del paciente

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 almacén de Keeper 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 EEUU bajo la Regulación Administrativa de Exportación (EAR por sus siglas en inglés)

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 el EAR: https://www.bis.doc.gov

Monitoreo Remoto 24x7

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 nuestra página 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 páginas web que se parecen a KeeperSecurity.com, pero no lo son. La página web puede pedirle su contraseña principal de Keeper Security o intentar instalar software no deseado en su ordenador con el objetivo de robarle información personal o acceder a su dispositivo. Otros correos electrónicos contienen enlaces que pueden redirigirle a otras páginas web potencialmente peligrosas. 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 preocupaciones de seguridad relacionadas con otros asuntos, 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 en la nube corre 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 las siguientes atestaciones, reportes y certificaciones externas:

SOC2 PCI Compliant FIPS-140-2 ISO 27001 FedRAMP StateRAMP

Notificación de vulnerabilidades y programa de localización de errores

Keeper Security se dedica a desarrollar la solución de gestión de contraseñas y accesos privilegiados 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 segura e innovadora 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 común.

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:

  • Se considerarán como actividades autorizadas de acuerdo con la Ley de Fraude y Abuso Informático.
  • 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 cualquier momento siente preocupación o incertidumbre acerca de la realización de pruebas de una forma que sea coherente con las directrices y el alcance 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.
  • Contáctenos de inmediato en security@keepersecurity.com si encuentra datos de usuario durante la prueba.
  • 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 ciberseguridad en constante cambio.

El modelo de cifrado de conocimiento y confianza cero de Keeper asegura que, incluso en el peor escenario, su almacén de Keeper 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.

Documentación del producto

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 del producto

Para incrementar la transparencia, Keeper publica notas de versiones detalladas en cada plataforma.

Estado del sistema

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

close
close
Español (ES) Llámenos