> For the complete documentation index, see [llms.txt](https://wiki.datadike.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://wiki.datadike.com/product-docs/expert-insights/criptografia-na-rotacao-de-senhas.md).

# Criptografia na Rotação de Senhas

Como o DataDike PAM protege credenciais em trânsito durante a rotação automática de senhas em ativos Linux (SSH) e Windows (WinRM/HTTPS) — sem agentes instalados.

## Visão Geral

Quando o DataDike PAM realiza a rotação automática de uma senha, a nova credencial precisa ser transmitida ao ativo de destino. Sem um agente no host, o protocolo de transporte é responsável por toda a proteção criptográfica.

> ✅ **Não há tráfego de senha em texto claro.** O protocolo de transporte — SSH ou WinRM/HTTPS — criptografa a sessão de ponta a ponta antes de qualquer credencial ser enviada.

***

## Linux — Rotação via SSH

### Protocolo e criptografia

| Elemento             | Detalhe                                     |
| -------------------- | ------------------------------------------- |
| Protocolo            | SSH 2.0                                     |
| Cifras suportadas    | AES-256-CTR, AES-256-GCM, ChaCha20-Poly1305 |
| Troca de chaves      | Diffie-Hellman curve25519, ECDH P-384       |
| Autenticação do host | Host key verification (ed25519 / RSA-4096)  |
| Integridade          | HMAC-SHA2-256 / HMAC-SHA2-512               |

### Fluxo de rotação

1. O PAM abre uma sessão SSH autenticada com o host de destino (usando a credencial atual, armazenada no cofre com AES-256).
2. Dentro do túnel SSH criptografado, executa o comando `passwd` ou equivalente para definir a nova senha.
3. A nova senha **nunca trafega fora do túnel SSH**.
4. O PAM armazena a nova credencial no cofre e encerra a sessão.

***

## Windows — Rotação via WinRM/HTTPS

### Protocolo e criptografia

| Elemento                 | Detalhe                                                     |
| ------------------------ | ----------------------------------------------------------- |
| Protocolo                | WinRM sobre HTTPS                                           |
| Versão TLS               | TLS 1.2 (mínimo) / TLS 1.3 (preferencial)                   |
| Cifras (TLS 1.3)         | TLS\_AES\_256\_GCM\_SHA384, TLS\_CHACHA20\_POLY1305\_SHA256 |
| Cifras (TLS 1.2)         | ECDHE-RSA-AES256-GCM-SHA384                                 |
| Autenticação do servidor | Certificado X.509 no listener HTTPS                         |
| Autenticação do PAM      | Kerberos (domínio) ou credencial local com NTLM via HTTPS   |

### Fluxo de rotação

1. O PAM estabelece uma sessão WinRM sobre HTTPS (porta 5986 por padrão).
2. O certificado do servidor é validado — conexões sem certificado válido são recusadas.
3. Dentro do canal TLS, o PAM executa o cmdlet PowerShell `Set-LocalUser` (local) ou `Set-ADAccountPassword` (domínio).
4. A nova senha **nunca trafega fora do canal TLS**.
5. O PAM atualiza o cofre e encerra a sessão.

{% hint style="warning" %}
**WinRM sem HTTPS (HTTP na porta 5985) não deve ser habilitado em produção.** Consulte o guia [Habilitação Segura do WinRM](/product-docs/expert-insights/habilitacao-segura-do-winrm.md) para configurar corretamente o listener HTTPS com GPO.
{% endhint %}

***

## Comparativo de Proteção

| Camada                    | Linux (SSH)            | Windows (WinRM/HTTPS)          |
| ------------------------- | ---------------------- | ------------------------------ |
| Transporte                | SSH 2.0                | TLS 1.2/1.3                    |
| Criptografia              | AES-256-CTR / ChaCha20 | AES-256-GCM / ChaCha20         |
| Autenticação mútua        | Host key + credencial  | Certificado X.509 + credencial |
| Proteção contra sniffing  | ✅                      | ✅                              |
| Agente no host necessário | ❌                      | ❌                              |

***

## Perguntas Frequentes

**A senha trafega em texto claro em algum momento?**\
Não. O handshake TLS/SSH é concluído antes de qualquer dado de aplicação ser transmitido. Toda a troca de credenciais ocorre dentro do canal criptografado.

**O que acontece se o certificado WinRM expirar?**\
A conexão é recusada. O PAM registra o erro como falha de rotação e a credencial anterior permanece válida no cofre até que o problema seja corrigido.

**O PAM valida a identidade do host de destino?**\
Sim. Para SSH, a host key do servidor é verificada a cada conexão. Para WinRM/HTTPS, o certificado do servidor deve ser válido e confiável pela CA configurada.

**Como um analista de segurança pode auditar as rotações?**\
Cada rotação gera um registro no módulo de auditoria do PAM (Console → Password changes), incluindo timestamp, ativo de destino, conta rotacionada e resultado (sucesso/falha).