A autenticação e a autorização estão entre as principais prioridades para os desenvolvedores de aplicativos atualmente. Embora sejam frequentemente usados de forma intercambiável, na verdade representam duas coisas muito diferentes. No entanto, para garantir uma experiência segura e contínua aos utilizadores, ambos devem trabalhar em conjunto.
Para ilustrar a distinção entre autenticação e autorização, costumo usar o exemplo de levar sua família à Disneylândia. A autenticação é como o portão de entrada onde, na chegada, você mostra seu ingresso e identidade ao porteiro, que verifica se você é quem diz ser – da mesma forma que quando você faz login em um aplicativo no qual o sistema de autenticação verifica seu nome de usuário e senha para valide sua identidade.
Autorização é o que acontece quando você passa pelo portão da frente. Seu ingresso pode ter um “Fast Pass” que permite evitar filas de espera, ou seus filhos podem ter ingressos diferentes destinados apenas a determinadas atrações. Essas medidas de autorização (ou controle de acesso) regem “o que você pode fazer” depois de ser autenticado. Num contexto organizacional, isto é semelhante a ter as permissões corretas para acessar determinados arquivos ou programas.
É claro que o gerenciamento de autorização para um aplicativo corporativo é muito mais complexo e cheio de nuances do que o exemplo compartilhado acima. Talvez você precise conceder acesso a um recurso temporariamente e apenas a um subgrupo selecionado de usuários. Ou talvez existam certos recursos que só deveriam estar disponíveis para indivíduos em condições específicas, como fazer parte de uma equipe de projeto ou trabalhar em um departamento específico.
RBAC e ABAC
É por isso que nas últimas duas décadas assistimos à introdução e adoção de vários modelos diferentes de controlo de acesso. Os modelos de autorização de primeira geração, como os controles de acesso obrigatórios, priorizaram uma abordagem única para todos os controles de acesso refinados. No entanto, nas empresas modernas, onde os direitos de acesso a determinadas aplicações, sistemas ou recursos podem ter de ser concedidos ou revogados diariamente, tornou-se evidente que eram necessárias soluções mais dinâmicas. Isto levou ao desenvolvimento de modelos de autorização mais modernos, como o controle de acesso baseado em funções (RBAC) e, posteriormente, o controle de acesso baseado em atributos (ABAC).
O RBAC simplificou o gerenciamento de acesso atribuindo permissões a funções em vez de usuários individuais. Num ambiente corporativo, funções como “gestor”, “contador” ou “técnico de TI” vêm com direitos de acesso predefinidos, simplificando o processo de concessão ou revogação de acesso à medida que os funcionários assumem diferentes funções ou responsabilidades. A ABAC deu um passo adiante ao incorporar uma gama mais ampla de atributos (como localização do usuário, horário de acesso e tipo de dispositivo usado) na administração de decisões de acesso.
No entanto, embora o ABAC ofereça um elevado grau de granularidade e flexibilidade, também é difícil de gerir, uma vez que requer a definição e a manutenção contínua de numerosos atributos e políticas em constante mudança. Esta complexidade, por sua vez, levou a uma série de desafios administrativos, especialmente em ambientes de grande escala, onde o grande número de atributos e regras, e as relações entre eles, podem rapidamente tornar-se um fardo esmagador.
ReBAC entra no chat
O controle de acesso baseado em relacionamento, ou ReBAC, oferece uma opção mais flexível para desenvolvedores de software adicionarem autorização refinada a aplicativos e recursos. Com base na estrutura Zanzibar do Google, o ReBAC considera as relações entre entidades (como usuários, recursos e grupos) para governar o acesso. Ele fornece uma abordagem mais contextual para controle de acesso em comparação com RBAC ou ABAC, tornando-o particularmente adequado para ambientes complexos onde relacionamentos e interações são priorizados na determinação de quem deve ou não ter acesso.
Por exemplo, considere um hospital típico que conta com uma ampla variedade de indivíduos e funções – desde administradores hospitalares, médicos e enfermeiros até técnicos de laboratório, seguranças e zeladores. Embora todos esses indivíduos possam ter acesso à porta da frente, isso não significa que todos possuam os mesmos direitos de autorização. Além disso, só porque um médico pode ter autoridade para rever registos detalhados de pacientes, isso não significa necessariamente que deva ter acesso à informação privilegiada de cada paciente – apenas daqueles que estão sob os seus cuidados enquanto recebem cuidados da instituição.
No modelo ReBAC, quando um médico é designado para um paciente, ele tem acesso aos registros médicos desse paciente. Esse acesso pode ser revogado dinamicamente quando o paciente não estiver mais sob os cuidados do médico. Da mesma forma, um enfermeiro no mesmo sistema pode ter direitos de acesso diferentes, limitados aos pacientes com os quais está diretamente envolvido. Esta agilidade garante que os profissionais de saúde tenham as informações necessárias para prestar cuidados, mantendo ao mesmo tempo a privacidade rigorosa do paciente, em conformidade com os requisitos regulamentares.
O ReBAC também permite um gerenciamento mais detalhado e preciso das permissões dos usuários em comparação aos modelos tradicionais de controle de acesso, o que é conseguido concentrando-se na natureza, no contexto e nos atributos dos relacionamentos entre várias entidades (como usuários, recursos e dados). No entanto, embora o ReBAC ofereça um caminho promissor, não deixa de ter os seus próprios desafios.
Diretrizes de implementação para ReBAC
Implementar e gerenciar um sistema ReBAC pode ser uma tarefa complexa, especialmente em grandes organizações onde os relacionamentos e interdependências são numerosos e estão em constante evolução. Se você está planejando implementar o ReBAC, considere estas três diretrizes.
Concentre-se na definição inicial
Antes de mergulhar no pool do ReBAC, é essencial investir tempo antecipadamente para obter uma compreensão completa dos vários relacionamentos que existem dentro de sua organização. Isso inclui mapear detalhadamente como os usuários se relacionam entre si, com os recursos e com a organização como um todo. Compreender e comunicar estas dinâmicas é crucial para definir políticas eficazes de controlo de acesso. O estabelecimento destas definições iniciais desempenhará um papel crítico na determinação não apenas de como o ReBAC é inicialmente implementado, mas também de como poderá evoluir ao longo do tempo.
Comece pequeno para garantir ganhos rápidos
Antes de implementar o ReBAC em toda a organização, é melhor começar com uma pequena implementação ou programa piloto que permitirá o teste do sistema em um ambiente controlado. Por exemplo, considere testar o ReBAC inicialmente no departamento de recursos humanos (RH), que normalmente tem relacionamentos bem definidos e estáveis, como aqueles entre gerentes de RH, funcionários e dados confidenciais. Neste contexto, o ReBAC pode gerenciar o acesso a informações confidenciais dos funcionários, como dados pessoais, avaliações de desempenho e dados de folha de pagamento. Esta abordagem ajuda a identificar potenciais problemas, a aperfeiçoar as políticas e a compreender as implicações práticas do sistema, sem sobrecarregar o pessoal ou perturbar os principais processos organizacionais.
Desenvolva, teste e refine políticas
Como parte de uma implementação em pequena escala, é essencial garantir que as políticas que estão a ser implementadas sejam regularmente testadas e refinadas com base no feedback das partes interessadas e que reflitam com precisão os controlos de acesso desejados com base nas relações. As políticas também devem ser testadas utilizando vários cenários hipotéticos para avaliar a sua eficácia e viabilidade. Isto pode incluir cenários como mudanças de funções, transferências de departamentos ou mudanças nas equipas de projeto, garantindo que tais políticas concedam acesso apropriado em cada cenário e que quaisquer alterações nas relações resultarão numa atualização imediata nos direitos de acesso. Também é importante reconhecer que o desenvolvimento e o teste de políticas são um processo iterativo e que, à medida que a organização evolui e surgem novos tipos de relações, as políticas terão de ser revistas e atualizadas para permanecerem eficazes e relevantes.
Não importa onde você esteja em sua jornada de autenticação e autorização, é essencial manter-se informado sobre os modelos de segurança em evolução, como o ReBAC, pois eles oferecem abordagens mais diferenciadas e adaptáveis para proteger seus recursos e dados no cenário digital atual.
Rishi Bhargava é cofundador da Descope, uma plataforma de arrastar e soltar para autenticação de clientes e gerenciamento de identidade.
–
O New Tech Forum oferece um local para líderes de tecnologia – incluindo fornecedores e outros colaboradores externos – explorarem e discutirem tecnologias empresariais emergentes com profundidade e amplitude sem precedentes. A seleção é subjetiva, baseada na escolha das tecnologias que acreditamos serem importantes e de maior interesse para os leitores do InfoWorld. A InfoWorld não aceita material de marketing para publicação e reserva-se o direito de editar todo o conteúdo contribuído. Envie todos consultas para [email protected].
