Capítulo 34 — Operações de segurança e blue team: integração
Mapa da aula
Aula 34 publicada. Mapa, exemplo, EX100.
flowchart TD
N0["34.1 Por que a integração importa"]
N1["34.2 Gestão de serviços de TI"]
N2["34.3 Plataforma de identidade"]
N3["34.4 Atendimento ao cliente"]
N4["34.5 Contratos de interface"]
N5["34.6 Tratamento de falhas"]
N6["34.7 Testes"]
N7["Responsáveis pelas integrações"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Exemplo resolvido"]
EX --> Q["Exercício EX100"]
Desenho lógico
flowchart LR
N0["34.1 Por que a integração importa"]
N1["34.2 Gestão de serviços de TI"]
N2["34.3 Plataforma de identidade"]
N3["34.4 Atendimento ao cliente"]
N4["34.5 Contratos de interface"]
N5["34.6 Tratamento de falhas"]
N6["34.7 Testes"]
N7["Responsáveis pelas integrações"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX100"]
[34.1 Por que a integração importa]
|
v
[34.2 Gestão de serviços de TI]
|
v
[34.3 Plataforma de identidade]
|
v
[34.4 Atendimento ao cliente]
|
v
[34.5 Contratos de interface]
|
v
[34.6 Tratamento de falhas]
|
v
[34.7 Testes]
|
v
[Responsáveis pelas integrações]
|
v
[Exemplo resolvido] --> [Exercício EX100]
Objetivos de aprendizagem
Você vai (1) integrar o SOC aos sistemas de gestão de serviços de TI, de identidade e de atendimento ao cliente; (2) projetar interfaces e trocas de dados confiáveis; (3) tratar falhas de integração; (4) testar integrações de ponta a ponta.
34.1 Por que a integração importa
Uma detecção só é útil se o resultado chega às pessoas e aos sistemas que agem. O alerta de possível tomada de conta precisa chegar ao sistema de casos, à fila do atendimento ao cliente e à plataforma de identidade que guarda as contas. Um alerta parado no SIEM não ajuda ninguém até que um analista aja sobre ele, que um atendente saiba o que dizer ao cliente e que a plataforma de identidade de fato bloqueie a conta. Cada passagem é um ponto onde a informação pode se perder ou atrasar. O projeto de integração mapeia cada passagem, incluindo que dados precisam atravessá-la e com que rapidez.
34.2 Gestão de serviços de TI
Alertas que exigem ação da TI, como consertar uma alimentação de logs, viram chamados no sistema de serviços de TI, com um mapeamento de prioridade combinado: "alta" no SOC significa "P2" na TI, com resposta em quatro horas. Sem um mapeamento combinado, uma "alta" do SOC poderia cair na fila da TI como pedido de rotina e esperar dias. O mapeamento traduz a urgência para os termos que a equipe receptora já usa. As quatro horas foram combinadas com a TI como realistas para o quadro de pessoal dela. Os chamados levam um link de volta ao caso do SOC, para que as duas equipes acompanhem o andamento.
34.3 Plataforma de identidade
A automação chama a interface da plataforma de identidade de clientes para aplicar bloqueios e invalidar sessões. A interface usa uma conta de serviço dedicada, só com essas permissões, e toda chamada é registrada. Uma conta dedicada, só com permissões de bloqueio e invalidação, limita o dano se a automação for mal usada ou comprometida: ela não consegue ler dados de clientes nem trocar senhas. Registrar cada chamada cria uma trilha de auditoria que mostra quais contas foram bloqueadas, quando e por qual alerta. Esses próprios registros são monitorados em busca de volumes incomuns.
34.4 Atendimento ao cliente
O atendimento ao cliente vê uma visão simplificada: "conta em bloqueio de segurança, motivo: login suspeito, contatar o cliente pelo telefone cadastrado". Os atendentes não veem logs brutos. Os logs brutos contêm detalhes de que o atendimento não precisa e que poderia interpretar mal ou divulgar. A visão simplificada dá exatamente o que o atendente precisa para agir: que a conta está bloqueada, por que, em termos simples, e como contatar o cliente com segurança. Usar o telefone cadastrado protege contra um atacante que tenha trocado o endereço de e-mail.
34.5 Contratos de interface
Cada integração tem um contrato: campos de dados, formatos, limites de taxa, códigos de erro e responsável. Os contratos evitam quebras silenciosas quando um dos lados muda. Os limites de taxa importam porque a automação pode chamar a plataforma de identidade muitas vezes durante um incidente grande. Os códigos de erro permitem à automação distinguir "conta não encontrada" de "plataforma sobrecarregada". Os responsáveis dos dois lados são avisados das mudanças planejadas. Os contratos ficam junto com o código da integração e são testados, para que uma mudança incompatível apareça antes da produção. Números de versão marcam cada revisão do contrato.
34.6 Tratamento de falhas
Se a plataforma de identidade não responde, a automação tenta de novo duas vezes e depois gera um alerta de alta prioridade para ação manual. Ela nunca presume sucesso. Presumir sucesso quando a plataforma não responde poderia deixar ativa uma conta comprometida enquanto o SOC acredita que ela está bloqueada. Duas novas tentativas cobrem falhas breves de rede sem atrasar demais. O alerta manual dá ao analista os detalhes necessários para aplicar o bloqueio à mão pelo console da plataforma, e o caso registra qual caminho foi usado.
34.7 Testes
Os testes de integração rodam todo mês com uma conta sintética de cliente de teste reservada para esse fim. Uma conta de teste reservada se comporta como um cliente real, mas não pertence a ninguém, então os bloqueios e a invalidação de sessões podem ser exercitados com segurança. Os testes mensais pegam mudanças do lado da plataforma de identidade, como um campo renomeado ou uma permissão revogada. Os resultados dos testes são registrados, e as falhas abrem um chamado para o responsável pela integração. Um teste que deixa a conta reservada bloqueada é ele mesmo uma falha, então o teste termina liberando o bloqueio e verificando que a conta volta a funcionar normalmente.
Responsáveis pelas integrações
Cada integração tem um responsável de cada lado, que é avisado antes das mudanças.
Exemplo resolvido
O primeiro teste mensal falha: o bloqueio é aplicado, mas a fila do atendimento ao cliente nunca recebe o caso, porque uma mudança de firewall bloqueou a conexão do SOC com o sistema de atendimento. O caminho de tratamento de falhas alerta o engenheiro de plantão, que corrige a regra; o teste é refeito e passa.
Caso sintético. Os sistemas e os testes são inventados.
Erros e limites
As integrações multiplicam as dependências; cada uma é um novo lugar onde falhar.
Exercícios
- EX100 — Mapeamento de prioridades. Por que mapear explicitamente as prioridades do SOC para as da TI? Rubrica: 3 = significado e tempos de resposta compartilhados entre as equipes; 2 = parcial; 1 = estilo; 0 = nada.
- EX101 — Conta de menor privilégio. Como a conta da interface de identidade é limitada? Rubrica: 3 = só permissões de bloqueio e invalidação; todas as chamadas registradas; 2 = parcial; 1 = conta de administrador; 0 = nada.
- EX102 — Falha no teste. O que revelou o primeiro teste de integração? Rubrica: 3 = uma mudança de firewall bloqueou a entrega do caso; o caminho de falha alertou; corrigido; 2 = parcial; 1 = vago; 0 = nada.
Síntese
As integrações levam as detecções até a ação; contratos, menor privilégio, tratamento de falhas e testes regulares as mantêm funcionando.
Continue estudando — capítulo 34 de 50
← Capítulo 33 (rascunho) · Índice de capítulos do curso · Capítulo 35 (rascunho) →