> 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-guide/configuracoes/pam/secrets-devops.md). # Secrets & DevOps (A2A / Hardcoded) O módulo **Secrets Management / DevOps** do DataDike PAM elimina o problema crônico de **credenciais embutidas em código (hardcoded)** e estabelece um modelo seguro de comunicação **Application-to-Application (A2A)**. Em vez de aplicações, scripts e serviços guardarem senhas em arquivos de configuração, variáveis de ambiente em texto claro ou no próprio código-fonte, elas passam a solicitar o segredo ao cofre digital do DataDike PAM no momento exato do uso, de forma autenticada, auditada e com baixa latência. Este módulo é gerenciado no console em **Sysadmin > Accounts > Automations** (contas e identidades não humanas) e em **System Settings > Account Storage** (configuração do cofre, replicação e políticas), e cobre todo o ciclo de vida do segredo: descoberta, armazenamento, distribuição, rotação, auditoria e desativação. {% hint style="info" %} **A2A (Application-to-Application)** refere-se à autenticação entre sistemas sem intervenção humana — uma aplicação que acessa um banco de dados, um pipeline que faz deploy em nuvem, um serviço Windows que consome uma API. São exatamente esses os casos em que senhas costumam ser deixadas em texto claro. {% endhint %} ## Visão geral da arquitetura O módulo é composto por quatro planos funcionais que operam de forma integrada: * **Plano de descoberta** — varre serviços automatizados, repositórios de código e pipelines CI/CD em busca de credenciais hardcoded. * **Plano de cofre (A2A Vault)** — armazena segredos cifrados e os entrega sob demanda mediante autenticação da aplicação consumidora. * **Plano de distribuição/entrega** — leva o segredo até o servidor, contêiner ou pipeline com cache seguro e resiliência a falhas de rede. * **Plano de governança** — políticas de acesso não humano, rotação automatizada, auditoria e conformidade. ## 1. Descoberta automatizada de credenciais hardcoded O DataDike PAM realiza varredura contínua para localizar credenciais embutidas em três superfícies principais: ### Serviços automatizados O agente de descoberta inspeciona o ambiente operacional em busca de senhas estáticas configuradas em: * **Serviços do Windows** (contas de logon `Log On As`), Tarefas Agendadas e pools de aplicação do IIS. * **Daemons e units do Linux** (systemd, scripts em `/etc/init.d`, cron jobs). * **Strings de conexão** de bancos de dados, filas de mensagens e middlewares. * **Arquivos de configuração** (`.config`, `.ini`, `.properties`, `.env`, `.yaml`, `.json`). ### Repositórios de código-fonte A varredura de repositórios identifica segredos versionados, inclusive em commits históricos: * Chaves de API, tokens OAuth, senhas de banco, chaves privadas e certificados. * Análise por **padrões (regex/assinaturas)** e por **entropia** (detecção de strings aleatórias com alta probabilidade de serem segredos). * Inspeção do **histórico do Git**, não apenas do estado atual da árvore, para encontrar segredos removidos do `HEAD` mas ainda presentes em commits anteriores. ### Pipelines DevOps (CI/CD) A descoberta cobre a esteira de entrega contínua: * Definições de pipeline (arquivos de workflow, jobs, stages). * Variáveis de pipeline e arquivos de credenciais usados em build e deploy. * Artefatos e imagens intermediárias geradas pela esteira. Cada achado gera um **registro de descoberta** com localização, tipo de segredo, criticidade estimada e recomendação de remediação (cofrar, rotacionar e remover do código). ## 2. Cofre digital A2A (Application-to-Application) O coração do módulo é o **A2A Vault**, um cofre digital dedicado ao armazenamento e à consulta sob demanda das credenciais usadas por aplicações. * Segredos armazenados **cifrados em repouso** e **em trânsito** (TLS 1.3 obrigatório). * Organização por **namespaces** e **coleções de segredos**, com herança de políticas. * Suporte a múltiplos tipos de segredo: senhas, chaves de API, tokens, chaves SSH, certificados, pares de chaves e segredos genéricos (binários/JSON). * Consulta sob demanda: a aplicação autentica-se, recebe o segredo válido naquele instante e nunca precisa persisti-lo localmente. {% hint style="warning" %} Uma vez cofrado, o segredo deve ser **removido do código e dos arquivos de configuração**. Manter cópias paralelas anula o controle do cofre e reabre a superfície de risco que o módulo elimina. {% endhint %} ### Identidade da aplicação consumidora Cada aplicação ou serviço que consome segredos recebe uma **identidade A2A** em **Sysadmin > Accounts > Automations**, autenticada por um ou mais fatores: * **AppRole / Client ID + Secret** com rotação do próprio fator. * **Certificado mTLS** (TLS mútuo) vinculado à carga de trabalho. * **Atributos de host** (caminho do binário, hash, hostname, usuário do processo). * **Identidade de carga de trabalho** em Kubernetes (ServiceAccount/JWT) e em nuvens (IAM/Managed Identity). ## 3. APIs e SDKs para password injection Para tirar a senha do código de aplicações legadas e modernas, o DataDike PAM oferece dois caminhos de **injeção de senha (password injection)**: * **API REST** — endpoint autenticado para recuperar um segredo por nome/caminho, ideal para integrações pontuais e linguagens sem SDK dedicado. * **SDKs nativos** — bibliotecas para **Java, .NET, Python, Go, Node.js e C/C++**, que cuidam de autenticação, cache em memória, renovação de lease e tratamento de falhas. Para aplicações que **não podem ser recompiladas**, há modos sem alteração de código: * **Wrapper de processo** que injeta segredos como variáveis de ambiente apenas em memória. * **Substituição de placeholders** em tempo de inicialização, trocando marcadores como `{{secret:db/prod#password}}` pelo valor real. ```bash # Exemplo: recuperar um segredo via API REST (token de aplicação A2A) curl -s https://pam.datadike.local/api/v1/secrets/db/prod \ -H "Authorization: Bearer ${APP_TOKEN}" \ | jq -r '.data.password' ``` ## 4. Rotação automatizada de senhas O DataDike PAM rotaciona as senhas **sem exigir reescrita de arquivos de configuração**, porque as aplicações sempre buscam o valor corrente no cofre. * Rotação por **agendamento** (intervalo fixo) ou **por evento** (ao detectar exposição, desligamento de colaborador, suspeita de vazamento). * Rotação **on-checkout** e **just-in-time**: o segredo pode ser de uso único ou ter validade curta. * Conectores de rotação para **bancos de dados** (SQL Server, Oracle, PostgreSQL, MySQL/MariaDB), **diretórios** (Active Directory/LDAP), **sistemas operacionais** (Windows/Linux) e **serviços de nuvem**. * **Sincronização atômica**: a nova senha só é considerada ativa após confirmação no sistema-alvo, evitando janela de credencial inválida. {% hint style="success" %} Como a aplicação nunca guarda a senha, a rotação é transparente: na próxima requisição ao cofre, a carga de trabalho já recebe o valor atualizado, sem reinício e sem deploy. {% endhint %} ## 5. Auditoria de uso das credenciais Todo acesso a segredo gera trilha de auditoria imutável, respondendo **quem, como e quando**: | Campo | Descrição | | ------------- | ----------------------------------------------------------------- | | **Quem** | Identidade A2A, host de origem, ServiceAccount/IAM associado | | **O quê** | Caminho/nome do segredo e versão entregue | | **Como** | Método (API, SDK, sidecar, CSI), fator de autenticação usado | | **Quando** | Timestamp com fuso do servidor e correlação com a janela de lease | | **Resultado** | Concedido, negado por política, expirado ou revogado | * Eventos exportáveis para **SIEM** via syslog/CEF, webhook ou integração de eventos de terceiros (**System Settings > Integrations**). * Detecção de anomalias: volume incomum de leituras, acesso de host não esperado, uso fora de janela. * Trilha vinculada às descobertas de hardcoded, permitindo provar a remediação ponta a ponta. ## 6. Compatibilidade multiplataforma O módulo opera de forma homogênea em ambientes heterogêneos: * **Windows** — agente de serviço, integração com Serviços, Tarefas Agendadas e IIS. * **Linux** — agente/daemon, integração com systemd e ferramentas de configuração. * **Contêineres** — **Docker** (sidecar e variáveis injetadas) e **Kubernetes** (sidecar, init container, CSI Driver e mutating webhook). A mesma identidade A2A e as mesmas políticas valem independentemente da plataforma, garantindo governança unificada. ## 7. Políticas de acesso para credenciais não humanas Senhas de uso não humano têm requisitos distintos das de uso interativo, e o DataDike PAM aplica políticas específicas: * **Vínculo à carga de trabalho** — o segredo só é entregue à aplicação esperada, no host esperado, durante a janela esperada. * **Escopo mínimo (least privilege)** — cada identidade A2A enxerga apenas os segredos de que precisa. * **Lease com TTL** — concessões temporárias com renovação controlada e revogação imediata. * **Restrições de origem** — listas de hosts/redes, faixas de IP, exigência de mTLS. * **Sem fluxo interativo** — políticas de uso não humano não exigem (nem aceitam) aprovação manual em tempo real, mas registram tudo para revisão posterior. * **Segregação de ambientes** — segredos de produção, homologação e desenvolvimento isolados por namespace e política. ## 8. Integração com controle de versão e alertas de hardcoded Para evitar que credenciais cheguem ao repositório e para alertar quando já estiverem expostas, o módulo integra-se ao fluxo de versionamento: ### Prevenção no commit (Git) * **Hook de pré-commit** e **hook de servidor (pre-receive)** que bloqueiam o envio de código contendo segredos. * Integração com **GitLab** e **GitHub** para varredura de pushes e Pull/Merge Requests. * Política de **break-the-build**: o pipeline falha se um segredo for detectado, forçando a remediação antes do merge. ### Alertas de detecção * **Alerta em repositório** ao identificar segredo em commit novo ou no histórico. * **Alerta em produção** ao identificar credencial hardcoded em servidores e contêineres em execução. * Notificações via console, e-mail, webhook e eventos para integrações de terceiros. * Cada alerta traz **localização exata**, tipo de segredo e fluxo guiado de remediação (cofrar → rotacionar → remover do código). {% hint style="danger" %} Um segredo que já foi commitado deve ser tratado como **comprometido**: remover do histórico não basta. O fluxo de remediação do DataDike PAM **rotaciona automaticamente** a credencial exposta, invalidando o valor que vazou. {% endhint %} ## 9. Entrega local com cache seguro e resiliência A entrega de segredos ocorre **localmente** no servidor ou contêiner, com cache seguro e sincronização posterior, garantindo baixa latência e resiliência: * **Agente local** mantém um **cache cifrado em memória** dos segredos autorizados para aquela carga de trabalho. * Em **falha de rede** com o cofre central, a aplicação continua recebendo o valor em cache válido (dentro do TTL), evitando indisponibilidade. * Ao **restabelecer a conexão**, o agente sincroniza: aplica rotações pendentes, atualiza versões e descarta valores expirados. * O cache nunca é gravado em disco em texto claro; chaves de proteção ficam vinculadas ao processo/host. Esse modelo combina a **segurança de um cofre centralizado** com a **disponibilidade de entrega na borda**, adequado a microsserviços e cargas distribuídas. ## 10. Replicação e sincronização com cofres de nuvem O DataDike PAM atua como **plano de controle unificado** de segredos, replicando e sincronizando com cofres gerenciados de nuvem: * **AWS Secrets Manager** * **Azure Key Vault** * **GCP Secrets Manager** Características da sincronização: * **Políticas unificadas** — a mesma regra de acesso, rotação e auditoria vale para o segredo, esteja ele no cofre DataDike ou replicado na nuvem. * **Visibilidade centralizada** — inventário único de segredos, independentemente do provedor onde residem. * **Direção configurável** — replicação do DataDike para a nuvem (push) ou ingestão da nuvem para o inventário central (pull), por namespace. * **Rotação propagada** — uma rotação no plano de controle é refletida nos cofres de destino, mantendo consistência. ## 11. SDKs, conectores DevOps e modos de injeção Para integração com a esteira DevOps sem alterações significativas no código, o módulo oferece **conectores nativos** e **múltiplos modos de injeção**. ### Conectores DevOps nativos | Ferramenta | Forma de integração | | ------------- | ------------------------------------------------------------------------------ | | **Jenkins** | Plugin de credenciais; segredos resolvidos no job sem ficarem no `Jenkinsfile` | | **GitLab** | Integração CI/CD e varredura de repositório/MR | | **GitHub** | GitHub Actions e varredura de push/PR | | **Terraform** | Provider/data source para consumir segredos no `plan`/`apply` | | **Ansible** | Lookup plugin para resolver segredos em playbooks e templates | ### Modos de injeção em contêineres e pipelines * **Sidecar** — contêiner auxiliar que obtém os segredos e os disponibiliza ao contêiner principal. * **Init container** — popula segredos antes do start da aplicação. * **CSI Driver** — monta segredos como volume via Container Storage Interface no Kubernetes. * **Arquivos YAML** — renderização de manifests com valores resolvidos a partir do cofre. * **Variáveis de ambiente** — injeção em memória no boot do processo. * **Volumes compartilhados** — entrega via volume temporário com permissão restrita. {% hint style="info" %} Os modos podem ser combinados. Por exemplo, um **init container** para o segredo inicial e o **CSI Driver** para atualização contínua, mantendo a aplicação alheia à mecânica de rotação. {% endhint %} A integração foi desenhada para ser **não intrusiva**: na maioria dos casos, basta declarar a dependência de segredo no manifesto ou no job, sem reescrever a lógica da aplicação. ### Conformidade O módulo Secrets Management / DevOps do DataDike PAM foi projetado em aderência às melhores práticas de mercado, atendendo (no mínimo) aos seguintes referenciais: * **CIS Controls** — em especial os controles de gestão de contas, controle de acesso e gestão de credenciais (incluindo contas de serviço e não humanas). * **NIST** — alinhamento ao NIST SP 800-53 (controles de Identificação e Autenticação — família IA) e às diretrizes de gestão de identidade digital do NIST SP 800-63. * **OWASP Secrets Management** — adoção do OWASP Secrets Management Cheat Sheet, cobrindo armazenamento centralizado e cifrado, rotação, eliminação de segredos no código, distribuição segura e detecção de segredos em repositórios. Os controles do módulo — descoberta de hardcoded, cofre A2A, rotação automatizada, políticas de uso não humano, auditoria imutável e prevenção em pipelines — fornecem as evidências necessárias para demonstrar conformidade em auditorias internas e externas, com relatórios exportáveis em **System Settings > Account Storage** e nos painéis de auditoria do DataDike PAM. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://wiki.datadike.com/product-guide/configuracoes/pam/secrets-devops.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.