← ISC2 CC: fundamentos de cibersegurança na prática
06 / 8 · 18 MIN

Modelos de autorização, responsabilidades e recertificação

Aplica RBAC, ABAC e separação de funções sem confundir autenticação com aprovação.

Conceito e mecanismo

Depois de autenticar alguém, a organização continua a ter de decidir o que essa identidade pode fazer. Em RBAC, permissões são associadas a funções; a pertença à função deve seguir a necessidade real do trabalho. Em ABAC, uma decisão pode considerar atributos da identidade, do recurso, da ação e do contexto, sujeitos a uma política validada.

Um modelo não é automaticamente melhor: a política tem de ser compreensível, testável e aplicada pelo serviço que protege os dados. Separação de funções evita que a mesma pessoa consiga executar e aprovar isoladamente uma transação sensível.

Menor privilégio limita ações e âmbito; não é apenas dar a todos uma função com poucos privilégios por nome. Regista exceções, responsáveis, duração e evidência da revisão. As regras aplicam-se também a contas de serviço e agentes automatizados, cuja identidade não se confunde com a do utilizador humano que desencadeou a tarefa.

Aplicação guiada

Num exercício de revisão de acessos, compara três casos: alguém mudou de departamento e mantém permissões antigas; uma conta técnica recebeu acesso de escrita para executar apenas leituras; um operador aprova o próprio pedido de pagamento. O primeiro exige rever memberships e remover acessos desnecessários, o segundo restringir ações e recursos e o terceiro separar aprovação de execução.

Na política ABAC, indicar departamento no cliente não chega: valida o atributo numa fonte fiável e aplica a decisão na API, não apenas na interface. Recolhe uma amostra de tentativas permitidas e negadas, datas de expiração de exceções e provas de revogação em sessões já emitidas.

Concluir que a política é correta só porque o ecrã omite um botão não constitui teste de autorização. Quando uma identidade é desativada, verifica também tokens, integrações e credenciais que continuem válidos.

NA PRÁTICA

Uma conta de leitura consegue apagar um registo chamando a API diretamente: o controlo visual existe, mas a autorização no servidor está em falta.

Armadilhas comuns

Confundir login com permissão; atribuir papel pelo nome; confiar em atributos do cliente; deixar exceções sem prazo; omitir contas técnicas.

Tópicos relacionados: Ciclo de identidade e acessos · Governance, continuidade e sensibilização · Dados, operação e resposta inicial

Leva esta ideia contigo

Demonstra permissões com decisões no servidor, responsabilidades distintas e revisão do ciclo de vida.

Criar conta

Referência: Security and privacy controls · CC examination outline effective 2026-09-01; PDF v01/2026

ISC2® e Certified in Cybersecurity são marcas comerciais ou marcas registadas de ISC2, Inc. A dr.pt é uma plataforma de preparação independente e não está afiliada, associada, patrocinada, autorizada nem aprovada por ISC2. Os conteúdos e as perguntas são originais, não são perguntas oficiais de exame, e concluir os nossos testes não atribui nem garante qualquer certificação. Os nomes são usados apenas para identificar o tema. Todas as outras marcas pertencem aos respetivos titulares.