O Keeper é fanático sobre segurança de credenciais e proteção de dados

Visão geral

O Keeper Security, Inc. valoriza a proteção das informações dos clientes com softwares de segurança de desktop e dispositivos móveis. Milhões de clientes e negócios confiam no Keeper para proteger e acessar informações privadas.

O software Keeper é constantemente aprovado e atualizado para fornecer aos clientes a melhor proteção e tecnologia. Esta página fornece uma visão geral da arquitetura de segurança, metodologias de criptografia e ambientes de hospedagem do Keeper conforme a versão atual publicada. Uma visão geral sobre os detalhes técnicos dos nossos métodos de criptografia e segurança é descrita neste documento.

A política de privacidade e os termos de uso estão disponíveis em nosso site nos seguintes links:

Plataforma de confiança zero

O Keeper utiliza uma arquitetura de confiança zero, que garante que todo usuário deve ser verificado e autenticado antes de acessar um site, aplicativo ou sistema.

O Gerenciamento de senhas empresarial (EPM) do Keeper oferece às empresas total controle e visibilidade sobre as práticas de senhas dos funcionários, possibilitando que administradores de TI monitorem o uso de senha e exijam as melhores práticas de segurança.

O Gerenciador de segredos do Keeper (KSM) fornece às equipes de engenharia uma plataforma para gerenciar todas as credenciais, incluindo segredos de infraestrutura, chaves SSH, chaves de API e certificados com SDKs e integração CI/CD.

O Gerenciador de conexões do Keeper (KCM) é um gateway de desktop remoto que fornece a equipes de DevOps e IT acesso a rede de confiança zero (ZTNA) para RDP, SSH, bancos de dados, aplicativos de web internos e pontos finais de Kubernetes por um navegador da web – sem a necessidade de um agente.

Melhor segurança da categoria do Keeper em detalhes

Criptografia de dados de cofre

O Keeper fornece um modelo de criptografia multicamada com base em menor privilégio. As chaves de nível de registro e chaves de nível de pasta AES de 256 bits no dispositivo co cliente, que criptografa cada registro de cofre armazenado. Os registros do cofre e todo o conteúdo são totalmente criptografados, incluindo logins, anexos de arquivos, códigos TOTP, informações de pagamento, URLs e campos personalizados.

As chaves de criptografia são geradas localmente no dispositivo para preservar os recursos avançados de suporte e o conhecimento zero, como compartilhamento de pastas e registros. Conhecimento zero significa que cada usuário tem completo controle sobre a criptografia e descriptografia de todas as informações pessoais no Cofre do Keeper e nenhuma dessas informações é acessível por qualquer parte, até mesmo por funcionários do Keeper.

Chaves de registro e chaves de pasta são criptografadas por uma chave de dados AES de 256 única para cada usuário e gerada no dispositivo do usuário.

No dispositivo do usuário, outra chave de cliente AES de 256 bits é gerada para criptografar um cache local off-line (se o administrador permitir acesso off-line). Finalmente, a chave de dados AES de 256 bits criptografada com outra chave, conforme descrito na próxima seção.

Métodos de criptografia de cofre

O Keeper criptografa dados de diversas formas, dependendo de como os usuários se conectam. Para membros de planos familiares e clientes, uma senha principal e autenticação biométrica são usadas. Para usuários comerciais e empresariais que se conectam com SSO, o Keeper utiliza criptografia de curva elíptica para garantir uma experiência segura sem senha.

Para usuários que se conectam com uma senha principal: a chave para descriptografar e criptografar a chave de dados é derivada da senha principal do usuário, utilizando a função de variação de chave baseada em senha (PBKDF2), com 1.000.000 de iterações. Depois que o usuário digita a senha principal, a chave é derivada localmente e libera a chave de dados. A chave de dados é descriptografada e usada para liberar as chaves individuais e de pasta. A descriptografia de cada chave armazena o conteúdo do registro localmente no dispositivo do usuário.

Para usuários que se conectam com SSO ou tecnologia sem senha: a criptografia de curva elíptica é usada para criptografar e descriptografar dados no nível do dispositivo. Uma chave privada local ECC-256 (secp256r1) é usada para descriptografar a chave de dados. Após a descriptografia da chave de dados, ela é usada para liberar as chaves de pasta e de registro individual. A chave de registro então descriptografa cada um dos conteúdos de registro armazenados. A chave de dados criptografados é transmitida entre os dispositivos do usuário por um sistema push ou serviço de troca de chaves, chamado de aprovação de dispositivo. Para preservar o conhecimento zero, a aprovação de dispositivo é gerenciada localmente pelo usuário.

Modelo de criptografia SSO

Fluxo de primeiro dispositivo (integração de novo usuário)

1. A chave de dados, o par de chaves de compartilhamento e o par de chaves públicas/privadas de CE do dispositivo são gerados
2. A chave de dados é criptografada com a chave pública de CE do dispositivo e armazenada na nuvem (DEDK)
3. O usuário se conecta com o provedor de identidade (IdP)
4. Após a conexão IdP, a afirmação do SAML conectado é verificada pelo Keeper
5. O cofre é criado e o usuário é integrado

Fluxo de dispositivo existente

1. O usuário se conecta com o provedor de identidade (IdP)
2. Após a conexão IdP, a afirmação do SAML conectado é verificada pelo Keeper
3. O Keeper entrega a chave de dados criptografados do dispositivo (DEDK) ao usuário
4. A chave de dados é descriptografada com a chave privada de CE do dispositivo
5. A chave de dados descriptografa as chaves de pasta e chaves de registro
6. As chaves de registro descriptografam o conteúdo do registro

Fluxo de dispositivo novo ou não reconhecido

1. Em cada dispositivo novo, um par de chave pública/privada de CE é gerado
2. O usuário se conecta com o provedor de identidade (IdP)
3. Após a conexão IdP, a afirmação do SAML conectado é verificada pelo Keeper
4. O dispositivo é "aprovado" por Keeper Push, aprovação do administrador ou pelo serviço Keeper Automator (*consulte a aprovação de dispositivo abaixo)
5. Durante o processo de aprovação, a chave de dados é criptografada com a chave pública do novo dispositivo
6. A chave de dados criptografada pelo dispositivo (DEDK) é enviada ao usuário

Aprovação do dispositivo

• A aprovação do dispositivo é um mecanismo para oferecer seguramente a chave de dados do usuário ao novo dispositivo preservando o conhecimento zero
• Um usuário pode aprovar seu dispositivo criptografando a chave de dados com a chave pública do novo dispositivo
• Um administrador pode aprovar o dispositivo no console de administrador, Commander ou serviço Keeper Automator
• O administrador descriptografa a chave de dados do usuário e recriptografa a chave de dados com a chave pública do novo dispositivo
• O serviço Keeper Automator pode realizar aprovações automatizadas de dispositivo na infraestrutura do cliente
• O Keeper Automator verifica a assinatura do SAML, libera a chave de dados e criptografa a chave de dados com a chave pública do novo dispositivo

Leia mais sobre o serviço Keeper Automator.

Segurança de nível de dispositivo para a nuvem do SSO Connect

Para os usuários da nuvem SSO Connect, uma chave privada de curva elíptica é gerada e armazenada localmente em cada dispositov. Em navegadores de web modernos e no aplicativo de desktop do Keeper baseado em Electron, o cofre Keeper armazena a chave privada de CE do dispositivo local (“DPRIV”) como uma criptochave não exportável. Em dispositivos iOS e macOS, a chave é armazenada na Chave. Em dispositivos Android, a chave é criptografada com a Chave do Android, utilizando preferências compartilhadas criptografadas. Quando disponível, o Keeper utiliza mecanismo de armazenamento seguro em cada sistema operacional.

A chave privada de dispositivo não é usada diretamente para criptografar ou descriptografar dados. Após a autenticação do Provedor de Identidade, uma chave separada (que não está armazenada) é utilizada para descriptografar os dados do cofre. Portanto, a extração off-line da chave privada do dispositivo não pode descriptografar o cofre de um usuário.

Criptografia de dados em repouso

O Keeper usa AWS para hospedar a arquitetura e a plataforma Keeper. Nossas centrais de dados de AWS ficam localizadas em vários locais geográficos e nossos clientes podem hospedar o locatário Keeper em qualquer região principal preferencial. Isto garante que os dados dos clientes e o acesso à plataforma serão isolados a essa região específica.

Os dados do cofre em repouso são criptografados no dispositivo do usuário localmente usando AES-256 GCM e os dados criptografados em trânsito são criptografados com TLS 1.3 com uma camada adicional de criptografia na carga útil.

O modelo de criptografia do Keeper adere à seguinte estrutura:

• Todos os cofres são criptografados por uma chave AES de 256 bits única gerada no lado do cliente no modo GCM.
• Todas as chaves de nível de registro em pastas compartilhadas são envolvidas por uma chave de pasta compartilhada AES de 256 bits.
• As chaves de registro e de pasta para usuários do cofre são criptografadas com outra chave AES de 256 bits chamada de chave de dados.
• Para o Keeper Secrets Manager (KSM), as chaves de pasta e de registro do usuário são criptografadas com uma chave de aplicativo AES de 256 bits.
• Para usuários que se conectam com uma senha principal, as chaves para descriptografar e criptografar dados são derivadas da senha principal.
• Conectar-se com SSO ou tecnologia sem senha usa criptografia de curva elíptica para criptografar e descriptografar dados no dispositivo.
• Cada carga útil criptografada é enviada para os servidores do Keeper e sé envolvida por uma chave de transmissão AES de 256 bits com TLS - para garantir uma proteção contra ataques de intermediários (MITM). A chave é gerada no cliente e transferida usando criptografia ECIES com a chave de curva elíptica pública do servidor.
• O compartilhamento seguro de segredos entre usuários usa distribuição de chave de criptografia de curva elíptica.

Controle de versão de registros

O Keeper mantém um histórico de versão de criptografia completo de cada registro armazenado no cofre do usuário, fornecendo confiança de que nenhum dado crítico é perdido. No aplicativo de cliente do Keeper, os usuários podem examinar o histórico do registro e realizar uma restauração de qualquer registro de cofre individual. Se uma senha ou arquivo armazenado no Keeper for alterado ou excluído, os usuários sempre poderão realizar uma restauração de período específico.

Keeper Business

Clientes que compram o Keeper Business recebem uma camada a mais de controle sobre os usuários e dispositivos. Os administradores do Keeper recebem acesso a um console administrativo baseado em nuvem que permite controle completo sobre integração e desligamento de usuários, permissões baseadas em cargos, administração delegada, equipes, integração de Active Directory/LDAP, autenticação de dois fatores, Single Sign-On e políticas de garantia de segurança. As políticas de garantia baseadas em cargo do Keeper são completamente personalizáveis e dimensionáveis para organizações de todos os tamanhos.

Super criptografia de dados em repouso

Além de armazenar apenas texto cifrado criptografado pelo dispositivo na infraestrutura de AWS, o Keeper também realiza uma grande criptografia com módulos de segurança de hardware de várias regiões (HSM) usando chaves não exportáveis.

Criptografia e proteção de backups

No nível de produto/usuário, o software do Keeper mantém um histórico de revisão completo de cada registro. Portanto, se um usuário precisar de recuperação, ele pode ver e reverter para versões anteriores dos registros do Keeper armazenados a qualquer momento, sem limites, pela interface de usuário.

No nível do sistema, os bancos de dados criptografados e objetos de arquivos do Keeper são replicados e salvos em diversas regiões geográficas com a finalidade de restauração de desastres. Todos os backups são criptografados com AES de 256 bits, além da grande criptografia do texto cifrado gerado pelo dispositivo.

Clientes que exigem assistência de recuperação (por exemplo, porque um cliente acidentalmente excluiu um cofre ou pasta compartilhada), a equipe de suporte do Keeper pode auxiliar em uma recuperação de qualquer período (incluindo os minutos) dentro de 30 dias. O suporte do Keeper também pode ajudar em qualquer tipo de recuperação, incluindo restauração de usuário, de cofre ou empresarial completa.

Recuperação de conta

Uma frase de recuperação de 24 palavras permite que os clientes do Keeper recuperem o acesso ao cofre do Keeper caso percam ou esqueçam a senha principal.

O Keeper implementou as frases de recuperação usando a mesma lista de palavras BIP39 usada para proteger carteiras criptográficas. A lista de palavras no BIP39 é um conjunto de 2.048 palavras usadas para gerar uma chave de criptografia com 256 bits de entropia. Este método de recuperação é normalmente usado em carteiras de criptomoedas e bitcoins populares. Cada palavra na lista BIP39 é cuidadosamente selecionada para melhorar a visibilidade e tornar o processo de recuperação menos propenso a erros. Os usuários devem anotar a frase de recuperação e armazená-la em um local seguro, como um cofre.

A frase de recuperação gera uma chave AES de 256 bits que criptografa uma cópia da chave de dados do usuário. Para recuperar a conta e redefinir a senha principal, os usuários precisarão da frase de recuperação junto com um e-mail de verificação e autenticação de dois fatores (2FA).

Administradores empresariais podem desativar a restauração de conta no nível de política de garantia de cargo.

Chaves de criptografia empresarial

Clientes do Keeper Enterprise e Business podem gerenciar diversas capacidades da plataforma Keeper, como políticas de acesso baseado em cargo, fornecimento, autenticação e gestão.

As funções de administração são protegidas pela plataforma do Keeper com autorização e criptografia. A autorização garante que apenas usuários designados possam realizar determinadas funções. A criptografia garante que os administradores designados só podem realizar, física e criptograficamente, funcionalidades que envolvem os dados do cofre ou chaves controladas pela empresa. Eis alguns exemplos:

• A plataforma do Keeper é a grande plataforma de gerenciamento de chaves, onde os usuários e os administradores têm controle completo sobre as chaves privadas.
• Pares de chave de criptografia privada e pública são usados na criação de dispositivos, usuários e equipes.
• Políticas de cargo para transferir cofres e realizar aprovações de dispositivo utilizam chaves de criptografia privadas e públicas.
• Pares de chaves de curva elíptica (CE) são usadas para compartilhar dados entre usuários e do usuário individual ao administrador em níveis empresariais.
• Dados de uso confidencial, como força de senhas de registro, são criptografados com chaves públicas empresariais que apenas os administradores podem descriptografar.
• Os campos de tipo de registro, URL e título de registro de cada registro de cofre de usuário empresarial são criptografados com a chave pública empresarial e podem ser descriptografadas dentro do console de administrador do Keeper por um administrador atribuído com privilégios de geração de relatórios de conformidade.

Verificação de dispositivo

Antes de um usuário poder tentar se conectar a uma conta, ele precisa passar por uma etapa de verificação e aprovação de dispositivo. A verificação do dispositivo impede enumeração de contas e protege contra ataques de força bruta.

Clientes que se conectam com uma senha principal podem realizar a verificação do dispositivo usando diversos métodos, incluindo:

• Código de verificação de e-mail
• Entrada de código de 2FA de um TOTP ou mensagem de texto
• Uso do Keeper Push^™ para enviar uma mensagem a um dispositivo reconhecido

Para clientes que fazem a autenticação com o Keeper SSO Connect Cloud, a aprovação do dispositivo é realizada com uma transferência de chave, onde a chave de dados criptografados do usuário é entregue ao dispositivo, que então descriptografa localmente usando a chave privada de curva elíptica do usuário. Eis alguns métodos de aprovação de dispositivo:

• Keeper Push (usando notificações push) para dispositivos de usuários existentes
• Aprovação de administrador pelo console de administrador do Keeper
• Aprovação automática com o serviço Keeper Automator
• Aprovação automática de administrador com Commander CLI

Leia mais sobre aprovações de dispositivo.

Privacidade de dados

O Keeper tem conformidade GDPR e o compromisso de garantir que nossos processos e produtos mantenham conformidade GDPR para os nossos clientes na União Europeia e em todo o 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 a Política de Privacidade de GDPR do Keeper.

Nenhum dos aplicativos do Keeper contém rastreadores ou bibliotecas terceirizadas que realizam rastreamento. Por exemplo, este relatório fornece informações sobre o aplicativo de Android do Keeper, mostrando que zero rastreadores foram instalados.

Isolamento de dados

O Keeper é uma plataforma SaaS totalmente gerenciada e hospeda seus dados em várias centrais de dados AWS geograficamente isoladas. As organizações podem hospedar seu locatário do Keeper em sua região principal preferida. Os dados de clientes e o acesso à plataforma são isolados para essa região específica.

Regiões disponíveis:

• Estados Unidos (EUA)
• Nuvem do Governo dos Estados Unidos (US_GOV)
• Europa (EU)
• Austrália (AU)
• Japão (JP)
• Canadá (CA)

Criptografia em trânsito

O Cofre do Keeper é protegido por APIs que são validadas com a autorização do dispositivo do usuário.

• O usuário recupera um token de sessão com o login, enviando-o com cada chamada de API.
• O token de sessão é gerenciado e controlado no servidor de back-end.
• A conexão é realizada com uma senha principal, biometria, resumo de sessão ou autenticação SSO SAML 2.0.

Ao usar uma senha principal, o dispositivo do usuário deriva uma chave de autenticação de 256 bits usando PBKDF2-HMAC_SHA256 com 1.000.000 iterações e um sal aleatório. Um hash de autenticação é criado com hashing da chave de autenticação usando SHA-256. Ao se conectar, o hash de autenticação é comparado com o hash de autenticação armazenado no Cofre do Keeper. Depois que o usuário se conecta, um token de sessão é criado no servidor e enviado ao usuário para ser utilizado pelo dispositivo para futuras solicitações de API. Para permitir o uso contínuo das comunicações do cliente para o servidor, a sessão deve estar ativa.

• O Keeper usa TLS de 256 bits e 128 bits para criptografar 100% dos dados armazenados no aplicativo do usuário e o armazenamento seguro de arquivos do Keeper.
• O Keeper implementa certificados de TLS assinados usando o algoritmo SHA2. O SHA2 é o algoritmo de assinatura mais seguro atualmente disponível por autoridades de certificados comerciais. O uso de SHA2 do Keeper protege contra certificados falsificados que um agressor pode usar para imitar um site da web.

Autenticação de nuvem

O Keeper criou um modelo de comunicações de rede e autenticação de nuvem avançado com os maiores níveis de privacidade, segurança, confiança e transparência. Eis alguns dos principais recursos desse modelo de autenticação:

Integração com qualquer provedor SAML 2.0

O Keeper tem integração com todos os provedores de identidade compatíveis com SAML 2.0, incluindo Okta, Microsoft Entra ID (Azure), AD FS, Google Workspace, Centrify, OneLogin, PIng Identity, JumpCloud, Duo, Auth0 e muito mais.

Nossos produtos oferecem dois tipos de SSO: SSO Connect Cloud e SSO Connect On-Prem. As duas implementações oferecem arquitetura de conhecimento zero com autenticação simples para os usuários.

As senhas mestras de usuário nunca são transmitidas pela camada de rede

Diferente da maioria dos serviços de SaaS, as credenciais de login de usuários do Keeper nunca deixam o dispositivo. Quando os usuários se conectam usando uma senha principal, o PBKDF2 é utilizado no dispositivo local para derivar uma chave AES de 256 bits para concluir a descriptografia. Uma chave PBKDF2 é gerada no nível do dispositivo e é então passada por um process de hashing com HMAC_SHA256 para criar um token de autenticação. O Keeper tem conhecimento zero da chave de descriptografia do usuário.

O tráfego entre o dispositivo do cliente e a nuvem do Keeper não pode ser interceptado ou descriptografado

Todas as cargas úteis criptografadas enviadas para os servidores do Keeper são envolvidas por uma chave de transmissão AES de 256 bits e TLS para proteger contra ataques de intermediários (MITM). A chave de transmissão é gerada no dispositivo do cliente e transferida para o servidor usando criptografia ECIES com uma chave de CE pública do servidor.

Novos dispositivos não podem se conectar a uma conta sem uma etapa de verificação

Os usuários não podem usar novos dispositivos para acessar as contas do Keeper sem usar um método de verificação. O Keeper suporta vários tipos de métodos de verificação, dependendo do esquema de autenticação.

A autenticação multifatorial (MFA) é realizada após a verificação, antes de o usuário inserir a senha mestra

Se um usuário tiver AVF configurada ou garantida, será preciso realizar esta etapa antes de inserir a senha principal.

A senha mestra não pode ser inserida até que as etapas de verificação de dispositivo e autenticação multifatorial tenham sucesso

Caso não tenha método de verificação definido, o usuário não poderá prosseguir para inserir a senha principal. Essa autenticação avançada protege contra vários métodos de ataques comuns, incluindo ataques de força bruta, pulverização de senhas, enumeração e MITM.

Autenticação multifatorial (MFA)

Para se proteger contra o acesso não autorizado a uma conta de cliente, o Keeper oferece autenticação de vários fatores (AVF) – uma abordagem de autenticação que exige dois ou mais fatores de autenticação, que pode ser um fator de conhecimento, posse e/ou inerência. Leia mais sobre a configuração de AVF no Keeper.

O Keeper usa a senha principal e o dispositivo em posse para fornecer uma camada a mais de segurança caso a senha mestre ou o dispositivo seja comprometido. O Keeper suporta chaves de hardware FIDO2 WebAuthn e soluções baseadas em software como TOTP e SMS.

Ao usar o método de AVF/2FA TOTP, o Keeper egra uma chave de segredo de 10 bytes usando um gerador de número aleatório criptograficamente seguro. Este código é válido por cerca de um minuto e não pode ser reutilizado após realizar uma autenticação. O Keeper suporta qualquer aplicativo de TOTP, incluindo Google Authenticator e Microsoft Authenticator. O Keeper também integra diretamente serviços de AVF populares, como Duo e RSA SecurID.

Ao usar autenticadores de AVF, como Google Authenticator, Microsoft Authenticator ou outros aplicativos de TOTP no seu dispositivo móvel, o servidor do Keeper gera internamente um código QR contendo a chave secreta. Sempre que um usuário ativa a AVF, uma nova chave é gerada.

Para ativar a AVF, acesse a tela de configurações do aplicativo da web, de computador ou de iOS/Android do Keeper. Os administradores do Keeper Business também podem usar a AVF ou métodos de AVF suportados pelo console de administrador do Keeper.

Suporte para WebAuth compatível com FIDO2 é fornecido pelo Keeper, com dispositivos de chave de segurança baseados em hardware como chaves YubiKey e Google Titan como fator adicional. As chaves de passe também são suportadas como um método de 2FA usando dispositivos físicos ou navegadores da web. As chaves de segurança fornecem uma forma segura de realizar AVF sem precisar que o usuário insira os códigos manualmente.

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

Keeper Active Directory / LDAP Bridge

O Keeper Bridge é integrado com servidores Active Directory e LDAP para fornecer e integrar usuários. A comunicação do Keeper Bridge é primeiro autorizado por um administrador com o privilégio para gerenciar a ponte. Uma chave de transmissão é gerada e compartilhada com o Keeper para todas as comunicações subsequentes. O uso da chave de transmissão é a autorização de todas as operações realizadas pela ponte, exceto pela inicialização da ponte. A chave de transmissão pode ser gerada novamente a qualquer momento e será rotacionada automaticamente a cada 30 dias.

A chave de transmissão serve apenas para transmissões, o que significa que uma chave comprometida pode ser reinicializada ou revogada sem perder nenhum dado ou permissão.

O Keeper Bridge pode não conceder privilégios a uma função ou usuário. Ele pode adicionar um usuário a um cargo privilegiado, contanto que não sejam necessárias chaves de garantia. O Keeper Bridge não pode elevar a si ou um usuário acima da porção da árvore que está gerenciando. Nem todas as operações estão disponíveis para o Bridge. Por exemplo, o Bridge pode cancelar um usuário ativo, mas não pode excluir esse usuário. O administrador terá que escolher se o usuário será excluído ou transferido.

Autenticação SSO com MFA

Quando o Keeper é implantado com uma solução SSO, como Entra ID/Azure AD, Okta, Ping, Google Workspace ou qualquer outro provedor de identidade SAML 2.0, a MFA pode ser totalmente gerenciada durante o processo de login do IdP. O Keeper também oferece suporte a políticas de acesso condicional do Azure em todos os tipos de dispositivo e aplicativos.

A AVF pode ser exigida tanto no lado do Keeper quanto no lado do provedor de identidade. Por exemplo, quando um usuário passa da etapa de AVF com o provedor de identidade, ele pode adicionalmente ser forçado a passar por uma segunda etapa de AVF na interface do Keeper. Esta política pode ser forçada pelo administrador do Keeper.

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

Autenticação SAML 2.0 com nuvem SSO Connect

A Nuvem Keeper SSO Connect permite que clientes empresariais integrem completamente o Keeper com qualquer provedor de identidade com conformidade de SAML 2.0 e implementem cofres criptografados aos seus usuários.

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.

O Keeper Automator é um serviço opcional que realiza aprovações instantâneas de equipe, aprovações de dispositivo e atribuições de usuários de equipe após um login bem-sucedido do provedor de identidade SSO.

Quando o Automator estiver em execução, os usuários poderão acessar o Keeper em novos dispositivos (não aprovados anteriormente) após uma autenticação bem-sucedida com seu provedor de identidade, sem mais etapas de aprovação.

Keeper SSO Connect no local

Embora a maioria dos clientes implante a nuvem Keeper SSO Connect, os clientes que exigem uma solução local podem implantar o SSO Connect On-Prem, uma integração auto-hospedada que exige um servidor de aplicativo hospedado Windows ou Linux. Para manter a segurança de conhecimento zero e garantir uma experiência SSO perfeita para os usuários, o Keeper SSO Connect deve ser instalado no servidor do cliente. Os ambientes Windows, Mac e Linux são totalmente suportados com modos operacionais de balanceamento de carga de alta disponibilidade (HA) e super criptografia com módulos de segurança de hardware.

O Keeper SSO Connect gera automaticamente e mantém a senha principal para cada usuário fornecido, sendo uma chave de 256 bits gerada aleatoriamente. Esta senha principal é criptografada com a chave SSO. A chave SSO é criptografada com a chave da árvore. A chave SSO é retirada do servidor durante a inicialização do serviço Keeper SSO Connect e, em seguida, descriptografada usando a chave de árvore, que é armazenada localmente no servidor para suportar a inicialização do serviço automático. A comunicação entre o SSO Connect e o cofre de segurança de nuvem do Keeper é protegida com uma chave de transmissão. As comunicações de SAML são assinadas de forma criptográfica e protegidas por algoritmos de assinatura RSA-SHA256 ou ECDSA-SHA256, dependendo do tipo de chave de criptografia (RSA ou ECC) fornecida pelo cliente.

Compartilhamento

O Keeper suporta a capacidade de armazenar seguramente os registros entre usuários a uma equipe interna ou até mesmo fora da organização (se permitido pelo administrador do Keeper).

=Compartilhamento de registros

Os usuários do Keeper podem compartilhar diretamente registros entre si. Para fazer isso, o Keeper inicialmente solicita a chave pública de curva elíptica do usuário do cofre. Cada registro tem uma chave de registro que é criptografada com a chave pública de curva elíptica do destinatário e sincronizada com o Cofre Keeper do usuário.

O proprietário do registro compartilhado criptografado descriptografa a chave de registro com a chave privada de curva elíptica. A chave de registro também será recriptografada com a chave de dados do usuário e texto cifrado é armazenado no cofre do destinatário.

Compartilhamento único

O Compartilhamento Único do Keeper fornece um compartilhamento seguro e limitado de um registro, como senha, segredo, conexão, documento ou outra informação confidencial, com qualquer pessoa, mesmo se ela não tiver uma conta do Keeper. O modelo de criptografia de Compartilhamento Único do Keeper usa a mesma tecnologia que o Keeper Secrets Manager (KSM) – uma plataforma de conhecimento zero e confiança zero para proteger infraestruturas de nuvens.

1. No Cofre do Keeper de um usuário, o originador gera um acesso único clicando no Compartilhamento Único. A chave de registro AES de 256 bits é criptografada com um token de acesso único e o valor criptografado é armazenado no Cofre do Keeper.
2. O usuário compartilhando o token de acesso único com um destinatário usa um códgio QR ou URL simples. A porção do URL que contém o token de acesso é mantido dentro da porçaõ de "identificador de fragmento" do URL, que nunca é enviado para os servidores do Keeper. Portanto, o Keeper não pode acessar ou descriptografar as informações e o conhecimento zero é preservado.
3. O URL abre no navegador do usuário e o aplicativo de cofre é carregado no dispositivo. O token é entregue diretamente ao aplicativo de cofre local e não é enviado ao servidor.
4. O destinatário então usa o dispositivo para gerar um par de chaves de CE do lado do usuário final e a chave privada é armazenada localmente, no dispositivo, no armazenamento CryptoKey do navegador.
5. Durante o primeiro uso do destinatário, a biblioteca SDK autentica com o hashing do token de acesso único. Em seguida, o servidor do Keeper responde com o texto cifrado do registro criptogafado e a chave de registro criptografada.
6. O dispositivo descriptografa a chave de registro com o token de acesso único e o conteúdo é descriptografado. A chave é armazenada no dispositivo do cliente no armazenamento CryptoKey do navegador ou em outro local de armazenamento.
7. A chave de registro criptografada para o determinado dispositivo é excluída para que o token não seja usado novamente. Em seguida, o pedido do cliente deve ser assinado com a chave privada.
8. Mais chamadas no mesmo dispositivo são enviadas com um identificador que define o dispositivo e um pedido que é assinado com a chave privada de cliente. O pedido para o identificador de dispositivo concedido – por uma assinatura ECDSA – usa a chave pública de cliente do dispositivo e é conferida pelo servidor. O Keeper processa o pedido e o servidor devolve um registro criptografado em texto cifrado para o dispositivo do usuário.
9. Além da criptografia de nível de registro, o dispositivo do cliente cria uma chave de transmissão AES de 256 bits gerada aleatoriamente, criptografada com a chave pública da API de nuvem do Keeper. O dispositivo do cliente descriptografa a resposta do servidor com a chave de transmissão e, em seguida, descriptografa a carga útil de resposta em texto cifrado com a chave do registro, que descriptografa o conteúdo do registro.

Administrador de compartilhamento

O recurso de administrador de compartilhamento do Keeper é uma permissão de controle de acesso baseado em cargo (RBAC) que concede aos administradores privilégios elevados sobre os registros e pastas compartilhadas de uma organização. Os administradores de compartilhamento têm privilégios de registro e usuário completos para qualquer registro compartilhado que eles podem acessar.

Modelo de criptografia do Secrets Manager

O Keeper Secrets Manager (KSM) é uma plataforma de conhecimento zero para profissionais de TI e DevOps. Isso permite que equipes gerenciem segredos por todo o ciclo de vida de implementação e desenvolvimento de software.

O Secrets Manager usa o seguinte modelo de criptografia:

• A criptografia e descriptografia acontecem localmente no dispositivo (e não no servidor).
• Textos simples nunca são armazenados no dispositivo.
• O texto simples nunca é recebido pelo servidor.
• Ninguém, incluindo os funcionários do Keeper, terceiros ou intermediários, é capaz de descriptografar os segredos.
• O dispositivo do cliente gerencia as chaves para criptografar e descriptografar segredos, sob o controle do usuário.
• Cada segredo é criptografado por uma chave de criptografia AES de 256 bits gerada pelo lado do cliente no modo GCM.
• Se a chave estiver dentro de uma pasta compartilhada, a chave de registro é envolvida por uma chave de pasta compartilhada.
• A chave de aplicativo AES de 256 bits é gerada no lado do cliente e usada para descriptografar as chaves de registro e pasta compartilhada. A chave de registro então desvendará o segredo individual.
• Os servidores do Keeper são envolvidos por uma chave AES de 256 bits com TLS para garantir proteção contra ataques MITM.
• A chave de transmissão é gerada no dispositivo do cliente e transferida para o servidor usando criptografia ECIES pela chave de CE pública do servidor.
• A criptografia de curva elíptica é usada para compartilhar segredos entre usuários para realizar a distribuição de chaves de forma segura.
• A criptografia de várias camadas oferece controle de acesso aos níveis de usuários, grupo e administrador.
• Os segredos que são gerenciados dentro do cofre são segmentados e isolados para dispositivos definidos do Secrets Manager que recebem acesso ao registro e à pasta.

Modelo do Keeper Secrets Manager para rotação de senhas

• Um cliente Keeper Secrets Manager (KSM) exclusivo, chamado de gateway, é instalado no ambiente do cliente.
• O gateway estabelece uma conexão de limite seguro ao roteador do Keeper.
• O roteador é um serviço de nuvem hospedado em um ambiente AWS do Keeper, que facilita a comunicação entre a API de back-end do Keeper, os aplicativos de usuário final (cofre da web, aplicativo de computador etc.) e os gateways instalados no ambiente do usuário.
• Websockets são estabelecidos entre o dispositivo de usuário final (como um cofre de web) e o Roteador do Keeper, usando um token de sessão atual.
• O Roteador do Keeper verifica o token de sessão e autentica a sessão. Todas as cargas úteis criptografadas enviadas ao Roteador do Keeper são envolvidas por uma chave AES de 256 bits, além do TLS, para garantir proteção contra ataques MITM.
• A chaves AES de 256 bits é criada no dispositivo de usuário final e transferida para o servidor usando criptografia ECIES pela chave de CE pública do roteador.
• Os pedidos de descoberta e rotação são emitidos entre o dispositivo de usuário final (ou Keeper Scheduler) e o gateway pelo canal de comunicações do Websocket estabelecido.
• Durante a rotação, quando o gateway exige um segredo do Cofre do Keeper, ele é autenticado e descriptografa o segredo usando as APIs do Keeper Secrets Manager para preservar conhecimento zero.
• Como qualquer outro dispositivo de gerenciamento de segredos, o acesso também pode ser restrito com base no endereço IP, além dos processos de conexão e criptografia.

Conexão de confiança zero e segurança de túnel

O KeeperPAM de confiança zero oferece a capacidade de estabelecer sessões privilegiadas em nuvem e no local, criar túneis, estabelecer acesso direto à infraestrutura e proteger acesso remoto a banco de dados sem uma VPN.

Uma conexão é uma sessão remota visual usando o navegador da web. A interação entre o usuário e o dispositivo de destino é com uma janela do navegador da web ou dentro do aplicativo do Keeper Desktop.

Um túnel é uma conexão TCP/IP estabelecida entre o cliente de cofre local por meio do Keeper Gateway para o ponto de extremidade de destino. O usuário pode utilizar qualquer aplicativo nativo para se comunicar com o ponto de extremidade de destino, como o terminal de linha de comando, aplicativo GUI ou aplicativo de gerenciamento de banco de dados, como o MySQL Workbench.

Quando o usuário estabelece uma conexão ou um túnel:

1. O aplicativo cliente do cofre se comunica com a infraestrutura do roteador do Keeper para iniciar uma conexão WebRTC protegida por uma chave simétrica ECDH armazenada dentro do registro relevante do Keeper.
2. O Keeper Gateway se comunica com o roteador do Keeper por meio de webSockets apenas de saída. Isso é descrito em detalhes neste link.
3. O Keeper Gateway utiliza as APIs do Keeper Secrets Manager para obter os segredos necessários do cofre, incluindo a chave simétrica ECDH.
4. Para conexões, o cliente do cofre (usando o protocolo Apache Guacamole) passa dados por meio da conexão WebRTC para o Keeper Gateway que, em seguida, usa o Guacd para se conectar ao destino encontrado no registro do Keeper.
5. Para funcionalidades de túnel (encaminhamento de porta), uma porta local é aberta no dispositivo local com o software do Keeper Desktop. Os dados enviados para a porta local são transmitidos por meio da conexão WebRTC para o Keeper Gateway e posteriormente encaminhados para o ponto de extremidade de destino definido no registro do Keeper.
6. As gravações de sessão de conexões são protegidas por uma chave de criptografia AES-256 ("chave de gravação") que é gerada no Keeper Gateway em todas as sessões. A chave de gravação é adicionalmente envolvida por uma chave de fonte AES-256 derivada de HKDF.

Segurança de isolamento de navegador remoto

A tecnologia de isolamento remoto de navegador do Keeper protege o acesso a aplicativos de web internos ou qualquer outro ativo baseado na web por meio do contêiner do Docker do Keeper Connection Manager ou por meio do Keeper Gateway.

Como usar o método de contêiner do Docker do Connection Manager:

1. O usuário se autentica no serviço da web do Keeper Connection Manager, hospedado pelo cliente em um contêiner do Docker.
2. O usuário inicia uma sessão de isolamento de navegador remoto para o aplicativo da web de destino. Entre o navegador do usuário e o serviço web do Keeper Connection Manager hospedado, a comunicação por HTTPS é protegida pelo Let's Encrypt ou pelo certificado especificado do cliente.
3. No contêiner do Docker do Keeper Connection Manager, uma versão incorporada do Chromium é executada em um ambiente controlado, o site de destino é renderizado usando um driver de exibição local que transmite o conteúdo visível da página em tempo real para o navegador da web do usuário usando o protocolo Apache Guacamole.

Como usar o Keeper Gateway com o cofre do Keeper na Web ou o aplicativo para desktop:

1. O aplicativo cliente do cofre se comunica com a infraestrutura do roteador do Keeper para iniciar uma conexão WebRTC protegida por uma chave simétrica ECDH armazenada dentro do registro relevante do Keeper.
2. O Keeper Gateway se comunica com o roteador do Keeper por meio de webSockets apenas de saída. Isso é descrito em detalhes neste link.
3. O Keeper Gateway utiliza as APIs do Keeper Secrets Manager para obter os segredos necessários do cofre, incluindo a chave simétrica ECDH.
4. O cliente do cofre (usando o protocolo Apache Guacamole) passa dados por meio da conexão WebRTC para o Keeper Gateway que, em seguida, usa HTTP ou HTTPS para se conectar ao destino encontrado no registro do Keeper.
5. As gravações de sessão de conexões são protegidas por uma chave de criptografia AES-256 ("chave de gravação") que é gerada no Keeper Gateway em todas as sessões. A chave de gravação é adicionalmente envolvida por uma chave de fonte AES-256 derivada de HKDF.

Proteção de isolamento de navegador

Várias medidas de segurança são ativadas usando o protocolo de isolamento de navegador remoto:

1. O ponto de extremidade de aplicativo da web protegido é envolvido por uma camada de criptografia TLS do gateway do Keeper Connection Manager para o dispositivo local do usuário, independentemente de o TLS ser usado entre o gateway e o ponto de extremidade — protegendo contra ataque MITM ou inspeção de pacote na rede local do usuário.
2. A sessão de navegação remota projeta visualmente a interação para o dispositivo local do usuário usando uma tela e uma renderização gráfica. Nenhum código JavaScript ou HTML do site de destino é executado na máquina local do usuário.
3. Como nenhum código de site do destino é executado localmente e o navegador local não pode acessar diretamente o código de aplicativo subjacente, o aplicativo da web isolado é protegido contra vetores de ataque, como vulnerabilidades de script entre sites refletidas, falsificação de solicitação entre sites e abuso de API.
4. O usuário final pode ser impedido de realizar a exfiltração de dados do ponto de extremidade de destino por meio de filtragem de solicitação de URL e de fonte. Os uploads e downloads de arquivos são restritos, mesmo se o aplicativo da web de destino permitir a ação.
5. A sessão de navegação e as teclas digitadas podem ser registradas para fins de auditoria e conformidade, fornecendo a capacidade de realizar análise forense de sessões baseadas na web.
6. As credenciais que são preenchidas automaticamente do gateway para o aplicativo da web de destino nunca são transmitidas para o dispositivo do usuário e não são acessíveis pelo usuário em seu dispositivo local, protegendo contra vazamento secreto.
7. Por meio de políticas de firewall, o usuário pode ser obrigado a acessar o aplicativo da web de destino apenas por meio da sessão de isolamento de navegador remoto, reduzindo a ameaça de um navegador comprometido ou malware de dispositivo local.
8. O aplicativo da web de destino se torna protegido por logon único e/ou autenticação MFA, mesmo se o aplicativo não oferecer suporte nativo. O Keeper protege o acesso ao cofre e a qualquer sessão de isolamento de navegador remoto por meio dos métodos de autenticação avançada descritos neste documento.

BreachWatch^®

O Keeper opera uma arquitetura gerenciada de autocontenção no AWS chamada BreachWatch. O BreachWatch é fisicamente separado da API do Keeper e dos registros de usuários.

Um módulo de segurança de hardware físico (HSM) nos servidores do BreachWatch é usado para processar, fazer hashing e armazenar bilhões de senhas únicas de violações de dados da dark web. Todas as senhas são processadas nos servidores do Keeper usando o método de hashing HMAC_SHA512 e com HSM usando uma chave não exportável.

Quando o BreachWatch é ativado no dispositivo do cliente, um hash HMAC_SHA512 é gerado com base em todos os registros e enviado ao servidor. No servidor, um segundo hash é criado usando HMAC_SHA512 pelo HSM usando uma chave não exportável. Os "Hashes-of-Hashes" são comparados para conferir se uma credencial foi violada.

A arquitetura do BreachWatch foi construída para evitar a correlação de uma senha violada para uma senha no cofre do usuário, independentemente do tamanho da violação de dados. A detecção de senhas violadas utiliza um HSM físico para garantir que o hashing seja realizado apenas on-line – para evitar qualquer ataque de força bruta aos dados.

• As senhas passam por um processo de hashing duas vezes com HMAC_512: uma vez no dispositivo do cliente usando um "pepper", e outra no AWS CloudHSM usando um módulo de segurança de hardware com uma chave não exportável.
• O HMAC_512 é utilizado porque tira vantagem de uma função de hashing potente, além de uma chave secreta que não é exportável. Portanto, um ataque off-line contra os hashes não é algo viável.
• O código de autenticação de mensagem (MAC) com o resultado da função de hash criptográfica expande o uso de funções de hash. Os resultados dependem não só da mensagem, mas de uma segunda entrada que pode ser uma chave secreta.

O BreachWatch é 100% integrado pelo Keeper com o uso de feeds de dados do SpyCloud, mas o Keeper nunca envia dados para terceiros.

Varredura de domínios

Os clientes do BreachWatch baixam uma lista de domínios que foram violados e realiza a verificação localmente.

Varredura de nomes de usuários e senhas

Os dispositivos do cliente se conectam ao BreachWatch e carregam uma lista de usuários em hash (ou senhas) junto com um identificador aleatório selecionado pelo cliente (identificadores separados para serviços de verificação de nome de usuário e senha). Esses hashes de senha são processados no carregamento com HMAC usando um módulo de segurança de hardware (HSM) e uma senha secreta armazenada no HSM é marcada como não exportável (ou seja, o HSM apenas processará o HMAC localmente e a chave não pode ser extraída). Essas entradas de HMAC (nomes de usuários e senhas) são comparadas com os conjuntos de brechas que foram processadas com so mesmos HMAC e senha. Quaisquer valores incorrespondentes são armazenados junto com o ID anônimo do cliente.

Conforme novos nomes de usuários e senhas violados são adicionados ao sistema, eles são processados com HMAC no HSM, adicionados ao conjunto de dados do BreachWatch e comparados com os valores armazenados do cliente. Quaisquer correspondências acionam um alerta para o ID deste cliente.

Os clientes se conectam periodicamente ao BreachWatch e apresentam seus IDs do BreachWatch. As mensagens enfileiradas são baixadas e os clientes carregam nomes de usuários e senhas novos ou alterados, que são processados da mesma forma.

A segurança dos serviços do BreachWatch é do tipo "confiar no primeiro uso" (TOFU). Ou seja, os clientes devem supor que o servidor do BreachWatch não é malicioso (quer dizer, não está ativamente comprometido por um atacante) quando o cliente carrega os valores com hash. Quando esses valores são processados com um HSM, são protegidos contra tentativas de violação off-line. Em outras palavras, se um atacante rouba o conjunto de dados de valores armazenados do cliente, não conseguem violar esses valores off-line sem a chave HMAC armazenada no HSM.

Se a brecha de uma senha for detectada, o dispositivo do cliente envia um hash de combinação de nome de usuário e senha para os servidores do BreachWatch, que então realiza uma comparação de hash de HMAC para determinar se uma combinação de nome de usuário e senha foi violada e, se este for o caso, o domínio relacionado a essas brechas são devolvidos para que o cliente possa determinar se a combinação de nome de usuário, senha e domínio é correspondente. Se todos os três parâmetros forem correspondentes com o dispositivo do cliente, o usuário é acionado sobre a gravidade da brecha.

BreachWatch para clientes corporativos e empresariais

Quando o BreachWatch é ativado para clientes empresariais e comerciais, os cofres de usuário final são verificados automaticamente, sempre que um usuário se conecta com o Keeper. Os dados de resumo do BreachWatch verificados no dispositivo do usuário são criptografados com a chave pública empresarial e descriptografados pelo administrador empresarial ao se conectar com o console de administrador do Keeper. Estas informações criptografadas incluem endereço de e-mail, número de registros de alto risco, número de registros resolvidos e número de registros ignorados. O administrador do Keeper pode ver as estatísticas de resumo de nível de usuário dentro da interface de usuário do console de administrador.

Registro de eventos e relatórios

Quando integrados com os alertas e geração de relatórios avançados, os dispositivos de usuário final do Keeper também podem ser opcionalmente configurados para transmitir eventos em tempo real detalhados em soluções de SIEM terceirizadas e na interface de geração de relatórios do console de administrador do Keeper. Os dados de eventos contêm endereço de e-mail, UID de registro, endereço IP e informações de dispositivo (os eventos não incluem dados de registro descriptografados, já que o Keeper é uma plataforma de conhecimento zero e não pode descriptografar dados de usuários).

Por padrão, os dados de eventos detalhados do BreachWatch não são enviados para o módulo de alertas e geração de relatórios avançados ou qualquer sistema de registro externo conectado. Para ativar a geração de relatórios de nível de evento dos dados do BreachWatch para o módulo de alertas e geração de relatórios avançados, é preciso ativar a política de garantia de cargo de evento na tela de cargo específico > Políticas de Garantia > Recursos de Cofre. Após a ativação, os dispositivos de cliente de usuário final começarão a enviar estes dados de evento. Como a integração com soluções SIEM terceirizadas é transmitida do back-end do Keeper para o SIEM De destino, estas informações de evento são portanto legíveis pelo SIEM De destino e podem ser usadas para identificar quais registros e usuários dentro da organização têm senhas de alto risco. Se o Administrador do Keeper não quiser transmitir dados de eventos de nível de registro para o módulo de alertas e geração de relatórios avançados, esta configuração pode ficar desativada.

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

Modo off-line

O modo off-line permite que os usuários acessem seus cofres quando não são capazes de estabelecer conexão on-line com o Keeper ou outro provedor de identidade SSO. Esta capacidade está disponível no aplicativo móvel, no aplicativo de computador e no cofre de web do Keeper entre todos os navegadores.

A capacidade funciona fazendo uma cópia do cofre para o dispositivo local do usuário. Os dados do cofre armazenados of-line são criptografados por AES-GCM com uma "chave de cliente" de 256 bits gerada aleatoriamente e protegida por PBKDF2-HMAC-SHA512 com 1.000.000 iterações e um sal aleatório. O sal e as iterações são armazenados localmente. Quando o usuário insere a senha principal ou usa uma biometria, uma chave é derivada usando o sal e as iterações e uma tentativa é feita para descriptografar a Chave de Cliente. A Chave de Cliente é então usada para descriptografar o cache do registro armazenado. Se a proteção de autodestruição estiver ativada no cofre do usuário, 5 falhas de conexão apagará automaticamente todos os dados armazenados localmente no cofre. Para clientes comerciais, o acesso off-line pode ser restrito com base em políticas de cargo pelo administrador do Keeper.

Acesso de emergência (legado digital)

Os planos familiares e individuais do Keeper permitem que os usuários adicionem até cinco contatos de emergência para conceder acesso ao cofre no caso de morte ou outra emergência do usuário. O usuário especifica um tempo de espera e, quando esse tempo passa, o contato de mergência terá acesso ao cofre do usuário. Compartilhar o cofre com um contato de emergência é um processo de conhecimento zero e a senha principal do usuário nunca é compartilhada. Além disso, uma criptografia RSA de 2048 bits é usada com uma chave AES de 256 bits. O contato de emergência deve ter uma conta do Keeper para aceitar as informações.

Arquitetura de rede

O Keeper utiliza AWS na América do Norte (comercial ou GovCloud), Europa, Austrália, Japão e Canadá para a privacidade de dados localizados e isolamento geográfico para hospedar e operar a arquitetura e a solução do Keeper. Utilizar AWS permite que o Keeper dimensione com facilidade os recursos sob demanda e forneça aos usuários o ambiente de armazenamento de nuvem mais rápido e seguro. O Keeper opera em ambientes de várias zonas e regiões para maximizar o tempo de atividade e fornecer o melhor tempo de resposta aos clientes. Os clientes empresariais podem hospedar seus locatários Keeper em qualquer região de preferência. Os dados de clientes e o acesso à plataforma são isolados nessa região específica.

Autenticação de nuvem

O Keeper criou uma autenticação de nuvem avançada e um modelo de comunicações de rede que foi construído para os mais altos níveis de privacidade, segurança e confiança. Estes são alguns dos principais recursos do modelo de autenticação:

• A senha principal nunca é transmitida pela camada da rede. Diferente da maioria dos serviços de SaaS, as credenciais de login nunca deixam o dispositivo. PBKDF2 é utilizado no dispositivo local para derivar uma chave AES de 256 bits usada para realizar a descriptografia. Uma segunda chave PBKDF2 é gerada localmente e, em seguida, passa por um processo de hashing com HMAC_SHA256 para derivar um token de autenticação. O cofre de segurança de nuvem do Keeper tem conhecimento zero da chave de descriptografia do usuário.
• O tráfego entre o dispositivo do cliente e a nuvem do Keeper não pode ser interceptad.o nem descriptografado. O Keeper utiliza fixação de chave e camadas adicionais de criptografia de nível de rede (chaves de transmissão) entre o dispositivo e os servidores do Keeper para garantir que ataques de MITM sejam evitados.
• Novos dispositivos não podem se conectar a uma conta sem uma etapa de verificação de dispositivo. Nenhuma tentativa de conexão pode ser feita na conta sem passar por essa etapa. O Keeper suporta vários tipos de métodos de verificação de dispositivo que dependem do esquema de autenticação em uso
• A 2FA é realizada após a verificação do dispositivo, antes de inserir a senha principal. Se um usuário tem 2FA configurada ou obrigatória, esta etapa deve ser realizada antes de inserir a senha principal.
• A senha principal não pode ser inserida até a verificação do dispositivo e a etapa de 2FA serem concluídas. O usuário não pode prosseguir para a etapa da senha principal sem primeiro realizar a verificação do dispositivo e 2FA. Este fluxo de autenticação fornece proteção contra vários vetores de ataque, incluindo ataques de força bruta, pulverização de senhas, enumeração e MITM.

Criptografia em trânsito

O Cloud Security Vault do Keeper é protegido por APIs que são validadas por autorização do cliente. O cliente recupera um token de sessão ao se conectar, enviando-o com cada chamada de API. O token de sessão é rastreado no servidor. A conexão é realizada por uma senha principal, resumo de sessão ou autenticação de SSO de SAML 2.0.

Ao usar uma senha principal, o dispositivo do cliente deriva uma "chave de autenticação" de 256 bits usando PBKDF2-HMAC-SHA256 com 1.000.000 iterações e um sal aleatório de 128 bits. Um "hash de autenticação" é gerado pelo hashing da chave de autenticação usando SHA-256. Para se conectar, o hash de autenticação é comparado com um hash de autenticação armazenado no Cloud Security Vault. Após a conexão, um token de sessão é gerado no servidor e enviado para o cliente para ser usado pelo dispositivo do cliente para pedidos subsequentes de API. A sessão deve estar ativa para permitir o uso contínuo do cliente para realizar comunicações do servidor.

O Keeper suporta TLS de 256 bits e 128 bits para criptografar todos os transportes de dados entre o aplicativo do cliente e o armazenamento baseado em nuvem do Keeper.

O Keeper implementa certificados TLS assinados por DigiCert usando algoritmo SHA2, o algoritmo de assinatura mais seguro oferecido por autoridades de certificação comercial. O SHA2 é drasticamente mais seguro do que o amplamente usado SHA1, que pode ser explorado devido a fraquezas matemáticas identificadas no algoritmo. O SHA2 ajuda a proteger contra a emissão de certificados falsificados que podem ser usados por um agressor para falsificar um site da web.

O Keeper também apoia transparência de certificado (TC), uma iniciativa da Google para criar um registro publicamente fiscalizável de certificados assinados pelas autoridades de certificação. A TC ajuda a proteger contra a emissão de certificados de entidades não autorizadas. A TC é atualmente suportada nas versões mais recentes dos navegadores Chrome, Safari e Brave. Mais informações sobre a transparência de certificados podem ser conferidas em: https://certificate.transparency.dev/. O Keeper suporta os seguintes suites de cifra de 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

Os dispositivos de cliente do Keeper no iOS e Android também implementam fixação de senha, um mecanismo de segurança que impede a falsificação de agressores usando certificados digitais fraudulentos.

Proteção contra ataque de script entre sites (XSS)

O Cofre Web do Keeper implementa uma política rigorosa de segurança de conteúdo que restringe a origem das solicitações enviadas e impede todos os scripts de serem executados, exceto aqueles explicitamente provenientes do Keeper, incluindo scripts em linha e atributos HTML de tratamento de eventos, reduzindo ou eliminando a maioria dos vetores para ataques de script entre sites.

O acesso aos nomes de domínio Keeper é restrito a HTTPS com TLS 1.3 e é garantida por segurança de transporte estrito HTTP. Isso impede uma ampla variedade de ataques de detecção de pacotes, modificação de dados e intermediários.

Dentro da extensão de navegador do Keeper, o Keeper não pedirá aos usuários as credenciais dos cofres de dentro da área da moldura da página. A conexão à extensão ocorre dentro da área da barra de ferramentas da extensão do navegador. A conexão ao cofre no navegador da web acontecerá nos domínios keepersecurity.com, keepersecurity.eu, keepersecurity.com.au, keepersecurity.jp, keepersecurity.ca ou govcloud.keepersecurity.us ou a partir da barra de ferramentas da extensão de navegador do Keeper, que existe fora da página de conteúdo.

A extensão de navegador do Keeper coloca um iFrame nos formulários de conexão de uma página da web para garantir que nenhum site malicioso tenha acesso ao conteúdo injetado. O conteúdo do registro injetado nos iFrames também é limitado aos registros do cofre armazenado no cofre do usuário que corresponde ao domínio do site de destino. O Keeper não oferecerá preenchimento automático de dados de login ou senhas a não ser que o domínio do site da web corresponda ao campo do domínio do site da web do registro do cofre do Keeper. A extensão não mostrará registros a não ser que os registros correspondam ao domínio raiz do endereço do site da web.

Extensões de navegador terceirizados podem ter permissões elevadas em navegadores da web e podem acessar informações dentro da página. Portanto, recomenda-se que os administradores do Keeper evitem instalar extensões de navegadores terceirizadas da loja de aplicativos respectiva do navegador.

Biometria

O Keeper suporta de forma nativa Windows Hello, Touch ID, Face ID e biometria Android. Os clientes que se conectam normalmente ao Cofre do Keeper usando uma senha principal ou conexão SSO empresarial (SAML 2.0) também podem estabelecer conexão com os dispositivos usando biometria. A biometria deve ser ativada pelo administrador do Keeper na política de cargo. O acesso off-line também pode ser obtido com uma biometria da senha principal e dos usuários com SSO ativado quando esse recurso é acionado.

Quando a conexão biométrica é ativada em um dispositivo, uma chave é gerada aleatoriamente e localmente e armazenada em uma unidade segura (por exemplo, Chave ou Chaveiro) do dispositivo. A chave de dados do usuário é criptografada com a chave biométrica. Após realizar a autenticação biométrica, a chave é resgatada e o usuário é capaz de descriptografar o cofre.

Chaves do iOS, Touch ID e Face ID

Touch ID e Face ID em dispositivos iOS permitem que usuários acessem o seu cofre do Keeper usando biometria. Para fornecer este recurso conveniente, uma "chave biométrica" de 256 bits gerada aleatoriamente é armazenada na Chave do iOS. O item de Chave do iOS criado para esta funcionalidade não é designado para sincronizar com a Chave do iCloud e, portanto, não deixará o seu dispositivo móvel iOS.

É muito recomendado o uso de uma senha principal complexa e a ativação de autenticação de vários fatores para oferecer segurança máxima para o Cofre do Keeper. O uso de Touch ID e Face ID torna mais conveniente o uso de uma senha principal complexa no dispositivo móvel iOS. Também é recomendado a definição de uma senha maior do que o mínimo de 4 dígitos para proteger a Chave do iOS.

A Chave do iOS é usada por iOS e aplicativos para armazenar credenciais de forma segura. Os aplicativos de iOS usam a Chave do iOS para armazenar uma variedade de informações confidenciais, chaves, números de cartão de crédito e informações do Apple Pay. O Keeper não usa a Chave do iOS para armazenar os registros do Keeper - todos os registros do Keeper são protegidos com uma criptografia AES de 256 bits e armazenados de forma segura usando a senha do dispositivo. Mesmo quando o dispositivo é perdido ou quando um agressor obtém acesso físico ao dispositivo móvel, ele não poderá acessar nenhuma informação armazenada do Keeper. A Chave do iOS não pode ser descriptografada sem a senha e o Cofre do Keeper não pode ser descriptografado sem a senha principal do Keeper.

Apple Watch^®

O recurso Favorito do Apple Watch permite ver registros selecionados em Apple Watch pareado. Os registros do Keeper devem estar explicitamente habilitados para permitir exibição no Apple Watch. O Apple Watch pareado se comunica com a extensão de relógio do Keeper, que funciona de maneira invisível num espaço restrito, separado do aplicativo iOS Keeper. A extensão de relógio do Keeper também usa a Chave do iOS para armazenar com segurança e ter acesso a chaves para habilitá-lo a se comunicar de maneira imperceptível e segura com o aplicativo iOS Keeper.

Keeper DNA^®

O Keeper DNA oferece um método de autenticação de vários fatores usando um dispositivo de smart watch. O Keeper DNA usa tokens seguros armazenados no Cofre do Keeper para gerar códigos baseados em tempo para realizar autenticações de vários fatores. Esses pedidos de autenticação baseados em tempo podem ser aprovados e enviados automaticamente do Apple Watch (ou dispositivo Android Wear) com um toque na tela do relógio ou inseridos manualmente pelo usuário.

Desligamento de funcionários (transferência de cofre)

Quando uma política de transferência de conta é ativada para um nó, a política do nó para um par de chave privada/pública é criado no console de administrador no dispositivo do usuário. A chave de dados do usuário final – para usuários em um cargo aplicado – é criptografada com a chave pública da política quando o usuário se conecta ao cofre. A chave privada é criptografada com a chave pública do administrador e o administrador pode então descriptografar a chave de cargo com uma transferência de cofre.

Ao realizar uma transferência de cofre, o administrador do Keeper deve primeiro bloquear a conta do usuário. A transferência de cofre pode então ocorrer imediatamente, seguido da exclusão da conta do usuário. Isto garante que a operação não seja realizada em segredo. Ao realizar a transferência, a chave de dados do usuário é recuperada primeiro liberando a chave privada de cargo e, em seguida, liberando a chave de dados do usuário. A chave de dados é então usada para liberar as chaves de registro, as chaves de equipe e as chaves de pasta.

Toda a criptografia é realizada no lado do cliente dentro do console do administrador e em nenhum momento o Keeper tem a capacidade de descriptografar as informações que são compartilhadas ou transferidas. Além disso, em nenhum momento a chave de dados de cliente de um usuário é compartilhada. Um usuário que é removido de uma equipe, pasta compartilhada ou compartilhamento direto não receberá novos dados da equipe, pasta compartilhada ou registro. Apesar de as chaves de registro, pasta e equipe serem descriptografadas localmente para o administrador durante a transação, as chaves não podem ser usadas para obter acesso aos dados do registro ou da pasta.

Durante a transferência de cofres, o administrador só recebe a chave de dados criptografados, as chaves de registros criptografados e as chaves de pasta criptografada. As chaves são descriptografadas e, em seguida, recriptografadas com a chave pública do cofre de destino. O acesso aos dados de registro nunca é concedido. O Keeper não criptografa diretamente os dados armazenados pelo cliente com a chave de dados – tudo acontece no dispositivo.

Certificações e conformidade

O Keeper se importa muito com a segurança. O Keeper é a plataforma de gerenciamento de acesso privilegiado e solução de segurança de senhas com certificação, testes, auditorias e com a maior segurança do mundo. O Keeper tem as certificações SOC 2 e ISO mais duradouras do setor. O Keeper tem certificação ISO 27001, 27017 e 27018. O Keeper tem conformidade com GDPR, CCPA, HIPAA, autorização FedRAMP e StateRAMP, certificação PCI DSS e certificação TrustArc para privacidade.

• As equipes de desenvolvimento de software do Keeper consistem de funcionários integrais localizados nos EUA.
• O Keeper não armazena senhas, credenciais nem segredos como chaves de acesso no código fonte. Verificamos o código fonte dessas informações com frequência.
• O código fonte do Keeper, apesar de ser mantido de forma privada na GitHub Enterprise, não fornece as informações necessárias para acessar o cofre de um usuário, já que a criptografia dos dados ocorre no nível do dispositivo. Grande parte desse código é publicada em nosso repositório público do GitHub como parte dos produtos Secrets Manager e Commander do Keeper.
• O Keeper não integra código de provedores de AVF terceirizados em nossos aplicativos. Os vendedores do Keeper não passaram por nenhuma violação envolvendo o Keeper.
• O Keeper não fornece a nenhum terceiro gestão ou acesso às centrais de dados AWS. Toda a gestão é realizada pelos funcionários integrais do Keeper Security, que são cidadãos dos EUA, localizados nos EUA.

FIPS 140-3 validada

O Keeper utiliza módulos de criptografia validados por FIPS 140-3 para lidar com requisitos de segurança do setor público e governamentais. A criptografia do Keeper foi certificada pelo Programa de Validação de Módulo Criptográfico NIST (CMVP) e validado pelo padrão FIPS 140 por laboratórios terceirizados de confiança.

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

Conformidade com ITAR

A Nuvem de Governo de Segurança do Keeper (KSGC) suporta conformidade com o Regulamento de Tráfego em Armas Internacional dos Estados Unidos (ITAR). Companhias sujeitas a regulamentos de exportação de ITAR devem controlar exportações não intencionais restringindo o acesso aos dados protegidos aos cidadãos dos EUA e restringindo o local físico dos dados protegidos aos EUA.

O ambiente moderado FedRAMP do KSGC suporta os requisitos de ITAR com os seguintes itens:

• Armazenamento de dados completamente em conformidade hospedado em GovCloud AWS e restrito aos EUA.
• O KSGC oferece criptografia de dados seguros em trânsito e em repouso.
• Segurança de conhecimento zero e confiança zero, em conjunto com permissões granulares, permitem que as organizações garantam que apenas pessoas aprovadas possam acessar os dados confidenciais.
• Os recursos de relatórios de conformidade robusta fornecem um traço de auditoria eletrônico rastreável de todas as ações realizadas e dados inseridos.
• A equipe de sucesso de clientes de captura é composta de cidadãos dos EUA especificamente treinados para lidar com o controle de exportação e dados governamentais de ITAR sem apoio fora dos EUA.

O ambiente FedRAMP do Keeper foi fiscalizado por uma organização de avaliação terceirizada independente (3PAO) para validar que os controles adequados foram colocados para suportar os programas de conformidade de exportação de clientes e continua sendo fiscalizado anualmente conforme necessário para manter a conformidade.

Mais informações sobre ITAR.

Autorizado pelo FedRAMP

KSGC é a plataforma de segurança cibernética e gerenciamento de senhas do Keeper Security para organizações do setor público. KSGC é um provedor autorizado de FedRAMP no nível de impacto moderado, hospedado no AWS GovCloud (EUA). KSGC pode ser encontrado no Mercado FedRAMP.

O Programa de Gerenciamento de Autorização e Risco Federal (FedRAMP) é um programa do governo federal dos Estados Unidos que fornece uma abordagem padronizada a avaliações de segurança, autorizações e monitoração contínua para produtos e serviços de nuvem. O FedRAMP procura acelerar a adoção de soluções baseadas em nuvem pelas agências do governo, com ênfase em segurança e proteção de informações federais. Obtenha mais informações sobre FedRAMP.

Autorizado pelo StateRAMP

O StateRAMP foi desenvolvido cerca de uma década após FedRAMP, com o objetivo de encorajar a adoção de soluções seguras baseadas em nuvem em níveis de governo local e estadual. Conquistar a autorização de StateRAMP é normalmente um processo de dois anos facilitado pelo programa de reciprocidade graças à autorização FedRAMP do Keeper.

Conformidade com SOC 2

Os registros de cofre de cliente são protegidos usando práticas de controle interno monitorados e rigorosos. O Keeper tem conformidade SOC 2 Tipo 2 por dez anos de acordo com a estrutura de Controle de Organização de Serviço AICPA. A conformidade SOC 2 ajuda a garantir que os cofres de usuários sejam protegidos com a implementação de controles padronizados conforme definido pela estrutura de Princípios de Serviço de Confiança AICPA.

Certificações ISO

O Keeper tem certificação ISO 27001, 27017 e 27018, cobrindo a infraestrutura de nuvem e o sistema de gerenciamento de informações do Keeper Security, dando suporte à plataforma empresarial do Keeper. As certificações ISO do Keeper incluem gerenciamento e operação de serviços de nuvem e cofres digitais, controles de segurança de nuvem, controles de privacidade de dados, desenvolvimento de aplicativos e software e proteção de ativos digitais tanto para serviços de nuvem quanto para cofres digitais.

Conformidade com o FDA 21 CFR Parte 11

O Keeper está em conformidade com o 21 CFR Parte 11, que se aplica a cientistas trabalhando em ambientes altamente regulados, incluindo pesquisadores que conduzem estudos clínicos. Esta regulação especifica os critérios do FDA sob os quais os registros e as assinaturas eletrônicos são considerados confiáveis e equivalentes a registros em papel com assinaturas manuscritas. Especificamente, os cientistas devem garantir que todos os softwares que usam estejam em conformidade com as regras do 21 CFR Parte 11 em relação a:

Controles de segurança para identificação de usuários - O Keeper está em conformidade com os requisitos do 21 CFR Parte 11 para recursos de segurança que limitam o acesso dos usuários e seus privilégios, incluindo garantir que todos os usuários tenham nomes de usuários e senhas únicos, a capacidade de detectar e impedir acesso não autorizado aos sistemas e a habilidade de bloquear contas comprometidas.

Rastreamento de auditoria detalhado

Durante a inspeção de FDA, os reguladores exigem que os pesquisadores forneçam um caminho de fiscalização detalhando o registro cronológico de todas as operações. Os recursos de geração de relatórios de conformidade do Keeper permitem que os pesquisadores produzam facilmente os caminhos de auditoria eletrônica rastreáveis.

Assinaturas eletrônicas

Quando um documento exige uma assinatura eletrônica legalmente vinculável, o 21 CFR Parte 11 exige que ela esteja anexada a um login e senha únicos ou à identificação biométrica. O Keeper tem suporte para esse requisito ao permitir que os pesquisadores garantam que todos os usuários tenham nomes de usuário e senhas únicos, guardados seguramente em um cofre digital que somente o usuário pode acessar.

Mais informações sobre 21 CFR Parte 11 estão disponíveis aqui.

Proteção de dados médicos do paciente

O software Keeper está em conformidade com as normas de proteção de dados médicos, atendendo, sem limitação, a HIPAA (Lei de portabilidade e responsabilidade de seguro de saúde) e a DPA (Lei de proteção de dados).

Conformidade com HIPAA e Contratos de Associados Comerciais

O Keeper é uma plataforma de segurança de conhecimento zero com certificação SOC2 e ISO 27001 com conformidade HIPAA. Aderência e controles rigorosos que cobrem privacidade, confidencialidade, integridade e disponibilidade são mantidos. Com essa arquitetura de segurança, o Keeper não pode descriptografar, visualizar ou acessar quaisquer informações, incluindo ePHI, armazenadas no Cofre do Keeper de um usuário. Pelos motivos supracitados, o Keeper não é um Associado Comercial conforme definido no Ato de Contabilidade e Portabilidade de Garantia de Segurança (HIPAA) e, portanto, não está sujeito a um Acordo de Associação Comercial.

Para obter mais informações sobre os benefícios adicionais para os provedores de saúde e companhias de plano de saúde, leia todo este documento de segurança e acesse o nosso guia empresarial.

Certificação FSQS-NL

A Keeper Security EMEA Limited tem certificação do Hellios Financial Services Qualification System-Netherlands (FSQS-NL), que reconhece os padrões mais alto de segurança, qualidade e inovação nos Países Baixos. Esse padrão demonstra a conformidade com a Financial Conduct Authority e a Prudential Regulation Authority para garantir a confiabilidade do software Keeper Enterprise para grandes bancos e instituições financeiras.

Exportação licenciada pelo Departamento de Comércio dos EUA quanto à EAR

O Keeper é certificado pelo Departamento dos Estados Unidos do Sindicato de Comércio de Indústria e Segurança sob o Controle de Classificação de Commodity de Exportação Número 5D992, em conformidade com os Regulamentos de Administração de Exportação (EAR).
Para obter mais informações sobre EAR: https://www.bis.doc.gov

Monitoramento 24 horas por dia

O Keeper é monitorado 24 horas por dia, 7 dias por semana, 365 dias por ano por uma equipe de DevOps integral e uma rede de monitoração terceirizada global para garantir que nosso site e Cofre de Segurança em Nuvem estejam disponíveis mundialmente.

Caso tenha dúvidas sobre esta divulgação de segurança, entre em contato conosco.

E-mails clonados ou de phishing

Caso receba um e-mail supostamente enviado pela Keeper Security e não sabe ao certo se ele é legítimo, ele pode ser um "e-mail de phishing” onde o endereço de e-mail do remetente é forjado ou “spoofing”. Neste caso, um e-mail pode conter links para um site da web que se parece com KeeperSecurity.com, mas não é o nosso site. O site da web pode pedir a sua senha principal do Keeper Security ou tentar instalar softwares indesejados no computador em uma tentativa de roubar suas informações pessoais ou acessar seu computador. Outros e-mails contêm links que podem ser redirecionados para outros possíveis sites perigosos. A mensagem também pode incluir anexos que geralmente contêm softwares indesejados chamados de "malware". Caso não tenha certeza sobre um e-mail que recebeu na caixa de entrada, recomenda-se excluí-lo sem clicar em links ou abrir anexos.

Caso queira denunciar um e-mail se passando pela Keeper que você acha ser falso ou tenha outras dúvidas de segurança envolvendo outros casos, entre em contato conosco.

Certificado para infraestrutura de hospedagem de acordo com os mais rigorosos padrões do mercado

O site do Keeper e o armazenamento em nuvem são executados usando a infraestrutura de computação em nuvem segura Amazon Web Services (AWS). A infraestrutura de nuvem AWS, que armazena a arquitetura do sistema do Keeper, foi certificada para atender a certificações, relatórios e declarações dos seguintes terceiros:

Programa de caça a erros e registro de vulnerabilidades

O Keeper Security é dedicado para desenvolver a solução de gerenciamento de acesso privilegiado e senhas mais seguro do mercado. Temos o compromisso de proteger os dados pessoais e privados dos nossos clientes. A missão do Keeper é construir a plataforma mais segura e inovadora do mundo e acreditamos que os relatórios de erros da comunidade global de pesquisadores de segurança é essencial para garantir a segurança dos produtos e serviços do Keeper.

O Keeper conduz testes externos e internos extensivos, incluindo testes semestrais realizados pela NCC Group e CyberTest com acesso completo ao código fonte. O Keeper opera seu programa de divulgação de vulnerabilidade em parceria com a Bugcrowd. Isso beneficia todo o setor e, acima de tudo, apoia o bem social.

Diretrizes

A Política de Divulgação de Vulnerabilidades do Keeper define as expectativas ao trabalhar com hackers de boa fé, bem como o que você pode esperar de nós.

Se o teste de segurança e a geração de relatório são feitos dentro das diretrizes dessa política, nós:

• Aprovamos a autorização de acordo com o Ato de Abuso e Fraudes de Computador.
• Consideramos uma exceção do DMCA e não faremos queixa contra você por anular a segurança ou os controles de tecnologia.
• Consideraremos legal e não perseguiremos nem apoiaremos ações jurídicas relacionadas a esse programa contra você.
• Trabalharemos com você para entender e resolver este problema rapidamente.
• Reconhecermos suas contribuições publicamente caso seja a primeira pessoa a informar o erro e criar uma alteração de código ou configuração com base no problema.

Se, em qualquer momento, estiver preocupado ou não tiver certeza de que isto está dentro das diretrizes e do escopo dessa política, entre em contato com security@keepersecurity.com antes de prosseguir.

Para encorajar os testes de segurança de boa fé e a divulgação das vulnerabilidades descobertas, pedimos que você:

• Evite violar a privacidade do usuário, atrapalhar a experiência do usuário, interromper a produção ou os sistemas corporativos e/ou destruir dados.
• Realize apenas pesquisas dentro do escopo definido pelo programa de divulgação de vulnerabilidades Bugcrowd apresentado abaixo e respeite os sistemas e atividades que não estão no escopo.
• Entre em contato conosco imediatamente por security@keepersecurity.com caso encontre qualquer dado de usuário durante o teste.
• Forneça tempo suficiente para analisar, confirmar e resolver os problemas informados antes de liberar publicamente qualquer descoberta de vulnerabilidade.

Envie os relatórios para: https://bugcrowd.com/keepersecurity

Transparência

O Keeper tem muito compromisso e valoriza a segurança. É por isso que tornamos todos os detalhes do nosso modelo de criptografia disponível ao público. Acreditamos que nossos clientes merecem saber de todos os passos que tomamos para garantir que os dados estão seguros diante de um panorama de segurança cibernética que passa por mudanças sem parar.

O modelo de criptografia de conhecimento zero e confiança zero do Keeper garante que até no pior dos casos o seu Cofre Keeper é protegido e conduzimos continuamente testes de segurança para garantir que permaneceremos como a melhor solução para proteger seus dados mais valiosos.

Documentação do produto

O portal de documentação do Keeper, contendo manuais de produto, informações técnicas, notas de atualização e guias de usuário final, está disponível neste link.

Notas de atualização do produto

Para aumentar a transparência, o Keeper publica notas de atualização detalhadas entre todas as plataformas.

Status do sistema

O estado do sistema em tempo real pode ser encontrado aqui.