Criptografia de banco de dados do Amazon Redshift
No Amazon Redshift, você pode habilitar a criptografia de banco de dados para seus clusters para ajudar a proteger os dados em repouso. Quando você ativar a criptografia de um cluster, os blocos de dados e os metadados do sistema serão criptografados para o cluster o os snapshots.
É possível habilitar a criptografia ao iniciar o cluster ou modificar um cluster não criptografado para usar criptografia do AWS Key Management Service (AWS KMS). Para fazer isso, você pode usar uma chave gerenciada pela AWS ou uma chave gerenciada pelo cliente. Ao modificar o cluster para habilitar a criptografia do AWS KMS, o Amazon Redshift migra automaticamente os dados para um novo cluster criptografado. Os snapshots criados a partir do cluster criptografado também são criptografados. Você também pode migrar um cluster criptografado para um cluster não criptografado, modificando o cluster e alterando a opção Encrypt database (Criptografar banco de dados). Para ter mais informações, consulte Alterar a criptografia do cluster.
Embora a criptografia seja uma configuração opcional no Amazon Redshift, recomendamos que você a habilite para clusters que contêm dados sigilsos. Além disso, talvez seja necessário usar a criptografia, dependendo das diretrizes ou das regulamentações que regem os dados. Por exemplo, PCI DSS (Payment Card Industry Data Security Standard), SOX (Sarbanes-Oxley Act), HIPAA (Health Insurance Portability and Accountability Act) e outras regulamentações determinam as diretrizes para processar tipos de dados específicos.
O Amazon Redshift usa uma hierarquia de chaves de criptografia para criptografar o banco de dados. Você pode usar o AWS Key Management Service (AWS KMS) ou um Hardware Security Module (HSM – Módulo de segurança de hardware) para gerenciar as chaves de criptografia de nível superior nessa hierarquia. O processo usado pelo Amazon Redshift é diferente de acordo com a maneira que você gerencia chaves. O Amazon Redshift se integra automaticamente ao AWS KMS mas não com um HSM. Ao usar um HSM, você deve usar certificados de cliente e servidor para configurar uma conexão confiável entre o Amazon Redshift e seu HSM.
Melhorias no processo de criptografia para aumentar a performance e a disponibilidade
Criptografia com nós RA3
As atualizações no processo de criptografia dos nós RA3 melhoraram muito a experiência. Consultas de leitura e gravação podem ser executadas durante o processo, com menos impacto na performance decorrente da criptografia. Além disso, a criptografia termina muito mais rapidamente. As etapas atualizadas do processo incluem uma operação de restauração e a migração dos metadados do cluster para um cluster de destino. A experiência aprimorada se aplica a tipos de criptografia como o AWS KMS, por exemplo. Em casos de volumes de dados na escala de petabytes, a operação foi reduzida de semanas para dias.
Antes de criptografar um cluster, se você planeja continuar executando workloads de banco de dados, poderá melhorar a performance e acelerar o processo adicionando nós com redimensionamento elástico. Não é possível usar o redimensionamento elástico quando a criptografia está em andamento, então faça isso antes de iniciar a criptografia. Observe que a adição de nós normalmente resulta em um custo mais alto.
Criptografia com outros tipos de nós
Quando se criptografa um cluster com nós DC2, não é possível realizar consultas de gravação, ao contrário dos nós RA3. Somente consultas de leitura podem ser executadas.
Notas de uso para criptografia com nós RA3
Os insights e recursos a seguir ajudam você a se preparar para a criptografia e monitorar o processo.
-
Execução de consultas depois de iniciar a criptografia: depois que a criptografia é iniciada, as leituras e gravações ficam disponíveis em até 15 minutos. O tempo necessário para concluir todo o processo de criptografia depende da quantidade de dados no cluster e dos níveis de workload.
-
Quanto tempo demora a criptografia? O tempo necessário para criptografar os dados depende de vários fatores, como o número de workloads em execução, os recursos computacionais usados, o número de nós e os tipos de nós. Recomendamos que você execute a criptografia em um ambiente de teste primeiro. Como regra geral, se você estiver trabalhando com volumes de dados na escala de petabytes, a criptografia provavelmente levará de um a três dias para ser concluída.
-
Como saber se a criptografia foi concluída? – Depois de habilitar a criptografia, a conclusão do primeiro snapshot confirma que a criptografia foi concluída.
-
Reversão da criptografia: se você precisar reverter a operação de criptografia, a melhor maneira de fazer isso será restaurar o backup mais recente feito antes do início da criptografia. Você precisará reaplicar todas as novas atualizações (atualizações/exclusões/inserções) feitas depois do último backup.
-
Execução de uma restauração de tabela: observe que você não pode restaurar uma tabela de um cluster não criptografado para um cluster criptografado.
-
Criptografia de um cluster de nó único: esse tipo de criptografia apresenta limitações de performance. Ela é mais longa que a criptografia de um cluster de vários nós.
-
Criação de um backup depois da criptografia: quando você criptografa os dados de um cluster, nenhum backup será criado enquanto o cluster não estiver totalmente criptografado. A quantidade de tempo que isso leva pode variar. O tempo necessário para criação do backup pode ser de horas a dias, dependendo do tamanho do cluster. Após a conclusão da criptografia, poderá haver um atraso até que você possa criar um backup.
Observe que, como ocorre uma operação de backup e restauração durante o processo de criptografia, nenhuma tabela ou visão materializada criada com
BACKUP NOé retida. Para obter mais informações, consulte CRIAR TABELA ou CRIAR VISÃO MATERIALIZADA.
Tópicos
Criptografia por meio do AWS KMS
Quando você escolhe o AWS KMS para gerenciamento de chaves com o Amazon Redshift, há uma hierarquia de quatro camadas de chaves de criptografia. Essas chaves, em ordem hierárquica, são a chave raiz , uma chave de criptografia de cluster (CEK), uma chave de criptografia de banco de dados (DEK) e chaves de criptografia dos dados.
Quando você inicia seu cluster, o Amazon Redshift retorna uma lista das AWS KMS keys que sua conta da AWS criou ou tem permissão para usar no AWS KMS. Selecione uma chave KMS a ser usada como a chave raiz na hierarquia da criptografia.
Por padrão, o Amazon Redshift seleciona a chave padrão como a chave raiz. Sua chave padrão é uma chave gerenciada pela AWS que é criada para sua conta da AWS para uso no Amazon Redshift. O AWS KMS cria essa chave na primeira vez que você inicia um cluster criptografado em uma região da AWS e escolhe a chave padrão.
Se não quiser usar a chave padrão, você deve ter (ou criar) uma chave KMS gerenciada pelo cliente separadamente no AWS KMS antes de iniciar seu cluster no Amazon Redshift. As chaves gerenciadas pelo cliente dão mais flexibilidade, inclusive a possibilidade de criar, alternar, desativar e definir controle de acesso, além de auditar as chaves de criptografia usadas para ajudar a proteger os dados. Para obter mais informações sobre como criar chaves KMS, consulte Criar chaves no Guia do desenvolvedor do AWS Key Management Service.
Se quiser usar uma chave AWS KMS de outra conta da AWS, você deve ter permissão para usar a chave e especificar seu nome do recurso da Amazon (ARN) no Amazon Redshift. Para obter mais informações sobre acesso a chaves do AWS KMS, consulte Controlar o acesso a suas chaves no Guia do desenvolvedor do AWS Key Management Service.
Depois de escolher uma chave raiz, o Amazon Redshift solicita que o AWS KMS gere uma chave de dados e a criptografe usando a chave raiz selecionada. Essa chave de dados é usada como o CEK no Amazon Redshift. O AWS KMS exporta o CEK criptografado para o Amazon Redshift, onde é armazenado internamente em disco em uma rede separada do cluster junto com a concessão à chave KMS e o contexto de criptografia para o CEK. Somente o CEK criptografado é exportado para o Amazon Redshift; e a chave KMS permanece no AWS KMS. O Amazon Redshift também passa o CEK criptografado por um canal seguro para o cluster e o carrega na memória. Em seguida, o Amazon Redshift chama o AWS KMS para descriptografar o CEK e carrega o CEK descriptografado na memória. Para obter mais informações sobre concessões, contexto de criptografia e outros conceitos relacionados ao AWS KMS, consulte Conceitos no Guia do desenvolvedor do AWS Key Management Service.
Em seguida, o Amazon Redshift gera aleatoriamente uma chave para usar como DEK e a carrega na memória do cluster. O CEK descriptografado é usado para criptografar o DEK, que é então passado por um canal seguro do cluster para ser armazenado internamente pelo Amazon Redshift em disco em uma rede separada do cluster. Assim como a CEK, as versões criptografadas e descriptografadas da DEK são carregadas na memória no cluster. Em seguida, a versão descriptografada da DEK é usada para criptografar as chaves de criptografia individuais geradas aleatoriamente para cada bloco de dados no banco de dados.
Quando o cluster é reinicializado, o Amazon Redshift começa com as versões criptografadas e armazenadas internamente do CEK e do DEK, recarrega-as na memória e chama o AWS KMS para descriptografar o CEK com a chave KMS novamente para que possa ser carregada na memória. Em seguida, a CEK descriptografada é usada para descriptografar a DEK novamente, e a DEK descriptografada é carregada na memória e usada para criptografar e descriptografar as chaves do bloco de dados conforme necessário.
Para obter mais informações sobre como criar clusters do Amazon Redshift que são criptografados com chaves do AWS KMS, consulte Criar um cluster.
Copiar snapshots criptografados pelo AWS KMS para outra região da AWS
As chaves AWS KMS são específicas para uma região da AWS. Se você habilitar a cópia de snapshots do Amazon Redshift para outra região da AWS e o cluster de origem e seus snapshots forem criptografados usando uma chave raiz do AWS KMS, será necessário configurar uma concessão para o Amazon Redshift para usar uma chave raiz na região da AWS de destino. Essa concessão permite que o Amazon Redshift criptografe snapshots na região da AWS de destino. Para obter mais informações sobre uma cópia do snapshot em várias regiões, consulte Copiar um snapshot em outra região da AWS.
nota
Se ativar a cópia de snapshots de um cluster criptografado e usar o AWS KMS para a chave raiz, você não poderá renomear o cluster porque o nome do cluster faz parte do contexto da criptografia. Se você precisar renomear seu cluster, poderá desabilitar a cópia de snapshots na região da AWS de fonte, renomear o cluster e, em seguida, configurar e habilitar a cópia de snapshots novamente.
O processo para configurar a concessão para cópia de snapshots é este.
-
Na região da AWS de destino, crie uma concessão de cópia de snapshot fazendo o seguinte:
-
Se você ainda não tiver uma chave do AWS KMS a ser usada, crie uma. Para obter mais informações sobre como criar chaves AWS KMS, consulte Criar chaves no Guia do desenvolvedor do AWS Key Management Service.
-
Especifique um nome para a concessão de cópia do snapshot. Este nome deve ser único naquela região da AWS para sua conta da AWS.
-
Especifique o ID da chave do AWS KMS para o qual você está criando a concessão. Se você não especificar um ID da chave, a concessão se aplicará à chave padrão.
-
-
Na região da AWS de origem, habilite a cópia de snapshots e especifique o nome da concessão de cópia de snapshot que você criou na região da AWS de destino.
Este processo anterior só é necessário se você habilitar a cópia de snapshots usando a AWS CLI, a API do Amazon Redshift ou SDKs. Se você usar o console, o Amazon Redshift fornece o fluxo de trabalho adequado para configurar a concessão ao habilitar a cópia de snapshot entre regiões. Para obter mais informações sobre como configurar a cópia de snapshot em todas as regiões para clusters criptografados pelo AWS KMS usando o console, consulte Configurar a cópia de snapshots entre regiões para um cluster criptografado pelo AWS KMS.
Antes que o snapshot seja copiado para a região da AWS de destino, o Amazon Redshift descriptografa o snapshot usando a chave raiz na região da AWS de fonte e recriptografa temporariamente usando uma chave RSA gerada aleatoriamente que o Amazon Redshift gerencia internamente. Em seguida, o Amazon Redshift copia o snapshot em um canal seguro para a região da AWS de destino, descriptografa o snapshot usando a chave RSA gerenciada internamente e, em seguida, criptografa novamente o snapshot usando a chave raiz na região da AWSde destino.
Criptografia por meio de módulos de segurança de hardware
Se você não usa o AWS KMS para gerenciamento de chaves, pode usar um módulo de segurança de hardware (HSM) para gerenciamento de chaves com o Amazon Redshift.
Importante
A criptografia de HSM não é compatível com tipos de nós DC2 e RA3.
HSMs são dispositivos que oferecem controle direto sobre a geração e o gerenciamento de chaves. Eles fornecem maior segurança separando o gerenciamento de chaves das camadas de aplicação e banco de dados. O Amazon Redshift oferece suporte ao AWS CloudHSM Classic para gerenciamento de chaves. O processo de criptografia é diferente quando você usa o HSM para gerenciar as chaves de criptografia, em vez do AWS KMS.
Importante
O Amazon Redshift suporta apenas AWS CloudHSM Classic. Não há suporte para o serviço mais recente do AWS CloudHSM.
O AWS CloudHSM Classic está fechado para novos clientes. Para obter mais informações, consulte Preço do CloudHSM Classic
Quando você configura seu cluster para usar um HSM, o Amazon Redshift envia uma solicitação ao HSM para gerar e armazenar uma chave a ser usada como CEK. No entanto, ao contrário do AWS KMS, o HSM não exporta o CEK para o Amazon Redshift. Em vez disso, o Amazon Redshift gera aleatoriamente o DEK no cluster e o passa para o HSM para ser criptografado pelo CEK. O HSM retorna a DEK criptografada ao Amazon Redshift, onde ela é mais criptografada usando uma chave raiz interna gerada aleatoriamente e armazenada internamente em disco em uma rede à parte do cluster. O Amazon Redshift também carrega a versão descriptografada da DEK na memória no cluster, de maneira que a DEK possa ser usada para criptografar e descriptografar as chaves individuais dos blocos de dados.
Se o cluster for reinicializado, o Amazon Redshift descriptografa a DEK criptografada duplamente armazenada internamente usando a chave raiz interna para retornar a DEK armazenada internamente ao estado criptografado por CEK. O DEK criptografado por CEK é então passado ao HSM para ser descriptografado e devolvido ao Amazon Redshift, onde pode ser carregado na memória novamente para uso com as chaves de bloco de dados individuais.
Configurar uma conexão confiável entre o Amazon Redshift e um HSM
Quando você opta por usar um HSM para gerenciamento de sua chave de cluster, você precisa configurar um link de rede confiável entre o Amazon Redshift e seu HSM. Isso exige a configuração dos certificados de cliente e servidor. A conexão confiável é usada para passar as chaves de criptografia entre o HSM e o Amazon Redshift durante as operações de criptografia e descriptografia.
O Amazon Redshift cria um certificado de cliente público a partir de um par de chaves públicas e privadas gerado aleatoriamente. Elas são criptografadas e armazenadas internamente. Você faz download e registra o certificado cliente público no HSM, além de atribui-lo à partição do HSM aplicável.
Você fornece ao Amazon Redshift o endereço IP HSM, o nome da partição HSM, a senha da partição HSM e um certificado de servidor HSM público, que é criptografado usando uma chave raiz interna. O Amazon Redshift conclui o processo de configuração e verifica se ele pode se conectar ao HSM. Se não puder, o cluster será colocado no estado INCOMPATIBLE_HSM, e não será criado. Nesse caso, você deve excluir o cluster incompleto e tentar novamente.
Importante
Quando você modifica seu cluster para usar uma partição HSM diferente, o Amazon Redshift verifica se ele pode se conectar à nova partição, mas não verifica se existe uma chave de criptografia válida. Para usar a nova partição, você deve replicar as chaves para a nova partição. Se o cluster for reiniciado e o Amazon Redshift não puder encontrar uma chave válida, a reinicialização falhará. Para obter mais informações, consulte Replicação de chaves entre os HSMs.
Após a configuração inicial, se o Amazon Redshift não conseguir se conectar ao HSM, um evento será registrado. Para obter mais informações sobre esses eventos, consulte Notificações de evento do Amazon Redshift.
Alternância de chaves de criptografia
No Amazon Redshift, você pode alternar as chaves de criptografia para clusters criptografados. Quando você inicia o processo de alternância de chaves, o Amazon Redshift alterna a CEK do cluster especificado e de qualquer snapshot automatizado ou manual do cluster. O Amazon Redshift também alterna a DEK do cluster especificado, mas não pode alternar a DEK dos snapshots enquanto eles permanecem armazenados internamente no Amazon Simple Storage Service (Amazon S3) e criptografados usando-se a DEK existente.
Enquanto a alternância está em andamento, o cluster é colocado em um estado ROTATING_KEYS até a conclusão, momento em que o cluster retorna ao estado AVAILABLE. O Amazon Redshift lida com a descriptografia e a recriptografia durante o processo de alternância da chave.
nota
Você não pode alternar chaves para snapshots sem um cluster de origem. Para excluir um cluster, leve em consideração se os snapshots dependem do rodízio da chave.
Como o cluster está temporariamente indisponível durante o processo de rodízio da chave, você deverá alternar as chaves somente com a frequência que os dados exigirem ou quando suspeitar de que as chaves foram comprometidas. Como melhores práticas, você deve examinar o tipo de dados que armazena e planejar com que frequência alternar as chaves que criptografam esses dados. A frequência para alternar chaves varia de acordo com as políticas corporativas da segurança de dados e todos os padrões do setor referentes aos dados confidenciais e à compatibilidade regulatória. Verifique se o plano equilibra necessidades de segurança com considerações sobre disponibilidade para o cluster.
Para obter mais informações sobre como alternar chaves, consulte Alternar chaves de criptografia.
