A inteligência artificial está se movendo para a empresa mais rápido do que quase qualquer tecnologia que já vimos antes.
Os funcionários estão usando IA generativa para escrever código, resumir documentos, analisar informações, desenvolver conteúdo de marketing, automatizar fluxos de trabalho e melhorar a produtividade. As organizações estão incorporando simultaneamente modelos de IA em aplicativos, plataformas em nuvem, serviços voltados para o cliente e processos de negócios internos.
A oportunidade é enorme.
Assim é o desafio da segurança.
Uma recente Melhores Práticas de Segurança GenAI O guia da Wiz deixa o desafio claro: as equipes de segurança precisam entender não apenas os aspectos técnicos da inteligência artificial, mas também o cenário mais amplo de segurança da IA, ganhar visibilidade sobre como a IA está sendo usada em toda a organização e estabelecer processos capazes de detectar e responder a ameaças relacionadas à IA.
O documento identifica quatro objetivos importantes:
Visibilidade. Zero riscos críticos. Democratização. Prevenção.
Esses princípios fornecem uma excelente base para garantir a IA corporativa.
Mas à medida que as organizações as implementam, outra questão surge rapidamente:
Quem, o que, É permitido acessar a IA em primeiro lugar?
Porque se estamos protegendo um modelo de IA generativo, seus dados de treinamento, um API, um ambiente de nuvem ou os sistemas administrativos que o cercam, praticamente todos os controles de segurança acabam encontrando o mesmo problema fundamental:
Identidade.
IA gera novos riscos de segurança
GenAI é diferente do software empresarial convencional.
Os sistemas gerativos ingerem enormes quantidades de informações não estruturadas – texto, imagens, áudio, código, documentos, prompts e outros dados – e produzem novos conteúdos com base nessas entradas.
Essa flexibilidade é precisamente o que torna a GenAI útil.
Também é parte do que torna a segurança complicada.
O guia Wiz destaca várias ameaças importantes que as organizações devem considerar, incluindo:
Envenenamento de dados manipular deliberadamente dados de treinamento para influenciar a saída de um modelo de IA.
Modelo de roubo acesso não autorizado e duplicação de modelos proprietários.
Ataques Adversarial - entradas especialmente criadas destinadas a causar comportamento de modelo incorreto, enganoso ou prejudicial.
Ataques de inversão de modelo ⁇ consultas destinadas a extrair informações sensíveis de dados de treinamento.
Vulnerabilidades na cadeia de suprimentos Explorar dependências de software de terceiros ou outros componentes no ecossistema de IA.
Essas ameaças são diferentes tecnicamente.
Mas muitos, em última análise envolvem algo familiar:
Acesso não autorizado.
Quem pode acessar o modelo?
Quem pode acessar seus dados?
Quem pode modificá-lo?
Quem pode treiná-lo?
Quem pode implantá-lo?
Quem pode chamar suas APIs?
Quem tem privilégios administrativos?
E o mais importante:
Quão certos somos de que a pessoa que solicita esse acesso é realmente quem eles afirmam ser?
A IA pode estar transformando a computação, mas não eliminou um dos problemas mais antigos da segurança cibernética.
Você ainda tem que estabelecer confiança.
1. Eliminar Shadow AI
A primeira prática de segurança identificada no documento Wiz está eliminando sombra AI.
As organizações não podem garantir tecnologias que não sabem que os funcionários estão usando.
O problema deve soar familiar.
Já experimentamos anteriormente: Sombra-o.
Então: Nuvem de sombra.
Agora temos: Inteligência Artificial Sombra.
Os funcionários podem criar contas com provedores de IA, instalar aplicativos habilitados para IA, conectar serviços a informações corporativas e começar a usar ferramentas de IA generativas sem necessariamente envolver segurança ou TI.
O guia Wiz recomenda desenvolver um AI-BOM – ou AI Bill of Materials – para inventariar ativos relacionados à IAEstabelecer controles sobre provedores GenAI aprovados e proibidos e educar os funcionários sobre o uso aceitável de IA.
Esse é um ponto de partida forte.
Mas a visibilidade deve eventualmente ser acompanhada por identidade.
Depois de identificar um aplicativo de IA autorizado, a próxima pergunta é:
Quem deve ser autorizado a usá-lo?
2. Proteja a IA de alimentação de dados
A segunda recomendação pode ser uma das mais importantes:
Proteja seus dados.
Os sistemas de IA podem interagir com enormes quantidades de informações, incluindo potencialmente:
Informações do cliente
Propriedade intelectual
Informações financeiras
Código fonte
Informações de saúde
Registros de funcionários
Pesquisa proprietária
Contratos
Estratégias de negócios
Informações pessoalmente identificáveis
O documento Wiz recomenda descobrir e classificar dados de acordo com a sensibilidade, criptografar informações em repouso e em trânsito, higienizar dados, implementar políticas de prevenção de perda de dados e auditar quem pode acessar informações específicas.
Esse último ponto merece atenção especial:
Auditoria quem tem acesso.
Porque a criptografia pode proteger os dados.
DLP pode ajudar a evitar movimentos inadequados de dados.
A classificação pode identificar informações confidenciais.
Mas, eventualmente, o sistema ainda tem que tomar uma decisão:
Essa identidade deve ser permitida para acessar esse recurso?
E se a identidade foi comprometida, a política de controle de acesso pode funcionar perfeitamente, permitindo que a pessoa errada passe.
3. Acesso seguro aos modelos GenAI
A terceira recomendação traz identidade diretamente para a conversa:
Acesso seguro aos modelos GenAI.
O documento identifica especificamente uma Gerenciamento de Identidade e Acesso (IAM) como pré-requisito para a configuração de ativos associados a implantações da GenAI e recomenda controle de acesso baseado em funções.
Também recomenda controles como:
Autenticação para o uso do API
Limitação da taxa
Acesso restrito a pesos-modelo
Limitar quem pode iniciar o treinamento
Limitando quem pode iniciar pipelines de implantação
Monitorização de permissões excessivas
Seguindo o princípio do privilégio mínimo
É exatamente aqui que a conversa de segurança da IA e a conversa de autenticação se cruzam.
Você pode estabelecer permissões perfeitas.
Mas as permissões só funcionam se a identidade que recebe essas permissões puder ser confiável.
Considere um administrador autorizado a implantar um modelo de IA.
O sistema de controle de acesso diz:
Esta conta tem permissão.
Mas a segurança cibernética precisa responder a outra pergunta:
A pessoa que usa essa conta é realmente o administrador autorizado?
Essas são duas perguntas muito diferentes.
AI torna identidades comprometidas mais perigosas
É aqui que as organizações devem pensar além do IAM convencional.
Suponha que um atacante roube as credenciais de alguém autorizado a:
Modelos de IA proprietários de acesso
Modificar dados de treinamento
Implantar modelos
Guardrails de mudança
Acesso a conjuntos de dados sensíveis
Recuperar credenciais API
Modificar a infraestrutura de IA
Do ponto de vista do aplicativo, a conta pode ser autorizada.
Do ponto de vista da organização, o usuário não é.
Autorização sem autenticação forte pode tornar-se o acesso autorizado para uma pessoa não autorizada.
E à medida que os sistemas de IA ganham acesso a informações empresariais mais valiosas e capacidades de negócios cada vez mais poderosas, as identidades comprometidas podem potencialmente ter um raio de explosão muito maior.
4. Use Guardrails LLM incorporados
A quarta prática é implementar as capacidades de segurança disponíveis dentro dos próprios modelos GenAI.
Dependendo do fornecedor e do modelo, esses controles podem incluir:
Filtragem de conteúdo para remover ou sinalizar conteúdo inadequado ou prejudicial.
Detecção de abuso para identificar o potencial uso indevido do modelo.
Controles de configuração do modelo Isso afeta a previsibilidade com que o modelo responde.
Esses controles são importantes porque a segurança deve ser em camadas.
Mas guardrails não deve se tornar outro exemplo de confiança equivocada.
Uma organização pode ter excelentes guardrails protegendo os usuários comuns, proporcionando aos administradores a capacidade de modificar esses guardrails.
O que leva de volta à identidade:
Quem está autorizado a alterar os controles de segurança?
E:
Quão fortemente os autenticamos antes de permitir essa mudança?
5. Detecte e elimine caminhos de ataque de IA
A quinta recomendação é análise de caminho de ataque.
Em vez de olhar para vulnerabilidades individuais isoladamente, as organizações devem examinar como múltiplas fraquezas podem ser acorrentadas.
O guia Wiz recomenda procurar por:
vulnerabilidades do modelo de IA
Patches em falta
Modelos maliciosos
Configurações incorretas da IA
Permissões excessivas
Exposição à rede
Segredos expostos
Dados sensíveis
Controles de acesso fracos
O objetivo é entender como um atacante pode se mover através do ambiente e alcançar um recurso crítico de IA.
O diagrama na página 5 ilustra este conceito particularmente bem: um sistema exposto à internet pode potencialmente se tornar o início de um caminho que leva a um recurso de treinamento de IA de alto valor.
Esta é uma mudança importante no pensamento de segurança.
Não pergunte apenas:
"Esta vulnerabilidade é perigosa?"
Perguntar:
"O que um atacante poderia alcançar se o explorasse?"
Devemos aplicar exatamente o mesmo pensamento à identidade.
Não pergunte apenas:
"Este usuário foi autenticado?"
Perguntar:
"O que essa identidade autenticada pode alcançar?"
6. Monitor para Anomalias
A sexta recomendação é o monitoramento contínuo.
O documento recomenda observar ambientes de IA para comportamentos incomuns de entrada e saída, atividade suspeita de pipeline de IA, mudanças inesperadas de latência e outras anomalias.
O objetivo é a detecção precoce.
Porque a prevenção nunca será perfeita.
Se algo incomum acontecer, as equipes de segurança precisam identificá-lo com rapidez suficiente para conter o raio de explosão.
A telemetria de identidade deve fazer parte dessa mesma filosofia.
Por exemplo:
Por que esse usuário está acessando de repente um sistema sensível?
Por que uma identidade administrativa se comporta de maneira diferente?
Por que os pedidos de autenticação repetidos estão ocorrendo?
Por que o acesso vem de um dispositivo inesperado?
Por que uma conta que solicita recursos normalmente não usa?
A autenticação não deve existir como uma porta isolada para o aplicativo.
A identidade deve tornar-se parte do contexto de segurança em torno de toda a transação.
7. Tenha um plano de resposta a incidentes de IA antes de precisar
A recomendação final do Wiz é algo que as organizações às vezes adiam até que seja tarde demais:
Resposta a incidentes.
A resposta a incidentes específicos de IA pode exigir isolamento, backups, controle de tráfego, procedimentos de reversão, integração com plataformas SecOps existentes e um plano de resposta a incidentes focado em IA.
A palavra-chave é antes.
O pior momento para decidir o que fazer durante um incidente de segurança de IA é enquanto o incidente está acontecendo.
As organizações devem saber com antecedência:
Quem pode desativar um sistema de IA?
Quem pode revogar o acesso?
Quem pode modificar modelos?
Quem pode restaurar dados?
Quem pode iniciar procedimentos de reversão?
Quem pode mudar as políticas de segurança?
E outra vez:
Como vamos autenticar essas pessoas com segurança durante um incidente?
Uma conta de administrador comprometida durante um incidente pode piorar significativamente uma situação ruim.
The Missing Layer: Autenticação Forte
O documento Wiz fornece uma excelente estrutura para a segurança da GenAI.
Suas recomendações repetidamente se cruzam com:
IAM
Controlos de acesso
Permissões
Menor privilégio
Autenticação API
Acesso a dados
Autoridade administrativa
Isso leva a uma conclusão que toda organização que implanta AI deve considerar:
A segurança da IA depende, em parte, da segurança da identidade.
Você pode saber exatamente onde estão seus modelos de IA.
Você pode classificar os dados.
Você pode estabelecer políticas RBAC perfeitas.
Você pode monitorar a infraestrutura.
Você pode identificar caminhos de ataque.
Você pode estabelecer um programa de resposta a incidentes.
Mas se um atacante pode se passar por alguém autorizado a acessar esses recursos, muitas dessas defesas se tornam consideravelmente menos eficazes.
Senhas são uma fundação fraca para a era da IA
Isso cria uma contradição interessante.
Estamos construindo alguns dos sistemas de computação mais sofisticados já criados.
E muitas organizações ainda protegem o acesso a elas com tecnologia desenvolvida décadas atrás:
A senha.
As senhas podem ser:
Phished
Roubado
Reutilizado
Compartilhado
Adivinha
Keylogged
Expostos em violações
Comprado em mercados criminosos
O MFA tradicional melhora consideravelmente a situação.
Mas dependendo da implementação, os atacantes ainda podem tentar:
fadiga MFA
Push bombardeio
Engenharia social
phishing Adversary-in-the-middle
Sites de autenticação semelhantes
roubo de credenciais e sessões
A era da IA merece uma arquitetura de autenticação projetada para o ambiente de ameaças de hoje.
Autenticação sem senha altera a equação
Em vez de cercar senhas com mais defesas, as organizações podem eliminar a dependência de senhas reutilizáveis.
Uma arquitetura de autenticação sem senha pode usar:
Algo que você tem:
Um dispositivo confiável.
combinado com:
Algo que você é:
Uma biometria verificada localmente.
Isso pode fornecer vários fatores de autenticação sem exigir uma senha reutilizável.
Para os funcionários, a experiência pode se tornar mais simples.
Para os atacantes, não há nenhuma senha convencional disponível para roubar através de phishing de credenciais tradicionais.
Mas remover a senha é apenas parte da resposta.
Autenticação Assuntos Intent
Os sistemas de IA podem realizar ações cada vez mais conseq ⁇ entes.
Isso torna importante saber não só que autenticado, mas se o usuário legítimo realmente pretendia iniciar a autenticação.
Identité pode fornecer informações contextuais durante a autenticação na mesma tela.
Por exemplo, o usuário pode ser explicitamente perguntado:
"Você solicitou esta sessão de autenticação?"
A tela também pode apresentar um imagem e número de verificação de três dígitos associada à interação de autenticação.
A distinção é importante.
Um pedido genérico de MFA pergunta essencialmente:
"Aprovar?"
Uma experiência de autenticação contextual pode perguntar:
“Você iniciou isso?”
Essa é a diferença entre apenas pedir aprovação e ajudar a estabelecer intenção.
Mas a segurança da IA levanta outra questão de autenticação
Suponhamos que estabeleçamos que a pessoa que acessa o ambiente de IA é legítima.
Ainda há outro lado da transação.
O sistema ao qual eles estão se conectando é legítimo?
Os atacantes não apenas personificam os usuários.
Eles personificam:
sites corporativos
Aplicações em nuvem
Portais de autenticação
Serviços SaaS
Bancos
Portais de saúde
Microsoft 365
Aplicações internas de negócios
Com a IA cada vez mais ajudando os invasores na geração de conteúdo convincente, destinos fraudulentos podem se tornar ainda mais difíceis para os usuários comuns reconhecerem.
Uma cópia perfeita de uma tela de login ainda é uma tela de login falsa.
Então, por que a autenticação deve ocorrer apenas em uma direção?
Full Duplex Authentication®: Ambos os lados estabelecem confiança
Este é o princípio por trás do Identité patenteado Full Duplex Authentication® (FDA).
A autenticação tradicional pergunta: "Você é o usuário legítimo?"
Full Duplex Authentication® adiciona: "Este é o destino legítimo?"
Ambos os lados participam do estabelecimento da confiança.
Isso é Auten autenticação mútua.
Isso se torna particularmente relevante para a segurança da IA porque os sistemas de IA estão cada vez mais atrás de APIs, portais, serviços em nuvem, consoles administrativos e aplicativos corporativos.
Um destino fraudulento pode imitar a aparência de um serviço legítimo.
Mas aparência não é identidade.
A autenticação deve estabelecer legitimidade em vez de confiar no usuário para reconhecê-la visualmente.
Biometria descentralizada também importa
Quando a biometria é usada, as organizações também devem perguntar:
Onde estão armazenadas as informações biométricas?
Identité utiliza a Arquitetura descentralizada em que a verificação biométrica ocorre no dispositivo do usuário confiável.
A biometria não precisa ser transmitida para o Identité ou colocada em um repositório biométrico centralizado do Identité para correspondência.
Os dados biométricos do usuário permanecem no dispositivo do usuário.
Isso é particularmente relevante à medida que as organizações se tornam cada vez mais preocupadas com repositórios centralizados de informações de identidade altamente sensíveis.
As senhas podem ser alteradas após um compromisso.
Sua impressão digital não pode.
A arquitetura importa.
PasswordFree® para autenticação SaaS
Identité PasswordFree® é a nossa solução de autenticação sem senha SaaS.
PasswordFree® é projetado em torno de capacidades, incluindo:
Autenticação sem senha
Full Duplex Authentication® patenteado
Autenticação mútua
Autenticação de dispositivo confiável
Verificação biométrica descentralizada
Autenticação contextual
Intenção de autenticação
Autenticação de PIN de emergência
Backup e restauração seguros
Opções de autenticação de terceiros compatíveis
Para organizações que criam ou implantam aplicativos de nuvem e SaaS – incluindo aplicativos habilitados para IA – o objetivo é direto:
Reduza a dependência de senha enquanto aumenta a confiança na relação de autenticação.
NoPass™ para ambientes de AI corporativos
Para empresas que exigem integração mais profunda e maior controle de infraestrutura, a Identité oferece NoPass™, nossa solução PaaS alimentada por Full Duplex Authentication® patenteado.
NoPass™ pode ser implantado na nuvem ou no local e pode apoiar ambientes empresariais que envolvam:
Microsoft Active Directory
ID de entrada Microsoft
Microsoft 365 / Escritório 365
Microsoft Azure
Essa flexibilidade de implantação pode ser especialmente importante para:
instituições financeiras
Organizações de saúde
Governo
Infraestrutura crítica
Empresas altamente regulamentadas
As organizações que relutam em colocar infraestrutura de autenticação sensível ou informações na nuvem podem manter maior controle por meio de uma Implantação local do NoPass™.
A segurança da IA precisa de confiança zero e premissas zero
Uma das lições mais fortes do documento Wiz é que a segurança da IA não pode depender de um único controle.
As organizações precisam:
Visibilidade.
Proteção de dados.
Controle de acesso.
Guardas-costas.
Análise de ataque-caminho.
Monitorização.
Resposta a incidentes.
E eu acrescentaria mais um:
Autenticação de identidade forte.
O princípio da segurança deve ser simples:
Nunca assuma a identidade simplesmente porque as credenciais foram apresentadas.
Estabeleça-o.
E não assuma que o destino é legítimo simplesmente porque parece legítimo.
Autenticar isso também.
Sete perguntas de segurança de IA que toda organização deve fazer
⁇ medida que as organizações implementam a GenAI, as equipes de liderança e segurança devem ser capazes de responder a estas perguntas:
Conhecemos todos os sistemas de IA utilizados dentro da nossa organização?
Sabemos que informações sensíveis esses sistemas podem acessar?
Sabemos quem tem acesso aos nossos modelos, dados, APIs e pipelines de treinamento?
Essas permissões são baseadas no menor privilégio?
Podemos detectar comportamentos anormais e possíveis caminhos de ataque?
Temos uma estratégia de resposta a incidentes específica da IA?
Estamos certos de que a pessoa que acessa nossos recursos de IA – e o destino que recebe a autenticação – são ambos legítimos?
Essa sétima pergunta conecta a segurança da IA com a segurança da identidade.
E isso se tornará cada vez mais importante à medida que os sistemas de IA se tornarem mais poderosos.
A perspectiva Identité
A inteligência artificial pode mudar quase tudo sobre como as empresas usam a tecnologia.
Isso não muda o requisito fundamental para a confiança.
Os modelos de IA precisam de proteção.
Dados de treinamento precisam de proteção.
APIs precisam de proteção.
Os consoles administrativos precisam de proteção.
Os ambientes de nuvem precisam de proteção.
E as identidades autorizadas para acessar todas elas precisam de proteção.
O guia Wiz conclui que as organizações precisam de um abordagem proativa e ágil para a segurança GenAI capaz de acompanhar a velocidade com que a IA está sendo desenvolvida e adotada.
Concordo.
Mas à medida que as organizações constroem essa estratégia, a identidade não pode se tornar uma reflexão tardia.
Com Identité:
A biometria pode ajudar a estabelecer:
"Eu sou o usuário autorizado."
O dispositivo de confiança participa no estabelecimento de:
"Este é o dispositivo autorizado."
A autenticação contextual pode perguntar:
"Eu iniciei esta sessão de autenticação?"
A imagem e o número de três dígitos fornecem contexto de autenticação adicional.
E patenteado Full Duplex Authentication® Endereços:
"Este é o destino legítimo?"
O resultado é uma relação de confiança mais ampla construída em torno de:
Identidade + Dispositivo + Intent + Contexto + Destino
A IA está mudando rapidamente o que a tecnologia pode fazer.
A segurança tem que evoluir com isso.
Porque quanto mais poderosos nossos sistemas se tornam, mais importante uma pergunta se torna:
Em Quem Confiamos… e como sabemos?