Gestão de identidades e acessos para Analista Judiciário - TI: IAM, RBAC e auditoria

Gestão de Identidades e Acessos (IAM – Identity and Access Management) é o conjunto de processos, políticas e controles técnicos que garantem que apenas pessoas e sistemas autorizados acessem recursos (sistemas, dados, APIs, estações, redes) com o nível mínimo necessário e com rastreabilidade. Em ambientes do Judiciário, o IAM é crítico por envolver dados sensíveis, sigilo processual, cadeia de custódia e necessidade de auditoria.

Conceitos centrais: identidade, credencial, autenticação e autorização

Identidade (quem é)

Identidade é a representação de um sujeito (usuário humano, serviço, robô de automação, aplicação) no diretório/IdP (Identity Provider). Uma identidade costuma ter atributos: nome, matrícula, lotação, cargo, unidade, perfil funcional, status (ativo/inativo), e identificadores únicos (login, ID interno).

Credencial (como prova quem é)

Credenciais são meios de comprovar a identidade: senha, certificado digital, token, biometria, chave FIDO2, OTP, entre outros. A credencial não é a identidade; é um mecanismo associado a ela.

Autenticação (provar quem é)

Autenticação é o processo de verificar a identidade. Pode ser local (no próprio sistema) ou federada (via IdP). Em concursos, é comum diferenciar fatores:

• Algo que você sabe: senha, PIN.
• Algo que você tem: token, app autenticador, smartcard.
• Algo que você é: biometria.

Autorização (o que pode fazer)

Autorização define permissões após a autenticação: quais sistemas, funcionalidades e dados podem ser acessados, e com quais ações (ler, incluir, alterar, excluir, assinar, homologar, administrar).

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

AAA: Authentication, Authorization e Accounting

AAA é um modelo clássico para organizar controles de acesso:

• Authentication: valida identidade (login, SSO, MFA).
• Authorization: aplica políticas de acesso (RBAC/ABAC, ACLs, escopos).
• Accounting: registra o uso (logs, trilhas de auditoria, relatórios de acesso e ações).

Em termos práticos, “Accounting” é o que permite responder perguntas como: “quem acessou o processo X?”, “quem alterou o cadastro Y?”, “qual IP e horário?”, “qual justificativa?”, “houve tentativa negada?”.

RBAC e ABAC: modelos de controle de acesso

RBAC (Role-Based Access Control)

No RBAC, permissões são atribuídas a papéis (roles), e usuários recebem papéis. É adequado quando as funções são relativamente estáveis e bem definidas (ex.: servidor de secretaria, assessor, magistrado, administrador do sistema).

Elementos típicos:

• Permissões: ações em recursos (ex.: “protocolar petição”, “movimentar processo”, “expedir mandado”).
• Roles: conjuntos de permissões (ex.: “Secretaria – Movimentação”, “Gabinete – Minuta”).
• Usuários: recebem roles conforme lotação e função.
• Hierarquia de roles (opcional): um role herda permissões de outro.

Vantagens: simplifica gestão, facilita auditoria (“usuário tem role X”). Riscos: “explosão de roles” se tentar representar muitas exceções; acúmulo de permissões ao longo do tempo (role creep).

ABAC (Attribute-Based Access Control)

No ABAC, decisões de acesso são baseadas em atributos do sujeito (usuário), do recurso (objeto), da ação e do contexto. Ex.: permitir acesso a processos sigilosos apenas se (lotação = unidade do processo) E (cargo = magistrado/assessor autorizado) E (horário dentro do expediente) E (dispositivo gerenciado) E (rede interna/VPN).

Atributos comuns:

• Sujeito: unidade, cargo, vínculo, clearance, status, treinamento concluído.
• Recurso: classe processual, sigilo, unidade responsável, fase, etiqueta de sensibilidade.
• Contexto: localização, IP, postura do dispositivo (compliance), horário, risco da sessão.

Vantagens: flexível e aderente a regras de negócio e sigilo. Desafios: exige boa governança de atributos, qualidade de dados e políticas bem testadas para evitar negações indevidas.

Quando usar RBAC, ABAC ou combinação

Em ambientes judiciais, é comum uma abordagem híbrida:

• RBAC para permissões funcionais (o que cada função pode fazer no sistema).
• ABAC para restrições finas (em quais processos/dados e em quais condições).

Exemplo: o role “Servidor de Secretaria” permite “movimentar processo”, mas o ABAC limita a movimentação a processos da própria unidade e não sigilosos, salvo atributo de autorização especial.

MFA e autenticação forte em ambientes sensíveis

MFA (Multi-Factor Authentication) reduz risco de comprometimento por senha vazada. Em órgãos com alta sensibilidade, MFA deve ser aplicado pelo menos a:

• Contas administrativas (sistemas, banco, rede, nuvem).
• Acesso remoto (VPN, VDI, webmail, portais internos).
• Ações críticas (assinatura, homologação, alteração de permissões, exportação massiva).

Passo a passo prático: desenhando uma política de MFA

• 1) Classifique sistemas e ações por criticidade: ex.: “consulta” (baixa), “alteração de cadastro” (média), “concessão de acesso” e “assinatura” (alta).
• 2) Defina escopo mínimo: MFA obrigatório para administradores e acesso externo; depois amplie para ações críticas internas.
• 3) Escolha fatores e métodos: app autenticador/OTP, push, FIDO2, certificado. Evite SMS quando houver alternativa mais robusta.
• 4) Defina exceções controladas: contingência com prazo, aprovação formal e registro em auditoria.
• 5) Estabeleça recuperação segura: processo de reset com validação forte (ex.: presencial, validação por gestor + Service Desk com evidências).
• 6) Monitore e ajuste: taxa de falhas, tentativas suspeitas, usuários sem segundo fator, e impacto operacional.

Ciclo de vida de contas (Joiner–Mover–Leaver) e provisionamento

Um dos maiores riscos de IAM é a manutenção de acessos indevidos por falhas no ciclo de vida. O modelo Joiner–Mover–Leaver organiza controles para entrada, movimentação e desligamento.

Joiner (entrada)

Na admissão/lotação inicial, a conta deve ser criada com base em dados oficiais (RH) e receber apenas acessos necessários ao início das atividades.

Mover (mudança)

Quando o usuário muda de unidade, função ou atribuição, acessos antigos devem ser removidos e novos acessos concedidos. Esse ponto é crítico para evitar acúmulo de permissões.

Leaver (saída)

No desligamento, cessão encerrada ou término de contrato, acessos devem ser revogados imediatamente, com tratamento de e-mail, caixas compartilhadas e propriedade de documentos conforme política.

Provisionamento, desprovisionamento e recertificação

• Provisionamento: concessão de acessos (idealmente automatizada por workflow com aprovação e trilha).
• Desprovisionamento: remoção de acessos (automatizada e imediata quando evento de RH ocorrer).
• Recertificação (access review): revisão periódica por gestores/donos do sistema para confirmar necessidade dos acessos.

Passo a passo prático: fluxo de concessão de acesso com governança

• 1) Solicitação: usuário ou gestor solicita acesso informando sistema, perfil e justificativa (ex.: “atuar na 2ª Vara Cível”).
• 2) Validação de elegibilidade: checar vínculo ativo, lotação, treinamento obrigatório, ausência de impedimentos.
• 3) Aprovação: gestor da unidade aprova necessidade; dono do sistema aprova perfil; TI executa ou automatiza.
• 4) Implementação: atribuir role(s) RBAC e regras ABAC (ex.: unidade = X).
• 5) Registro: gerar evidências (ticket, aprovadores, data/hora, perfil concedido, prazo).
• 6) Prazo e revisão: acessos temporários com expiração; acessos permanentes com recertificação trimestral/semestral.

Contas privilegiadas e segregação de funções (SoD)

Contas privilegiadas (administração de sistemas, banco, rede, segurança, IAM) exigem controles adicionais. Um princípio essencial é a Segregação de Funções (SoD – Segregation of Duties): evitar que uma única pessoa consiga executar ponta a ponta um processo crítico sem supervisão, reduzindo risco de fraude e erro.

Exemplos de conflitos de SoD em TI

• Quem aprova acesso não deve ser o mesmo que implementa o acesso em produção, sem controle compensatório.
• Quem desenvolve não deve ter permissão irrestrita de alterar produção e apagar logs.
• Administrador de banco não deve, sozinho, conseguir extrair dados sensíveis e alterar trilhas sem detecção.

Controles típicos para privilegiados

• Contas nominativas (sem compartilhamento) e uso de “break-glass” apenas em contingência.
• PAM (Privileged Access Management): cofre de senhas, rotação, sessão gravada, aprovação just-in-time.
• Privilégio mínimo: admin por escopo (apenas o necessário) e por tempo (elevação temporária).
• MFA obrigatório e restrição por dispositivo gerenciado.

Trilhas de auditoria, logs e evidências

Trilha de auditoria é o registro confiável e cronológico de eventos relevantes para reconstruir ações e decisões. Em sistemas judiciais, deve permitir rastrear:

• Autenticações: sucesso/falha, método (MFA), origem (IP, dispositivo), sessão.
• Autorizações: concessão/remoção de perfis, mudanças de roles, alterações de políticas.
• Ações no sistema: leitura de dados sensíveis, exportações, inclusões/alterações/exclusões, assinatura, juntada, movimentações.
• Administração: mudanças de configuração, criação de usuários, alteração de parâmetros de segurança.

Boas práticas de logging para alta sensibilidade

• Integridade: logs protegidos contra alteração (WORM/imutabilidade, hash encadeado, assinaturas).
• Centralização: enviar logs para repositório central (SIEM/gerenciador de logs) com controle de acesso.
• Sincronização de tempo: NTP consistente para correlação de eventos.
• Retenção: prazos definidos por norma interna e necessidade de auditoria/investigação.
• Princípio do menor acesso aos logs: poucos administradores, com trilha de acesso ao próprio log.
• Alertas: detecção de anomalias (muitas falhas de login, acesso fora do padrão, exportação massiva).

Passo a passo prático: definindo eventos auditáveis em um sistema processual

• 1) Liste ativos e operações críticas: processos sigilosos, dados pessoais, decisões, assinaturas.
• 2) Defina eventos mínimos: login/logout, falhas, alteração de perfil, consulta a sigilo, exportação, assinatura.
• 3) Defina campos obrigatórios: usuário/ID, role, unidade, ação, recurso (ID do processo/documento), data/hora, IP, resultado (permitido/negado), justificativa quando aplicável.
• 4) Padronize formato: JSON/CEF, nomenclatura de eventos, severidade.
• 5) Proteja e retenha: envio imediato ao centralizador e política de retenção.
• 6) Teste com casos reais: simular acesso indevido e verificar se a trilha permite reconstituir o ocorrido.

Desenho de perfis de acesso para unidades judiciais (exemplos)

A seguir, um exemplo conceitual de desenho de perfis em um sistema processual e sistemas de apoio, usando RBAC (papéis) e restrições ABAC (atributos).

Exemplo de roles (RBAC) por função

• Magistrado: visualizar todos os processos da unidade; proferir decisões; assinar; delegar tarefas; acesso a sigilo conforme regra.
• Assessor de Gabinete: elaborar minutas; acessar processos atribuídos ao gabinete; sem permissão de assinatura final.
• Diretor de Secretaria / Chefe de Cartório: gerenciar filas de trabalho; distribuir tarefas; expedir atos ordinatórios; supervisionar movimentações.
• Servidor de Secretaria: movimentar processos; expedir documentos; juntar petições; cumprir diligências internas.
• Oficial de Justiça: receber mandados; registrar cumprimento; anexar certidões; acesso restrito aos mandados atribuídos.
• Estagiário: acesso de leitura a processos não sigilosos e apenas sob supervisão; sem exportação massiva; sem alteração.
• Administrador do Sistema (TI): administrar parâmetros técnicos; sem permissão funcional de movimentar/assinar atos processuais (SoD).

Exemplo de políticas ABAC (restrições finas)

• Escopo por unidade: permitir acesso a processos onde recurso.unidadeResponsavel = usuário.lotacao.
• Sigilo: se recurso.sigilo = verdadeiro, exigir atributo usuário.autorizacaoSigilo = verdadeiro e registrar justificativa.
• Mandados: oficial só acessa mandados com recurso.responsavelID = usuário.id.
• Contexto: para ações críticas, exigir dispositivo gerenciado e MFA recente (reauth).
• Exportação: limitar exportação por volume e exigir motivo; elevar nível de auditoria.

Passo a passo prático: construindo uma matriz de acesso (role x permissão)

• 1) Inventarie funcionalidades: listar telas/serviços e ações (consultar, incluir, alterar, excluir, assinar, exportar).
• 2) Agrupe por macroprocesso: distribuição, movimentação, expedição, assinatura, administração.
• 3) Defina roles por função real: evitar roles “genéricos” demais; alinhar com organograma e atribuições.
• 4) Aplique privilégio mínimo: comece com leitura, adicione escrita apenas quando necessário.
• 5) Defina restrições ABAC: unidade, sigilo, atribuição, contexto.
• 6) Valide com donos do processo: secretaria, gabinete, corregedoria/controle interno (quando aplicável).
• 7) Documente e versiona: matriz, justificativas, data de aprovação, responsável.

Questões situacionais de conformidade (como pensar em prova e no trabalho)

Situação 1: servidor removido de unidade mantém acesso antigo

Cenário: servidor foi removido da Vara A para a Vara B, mas ainda consegue consultar e movimentar processos da Vara A.

Falha típica: ausência de desprovisionamento no evento “Mover” ou roles não vinculadas a atributos de lotação.

Medidas esperadas:

• Integração IAM–RH para disparar atualização automática de lotação.
• Roles baseadas em função + ABAC por unidade (lotação) para escopo de dados.
• Recertificação periódica por gestores das unidades.
• Auditoria de acessos pós-movimentação (relatório de usuários com acesso cruzado).

Situação 2: necessidade de acesso emergencial a processo sigiloso

Cenário: em plantão, há necessidade de acesso a processo sigiloso por servidor que não possui autorização padrão.

Tratamento adequado:

• Concessão temporária (just-in-time) com prazo curto e aprovação registrada.
• MFA obrigatório e reautenticação para ação crítica.
• Registro de justificativa e trilha reforçada (evento de “acesso excepcional”).
• Revisão posterior (auditoria) para confirmar legitimidade.

Situação 3: administrador de TI com permissão funcional indevida

Cenário: administrador do sistema consegue também movimentar processos e alterar dados funcionais.

Risco: quebra de segregação de funções e possibilidade de alteração sem detecção.

Correção:

• Separar perfis: “Admin técnico” não recebe permissões funcionais.
• Uso de PAM para tarefas administrativas, com sessão registrada.
• Auditoria de alterações de perfil e de parâmetros críticos.

Situação 4: logs insuficientes para apurar incidente

Cenário: suspeita de acesso indevido a dados sensíveis, mas o sistema só registra “usuário acessou o sistema”, sem detalhar o recurso consultado.

Ajustes necessários:

• Definir eventos auditáveis por recurso (ID do processo/documento) e ação (visualização/exportação).
• Centralizar logs e garantir integridade/retensão.
• Implementar alertas para padrões anômalos (consultas em massa, fora do horário, em sigilo).

Erros comuns em IAM cobrados em provas e vistos em auditorias

• Contas compartilhadas (sem rastreabilidade individual).
• Excesso de privilégios por perfis amplos e falta de revisão periódica.
• Ausência de expiração para acessos temporários (substituições, plantões, projetos).
• Processo manual sem evidência: concessões por e-mail sem registro formal e sem trilha.
• Logs sem integridade ou com acesso amplo, permitindo adulteração.
• Falta de SoD em mudanças de perfil e administração de produção.

Exemplo de estrutura mínima de política de acesso (para memorizar)

Política de Acesso (resumo operacional) 1) Identidades: cadastro via RH/contrato; conta nominativa; proibição de compartilhamento. 2) Autenticação: MFA para acesso remoto e ações críticas; requisitos de senha conforme norma interna. 3) Autorização: RBAC por função + ABAC por unidade/sigilo/contexto; privilégio mínimo; acessos temporários com expiração. 4) Provisionamento: workflow com solicitante, aprovador (gestor), dono do sistema; registro e evidências. 5) Recertificação: revisão periódica por unidade e por sistema; remoção de acessos não justificados. 6) Contas privilegiadas: PAM, JIT, sessões registradas, MFA obrigatório, segregação de funções. 7) Auditoria e logs: eventos mínimos definidos; centralização; integridade; retenção; alertas e relatórios.