Ao ler sobre ACL e RBAC, pareço entendê-lo facilmente - existem nomes de usuários ou funções que têm acesso a um ativo. Eu também posso ver como eu poderia implementá-las.

ou seja, esta imagem fornece uma visão clara do ACL e do RBAC para mim (como em eu posso prosseguir e criar tabelas de banco de dados com base acima): (Imagem cortesia de pressbooks )

O que eu estou lutando é com o ABAC. Várias imagens que encontrei até agora são onduladas ou complicadas demais, ou sugerem o uso de uma entidade externa de terceiros para fazer a autorização. Ou dê exemplos de atributos estranhos que não sei ao certo como usar.

Exemplo inicial

Então, deixe-me começar com algo na vida real. Digamos que eu tenha uma empresa com 70 a 200 pessoas. E meu bem para proteger é um site com várias páginas. Desejo permitir que certas pessoas acessem certos ativos.

Por exemplo, quero que uma pessoa Leslietenha acesso a uma página da Web chamada Price Managere permita que ela gerencie apenas os preços do Travelgrupo de preços nessa página, mas não consiga gerenciar os preços do Productgrupo na mesma página. Como eu implementaria isso usando o ABAC?

Examinando até agora, meu palpite é que eu poderia atribuir Lesliealguns atributos (mas quais e quais são esses atributos?) E, em seguida, ter uma tabela de banco de dados armazenando-os. Posso então projetar um mecanismo que analise esses atributos (mas não pareça Lesliecomo uma "Função", como é feito no RBAC), e decida a partir daí se deve ou não conceder acesso à página. Como seria esse mecanismo? É um bloco if / else simples? Algo mais?

O que acontece se Leslie mais tarde mudar de posição e alguém precisar alterar seu acesso? Como será se ela precisar acessar Producte revogar o acesso Travel? Como será codificado se ela precisar ter acesso revogado à Price Managerpágina completamente e, portanto, não tiver mais acesso a nenhum Travel, ou Product?

O ativo no meu caso, apenas para reformular, é Price Manager, e um usuário pode acessar vários grupos de preços nessa página, como Travelpreços, Productpreços etc.

O que estou procurando é um roteiro razoavelmente completo para esclarecer os detalhes e para a implementação de onde eu poderia implementá-lo sem adivinhar. isto é, pode ser concluído conceitualmente e / ou ter um exemplo específico de onde eu posso visualizar uma estrutura de banco de dados, etc.

Bônus: O ABAC é uma maneira adequada para uma necessidade de permissão relativamente pequena, ou seja, gerenciando 70-200 pessoas e acesso a cerca de 150 a 450 ativos? Será melhor seguir o ACL / RBAC?

Uma implementação ABAC é mais complexa que o ACL / RBAC. Algumas estruturas fornecem até alguns bits de infraestrutura para lidar com esta última. Se as pessoas e os ativos puderem ser agrupados em um número relativamente pequeno e fixo de funções / categorias, provavelmente será melhor manter a ACL / RBAC. Se as permissões diferirem amplamente de pessoa para pessoa, o ABAC poderá fornecer uma solução melhor e mais flexível.

Se você optar por seguir o caminho ABAC, a primeira coisa a fazer é gastar algum tempo lendo e compreendendo o padrão XACML . Os exemplos fornecidos no documento usam sintaxe compatível com XACML e são um pouco difíceis de mastigar no início. Suponho que você não queira implementar uma solução compatível padrão, portanto, você só precisa das idéias gerais.

Conceitos

O XACML gira em torno de quatro conceitos e seus atributos: assuntos , ações , recursos e ambiente . Existem mais alguns, mas estes são os mais importantes. Tudo o resto é construído em cima deles. Se eu fosse fazer uma frase com esses conceitos, poderia ser algo como: sujeitos realizam ações sobre recursos em um determinado ambiente . A aplicação disso ao seu cenário se traduziria em algo como:

• Leslie abre a página da web do gerenciador de preços.
• Leslie cria um preço de viagem usando a página da web do gerenciador de preços.

Coleção de atributos

A primeira coisa que precisamos fazer é reunir os atributos relevantes dos conceitos declarados acima. Idealmente, você não deve atribuir nenhum atributo específico, pois o XACML tenta ser discreto e confiar apenas no que o sistema fornece naturalmente. E assim temos:

Sujeito

Qualquer ator, seja uma pessoa ou um serviço, em seu sistema. Nosso assunto é Leslie. Quais atributos são necessários para identificar Leslie de forma exclusiva? Provavelmente alguns dos seguintes: first name, last name, e-mail, ssn, company id, position(s).

Açao

Qualquer ação realizada pelos sujeitos. Podem ser as operações CRUD padrão ou algo mais complexo. Nossas ações são open/viewe create. Os atributos para essas ações podem ser diferentes com base na estrutura de aplicativos da web que você está usando. Falaremos mais sobre isso quando chegarmos ao recurso.

Recurso

Bastante auto-explicativo. Nossos recursos são os price manager page, travel pricese the newly created price. Poderia haver mais, se você realmente quiser. Você pode ocultar ações que os usuários não podem executar. Por exemplo. o create price buttonpode ser um recurso que pode ser mostrado / oculto com base no fato de o usuário ter permissões para criar preços. Como a única maneira de um usuário ver uma lista de preços pode ser através desta página, provavelmente seria uma boa ideia impor a autorização nesse nível, em vez de descer mais a pilha.

O acesso aos recursos é o mais complicado de implementar, especialmente os que vêm de um banco de dados. A opção mais refinada é a segurança no nível da linha. Alguns bancos de dados têm um certo grau de suporte. Alguns implementadores XACML chegaram ao ponto de criar um superconjunto SQL. Isso realmente depende das suas necessidades de autorização, mas a única coisa que você não quer fazer é extrair tudo de uma tabela e depois decidir o que mostrar. Você pode agrupar recursos por conjuntos de permissões, abstraí-los por trás de uma API e impor autorização nos terminais da API.

Meio Ambiente

Não posso defini-lo corretamente (XACML também não tem uma definição adequada), mas digamos que é a "bolha" na qual tudo isso acontece. Isto inclui: web application, web server, operating system, browser, office. Você poderia extrair atributos como: ip address, time of day, user locale, user agent, operating system version. Você pode usá-los para bloquear o acesso do usuário a ambientes não suportados pelo seu aplicativo (por exemplo, navegadores antigos, sistemas operacionais antigos, computadores fora da rede, acesso fora do horário comercial).

Pedido de autorização

Depois de reunir todos os atributos necessários, agrupamos-os em uma solicitação de autorização e a encaminhamos para uma entidade que pode tomar decisões de autorização com base nos valores desses atributos. Na linguagem XACML, o local em que você coleta esses atributos e aplica as decisões tomadas em seguida é chamado de ponto de aplicação de política (PEP) e o ponto de tomada de decisões é chamado de ponto de decisão de política (PDP). Os locais dos quais os valores dos atributos são obtidos são chamados PIP ( Policy Information Point s). PEPs, PDPs e PIPs podem fazer parte da sua aplicação, pois podem ser sistemas externos. Você pode encontrar um diagrama de como eles se comunicam no padrão XACML.

Processo de decisão

O processo de tomada de decisão é baseado em regras . As regras podem ser agrupadas em políticas que podem ser agrupadas em conjuntos de políticas . Cada um deles tem um alvo . O destino é usado para decidir se alguma das regras se aplica à solicitação de autorização. Pense nisso como um filtro. O destino contém condições criadas usando nomes e valores de atributos. Por exemplo, as regras para o seu aplicativo podem ser agrupadas em algo como:

Aplicativo da Web (conjunto de políticas)
| - target: application-name == "Aplicativo da Web"
`- Versão 1.0 (conjunto de políticas)
    | - target: application-version == "1.0"
    `- Ver gerente de preços (política)
        | - target: nome da página da web == "gerente de preços" && nome da ação == "visualizar"
        `- Leslie pode ver o gerente de preços (regra)
            | - target: subject-name == "Leslie"
            `- permissão: permitir

O PDP corresponderá a tudo no conjunto acima com os valores de atributo na solicitação de autorização. O que acontece se não houver regras correspondentes, depende da implementação do seu PDP. Uma vez que o PDP tomou uma decisão ( allow, denyou not-applicable) que envia de volta para o PEP, que age sobre ela por conceder ou negar o acesso ao recurso. Juntamente com a resposta, o PDP pode enviar uma lista obligationse advicesque o PEP deve ou deve cumprir no processo de execução. Dependendo de como as regras são armazenadas (arquivos de texto ou banco de dados), um administrador pode usar um editor de texto padrão ou um aplicativo de edição personalizado para alterá-las conforme desejar. A revogação do acesso de Leslie ao gerente de preços é retomada simplesmente mudando a permissão de allowparadeny, concedido o PEP faz o seu trabalho.

Execução

Isso depende muito da sua pilha de tecnologia. Algumas estruturas da Web têm pontos de imposição naturais (por exemplo, o ASP.NET MVC possui filtros de atributo). Suas camadas de negócios podem precisar definir esses pontos de aplicação. Achei mais fácil aplicar a aplicação nos pontos de extremidade de serviço (pense em microsserviços) ou no nível da interface do usuário.

Outros benefícios

Um bom efeito colateral da implementação disso é que você acaba com uma trilha de auditoria bastante rica que pode ser usada para outros fins.