>> Apresentação e considerações

Fala “Churropeiros”!

Como temos muito trabalho para apresentação do nosso meetup, daremos início na trilha por aqui.

Como assim?

Isso mesmo, estamos fazendo diferente da grande maioria, vamos iniciar a trilha falando do Vault, para quando chegarmos no dia da apresentação, já iniciaremos a parte técnica com o Vault configurado pronto para auxiliar (autenticar) na AWS.

O ambiente para reprodução dessa trilha será muito simples, o ambiente foi construído em Containers Docker e a orquestração através do Ansible.

Basta baixar o projeto e seguir os passos para levantar o seu ambiente.

Obs: Caso não possua uma conta na AWS, baixe o projeto e suba no seu próprio ambiente local. Na dúvida, basta enviar um comentário que auxiliaremos com a configuração.

Rumbora!?

>> Vault – O que é?, nunca vi e nem sei o que faz!

O Vault nada mais é que uma ferramenta para acessar de forma segura os "secrets".

O Vault foi escrito em Go (linguagem criada pelo Google) e distribuído em um único binário, tornando ótimo para os diversos ambientes e sistemas operacionais.

Uma vez que você baixa o binário, você pode executar os comandos imediatamente ou até mesmo já iniciá-lo como um client/server.

A inicialização produz duas partes de informação incrivelmente importantes: as chaves unseal e o token de raiz inicial.

Durante inicialização (vault init) as chaves de criptografia serão geradas (chaves unseal e o token de root inicial). Após a inicialização teremos um total de 5 chaves mais um token root.

É necessário que guarde todas essas chaves em um local seguro, o ideal é que você distribua de forma segura. Quando o Vault é resselado (“sealed“), reiniciado, ou parado, você deverá fornecer pelo menos 3 chaves para que ele volte ao estado (“desselado“) unseal.

Esta é a única vez que todos esses dados são conhecidos pelo Vault, e também a única vez que as chaves devem estar tão “próximas”.

Obs: Em um cenário de produção é extremamente importante que você não salve essas chaves juntas.

>> Secret

Um secret pode ser qualquer coisa que você deseja controlar o acesso, como chaves, API's, senhas, certificados e etc.

O Vault fornece uma interface unificada para qualquer secret, proporcionando um controle de acesso totalmente seguro e com um registro de auditoria bem detalhado.

E onde posso colocar o Vault?

Em sistemas modernos ou até mesmo na gestão de ambientes em Cloud, existe uma infinidade de secret’s que precisam ser armazenados, exemplo: (Banco de Dados – Chaves de API’s – Consoles de Cloud Computing – Serviços SaaS – Arquiteturas orientadas a serviços e muito mais …). É ai que entra o Vault, pois com ele podemos armazenar seguramente todos os secret’s e logs de auditoria.

Para o propósito deste guia inicial, guarde todas essas chaves em algum lugar e continue. Em um cenário de implantação real, você nunca salvaria essas chaves juntas. Em vez disso, você provavelmente usaria PGP e Keybase.io do Vault para criptografar cada uma dessas chaves com as chaves PGP dos usuários. Isso evita que uma única pessoa tenha todas as chaves não liberadas. Consulte a documentação sobre PGP, GPG e Keybase para obter mais informações.

O processo unseal é totalmente stateful, possibilitando que através de outro computador com o Vault instalado, possa executar o processo de desbloqueio (unseal), isso quanto o Vault estiver direcionado para o mesmo Vault Server.

Isso é extremamente importante para o processo de unseal. Somente assim, 2 ou mais pessoas poderão liberar o cofre. O Vault pode ser desmarcado de vários computadores e as chaves nunca deverão estarem juntas. Desta forma, um único operador não possuirá chaves suficientes para ser mal-intencionado. Uma vez que o ambiente esteja unseal, o passo seguinte será o vault auth que terá como função autenticar-se no Vault com o token root. Com o token root, será possível fechar o Vault (Único operador que poderá fazer isso). Isso permite que um único operador bloqueie o Vault em uma emergência sem consultar os demais operadores. Qaundo o Vault é selado (sealed) novamente, ele limpa todo o estado (incluindo a chave de criptografia) da memória.

>> Os principais recursos do Vault:

Secure Secret Storage: secret de chave/valor (Arbitrários podem ser armazenados no Vault). O Valut criptografa esses secret’s antes de escrevê-lo para no armazenamento persistente (Storage/Banco de dados/Cônsul), de modo que mesmo obtendo acesso forçado/bruto não será possível acessar os secret’s.

Dynamic Secrets: O Vault pode gerar secrets sob demanda para alguns sistemas, como Amazon AWS, SQL e etc.

Por exemplo, quando um aplicativo precisa acessar um bucket S3, ele solicita ao Vault as credenciais, o Vault irá gerar um par de chaves do tipo AWS com permissões válidas sob demanda. (Legal neh?!)

Data Encryption: O Vault pode criptografar e descriptografar dados sem armazená-lo. Isso permite que equipes de segurança definam parâmetros de criptografia, possibilitando que os desenvolvedores armazenem os dados criptografados em um local como o SQL sem ter que precisar projetar seus próprios métodos de criptografia.

Leasing and Renewal: Todos os secret’s no Vault São criados com um registro de metadados contendo informações de duração do tempo, renovabilidade e muito mais. No final da locação, o Vault revogará automaticamente esse secret. Os clientes podem renovar esses registros através de APIs de renovação integradas.

Revocation: O Vault possui um suporte interno para a revogação secret. O Vault pode revogar não só secret’s únicos, mas uma árvore de secret’s, por exemplo, todos os secret’s lidos por um usuário específico ou todos os secret’s de um tipo específico. (Ótimo em caso de substituição do colaborador).

>> Casos de usos

General Secret Storage

Possibilidade de armazenar qualquer tipo de secret

Exemplo:

– Variáveis de ambientes sensíveis
– Credenciais de Banco de dados
– Credenciais de API’s
– Gerenciamento de configuração

Employee Credential Storage

Mecanismo para armazenar credenciais compartilhadas

Exemplo:
– Serviços WEB
– Serviços de senhas compartilhadas

OBS: O mecanismo de log de auditoria permite que você saiba quais os secret’s foram acessados por um determinado usuário, podendo obter os últimos logs de acesso que o usuário utilizou.

API Key Generation for Scripts

O recurso "dynamic secrets" do Vault é ideal para scripts: uma chave de acesso AWS pode ser gerada durante a duração de um script e logo em seguida revogada. O par de chaves não existirá antes ou depois do script, e a criação das chaves será completamente registrada.

Exemplo:

– Aplicações

Data Encryption

Além de poder armazenar secret’s, o Vault pode ser usado para criptografar/descriptografar dados armazenados em outros lugares. O principal uso disso é permitir que os aplicativos criptografem seus dados enquanto ainda o armazenam no storage de dados primário.

O principal benefício é que os desenvolvedores não precisam se preocupar com como criptografar dados.

Exemplo:

– Aplicações
– Tokens

Versão atual até a data da criação desse artigo:

Vault 0.8.1 released

Esta versão inclui a autenticação Google Cloud IAM, os backends da base de dados Oracle, os plugins de auto-recarga, além de outros recursos. (Veja mais no site do Vault).
https://www.vaultproject.io/

>> Vault storage backend

Um backend de Storage nada mais é que o local para armazenamento dos dados “persistente”.

A configuração do backend de Storage é feita através do arquivo de configuração do Vault "config.hcl", exemplo:

storage [NAME] {
[PARAMETERS...]
}

For example:

storage "file" {
path = "/mnt/vault/data"
}

Obs: É possível incluir nos parâmetros variáveis de ambiente, tornando precedente sobre os valores no arquivo de configuração.

>> Backends secret

O backend (secret/prefixo)

Para que seja possível escrever os secrets no Vault é necessário especificar qual o backend que pretende utilizar. Por padrão, o Vault monta um backend chamado de genérico para o Secret/prefix. O backend lê e grava os dados no Storage Backend. O Vault suporte outros tipos de backends, além do genérico, e esse recurso em particular é o que torna o Vault exclusivo.

Para representar o backends, o Vault se comporta como um sistema de arquivos: Os backends são montados em caminhos específicos (backend/prefix).

Tipos de backend Storage suportados:

Azure Storage
CockroachDB
Consul
DynamoDB
MongoDB

Etcd
Filesystem
Google Cloud
In-Memory
Mysql
PostrgreSQL
Cassandra
S3
Swift
Zookeper

Obs: Na parte prática será utilizado o Storage MySQL, para armazenar todos os dados (secret, logs, configs e etc).

>> Conceitos Básico:

Vault – modo “Dev”.

Iniciando o Vault no modo DEV

No modo DEV (vault -dev) não é necessário nenhuma configuração adicional. A autenticação será realizada automaticamente (local), facilitando a o uso dos recursos do Vault apenas para desenvolvimento/estudos.

Obs: No modo DEV todas as funcionalidades estarão disponíveis.

Vault – modo Server

O Vault funciona como uma aplicação client/server. No modo server o Vault será o responsável por interagir com os Storages e Backends.

Todas as operações realizadas através da CLI do Vault interagem com o servidor através de um conexão TLS.

>> Propriedades

As propriedades do servidor dev:

Initialized and unsealed

– O servidor será inicializado e desmarcado automaticamente.
– Você não precisa usar o unseal.
– Está pronto para uso imediatamente.

In-memory storage:

– Todos os dados são armazenados (criptografados) na memória.
– O servidor do Vault não requer permissões de arquivo.

Bound to local address without TLS:

– O servidor ficará escutando a porta 127.0.0.1:8200.
– Endereço padrão sem suporte TLS.

Automatically Authenticated:

– O servidor armazena o token de acesso (root).

Com todos os segredos dinâmicos e token de autenticação, o Vault cria um contrato de arrendamento: metadados contendo informações como duração do tempo, renovabilidade e muito mais. O Vault promete que os dados serão válidos para a duração determinada, ou Time To Live (TTL). Uma vez que o arrendamento expirou, o Vault pode revogar automaticamente os dados, e o consumidor do segredo não poderá mais ter certeza de que é válido.

O benefício deve ser claro: os consumidores de segredos precisam fazer check-in com o Vault rotineiramente para renovar o contrato de arrendamento (se permitido), ou solicitar um secret de substituição. Isso faz com que os logs de auditoria do Vault sejam mais valiosos e também tornam a chave muito mais fácil.

Todos os secret dinâmicos no Vault são obrigados a ter um contrato de arrendamento (tempo de vida). Mesmo que os dados sejam válidos para a eternidade, é necessária uma locação para obrigar o consumidor a verificar-se rotineiramente.

Além das renovações, uma locação pode ser revogada. Quando uma locação é revogada, invalida esse segredo imediatamente e evita novas renovações. Por exemplo, com o backend secreto AWS, as chaves de acesso serão excluídas da AWS no momento em que um secret é revogado. Isso tornará as chaves de acesso inválidas a partir desse ponto.

A revogação pode acontecer manualmente através da API, através do comando CLI, ou automaticamente pelo Vault. Quando um contrato de arrendamento expirar, o Vault revogará automaticamente essa locação.

Obs: O Generic Backend, não emite leases.

>> Seal / Unseal

Quando um servidor Vault é iniciado, ele iniciará da seguinte maneira:

Seal: Quando um servidor Vault é iniciado, ele inicia em um estado sealed (selado). Neste estado, o Vault está configurado para saber onde e como acessar o armazenamento físico, mas não sabe como descriptografar qualquer um dado.

Unseal: É o processo de construção da chave master, necessário para ler a chave de telecriptografia e em seguida descriptografar os dados, permitindo o acesso ao Vault.

Antes de destravar (unsealing), quase nenhuma operação é possível com o Vault.

Por exemplo, autenticação, gerenciamento das tabelas de montagem e etc., não serão possíveis.

As únicas operações possíveis são desbloquear o Vault e verificar o status do cancelamento.

Mas Por quê?

Tudo porque os dados são armazenados e criptografados. O Vault precisa da chave de criptografia para descriptografar os dados. As chave de criptografia também é armazenada com os dados, mas criptografada com outra chave de criptografia conhecida como chave master. (hum?)

Quando chegarmos na parte prática tudo ficará mais claro.

A chave master não está armazenada em nenhum lugar, ela será criada no momento em que você rodar o comando (vault init).

Desbloqueando

O processo unseal é feito executando o vault unseal ou através da API. Este processo é stateful: cada chave pode ser inserida através de múltiplos mecanismos e em vários computadores. Isso permite que cada fragmento da chave master esteja em máquinas distintas, tudo isso para uma melhor segurança.

Uma vez que um Vault esteja (Sealed: false), ele permanecerá “aberto” até que ocorra as seguintes situações:

– Fechado novamente via API
– Reiniciando o servidor Vault

Sealing

Há também uma API para selar o Vault. Isso eliminará a chave master e exigirá que outro processo não desejado para restaurá-lo. O Sealing requer apenas um único operador com privilégios de root.

Desta forma, se houver uma intrusão detectada, os dados do Vault poderão ser bloqueados rapidamente, sendo obrigado acessar novamente os fragmentos das chave master.

>> Lease, Renew, and Revoke

Por segurança o Vault guarda por um determinado período as informações em metadados contendo a duração do tempo, renovabilidade e etc.

O Vault precisa garantir que os dados serão válidos durante o tempo que foi determinado (TTL).

Uma vez que aquele arrendamento do secret expirou, o Vault pode revogar automaticamente os dados, e com isso o consumidor não poderá mais ter certeza que aquela informação do secret seja válida.

Por isso os consumidores dos secrets precisam fazer o check-in com o Vault rotineiramente para renovar o contrato de arrendamento (caso permitido), ou solicitar um secret de substituição.

Isso fará com que os logs de auditoria do Vault sejam mais valiosos.

Todos os secrets dinâmicos no Vault são obrigados a terem um contrato de arrendamento. Mesmo que os dados sejam válidos indeterminadamente, será necessário uma locação para obrigar o consumidor verificar rotineiramente, gerando os logs de auditoria.

Quando uma locação for revogada, sequentemente o secret será invalidado para evitar novas renovações.

Exemplo:

Com o backend secret da AWS, as chaves de acesso serão excluídas da AWS no momento em que o secret for revogado. Isso tornará as chaves de acesso inválida a partir desse ponto.

>> Lendo um secret

O Vault lê os dados do armazenamento e em seguida desencriptografa-os. O formato de saída é propositadamente separado em espaços em branco para facilitar a utilização de ferramentas como cut, awk, grep e etc.

Além do formato do Vault, é possível também utilizar ferramentas como o jq (apt-get Install jq), podendo enviar os dados no formato JSON.

>> Excluindo um secret

Para excluir um secret, basta utilizar o comando vault delete.

>> Mount Backend

Assim como em um sistema de arquivos normal, o Vault pode montar um backend várias vezes em diferentes pontos de montagem, tornando útil quando se deseja aplicar políticas de segurança ou até mesmo para especificar diferentes caminhos.

>> Unmount backend

Uma vez que o backend for desmontado, todos os seus secrets serão revogados e seus dados excluídos.

>> Auth Backends

Além dos tokens, é possível também adicionar outros métodos de autenticação.
Auth backends permite métodos alternativos de identificação com o Vault.
Essas identidades são vinculadas de volta a um conjunto de políticas de acesso, assim como tokens.

Por exemplo, para ambientes de desktop, a chave privada ou a autenticação baseada em GitHub estão disponíveis.

Obs: Veremos na prática mais adiante.

>> Policys

As policys do Vault controlam os acessos dos usuários.

Para autenticação, o Vault possui várias opções ou backends que podem ser ativados e usados. Para autorização e políticas (policys), o Vault sempre usa o mesmo formato.

Todos os backends de autenticação devem mapear as identidades de volta para as políticas principais configuradas com o Vault.

Ao inicializar o Vault, sempre existe uma política (policy) especial que não pode ser removida: (root).

Está politica (policy) root é especial, com ela é possível dar o acesso de super-user em tudo que há no Vault.

Uma identidade mapeada para a diretiva root pode fazer qualquer coisa.

As políticas (policys) podem ser criadas no formato HCL ou no modo inline.

Obs: Veremos os dois métodos mais adiante.

O HCL é um formato de configuração legível para humanos e também é compatível com o formato JSON.

Ufa! Quanta coisa….

>> Parte prática

Essa vai ficar para o segundo artigo da trilha….

Segura a onda ae, ainda está semana (28/08 a 01/09) lançaremos a parte prática da trilha.

>> Fonte

https://www.vaultproject.io/