Durante meu trabalho como arquiteto em projetos de implementação do IdM, analisei dezenas de implementações de mecanismos de autorização, tanto em soluções internas de empresas quanto em produtos comerciais, e posso dizer que em quase todos os lugares com requisitos relativamente complexos eles não são feitos corretamente ou, pelo menos, não de maneira ideal. O motivo, na minha opinião, é a pouca atenção do cliente e dos desenvolvedores a esse aspecto nos estágios iniciais e a avaliação insuficiente do impacto dos requisitos. Isso confirma indiretamente o amplo uso indevido do termo: quando vejo a frase "autorização de dois fatores", começo a sentir dores logo abaixo das costas. Por uma questão de interesse, analisamos os 100 primeiros artigos sobre Habré nos resultados da pesquisa por "autorização", o resultado foi decepcionante, houve muita dor:
Em mais de 80% dos casos, o termo é usado incorretamente, a palavra "autenticação" deve ser usada. A seguir, tentarei explicar o que é e por que é extremamente importante prestar atenção especial a esse tópico.
O que é isso?
Para citar a Wikipedia:
Do ponto de vista de qualquer sistema de informação, esse é o processo de tomada de decisão sobre como fornecer acesso ao sujeito para executar a operação com base em qualquer conhecimento sobre o assunto. Nesse ponto, o sujeito, por regra, já deve estar
identificado (precisamos saber quem ele é) e
autenticado (sua identidade é confirmada).
A implementação da autorização no desenvolvimento de um sistema ou produto de informações corporativas focado no setor corporativo é uma tarefa muito difícil e responsável, que muitas vezes recebe atenção insuficiente no estágio de design e no estágio inicial de desenvolvimento, o que no futuro leva a uma implementação "muleta".
Edição
Vamos ver quais requisitos de autorização são atendidos e por que é extremamente importante considerá-los inicialmente ao projetar um sistema e não adiá-lo para o futuro. Geralmente, existem duas fontes de requisitos de autorização em um sistema de informações corporativas - são negócios e segurança da informação. Em geral, uma empresa deseja manter segredos em sigilo e fornecer autoridade aos usuários de acordo com sua função no processo de negócios, e a segurança deseja garantir a suficiência mínima de autoridade para cada usuário e acesso à auditoria.
Tomemos, por exemplo, um sistema hipotético para negociar contratos de grandes empresas, uma empresa típica e sangrenta. Os seguintes
requisitos de autorização comercial provavelmente surgirão:
- Um usuário que não está relacionado a um contrato específico não deve vê-lo no sistema
- O autor do contrato deve vê-lo em todas as etapas.
- Um usuário com uma classificação de pelo menos 10 tem o direito de criar um contrato.
- O visitante deve ver o contrato, começando com o recebimento no estágio e posteriormente.
- Os chefes de departamento devem ver os contratos de suas unidades na hierarquia.
- O autor do contrato e o chefe da unidade têm o direito de rescindir o contrato em qualquer estágio da aprovação.
- A gerência e o secretariado da sede devem ver os documentos de todas as filiais.
- O usuário que criou o contrato não deve ter o direito de endossá-lo.
Da segurança, podemos obter os seguintes requisitos :
- Saiba quem tem acesso a um contrato específico.
- Saiba quem teve acesso a um contrato específico em um determinado momento.
- Privar o usuário do acesso a documentos anteriormente disponíveis ao alterar suas funções.
Eu acho que os desenvolvedores já estavam assustados :). Uma dor adicional é a alta variabilidade desses requisitos. A propósito, de acordo com as estatísticas de uma grande franquia 1C, os requisitos adicionais de autorização são uma das tarefas mais comuns para personalizar configurações típicas.
Portanto, indicamos por que esses requisitos são problemáticos:
- Eles não são estáveis. A probabilidade de sua mudança, mesmo no curto prazo, tende a 1.
- Eles são transversais. Sua implementação afeta todas as camadas, do design do banco de dados à interface do usuário.
- Eles estão no plano da área de assunto. Isso leva a uma forte conectividade do mecanismo de autorização com uma camada de lógica de negócios.
- Eles afetam o desempenho.
Soluções
Os modelos de controle de acesso desenvolvidos nos ajudam a resolver esse problema:
MAC é um modelo de controle de acesso credencial. O acesso do sujeito ao objeto é determinado pelo seu nível de acesso: o nível de acesso do sujeito não deve ser inferior ao nível de sigilo do objeto.
DAC - controle de acesso direto. O acesso do sujeito ao objeto é determinado pela presença do sujeito na lista de acesso
(ACL) do objeto.
O RBAC é um modelo de controle de acesso. O acesso do sujeito ao objeto é determinado pela presença do papel do sujeito que contém os poderes correspondentes ao acesso solicitado.
ABAC é um modelo de atributo de controle de acesso. O acesso do sujeito ao objeto é determinado dinamicamente com base em uma análise de políticas que levam em consideração os valores dos atributos do sujeito, objeto e ambiente. Isso também inclui
PBAC, RAdAC, CBAC , com algumas nuances (
revisão chique da CUSTIS ).
Eles são altamente recomendados para serem usados em sua forma original sem reinventar a roda. Muitas vezes, em sistemas de informação complexos, é usada uma combinação de modelos. Por exemplo, a combinação ACL + RBAC é popular quando uma função é incluída em uma lista de acesso. No entanto, o uso correto de modelos prontos também não é uma tarefa fácil. Nem todos podem escolher o modelo certo, separá-lo da lógica de negócios e alcançar um desempenho aceitável do mecanismo de autorização.
Para implementar os requisitos mencionados acima na seção "Problemas", à primeira vista, eu escolheria a combinação PBAC + ACL. Os requisitos podem ser implementados da seguinte maneira:
Os requisitos de IS listados são implementados sem problemas usando ACLs, mas implementamos os requisitos de negócios 5 e 7 usando PBAC. Portanto, para implementar os requisitos do IS 1 e 2, você precisará adicionar um diário ou um mecanismo semelhante a eles, porque, por toda a sua beleza, as regras dinâmicas são mal auditadas:
Total
Autorização é um tópico imerecidamente negligenciado, tanto em publicações quanto diretamente no processo de desenvolvimento. A autenticação de dois fatores via SMS será parafusada no site pela criança. A implementação correta da autorização no sistema corporativo sem fazer muletas é uma tarefa difícil da qual senhores e arquitetos quebram lanças, e muitos produtos comerciais populares (por exemplo, Atlassian Jira) ficam de muletas devido à complexidade dos requisitos.
Estamos planejando uma série de artigos sobre modelos de autorização e o assunto como um todo. Congratulamo-nos com perguntas e sugestões sobre tópicos a serem considerados.