O Looker usa a encriptação AES-256 no modo Galois/Counter (GCM) para encriptar dados confidenciais armazenados internamente, incluindo:
- Cópias de segurança da base de dados interna do Looker
- Informações de ligação de bases de dados e serviços
- Informações de autenticação do utilizador
- Valores de atributos do utilizador
- Dados de clientes em cache ou preparados para entrega
Para uma lista detalhada dos dados que o Looker encripta, abra um pedido de apoio técnico.
Os dados são encriptados através de uma chave de dados única e contêm um envelope de encriptação assinado e com controlo de versões para garantir a validação. Este modo requer a utilização de uma chave principal do cliente (CMK) externa. A CMK é usada para derivar, encriptar e desencriptar a chave de encriptação de chaves (KEK), que, por sua vez, é usada para derivar, encriptar e desencriptar chaves de dados.
A encriptação é usada apenas para a base de dados interna e a cache do Looker. As bases de dados de clientes não são afetadas pela encriptação do Looker de forma alguma. Além disso, apenas os dados estáticos (dados armazenados no disco) são encriptados desta forma.
As instalações alojadas pelo cliente podem usar as suas próprias contas do AWS KMS ou os seus próprios sistemas de gestão de chaves personalizados. Todas as chaves de dados e a KEK são encriptadas e usadas internamente na instalação do Looker alojada pelo cliente. Se não usar o AWS KMS, a CMK externa deve ser mantida em segurança.
As instalações alojadas pelo cliente existentes que queiram usar a encriptação GCM têm de migrar da encriptação antiga para a nova encriptação GCM. As novas instalações alojadas pelo cliente requerem uma configuração adicional para a encriptação GCM.
Siga os procedimentos nas secções seguintes por ordem.
Parar o Looker e criar uma cópia de segurança completa
Se estiver a migrar para a encriptação GCM a partir de uma instância do Looker existente, certifique-se de que cria uma cópia de segurança completa caso haja um problema com a migração da encriptação. Se estiver a instalar uma nova instância do Looker, ignore esta secção.
Se estiver a usar a base de dados interna 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 estiver a executar uma base de dados MySQL externa para armazenar dados da aplicação Looker, faça uma cópia de segurança da base de dados separadamente. Se a base de dados for uma instância do MySQL, tire um instantâneo. A base de dados é relativamente pequena, pelo que o processo deve demorar apenas alguns minutos. Em seguida, pare o Looker.
Se o Looker estiver agrupado, certifique-se de que para todos os nós antes de continuar:
cd looker
./looker stop
Se algum nó ainda estiver em execução quando emitir posteriormente o comando de migração, o comando falha com a mensagem "Existem outros nós ativos ligados a esta base 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 estão encerrados."
Gerar uma CMK
Se estiver a usar o AWS KMS, crie uma CMK através da AWS Management Console ou da API.
Se não estiver a usar o AWS KMS, gere uma CMK de 32 bytes em Base64. Pode armazenar a CMK numa variável de ambiente ou num ficheiro.
Para gerar a CMK e armazená-la numa variável de ambiente, pode usar o seguinte comando para gerar a CMK:
openssl rand -base64 32
Depois de gerar a CMK, copie-a e use o seguinte comando para armazenar a CMK na variável de ambiente
LKR_MASTER_KEY_ENV
(em que<CMK_value>
é a CMK que gerou 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 a CMK num ficheiro, pode usar o seguinte comando (em que
<path_to_CMK_file>
é o caminho e o nome do ficheiro para armazenar a CMK):openssl rand -base64 32 > <path_to_key_file>
Depois de gerar o ficheiro CMK, defina as autorizações do ficheiro de chave como só de leitura para o utilizador atual:
chmod 0400 <path_to_key_file>
Depois de gerar uma CMK, certifique-se de que a armazena num local seguro e permanente antes de continuar! A perda da CMK após a encriptação da base de dados interna pode resultar na perda da sua instância.
Criar uma função de IAM do AWS
Se não estiver a usar o AWS KMS, ignore esta secção.
Se estiver a usar o AWS KMS, o Looker recomenda que crie uma nova função da IAM exclusiva para a sua CMK e a associe à sua instância do Looker.
Segue-se um exemplo de uma função do IAM que contém as autorizações mínimas necessárias para a 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/*"
}
]
}
Definir variáveis de ambiente
Se estiver a usar o AWS KMS, defina a variável de ambiente AWS_REGION
para a sua região da AWS e a variável de ambiente LKR_AWS_CMK
para o alias da sua CMK:
export AWS_REGION=<AWS_region>
export LKR_AWS_CMK=alias/<CMK_alias>
Opcionalmente, também pode definir a variável de ambiente LKR_AWS_CMK_EC
para definir um contexto de encriptação da AWS personalizado. Se não definir esta variável de ambiente, o Looker usa o contexto de encriptação predefinido, a string Looker_Encryption_Context
.
export LKR_AWS_CMK_EC=<My_Encryption_Context>
Se não estiver a usar o AWS KMS e estiver a armazenar a CMK num ficheiro, defina a variável de ambiente LKR_MASTER_KEY_FILE
para o caminho do ficheiro CMK:
export LKR_MASTER_KEY_FILE=<path_to_key_file>
Se não estiver a usar o AWS KMS e estiver a armazenar a CMK numa variável de ambiente, defina a variável de ambiente LKR_MASTER_KEY_ENV
para o valor da CMK:
export LKR_MASTER_KEY_ENV=<CMK_value>
Se o Looker estiver agrupado, execute o comando anterior em todos os nós do cluster.
Encriptação da base de dados interna
Se estiver a migrar uma instância do Looker existente para a encriptação GCM, migre a base de dados interna do Looker e inicie o Looker:
java -jar looker.jar migrate_encryption
./looker start
Se a sua instância do Looker começar com a
-d <db.yaml>
ou as--internal-db-creds=<db.yaml>
opções de arranque, que fornecem um caminho para um ficheiro YAML com as suas credenciais da base de dados, tem de 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 estiver a instalar uma nova instância do Looker, o processo de encriptação começa quando iniciar a nova instância do Looker.
Normalmente, o processo de encriptação demora menos de um minuto. Assim que o Looker for iniciado, pode validar a nova encriptação pesquisando GCM
no registo 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
Resolução de problemas
Esta secção apresenta alguns erros comuns e as respetivas resoluções:
Não foi possível encontrar a tarefa "migrate_encryption": atualize a sua instância do Looker para o Looker 6.4.
Não é possível iniciar o Looker porque: Missing backing keystore: o Looker não consegue encontrar a CMK. Verifique se o caminho da CMK na variável de ambiente
LKR_MASTER_KEY_FILE
está correto.O Looker não pode ser iniciado porque: o tamanho da chave principal é inválido. Tem de ter 32 bytes, mas tem X: o CMK tem de ter exatamente 32 bytes de comprimento.
Não é possível iniciar o Looker porque: a autorização para o ficheiro de chave de apoio
tem de ser 0400, mas é XXX : o ficheiro CMK tem de ser só de leitura com um valorchmod
de0400
.