O Looker usa criptografia AES-256 Galois/Counter (GCM, na sigla em inglês) para criptografar dados confidenciais armazenados internamente, incluindo:
- Backups do banco de dados interno do Looker
- Informações sobre conexão de bancos de dados e serviços
- Informações de autenticação do usuário
- Valores do atributo do usuário
- Dados do cliente que são armazenados em cache ou preparados para entrega
Para uma lista detalhada dos dados que o Looker criptografa, entre em contato com seu gerente de contas ou abra uma solicitação de suporte na Central de Ajuda do Looker clicando em Fale conosco.
Os dados são criptografados usando uma chave de dados exclusiva e contêm um envelope de criptografia assinado e com controle de versão para garantir a verificação. Esse modo requer o uso de uma chave mestra externa do cliente (CMK, na sigla em inglês). O CMK é usado para gerar, criptografar e descriptografar a chave de criptografia de chaves (KEK, na sigla em inglês), que, por sua vez, é usada para derivar, criptografar e descriptografar chaves de dados.
A criptografia é usada apenas para o banco de dados e o cache internos do Looker. Os bancos de dados do cliente não são afetados pela criptografia do Looker. Além disso, somente os dados estáticos (dados armazenados em disco) são criptografados dessa maneira.
As instalações hospedadas pelo cliente podem usar as próprias contas do AWS KMS ou os próprios sistemas personalizados de gerenciamento de chaves. Todas as chaves de dados e a KEK são criptografadas e usadas internamente na instalação do Looker hospedada pelo cliente. Se não estiver usando o AWS KMS, o CMK externo deverá ser mantido em segurança.
As instalações atuais hospedadas pelo cliente que quiserem usar a criptografia do GCM precisam migrar da criptografia legada para a nova do GCM. Novas instalações hospedadas pelo cliente exigem configurações adicionais para a criptografia do GCM.
Siga os procedimentos nas próximas seções na ordem.
Como interromper o Looker e criar um backup completo
Se você estiver migrando para a criptografia do GCM de uma instância existente do Looker, crie um backup completo caso haja um problema com a migração de criptografia. Se você estiver instalando uma nova instância do Looker, pule esta seção.
Se você estiver usando o banco de dados interno do Looker:
cd looker
./looker stop
tar -zcvf /tmp/looker-pre-encrypt.tar.gz /home/lookerops/looker --exclude=.cache --exclude=log --exclude=.tmp --exclude=.snapshots --exclude=looker.jar --exclude=authorized_keys --exclude=dr-log --exclude=core
Se você estiver executando um banco de dados MySQL externo para armazenar dados do aplicativo Looker, faça backup do banco de dados separadamente. Se o banco de dados for uma instância do MySQL, tire um snapshot. O banco de dados é relativamente pequeno, então leva apenas alguns minutos. Em seguida, interrompa o Looker.
Se o Looker estiver em cluster, interrompa todos os nós antes de continuar:
cd looker
./looker stop
Se algum nó ainda estiver em execução quando você emitir o comando de migração, a mensagem falhará: "quot;Existem outros nós ativos conectados a este banco de dados do back-end do Looker. Se o Looker foi encerrado no último minuto, tente novamente em breve. Caso contrário, verifique se todos os nós no cluster estão encerrados."
Como gerar um CMK
Se você usa o AWS KMS, crie um CMK usando o AWS Management Console ou a API.
Se você não estiver usando o AWS KMS, gere um CMK Base64 de 32 bytes. É possível armazenar o CMK em uma variável de ambiente ou em um arquivo.
Para gerar o CMK e armazená-lo em uma variável de ambiente, use o seguinte comando para gerar o CMK:
openssl rand -base64 32Depois de gerar o CMK, copie-o e use o seguinte comando para armazenar o CMK na variável de ambiente
LKR_MASTER_KEY_ENV(em que<CMK_value>é o CMK gerado com o comando anterior):export LKR_MASTER_KEY_ENV=<CMK_value>Se o Looker estiver em cluster, execute o comando anterior em cada nó do cluster.
Para gerar e armazenar a CMK em um arquivo, use o seguinte comando (em que
<path_to_CMK_file>é o caminho e o nome do arquivo para armazenar a CMK):openssl rand -base64 32 > <path_to_key_file>
Após gerar o arquivo CMK, defina as permissões do arquivo de chave como somente leitura para o usuário atual:
chmod 0400 <path_to_key_file>
Depois de gerar um CMK, armazene-o em um local seguro e permanente antes de continuar. Perder a CMK após criptografar o banco de dados interno pode resultar na perda da instância.
Como criar um papel do IAM da AWS
Se você não estiver usando o AWS KMS, pule esta seção.
Se você estiver usando o AWS KMS, o Looker recomenda que você crie um papel do IAM exclusivo para seu CMK e anexe-o à sua instância do Looker.
Veja a seguir um exemplo de papel do IAM que contém as permissões mínimas necessárias para seu CMK:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "VisualEditor0",
"Effect": "Allow",
"Action": "kms:GenerateRandom",
"Resource": "*"
},
{
"Sid": "VisualEditor1",
"Effect": "Allow",
"Action": [
"kms:Decrypt",
"kms:Encrypt",
"kms:Generate*",
],
"Resource": "arn:aws:kms:*:*:key/*"
}
]
}
Como definir variáveis de ambiente
Se você estiver usando o AWS KMS, defina a variável de ambiente AWS_REGION como a região da AWS e a variável de ambiente LKR_AWS_CMK como o alias do CMK:
export AWS_REGION=<AWS_region>
export LKR_AWS_CMK=alias/<CMK_alias>
Também é possível definir a variável de ambiente LKR_AWS_CMK_EC para definir um contexto de criptografia da AWS personalizado. Se você não definir essa variável de ambiente, o Looker usará o contexto de criptografia padrão, a string Looker_Encryption_Context.
export LKR_AWS_CMK_EC=<My_Encryption_Context>
Se você não estiver usando o AWS KMS e estiver armazenando seu CMK em um arquivo, defina a variável de ambiente LKR_MASTER_KEY_FILE como o caminho do arquivo CMK:
export LKR_MASTER_KEY_FILE=<path_to_key_file>
Se você não estiver usando o AWS KMS e estiver armazenando seu CMK em uma variável de ambiente, defina a variável de ambiente LKR_MASTER_KEY_ENV como o valor do CMK:
export LKR_MASTER_KEY_ENV=<CMK_value>
Se o Looker estiver em cluster, execute o comando anterior em cada nó do cluster.
Como criptografar o banco de dados interno
Se você estiver migrando uma instância do Looker para a criptografia do GCM, migre o banco de dados interno do Looker e inicie o Looker:
java -jar looker.jar migrate_encryption
./looker start
Caso sua instância do Looker comece com as opções de inicialização
-d <db.yaml>ou--internal-db-creds=<db.yaml>, que fornecem um caminho para um arquivo YAML com suas credenciais de banco de dados, será necessário incluir a mesma opção com o comandojava -jar looker.jar migrate_encryption.Por exemplo,
java -jar looker.jar migrate_encryption -d /path/file.
Se você estiver instalando uma nova instância do Looker, o processo de criptografia começará quando você iniciar a nova instância do Looker.
O processo de criptografia geralmente leva menos de um minuto. Depois que o Looker for iniciado, você poderá verificar a nova criptografia pesquisando GCM no registro do Looker:
grep GCM log/looker.log
2018-10-29 22:42:20.279 +0000 [INFO|007d0|crypt] :: Starting migration from AES-128-CBC Legacy to AES-GCM-256
2018-10-29 22:42:20.468 +0000 [INFO|007d0|db:looker] :: (0.000152s) INSERT INTO "SETTING" ("KEY", "VALUE") VALUES
Solução de problemas
Esta seção lista alguns erros comuns e suas soluções:
Não foi possível encontrar a tarefa "migrate_encryption": atualize sua instância do Looker para o Looker 6.4.
O Looker não pode ser iniciado porque: keystore de apoio ausente: o Looker não consegue encontrar o CMK. Verifique se o caminho do CMK na variável de ambiente
LKR_MASTER_KEY_FILEestá correto.O Looker não pode começar porque: o tamanho da chave mestra é inválido. Ele precisa ter 32 bytes, mas é X: o CMK precisa ter exatamente 32 bytes de comprimento.
O Looker não pode ser iniciado porque: a permissão para o arquivo de chave de backup
precisa ser 0400, mas é XXX : o arquivo CMK precisa ser somente leitura com um valorchmodde0400.