Capítulo 13 — Identidade e acesso | Graduação Segurança de IA e aprendizado de máquina

Ensino gratuito e aberto para quem deseja proteger pessoas e tecnologias. Não é preciso criar uma conta para estudar ou consultar as respostas.

Mapa da aula

Aula 13 publicada. Mapa, exemplo, EX037.

flowchart TD
  N0["13.1 Autenticação, autorização, accounting"]
  N1["13.2 Acesso baseado em papéis e em atributos"]
  N2["13.3 Delegação para agentes de IA"]
  N3["13.4 Accounting das ações de IA"]
  N4["13.6b Revisão das permissões de agentes"]
  N5["Síntese"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5
  N5 --> EX["Exemplo resolvido"]
  EX --> Q["Exercício EX037"]

Desenho lógico

flowchart LR
  N0["13.1 Autenticação, autorização, accounting"]
  N1["13.2 Acesso baseado em papéis e em atributos"]
  N2["13.3 Delegação para agentes de IA"]
  N3["13.4 Accounting das ações de IA"]
  N4["13.6b Revisão das permissões de agentes"]
  N5["Síntese"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> Q["EX037"]

[13.1 Autenticação, autorização, accounting]
    |
    v
[13.2 Acesso baseado em papéis e em atributos]
    |
    v
[13.3 Delegação para agentes de IA]
    |
    v
[13.4 Accounting das ações de IA]
    |
    v
[13.6b Revisão das permissões de agentes]
    |
    v
[Síntese]
    |
    v
[Exemplo resolvido] --> [Exercício EX037]

Objetivos de aprendizagem

Você vai (1) explicar autenticação, autorização e registro de responsabilidade (accounting); (2) projetar acesso baseado em papéis e em atributos para aplicações de IA; (3) aplicar a delegação para que agentes de IA ajam com os direitos limitados do usuário; e (4) evitar problemas de confused deputy.

13.1 Autenticação, autorização, accounting

A autenticação prova quem alguém é; a autorização decide o que a pessoa pode fazer; o accounting registra o que ela fez. Uma autenticação forte (multifator) protege as contas; uma autorização precisa limita o dano; o accounting possibilita a investigação. No Ask Lumen, a autenticação é o login do paciente no portal da clínica; a autorização é a regra de que uma marcação só pode ser para esse paciente ou para alguém de quem ele é cuidador cadastrado; o accounting é o log que liga cada marcação à conversa e à sessão que a produziram. Uma fraqueza em qualquer um deles enfraquece os outros: logs perfeitos não ajudam se a ferramenta de agendamento nunca verificou quem estava pedindo.

13.2 Acesso baseado em papéis e em atributos

Papéis (paciente, recepcionista, clínico) agrupam permissões. Atributos (clínica, relação com o paciente, horário) as refinam. A ferramenta de agendamento do Ask Lumen deve verificar "quem pede é o paciente ou seu cuidador cadastrado, para esta clínica?", e não "o serviço do chatbot tem permissão para marcar?". A segunda pergunta é a errada porque o serviço do chatbot sempre tem permissão; fazê-la transforma os direitos amplos do serviço em direitos de todo mundo. Atributos como a clínica e a relação de cuidador permitem que a regra acompanhe situações reais sem criar um papel novo para cada uma.

13.3 Delegação para agentes de IA

Quando um agente de IA age, ele deve usar um token delegado pelo usuário, com escopo e validade limitados, para que nunca possa fazer mais do que esse usuário. Uma conta de serviço poderosa transforma qualquer manipulação do modelo numa escalada de privilégios — o problema do confused deputy, em que um componente confiável é enganado e usa mal sua autoridade. Um token delegado carrega a identidade do paciente, então o sistema de agendamento pode aplicar diretamente os direitos do paciente. Sua validade curta limita o dano se ele vazar por um log ou por uma chamada de ferramenta manipulada.

13.4 Accounting das ações de IA

Registre qual usuário, qual conversa, qual proposta do modelo e qual aprovação levaram a cada ação. Sem essa cadeia, os incidentes não podem ser explicados. A cadeia de uma marcação poderia ser: sessão do paciente 7f2, conversa c-118, proposta do modelo às 10:14:03 para marcar na clínica C3 numa certa data, verificação de política aprovada, paciente confirmou às 10:14:20, identificador da marcação gravado. Se um paciente contestar uma marcação mais tarde, cada passo pode ser mostrado. Se o modelo propôs algo que a política bloqueou, isso também fica registrado, o que ajuda a detectar tentativas de manipulação.

13.5 Exemplo resolvido (caso sintético da LCH)

O Ask Lumen marcava consultas por meio de uma conta de serviço autorizada a marcar para qualquer paciente. Rina mostrou, no ambiente de teste, que uma mensagem elaborada com o identificador de outro paciente sintético levava o modelo a propor uma marcação para esse paciente, que a conta de serviço executava. A correção usou um token delegado por sessão, vinculado ao paciente conectado (e aos cuidadores cadastrados), e uma verificação de política que compara o paciente da marcação com o titular do token. O teste mostra o confused deputy diretamente: o modelo não fez nada de errado segundo sua própria lógica, e a conta de serviço fez o que tinha permissão para fazer.

13.6 Erros e limites

Três erros são comuns: ferramentas de IA rodando sob contas de serviço amplas; autorização decidida pelo modelo; e falta, nos logs, de ligação entre conversas e ações. Contas de serviço amplas fazem de toda injeção de prompt uma possível escalada de privilégios, como mostrou o exemplo resolvido. Deixar o modelo decidir a autorização coloca a regra onde um texto pode discutir com ela. A falta de ligação entre conversas e ações deixa os investigadores sem conseguir dizer qual mensagem causou qual marcação. Tokens delegados, uma verificação de política externa e identificadores de requisição tratam os três, um a um.

13.6b Revisão das permissões de agentes

A cada trimestre, a LCH lista o que a ferramenta de agendamento do Ask Lumen realmente pode fazer e compara com aquilo de que o chatbot precisa. Uma revisão descobriu que a conta da ferramenta também podia editar as agendas dos clínicos; esse direito foi removido, e o registro da revisão anota quem aprovou as permissões restantes. As permissões tendem a crescer à medida que funcionalidades são acrescentadas, e ninguém as remove a menos que uma revisão o peça. O direito de editar agendas havia sido acrescentado para um piloto já encerrado, e ninguém tinha notado que continuava concedido.

Exercícios

EX037 — AAA. Defina autenticação, autorização e accounting com um exemplo do Ask Lumen para cada. Rubrica: 3 = três corretas com exemplos; 2 = duas; 1 = uma; 0 = nenhuma.
EX038 — Confused deputy. Explique o problema do confused deputy usando o achado de Rina. Rubrica: 3 = conta de serviço confiável usada indevidamente por meio de um modelo manipulado; 2 = parcial; 1 = vago; 0 = errado.
EX039 — Política. Escreva a verificação de política para marcações. Rubrica: 3 = booking.patient ∈ {token.subject} ∪ carers(token.subject) e clínica permitida; 2 = parcial; 1 = vago; 0 = nenhuma.

Síntese

Os controles de identidade decidem o que um agente de IA pode fazer e em nome de quem. Tokens delegados com escopo e verificações de política externas impedem que o modelo se torne um confused deputy.

Continue estudando — capítulo 13 de 40

← Capítulo 12 (rascunho) · Índice de capítulos do curso · Capítulo 14 (rascunho) →