◇ OpenCyber Academy
Técnico · Capítulo 1 · Português

Capítulo 1 — Computação e arquitetura de serviços

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

Capítulo 1 — Computação e arquitetura de serviços

Mapa da aula

Aula 01 publicada. Mapa, exemplo, EX001.

flowchart TD
  N0["1.1 Componentes"]
  N1["1.2 Acompanhando uma requisição"]
  N2["1.3 Dados e segredos"]
  N3["1.4 Controles que os técnicos configuram"]
  N4["Síntese"]
  N0 --> N1 --> N2 --> N3 --> N4
  N4 --> EX["Exemplo resolvido"]
  EX --> Q["Exercício EX001"]

Desenho lógico

flowchart LR
  N0["1.1 Componentes"]
  N1["1.2 Acompanhando uma requisição"]
  N2["1.3 Dados e segredos"]
  N3["1.4 Controles que os técnicos configuram"]
  N4["Síntese"]
  N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX001"]

[1.1 Componentes]
    |
    v
[1.2 Acompanhando uma requisição]
    |
    v
[1.3 Dados e segredos]
    |
    v
[1.4 Controles que os técnicos configuram]
    |
    v
[Síntese]
    |
    v
[Exemplo resolvido] --> [Exercício EX001]

Objetivos de aprendizagem

Você vai (1) nomear os componentes de um serviço com IA; (2) acompanhar uma requisição através deles; (3) identificar onde ficam os dados e os segredos; (4) localizar os controles que um técnico configura.

1.1 Componentes

Um serviço de suporte com IA tem: uma interface com o cliente (chat na web, aplicativo); um servidor de aplicação; um orquestrador que monta os prompts e chama o modelo; um modelo, normalmente acessado pela API de um fornecedor; um serviço de recuperação com um índice de artigos de ajuda; serviços de ferramentas (chamados, gerenciamento de roteadores); bancos de dados; registro de eventos; e monitoramento. Cada um roda em servidores ou contêineres que os técnicos instalam, atualizam e configuram. O inventário do HelpBot feito por Ana contou onze desses componentes, e essa contagem importa para a aplicação de correções. A interface, o gateway, o orquestrador, o serviço de recuperação com seu índice, a ferramenta de chamados, o serviço de gerenciamento de roteadores, o banco de dados de contas, o cofre de segredos, o registro de eventos, o monitoramento e a API do modelo do fornecedor têm, cada um, um responsável e um ciclo de atualização diferentes. Só o último é atualizado por alguém de fora da Kestrel, e é por isso que a versão do modelo do fornecedor precisou, mais tarde, ser acrescentada à mão à lista de materiais.

1.2 Acompanhando uma requisição

Um cliente escreve "minha internet caiu". O aplicativo autentica o cliente, o orquestrador recupera os artigos de ajuda pertinentes, monta um prompt (instruções de sistema + artigos + mensagem), envia-o ao modelo, recebe uma resposta que pode pedir uma ferramenta ("restart_router"), verifica o pedido, chama o serviço de gerenciamento de roteadores e devolve uma resposta. Cada etapa grava registros. Cada salto desse percurso é um lugar onde pode ficar uma verificação. Quando Ana acompanhou a requisição pelos registros, o ID do cliente autenticado aparecia no aplicativo e de novo no serviço de ferramentas, mas a chamada do orquestrador ao serviço de gerenciamento de roteadores levava apenas uma conta de serviço. Foi essa lacuna que permitiu que uma reinicialização chegasse a um roteador que não pertencia ao cliente, e é por isso que a correção posterior fez o serviço de ferramentas ler a identidade do cliente a partir da chamada, em vez de confiar no ID de roteador presente no pedido do modelo.

1.3 Dados e segredos

Dados das contas dos clientes, textos das conversas e resultados das ferramentas passam todos pela memória, pelos registros e, às vezes, por caches. Os segredos — a chave de API do fornecedor, as credenciais de gerenciamento de roteadores — ficam num cofre de segredos e são lidos pelos serviços na inicialização. Um técnico precisa saber onde está cada um, quem pode lê-lo e por quanto tempo é guardado. Na Kestrel, a resposta a "quem pode lê-lo" era o problema: a credencial de gerenciamento de roteadores estava no arquivo de configuração do orquestrador, de modo que todo engenheiro com acesso ao servidor podia lê-la, assim como qualquer cópia de segurança desse servidor. Levá-la para o cofre de segredos limitou os leitores à conta do serviço de ferramentas. Um técnico também deve perguntar por quanto tempo o texto das conversas fica em caches e registros, porque um endereço que o cliente digita no chat vai parar nos mesmos arquivos de registro que as chamadas de ferramentas.

1.4 Controles que os técnicos configuram

Configurações de autenticação, limites de taxa, fontes de recuperação, permissões de ferramentas, retenção e mascaramento de registros, limiares de alerta, configurações de contêineres e aplicação de correções. A maioria das falhas de segurança de IA vem da configuração, não de ataques exóticos. Todo incidente da Kestrel neste livro foi corrigido por uma dessas configurações, e não por uma mudança no modelo. A conta dobrada do fornecedor foi corrigida com um limite no gateway de 2 requisições por segundo, rajada de 10, e um orçamento diário de tokens. O abuso das reinicializações foi corrigido com uma verificação de titularidade e um teto de 3 reinicializações por dia no serviço de ferramentas. O modelo de teste copiado para a produção do LineWatch foi detectado por uma verificação de hash na inicialização. O artigo exclusivo da equipe arquivado no lugar errado foi corrigido limitando o índice dos clientes à coleção pública. Nada disso exigiu um cientista de dados.

1.5 Exemplo resolvido (caso sintético da Kestrel)

Ana recebe a tarefa de documentar o HelpBot. Ela lista onze componentes e acompanha uma requisição de "reiniciar roteador". Percebe que a credencial de gerenciamento de roteadores está guardada no arquivo de configuração do orquestrador, legível por todo engenheiro com acesso ao servidor. Ela relata o problema; a equipe leva a credencial para o cofre de segredos e restringe o serviço de ferramentas para que aceite reinicializações apenas do roteador vinculado ao cliente autenticado. Dois detalhes fizeram este achado valer mais do que um diagrama bem-feito. Primeiro, Ana não testou se alguém tinha usado a credencial exposta; ela relatou o fato e deixou a equipe conferir os registros de acesso. Segundo, mover o segredo não bastaria, porque o serviço de ferramentas continuaria reiniciando qualquer roteador que lhe pedissem. A restrição de titularidade é a mudança que depois reduziu as reinicializações entre contas de 9 em 60 para 0 em 60.

1.6 Erros e limites

Três erros são comuns: documentar o modelo, mas não as ferramentas; deixar segredos em arquivos de configuração; e supor que o fornecedor cuida de toda a segurança. Cada item tem uma ocorrência na Kestrel. Documentar só o modelo teria deixado de fora a ferramenta de reinicialização de roteadores, que causou o achado mais grave. O segredo num arquivo de configuração é a credencial do roteador que Ana encontrou na primeira semana. Supor que o fornecedor cuida da segurança teria deixado sem explicação o fim de semana de 40.000 mensagens, porque o fornecedor cobrou o tráfego corretamente; nada do lado dele estava quebrado. A fraqueza era a falta de um limite por conta no próprio gateway da Kestrel. Um diagrama de serviço deve, portanto, mostrar as ferramentas, os segredos e os limites do gateway com a mesma clareza que o modelo.

Exercícios

Síntese

Um serviço de IA é feito de muitos componentes; os técnicos o protegem sobretudo pela configuração — sabendo para onde vão os dados e os segredos e ajustando os controles corretamente.

Continue estudando — capítulo 01 de 18

← Página do curso · Índice de capítulos do curso · Capítulo 02 (rascunho) →