Security Operations / Threat Response

Permissões

• microsoft.directory/identityProtection/allProperties/update — remediar usuários de risco no Identity Protection
• microsoft.directory/signInReports/allProperties/read — ler relatórios completos de entrada
• microsoft.office365.securityComplianceCenter/allEntities/allTasks — operar o Microsoft 365 Defender
• microsoft.directory/auditLogs/allProperties/read — ler logs de auditoria do diretório
• microsoft.directory/riskyUsers/allProperties/update — descartar risco e forçar redefinição de senha

Mitigações

• Ativar a role por PIM com justificativa e janela de no máximo 8 horas
• Separar quem investiga de quem define política — Security Operator não deve acumular Security Administrator
• Alertar sobre descarte de risco em massa: dispensar risco é a ação que apaga o sinal de comprometimento
• Exigir MFA resistente a phishing para a ativação, já que o alvo natural do atacante é o time que o detectaria
• Revisar trimestralmente quem tem a role contra a escala real do SOC

O Azure RBAC não tem role dedicada de resposta a incidente. Security Reader lê a postura; qualquer ação corretiva no Defender for Cloud exige Security Admin, que é a linha Security Administrator desta tabela.

Permissões

• Microsoft.Security/*/read — ler alertas, avaliações e recomendações do Defender for Cloud
• Microsoft.Security/iotSecuritySolutions/analyticsModels/read — ler modelos analíticos de IoT
• Microsoft.OperationalInsights/workspaces/*/read — consultar workspaces do Log Analytics
• Microsoft.Insights/alertRules/read — ler regras de alerta configuradas
• Microsoft.Support/* — abrir caso de suporte durante um incidente

Mitigações

• Combinar com Log Analytics Reader no workspace do Sentinel — Security Reader sozinho não lê a tabela de eventos
• Preferir escopo de subscription ao de management group: leitura de alerta em toda a organização raramente é necessária
• Auditar exportações de alerta, que carregam nome de recurso e caminho de ataque
• Revisar a atribuição quando o time de resposta muda de fornecedor
• Registrar que responder a incidente (isolar recurso, aplicar correção) exige Security Admin — esta role só lê

Permissões

• guardduty:Get* / guardduty:List* — ler achados do GuardDuty
• securityhub:Get* / securityhub:Describe* — ler achados agregados do Security Hub
• cloudtrail:LookupEvents — pesquisar eventos de API durante a investigação
• config:Describe* — ler regras e histórico de conformidade do AWS Config
• iam:GenerateCredentialReport — gerar o relatório de credenciais da conta

Mitigações

• Atribuir na conta de segurança do Organizations, não em cada conta de workload
• Combinar com uma policy de resposta escrita à parte: SecurityAudit é estritamente leitura
• Monitorar iam:GenerateCredentialReport e GetCredentialReport — o relatório expõe idade de chave e uso de MFA de toda a conta
• Exigir MFA e origem de rede confiável na trust policy da role assumida
• Revisar o diff da policy a cada versão nova: a AWS amplia SecurityAudit sem aviso

Permissões

• securitycenter.findings.list — listar achados do Security Command Center
• securitycenter.assets.list — inventariar recursos monitorados pelo SCC
• securitycenter.sources.list — ler as fontes de detecção configuradas
• securitycenter.findings.setState — marcar achado como ativo ou inativo
• logging.logEntries.list — consultar Cloud Logging durante a investigação

Mitigações

• Atribuir na organização, não no projeto — achado de SCC só faz sentido com visão completa
• Alertar sobre securitycenter.findings.setState: marcar achado como inativo é a ação que silencia a detecção
• Combinar com roles/logging.privateLogViewer só quando a investigação exigir Data Access logs
• Revisar quem tem a role sempre que o contrato do SOC terceirizado mudar
• Registrar que remediar exige role de administração do recurso afetado — esta role não corrige nada

A IBM tem 7 roles e nenhuma é específica de serviço: o que varia é o serviço sobre o qual a role é atribuída. Aqui é a role de Reader sobre Security and Compliance Center. A IBM não publica a lista de ações por role — cada serviço mapeia as próprias.

Permissões

• Ler resultados de varredura e avaliações de conformidade do SCC
• Consultar o histórico de atestações e evidências coletadas
• Visualizar perfis e controles atribuídos à conta
• Acompanhar o painel de postura sem alterar configuração
• Exportar relatórios de conformidade para auditoria externa

Mitigações

• Separar de Administrator (Security and Compliance Center): quem lê o resultado não deveria alterar o perfil que o gera
• Auditar exportações de relatório — carregam inventário e falhas de controle da conta inteira
• Atribuir via access group por função, não por usuário
• Revisar a atribuição quando o escopo de conformidade regulatória mudar
• Registrar que a IBM não publica a lista de ações por role: o alcance real depende do serviço