2.8.1 Introdução
O processo de restringir o acesso de um grupo de utilizadores / utilizador a um recurso protegido é denominado controlo de acesso. Depois de autenticado, o utilizador poderá ser submetido a um processo de controlo de acesso, para
determinar se é permitido o acesso a determinado recurso protegido ou sistema, com efeito, o fato de um utilizador estar autenticado não signi ca que pode aceder a um recurso protegido, pois poderá ter de passar por um controlo de acesso (autorização). O processo de autenticação costuma decorrer antes do processo de autorização. Os termos autenticação e autorização são muitas vezes confundidos. Enquanto a autenticação é o processo de validar a identidade de um utilizador, a autorização é o processo de validar se um determinado utilizador pode ter acesso a um recurso protegido.
Também o registo de dados de eventos em cheiro (logs) é um processo relevante numa aplicação, pois permite que o estado original de uma aplicação seja restabelecido ou se perceba um comportamento passado da aplicação, ainda mais, permite processos de auditoria ou diagnóstico a problemas funcionais ou de acessos indevidos a uma aplicação.
2.8.2 Controlo de acesso
Em sistemas informáticos normalmente as políticas de controlo de acesso enquadram-se nas seguintes categorias(Stallings and Brown, 2014, p. 116-133):
Controlo de acesso discricionário (DAC240): neste modelo de controlo de acesso
o proprietário de um objeto estabelece quem pode ter acesso e privilégios. Várias propriedades são importantes neste modelo: propriedade e data do objeto, privilégios e permissões.
Controlo de acesso mandatório (MAC241): neste modelo o sistema é que
aplica as políticas de acesso, respeitando as con gurações de privilégios (determinados pelo administrador de sistema) e os rótulos de informação (consoante classi cação efetuada pelo gestor de informação).
Controlo de acesso baseado em roles (RBAC242): controlo de acesso baseado em
240Discretionary Access Control. 241Mandatory Access Control. 242Role-Based Access Control.
roles, a política de acesso é determinada pelo sistema e não pelo proprietário do objeto. Este modelo é não discricionário e é de nido por três regras: atribuição de roles, autorização de roles e transação de roles.
Controlo de acesso baseado em atributos (ABAC243): controlo de acesso não
baseado nos direitos de acesso de um utilizador, mas sim nos atributos do utilizador. O motor que determina o acesso a um objeto tem de analisar os atributos necessários para permitir o acesso.
Em suma, autorização é o processo de permitir / rejeitar o acesso de um individuo / dispositivo a objetos de um sistema baseado em determinados critérios como a sua identidade (i.e., per l / grupo a que pertence), localização, tempo (i.e., hora do dia, dia da semana, etc.), tipo de transação.
Figura 2.17 Relação entre o controlo de acesso e as outras funções de segurança(Stallings and Brown,2014, p. 115)
Na prática, determinado número de componentes podem cooperar e partilhar funções no controlo de acesso (vid. gura 2.17). Os sistemas operativos possuem
componentes de controlo de acesso simples ou complexos. Determinadas aplicações (e.g., sistemas de gestão de base de dados, rewall, etc.) também possuem funções de controlo de acesso. As frameworks de desenvolvimento revistas também podem ter implementado o controlo de acesso, como se pode ver na gura seguinte:
Framework Controlo de acesso
Django REST Framework Sim
Flask-RESTful Sim
Laravel Sim
Zend Framework Sim (ACL)
CakePHP Sim (ACL)
Restlet Sim
Spark Não
Sinatra Sim (Rack middleware)
Express Não
Restify Não
SailsJS Sim
LoopBack Sim (ACL)
Gugamarket Não
Spring boot Sim (Spring security)
Grails Sim (Spring security, Apache Shiro)
Phoenix Não
Tabela 2.10 Controlo de acesso em frameworks de desenvolvimento (REST)
2.8.3 Auditoria
A função de auditoria monitoriza e mantém registos de ocorrências de controlo de acesso aos recursos do sistema. O registo de eventos (logs) durante o controlo de acesso é o processo que permite associar um sujeito (indivíduo / dispositivo) com a execução de determinadas operações. Auditoria assume enorme relevância para detetar violações de segurança, recrear incidentes de segurança ou analisar comportamentos de uma aplicação. Frequentemente sistemas informáticos possuem métodos automáticos de auditoria que despoletam o registo de eventos (logs) sob determinados critérios ou ativação de triggers244 especí cos, além disso, podem
determinar algum tipo de resposta automática (e.g., restrição de operações, envio de aviso ao administrador do sistema, etc.).
Existem determinados requerimentos para efetuar uma auditoria de 244Recurso de programação executado sempre que ocorre o evento associado.
segurança(Stallings and Brown, 2014, p. 581): de nição de eventos, deteção de eventos, registo de eventos, ferramentas / interfaces de análise de registo de eventos, garantia de não comprometimento das ferramentas de análise e menor efeito possível das ferramentas de análise (não alteração de dados).
Também deve existir uma efetiva proteção / armazenamento dos dados de registos para auditoria(Stallings and Brown,2014, p. 588):
Leitura / escrita de cheiro num servidor.
Gravação em meios não regraváveis (e.g., cd-rom, dvd-rom). Registo em dispositivos de escrita única (e.g., impressora).
Assim, segundo Brown e Stallings(Stallings and Brown,2014, p. 595), fazer auditoria a nível de sistema pode não ser su ciente para detetar problemas de funcionamento e problemas de lógica aplicacional. Pode ser necessário detetar em pormenor o comportamento da aplicação, para além da sua interação com o sistema operativo. A informação necessária para detetar ataques a nível de aplicação pode não existir ou ser difícil de extrair dos registos do sistema operativo.
2.8.4 Conclusão
O processo de controlo de acesso a sistemas informáticos é baseado na de nição de políticas de acesso aos recursos protegidos. Frequentemente é necessário alterar ou remover a autorização de um utilizador a um determinado recurso (i.e., alteração ou remoção da regra de acesso do sistema informático), o que deverá ser simpli cado e célere se existirem interfaces próprias para o efeito. Por conseguinte, a segurança de uma aplicação é reforçada se forem tomadas medidas que permitam a devida implementação do processo de autenticação, autorização e auditoria.