O Looker usa a criptografia AES-256 Galois/modo contador (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 atributos do usuário
- Dados do cliente armazenados em cache ou preparados para envio
Para conferir uma lista detalhada dos dados que o Looker criptografa, 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 requer 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 banco de dados e o cache interno do Looker. Os bancos de dados dos clientes não são afetados pela criptografia do Looker. Além disso, apenas dados estáticos (armazenados no 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 precisa ser mantida com segurança.
As instalações hospedadas pelo cliente que querem usar a criptografia do GCM precisam migrar da criptografia legada para a nova 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 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 com a mensagem "Há outros nós ativos conectados a este banco de dados do Looker de back-end. 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 um CMK Base64 de 32 bytes. É 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 comando a seguir 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 agrupado, execute o comando anterior em todos os nós 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 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 AWS IAM
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 um novo papel do IAM exclusivo para seu CMK e anexá-lo à 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 sua 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 da sua CMK:
export AWS_REGION=<AWS_region>
export LKR_AWS_CMK=alias/<CMK_alias>
Como alternativa, 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 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 a CMK em uma variável de ambiente, defina a variável de ambiente LKR_MASTER_KEY_ENV como o valor da 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 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 iniciar porque falta um keystore de backup: 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 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 iniciar 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.