> 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/clm.md). # CLM O **DataDike CLM** (Certificate Lifecycle Management) é o módulo proprietário do PAM responsável por **descobrir, inventariar, monitorar, renovar e auditar** certificados digitais em todo o parque tecnológico da organização. Ele opera de forma totalmente integrada à plataforma PAM, compartilhando a **console unificada**, o cofre de segredos e o modelo de identidade, sem exigir uma ferramenta externa ou um portal separado. O CLM elimina o trabalho manual de planilhas e lembretes de vencimento, transformando o controle de certificados em um processo contínuo, governado por **políticas de conformidade** e suportado por **jobs automáticos**, **eventos** e **alertas**. Toda a operação acontece em arquitetura **cluster ativo-ativo**, garantindo continuidade mesmo durante manutenções ou falhas de um nó. {% hint style="info" %} Esta é a página índice e operacional do módulo no Product Guide. Para procedimentos detalhados, utilize os links da seção [Índice de Páginas](#indice-de-paginas) ao final deste documento. {% endhint %} ## Como Acessar O CLM é acessível por dois pontos complementares, ambos parte da mesma plataforma PAM: ### Console Unificada do PAM A operação do dia a dia é feita diretamente na console web do PAM, no menu **PAM > Certificados**. A partir dele, o operador navega pelas visões de inventário, máquinas, autoridades certificadoras, políticas, jobs e eventos sem alternar de aplicação. A console unificada respeita o mesmo controle de acesso baseado em papéis (RBAC) do restante do PAM, de modo que cada usuário enxerga apenas os ativos e ações compatíveis com seu perfil. ### Tela de Settings do CLM (porta 5434) As configurações estruturais do módulo — credenciais de integração, parâmetros de descoberta, definição de gateways, ajustes de cluster e chaves de API — ficam na **tela de settings própria do CLM**, exposta pela **API REST do módulo na porta 5434**. Essa separação isola a administração de baixo nível da operação cotidiana, reduzindo a superfície de erro. {% hint style="warning" %} O acesso à porta **5434** é restrito por rede e por credencial. Mesmo administradores do PAM precisam estar dentro da faixa de IP autorizada e portar um token válido para interagir com a API e com a tela de settings do CLM. Consulte o [Modelo de Segurança](#modelo-de-seguranca). {% endhint %} ## Conceitos Fundamentais Antes de operar o módulo, é importante compreender as entidades que o CLM gerencia. Elas se relacionam entre si e formam a base de todos os relatórios, políticas e automações. ### Inventário de Certificados O **inventário** é a fonte única de verdade sobre cada certificado conhecido pela organização. Para cada item são mantidos atributos como emissor, titular (subject), SANs, algoritmo e tamanho de chave, número de série, fingerprint, datas de emissão e expiração, cadeia de confiança e o local onde o certificado está efetivamente instalado. Os registros do inventário são alimentados por **descoberta automática** e por **importação manual**, e são continuamente reconciliados pelos jobs do módulo. Isso permite identificar certificados duplicados, órfãos, autoassinados ou fora de política. ### Máquinas As **máquinas** representam os hosts, serviços e endpoints onde os certificados residem ou são utilizados — servidores web, balanceadores, appliances, bancos de dados, dispositivos de rede e cargas de trabalho em nuvem. Cada máquina pode hospedar múltiplos certificados, e o CLM mapeia essa relação para que a renovação de um certificado atualize todos os pontos de uso correspondentes. ### Autoridades Certificadoras (CAs) As **Autoridades Certificadoras** cadastradas no módulo são as fontes confiáveis de emissão e renovação. O CLM suporta CAs internas (corporativas) e públicas, e mantém para cada uma os parâmetros de protocolo, perfis de emissão e credenciais necessárias para solicitar, renovar e revogar certificados de forma automatizada. {% hint style="info" %} A configuração detalhada de CAs e dos fluxos de emissão/renovação é tratada na página **Ciclo de Vida, Renovação e Autoridades Certificadoras**. {% endhint %} ### Políticas de Conformidade As **políticas** definem o que é considerado um certificado em conformidade dentro da organização. Uma política pode exigir, por exemplo, tamanho mínimo de chave, algoritmos de assinatura aprovados, validade máxima, emissores permitidos, presença de SANs obrigatórias e janelas de antecedência para renovação. Cada certificado do inventário é avaliado continuamente contra as políticas aplicáveis. Desvios geram **eventos** e podem disparar **alertas** e ações automáticas, conforme a configuração. ### Jobs Os **jobs** são as rotinas automáticas que mantêm o módulo vivo: varreduras de descoberta, reconciliação de inventário, avaliação de conformidade, verificação de expiração, solicitações de renovação e coleta de métricas. Cada job tem agendamento próprio, registra histórico de execução e expõe status para acompanhamento na console. ### Eventos e Alertas Os **eventos** formam a trilha de tudo o que acontece no módulo — descoberta de um certificado novo, mudança de estado, falha de renovação, violação de política ou proximidade de expiração. A partir dos eventos, o CLM gera **alertas** roteados aos canais e destinatários configurados, permitindo ação proativa antes de uma indisponibilidade causada por certificado vencido. ### Gateways Os **gateways** são componentes distribuídos que estendem o alcance do CLM até segmentos de rede isolados, filiais, DMZs e ambientes de nuvem. Em vez de exigir conectividade direta do núcleo do módulo a cada host, o gateway atua como ponto de coleta e execução local, comunicando-se de volta ao núcleo de forma autenticada e cifrada. Isso preserva a segmentação de rede sem abrir mão da visibilidade centralizada. ## Modelo de Segurança A segurança do CLM segue os mesmos princípios rígidos do restante do PAM e adiciona controles específicos para o tráfego da API do módulo. ### Autenticação em Duas Camadas (IP + Bearer) Toda requisição à API REST do CLM na porta **5434** passa por **duas camadas de autenticação obrigatórias e cumulativas**: * **Camada de rede (IP):** apenas origens dentro das faixas de IP explicitamente autorizadas conseguem estabelecer conexão com o serviço. Requisições de fora dessas faixas são recusadas antes mesmo da avaliação de credenciais. * **Camada de credencial (Bearer):** além do IP autorizado, cada chamada deve apresentar um **token Bearer** válido. Sem o token correto, a requisição é rejeitada mesmo vindo de uma origem confiável. Essa combinação garante que conhecer o token não basta sem estar na rede certa, e estar na rede certa não basta sem o token — reduzindo drasticamente o risco de acesso indevido. {% hint style="danger" %} Nunca exponha a porta **5434** diretamente à internet nem reutilize tokens entre ambientes. A rotação periódica de tokens deve ser tratada como parte da rotina de segurança e é configurada na tela de settings do CLM. {% endhint %} ### Segredos Cifrados em Repouso Credenciais de integração com CAs, gateways, provedores de nuvem e ferramentas de DevOps são armazenadas **cifradas em repouso**. Em nenhum momento esses segredos são apresentados em texto claro na console ou na API após o cadastro; o módulo trabalha apenas com referências e com a forma cifrada. ### Chaves no Cofre do PAM As **chaves privadas** e demais materiais sensíveis manipulados pelo CLM são custodiados no **cofre de segredos do PAM**, herdando todos os seus controles de proteção, segregação de funções e auditoria. O CLM nunca mantém chaves privadas fora do cofre, o que assegura que a custódia do material criptográfico permaneça centralizada e auditável. ### Trilha de Auditoria Todas as ações administrativas e operacionais — emissão, renovação, revogação, alterações de política, mudanças de configuração e acessos à API — são registradas na trilha de auditoria da plataforma, permitindo rastreabilidade completa para fins de governança e conformidade. ## Alta Disponibilidade O CLM opera em **cluster ativo-ativo**: dois ou mais nós atendem requisições simultaneamente, compartilhando estado de forma consistente. Não há um nó "passivo" ocioso à espera de falha — todos participam da operação. Caso um nó fique indisponível, os demais continuam atendendo sem interrupção perceptível, e os jobs agendados não são perdidos. Os detalhes de topologia, sincronização e dimensionamento são tratados na página de Integrações e Alta Disponibilidade. {% hint style="info" %} Os parâmetros de cluster (membros, endpoints internos e chaves de coordenação) são definidos na tela de settings do CLM na porta 5434. {% endhint %} ## Índice de Páginas Este módulo está organizado nas seguintes páginas filhas. Cada uma aprofunda um aspecto do ciclo de vida de certificados: * **Inventário e Descoberta** — como o CLM encontra certificados na rede, importa registros manualmente, reconcilia o inventário e mantém a relação entre certificados e máquinas. * **Ciclo de Vida, Renovação e Autoridades Certificadoras** — cadastro de CAs, perfis de emissão, renovação automática e manual, revogação e tratamento de falhas de renovação. * **Alertas, Relatórios e Notificações** — configuração de eventos, políticas de conformidade, canais de notificação, relatórios de validade e painéis de acompanhamento. * **Integrações (Nuvem/DevOps) e Alta Disponibilidade** — conectores para provedores de nuvem e pipelines de DevOps, configuração de gateways e operação do cluster ativo-ativo. {% hint style="info" %} Comece por **Inventário e Descoberta** caso o módulo esteja sendo implantado pela primeira vez: o inventário é a base sobre a qual políticas, alertas e renovação automática passam a fazer sentido. {% endhint %} --- # 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/clm.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.