Modelos de Segurança para Controles de Acesso

Quando se fala de segurança da informação sempre se vem a mente a necessidade de controles. Controles das mais variadas formas, desde portas com fechaduras eletrônicas até atributos de arquivos digitais. De forma a orientar em como implementar os controles lógicos, existem modelos de segurança para controle de acesso. Esses modelos, baseados em concepção de softwares já consolidados em mercado, apoiam arquitetos de softwares no desenvolvimento da melhor proposta de segurança dos softwares.

Modelos de Controle de Acesso

Quando se fala em controle de acesso é proposto com que existam mecanismos que permitam a diferenciação dos acessos, sejam acessos de determinados usuários ou grupos até a diferenciação em como os controles são impostos no sistema.

Para a compreensão dos modelos que serão apresentados é importante com que alguns papéis sejam claros:

  • Data Owner: ou apenas “dono do dado” é a pessoa, grupo ou departamento de uma empresa que possui propriedade institucional sobre os dados. O dono do dado que sabe o propósito do dado para a instituição e como pode ser utilizado, seja de forma regimental e/ou legal. Exemplo: o departamento de RH de uma organização que sabe como os dados cadastrais dos funcionários devem ser manipulados.
  • Data Processor: ou “processador dos dados” é a pessoa, grupo ou departamento de uma empresa que possui privilégios para manipular os dados, porém de acordo com a orientação do Data Owner. Geralmente é a TI da organização, já que essa processa o dado porém não detém propriedade institucional sobre o dado e deve obedecer as diretrizes definidas pelo Data Owner.
  • Data subject: é a quem se trata a informação ou dado. Em um cadastro de funcionários, o data subject seria o próprio funcionário. Ou seja, é o possuir das informações de identificação pessoal (Personally Identifiable Information ou PII).

Existem outros papéis mas que para o propósito do tema do artigo esses serão os mais relevantes.

A seguir descreve os 5 modelos de controles de acesso reconhecidos na literatura:

DAC (Discretionary Access Control)

Os Data Owners decidem quem tem o acesso aos dados. Nesse modelo a concessão do acesso e controle fica com o dono do dado. E para impor esse modelo são utilizadas ACL (Access Control Lists) para definir os privilégios dos demais grupos.

Nesse modelo, que é largamente utilizado em sistemas de arquivos, o dono do dado geralmente é o usuário que criou o arquivo. Ele detém controle sobre a ACL do arquivo. Eventualmente alguns controles não-discricionários (non-discretionary) poderão ser utilizados para garantir maior segurança do ambiente, como regras baseadas em horários de uso do arquivo ou recurso. 

MAC (Mandatory Access Control)

Sistemas operacionais garantem a política com o uso de rótulos de segurança (security labels). Tudo no ambiente deverá possuir sua classificação de acordo com os rótulos. Os rótulos devem ser definidos para usuários e/ou programas para que possuam apenas acesso ao que deve ser necessário. Nesse modelo, os arquivos e programas que possuam determinado rótulo de segurança apenas apenas poderão se comunicar com outros de mesmo rótulo.

Porém eventualmente um arquivo ou programa precisa acessar ou ser lido por outro que possua diferente classificação. Para permitir isso são definidas interfaces claras e restritas.

No caso de uma implementação do modelo pelo sistema operacional, esse será responsável em garantir a integridade dos acessos por meio do método descrito. Não caberá aos usuários definir quem acessará o que.

Um sistema operacional ou ambiente que faça uso de MAC deverá ter sido projetado para tanto. O componente Security-Enhanced Linux – SELinux – é uma implementação prática desse modelo.

Quanto aos rótulos de segurança, esses não necessariamente serão hierárquicos. Determinados rótulos poderão possuir privilégios (clearances) para acessos específicos.

RBAC (Role-Based Access Control)

Os acessos são concedidos de acordo com o papel do usuário ou posição que esse exerça na organização. Semelhante ao modelo DAC, em que existe uma discrição, o que determina a possibilidade de acesso é sua função e um conjunto de regras. Ou seja, mais relevante do que as pessoas, são as funções que essas desempenhas e que a elas são definidas.

As permissões de acesso ocorrem de forma hierárquica, onde nívels superiores acumularão os acessos dos níveis inferiores. Essa estrutura hierárquica geralmente reflete a própria estrutura organizacional da empresa. A herança de privilégios poderá ser de forma limitada ou geral.

O modelo prevê que situações que existam possíveis conflitos de interesses tenham que ser individualmente modeladas através de separação de funções de forma estática. Por exemplo, o supervisor de um grupo de caixas não poderá acumular as funções de caixa e possuir os privilégios de supervisor. Ou o nível de privilégio dele deverá ser definido no momento de acesso ao sistema.

RB-RBAC (Rule-Based Access Control)

Semelhante ao RBAC mas com a imposição de regras que restrinjam o controle de acesso de acordo com complexos conjuntos de regras discricionárias e não-discricionárias.

É mais fácil sua compreensão através de um exemplo: se João, às 8 da manhã, e a partir de sua localização geográfica ou lógica acessar o recurso, ele terá privilégio de leitura. Se não, o acesso não será concedido. Ou seja, as regras vão muito além da estrutura hierárquica ou funcional do usuário.

Um exemplo prático de implementação desse tipo de controle são as regras que geralmente são implementadas em Web Gateways para acesso á Internet a partir de uma organização.

As regras são impostas de forma arbitrária pelos administradores do ambiente.

ABAC (Attribute-Based Access Control)

As decisões de acesso são baseadas em atributos do componente ou da ação a ser realizada. Os atributos podem ser entre os seguintes não limitados a esses: Subjects, Objects, Actions e Context.

É o modelo mais completo de todos, pois utilizando dos atributos citados é possível a definição de uma variedade enorme de combinações para o controle de acesso.

Por ser um modelo que permita a elaboração de regras muito complexas e granulares, sua manutenção pode ser difícil. Manter a política e os controles pode onerar tanto que o propósito ou necessidade do acesso pode findar antes de ser viável.

Por fim…

Naturalmente os modelos são diretrizes para desenvolvedores implementarem controles de acesso. Os modelos não são excludentes e pode ser possível a implementação de vários em um único ambiente. Importante notar que nem todos os modelos são privacy-aware e que outras medidas podem ser necessárias para atender a outros serviços de segurança.

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *