O Amazon Redshift não permitirá mais a criação de UDFs do Python a partir do Patch 198. As UDFs do Python existentes continuarão a funcionar normalmente até 30 de junho de 2026. Para ter mais informações, consulte a [publicação de blog ](https://aws.amazon.com/blogs/big-data/amazon-redshift-python-user-defined-functions-will-reach-end-of-support-after-june-30-2026/). # Criptografia de dados Proteção de dados refere-se à proteção de dados durante o trânsito (enquanto eles viajam de e para o Amazon Redshift) e em repouso (enquanto são armazenados em discos nos datacenters do Amazon Redshift). Você pode proteger os dados em trânsito, utilizando SSL ou a criptografia no lado do cliente. Você tem as opções a seguir de proteção de dados em repouso no Amazon Redshift. + **Usar criptografia do lado do servidor** – Você solicita que o Amazon Redshift criptografe seus dados antes de salvá-los em discos em seus datacenters e descriptografá-los ao baixar os objetos. + **Usar criptografia do lado do cliente** — Você pode criptografar dados no lado do cliente e carregar os dados criptografados no Amazon Redshift. Nesse caso, você gerencia o processo de criptografia, as chaves de criptografia e as ferramentas relacionadas. # Criptografia inativa A criptografia do lado do servidor trata da criptografia de dados em repouso - ou seja, o Amazon Redshift criptografa opcionalmente seus dados à medida que os grava em seus datacenters e os descriptografa para você quando você os acessa. Contanto que você autentique sua solicitação e tenha permissões de acesso, não há diferença na forma de acesso aos dados criptografados ou não criptografados. O Amazon Redshift protege os dados em repouso por meio de criptografia. Opcionalmente, você pode proteger todos os dados armazenados em discos dentro de um cluster e todos os backups no Amazon S3 com Advanced Encryption Standard AES-256. Para gerenciar as chaves usadas para criptografar e descriptografar seus recursos do Amazon Redshift, use o [AWS Key Management Service (AWS KMS)](https://docs.aws.amazon.com/kms/latest/developerguide/). O AWS KMS combina hardware e software seguros e altamente disponíveis para fornecer um sistema de gerenciamento de chaves escalado para a nuvem. utilizando o AWS KMS, é possível criar chaves de criptografia e definir as políticas que controlam como elas podem ser usadas. O AWS KMS é compatível com o AWS CloudTrail, o que possibilita a auditoria do uso de chaves para verificar se elas estão sendo usadas adequadamente. Você pode usar suas chaves AWS KMS em combinação com o Amazon Redshift e serviços compatíveis da AWS. Para obter uma lista de serviços compatíveis com o AWS KMS, consulte [Como os serviços da AWS usam o AWS KMS](https://docs.aws.amazon.com/kms/latest/developerguide/services.html) no *Guia do desenvolvedor do AWS Key Management Service*. Se você optar por gerenciar o cluster provisionado ou a senha de administrador do namespace de tecnologia sem servidor usando AWS Secrets Manager, o Amazon Redshift também aceitará uma chave KMS da AWS usada pelo AWS Secrets Manager para criptografar as credenciais. Essa chave adicional pode ser uma chave gerada automaticamente pelo AWS Secrets Manager ou uma chave personalizada fornecida por você. O editor de consultas v2 do Amazon Redshift armazena com segurança as informações inseridas no editor de consultas da seguinte maneira: + O nome do recurso da Amazon (ARN) da chave KMS a ser usada para criptografar os dados do editor de consultas v2. + Informações da conexão do banco de dados. + Nomes e conteúdo de arquivos e pastas. O editor de consultas v2 do Amazon Redshift criptografa informações usando criptografia em nível de bloco com a chave KMS ou a chave KMS da conta de serviço. A criptografia dos dados do Amazon Redshift é controlada pelas propriedades do cluster do Amazon Redshift. **Topics** + [Criptografia de banco de dados do Amazon Redshift](working-with-db-encryption.md) # Criptografia de banco de dados do Amazon Redshift No Amazon Redshift, o banco de dados é criptografado por padrão para proteger os dados em repouso. A criptografia do banco de dados se aplica ao cluster e também aos snapshots. É possível modificar um cluster não criptografado para usar a criptografia do AWS Key Management Service (AWS KMS). Para fazer isso, você pode usar uma chave de propriedade da 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 obter mais informações, consulte [Alterar a criptografia do cluster](changing-cluster-encryption.md). Embora você ainda possa transformar o cluster criptografado padrão em não criptografado após criá-lo, recomendamos manter o cluster que contém dados confidenciais criptografado. 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. **Importante** O Amazon Redshift pode perder o acesso à chave do KMS para um cluster provisionado ou um namespace sem servidor quando você desabilita a chave do KMS gerenciada pelo cliente. Nesses casos, o Amazon Redshift faz um backup do armazém de dados do Amazon Redshift e o coloca em um estado `inaccessible-kms-key` por 14 dias. Se você restaurar a chave KMS dentro desse período, o Amazon Redshift restaurará o acesso e o armazém funcionará normalmente. Se o período de 14 dias terminar sem que a chave KMS seja restaurada, o Amazon Redshift excluirá o data warehouse. Enquanto um armazém está no estado `inaccessible-kms-key`, ele tem as seguintes características: Você não pode executar nenhuma consulta no data warehouse. Se o data warehouse for o armazém produtor de uma unidade de compartilhamento de dados, você não poderá executar consultas de compartilhamento de dados nele a partir de armazéns de consumidores. Você não pode criar cópias instantâneas entre regiões. Para obter informações sobre como restaurar uma chave KMS desativada, consulte [Ativar e desativar chaves](https://docs.aws.amazon.com/kms/latest/developerguide/enabling-keys.html) no Guia do desenvolvedor do AWS Key Management Service**. Se a chave KMS do armazém tiver sido excluída, você poderá usar o backup para criar um novo data warehouse antes que o armazém do status `inaccessible-kms-key` seja excluído. ## 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](https://docs.aws.amazon.com/redshift/latest/dg/r_CREATE_TABLE_NEW.html) ou [CRIAR VISÃO MATERIALIZADA](https://docs.aws.amazon.com/redshift/latest/dg/materialized-view-create-sql-command.html). **Topics** + [Melhorias no processo de criptografia para aumentar a performance e a disponibilidade](#resize-classic-encryption) + [Criptografia por meio do AWS KMS](#working-with-aws-kms) + [Criptografia por meio de módulos de segurança de hardware](#working-with-HSM) + [Alternância de chaves de criptografia](#working-with-key-rotation) + [Alterar a criptografia do cluster](changing-cluster-encryption.md) + [Migrar para um cluster criptografado por HSM](migrating-to-an-encrypted-cluster.md) + [Alternar chaves de criptografia](manage-key-rotation-console.md) ## 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 o cluster, o Amazon Redshift retorna uma lista das AWS KMS keys que o Amazon Redshift ou 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 uma chave de propriedade da AWS gerada automaticamente como chave raiz para sua conta da AWS usar no Amazon Redshift. 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](https://docs.aws.amazon.com/kms/latest/developerguide/create-keys.html) 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](https://docs.aws.amazon.com/kms/latest/developerguide/control-access.html) 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](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html) 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](create-cluster.md). ### Copiar snapshots criptografados pelo AWS KMS para outra Região da AWS As chaves do AWS KMS são específicas para uma Região da AWS. Se quiser habilitar a cópia de snapshots do Amazon Redshift com base em um cluster de origem criptografado para outra Região da AWS, mas quiser usar sua própria chave do AWS KMS para snapshots no destino, você deverá configurar uma concessão para o Amazon Redshift usar uma chave raiz em sua conta na Região da AWS de destino. Essa concessão permite que o Amazon Redshift criptografe snapshots na Região da AWS de destino. Se você quiser que os snapshots no destino sejam criptografados por uma chave de propriedade da Região da AWS, não será necessário configurar nenhuma concessão 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](cross-region-snapshot-copy.md). **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. 1. 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](https://docs.aws.amazon.com/kms/latest/developerguide/create-keys.html) 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. 1. 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](xregioncopy-kms-encrypted-snapshot.md). 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. AWS CloudHSMO Classic está fechado para novos clientes. Para obter mais informações, consulte [Preço do CloudHSM Classic](https://aws.amazon.com/cloudhsm/pricing-classic/).AWS CloudHSM O Classic não está disponível em todas as regiões da AWS. Para obter mais informações sobre as regiões da AWS disponíveis, consulte a [Tabela de regiões da AWS](https://aws.amazon.com/about-aws/global-infrastructure/regional-product-services/). 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\$1HSM, 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](https://docs.aws.amazon.com/cloudhsm/latest/userguide/cli-clone-hapg.html). 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](https://docs.aws.amazon.com/redshift/latest/mgmt/working-with-event-notifications.html). ## 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\$1KEYS 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](manage-key-rotation-console.md). # Alterar a criptografia do cluster É possível modificar um cluster não criptografado para usar a criptografia do AWS Key Management Service (AWS KMS) usando uma chave de propriedade da 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. Você também pode migrar um cluster criptografado para um cluster não criptografado, modificando o cluster com a AWS CLI, mas não com o Console de gerenciamento da AWS. Durante a operação de migração, o cluster fica disponível em modo de somente leitura e o status do cluster é exibido como **resizing (redimensionando)**. Se o seu cluster estiver configurado para habilitar a cópia de snapshot entre regiões da AWS, você deve desabilitá-lo antes de alterar a criptografia. Para obter mais informações, consulte [Copiar um snapshot em outra região da AWS](cross-region-snapshot-copy.md) e [Configurar a cópia de snapshots entre regiões para um cluster criptografado pelo AWS KMS](xregioncopy-kms-encrypted-snapshot.md). Você não pode habilitar a criptografia do módulo de segurança de hardware (HSM) modificando o cluster. Em vez disso, crie um cluster criptografado por HSM e migre seus dados para esse cluster. Para obter mais informações, consulte [Migrar para um cluster criptografado por HSM](migrating-to-an-encrypted-cluster.md). ------ #### [ Amazon Redshift console ] 1. Faça login no Console de gerenciamento da AWS e abra o console do Amazon Redshift em [https://console.aws.amazon.com/redshiftv2/](https://console.aws.amazon.com/redshiftv2/). 1. No menu de navegação, escolha **Clusters**, depois selecione o cluster para o qual você deseja modificar a criptografia. 1. Escolha **Properties**. 1. Na seção **Configurações do banco de dados**, escolha **Editar** e, depois, escolha **Editar criptografia**. 1. Escolha uma das opções de criptografia e escolha **Salvar alterações**. ------ #### [ AWS CLI ] Para modificar o cluster não criptografado para usar o AWS KMS, execute o comando `modify-cluster` da CLI e especifique `–-encrypted`, como mostrado a seguir. Por padrão, a chave do KMS padrão é usada. Para especificar uma chave gerenciada pelo cliente, inclua a opção `--kms-key-id`. ``` aws redshift modify-cluster --cluster-identifier --encrypted --kms-key-id ``` Para remover a criptografia do cluster, execute o seguinte comando da CLI. ``` aws redshift modify-cluster --cluster-identifier --no-encrypted ``` ------ # Migrar para um cluster criptografado por HSM Para migrar um cluster não criptografado para um cluster criptografado usando um módulo de segurança de hardware (HSM), crie um cluster criptografado e mova os dados para esse cluster. Não é possível migrar para um cluster criptografado por HSM modificando o cluster. Para migrar de um cluster não criptografado para um cluster criptografado por HSM, descarregue os dados do seu cluster de origem existente. Em seguida, recarregue os dados em um novo cluster de destino com a configuração de criptografia escolhida. Para obter mais informações sobre como executar um cluster criptografado, consulte [Criptografia de banco de dados do Amazon Redshift](working-with-db-encryption.md). Durante o processo de migração, seu cluster de origem ficará disponível somente para consultas de leitura até a última etapa. A última etapa é renomear os clusters de origem e de destino, o que modifica os endpoints para que todo o tráfego seja roteado para o novo cluster de destino. Quando você renomear o cluster de destino, ele ficará disponível somente após a reinicialização. Suspenda todas as cargas de dados e outras operações de gravação no cluster de origem enquanto os dados estiverem sendo transferidos. **Preparo para a migração** 1. Identifique todos os sistemas dependentes que interagem com o Amazon Redshift, por exemplo, ferramentas de business intelligence (BI) e sistemas de extrair, transformar e carregar (ETL). 1. Identifique as consultas de validação para testar a migração. Por exemplo, você pode usar a seguinte consulta para localizar o número de tabelas definidas pelo usuário. ``` select count(*) from pg_table_def where schemaname != 'pg_catalog'; ``` A consulta a seguir retorna uma lista de todas as tabelas definidas pelo usuário e o número de linhas em cada tabela. ``` select "table", tbl_rows from svv_table_info; ``` 1. Escolha o momento adequado para a sua migração. Para saber o horário em que o uso do cluster é mais baixo, monitore as métricas do cluster, como a utilização da CPU e o número de conexões do banco de dados. Para obter mais informações, consulte [Visualizar dados de performance do cluster](performance-metrics-perf.md). 1. Remova tabelas não utilizadas. Para criar uma lista das tabelas e o número de vezes que cada tabela foi consultada, execute a seguinte consulta. ``` select database, schema, table_id, "table", round(size::float/(1024*1024)::float,2) as size, sortkey1, nvl(s.num_qs,0) num_qs from svv_table_info t left join (select tbl, perm_table_name, count(distinct query) num_qs from stl_scan s where s.userid > 1 and s.perm_table_name not in ('Internal worktable','S3') group by tbl, perm_table_name) s on s.tbl = t.table_id where t."schema" not in ('pg_internal'); ``` 1. Execute um novo cluster criptografado. Use o mesmo número de porta para o cluster de destino e o cluster de origem. Para obter mais informações sobre como executar um cluster criptografado, consulte [Criptografia de banco de dados do Amazon Redshift](working-with-db-encryption.md). 1. Configure o processo de descarregamento e o carregamento. Você pode usar o [Utilitário de descarregamento/cópia do Amazon Redshift](https://github.com/awslabs/amazon-redshift-utils/tree/master/src/UnloadCopyUtility) para lhe ajudar na migração de dados entre clusters. O utilitário exporta dados do cluster de origem para um local no Amazon S3. Os dados são criptografados com o AWS KMS. Em seguida, o utilitário importa automaticamente os dados para o destino. Opcionalmente, você pode usar o utilitário para limpar o Amazon S3 após a conclusão da migração. 1. Execute um teste para verificar seu processo e estime por quanto tempo as operações de gravação precisam ser suspensas. Durante as operações de descarregamento e carregamento, mantenha a consistência dos dados suspendendo os carregamentos deles e outras operações de gravação. Usando uma das suas maiores tabelas, execute o processo de descarregamento e carregamento para ajudar você a estimar o tempo. 1. Crie objetos de banco de dados, como esquemas, visualizações e tabelas. Para ajudá-lo a gerar as instruções de linguagem de definição de dados (DDL) necessárias, você pode usar os scripts em [AdminViews](https://github.com/awslabs/amazon-redshift-utils/tree/master/src/AdminViews) no repositório GitHub da AWS. **Para migrar o cluster** 1. Encerre todos os processos ETL no cluster de origem. Para confirmar que não há operações de gravação em andamento, use o Console de gerenciamento do Amazon Redshift para monitorar IOPS de gravação. Para obter mais informações, consulte [Visualizar dados de performance do cluster](performance-metrics-perf.md). 1. Execute as consultas de validação identificadas anteriormente para coletar informações sobre o cluster de origem não criptografado antes da migração. 1. (Opcional) Crie uma fila de gerenciamento de workload (WLM) para usar o máximo de recursos disponíveis nos clusters de origem e de destino. Por exemplo, crie uma fila chamada `data_migrate` e configure a fila com memória de 95% e simultaneidade de 4%. Para obter mais informações, consulte [Roteamento de consultas para filas baseadas em grupos de usuários e grupos de consultas](https://docs.aws.amazon.com/redshift/latest/dg/tutorial-wlm-routing-queries-to-queues.html) no *Guia do desenvolvedor de banco de dados do Amazon Redshift*. 1. Usando a fila `data_migrate`, execute UnloadCopyUtility. Monitore o processo de UNLOAD e COPY usando o console do Amazon Redshift. 1. Execute as consultas de validação novamente e verifique se os resultados correspondem aos resultados do cluster de origem. 1. Renomeie seus clusters de origem e destino para trocar os endpoints. Para evitar interrupções, execute esta operação fora do horário comercial. 1. Verifique se é possível se conectar ao cluster de destino usando todos os seus clientes SQL, como o ETL e as ferramentas de relatórios. 1. Desligue o cluster de origem não criptografado. # Alternar chaves de criptografia Você pode usar o procedimento a seguir para alternar as chaves de criptografia usando o console do Amazon Redshift. **Para alternar as chaves de criptografia de um cluster** 1. Faça login no Console de gerenciamento da AWS e abra o console do Amazon Redshift em [https://console.aws.amazon.com/redshiftv2/](https://console.aws.amazon.com/redshiftv2/). 1. No menu de navegação, escolha **Clusters**, depois selecione o cluster para o qual você deseja atualizar as chaves de criptografia. 1. Em **Actions (Ações)**, escolha **Rotate encryption (Alternar criptografia)** para exibir a página **Rotate encryption keys (Alternar chaves de criptografia)**. 1. Na página **Rotate encryption keys (Alternar chaves de criptografia)**, escolha **Rotate encryption keys (Alternar chaves de criptografia)**. # Criptografia em trânsito Você pode configurar seu ambiente para proteger a confidencialidade e integridade de dados em trânsito. Os detalhes a seguir aplicam-se à criptografia de dados em trânsito entre um cluster Amazon Redshift e clientes SQL sobre JDBC/ODBC: + Você pode se conectar a clusters do Amazon Redshift a partir de ferramentas de cliente SQL em conexões Java Database Connectivity (JDBC) e Open Database Connectivity (ODBC). + O Amazon Redshift oferece suporte a conexões Secure Sockets Layer (SSL) para criptografar dados e certificados do servidor para validar o certificado do servidor ao qual o cliente se conecta. O cliente se conecta ao nó líder de um cluster do Amazon Redshift. Para obter mais informações, consulte [Configurar as opções de segurança para conexões](connecting-ssl-support.md). + Para oferecer suporte a conexões SSL, o Amazon Redshift cria e instala certificados AWS Certificate Manager (ACM) emitidos em cada cluster. Para obter mais informações, consulte [Transição para certificados ACM das conexões SSL](connecting-transitioning-to-acm-certs.md). + Para proteger seus dados em trânsito na Nuvem AWS, o Amazon Redshift usa SSL acelerado por hardware para se comunicar com o Amazon S3 ou Amazon DynamoDB para operações de COPY, UNLOAD, backup e restauração. Os detalhes a seguir aplicam-se à criptografia de dados em trânsito entre um cluster do Amazon Redshift e o Amazon S3 ou o DynamoDB: + O Amazon Redshift usa SSL acelerado por hardware para se comunicar com o Amazon S3 ou DynamoDB para operações de COPY, UNLOAD, backup e restauração. + O Redshift Spectrum oferece suporte à criptografia no lado do servidor (SSE) do Amazon S3 usando a chave padrão da conta gerenciada pelo AWS Key Management Service (KMS). + Você pode criptografar o Amazon Redshift com o Amazon S3 e o AWS KMS. Para obter mais informações, consulte [Criptografar seus carregamentos do Amazon Redshift com o Amazon S3 e o AWS KMS](https://aws.amazon.com/blogs/big-data/encrypt-your-amazon-redshift-loads-with-amazon-s3-and-aws-kms/). Os detalhes a seguir aplicam-se à criptografia e assinatura de dados em trânsito entre clientes AWS CLI, SDK ou API e endpoints do Amazon Redshift: + O Amazon Redshift fornece endpoints HTTPS para criptografar dados em trânsito. + Para proteger a integridade das solicitações de API para o Amazon Redshift, as chamadas de API devem ser assinadas pelo autor da chamada. As chamadas são assinadas por um certificado X.509 ou pela chave de acesso secreta AWS de acordo com o Processo de assinatura do Signature versão 4 (Sigv4). Para obter mais informações, consulte [Processo de assinatura do Signature versão 4](https://docs.aws.amazon.com/general/latest/gr/signature-version-4.html) na *Referência geral da AWS.* + Use a AWS CLI ou um dos AWS SDKs para fazer solicitações à AWS. Essas ferramentas autenticam automaticamente as solicitações para você com a chave de acesso especificada na configuração das ferramentas. Os detalhes a seguir aplicam-se à criptografia de dados em trânsito entre clusters do Amazon Redshift e o editor de consultas v2 do Amazon Redshift + Os dados são transmitidos entre os clusters do editor de consultas v2 do Amazon Redshift em um canal criptografado com TLS. # Controles de criptografia de VPC com o Amazon Redshift O Amazon Redshift comporta os [controles de criptografia de VPC](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-encryption-controls.html), um recurso de segurança que ajuda você a aplicar a criptografia em trânsito a todo o tráfego dentro e entre VPCs em uma região. Este documento descreve como usar os controles de criptografia de VPC com clusters e grupos de trabalho sem servidor do Amazon Redshift. Os controles de criptografia de VPC fornecem controle centralizado para monitorar e aplicar a criptografia em trânsito em suas VPCs. Quando habilitado no modo de imposição, ele garante que todo o tráfego da rede seja criptografado na camada de hardware (usando o AWS Nitro System) ou na camada de aplicação (usando TLS/SSL). O Amazon Redshift se integra aos controles de criptografia de VPC para ajudar você a atender aos requisitos de conformidade de setores, como saúde (HIPAA), governo (FedRAMP) e financeiro (PCI DSS). ## Como controles de criptografia de VPC funcionam com o Amazon Redshift Os controles de criptografia de VPC operam em dois modos: + Modo de monitor: fornece visibilidade do status de criptografia dos fluxos de tráfego e ajuda a identificar recursos que permitem tráfego não criptografado. + Modo de imposição: impede a criação ou o uso de recursos que permitem tráfego não criptografado dentro da VPC. Todo o tráfego deve ser criptografado na camada de hardware (instâncias baseadas em Nitro) ou na camada de aplicação (TLS/SSL). ## Requisitos para usar controles de criptografia de VPC **Requisitos do tipo de Instância** O Amazon Redshift exige instâncias baseadas em Nitro para comportar os controles de criptografia de VPC. Todos os tipos modernos de instância do Redshift comportam os recursos de criptografia necessários. **Requisitos de SSL/TLS** Quando os controles de criptografia de VPC estão habilitados no modo de imposição, o parâmetro require\$1ssl deve ser definido como true e não pode ser desabilitado. Isso garante que todas as conexões do cliente usem conexões TLS criptografadas. ## Migração para controles de criptografia de VPC **Para clusters e grupos de trabalho existentes** Você não pode habilitar os controles de criptografia de VPC no modo de imposição em uma VPC que contém clusters ou grupos de trabalho sem servidor existentes do Redshift. Consulte as seguintes etapas para usar controles de criptografia se você tiver um cluster ou um grupo de trabalho existente: 1. Crie um snapshot do seu cluster ou namespace existente. 1. Crie uma VPC com os controles de criptografia de VPC habilitados no modo de imposição. 1. Restaure do snapshot para a nova VPC usando uma das seguintes operações: + Para clusters provisionados: use a operação `restore-from-cluster-snapshot`. + Para tecnologia sem servidor: use a operação `restore-from-snapshot` em seu grupo de trabalho. **Ao criar clusters ou grupos de trabalho em uma VPC com controles de criptografia habilitados, o parâmetro require\$1ssl deve ser definido como true.** O Amazon Redshift exige instâncias baseadas em Nitro para comportar os controles de criptografia de VPC. Todos os tipos modernos de instância do Redshift comportam os recursos de criptografia necessários. **Requisitos de SSL/TLS** Quando os controles de criptografia de VPC estão habilitados no modo de imposição, o parâmetro require\$1ssl deve ser definido como true e não pode ser desabilitado. Isso garante que todas as conexões do cliente usem conexões TLS criptografadas. ## Considerações e limitações Ao usar controles de criptografia de VPC no Amazon Redshift, pense no seguinte: **Restrições de estado da VPC** + A criação de clusters e grupos de trabalho fica bloqueada quando os controles de criptografia de VPC estão no estado `enforce-in-progress`. + Você deve esperar até a VPC chegar ao modo `enforce` antes de criar recursos. **Configuração do SSL** + Parâmetro require\$1ssl: sempre deve ser `true` para clusters e grupos de trabalho criados em VPCs com criptografia aplicada. + Depois que um cluster ou grupo de trabalho é criado em uma VPC com criptografia aplicada, não é possível desativar `require_ssl` por toda a vida útil. **Disponibilidade de regiões** Esse recurso não está disponível no modo de imposição com o Amazon Redshift sem servidor nas seguintes regiões: + América do Sul (São Paulo) + Europa (Zurique) # Gerenciamento de chaves É possível configurar o ambiente para proteger os dados com chaves: + O Amazon Redshift se integra automaticamente com o AWS Key Management Service (AWS KMS) para gerenciamento de chaves. O AWS KMS usa criptografia de envelope. Para obter mais informações, consulte [Criptografia de envelope](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#enveloping). + Quando as chaves de criptografia são gerenciadas no AWS KMS, o Amazon Redshift usa uma arquitetura baseada em chave de quatro camadas para criptografia. A arquitetura consiste em chaves de criptografia dos dados AES-256 geradas aleatoriamente, uma chave de banco de dados, uma chave de cluster e uma chave raiz. Para obter mais informações, consulte [Como o Amazon Redshift usa o AWS KMS](https://docs.aws.amazon.com/kms/latest/developerguide/services-redshift.html). + É possível criar sua própria chave gerenciada pelo cliente no AWS KMS. Para obter mais informações, consulte [Criação de chaves](https://docs.aws.amazon.com/kms/latest/developerguide/create-keys.html). + Você também pode importar seu próprio material de chaves para novas AWS KMS keys. Para obter mais informações, consulte [Importando material chave no AWS Key Management Service (AWS KMS)](https://docs.aws.amazon.com/kms/latest/developerguide/importing-keys.html). + O Amazon Redshift oferece suporte ao gerenciamento de chaves de criptografia em módulos de segurança de hardware externos (HSMs). O HSM pode ser on-premises ou pode ser AWS CloudHSM. 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. O Amazon Redshift oferece suporte apenas para AWS CloudHSM Classic para gerenciamento de chaves. Para obter mais informações, consulte [Criptografia por meio de módulos de segurança de hardware](working-with-db-encryption.md#working-with-HSM). Para obter informações sobre o AWS CloudHSM, consulte [O que é o AWS CloudHSM?](https://docs.aws.amazon.com/cloudhsm/latest/userguide/introduction.html) + Você pode alternar chaves de criptografia para clusters criptografados. Para obter mais informações, consulte [Alternância de chaves de criptografia](working-with-db-encryption.md#working-with-key-rotation).