Como integrar conhecimentos por competências (o que a banca costuma cobrar)
Em provas para Analista Judiciário – TI, é comum que um enunciado descreva um problema “real” (ex.: indisponibilidade do sistema processual, vazamento de dados, lentidão, falha de autenticação) e exija decisões técnicas e normativas ao mesmo tempo. A integração por competências consiste em identificar, em cada caso, quais domínios estão sendo acionados e quais evidências (logs, métricas, configurações, políticas) sustentam a resposta.
Matriz rápida de competências para leitura de casos
- Lógica e raciocínio: decompor o problema, levantar hipóteses, definir testes, priorizar ações por impacto/risco.
- Redes: segmentação, roteamento, DNS, latência, perda, ACL, VLAN, inspeção de tráfego, análise de fluxos.
- Banco de dados: concorrência, locks, planos de execução, índices, I/O, pool de conexões, replicação, backup/restore.
- Segurança: triagem de incidente, contenção, evidências, hardening, IAM, trilhas de auditoria, resposta e comunicação.
- Governança/serviços: gestão de incidentes e mudanças, catálogo de serviços, SLAs, riscos, conformidade, segregação de funções.
Critérios para identificar o tema central de uma questão (mesmo quando é “mista”)
- Objeto afetado: é o tráfego (rede), a consulta (BD), a autenticação (IAM), o processo (governança) ou o dado (segurança/LGPD)?
- Tipo de evidência citada: picos de RTT e perda (rede), waits/locks (BD), alertas IDS e logs de autenticação (segurança), registro de mudança e SLA (governança).
- Verbo de comando: “mitigar”, “conter”, “preservar evidências” tende a segurança; “otimizar”, “reduzir tempo” tende a BD; “segmentar”, “isolar” tende a redes; “formalizar”, “aprovar”, “registrar” tende a governança.
- Restrição normativa: menção a sigilo, dados pessoais, trilha de auditoria e segregação de funções desloca o centro para conformidade/segurança.
Caso integrado 1: Incidente de segurança com impacto no sistema processual
Cenário: usuários relatam que o sistema processual está instável e, em paralelo, a equipe de segurança recebe alerta de comportamento anômalo: múltiplas tentativas de login e aumento de tráfego de saída do servidor de aplicação para um IP externo. Há risco de indisponibilidade e de exfiltração de dados.
Objetivo do caso
- Restabelecer o serviço com segurança.
- Conter o incidente e preservar evidências.
- Garantir rastreabilidade (auditoria) e conformidade (sigilo/LGPD quando aplicável).
Passo a passo prático (resposta integrada)
- 1) Triagem e classificação: registrar o incidente (hora, sintomas, sistemas afetados, impacto). Definir severidade com base em indisponibilidade e possível vazamento.
- 2) Preservação de evidências: antes de “limpar” o ambiente, coletar logs relevantes (aplicação, autenticação, proxy/WAF, firewall, banco, sistema operacional) e garantir integridade (hash e cadeia de custódia interna).
- 3) Contenção imediata (rede + segurança): aplicar bloqueio temporário de egress para o IP suspeito no firewall/ACL; se necessário, isolar o servidor em VLAN/quarentena mantendo acesso administrativo controlado. Evitar desligar abruptamente sem necessidade, para não perder evidências voláteis.
- 4) Verificação de IAM: identificar contas alvo (tentativas de login), checar se houve sucesso, origem (IPs), horário e padrão. Se houver indício de comprometimento, revogar sessões/tokens, resetar credenciais e aplicar MFA conforme política.
- 5) Avaliação do banco de dados: validar se houve consultas fora do padrão (ex.: exportações massivas), picos de leitura, conexões incomuns, alterações de privilégios. Conferir trilhas de auditoria e permissões.
- 6) Hipóteses e testes (lógica): separar hipóteses: (a) ataque de força bruta causando indisponibilidade; (b) exploração de vulnerabilidade com exfiltração; (c) falso positivo com gargalo de infraestrutura. Testar por evidências: correlação de logs, volume de tráfego, erros 5xx, saturação de CPU/memória, filas de conexão.
- 7) Erradicação e recuperação: aplicar correções (patch, regra WAF, hardening, remoção de artefatos maliciosos), restaurar serviço em ambiente limpo quando necessário. Se houver suspeita de integridade comprometida, preferir rebuild a “conserto” manual.
- 8) Governança e comunicação: registrar ações, aprovar mudanças emergenciais conforme processo, comunicar partes interessadas (gestão, segurança institucional, encarregado de dados quando aplicável) com informação mínima necessária e rastreável.
- 9) Ações preventivas: reforçar rate limiting, políticas de senha/MFA, segmentação, princípio do menor privilégio, revisão de logs e alertas, testes de restauração e exercícios de resposta.
Checklist de evidências que costumam aparecer em questões
- Logs de autenticação com tentativas repetidas e IPs de origem.
- Alertas IDS/IPS/WAF com assinatura ou anomalia.
- Netflow/telemetria indicando egress incomum.
- Logs do banco com consultas massivas ou criação de usuário.
- Registro de mudança emergencial e linha do tempo do incidente.
Caso integrado 2: Lentidão no banco de dados afetando prazos e produtividade
Cenário: em horários de pico, o sistema processual fica lento ao consultar movimentações e anexos. A aplicação não caiu, mas o tempo de resposta ultrapassa o aceitável. Há reclamações de unidades e risco operacional.
Objetivo do caso
- Diagnosticar gargalo com método (não “chute”).
- Aplicar correções com menor risco e com controle de mudança.
- Manter segurança e auditoria (sem “abrir” permissões indevidas para ganhar desempenho).
Passo a passo prático (diagnóstico orientado por evidências)
- 1) Definir o sintoma mensurável: qual operação está lenta (tela X, relatório Y), qual o tempo atual e o alvo (SLA interno). Separar latência de rede vs tempo de processamento.
- 2) Coletar métricas por camada: aplicação (tempo por endpoint), banco (tempo por query, waits/locks), SO (CPU, memória, I/O), rede (RTT, perda). A questão costuma “entregar” um indicador-chave.
- 3) Identificar o tipo de gargalo no BD: (a) CPU-bound (muitas operações), (b) I/O-bound (leitura em disco), (c) contenção/locks, (d) pool de conexões saturado, (e) plano de execução ruim por estatísticas desatualizadas.
- 4) Localizar a consulta crítica: usar logs de consultas lentas e correlacionar com o horário de pico. Priorizar pelo impacto (maior frequência x maior custo).
- 5) Ações de correção com menor risco: atualizar estatísticas, criar/ajustar índices, revisar parâmetros de conexão, particionar quando aplicável, ajustar cache/buffer. Evitar “soluções” que violem governança (ex.: dar privilégio amplo para reduzir joins).
- 6) Validar efeito e regressão: testar em ambiente controlado, medir antes/depois, garantir que não degradou outras operações.
- 7) Governança: registrar mudança, janela de manutenção, plano de rollback, evidências de teste e atualização do catálogo de serviço/SLA.
Exemplo de raciocínio típico em prova
Se o enunciado traz “muitos usuários simultâneos” e “tempo de resposta cresce em degraus” com “muitas conexões abertas”, o tema central tende a ser pool de conexões e contenção. Se traz “alto I/O e cache miss”, tende a ser índices/planos e disco. Se traz “RTT alto entre aplicação e BD”, o centro pode ser rede mesmo com sintoma no BD.
Caso integrado 3: Segmentação de rede para unidades e sistemas com diferentes níveis de sigilo
Cenário: o tribunal possui unidades (gabinetes, secretarias, atendimento) e sistemas com diferentes perfis de acesso. Há necessidade de reduzir superfície de ataque e limitar movimentação lateral, sem interromper serviços essenciais (DNS, autenticação, banco, impressão, videoconferência).
Continue em nosso aplicativo
Você poderá ouvir o audiobook com a tela desligada, ganhar gratuitamente o certificado deste curso e ainda ter acesso a outros 5.000 cursos online gratuitos.
ou continue lendo abaixo...
Baixar o aplicativo
Objetivo do caso
- Propor segmentação com base em função e risco.
- Definir regras mínimas de comunicação (allowlist).
- Manter governança: documentação, aprovação e testes.
Passo a passo prático (desenho e implantação)
- 1) Inventariar fluxos: mapear quem fala com quem (clientes → aplicação, aplicação → banco, estações → serviços corporativos). Sem isso, segmentação vira indisponibilidade.
- 2) Definir zonas: por exemplo, Usuários, Servidores de Aplicação, Banco de Dados, Administração, Terceiros, DMZ. Separar ambientes críticos e administrativos.
- 3) Implementar VLANs/sub-redes: criar segmentação lógica por unidade/função e por criticidade. Planejar endereçamento e roteamento inter-VLAN.
- 4) Controlar tráfego inter-zonas: aplicar ACL/firewall entre VLANs com regra padrão de negação e exceções justificadas (portas e destinos estritamente necessários).
- 5) Proteger serviços centrais: restringir acesso a DNS, diretório/autenticação, NTP e gerenciamento. Separar rede de administração (jump server/bastion) e registrar acessos.
- 6) Validar e monitorar: testes de conectividade por serviço, monitoramento de bloqueios (logs de firewall) para ajustar regras sem abrir demais.
- 7) Governança e continuidade: documentar diagrama, matriz de regras, responsáveis, janela de mudança, plano de retorno.
Pontos de atenção que viram pegadinha
- Segmentar sem mapear fluxos pode derrubar autenticação e resolução de nomes.
- Permitir “any-any” entre VLANs anula o objetivo de segurança.
- Administrar servidores a partir da rede de usuários aumenta risco; separar rede administrativa é medida clássica.
Caso integrado 4: Implantação de controle de acesso e auditoria (RBAC + trilhas)
Cenário: auditoria interna identificou que perfis de acesso no sistema processual são concedidos de forma informal e que não há trilha confiável de quem acessou processos sigilosos. É necessário implantar controle por papéis, segregação de funções e auditoria ponta a ponta.
Objetivo do caso
- Definir papéis e permissões alinhados às funções.
- Implantar fluxo de concessão/revogação com rastreabilidade.
- Garantir logs úteis (com integridade e retenção) sem expor dados sensíveis.
Passo a passo prático (implantação por camadas)
- 1) Levantamento de funções e operações: listar operações críticas (ver processo sigiloso, baixar documento, alterar cadastro, conceder perfil, executar relatório massivo).
- 2) Modelar papéis (RBAC): criar papéis por função (ex.: servidor de secretaria, magistrado, administrador de sistema, auditor). Evitar papéis “genéricos” com permissões excessivas.
- 3) Segregação de funções: separar quem solicita acesso, quem aprova e quem implementa. Evitar que o mesmo usuário tenha papel de administração e de auditoria.
- 4) Fluxo de provisionamento: solicitação formal, aprovação por responsável, implementação automatizada quando possível, revisão periódica e revogação por desligamento/mudança de lotação.
- 5) Auditoria e trilhas: registrar eventos relevantes (login, falha de login, acesso a processo sigiloso, exportação, alteração de permissões). Garantir sincronismo de tempo (NTP), retenção e proteção contra alteração.
- 6) Integração com banco e aplicação: garantir que a aplicação registre o “quem fez” e o banco registre operações administrativas e acessos sensíveis quando aplicável. Evitar logs com conteúdo sensível desnecessário; registrar identificadores e metadados.
- 7) Monitoramento e resposta: alertas para eventos suspeitos (ex.: acesso fora do horário, volume anormal, tentativas repetidas). Definir procedimento de investigação.
- 8) Governança: política de acesso, matriz de responsabilidades, evidências de aprovação, relatórios de revisão e conformidade.
Questões mistas (simulado por competências) com gabarito comentado
Como usar este bloco
- Primeiro, identifique o tema central pelo critério: evidência + verbo de comando + objeto afetado.
- Depois, marque quais competências aparecem como suporte (secundárias).
Questões
Q1. Durante um incidente, a equipe detecta tráfego de saída incomum do servidor do sistema processual para um IP externo. O serviço está instável. Qual ação inicial é mais adequada para reduzir risco sem comprometer a investigação?
- A) Desligar imediatamente o servidor para interromper o tráfego.
- B) Bloquear temporariamente o destino suspeito no controle de borda e coletar logs relevantes antes de mudanças destrutivas.
- C) Conceder privilégios administrativos amplos a um usuário para acelerar a análise.
- D) Executar limpeza de arquivos temporários e reiniciar serviços para “normalizar”.
Q2. Um sistema apresenta lentidão apenas em horários de pico. Métricas mostram CPU do banco moderada, mas alto tempo de espera por I/O e aumento de leituras físicas. Qual hipótese é mais consistente e qual medida tende a ser mais efetiva?
- A) Gargalo de rede; aumentar MTU e trocar cabos.
- B) Gargalo de I/O; revisar índices/planos e reduzir leituras em disco (ex.: índices adequados e estatísticas).
- C) Falha de autenticação; redefinir políticas de senha.
- D) Problema de governança; abrir exceção permanente no processo de mudança.
Q3. Ao segmentar a rede por unidades, a equipe cria VLANs distintas e aplica regra padrão de negação entre elas. Após a mudança, usuários relatam falha intermitente ao acessar o sistema. Qual verificação é mais alinhada ao diagnóstico inicial?
- A) Verificar se serviços centrais (DNS/autenticação/NTP) continuam acessíveis conforme regras inter-VLAN.
- B) Desativar o firewall entre VLANs para “testar” por uma semana.
- C) Migrar o banco para outra tecnologia imediatamente.
- D) Remover logs para reduzir uso de disco.
Q4. Auditoria interna exige rastreabilidade de acessos a processos sigilosos. Qual combinação atende melhor ao requisito com segregação de funções?
- A) Um único perfil “Administrador Geral” com acesso total e sem logs detalhados.
- B) RBAC com papéis por função, fluxo de aprovação, trilha de auditoria de eventos sensíveis e proteção dos logs contra alteração.
- C) Acesso liberado por IP de origem, sem autenticação individual.
- D) Logs apenas no navegador do usuário, sem centralização.
Q5. Em um incidente, há suspeita de exfiltração. O enunciado informa que o time coletou logs, mas os relógios dos servidores estavam dessincronizados, dificultando a correlação. Qual controle preventivo reduz diretamente esse problema?
- A) Aumentar a quantidade de memória RAM dos desktops.
- B) Sincronização de tempo (NTP) padronizada e monitorada em servidores e dispositivos de rede.
- C) Trocar o algoritmo de hash de senhas por um mais rápido.
- D) Desabilitar criptografia para reduzir latência.
Q6. Um relatório do sistema processual executa uma consulta que faz varredura completa em tabela grande e degrada o serviço. A equipe quer corrigir rapidamente, mas precisa manter controle e rastreabilidade. Qual sequência é mais adequada?
- A) Alterar diretamente em produção sem registro; se der errado, “volta depois”.
- B) Identificar a consulta, propor ajuste (índice/reescrita), testar, registrar mudança com plano de rollback e aplicar em janela aprovada.
- C) Bloquear o acesso de todos os usuários ao banco indefinidamente.
- D) Criar um usuário com permissões totais para o relatório “rodar mais rápido”.
Gabarito comentado (com tema central e competências)
Q1: B. Tema central: segurança (contenção + preservação de evidências). Competências: redes (bloqueio de egress), governança (registro), lógica (priorização). Desligar pode destruir evidências voláteis; reiniciar/limpar antes de coletar logs prejudica investigação.
Q2: B. Tema central: banco de dados (I/O e otimização). Competências: lógica (hipótese baseada em métricas), governança (mudança controlada). Alto wait de I/O e leituras físicas apontam para falta de índice/planos/estatísticas ou cache insuficiente, não para autenticação.
Q3: A. Tema central: redes (segmentação e dependências). Competências: segurança (deny by default), governança (mudança). Após segmentação, falhas comuns surgem por bloqueio de DNS/diretório/NTP; desativar firewall anula o controle.
Q4: B. Tema central: IAM e auditoria (RBAC + trilhas). Competências: governança (aprovação e segregação), segurança (integridade de logs). Perfil único e sem logs viola segregação e rastreabilidade.
Q5: B. Tema central: governança/segurança operacional (correlação de eventos). Competências: redes (NTP), segurança (investigação). Sem tempo sincronizado, a linha do tempo do incidente fica inconsistente.
Q6: B. Tema central: governança de mudanças aplicada a desempenho de BD. Competências: banco (otimização), lógica (diagnóstico), segurança (evitar privilégios excessivos). Correção rápida não significa mudança sem controle; plano de rollback é requisito típico.
Roteiro de revisão por competências (aplicável a qualquer caso)
1) Perguntas-guia para decomposição lógica
- Qual é o serviço e qual é o impacto (indisponibilidade, lentidão, confidencialidade, integridade)?
- Quais são as hipóteses mais prováveis e quais evidências confirmam/refutam?
- Qual ação reduz risco agora (contenção) e qual ação resolve a causa (correção)?
2) Perguntas-guia de redes
- Há mudança recente de rota, VLAN, ACL, firewall, DNS?
- Os serviços centrais estão acessíveis? Há aumento de latência/perda?
- Existe tráfego anômalo de entrada/saída (volume, destino, porta)?
3) Perguntas-guia de banco de dados
- O gargalo é CPU, I/O, locks, conexões ou plano de execução?
- Quais consultas são mais custosas e mais frequentes?
- Há crescimento de dados, estatísticas desatualizadas, índices inadequados?
4) Perguntas-guia de segurança
- Há indício de comprometimento (tentativas de login, escalonamento de privilégio, egress incomum)?
- As evidências foram preservadas com integridade e rastreabilidade?
- O acesso segue menor privilégio e há trilha de auditoria útil?
5) Perguntas-guia de governança e conformidade
- O incidente/mudança foi registrado? Há responsável, aprovação e comunicação adequada?
- Há SLA/OLAs e critérios de severidade para priorização?
- Há segregação de funções e revisões periódicas de acesso?
