A maioria das implementações de RBAC falha antes de ser atribuída uma única permissão. A causa raiz está quase sempre no desenho da política. As equipas adquirem uma ferramenta de gestão de identidades e acessos (IAM), mapeiam algumas funções óbvias como admin e utilizador, e começam a atribuir acessos. Dezoito meses depois, têm 400 funções para 250 colaboradores, ninguém se lembra porque é que a função Finance-Temp-2023 ainda tem acesso de escrita ao livro-razão geral, e a auditoria anual demora semanas em vez de dias.
Uma política de controlo de acessos empresarial é o documento formal que define as funções existentes numa organização, as permissões de cada função, quem reúne os requisitos para uma determinada função e de que forma esse acesso é revisto e revogado ao longo do tempo.
Controlo de acesso baseado em funções (RBAC) é o modelo de autorização. A política de controlo de acessos é a camada de governação que determina como o modelo é aplicado na prática. Sem um desenho deliberado da política, o RBAC degrada-se em explosão de funções, acumulação indevida de privilégios (privilege creep) e caos na auditoria, por melhor que seja a tecnologia subjacente.
Este artigo apresenta uma metodologia repetível, o RBAC Policy Design Canvas, para construir de raiz uma política de controlo de acessos empresarial: engenharia de funções, mapeamento de conformidade com a NIST SP 800-53 e o Anexo A da ISO 27001, e a camada de armazenamento de credenciais em cofre que transforma a política em algo aplicado e não apenas aspiracional
Pontos principais
- Uma política de controlo de acessos é o documento de governação que define as funções existentes, as permissões que cada uma inclui e como o acesso é revisto e revogado. O RBAC é o modelo de autorização; a política é o que o torna aplicável.
- A explosão de funções é evitável. Exija pelo menos três pessoas a desempenhar a mesma atividade profissional antes de criar uma função autónoma. Trate as exceções com permissões suplementares em vez de novas funções.
- O RBAC Policy Design Canvas oferece uma sequência repetível de seis passos: mapear o panorama de acessos, definir a granularidade, modelar hierarquias, codificar o princípio do menor privilégio e a segregação de funções, documentar a política e, por último, estabelecer a aplicação e a cadência de revisão.
- As políticas de RBAC remetem para controlos concretos, e não para formulações vagas: NIST SP 800-53 (AC-2, AC-5, AC-6), ISO 27001:2022 (5.15, 5.16, 8.2), SOC 2 (CC6.1-CC6.3) e Diretiva NIS2, artigo 21.º, n.º 2, alínea i).
- Uma política que se fica pela camada aplicacional ignora o local onde reside o risco real. As credenciais comprometidas são a categoria mais dispendiosa de incidentes internos, com uma média de 779 000 dólares por evento. O armazenamento de credenciais em cofre associa os segredos a funções, e não a indivíduos, eliminando essa lacuna.
- As identidades não humanas (contas de serviço, chaves de API e agentes de IA) já superam em número as contas humanas na maioria dos ambientes. Necessitam da mesma estrutura de funções, das mesmas regras de granularidade e da mesma cadência de revisão que as funções humanas, e não de uma isenção da política.
- O ciclo de vida de uma função não termina na sua criação. A certificação de acessos, o tratamento de exceções e a desativação associados a eventos de joiner-mover-leaver (entrada, mudança e saída de colaboradores) impedem que o privilege creep se acumule sem ser detetado.
O que é uma política de controlo de acessos
Uma política de controlo de acessos é um conjunto documentado de regras que determina quem pode aceder a um recurso, em que condições e que ações pode executar depois de lhe ser concedido o acesso. Substitui o juízo caso a caso por uma lógica fixa e auditável, que escala à medida que aumentam a base de utilizadores e o número de recursos da organização.
Toda a política de controlo de acessos assenta num modelo de controlo de acesso, o mecanismo que determina como uma decisão de acesso é efetivamente tomada. Quatro modelos abrangem a maioria das implementações empresariais:
- DAC (controlo de acesso discricionário): o proprietário do recurso decide quem tem acesso, caso a caso, sem qualquer passo de aprovação central.
- MAC (controlo de acesso obrigatório): o acesso é fixado por níveis de classificação aplicados pelo sistema e nenhum indivíduo o pode alterar, independentemente da sua função. O NIST associa o MAC sobretudo a sistemas de elevada garantia que tratam dados classificados ou altamente sensíveis.
- RBAC (controlo de acesso baseado em funções): o acesso corresponde à função do utilizador na organização e não à sua identidade individual.
- ABAC (controlo de acesso baseado em atributos): o acesso depende de atributos dinâmicos, como o departamento, a localização, a hora do dia ou a postura de segurança do dispositivo, avaliados no momento do pedido. NIST SP 800-162 define o quadro formal que os sistemas federais utilizam para o ABAC.
O RBAC adequa-se à maioria dos ambientes empresariais porque as funções profissionais mudam com muito menos frequência do que os atributos individuais ou a titularidade dos recursos, e corresponde diretamente à forma como as organizações já estruturam o trabalho, por função e não por pessoa.
É essa estabilidade que explica por que razão este artigo constrói a sua metodologia de desenho de políticas especificamente em torno do RBAC. Os mesmos princípios de governação (mapear recursos, codificar restrições, aplicar o acesso na camada de credenciais) aplicam-se a qualquer dos quatro modelos acima, mas é no RBAC que a gestão de credenciais empresarial passa a maior parte do tempo.
Fundamentos do RBAC: O que a política de controlo de acessos rege
O RBAC organiza o acesso em torno de três elementos essenciais: utilizadores, funções e permissões. A política de controlo de acessos é o documento que especifica como estes elementos se relacionam numa organização concreta: que funções existem, que permissões cada função inclui, como as funções herdam umas das outras e em que condições de sessão o acesso é válido.
Três elementos compõem o modelo base:
- Os utilizadores são atribuídos a uma ou mais funções e nunca recebem permissões diretamente
- As funções agrupam um conjunto de permissões associado a uma atividade profissional, e não a uma pessoa
- As permissões são autorizações para realizar operações específicas, como ler, escrever, eliminar ou aprovar, sobre recursos específicos
A formalização original do RBAC surgiu com David Ferraiolo e Richard Kuhn, do NIST, em 1992. Quatro anos depois, Ravi Sandhu e colegas alargaram o modelo em quatro níveis de complexidade crescente: RBAC0 (o modelo base simples descrito acima), RBAC1 (acrescenta a hierarquia de funções), RBAC2 (acrescenta restrições como a segregação de funções) e RBAC3 (combina ambos). Hoje, a maioria das implementações empresariais situa-se algures entre o RBAC1 e o RBAC2, sem lhe atribuir esse nome.
Nada disto funciona sem uma especificação escrita. O documento da política deve definir:
- A convenção de nomenclatura das funções
- Quem tem autoridade para criar uma nova função
- Como são atribuídas as permissões a uma função
- Que restrições de sessão se aplicam às funções sensíveis
Sem essa especificação, a configuração do RBAC torna-se ad hoc, e cada nova contratação transforma-se numa decisão pontual em vez da aplicação de uma política.
O RBAC Policy Design Canvas: Modelo de 6 passos
O RBAC Policy Design Canvas é uma metodologia de seis passos para construir de raiz uma política de RBAC empresarial: mapear recursos, definir a granularidade das funções, modelar hierarquias, codificar o princípio do menor privilégio e a segregação de funções, documentar a política e estabelecer a aplicação e a cadência de revisão. Cada passo produz um artefacto concreto, e não apenas uma discussão.
Esta sequência é importante. Avançar diretamente para a criação de funções, sem um inventário do panorama de acessos, é a razão mais comum pela qual as organizações acabam com funções que não correspondem a atividades profissionais reais. Saltar o passo de aplicação é a razão pela qual as políticas são escritas uma vez e nunca cumpridas.
Passo 1: Mapear o panorama de recursos e acessos da organização
Antes de definir uma única função, inventarie o que precisa de ser protegido: aplicações, bases de dados, componentes de infraestrutura, partilhas de ficheiros e serviços de terceiros. Para cada recurso, registe a sensibilidade dos dados, quem tem atualmente acesso e como esse acesso foi concedido.
Este passo expõe quase de imediato a diferença entre o acesso presumido e o acesso real. Numa organização de média dimensão, com 500 ou mais colaboradores e mais de 30 aplicações, é de esperar que este inventário revele acessos concedidos que ninguém sabe explicar: antigos membros de projetos com permissões residuais, contas de serviço com acesso ao nível de utilizadores humanos e contas partilhadas sem responsável. Documente-os como constatações, ainda não como correções.
Passo 2: Definir regras de granularidade contra a explosão de funções
A explosão de funções ocorre quando as funções são criadas por pessoa ou por exceção, em vez de por atividade profissional. Defina uma regra rígida antes de criar qualquer função: uma função deve corresponder a uma atividade desempenhada por três ou mais pessoas, caso contrário não é criada como função autónoma.
Para a rara exceção individual, utilize uma concessão de permissão suplementar sobre uma função existente, em vez de uma função à medida. Esta regra única, aplicada desde o primeiro dia, é o controlo mais eficaz contra a proliferação de funções. As organizações que a ignoram descobrem, em regra, entre 300 e 500 funções para algumas centenas de colaboradores ao fim de dois anos.
Passo 3: Modelar hierarquias de funções e estruturas de herança
Agrupe as funções numa hierarquia que reflita a estrutura organizacional e a antiguidade, e não a política interna do organigrama. Um modelo hierárquico (RBAC1, na taxonomia de Sandhu) permite que as funções seniores herdem automaticamente as permissões das funções juniores, o que reduz as atribuições de permissões redundantes.
Mantenha a profundidade da hierarquia reduzida, em geral de três a quatro níveis. As hierarquias mais profundas tornam-se difíceis de auditar, porque uma permissão concedida no topo pode propagar-se por cadeias de herança que ninguém rastreia durante uma revisão. Os modelos planos são mais fáceis de auditar, mas exigem mais atribuições explícitas de permissões por função.
Passo 4: Codificar menor privilégio e segregação de funções
O princípio do menor privilégio e a segregação de funções são as duas restrições que transformam uma lista de funções numa política governada. De acordo com a NIST SP 800-53 Revisão 5, o controlo AC-6 exige que as organizações apliquem o princípio do menor privilégio, permitindo apenas os acessos autorizados necessários à execução das tarefas atribuídas (NIST SP 800-53 Rev. 5). O controlo AC-5 exige a segregação de funções, repartindo as tarefas críticas por pessoas diferentes para reduzir o risco de fraude e de erro.
Na prática, isto significa escrever regras de conflito explícitas na política: a função que aprova ordens de compra não pode ser também a função que cria registos de fornecedores. Estas regras devem ser codificadas como restrições documentadas, verificadas pelo processo de revisão de acessos, e não como conhecimento tácito na posse de um único responsável pela conformidade.
Passo 5: Documentar a política num formato vivo e auditável
Documente a finalidade de cada função, as permissões que inclui, o responsável pela aprovação e a data da última revisão, num formato estruturado e sujeito a controlo de versões, que auditores e novos administradores consigam ler sem ter de fazer engenharia inversa ao sistema de acessos.
Este documento torna-se a referência que o auditor confronta com o estado real do sistema. As discrepâncias entre o documento e a realidade são exatamente o que as auditorias de conformidade foram concebidas para detetar.
Passo 6: Estabelecer a aplicação e a cadência de revisão
Uma política sem aplicação é apenas uma declaração de intenções. Aplicar a política significa que cada concessão de acesso passa por um ponto de aplicação de políticas (policy enforcement point), um ponto de controlo técnico ou procedimental que verifica se o pedido corresponde à política documentada antes de conceder o acesso, seja um sistema IAM, um fluxo de aprovação ou um cofre de credenciais.
Associe a aplicação a uma cadência de revisão fixa: certificação trimestral de acessos para as funções padrão e revisão mais frequente para as funções privilegiadas e administrativas. A certificação de acessos, a reaprovação periódica de quem detém que acesso, é o mecanismo que deteta o privilege creep antes de este se tornar uma constatação de auditoria.
Mapeamento de conformidade: Controlos que a política RBAC deve cobrir
As políticas de RBAC empresariais correspondem diretamente a controlos específicos da NIST SP 800-53, do Anexo A da ISO 27001, do SOC 2 e, para as entidades reguladas na UE, da Diretiva NIS2, e não a formulações vagas sobre «gestão de acessos». Os auditores verificam estes controlos por identificador, e uma política que não os refira explicitamente torna a recolha de evidências mais lenta e as constatações de auditoria mais prováveis.
- A família de controlo de acesso (AC) da NIST SP 800-53 Revisão 5 define a base de referência. O AC-2 (gestão de contas) exige um processo documentado de criação, ativação, modificação e desativação de contas. O AC-5 (segregação de funções) exige a repartição de tarefas entre pessoas para reduzir o risco de conluio. O AC-6 (menor privilégio) exige a restrição do acesso ao que uma função necessita (NIST SP 800-53 Rev. 5).
- A ISO 27001:2022 reestruturou os controlos do Anexo A em quatro temas, num total de 93 controlos, em substituição dos domínios numerados da versão de 2013 (A.9 para o controlo de acessos). Os controlos equivalentes de 2022 relevantes para o RBAC são 5.15 (Controlo de acesso), 5.16 (Gestão de identidades), 5.18 (Direitos de acesso) e 8.2 (Direitos de acesso privilegiado), que em conjunto exigem uma política formal de controlo de acessos, o registo controlado de utilizadores e a gestão de acessos privilegiados (ISO/IEC 27001:2022).
- Os Trust Services Criteria do SOC 2 abordam o mesmo território nos pontos CC6.1 a CC6.3, que abrangem os controlos de acesso lógico, o registo e a remoção de registo de utilizadores e o aprovisionamento baseado em funções alinhado com o princípio do menor privilégio.
Para as organizações abrangidas pela Diretiva NIS2 da UE, o artigo 21.º, n.º 2, alínea i), refere expressamente as políticas de controlo de acessos e a gestão de ativos entre as medidas de gestão de riscos de cibersegurança exigidas, o que coloca a documentação de RBAC ao mesmo nível dos requisitos de tratamento de incidentes e de segurança da cadeia de abastecimento previstos no mesmo artigo (Diretiva (UE) 2022/2555, artigo 21.º).
| Quadro de controlos | ID do controlo | Requisito | Elemento da política RBAC |
|---|---|---|---|
| NIST SP 800-53 Rev. 5 | AC-2 | Ciclo de vida da gestão de contas | Procedimentos de criação, modificação e desativação de funções |
| NIST SP 800-53 Rev. 5 | AC-5 | Segregação de funções | Regras documentadas de conflito entre funções |
| NIST SP 800-53 Rev. 5 | AC-6 | Princípio do menor privilégio | Definição granular das permissões por função |
| ISO 27001:2022 | 5.15 | Política de controlo de acessos | Documento escrito da política de RBAC |
| ISO 27001:2022 | 5.16 | Gestão de identidades | Processo de atribuição de utilizadores a funções |
| ISO 27001:2022 | 8.2 | Direitos de acesso privilegiado | Revisão e aprovação de funções elevadas |
| SOC 2 | CC6.1 | Controlos de acesso lógico | Pontos de aplicação de políticas |
| SOC 2 | CC6.2 | Registo e autorização | Fluxo de atribuição de funções na integração |
| SOC 2 | CC6.3 | Aprovisionamento baseado em funções | Menor privilégio e certificação de acessos |
| Diretiva NIS2 | Art. 21.º, n.º 2, alínea i) | Políticas de controlo de acessos e gestão de ativos | Política de RBAC como medida nomeada de gestão de riscos |
Armazenamento em cofre como aplicação do RBAC: A camada em falta
As definições de funções não têm qualquer valor se as credenciais que lhes correspondem estiverem escritas numa folha de cálculo ou forem conhecidas por pessoas fora da função. Uma política de RBAC que se fica pela camada aplicacional, a que decide quem pode clicar em quê dentro de uma aplicação, ignora a camada onde ocorre a maior parte dos danos reais: as credenciais, as chaves de API e os segredos que concedem acesso direto aos sistemas.
O Ponemon Institute, no relatório 2025 Cost of Insider Risks Global Report, estima o custo médio anual dos incidentes de risco interno em 17,4 milhões de dólares por organização, face a 16,2 milhões de dólares em 2023. Neste total, as credenciais comprometidas são a categoria de incidentes mais dispendiosa, com uma média de 779 000 dólares por evento, valor superior ao dos incidentes causados apenas por negligência ou por intenção maliciosa. Uma grande parte destes incidentes remonta a credenciais partilhadas ou órfãs que sobreviveram ao processo de revisão de acessos porque ninguém era responsável por elas ao nível da credencial, apenas ao nível da aplicação.
O armazenamento de credenciais em cofre elimina esta lacuna ao associar o acesso aos segredos a funções e não a indivíduos, o mesmo princípio que o RBAC aplica às permissões das aplicações. Quando a função de engenheiro de DevOps recebe acesso a um segredo de um pipeline de CI/CD através do gestor de palavras-passe e segredos Passwork, a política é aplicada na camada de credenciais e não apenas dentro da aplicação:
- Ao adicionar alguém à função, esse utilizador herda exatamente os segredos de que a função necessita, nem mais nem menos
- Ao remover essa pessoa, o acesso a todas as credenciais associadas à função é revogado de imediato
Isto é particularmente relevante para a gestão de acessos privilegiados (PAM). As credenciais de administração permanentes, as palavras-passe root de bases de dados e as chaves de fornecedores de cloud são os ativos que os atacantes visam primeiro, e são também os ativos com maior probabilidade de acabar num documento partilhado quando não existe uma camada de armazenamento em cofre. O registo de auditoria do Passwork documenta cada obtenção de credenciais por função e por utilizador, o que dá aos responsáveis pela conformidade o mesmo rasto de evidências para os segredos que a certificação de acessos já proporciona para as funções das aplicações.
A governação de contas partilhadas é o modo de falha específico que isto resolve: um único início de sessão de service ou admin utilizado por seis pessoas porque ninguém criou contas individuais para um sistema legado. Um cofre com acesso baseado em funções permite que essas seis pessoas mantenham a comodidade de uma credencial partilhada e preservem a responsabilização individual, uma vez que cada obtenção é registada em nome da pessoa e não apenas da conta.
Governação do ciclo de vida das funções: Da criação à desativação
A política de RBAC rege uma função desde o momento em que é criada até ao momento em que é desativada, segundo um ciclo joiner-mover-leaver (JML) a que a maioria das falhas de auditoria remonta, por via de saídas de colaboradores ou mudanças de função tratadas de forma incompleta. Uma função que não é retirada quando a atividade que lhe deu origem desaparece torna-se precisamente o tipo de acesso órfão de que o privilege creep se alimenta.
O ciclo de vida divide-se em quatro fases governadas:
- Criação de funções exige uma justificação de negócio documentada, um responsável pela aprovação e o mapeamento com as regras de granularidade definidas na fase de desenho da política. Nenhuma função é criada sem passar por este ponto de controlo.
- Certificação de acessos é a reaprovação periódica de cada atribuição de utilizador a função, tipicamente trimestral para as funções padrão e mensal para as privilegiadas. Este é o controlo que deteta o privilege creep, a acumulação gradual de direitos de acesso que sobrevivem à sua justificação à medida que os colaboradores mudam de equipa ou de projeto.
- Tratamento de exceções abrange as concessões de acesso temporárias que ficam fora das funções padrão, como um prestador externo que precisa de acesso com prazo limitado a um sistema de produção. Estas devem expirar automaticamente, em vez de depender de alguém se lembrar de as revogar.
- Desativação de funções retira as funções e o respetivo acesso associado quando a atividade subjacente deixa de existir, segundo o mesmo processo de aprovação da criação, mas em sentido inverso.
O modelo joiner-mover-leaver associa este ciclo de vida a eventos reais de emprego: a entrada de um colaborador (joiner) implica o aprovisionamento numa função, a mudança de função de um colaborador (mover) desencadeia o desaprovisionamento da função anterior e o aprovisionamento na nova, e a saída (leaver) desencadeia o desaprovisionamento imediato em todos os sistemas.
Erros comuns no desenho de políticas RBAC e como evitá-los
A maioria das falhas de RBAC empresariais remonta a cinco erros recorrentes: explosão de funções, atribuição de funções por copiar e colar, ignorar as identidades de máquina, políticas estáticas sem ciclos de revisão e confundir o RBAC com o início de sessão único (SSO). Cada um é evitável com um controlo específico da política.
- Explosão de funções. Criar uma função única por pessoa em vez de por atividade profissional gera centenas de funções que ninguém consegue auditar. Solução: aplique a regra das três pessoas no mínimo, do passo 2 do canvas de desenho, antes de criar qualquer função.
- Atribuição de funções por copiar e colar. Conceder a um novo colaborador «o mesmo acesso que [colaborador existente]» propaga os erros de acesso que esse colaborador já acumulou, incluindo permissões que deveria ter perdido há meses. Solução: atribua funções com base na atividade profissional documentada e nunca pela cópia do estado atual de outro utilizador.
- Ignorar as contas de serviço e as identidades de máquina. As políticas de RBAC definem frequentemente as funções humanas com pormenor, enquanto as contas de serviço, as chaves de API e as credenciais de automação são aprovisionadas totalmente fora da política, muitas vezes com privilégios permanentes excessivos. Solução: integre todas as identidades não humanas na mesma estrutura de funções e na mesma cadência de revisão das funções humanas.
- Política estática sem ciclos de revisão periódicos. Um documento de política escrito uma só vez e nunca revisto afasta-se da configuração real do sistema em poucos meses. Solução: associe cada função a uma data de revisão obrigatória, imposta pelo processo de certificação de acessos e não deixada ao critério de cada um.
- Confundir o RBAC com o início de sessão único. O SSO controla a autenticação, ou seja, verifica quem é a pessoa. O RBAC controla a autorização, ou seja, determina o que essa pessoa pode fazer depois de verificada. As organizações que tratam a implementação do SSO como «a solução do controlo de acessos» deixam a camada de autorização por definir. Solução: trate o desenho da política de RBAC como um projeto separado da implementação do SSO, mesmo quando ambos decorrem em simultâneo.
RBAC para identidades não humanas: Contas de serviço, APIs e agentes de IA
As identidades não humanas (contas de serviço, chaves de API e, cada vez mais, agentes de IA autónomos) já superam em número as contas de utilizadores humanos na maioria dos ambientes empresariais, mas os modelos RBAC foram concebidos em torno de sessões humanas e raramente contemplam os padrões de acesso máquina a máquina. Alargar a política de RBAC para as abranger deixou de ser opcional.
Uma conta de serviço que executa uma cópia de segurança noturna da base de dados não se ajusta ao modelo de sessão que o RBAC pressupõe: não há ecrã de início de sessão, não há restrições de sessão interativa e há muitas vezes uma credencial que nunca é rodada, porque rodá-la implica o risco de interromper uma tarefa de produção. As chaves de API agravam o problema: uma única chave exposta pode conceder o mesmo acesso que uma função administrativa completa, mas a gestão de chaves vive muitas vezes fora do sistema IAM, registada em ficheiros de configuração ou variáveis de ambiente em vez de num cofre governado.
Os agentes de IA introduzem uma variante mais recente: um agente que atua em nome de um utilizador ou de um sistema e que precisa de permissões delimitadas e auditáveis, e não do acesso alargado que convém ao desenvolvimento. Trate as credenciais de agentes da mesma forma que a função de um prestador externo: com prazo limitado, estritamente delimitadas e revistas com a mesma cadência do acesso privilegiado humano, sem isenção da política só porque o requerente não é uma pessoa.
A solução prática é estrutural: integrar as identidades não humanas na mesma hierarquia de funções, nas mesmas regras de granularidade e no mesmo ciclo de certificação de acessos definidos para os humanos no RBAC Policy Design Canvas. Um cofre de credenciais que permita o acesso baseado em funções para chaves de API e segredos de contas de serviço, e não apenas para inícios de sessão humanos, fecha a lacuna entre a política e a prática neste ponto.
Construir a política que faz o RBAC funcionar
Uma implementação de RBAC vive ou morre pela qualidade da sua política. As organizações que evitam a explosão de funções, o privilege creep e o caos de auditoria são as que mapearam o seu panorama de acessos, escreveram regras de granularidade e estabeleceram uma cadência de revisão antes de atribuir uma única permissão.
O RBAC Policy Design Canvas fornece essa sequência. O mapeamento de conformidade fornece os identificadores de controlo concretos sobre os quais um auditor vai perguntar. Resta a aplicação: uma política bem desenhada especifica que funções acedem a que recursos, mas permanece teórica até que algo associe as credenciais a essas funções de forma automática.
Comece por um recurso de risco elevado, percorra os seis passos do canvas e utilize o resultado como modelo para o resto da organização.
Perguntas frequentes
Qual é a diferença entre uma política de controlo de acessos e uma política de RBAC?
Uma política de controlo de acessos é o documento de governação mais amplo, que abrange todos os modelos de autorização utilizados por uma organização. Uma política de RBAC é uma implementação específica dessa política mais ampla, que define funções, permissões e regras de atribuição de funções. Toda a política de RBAC é uma política de controlo de acessos, mas nem toda a política de controlo de acessos utiliza exclusivamente o RBAC.
Como se desenha o RBAC de raiz numa organização sem funções existentes?
Comece pelo passo 1 do RBAC Policy Design Canvas: inventarie todos os recursos, aplicações e repositórios de dados da organização. Em seguida, aplique a mineração de funções (role mining) para mapear os padrões reais de acesso dos utilizadores a atividades profissionais, defina as regras de granularidade antes de criar qualquer função e documente a política com uma cadência de revisão fixa.
Quem deve ser o responsável pela política de RBAC: a TI, a segurança ou os RH?
A segurança ou a TI são, tipicamente, responsáveis pela implementação técnica e pela aplicação, enquanto os RH fornecem os eventos de joiner-mover-leaver que desencadeiam a atribuição de funções. Nenhuma deve assumir essa responsabilidade sozinha. As políticas eficazes designam um responsável nomeado pela política, na área de segurança ou de conformidade, com os RH e os responsáveis das unidades de negócio como aprovadores obrigatórios da criação de funções.
Como tratar o acesso de prestadores externos e de terceiros no RBAC?
Crie funções separadas e com prazo limitado para os prestadores externos, em vez de lhes conceder as funções padrão dos colaboradores. Defina uma data de expiração automática associada à data de fim do contrato, restrinja as condições de sessão ao horário laboral sempre que viável e exija uma certificação de acessos mais frequente para as funções de prestadores externos do que para as de colaboradores a tempo inteiro.
Como evitar a explosão de funções?
Imponha um limiar mínimo, como três ou mais pessoas a desempenhar a mesma atividade, antes de criar uma função autónoma. Trate as exceções individuais com concessões de permissões suplementares sobre uma função existente, em vez de criar novas funções, e compare o número total de funções com o número de colaboradores em cada ciclo de certificação.
Alex Muntyan
Alex Muntyan
Passwork Team