Esta aplicação auto-hospedada dá às pessoas apenas o acesso de que precisam? Uma checklist de avaliação de RBAC
Use esta checklist prática para avaliar funções, permissões, limites administrativos, acesso à API e processos de ciclo de vida dos utilizadores antes de mover utilizadores e dados para uma aplicação auto-hospedada.
Porque é que o desenho do controlo de acesso deve anteceder a implementação
Uma migração pode tornar uma aplicação tecnicamente disponível, mas deixar a organização com uma solução inadequada para a forma como o trabalho está realmente dividido. Se as equipas de finanças, vendas, operações, serviços ao cliente e prestadores precisam de realizar ações diferentes sobre registos diferentes, valide esse modelo antes de importar dados de produção ou convidar utilizadores.
O controlo de acesso baseado em funções (RBAC) baseia-se em identificar as operações exigidas por determinadas funções profissionais, atribuir pessoas a funções e atribuir privilégios a essas funções. Por isso, a pergunta importante para quem avalia uma solução não é «Diz que tem RBAC?», mas sim «Conseguimos expressar e operar as decisões de acesso de que precisamos nesta aplicação?».
Trate o princípio do privilégio mínimo como um critério de desenho: cada pessoa deve receber os privilégios mínimos necessários para o seu trabalho. Pessoas com um nível de senioridade semelhante podem continuar a necessitar de acessos muito diferentes porque as suas responsabilidades são diferentes. A OWASP também recomenda a autorização com negação por defeito, o que significa que o acesso deve ser explicitamente permitido, e não assumido.
- Avalie as permissões durante a seleção, e não depois de uma implementação em produção ter tornado difícil reverter acessos amplos.
- Não equipare o uso do termo «RBAC» por uma aplicação a capacidades avançadas. O NIST distingue a atribuição básica de funções das hierarquias de funções opcionais e das funcionalidades de separação de funções.
- Faça com que a adequação do modelo de acesso seja um critério para avançar com a migração, a par da importação de dados, integrações, autenticação e requisitos de cópias de segurança.
Comece pelos grupos reais de utilizadores e pelas ações que cada grupo tem de realizar
Comece pelo trabalho, não pelos nomes de funções predefinidos da aplicação. Entreviste as pessoas responsáveis por cada processo de negócio e registe o menor conjunto prático de ações que têm de concluir. Inclua o trabalho normal, exceções, aprovações, exportações, eliminações, administração de utilizadores e alterações de configuração.
Evite rótulos de funções que ocultam privilégios amplos. «Gestor», «editor» ou «membro» não são requisitos de permissão. Um requisito útil indica um verbo, um objeto e um âmbito: por exemplo, «criar registos no espaço de trabalho atribuído», «ver projetos pertencentes ao cliente» ou «exportar apenas relatórios agregados».
Inclua requisitos negativos. São as ações ou os dados aos quais um grupo não deve poder aceder, alterar, divulgar ou aprovar. Frequentemente, revelam lacunas que uma lista de ações permitidas não identifica.
- Liste as populações de utilizadores: colaboradores, líderes de equipa, executivos, trabalhadores temporários, prestadores, clientes, parceiros, auditores e administradores técnicos.
- Para cada população, liste as ações: ver, criar, editar, comentar, atribuir, aprovar, eliminar, exportar, partilhar, configurar e administrar.
- Defina o âmbito de cada ação: registos próprios, registos atribuídos, registos da equipa, um espaço de trabalho, uma conta de cliente, todos os registos ou nenhum registo.
- Identifique campos sensíveis e ações de elevado impacto separadamente do acesso normal a conteúdos.
Identifique o modelo de acesso da aplicação: funções, grupos, objetos e limites
Peça ao fornecedor ou à documentação do projeto que apresente o modelo de acesso exato da versão que pretende implementar. Registe o que está documentado, o que pode ser demonstrado numa instância de teste e o que permanece incerto. Não preencha lacunas com pressupostos baseados noutra aplicação ou num nome de função familiar.
No mínimo, determine se as permissões são atribuídas através de funções fixas, funções personalizadas, grupos, concessões diretas a utilizadores ou uma combinação destes elementos. Em seguida, determine o âmbito em que essas permissões se aplicam: toda a instância, uma organização, uma equipa, um espaço de trabalho, um projeto, uma coleção, um registo ou um campo.
Um limite de espaço de trabalho só pode ser útil se restringir realmente o acesso da forma necessária. Teste se as pessoas podem pesquisar entre limites, seguir ligações para outros objetos, receber notificações com informação restrita, exportar dados que abrangem vários limites ou obter acesso através de associação herdada.
- É possível criar uma função que corresponda a cada requisito, sem atribuir privilégios não relacionados?
- As funções são globais ou podem variar por espaço de trabalho, projeto, cliente ou outro limite de negócio?
- As permissões podem ser definidas ao nível do objeto ou do campo quando o seu risco o exige?
- São suportadas hierarquias de funções e, em caso afirmativo, os privilégios herdados continuam compreensíveis e passíveis de revisão?
- As concessões diretas podem contornar o modelo normal de funções e como serão encontradas essas exceções durante a revisão?
- O que acontece ao acesso quando um objeto, espaço de trabalho ou utilizador é movido ou copiado?
Teste a separação entre a administração e o acesso a dados empresariais sensíveis
A administração operacional e o acesso a dados empresariais são responsabilidades diferentes. Uma equipa pode precisar de alguém para gerir utilizadores, encaminhamento, cópias de segurança ou disponibilidade da aplicação sem consultar habitualmente informações confidenciais de clientes, colaboradores ou finanças. Confirme se a aplicação suporta essa distinção, em vez de assumir que um administrador pode ser adequadamente limitado.
A separação de funções trata de saber se uma pessoa tem privilégios suficientes para usar indevidamente um sistema sozinha. Pode ser implementada através de funções incompatíveis atribuídas antecipadamente ou através de controlos que restringem uma ação incompatível no momento do acesso. A necessidade de qualquer uma das abordagens depende do seu processo e risco, mas a questão deve ser explícita para ações de elevado impacto.
Mapeie também o limite da infraestrutura. A Docker alerta que o controlo de um daemon Docker é altamente privilegiado e pode fornecer acesso de root no anfitrião. Do mesmo modo, as interfaces administrativas de apoio exigem revisão; a Traefik refere que uma API ou painel de controlo em produção pode expor elementos de configuração, incluindo dados sensíveis, e deve ser protegido com autenticação e autorização.
- Um administrador de utilizadores pode criar contas e repor acessos sem ler registos empresariais normais?
- Um administrador de conteúdos ou de espaço de trabalho pode gerir associações sem receber privilégios irrestritos de exportação ou configuração?
- Quem pode alterar funções, criar contas privilegiadas, modificar definições de autenticação, aceder a cópias de segurança ou gerir a implementação?
- As ações sensíveis são registadas de uma forma que a organização possa rever?
- Para operações de alto risco, devem ser necessárias duas pessoas distintas para o pedido e a aprovação?
Verifique colaboradores externos, prestadores e utilizadores clientes
Os utilizadores externos revelam frequentemente a diferença entre uma função geral de colaboração e um modelo seguro de acesso para clientes. O seu acesso pode exigir uma expiração curta, um conjunto limitado de projetos, nenhuma visibilidade do diretório, nenhum direito de exportação e nenhuma capacidade para convidar outras pessoas. Teste estes requisitos com as funcionalidades reais de partilha e associação da aplicação.
Não assuma que uma interface restrita significa dados restritos. Verifique a que pode aceder a conta externa através de pesquisa, URLs diretos, notificações, anexos de ficheiros, comentários, exportações e APIs. Teste um utilizador cliente com registos representativos de outro cliente, e não apenas num ambiente vazio.
Se a aplicação não conseguir expressar o limite necessário, uma instância separada, um espaço de trabalho separado com controlos cuidadosamente validados, um processo de partilha diferente ou uma aplicação diferente podem ser mais seguros. A resposta certa depende da sensibilidade dos dados e das consequências de um erro.
- O acesso externo pode ser limitado a utilizadores nomeados e a âmbitos de negócio definidos?
- Os convites podem expirar e o acesso pode ser removido prontamente?
- Os utilizadores externos conseguem descobrir outros utilizadores, equipas, clientes ou registos?
- Podem transferir, exportar, copiar ou voltar a partilhar informações?
- Podem criar utilizadores, convidar colaboradores ou alterar associações?
- A organização pode rever todas as contas externas ativas e os respetivos acessos?
Avalie separadamente tokens de API, contas de serviço e integrações
As permissões da interface humana não provam que as integrações são seguras. As APIs podem expor funções administrativas ou sensíveis se a autorização ao nível do endpoint estiver em falta ou for demasiado abrangente. A OWASP identifica especificamente a autorização quebrada ao nível da função como um risco quando endpoints administrativos estão acessíveis sem verificações adequadas.
Faça o inventário de todas as identidades não humanas: tokens de API, credenciais de integração, utilizadores de automação, contas de serviço e webhooks, quando aplicável. Para cada uma, identifique o proprietário, a finalidade, as permissões, o âmbito, o local de armazenamento, o processo de rotação e o método de revogação. Um token não deve herdar o acesso omnipotente de um administrador humano apenas porque era conveniente criá-lo.
Teste as integrações utilizando os mesmos âmbitos representativos aplicados às pessoas. Uma integração de relatórios que necessita de dados agregados não deve receber automaticamente a capacidade de modificar registos ou administrar utilizadores. Mantenha distintas as credenciais de desenvolvimento, teste e produção quando o seu modelo operacional suportar essa separação.
- A aplicação suporta credenciais com âmbito limitado ou cada token equivale, na prática, a acesso total à conta?
- Os tokens podem ser atribuídos a um proprietário individual ou a uma finalidade de serviço identificada?
- As permissões podem ser limitadas por ação, âmbito do recurso ou expiração?
- Um token pode ser revogado sem desativar integrações não relacionadas?
- As respostas da API respeitam os mesmos limites pretendidos que a interface de utilizador?
- Os endpoints e as funções administrativas são testados explicitamente, em vez de inferidos a partir de restrições da interface?
Crie uma matriz de testes de permissões com registos representativos e contas que não são de produção
Uma matriz de testes de permissões transforma requisitos de acesso em evidência. Crie utilizadores de teste representativos para cada função, incluindo uma conta deliberadamente com poucos privilégios e uma conta externa. Crie registos representativos que cubram cenários normais, confidenciais, entre equipas, entre clientes, arquivados e de transferência de propriedade relevantes para a sua organização.
Para cada função e ação, indique o resultado esperado: permitido, negado ou permitido apenas num âmbito identificado. Teste através de todos os caminhos disponíveis, incluindo a interface de utilizador, ligações diretas, pesquisa, exportações, ações em massa, clientes móveis se utilizados, notificações e APIs. Os testes de autorização devem abranger caminhos negados, bem como percursos de utilizador bem-sucedidos.
Volte a testar quando funções, integrações, fluxos de trabalho importantes ou funcionalidades da aplicação mudarem. A OWASP observa que os problemas de autorização surgem frequentemente quando são adicionadas ou alteradas funcionalidades sem reavaliar o comportamento de autorização.
- Use linhas para funções representativas e colunas para ações e âmbitos de dados.
- Registe os resultados esperados e observados, além de evidências como data do teste, nome da conta e referência do resultado.
- Teste ações de leitura, criação, edição, eliminação, partilha, exportação, convite, alteração de função e configuração, quando relevante.
- Inclua tentativas de acesso a dados de outra equipa, cliente ou espaço de trabalho.
- Adicione testes de regressão para as regras de autorização de maior risco quando a sua equipa tiver capacidade para tal.
Planeie os processos de entrada, mudança e saída
Mesmo um modelo de funções bem desenhado falha se as contas e associações não forem mantidas atualizadas. Defina como uma pessoa obtém acesso, altera o acesso quando muda de função ou atribuição a um cliente e perde o acesso quando termina o emprego, contrato ou projeto. Atribua um responsável identificado a cada passo e estabeleça uma cadência de revisão operacional adequada ao risco.
Se a aplicação suportar SCIM, o protocolo disponibiliza operações para recursos de Utilizador e Grupo, incluindo a sua criação, obtenção, modificação e eliminação. Isto pode apoiar fluxos de trabalho de aprovisionamento, mas não decide os seus gatilhos de ciclo de vida, desenho de funções, regras de transferência de propriedade ou tratamento de exceções. Estas continuam a ser responsabilidades organizacionais.
Preste especial atenção à propriedade. Antes de desativar uma conta, determine quem será proprietário dos registos, projetos, filas, ficheiros, automatizações, relatórios e credenciais de integração ativos associados a esse utilizador. Confirme que a transferência não alarga involuntariamente o acesso do destinatário.
- Entrada: verifique a identidade, selecione a função aprovada, defina o âmbito correto e registe o gestor ou proprietário que aprovou.
- Mudança: remova acessos obsoletos antes de, ou ao mesmo tempo que, adiciona novos acessos; reveja concessões diretas e associações externas.
- Saída: desative ou remova o acesso, revogue tokens, transfira a propriedade e reveja recursos partilhados.
- Data de fim de prestador ou cliente: utilize uma revisão agendada e confirme a remoção, em vez de depender de uma tarefa manual de que alguém se lembre.
- Reveja periodicamente as contas privilegiadas, externas, inativas e de exceção.
Perguntas frequentes
O que deve incluir uma checklist de RBAC para uma aplicação auto-hospedada?
Inclua grupos reais de utilizadores, ações necessárias e proibidas, âmbito dos dados, funções e grupos, limites de espaço de trabalho ou de objetos, separação administrativa, controlos para utilizadores externos, permissões de API e contas de serviço, uma matriz de testes de permissões e processos de entrada, mudança e saída. Documente o que foi demonstrado em comparação com o que é apenas assumido.
O alojamento gerido fornece RBAC à aplicação?
A infraestrutura gerida e a autorização da aplicação resolvem problemas diferentes. A Airbip gere a infraestrutura de cloud em torno de implementações de aplicações baseadas em Docker, incluindo encaminhamento, certificados TLS, gestão do ciclo de vida e cópias de segurança configuráveis. O cliente continua a ter de selecionar uma aplicação cujo modelo de permissões se adeque à organização, definir funções e âmbitos de acesso e operar a governação de acessos de forma apropriada.
Uma função chamada administrador é sempre demasiado poderosa?
Não necessariamente, mas tem de ser testada. Determine exatamente o que o administrador pode ver, alterar, exportar e delegar, e se a administração operacional pode ser separada do acesso a dados empresariais sensíveis. Reveja também a administração da infraestrutura de apoio, pois esses privilégios podem ser altamente sensíveis.
Porque testar permissões de API se a interface de utilizador parece restrita?
As restrições da interface de utilizador não demonstram que os endpoints da API aplicam as mesmas regras de autorização. Teste as funções da API separadamente, especialmente funções administrativas, exportações e acesso entre âmbitos. Faça o inventário e restrinja tokens e contas de serviço de acordo com a sua finalidade específica.
Quando é que uma aplicação auto-hospedada não é a solução adequada para o modelo de acesso necessário?
Escolha outra aplicação ou abordagem de implementação quando os limites necessários não puderem ser expressos e verificados sem exceções amplas; quando os utilizadores externos não puderem ser isolados de forma suficientemente segura; quando ações sensíveis exigirem uma separação que o sistema não suporte; ou quando a equipa não conseguir operar as revisões de acesso, os testes e os processos de ciclo de vida necessários. Uma infraestrutura gerida não compensa um modelo de autorização ao nível da aplicação inadequado.
Fontes e leituras adicionais
- Role Based Access Control FAQs — National Institute of Standards and Technology
- Authorization Cheat Sheet — OWASP Foundation
- Authorization Testing Automation Cheat Sheet — OWASP Foundation
- API5:2023 Broken Function Level Authorization — OWASP Foundation
- Separation of Duty glossary entry — National Institute of Standards and Technology
- SP 800-53 Rev. 5 controls download page — National Institute of Standards and Technology
- RFC 7644: System for Cross-domain Identity Management Protocol — IETF
- Docker Engine security — Docker
- Protect the Docker daemon socket — Docker
- API & Dashboard — Traefik Labs