Perguntas frequentes do AWS Key Management Service

O AWS KMS recomenda políticas de uso e gerenciamento que você define. Você pode escolher se permite que usuários e funções do IAM da sua conta ou de outras contas usem e gerenciem suas chaves.

O AWS KMS foi projetado para que ninguém, nem mesmo os funcionários da AWS, possam recuperar as chaves KMS em texto simples do serviço. O AWS KMS usa módulos de segurança de hardware (HSMs) validados ou em processo de validação pelo FIPS 140-2 para proteger a confidencialidade e a integridade das chaves. Suas chaves do KMS de texto simples nunca saem dos HSMs, nunca são gravadas em disco e são usadas exclusivamente na memória volátil dos HSMs pelo tempo necessário para executar as operações criptográficas solicitadas. As atualizações de software nos hosts do serviço e no firmware do HSM do AWS KMS são controladas por um controle de acesso com vários participantes, auditado e revisado por um grupo independente dentro da Amazon, além de um laboratório com certificação NIST em conformidade com a FIPS 140-2.auditoria.

Mais detalhes sobre esses controles de segurança podem ser encontrados na documentação técnica sobre os detalhes criptográficos do AWS KMS. Também é possível analisar o Certificado FIPS 140-2 de HSMs para o AWS KMS junto com a Política de segurança associada para obter mais detalhes sobre como os HSMs do AWS KMS atendem aos requisitos de segurança do FIPS 140-2. Além disso, é possível fazer o download de uma cópia do relatório System and Organization Controls (SOC) do AWS Artifact para saber mais sobre os controles de segurança usados pelo serviço para proteger as chaves do KMS.

Não é necessário fazer nada. Todas as chaves do AWS KMS, independentemente da data de criação ou da origem, são protegidas automaticamente usando HSMs que foram validados sob o FIPS 140-2 com nível de segurança 3.

Os HSMs validados pelo FIPS 140-2 com nível de segurança 3 são implantados em todas as regiões da AWS em que o AWS KMS é oferecido.
OBSERVAÇÃO: por regulamentação, o AWS KMS nas regiões da China não pode usar HSMs validados pelo FIPS do NIST e, em vez disso, usa HSMs certificados pelo Escritório de Administração Estatal de Criptografia Comercial (OSCCA).

O AWS KMS é um serviço em duas camadas. Os endpoints da API recebem solicitações de clientes por uma conexão HTTPS usando apenas pacotes de cifras TLS que oferecem suporte à Perfect Forward Secrecy. Esses endpoints de API autenticam e autorizam a solicitação antes de enviá-la para uma operação criptográfica nos HSMs do AWS KMS ou seu cluster do AWS CloudHSM se você estiver usando o recurso de armazenamento de chave personalizada do KMS.

Você configura as aplicações para conexão aos endpoints HTTPS regionais únicos validados pelo FIPS 140-2. Os endpoints HTTPS validados pelo FIPS 140-2 do AWS KMS usam o OpenSSL FIPS Object Module. Você pode consultar a política de segurança do módulo OpenSSL aqui. Os endpoints de API validados pelo FIPS 140-2 estão disponíveis em todas as regiões comerciais onde o AWS KMS é oferecido.

Sim. O AWS KMS foi validado por dispor de funcionalidade e controles de segurança para ajudar a cumprir os requisitos de criptografia e gerenciamento de chaves (mencionados principalmente nas seções 3.5 e 3.6) do PCI DSS 3.2.1.

Para obter mais detalhes sobre os serviços em conformidade com o PCI DSS na AWS, consulte as Perguntas frequentes sobre o PCI DSS.

Você pode solicitar que o AWS KMS gere chaves de dados e as retorne para uso em seu próprio aplicativo. As chaves de dados são criptografadas em uma chave raiz que você define no AWS KMS para que possa armazenar com segurança a chave de dados criptografada com seus dados criptografados. Sua chave de dados criptografados (e, portanto, seus dados de origem) podem ser descriptografados somente por usuários com permissões para usar a chave raiz original usada para descriptografar a chave de dados criptografada.

Não, As chaves do AWS KMS são criadas e usadas apenas no serviço para ajudar a verificar sua segurança, permitir que suas políticas sejam aplicadas de maneira consistente e fornecer um log centralizado do seu uso.

Uma chave KMS de região única gerada pelo AWS KMS é armazenada e usada apenas na região em que foi criada. Com as chaves multirregionais AWS KMS, você pode escolher replicar uma chave primária multirregional em várias regiões na mesma partição AWS.

Os Logs no AWS CloudTrail mostrarão todas as solicitações da API do AWS KMS, inclusive solicitações de gerenciamento (como criação, rotação, desabilitação, edições na política) e solicitações criptográficas (como criptografar/descriptografar). Ative o CloudTrail na sua conta para ver esses logs.

O CloudHSM disponibiliza um cluster de HSM de locatário único validado em sua Amazon Virtual Private Cloud (VPC) para armazenar e usar suas chaves. Você tem controle exclusivo sobre como as chaves são usadas por meio de um mecanismo de autenticação independente da AWS. Você interage com as chaves no seu cluster do CloudHSM de forma semelhante à interação com os aplicativos executados no Amazon EC2. O CloudHSM pode ser usado para oferecer suporte a diversos casos de uso, como gerenciamento de direitos digitais (DRM), infraestrutura de chaves públicas (PKI), assinatura de documentos e funções criptográficas usando interfaces PKCS#11, Java JCE ou Microsoft CNG.
 

O AWS KMS ajuda você a criar e controlar as chaves de criptografia usadas por aplicações e serviços com suporte da AWS em diversas regiões do mundo usando um único console. O serviço usa um HSM do FIPS validado ou em processo de validação pelo FIPS 140-2 para proteger a segurança das chaves. O gerenciamento centralizado de todas as chaves no AWS KMS ajuda você a decidir quem pode usar as chaves em quais condições, quando elas são alteradas e quem pode gerenciá-las. A integração do AWS KMS com o CloudTrail oferece a capacidade de auditar o uso de suas chaves para apoiar suas atividades regulatórias e de conformidade. Você interage com o AWS KMS nas aplicações usando o AWS SDK para chamar diretamente as APIs de serviço por meio de outros serviços da AWS integrados ao AWS KMS ou usando o SDK de criptografia da AWS se quiser realizar criptografia do lado do cliente.

Com o AWS KMS, você paga somente por aquilo que usa e não há tarifa mínima. Não há taxas de instalação ou compromissos para começar a usar o serviço. No final do mês, seu cartão de crédito receberá a cobrança automática referente ao uso daquele mês.

Você será cobrado por todas as chaves KMS que criar e por todas as solicitações de API feitas ao serviço mensalmente que ultrapassarem o nível gratuito.
 

Para obter informações sobre os preços atuais, acesse a Página de preços do AWS KMS.

Sim. Com o nível gratuito da AWS, você pode começar a usar o AWS KMS gratuitamente* em todas as regiões. As chaves do AWS KMS gerenciadas pela AWS criadas em seu nome pelos serviços da AWS são gratuitas para armazenar na sua conta. Há um nível gratuito para uso que fornece um número gratuito de solicitações para o serviço por mês. Para obter informações atualizadas sobre preços, inclusive do nível gratuito, acesse a Página de preços do AWS KMS.

*As solicitações de API que envolvem chaves KMS assimétricas e as solicitações de API para as APIs GenerateDataKeyPair e GenerateDataKeyPairWithoutPlaintext são excluídas do nível gratuito.

Salvo indicação em contrário, nossos preços excluem impostos e taxas aplicáveis, incluindo o IVA e o imposto de vendas aplicável. Para clientes com endereço de pagamento no Japão, o uso da AWS está sujeito ao imposto sobre consumo japonês. É possível saber um pouco mais aqui.

Sim. Você pode importar uma cópia da chave usando sua própria infraestrutura de gerenciamento de chaves para o AWS KMS e usá-la com qualquer serviço da AWS integrado ou em seus próprios aplicativos.

Você pode usar uma chave importada para obter maior controle sobre a criação, o gerenciamento do ciclo de vida e a resiliência da chave no AWS KMS. As chaves importadas foram criadas para ajudá-lo a atender aos seus requisitos de conformidade, os quais podem incluir a capacidade de gerar ou manter uma cópia segura da chave na sua infraestrutura, como também a capacidade de excluir a cópia importada da chave sob demanda por meio da infraestrutura da AWS quando você não precisar mais dela.

Você pode importar chaves simétricas, chaves assimétricas (RSA e curva elíptica) e chaves HMAC.

Durante o processo de importação, sua chave deve estar encapsulada por uma chave pública fornecida pelo AWS KMS usando o algoritmo de encapsulamento compatível a seguir. Dessa forma, você verifica se a chave criptografada pode ser descriptografada apenas pelo AWS KMS.

Há duas diferenças principais:
 

1. Você é responsável por manter de modo seguro uma cópia das chaves importadas na infraestrutura de gerenciamento de chaves para poder importá-las novamente a qualquer instante. Entretanto, a AWS verifica a disponibilidade, a segurança e a resiliência das chaves geradas pelo AWS KMS em seu nome até que você programe sua exclusão.
2. Você pode definir um período de expiração para uma chave importada. O AWS KMS excluirá automaticamente o material da chave depois do período de expiração. Você também pode excluir o material da chave importada sob demanda. Em ambos os casos, o próprio material da chave é excluído, mas a referência da chave KMS no AWS KMS e os metadados associados são retidos para que o material da chave possa ser reimportado no futuro. As chaves geradas pelo AWS KMS não têm um tempo de expiração e não podem ser imediatamente excluídas, há um período de espera obrigatório de 7 a 30 dias. Todas as chaves KMS gerenciadas pelo cliente, independentemente de o material da chave ter sido importado ou não, podem ser manualmente desativadas ou programadas para exclusão. Nesse caso, a chave do KMS em si é excluída, não apenas o material da chave subjacente.

Você pode importar novamente sua cópia do material de chave com um período de expiração válido para o AWS KMS com a chave do AWS KMS original para permitir o seu uso.

Sim. Depois de importar a sua chave para uma chave do AWS KMS, você receberá uma métrica do CloudWatch de poucos em poucos minutos, fazendo a contagem regressiva até o momento da expiração da chave importada. Você também receberá um evento do CloudWatch quando a chave importada com a sua chave do AWS KMS expirar. Você pode criar uma lógica que atue nessas métricas, ou nesses eventos, e importe novamente de modo automático a chave com um novo período de expiração para evitar riscos de disponibilidade.

O AWS KMS é compatível com chaves de 256 bits no momento da criação de uma chave do KMS para criptografia e descriptografia. As chaves de dados geradas retornadas ao chamador podem ser de 256 bits, 128 bits ou um valor arbitrário de até 1.024 bytes. Quando o AWS KMS usa uma chave do KMS de 256 bits em seu nome para criptografar ou descriptografar, o algoritmo AES no modo Galois Counter Mode (AES-GCM) é usado.

O AWS KMS é compatível com os seguintes tipos de chave assimétrica: RSA 2048, RSA 3072, RSA 4096, ECC NIST P-256, ECC NIST P-384, ECC NIST-521 e ECC SECG P-256k1. O AWS KMS dá suporte aos algoritmos de criptografia RSAES_OAEP_SHA_1 e RSAES_OAEP_SHA_256 com os tipos de chave RSA 2048, RSA 3072 e RSA 4096. Os algoritmos de criptografia não podem ser usados com os tipos de chave de curva elíptica (ECC NIST P-256, ECC NIST P-384, ECC NIST-521 e ECC SECG P-256k1).

Ao usar tipos de chave de curva elíptica, o AWS KMS oferece suporte aos algoritmos de contrato de chave ECDH.

Ao usar tipos de chave RSA, o AWS KMS dá suporte aos algoritmos de assinatura RSASSA_PSS_SHA_256, RSASSA_PSS_SHA_384, RSASSA_PSS_SHA_512, RSASSA_PKCS1_V1_5_SHA_256, RSASSA_PKCS1_V1_5_SHA_384 e RSASSA_PKCS1_V1_5_SHA_512. Ao usar os tipos de chave de curva elíptica, o AWS KMS é compatível com os algoritmos de assinatura ECDSA_SHA_256, ECDSA_SHA_384 e ECDSA_SHA_512.

A parte pública do material da chave assimétrica é gerada no AWS KMS e pode ser usada para verificação de assinatura digital chamando a API “Verify” ou para criptografia de chave pública chamando a API “Encrypt”. A chave pública também pode ser usada fora do AWS KMS para verificação ou criptografia. Você pode chamar a API GetPublicKey para recuperar a parte pública da chave KMS assimétrica.

O limite de tamanho é de 4 KB. Se você deseja assinar digitalmente dados maiores que 4 KB, tem a opção de criar um resumo da mensagem e enviá-los ao AWS KMS. A assinatura digital é criada sobre o resumo dos dados e retornada. Você especifica se está enviando a mensagem completa ou um resumo da mensagem como parâmetro na solicitação de API Sign. Quaisquer dados enviados às APIs Encrypt, Decrypt ou Re-Encrypt que exigem o uso de operações assimétricas também devem ser menores que 4 KB.

No console, cada chave terá um novo campo chamado Key Type. Ele terá o valor Asymmetric Key ou Symmetric Key para indicar o tipo de chave. A API DescribeKey retornará um campo KeyUsage que especificará se a chave pode ser usada para assinar, gerar HMACs ou criptografar.

Não há suporte para a rotação de chave automática para chaves do KMS assimétricas ou HMAC. Em geral, a rotação de chaves assimétricas ou HMAC pode ser altamente prejudicial à sua workload existente, pois você precisa retirar e substituir todas as instâncias de chaves compartilhadas com outras partes no passado. Se necessário, você pode fazer a rotação manual delas criando uma nova chave do KMS e mapeando um alias de chave existente da chave do KMS antiga para a nova chave do KMS.

Não. Ao criar uma chave KMS, você deve especificar se a chave pode ser usada para operações de assinatura ou criptografia. Um tipo de chave RSA pode ser usado para operações de assinatura ou criptografia, mas não ambas. Os tipos de chave de curva elíptica podem ser usados apenas para operações de assinatura.

Sim. Os limites de taxa de solicitação por segundo são diferentes para diferentes tipos de chave e algoritmos. Consulte a página de limites do AWS KMS para obter detalhes.

Não. Você não pode usar a funcionalidade de armazenamento de chaves personalizadas com chaves assimétricas.

Não diretamente. O AWS KMS não armazena nem associa certificados digitais a chaves KMS assimétricas criadas por ele. Você pode optar por fazer com que uma autoridade de certificação, como o AWS Private Certificate Authority, emita um certificado para a parte pública da sua chave do KMS assimétrica. Isso permitirá que as entidades que estão consumindo sua chave pública verifiquem se a chave pública realmente pertence a você.

O recurso de armazenamento de chave personalizada do AWS KMS combina os controles fornecidos pelo CloudHSM com a integração e a facilidade de uso do AWS KMS. Você pode configurar seu próprio cluster do CloudHSM e autorizar o AWS KMS a usá-lo como armazenamento de chave dedicada para suas chaves, em vez do armazenamento padrão de chave do AWS KMS. Quando você cria chaves no AWS KMS, pode escolher gerar o material da chave em seu cluster do CloudHSM. As chaves KMS geradas em seu armazenamento de chave personalizada nunca deixam os HSMs no cluster do CloudHSM em texto simples e todas as operações do AWS KMS que usam essas chaves são realizadas apenas nos seus HSMs. Em todos os outros aspectos, as chaves KMS em seu armazenamento de chave personalizada são consistentes com outras chaves do AWS KMS.

Encontre orientação adicional para decidir se o uso de um armazenamento personalizado de chaves é ideal para você neste blog.

Como você controla o cluster do CloudHSM, tem a opção de gerenciar o ciclo de vida das chaves do KMS de forma independente ao AWS KMS. Há três razões pelas quais pode ser útil usar um armazenamento de chaves personalizado. Primeiro, você pode ter chaves que precisam explicitamente ser protegidas em um HSM de locatário único ou em um HSM sobre o qual você tem controle direto. Segundo, você pode precisar da capacidade de remover imediatamente o material da chave do AWS KMS e comprovar que fez isso por meios independentes. Terceiro, talvez você seja requerido a auditar todo o uso das chaves de forma independente ao AWS KMS ou ao CloudTrail.

Há duas diferenças ao gerenciar chaves em um armazenamento de chave personalizada respaldado pelo CloudHSM em comparação com o armazenamento de chave padrão do AWS KMS. Você não pode importar material de chave em seu armazenamento de chave personalizada e não pode fazer o AWS KMS executar a rotação automática das chaves. Em todos os outros aspectos, inclusive o tipo de chaves que podem ser geradas, a forma como as chaves usam aliases e como as políticas são definidas, as chaves armazenadas em um armazenamento de chave personalizada são gerenciadas da mesma forma como qualquer outra chave KMS gerenciada pelo cliente do AWS KMS.

Não, apenas chaves KMS gerenciadas pelo gerente podem ser armazenadas e gerenciadas em um armazenamento de chave personalizada do AWS KMS respaldado pelo CloudHSM. As chaves KMS gerenciadas pela AWS criadas em seu nome por outros serviços da AWS para criptografar seus dados são sempre geradas e armazenadas no armazenamento padrão de chave do AWS KMS.

Não, as solicitações de API para o AWS KMS usar uma chave KMS para criptografar e descriptografar dados são tratadas da mesma forma. Os processos de autenticação e autorização operam independentemente de onde a chave está armazenada. Toda a atividade que utiliza uma chave em um armazenamento de chave personalizada respaldado pelo CloudHSM também é registrado no CloudTrail da mesma forma. No entanto, as operações criptográficas reais acontecem exclusivamente no armazenamento de chave personalizada ou no armazenamento de chave padrão do AWS KMS.

Além da atividade registrada no CloudTrail pelo AWS KMS, o uso de um armazenamento de chave personalizada oferece três mecanismos adicionais de auditoria. Primeiro, o CloudHSM também registra todas as atividades da API no CloudTrail, como a criação de clusters e a adição ou remoção de HSMs. Segundo, cada cluster também captura seus próprios logs locais para registrar atividade do usuário e de gerenciamento de chave. Terceiro, cada instância do CloudHSM copia os logs de atividades do usuário local e de gerenciamento de chave para o AWS CloudWatch.

O uso de um armazenamento de chave personalizada do AWS KMS ajuda você a ser o responsável por verificar se as chaves estão disponíveis para uso do AWS KMS. Erros na configuração do CloudHSM e exclusão acidental do material de chave em um cluster do CloudHSM podem afetar a disponibilidade. O número de HSMs usados e sua escolha de zonas de disponibilidade (AZs) também podem afetar a resiliência do seu cluster. Como em qualquer sistema de gerenciamento, é importante compreender como a disponibilidade das chaves pode afetar a recuperação de seus dados criptografados.

A taxa na qual as chaves armazenadas no armazenamento de chave personalizada do AWS KMS respaldado pelo CloudHSM podem ser usadas por meio de chamadas de API do AWS KMS é menor do que para as chaves armazenadas no armazenamento de chave padrão do AWS KMS. Consulte o Guia do desenvolvedor do AWS KMS para ver os limites de performance atuais.

Os preços do AWS KMS não são afetados pelo uso de um armazenamento de chave personalizada. No entanto, cada armazenamento de chave personalizada exige que você mantenha um cluster do AWS CloudHSM que contenha pelo menos dois HSMs. Esses HSMs são cobrados conforme os preços padrão do AWS CloudHSM. Não há cobranças adicionais para usar um armazenamento de chave personalizada.

Os usuários do AWS KMS que quiserem usar um armazenamento de chave personalizada precisarão configurar um cluster do AWS CloudHSM, adicionar HSMs, gerenciar usuários dos HSMs e, possivelmente, restaurar HSMs para backup. Essas são tarefas que precisam de segurança, e você pode verificar se tem os recursos apropriados e se os controles organizacionais estão disponíveis.

Não, não há suporte para a capacidade de importar seu próprio material de chave para um armazenamento de chave personalizada do AWS KMS. As chaves armazenadas em um armazenamento de chave personalizada só podem ser geradas nos HSMs que formam seu cluster do CloudHSM.

Não, atualmente não há suporte para a capacidade de migrar chaves entre os diferentes tipos de armazenamento de chave do AWS KMS. Todas as chaves devem ser criadas no armazenamento de chave onde serão usadas, exceto nos casos em que você importar seu próprio material de chave no armazenamento de chave padrão do AWS KMS.

Não há suporte para a capacidade de fazer rotação automática do material de chave em um armazenamento de chave personalizada do AWS KMS. A rotação de chave deve ser realizada manualmente criando novas chaves e remapeando os aliases de chave do AWS KMS usados para o código da aplicação para usar as novas chaves para futuras operações de criptografia.

Sim, o AWS KMS não exige acesso exclusivo ao seu cluster do CloudHSM. Se você já tem um cluster, pode usá-lo como armazenamento de chave personalizada e continuar a usar para suas outras aplicações. No entanto, se o seu cluster estiver suportando cargas de trabalho altas e que não são do AWS KMS, você pode ter uma taxa de transferência reduzida para operações que usam chaves KMS em seu armazenamento de chave personalizada. Da mesma forma, uma alta taxa de solicitação do AWS KMS para seu armazenamento de chave personalizada pode afetar suas outras aplicações.

Acesse o site do AWS CloudHSM para obter uma visão geral do serviço. E para mais detalhes sobre configuração e uso do serviço, leia o Guia do usuário do AWS CloudHSM.

Um armazenamento de chave externo é um armazenamento de chave personalizado respaldado por uma infraestrutura de gerenciamento de chave externa que você possui e gerencia fora da AWS. Todas as operações de criptografia ou descriptografia que usam uma chave KMS em um armazenamento de chave externo são executadas em seu gerenciador de chaves com chaves criptográficas e operações que estão sob seu controle e são fisicamente inacessíveis para a AWS.

O XKS pode ajudar você a cumprir regras ou regulamentos que exigem que as chaves de criptografia sejam armazenadas e usadas fora da AWS sob seu controle.

As solicitações para o AWS KMS de serviços integrados da AWS em seu nome ou de suas aplicações são encaminhadas para um componente em sua rede chamado XKS Proxy. O XKS Proxy é uma especificação de API de código aberto que ajuda você e seu fornecedor de gerenciamento de chaves a criar um serviço que aceite essas solicitações e as encaminhe para sua infraestrutura de gerenciamento de chaves para usar suas chaves para criptografia e descriptografia.

A Thales, Entrust, Atos, Fortanix, DuoKey, Securonix, Utimaco, Salesforce, T-Systems e HashiCorp têm soluções que se integram à especificação XKS Proxy. Para obter informações sobre disponibilidade, preços e como usar soluções desses fornecedores, consulte a documentação disponibilizada por eles. Incentivamos você e seu parceiro de infraestrutura de gerenciamento de chaves a aproveitar a especificação XKS Proxy de código aberto para criar uma solução que atenda às suas necessidades. A especificação da API para XKS Proxy está publicada aqui.

As chaves externas são compatíveis as seguintes operações de criptografia simétrica: Encrypt, ReEncrypt, Decrypt e GenerateDataKey.

Você pode usar chaves XKS para criptografar dados em qualquer serviço da AWS que se integre ao AWS KMS usando chaves gerenciadas pelo cliente. Veja uma relação dos serviços compatíveis aqui. Os serviços da AWS chamam a API GenerateDataKey do AWS KMS para solicitar uma chave de dados de texto simples exclusiva para criptografar seus dados. A chave de dados em texto simples é devolvida ao serviço com uma cópia criptografada da chave de dados a ser armazenada com seus dados criptografados. Para produzir a cópia criptografada da chave de dados, a chave de dados em texto simples é primeiro criptografada por uma chave armazenada no AWS KMS exclusiva para sua conta da AWS. Essa chave de dados criptografada é então encaminhada para sua implementação XKS Proxy conectada ao gerenciador de chaves externo para ser criptografada uma segunda vez sob a chave definida por você no gerenciador de chaves externo. A chave de dados duplamente criptografada resultante é retornada na resposta à solicitação da API GenerateDataKey.

A conexão de rede entre o AWS KMS, sua implementação do XKS Proxy e seu gerenciador de chaves externo deve ser protegida com um protocolo de criptografia ponto a ponto como o TLS. No entanto, para proteger seus dados da saída do AWS KMS até chegarem ao gerenciador de chaves externo, o AWS KMS primeiro os criptografa com uma chave KMS gerenciada internamente em sua conta específica para cada chave KMS definida em seu armazenamento de chaves externo. O texto cifrado resultante é encaminhado para o gerenciador de chaves externo, que o criptografa usando a chave contida nele. A criptografia dupla fornece o controle de segurança de que nenhum texto cifrado pode ser descriptografado sem usar o material da chave em seu gerenciador de chaves externo. Ele também oferece o controle de segurança de que o texto cifrado que sai da rede da AWS é criptografado usando os HSMs KMS da AWS com certificação FIPS 140. Como seu gerenciador de chaves externo deve ser usado para descriptografar dados, se você revogar o acesso ao AWS KMS, os dados criptografados subjacentes ficarão inacessíveis.

Sim. As chaves XKS também podem ser usadas em suas aplicações ao usar uma solução de criptografia simétrica do lado do cliente com o AWS KMS como provedor de chaves. As soluções de criptografia do lado do cliente de código aberto da AWS, como o SDK de criptografia da AWS, o S3 Encryption Client e o DynamoDB Encryption Client, são compatíveis com XKS.

Todas as chaves XKS devem ser criadas como novas chaves no KMS. Você não pode migrar chaves KMS existentes para chaves XKS hospedadas em seu gerenciador de chaves externo.

Você pode criptografar novamente os dados existentes em chaves XKS recém-geradas, supondo que o serviço da AWS ou sua própria aplicação ofereça suporte a essa ação. Muitos serviços da AWS ajudarão você a copiar um recurso criptografado e designar uma nova chave KMS a ser usada para criptografar a cópia. Você pode configurar a chave XKS no comando COPY fornecido pelo serviço da AWS. Você pode criptografar novamente os dados criptografados do lado do cliente em suas aplicações chamando a API KMS ReEncrypt e configurando a chave XKS.

Como todas as chaves gerenciadas pelo cliente, as chaves do XKS custam USD 1 por mês por chave até que sejam excluídas. As solicitações sob chaves do XKS são cobradas de forma semelhante a qualquer outra chave simétrica do AWS KMS. Saiba mais sobre preços na página de preço do AWS KMS.

Sim. A rotação automática de chaves é suportada pela especificação XKS e é um recurso fornecido pela maioria dos fornecedores que oferecem suporte ao XKS. A rotação automática de chaves XKS ocorre inteiramente no gerenciador de chaves externo e funciona de forma semelhante à rotação automática de chaves do AWS KMS criadas e gerenciadas no KMS. Quando você usa uma chave KMS XKS rotacionada para criptografar dados, seu gerenciador de chaves externo usa o material da chave atual. Quando você usa a chave XKS rotacionada para descriptografar texto cifrado, seu gerenciador de chaves externo usa a versão do material de chave que foi usado para criptografá-la. Contanto que as chaves XKS anteriores usadas para criar textos cifrados ainda estejam habilitadas no gerenciador de chaves externo, você poderá fazer a solicitação de API Decrypt sob essas versões de chaves XKS com êxito.

Para serviços que não armazenam chaves em cache, a próxima chamada de API usando essa chave XKS KMS falhará. Alguns serviços implementam cache de chave de dados ou outros esquemas de derivação de chave para performance, latência ou gerenciamento de custos KMS. O armazenamento em cache dessas chaves pode variar de 5 minutos a 24 horas. Qualquer recurso protegido que esteja em uso no momento (como banco de dados RDS ou instância do EC2) responderá de maneira diferente depois que você negar o acesso à chave. Consulte a documentação do serviço da AWS relevante para obter detalhes.

Para autenticar para seu proxy de armazenamento de chaves externo, o AWS KMS assina todas as solicitações para o proxy usando credenciais AWS SigV4, que você configura em seu proxy e fornece ao KMS. O AWS KMS autentica seu proxy de armazenamento de chaves externo usando certificados TLS do lado do servidor. Ou seu proxy pode habilitar TLS mútuo para garantia adicional de que ele só aceita solicitações do AWS KMS.

Todos os mecanismos de autorização usuais do AWS KMS (políticas do IAM, políticas de chave do AWS KMS, concessões) que você usa com outras chaves KMS funcionam da mesma maneira para chaves KMS em armazenamentos de chaves externos.

Além disso, você e/ou seus parceiros de gerenciamento de chaves externo têm a capacidade de implementar uma camada secundária de controles de autorização com base nos metadados de solicitação incluídos em cada solicitação enviada do AWS KMS ao XKS Proxy. Esses metadados incluem o usuário/função da AWS de chamada, o ARN da chave KMS e a API KMS específica que foi solicitada. Isso permite que você aplique uma política de autorização refinada no uso de uma chave em seu gerenciador de chaves externo, em vez de simplesmente confiar em qualquer solicitação do AWS KMS. A escolha da aplicação da política usando esses atributos de solicitação é deixada para suas implementações individuais do XKS Proxy.

O ID exclusivo gerado para cada solicitação que chega ao AWS KMS envolvendo chaves XKS também é encaminhado para o XKS Proxy. Você pode usar os dados de log (se disponíveis) do XKS Proxy ou o gerenciador de chaves externo para reconciliar as solicitações feitas ao AWS KMS com aquelas feitas ao seu gerenciador de chaves externo. Esse recurso permite verificar se todas as solicitações de uso de chaves em seu gerenciador de chaves externo foram originadas de uma chamada iniciada por você para o AWS KMS diretamente ou por meio de um serviço integrado da AWS.

Risco de disponibilidade: você é responsável pela disponibilidade do XKS Proxy e do material de chave externo. Este sistema deve ter alta disponibilidade para verificar que sempre que você precisar de uma chave XKS para descriptografar um recurso criptografado ou criptografar novos dados, o AWS KMS pode se conectar com êxito ao XKS Proxy, que, por sua vez, pode se conectar ao gerenciador de chaves externo para concluir a operação criptográfica necessária usando a chave. Por exemplo, suponha que você criptografou um volume EBS usando uma chave XKS e agora deseja iniciar uma instância do EC2 e anexar esse volume criptografado. O serviço EC2 passará a chave de dados criptografada exclusiva desse volume para o AWS KMS para que ela seja descriptografada, para que possa ser provisionada na memória volátil do cartão Nitro para descriptografar e criptografar operações de leitura/gravação no volume. Se o XKS Proxy ou gerenciador de chaves externo não estiver disponível para descriptografar a chave de volume, a inicialização de sua instância do EC2 falhará. Nesses tipos de falha, o AWS KMS retorna um KMSInvalidStateException, informando que o XKS Proxy não está disponível. Agora, cabe a você determinar por que o XKS Proxy e o gerenciador de chaves estão indisponíveis com base nas mensagens de erro fornecidas pelo KMS.

Risco de durabilidade: como as chaves estão sob seu controle em sistemas fora da AWS, você é a única pessoa responsável pela durabilidade de todas as chaves externas que cria. Se a chave externa de uma chave XKS for permanentemente perdida ou excluída, todo o texto cifrado criptografado sob a chave XKS se tornará irrecuperável.

Risco de performance: você é responsável por verificar se o XKS Proxy e a infraestrutura de repositório de chaves externo foram projetados com características de desempenho suficientes para atender às suas necessidades. Como cada solicitação usando chaves XKS requer uma conexão com seu armazenamento de chaves externo, seu XKS Proxy poderá se tornar um gargalo se a taxa de solicitação do AWS KMS exceder a taxa de solicitação que o XKS Proxy ou o gerenciador de chaves externo pode suportar. Além disso, se o tempo decorrido de uma única solicitação (incluindo uma nova tentativa) do AWS KMS para o XKS Proxy for superior a 500 ms*, o AWS KMS retornará um erro 400 para o cliente autor da chamada, comunicando efetivamente que a chave XKS não está disponível e que o cliente não deve tentar novamente. Esse comportamento é projetado para minimizar o risco de serviços upstream da AWS ou de suas próprias aplicações precisarem reagir à latência excessiva esporádica causada por problemas de conectividade com a infraestrutura.

*O AWS KMS fará uma única tentativa para qualquer solicitação que leve 250 ms. Se a solicitação de nova tentativa também demorar mais de 250 ms, um erro 400 será retornado ao cliente autor da chamada.

Como a AWS não pode controlar a disponibilidade de ponta a ponta da conexão entre o AWS KMS e sua infraestrutura de repositório de chaves externo, excluímos especificamente o uso de XKS em nossa SLA pública de disponibilidade do KMS. Além disso, as chaves XKS são excluídas da SLA de disponibilidade para qualquer serviço da AWS no qual uma chave XKS é configurada por você para criptografar dados no serviço.