O Looker usa criptografia no modo Galois/Contador AES-256 (GCM, na sigla em inglês) para criptografar dados sensíveis armazenados internamente, incluindo:
- Backups do banco de dados interno do Looker
- Informações de conexão de banco de dados e serviço
- Informações de autenticação do usuário
- Valores de atributo do usuário
- Dados do cliente armazenados em cache ou preparados para envio
Para ver uma lista detalhada dos dados criptografados pelo Looker, abra uma solicitação de suporte.
Os dados são criptografados com uma chave de dados exclusiva e contêm um envelope de criptografia assinado e com controle de versões para garantir a verificação. Esse modo exige o uso de uma chave mestra do cliente (CMK) externa. A CMK é usada para derivar, criptografar e descriptografar a chave de criptografia de chaves (KEK), que, por sua vez, é usada para derivar, criptografar e descriptografar as chaves de dados.
A criptografia é usada apenas para o banco de dados e o cache interno do Looker. Os bancos de dados do cliente não são afetados pela criptografia do Looker. Além disso, somente 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 sistemas de gerenciamento de chaves personalizados. Todas as chaves de dados e a KEK são criptografadas e usadas internamente na instalação do Looker hospedada pelo cliente. Se você não estiver usando o AWS KMS, a CMK externa deverá ser mantida em segurança.
As instalações hospedadas pelo cliente e que quiserem usar a criptografia do GCM precisam migrar da criptografia legada para a nova criptografia do GCM. Novas instalações hospedadas pelo cliente exigem configuração adicional para a criptografia do GCM.
Siga os procedimentos nas seções a seguir.
Como interromper o Looker e criar um backup completo
Se você estiver migrando para a criptografia do GCM de uma instância atual do Looker, crie um backup completo caso haja um problema com a migração. 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 de aplicativos do 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 isso deve levar apenas alguns minutos. Em seguida, pare 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 posteriormente, ele vai falhar com a mensagem "Há outros nós ativos conectados a este banco de dados de 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 foram encerrados."
Como gerar uma CMK
Se você estiver usando o AWS KMS, crie uma CMK usando o Console de Gerenciamento da AWS ou a API.
Se você não estiver usando o AWS KMS, gere uma CMK de 32 bytes em Base64. É possível armazenar a CMK em uma variável de ambiente ou em um arquivo.
Para gerar e armazenar o CMK em uma variável de ambiente, use o comando abaixo:
openssl rand -base64 32Depois de gerar a CMK, copie-a e use o seguinte comando para armazená-la na variável de ambiente
LKR_MASTER_KEY_ENV(em que<CMK_value>é a CMK gerada 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 o CMK em um arquivo, use o comando a seguir (em que
<path_to_CMK_file>é o caminho e o nome do arquivo para armazenar o CMK):openssl rand -base64 32 > <path_to_key_file>
Depois de 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 uma CMK, armazene-a em um local seguro e permanente antes de continuar. A perda do CMK após a criptografia do banco de dados interno pode resultar na perda da sua instância.
Como criar um papel do IAM da AWS
Se você não estiver usando o KMS da AWS, pule esta seção.
Se você estiver usando o AWS KMS, o Looker recomenda criar uma nova função do IAM exclusiva para sua CMK e anexá-la à instância do Looker.
Confira a seguir um exemplo de função do IAM que contém as permissões mínimas necessárias para o 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 sua 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 configurar um contexto de criptografia personalizado da AWS. Se você não definir essa variável de ambiente, o Looker vai 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 a 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 sua 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 agrupado, execute o comando anterior em todos os nós do cluster.
Como criptografar o banco de dados interno
Se você estiver migrando uma instância atual 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
Se a instância do Looker começar 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 as credenciais do 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 vai começar quando ela for iniciada.
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 as soluções para esses erros:
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: falta o keystore de suporte: o Looker não encontra o CMK. Verifique se o caminho do CMK na variável de ambiente
LKR_MASTER_KEY_FILEestá correto.O Looker não pode iniciar porque: o tamanho da chave mestra é inválido, ela precisa ter 32 bytes, mas é X: o CMK precisa ter exatamente 32 bytes.
O Looker não pode ser iniciado porque: a permissão para o arquivo de chave de reserva
precisa ser 0400, mas é XXX : o arquivo CMK precisa ser somente leitura com um valorchmodde0400.