O Looker usa a criptografia AES-256 Galois/Counter Mode (GCM) para criptografar dados sensíveis armazenados internamente, incluindo:
- Backups do banco de dados interno do Looker
- Informações de conexão de serviço e banco de dados
- Informações de autenticação do usuário
- Valores de atributo do usuário
- Dados do cliente armazenados em cache ou preparados para exibição
Para uma lista detalhada dos dados criptografados pelo Looker, abra uma solicitação de suporte.
Os dados são criptografados com uma chave exclusiva e contêm um envelope de criptografia assinado e com controle de versão para garantir a verificação. Esse modo exige o uso de uma chave mestra do cliente (CMK, na sigla em inglês) 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 chaves de dados.
A criptografia é usada apenas para o cache e o banco de dados 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 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 você não estiver usando o AWS KMS, o CMK externo deverá ser mantido com segurança.
As instalações hospedadas pelo cliente que quiserem usar a criptografia do GCM precisam migrar da criptografia legada para a nova criptografia do GCM. As novas instalações hospedadas pelo cliente exigem configuração adicional para a criptografia do GCM.
Siga os procedimentos nas seções a seguir em ordem.
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 para o caso de haver um problema com a migração da 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 externo do MySQL para armazenar os dados do app 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 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, ele vai falhar e mostrar a mensagem "Há outros nós ativos conectados a este banco de dados de back-end do Looker. Se o Looker tiver sido encerrado no último minuto, tente de novo em breve. Caso contrário, verifique se todos os nós no cluster estão encerrados."
Como gerar um CMK
Se você estiver usando o AWS KMS, crie um CMK usando o console de gerenciamento da AWS ou a API.
Se você não estiver usando o AWS KMS, gere um CMK Base64 de 32 bytes. É possível armazenar a 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 armazená-lo 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 o CMK em um arquivo, use o seguinte comando, 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 do 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 o CMK após a criptografia do banco de dados interno pode resultar na perda da instância.
Como criar um papel do AWS IAM
Se você não estiver usando o AWS KMS, pule esta seção.
Se você estiver usando o AWS KMS, o Looker recomenda criar um papel do IAM exclusivo para o 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 sua região da AWS e a variável de ambiente LKR_AWS_CMK como o alias do seu 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 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 o 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 o 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 atual do Looker para a criptografia 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, você precisará 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, pesquise GCM no registro do Looker para verificar a nova criptografia:
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 respectivas 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: o keystore de apoio ausente: o Looker não consegue encontrar o CMK. Verifique se o caminho CMK na variável de ambiente
LKR_MASTER_KEY_FILEestá correto.O Looker não pode ser iniciado 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 apoio
precisa ser 0400, mas é XXX : o arquivo CMK precisa ser somente leitura com um valorchmodde0400.