Onde devem viver as credenciais do painel

Todos os painéis de controlo alojados para automatização de servidores lhe pedem a mesma coisa no assistente de configuração: o endereço do seu hipervisor, um token de API, as credenciais de root do seu painel de alojamento web. Depois guardam-nas, porque precisam delas em cada pedido.

Isso é uma coisa razoável de o software querer e uma coisa genuinamente incómoda de se ter aceitado. Acabou de entregar à base de dados de um terceiro a capacidade de eliminar todas as máquinas que possui. Não por um defeito nem por má-fé: é este o comportamento normal, documentado e correto do produto.

Vale a pena ser preciso sobre o que as alternativas lhe dão de facto, porque «ciframos tudo em repouso» é a resposta que toda a gente dá e, por si só, é quase vazia.

Cifrado em repouso, decifrado por quem

Se um SaaS guardar cifrado o token do seu hipervisor, a chave tem de estar nalgum sítio a que esse mesmo SaaS chegue, porque tem de usar o token em seu nome enquanto dorme. A cifra em repouso protege contra um disco roubado e uma cópia de segurança fugida. Não protege contra aquilo que verdadeiramente o preocupa, que é a própria plataforma ser comprometida.

Isto não é um argumento contra cifrar em repouso. É um argumento de que a pergunta «onde está a chave» é a única pergunta, e de que um plano de controlo que consegue decifrar é um plano de controlo que pode ser levado a decifrar.

A alternativa estrutural é a terceira linha: não ter o segredo de todo. O que soa a truque de retórica, até se olhar para o que custa montar.

Guarde o segredo onde está a máquina

A forma que funciona: um pequeno agente corre dentro da rede do próprio cliente, guarda as credenciais localmente e liga-se para fora, à plataforma. A plataforma envia instruções. O agente guarda as chaves.

Isso inverte o raio de destruição. Um comprometimento do plano de controlo passa a poder emitir comandos, o que é mau e ao que voltaremos, mas não pode levar consigo um ficheiro cheio de tokens de hipervisor de todos os clientes, porque esse ficheiro não existe.

As peças que tornam isto real não têm glamour nenhum.

O cofre, e contra o que protege honestamente

O nosso agente guarda as credenciais num ficheiro local cifrado com XChaCha20-Poly1305. A chave não é o ficheiro em disco: é derivada com HKDF a partir de um ficheiro de chave misturado com a identidade da própria máquina, e os dados autenticados adicionais ligam o texto cifrado à versão do formato e ao identificador do agente.

A consequência prática é aquela para a qual vale a pena desenhar. Copie o ficheiro de chave e o cofre para outra máquina e não abre. Reponha noutro anfitrião a cópia de segurança do mês passado do diretório de dados e não abre. Todos os modos de falha, chave errada, agente diferente, bytes alterados, produzem o mesmo erro indistinguível, e é esse o objetivo.

Eis a parte que devia constar na documentação de todos os produtos que fazem isto e que normalmente lá não está. Isto não protege contra o root no anfitrião. Não pode, e não precisa: o cliente é dono do anfitrião e dono das credenciais. O que o cofre protege é contra um ficheiro fugido, não contra o dono da máquina. Um fornecedor que dê a entender o contrário está a vender-lhe uma sensação.

As credenciais nunca tocam na base de dados da plataforma

Esta é a parte que é fácil fazer mal na convicção de se ter feito bem, porque o código parece correto de qualquer das formas.

Quando alguém escreve um token de hipervisor no nosso painel, a linha que entra na tabela de comandos contém apenas nomes de campos. Os valores viajam numa mensagem transitória separada que não é guardada e vão diretos para a entrega ao agente. O despachante nunca os escreve no registo e nunca os guarda.

Se estiver a avaliar um produto quanto a isto, a pergunta a fazer não é «guardam credenciais». É «o que está no vosso registo de auditoria e o que está na vossa fila». Uma fila que transporta o segredo é uma base de dados que transporta o segredo com passos a mais.

Eliminar um segredo é um problema diferente de o guardar

Remover uma integração no painel tem de resultar no desaparecimento das credenciais de uma máquina que não controla, o que é um problema mais difícil do que parece.

A implementação óbvia é uma reconciliação: perguntar ao agente o que tem, comparar com o que a base de dados diz que devia ter, eliminar a diferença. É mais curta e é perigosa, porque a subtração falha na direção de desapareceu tudo. Uma leitura falhada, uma lista truncada, e acabou de gerar uma instrução para limpar todas as integrações a funcionar naquele anfitrião, e essas credenciais não são recuperáveis sem o cliente as voltar a escrever.

Por isso a instrução vem apenas de conhecimento positivo: existe uma linha porque alguém eliminou genuinamente uma integração. Uma leitura falhada produz zero linhas e, portanto, zero instruções, e o segredo fica onde estava, que é exatamente o estado em que já se encontrava.

É entregue duas vezes: de imediato pelo barramento de eventos, e outra vez em cada aperto de mão de sessão, para o agente que estava offline, a mensagem que se perdeu, o gateway que reiniciou. Ambos os caminhos leem a mesma tabela, pelo que não há segunda verdade nem segunda ordenação.

O que um certificado de agente roubado pode e não pode fazer

Se o agente se autentica com um certificado de cliente, a pergunta honesta é o que acontece quando alguém o leva. Ser específico sobre isto é mais útil do que uma página de segurança.

Pode fazer-se passar por esse agente. A porta da sessão exige TLS mútuo e, por cima da verificação de TLS, a impressão digital do certificado do par é procurada na tabela de agentes, que tem um índice único. Uma impressão digital aponta portanto para exatamente um agente, e a identidade declarada no aperto de mão é comparada com ela. Um atacante com o certificado passa a ser esse agente e pode enviar tudo o que um agente pode enviar: eventos de estado, resultados, telemetria.

Não consegue ler dados de outros clientes. Tudo é delimitado pela organização a que o agente pertence, resolvida a partir do certificado e não do que o cliente diga sobre si próprio.

Não entrega, por si só, as credenciais. O certificado é a identidade usada para falar com a plataforma. A chave do cofre é separada, vive no anfitrião e está ligada à identidade de máquina desse anfitrião. Quem tiver as duas tem root na máquina, e a essa altura o certificado é o menor dos problemas.

Deixa de funcionar quando o disser, em cerca de um minuto. A revogação é um estado na base de dados, não uma CRL nem OCSP. Uma ligação nova é recusada de imediato. Uma ligação existente é reverificada num intervalo de um minuto, pelo que um atacante já ligado tem no máximo isso. Se a própria verificação de estado continuar a falhar, a sessão é fechada ao fim de três falhas seguidas em vez de ser mantida aberta indefinidamente, o que limita o pior caso a cerca de três minutos.

E o agente limpa atrás de si. Ao ser revogado, apaga o cofre, a chave do cofre, a sua identidade, o estado de sessão e as suas filas, por esta ordem, credenciais primeiro. Cada passo é feito com o melhor esforço e registado individualmente, porque meia limpeza é melhor do que limpeza nenhuma.

Os certificados são também de vida curta, noventa dias, renovados automaticamente a meio do prazo com uma verificação de hora a hora. Isso não é tanto uma defesa contra o roubo como um limite ao tempo em que um roubo que ninguém notou continua útil.

O que isto não resolve

Três coisas, ditas com clareza, porque um modelo de ameaças sem risco residual é uma página de publicidade.

Um plano de controlo comprometido continua a poder emitir comandos. Não consegue roubar os seus tokens, mas pode dizer ao seu agente para eliminar uma máquina, e o agente elimina-a. Mudar os segredos de sítio muda o raio de destruição; não o elimina. O que ganha em troca é que o dano fica limitado ao que a API consegue exprimir e é visível num rasto de auditoria, em vez de ser um atacante com as suas credenciais a fazer o que lhe apetece diretamente contra o seu hipervisor às três da manhã.

O root no anfitrião do agente lê tudo. Por desenho. Se esse anfitrião estiver comprometido, tem uma máquina comprometida dentro da sua própria rede, e ela tem as credenciais do seu hipervisor porque é ali que elas têm de estar.

A eliminação depende de o agente voltar. Se um anfitrião nunca mais se ligar, a instrução para esquecer as credenciais fica em aberto. Isso é visível no painel em vez de ser marcado como feito em silêncio, que é a troca correta, mas é uma limitação real e vale a pena conhecê-la antes de se depender dela.

Perguntas que vale a pena fazer a um fornecedor

Seja o que for que acabe por comprar, estas cinco separam os produtos que pensaram no assunto dos que escreveram um parágrafo:

1. 01Onde está a chave de decifração, fisicamente? Se a resposta for «na nossa plataforma», a cifra em repouso está a proteger contra o roubo de um disco e contra mais nada.
2. 02O que está no registo de auditoria e na fila de trabalhos? Os segredos fogem para esses dois sítios muito mais vezes do que para a tabela com que alguém teve cuidado.
3. 03O que acontece às credenciais quando eliminar uma integração, e consigo ver se aconteceu mesmo?
4. 04Quanto tempo demora a revogar um acesso, e aplica-se às sessões que já estão abertas?
5. 05Alguma coisa precisa de uma porta de entrada? Uma regra de firewall que deixa a gama de endereços de um fornecedor entrar na interface de gestão do seu hipervisor é uma segunda versão, mais discreta, do mesmo problema.

Foi assim que o construímos no Provibr: o agente corre no hardware do próprio cliente, guarda as credenciais localmente e só se liga para fora.