Controle de acesso, gerenciamento de identidade e segredos

Ganhos:

• Capacidade de separar autenticação e autorização e aplicar autorização mínima com RBAC/ABAC
• Capacidade de evitar risco de proxy misto executando o modelo no contexto do usuário
• Capacidade de armazenar e alternar chaves de API com o sistema de gerenciamento de segredos

Uma parte significativa dos ataques a um sistema de IA não começa com “enganar” o modelo, mas com uma chave de API roubada ou uma conta excessivamente autorizada. Essa camada de segurança vem da segurança da informação clássica, mas acrescenta novos riscos no contexto da IA: um modelo pede carona em nome de outra pessoa, uma conta de serviço acessa todos os dados, uma chave vaza para o GitHub. Nesta unidade aprenderemos como restringir o acesso ao sistema de IA com autenticação, autorização (RBAC/ABAC), autorização mínima e gerenciamento de segredos.

Diferença entre autenticação e autorização

Os dois termos são frequentemente confundidos:

• Autenticação: "Quem é você?" — provar que o usuário/serviço é realmente quem afirma ser (senha, token, certificado, MFA).
• Autorização: "O que você pode fazer?" — determine qual recurso/ação a parte autenticada pode acessar.

A sutileza crítica nos sistemas de IA é esta: quando o modelo executa trabalho em nome de um usuário, ele opera com a autoridade desse usuário ou com uma conta de serviço ampla? Este último é perigoso – porque o modelo enganado pela injeção ganha acesso total à conta do serviço.

Cuidado: Problema de "deputado confuso": um usuário de baixa autoridade acessa indiretamente dados que não pode acessar terceirizando um modelo de alta autoridade. O modelo deve sempre operar dentro do contexto da autoridade do usuário, e não de sua própria autoridade ampla.

RBAC e ABAC

• RBAC (Role-Based Access Control): O acesso depende da função do usuário. A função "especialista de suporte" pode ler notas de clientes, mas não pode excluí-las. Simples e comum.
• ABAC (Controle de Acesso Baseado em Atributos): O acesso depende de atributos: o departamento do usuário, o rótulo de privacidade dos dados, a hora do dia, a rede de onde vem a solicitação. Mais afinado, mas mais complexo.

A maioria das organizações começa com o RBAC e se aprofunda no ABAC para dados confidenciais. Regra geral para IA: o modelo deve filtrar cada agente que chama e todos os dados que acessa com base na função/atributos do usuário que faz a solicitação.

Passo a passo: exercendo autoridade mínima

1. Faça um inventário. Quais ferramentas o modelo chama, quais dados ele acessa? Liste todos eles.
2. Justifique cada acesso. “Este assistente realmente precisa de autoridade de exclusão?” Caso contrário, remova-o.
3. Padrão somente leitura. O modelo deve ser capaz de ler por padrão; Exigir gravação/exclusão de token separado e de escopo restrito.
4. Mova o contexto do usuário. Ligue para o veículo com a autoridade do usuário, não com a conta de serviço.
5. Credencial de curta duração. Use tokens de curta duração e com renovação automática em vez de chaves de longa duração.

Gerenciamento Secreto

Um segredo são credenciais que devem permanecer secretas, como uma chave de API, senha, token ou certificado. O acidente mais comum em projetos de IA é quando a chave API do fornecedor do modelo é incorporada no código e vaza para o controle de versão (Git).

Aplicação correta:

• Nunca incorpore chaves no código; Use uma variável de ambiente ou um sistema de gerenciamento de segredos (um serviço que armazena chaves criptografadas e controla o acesso).
• Rotação: Renove as chaves em intervalos regulares (por exemplo, a cada 90 dias); Se houver suspeita de vazamento, cancele imediatamente.
• Redução de escopo: Cada switch possui apenas o serviço e a autorização necessários.
• Auditoria: registre quem usou a chave, quando e onde.

Quatro modelos copiáveis

Prompt de controle de revisão de acesso:

Para cada ferramenta na lista de ferramentas abaixo, avalie: - Esta ferramenta é NECESSÁRIA para realizar o trabalho deste assistente? (sim/não) - É somente leitura ou gravação/apagamento? - Esta ferramenta é chamada com a autoridade ou conta de serviço do usuário? Marque aqueles desnecessários ou excessivamente autorizados como "REMOVER/REDACT".<tools>{{ tool_list }}</tools>

Solicitação de verificação de vazamento secreto:

Encontre qualquer coisa que possa ser um segredo codificado no seguinte trecho de código: chave de API, senha, token, cadeia de conexão, chave privada. Forneça linha e tipo para cada um. COPIE o valor em resposta;máscara (primeiros 4 caracteres + ***).<code>{{ source }}</code>

Regra de decisão de menor autoridade:

Quando uma nova solicitação de ferramenta/acesso chegar, pergunte:1. A tarefa pode ser executada sem esse acesso? -> Se sim: REJECT2. Somente leitura é suficiente? -> Se sim: GRANT permissão de gravação3. O escopo pode ser reduzido a uma única fonte? -> Se sim: daratA ​​resposta padrão é "não"; O acesso é obtido pela razão.

Lembrete do calendário de rotação:

Para cada segredo, registre: proprietário, data de criação, expiração, escopo. Relate qualquer chave que tenha ultrapassado 90 dias ou não tenha sido usada por 30 dias como “CANDIDATO DE ROTAÇÃO/CANCELAMENTO”.

Alerta Fraco/Prompt Forte

abordagem pobre

Abordagem forte

O modelo acessa todos os dados com uma única conta de serviço

O modelo acessa com a autoridade do usuário que faz a solicitação

A chave da API está incorporada no código e nunca muda

Rotação no gerenciador de segredos de chave, 90 dias

Ampla autoridade de "fazer qualquer coisa" para o assistente

Padrão somente leitura, gravação restrita

Os acessos nunca são revisados

Revisão e revogação regulares de acesso

Três Mini Estojos

Caso 1 — Vazamento de dados de proxy misto. Um assistente interno trabalhava com uma conta de serviço que tinha acesso a todos os registros dos funcionários. Um usuário estagiário acessou dados que normalmente não veria dizendo “resuma a tabela salarial dos executivos”; porque o modelo o questionou no contexto de sua própria autoridade ampla, não do usuário. Depois que o contexto do usuário foi ajustado para ser movido, o estagiário conseguiu extrair gravações que somente ele poderia ver.

Caso 2 — Chave vazada, nota de 190.000 TL em 2 semanas. Um desenvolvedor incorporou a chave de API do modelo em um script auxiliar e a enviou para um repositório público. Um bot encontrou a chave em 40 minutos e a usou por duas semanas; A conta atingiu 190.000 TL. Quando a chave foi movida para o gerenciador de segredos, conectada à rotação e a verificação do repositório foi adicionada, o incidente não ocorreu novamente.

Caso 3 — Interrupção evitada por padrão somente leitura. Um assistente DevOps recebeu um comando “redefinir banco de dados de produção” por meio de injeção imediata. No entanto, o assistente recebeu apenas um token somente leitura; gravar/apagar estava em um fluxo aprovado separado. O comando foi rejeitado com erro de autorização e o evento foi registrado como alarme; Não houve perda de dados.

Dica: Faça do “não” sua resposta padrão para uma nova solicitação de acesso. O acesso é algo obtido através da justificação; Dar largura a todos e depois cortar quase nunca é feito e o risco se acumula.

Erros comuns

• Executando o modelo com uma conta de serviço grande e perdendo o contexto do usuário (proxy misto).
• Incorporar a chave de API no código e vazá-la para o controle de versão.
• Não girar as teclas ("trabalhando, não toque").
• Conceder permissões de gravação/exclusão ao assistente por padrão.
• Conceder acesso uma vez e nunca reconsiderá-lo.
• Confundir autenticação com autorização e presumir que “ele está logado, pode acessar tudo”.

Em resumo

• A autenticação é uma questão de “quem é você”, a autorização é uma questão de “o que você pode fazer”; Na IA, ambos devem operar no contexto do usuário.
• O modelo deve operar com a autoridade do usuário que faz a solicitação, e não com a sua própria autoridade ampla (evitando o risco de agência mista).
• Comece com RBAC, aprofunde-se com ABAC em dados sensíveis; Torne a autoridade mínima o padrão.
• Não enterre segredos em código; armazene-o no gerenciador secreto, restrinja-o e coloque-o em rotação regular.
• O padrão somente leitura e a gravação restrita limitam bastante o impacto da injeção.

Tarefa de aplicativo

Liste todas as ferramentas e dados que seu assistente de IA acessa. Responda três perguntas para cada: (1) É realmente necessário? (2) Somente leitura é suficiente? (3) Ele é executado no contexto do usuário? Em seguida, pesquise todos os segredos codificados (por meio do prompt de verificação acima) e escreva um plano de rotação para cada chave encontrada. Remova pelo menos uma autorização desnecessária.

lista de verificação

• [] O modelo é executado no contexto de autoridade do usuário que faz a solicitação.
• [] O acesso a ferramentas e dados foi reduzido ao princípio do menor privilégio.
• [] Gravar/apagar é separado de somente leitura, autenticado e restrito.
• [] Nenhum segredo está enterrado no código; Ele é mantido no gerenciador secreto.
• [ ] Existe um cronograma de rodízio e procedimento de cancelamento de chaves.
• [ ] Os acessos são revisados ​​regularmente.