Perguntas frequentes sobre o AWS CloudHSM

Uma taxa por hora será cobrada para cada hora (ou hora parcial) em que um HSM for provisionado para um cluster do AWS CloudHSM. Um cluster sem HSMs não será cobrado. Também não será cobrado o armazenamento automático de backups criptografados. Para obter mais informações, visita a página de preços do AWS CloudHSM. Observe que as transferências de dados de rede enviadas e recebidas pelos seus HSMs são cobradas separadamente. Para obter mais informações confira a definição de preço de transferência de dados do EC2.

Não há nível gratuito disponível para o AWS CloudHSM.

Não. A taxa horária, que varia por região, não depende do volume de uso do HSM.

Não oferecemos preços de instâncias reservadas para o AWS CloudHSM.

Sim. Para começar a usar o AWS CloudHSM, há alguns pré-requisitos, incluindo uma nuvem privada virtual (VPC) na região em que você deseja usar o serviço AWS CloudHSM. Consulte o Guia do usuário do AWS CloudHSM para obter mais detalhes.

Não. A AWS gerencia o firmware no hardware. O firmware é mantido por um terceiro, e cada firmware deve ser avaliado pela NIST para comprovar a conformidade com o FIPS 140-2 nível 3. Apenas o firmware que tenha sido criptograficamente assinado pela chave do FIPS (à qual a AWS não tem acesso) poderá ser instalado.

A AWS recomenda enfaticamente o uso de pelo menos dois HSMs em duas AZs diferentes para qualquer carga de trabalho de produção. Para cargas de trabalho de missão crítica, recomendamos no mínimo três HSMs em pelo menos duas AZs separadas. O cliente CloudHSM administrará automaticamente qualquer falha e balanceamento de carga de HSM em dois ou mais HSMs de modo transparente para o seu aplicativo.

A AWS faz backups criptografados automáticos do seu cluster do CloudHSM diariamente. A AWS faz backups adicionais quando eventos de ciclo de vida do cluster (como a adição ou a remoção de um HSM) ocorrem. Durante o período de 24 horas entre os backups, você será inteiramente responsável pela durabilidade do material de chaves criado ou importado para o cluster. Recomendamos enfaticamente garantir que qualquer chave criada seja sincronizada com pelo menos dois HSMs em duas AZs diferentes para garantir a durabilidade das chaves. Consulte o Guia do usuário do AWS CloudHSM para obter mais detalhes sobre a verificação da sincronização de chaves.

A alta disponibilidade é fornecida automaticamente quando você tem pelo menos dois HSMs distribuídos em duas zonas de disponibilidade no cluster do CloudHSM. Nenhuma configuração adicional é necessária. No caso de falha de um HSM no cluster, ele será substituído automaticamente. Além disso, todos os clientes serão atualizados para refletir a nova configuração sem que nenhum processamento seja interrompido. HSMs adicionais podem ser incluídos no cluster por meio da API da AWS ou do AWS SDK, o que aumenta a disponibilidade sem interromper aplicativos.

Um único cluster do CloudHSM pode conter até 28 HSMs, sujeito aos limites de serviço da conta. Saiba mais sobre limites de serviço e como solicitar um aumento de limite na documentação online.

O backup do cluster do CloudHSM é feito diariamente pela AWS. As chaves também podem ser exportadas (“encapsuladas”) do cluster e armazenadas on-premises, desde que não tenham sido geradas como “não exportáveis”.

Sim, o Acordo de nível de serviço (SLA) do AWS CloudHSM pode ser encontrado aqui.

Não. Como parte do serviço, você recebe acesso unilocatário ao HSM. O hardware subjacente pode ser compartilhado com outros clientes, mas o HSM só pode ser acessado por você.

A separação de responsabilidades e o controle de acesso baseado em funções são inerentes ao design do AWS CloudHSM. A AWS tem uma credencial limitada para o HSM que nos permite monitorar e manter a integridade e a disponibilidade do HSM, usar backups criptografados e extrair e publicar logs de auditoria em seu CloudWatch Logs. A AWS não tem acesso a chaves ou dados em seu cluster do CloudHSM nem pode executar operações diferentes daquelas permitidas para um usuário de dispositivo HSM.

Consulte o Guia do usuário do AWS CloudHSM para obter mais informações sobre a separação de responsabilidades e os recursos de cada categoria de usuário no HSM.

Sim. O AWS CloudHSM publica várias métricas do Amazon CloudWatch para clusters do CloudHSM e HSMs individuais. É possível usar o Console, a API ou o SDK do Amazon CloudWatch para obter e enviar alarmes sobre essas métricas.

Cada HSM tem um Deterministic Random Bit Generator (DRBG – Gerador de bits aleatórios determinísticos) validado pelo FIPS e propagado por um True Random Number Generator (TRNG – Gerador de números aleatórios verdadeiros) no módulo de hardware do HSM compatível com o SP800-90B.

O AWS CloudHSM possui mecanismos de detecção de tentativas de violação física e lógica, bem como mecanismos de resposta que acionam a exclusão da chave (“zeramento”) do hardware. O hardware foi projetado para detectar violações se sua barreira física for rompida. Os HSMs também são protegidos contra ataques de login por força bruta. Após um número fixo de tentativas malsucedidas de acessar um HSM com credenciais de administrador ou responsável pela criptografia (CO), o HSM bloqueia o administrador/CO. De forma semelhante, depois de um número fixo de tentativas malsucedidas de acessar um HSM usando credenciais de usuário de criptografia (CU), o usuário será bloqueado e deverá ser desbloqueado por um CO ou administrador.

A Amazon monitora e mantém o HSM e a rede para verificar as condições de disponibilidade e erros. Se um HSM falhar ou perder a conectividade de rede, ele será substituído automaticamente. Você pode verificar a integridade de um HSM individual usando APIs, SDKs ou ferramentas de CLI do AWS CloudHSM, bem como verificar a integridade geral do serviço a qualquer momento usando o Painel de Integridade de Serviços da AWS.

Se o cluster do AWS CloudHSM tiver apenas um HSM, você poderá perder as chaves que foram criadas desde o backup diário mais recente. Os clusters do AWS CloudHSM com dois ou mais HSMs, teoricamente em zonas de disponibilidade separadas, não perderão as chaves se um único HSM falhar. Consulte nossas práticas recomendadas para obter mais informações.

Não. A Amazon não tem acesso a suas chaves ou credenciais e, portanto, não será capaz de recuperar suas chaves se você perder suas credenciais.

O AWS CloudHSM é baseado em hardware validado pelo Federal Information Processing Standard (FIPS) 140-2 nível 3. Informações sobre o perfil de segurança do FIPS 140-2 para o hardware usado pelo CloudHSM e o firmware por ele executado estão disponíveis em nossa página de conformidade.

Sim, o CloudHSM oferece HSMs validados pelo FIPS 140-2 nível 3. Siga o procedimento do Guia do usuário do CloudHSM (em Verificar a identidade e a autenticidade do HSM de seu cluster) para confirmar se você tem um HSM autêntico no mesmo modelo de hardware especificado na política de segurança da NIST descrita na pergunta anterior.

O AWS CloudHSM está sempre no modo FIPS 140-2. Isso pode ser verificado com as ferramentas de CLI, conforme documentado no Guia do usuário do CloudHSM, e executando o comando getHsmInfo, que indicará o status do modo FIPS.

Sim. O AWS CloudTrail registra as chamadas de API da AWS realizadas na sua conta. O histórico de chamadas de API da AWS gerado pelo AWS CloudTrail permite executar análises de segurança, rastreamento de alterações em recursos e auditoria de conformidade. Saiba mais sobre o AWS CloudTrail na página inicial do CloudTrail e ative-o no Console de Gerenciamento da AWS do CloudTrail.

O AWS CloudTrail não inclui nenhum dispositivo HSM nem logs de acesso. Esses itens são disponibilizados diretamente na sua conta da AWS via AWS CloudWatch Logs. Consulte o Guia do usuário do AWS CloudHSM para obter mais detalhes.

Consulte o site de conformidade da AWS para obter mais informações sobre quais programas de conformidade englobam o CloudHSM. Diferentemente de outros serviços da AWS, os requisitos de conformidade relacionados ao AWS CloudHSM são atendidos com frequência pela validação do FIPS 140-2 nível 3 do próprio hardware, em vez de como parte de um programa de auditoria.

O FIPS 140-2 nível 3 é um requisito de determinados casos de uso, inclusive da assinatura de documentos, de pagamentos ou da operação como uma CA pública para certificados SSL.

Para ver quais relatórios de conformidade estão no escopo do AWS CloudHSM, revise os dados em Serviços da AWS no escopo do programa de conformidade. Para criar relatórios de conformidade gratuitos, de autoatendimento e sob demanda, use o AWS Artifact.

Se estiver interessado apenas na validação FIPS para HSMs fornecida pelo AWS CloudHSM, consulte Validação FIPS.

A performance pode variar de acordo com a configuração, o tamanho dos dados e a carga adicional das aplicações nas instâncias do EC2. Para aumentar a performance, é possível adicionar instâncias do HSM extras aos clusters. Incentivamos a realização do teste de carga da aplicação para determinar as necessidades de escalabilidade.

Para obter mais detalhes, consulte a página de performance do Guia do usuário do AWS CloudHSM.

Para obter detalhes sobre armazenamento de chaves e capacidade do cluster, consulte Cotas do AWS CloudHSM.

Não diretamente. Você também pode usar o AWS Key Management Service com o armazenamento de chaves personalizadas para proteger dados do Amazon RDS usando chaves geradas e armazenadas no cluster do CloudHSM.

Vários fornecedores terceirizados aceitam o AWS CloudHSM como raiz de confiança. Isso quer dizer que você pode utilizar uma solução de software de sua preferência ao criar e armazenar as chaves subjacentes no cluster do CloudHSM.

O AWS CloudHSM Client Library é um pacote de software disponibilizado pela AWS que permite que você e suas aplicações interajam com clusters do CloudHSM.

Não. Todas as comunicações entre o cliente e o HSM são totalmente criptografadas. A AWS não consegue ver ou interceptar essa comunicação e não tem visibilidade sobre as credenciais de acesso ao cluster.

As instruções estão disponíveis no Guia do usuário do CloudHSM.

Não. As ferramentas do CloudHSM se comunicam diretamente com o cluster do CloudHSM via CloudHSM Client Library por meio de um canal protegido e mutuamente autenticado. Não é possível para a AWS observar nenhuma comunicação entre o cliente, as ferramentas e o HSM. Ela é criptografado de ponta a ponta.

A documentação on-line contém uma lista completa dos sistemas operacionais compatíveis.

O host em que você está executando o CloudHSM Client Library e/ou usando as ferramentas da CLI evem permitir acesso via rede a todos os HSMs no cluster do CloudHSM.

É possível criar, modificar, excluir e obter o status dos HSMs e clusters do CloudHSM. O que você pode fazer com a API do AWS CloudHSM está limitado às operações que a AWS pode executar com o acesso restrito que temos. A API não pode acessar o conteúdo do HSM, modificar nenhum usuário/nenhuma política, nem outras configurações. Para saber mais, consulte a documentação do CloudHSM para obter informações sobre a API ou a página Ferramentas da Amazon Web Services para obter mais informações sobre o SDK.

Comece garantindo que os algoritmos e modos necessários sejam compatíveis com o AWS CloudHSM. Se necessário, o seu gerente de contas poderá nos enviar solicitações de recursos. Em seguida, determine a estratégia de rotação de chaves. Além disso, publicamos um guia de migração para o AWS CloudHSM detalhado. Agora você já está pronto para começar a usar o AWS CloudHSM.

A estratégia de rotação dependerá do tipo de aplicação. Veja a seguir alguns exemplos comuns.

• Chaves privadas para assinatura: geralmente, a chave privada no HSM corresponde a um certificado intermediário que, por sua vez, é assinado por uma raiz corporativa offline. Você fará a rotação das chaves emitindo um novo certificado intermediário. Crie uma nova chave privada e gere o CSR correspondente usando o OpenSSL no CloudHSM. Em seguida, assine o CSR com a mesma raiz corporativa offline. Talvez seja necessário registrar esse novo certificado com parceiros que não verificam automaticamente toda a cadeia de certificados. A partir desse momento, você assinará todas as novas solicitações (como solicitações de documentos, códigos ou outros certificados) com a nova chave privada correspondente ao novo certificado. É possível continuar a verificar assinaturas da chave privada original usando a chave pública correspondente. Nenhuma revogação é necessária. Esse processo é análogo ou da retirada ou do arquivamento de uma chave de assinatura.
• Oracle Transparent Data Encryption: é possível transferir sua carteira mudando primeiro de um keystore de hardware (seu HSM original) para um Keystore de software e, em seguida, de volta para um keystore de hardware (AWS CloudHSM). Observação: se você estiver usando o Amazon RDS, consulte a pergunta frequente acima “O AWS CloudHSM é compatível com o Amazon RDS Oracle TDE?”
• Chave simétrica para criptografia de envelopes: a criptografia envelopada é a arquitetura de chaves em que uma chave no HSM criptografa/descriptografa várias chaves de dados no host do aplicativo. Provavelmente, você já tem um processo de rotação de chaves implantado que pode ser executado para descriptografar as chaves de dados com a chave de empacotamento antiga e criptografá-las novamente com a nova chave de empacotamento. A única diferença durante a migração será que a nova chave de empacotamento será criada e usada no AWS CloudHSM, e não no HSM original. Se você ainda não tiver uma ferramenta e um processo de rotação de chaves, será necessário criá-los.

Cada aplicativo e caso de uso é diferente. As soluções para cenários comuns são discutidas no guia de migração para o CloudHSM. Se tiver mais dúvidas, abra um caso de suporte com detalhes do aplicativo, o tipo de HSM e o tipo de chaves utilizado e se as chaves são exportáveis ou não. Ajudaremos a determinar um caminho de migração adequado.

Não, mas a AWS talvez precise realizar manutenção em caso de upgrades obrigatórios ou falha de hardware. Faremos todos os esforço para informar com antecedência no Painel de Integridade Pessoal se houver previsão de algum impacto.

Lembre-se de que é sua responsabilidade projetar o cluster para alta disponibilidade. A AWS recomenda enfaticamente o uso de clusters do CloudHSM com dois ou mais HSMs em zonas de disponibilidade separadas. Informações sobre as práticas recomendadas podem ser encontradas na documentação online.

O guia de solução de problemas contém soluções para vários problemas comuns. Se ainda tiver problemas, contate o AWS Support.