As credenciais estáticas ainda são a forma mais fácil para a IA entrar

A IA não inventou a credencial com privilégios excessivos, apenas encontrou a maneira mais rápida de usá-la. Cada agente, script e integração que roda no seu ambiente se autentica com algo, e na maioria dos ambientes, esse algo é uma senha, uma chave de API ou um token emitido uma vez e nunca mais tocado. Uma pessoa esquece uma senha e acaba sendo bloqueada. Uma identidade de máquina simplesmente continua usando o que foi dado, enquanto ninguém estiver olhando.

Mais identidades, mais violações

Pesquisamos 2.317 líderes de segurança e TI este ano, e o número mais claro nos resultados foi este: organizações onde a IA aumentou significativamente o número de identidades em seu ambiente relataram uma taxa de violação de 43% nos últimos 12 meses. Organizações onde a IA não mudou muito a contagem de identidades relataram 11%. Isso é uma diferença de 4 vezes, e não é porque o grupo com muita IA tinha segurança mais fraca no geral. Nossos dados mostram que eles estavam à frente na maioria dos fundamentos.

Onde eles não estavam à frente era identidade não humana governança. Setenta e seis por cento das organizações nos disseram que não governam ou monitoram totalmente suas identidades não humanas, e apenas 19% disseram que sim. Essa é a população pela qual a IA está passando: um conjunto crescente de identidades de máquinas, a maioria delas se autenticando com uma credencial que ninguém verificou desde o dia em que foi emitida.

Credenciais estáticas

Uma credencial estática não expira sozinha, não é rotacionada automaticamente e não se importa com quantas vezes é usada. Isso é o que a torna perigosa uma vez que está dentro de algo automatizado. Uma pessoa usando uma senha roubada acaba sendo notada. Um agente de IA ou script usando uma credencial roubada continua funcionando, na velocidade que o fluxo de trabalho permitir, até que alguém a encontre.

Passos para proteger as credenciais NHI

1. Abóbada

O primeiro passo é tirar as credenciais de scripts, arquivos de configuração, planilhas e código-fonte e colocá-las em um sistema criado para armazená-las. Isso parece simples e raramente é. Um cofre precisa funcionar em aplicações estratégicas e legadas, cobrir diferentes padrões de acesso dependendo de como cada aplicativo acessa uma credencial, e suportar tanto o onboarding centralizado quanto a realidade de que algumas equipes sempre adicionarão credenciais manualmente. Na prática, isso significa uma arquitetura em vários níveis: uma camada de apresentação para os usuários, um servidor de aplicação que aplica a lógica de negócios e permissões, e uma camada de banco de dados que realmente armazena os segredos, com a opção de escalar vários servidores de aplicação para distribuir a carga entre equipes geograficamente distribuídas. O vaulting também é a etapa que traz retorno mais rápido, pois é a diferença entre uma credencial que qualquer um pode encontrar e uma que é realmente controlada.

2. Criptografia

Uma vez que uma credencial está em um cofre, ela precisa permanecer criptografada, com as chaves de criptografia gerenciadas com o mesmo cuidado que as próprias credenciais. Isso significa mais do que simplesmente ativar o AES e considerar o trabalho concluído. Um cofre bem construído deve usar criptografia autenticada (AES-GCM 256) para as próprias credenciais, funções fortes de derivação de chave com alta contagem de iterações para hashing de usuários e chaves, e criptografia de curva elíptica para troca de chaves públicas e privadas. Cada contêiner secreto deve ter seu próprio sal gerado aleatoriamente, e cada senha, usuário e função deve ter seu próprio par de chaves, para que o acesso seja criptografado hierarquicamente em vez de protegido por uma única chave compartilhada. Para ambientes que sincronizam com o Active Directory, um modo de criptografia de ponta a ponta, onde o próprio servidor nunca tem acesso ao texto simples, deve estar disponível como a opção mais forte, junto com um modo de chave mestra para organizações que precisam de recuperação centralizada. A chave mestra deve estar no hardware, não em um arquivo de configuração, protegida por um HSM. Mover uma senha de texto simples para um cofre criptografado construído dessa forma é a maneira mais comum de as organizações reduzirem o risco de credenciais, e é o passo mais acessível para equipes que ainda não enfrentaram a segurança NHI.

3. Ciclismo e rotação

Rotacionar credenciais regularmente reduz o risco relacionado a funcionários que saíram, limpa a exposição presente em códigos e scripts antigos, e frequentemente revela dependências que ninguém sabia que existiam. Também é a etapa mais difícil de executar. Se você não conhece todos os scripts e integrações que dependem de uma determinada credencial, rotacioná-la pode quebrar a produção em vez de reduzir o risco.

A rotação funciona apenas como um processo contínuo e automatizado vinculado diretamente ao cofre que contém a credencial, e não como uma tarefa manual que alguém se lembra de fazer. Isso significa redefinições baseadas em gatilhos, não lembretes de calendário: redefinir uma credencial um número definido de minutos após ter sido visualizada, após permanecer inalterada por um número definido de dias, ou uma vez que tenha expirado. Também significa que o processo precisa se proteger. Se uma redefinição scriptada falhar no meio do caminho, em uma conta do Active Directory, um usuário local do Windows ou Linux, ou uma conta de serviço, o sistema deve reverter automaticamente a credencial para seu último valor conhecido e registrar a falha, em vez de deixar uma conta de serviço em um estado quebrado e parcialmente alterado. Cada redefinição, reversão e bloqueio é registrado, para que uma rotação falhada seja visível imediatamente em vez de surgir três semanas depois como uma interrupção que ninguém consegue explicar.

A maioria das organizações que fazem progresso real domina primeiro o armazenamento seguro e a criptografia, depois avançam para a rotação automatizada baseada em gatilhos, uma vez que entendem bem suas dependências para configurá-la com segurança.

Conheça o Password Secure

Cada conta de serviço e conta de aplicativo vinculada ao Active Directory passa pelo mesmo mecanismo de políticas que seus funcionários, esteja alguém aplicando ou não.Netwrix Password Secure cobre diretamente os três passos.

Ele oferece um único cofre criptografado para credenciais de usuário, administrador e serviço, com criptografia compatível com FIPS (AES-GCM 256, derivação de chave reforçada PBKDF2 e troca de chaves de curva elíptica NIST P-521) protegendo cada segredo. O acesso baseado em funções significa que apenas as pessoas e processos que precisam de uma credencial podem recuperá-la, e um registro completo documenta cada retirada, redefinição e reversão, para que você possa saber quem acessou uma determinada credencial e quando. Além disso, a redefinição de senha configurável e baseada em gatilho gerencia a rotação: as credenciais são redefinidas automaticamente em uma programação ou em uma condição definida, com proteção contra reversão se um sistema de destino rejeitar a alteração.

Essa é a diferença entre uma senha de conta de serviço que fica indefinidamente em uma planilha, nunca rotacionada porque ninguém quer arriscar quebrar algo, e uma senha que fica em um local onde é criptografada, controlada no acesso, registrada e rotacionada em um cronograma que a organização realmente controla.