LUCAS LARROYD SOUZA
UMA VISÃO DE GESTÃO DE ACESSO E IDENTIDADE BASEADA NO MODELO DE RBAC EM UM AMBIENTE CORPORATIVO
Florianópolis 2014
UMA VISÃO DE GESTÃO DE ACESSO E IDENTIDADE BASEADA NO MODELO DE RBAC EM UM AMBIENTE CORPORATIVO
Trabalho de Conclusão de Curso apresentado ao Curso de Graduação em Sistemas de Informação da Universidade do Sul de Santa Catarina, como requisito parcial à obtenção do título de Bacharel em Sistemas da Informação.
Orientador: Prof. Luiz Otavio Botelho Lento, Me.
Florianópolis 2014
UMA VISÃO DE GESTÃO DE ACESSO E IDENTIDADE BASEADA NO MODELO DE RBAC EM UM AMBIENTE CORPORATIVO
Este Trabalho de Conclusão de Curso foi julgado adequado à obtenção do título de Bacharel em Sistemas de Informação e aprovado em sua forma final pelo Curso de Graduação em Sistemas da Informação da Universidade do Sul de Santa Catarina.
Florianópolis, 12 de novembro de 2014.
______________________________________________________ Prof. Luiz Otavio Botelho Lento, Me.
Universidade do Sul de Santa Catarina
______________________________________________________ Prof. Nome do Professor, abreviatura da titulação.
Universidade do Sul de Santa Catarina
______________________________________________________ Prof. Nome do Professor, abreviatura da titulação.
Dedico este projeto ao meu pai Dário Luiz Simon Souza, a minha mãe Denise Regina Larroyd Souza e a minha irmã Anelise Larroyd Souza, por serem aqueles que, tanto no passado, presente e futuro, são meus pilares na vida.
Agradeço a todas as pessoas que diretamente, e indiretamente, proporcionaram chegar até esta fase do curso de Sistemas de Informação e no desenvolvimento do projeto de conclusão de curso.
O presente documento trata como assunto principal a gestão de identidade e acesso, as ferramentas e recursos necessários para a sua idealização, assim como na realização desta gestão a partir da atribuição de um papel no sistema, a partir do conceito de Role Basic Access Control (RBAC), tendo este como meio para interação entre o usuário e os sistemas a serem acessados. O projeto foi embasado nos dados coletados em um ambiente corporativo para a visão do funcionamento da gerência, a partir da realização do esquema de funcionamento, sendo possível verificar as ações realizadas na verificação, validação, atribuição e negação dos acessos realizados. A estruturação proposta terá como finalidade a proteção idealizada para os sistemas e aplicações dos seus acessos, baseados em um ambiente na nuvem, visando a ampla disponibilidade das informações tendo um acesso seguro.
Palavras-chave: Gestão de acesso e identidade. Controle de acesso baseado em papel. Computação na nuvem.
This paper addresses the main issue identity and access control, among the necessary tools and resources to its idealization as well as in the realization of this management from assigning a role in the system , from the concept of Role Basic Access Control ( RBAC ) , having this as a means of interaction between the user and the systems to be accessed . The project have based on data collected in a corporate environment for viewing the operation management from the conduct of the operation scheme, to be possible to check the actions taken in verification, validation, granting and denial of access performed. The proposed structure will aim idealized protection for systems and applications access, based on a cloud environment, targeting the wide availability of this information with secure access.
LISTA DE ILUSTRAÇÕES
Figura 1 – Termos utilizados associados a criptografia ... 21
Figura 2– Modelo visual de definição de Computação em Nuvem... 28
Figura 3– Relação entre os modelos RBAC96 ... 33
Figura 4 – Hierarquia entre os papéis de um projeto ... 36
Figura 5 – Modelo conceitual RBAC3 ... 37
Figura 6 – Etapas metodológicas TCC ... 43
Figura 7 – Esquema de acesso ao ambiente na nuvem ... 46
Figura 8 – Negociação de acesso entre usuário e o ambiente na nuvem ... 46
Figura 9 – Detalhamento da negociação entre usuário e o ambiente na nuvem... 47
Figura 10 – Mapeamento da primeira parte de acesso ao ambiente na nuvem ... 49
Figura 11 – Mapeamento da segunda parte de acesso ao ambiente na nuvem ... 51
Figura 12 – Elaboração estrutural empresa DMS ... 56
Figura 13 – Funções e setores na empresa DMS ... 56
Figura 14 – Tela de retorno de erro para usuário não encontrado ... 58
Figura 15 – Tela de retorno de erro para senha incorreta ... 58
Figura 16 – Tela de retorno de erro para senha incorreta ... 59
Figura 17 – Tela de retorno de erro chave de acesso fora da validade ... 60
Figura 18 – Tela de retorno de erro chave de acesso inválido ... 60
SUMÁRIO 1 INTRODUÇÃO ...13 1.1 PROBLEMÁTICA ...14 1.2 OBJETIVOS ...14 1.2.1 Objetivo geral ...14 1.2.2 Objetivos específicos ...15 1.3 JUSTIFICATIVA ...15 1.4 ESTRUTURA DA MONOGRAFIA ...16 2 REVISÃO DA LITERATURA ...18 2.1 SEGURANÇA DA INFORMAÇÃO ...18
2.1.1 Princípios da segurança da informação...19
2.1.2 Criptografia ...20
2.1.2.1 Tipos de Criptografia ...21
2.1.2.1.1 Simétrica ou algoritmo da chave secreta ...21
2.1.2.1.1.1 Data Encryption Standard (DES) ...22
2.1.2.1.1.2 AES ...22
2.1.2.1.2 Assimétrica ou algoritmo da chave pública ...22
2.1.2.1.2.1 Algoritmo RSA ...23
2.1.2.1.3 Função HASH ...23
2.1.2.1.4 Certificado digital e certificado de autoridade ...23
2.1.2.1.5 Gerador de número randômicos ...24
2.1.2.2 Criptografia e computação na nuvem ...24
2.1.3 VPN ...24
2.1.3.1 Tunelamento...25
2.1.3.1.1 Protocolos de tunelamento ...25
2.2 CLOUD COMPUTING ...26
2.2.1 Características do Cloud Computing e modelos de implantação ...28
2.2.2 Cloud Computing como serviço ...29
2.2.2.1 Software as a Service (SaaS) ...29
2.2.2.2 Platform as a Service (PaaS) ...30
2.2.2.3 Infrastructure as a Service (IaaS) ...30
2.3 GERENCIA DE IDENTIDADE E ACESSO ...30
2.3.1.2.1 RBAC0 ...33 2.3.1.2.1.1 Papel ...33 2.3.1.2.1.2 Permissão ...34 2.3.1.2.1.3 Objeto...34 2.3.1.2.1.4 Usuário ...34 2.3.1.2.1.5 Interações ...34 2.3.1.2.1.6 Sessão...35 2.3.1.2.2 RBAC1 ...35 2.3.1.2.3 RBAC2 ...36 2.3.1.2.4 RBAC3 ...37 2.3.1.3 Administrative RBAC97 ...38
2.3.1.3.1 Administração de Permissões e Papéis ...38
2.3.1.3.2 Modelo ARBAC97 ...39 2.3.1.3.3 URA97 ...39 2.3.1.3.4 PRA97 ...39 2.3.1.3.5 RRA97 ...40 2.4 CONSIDERAÇÕES FINAIS ...40 3 MÉTODO ...41
3.1 CARACTERIZAÇÃO DO TIPO DE PESQUISA ...41
3.2 ETAPAS METODOLÓGICAS ...42
3.3 DELIMITAÇÕES ...44
4 ESQUEMATIZAÇÃO DO ACESSO AO AMBIENTE NA NUVEM ...45
4.1 ESQUEMATIZAÇÃO DA GERÊNCIA ...45
4.2 ACESSO AO AMBIENTE NA NUVEM ...46
4.2.1 Solicitação da chave de acesso (token) ...47
4.2.2 Solicitação do acesso ao sistema ...50
4.2.3 Considerações finais da solicitação de acesso ...52
4.3 COMPARAÇÃO ENTRE MODELO PROPOSTO E MODELOS BASEADOS ...52
4.4 CONSIDERAÇÕES FINAIS ...53
5 ESTUDO DE CASO ...54
5.1 COLETA DOS DADOS ...54
5.1.1 Empresa embasada ...54
5.1.2 Organograma ...55
5.2 REALIZAÇÃO DOS ACESSOS ...56
5.2.1 Solicitação de chave de acesso (token) ...57
5.2.2 Solicitação de acesso ao sistema ...59
5.3 CONSIDERAÇÕES DO MODELO ...61
5.4 CONSIDERAÇÕES FINAIS ...62
6 CONCLUSÕES E TRABALHOS FUTUROS ...63
6.1 CONCLUSÕES ...63
6.2 TRABALHOS FUTUROS ...64
REFERÊNCIAS ...65
APÊNDICE A – CRONOGRAMA...69
1 INTRODUÇÃO
No atual século os valores internos nas empresas demonstram-se dependentes do uso da tecnologia, visto que desde a última época evidenciou a utilização da informação, pois é vital o usufruto desta, desde apenas o uso como auxílio no negócio até se tornar o maior valor interno, objetivando melhor produtividade, ganho de mercado, redução de custos, agilidade, competitividade e tomada de decisão (SÊMOLA, 2003, pg 1). A importância das informações ganha um espaço privilegiado nas empresas, através da segurança da informação, uma área do conhecimento dedicada à proteção de ativos da informação contra acessos não autorizados, alterações indevidas ou sua indisponibilidade (SÊMOLA, 2003, pg 43). Usuários mal intencionados, ou com propósitos opostos aos da empresa, buscam diariamente uma brecha na segurança para visualizar, editar e alterar os dados. Uma forma de proteção destes dados é a criptografia das informações, desde no seu armazenamento ao seu compartilhamento, protegendo e bloqueando a visualização e manuseio de terceiros.
As informações acompanham o avanço tecnológico, e as inovações, nos últimos anos, ocasionando a transição, do uso das informações, em computadores desktop, sem praticidade de locomoção e pouco ergonômicos, para aparelhos notebook, tablets e até smarthphones que chegam a realizar as atividades básicas com comodidade, flexibilidade e agilidade. Este avanço está ligado com a utilização de nuvem para armazenar e acessar dados e sistemas, permitindo espelhamento das informações em qualquer lugar nos mais variados dispositivos. Conforme descrito por Leandro (2012), a nuvem proporciona uma coleção de serviços, informações, aplicações e infraestrutura através de uma demanda de recursos, a partir de um modelo de consumo e alocação de recursos de processamento e armazenagem.
Uma decorrência desta transição e ampliação dos meios de acesso é o aumento nos riscos operacionais, pois ampliam-se os acessos indesejados. Logo, com o objetivo de garantir um ambiente seguro a estes dados por meio da nuvem, a implantação de uma gerência de acesso e identidade, ou IAM (Identity Access Management) é recomendada. É capaz de instaurar uma barreira que controla e gera as modificações, visualizações e criações das informações contidas nesses ambientes.
Dentre os diversos modelos de gerência capazes de controlar, monitorar e relatar as informações desejadas, ligadas as suas vantagens e desvantagens, encontra-se a de RBAC (Role Basic Access Control), provendo uma estrutura de controle através da criação de papéis,
onde usuários, ou grupo de usuários, são atribuídos a estes papéis, e a estes papéis são atribuídas certas permissões. (SANDHU, 1997)
1.1 PROBLEMÁTICA
As empresas dão grande importância às suas informações, por conter valores que impactam nos seus processos. Por isso a perda, indisponibilidade ou mau uso dessas informações e dados devem ser evitados. Considerando essa importância e com a necessidade de prover um ambiente disponível a nuvem, que contém estas informações, há de ser percebida como uma alternativa com um acesso seguro. O seu controle, baseado em regras pré-definidas e divididas por papéis que caracterizam as permissões dos funcionários na empresa, oferece uma vantagem e segurança das informações contidas. Desta forma chega-se a pergunta: É possível programar uma gerência de acesso e identidade capaz de, através de regras, possibilitar o ingresso dos usuários no ambiente na nuvem conforme as suas responsabilidades e permissões de forma simples, maleável e contínua?
1.2 OBJETIVOS
São apresentados, a seguir, os objetivos deste trabalho.
1.2.1 Objetivo geral
Formar e utilizar um modelo de gerência de acesso e identidade, a fim de controlar por meio de regras o acesso a edição, criação e remoção de informações do sistema computacional em uma empresa.
1.2.2 Objetivos específicos
Como objetivos específicos, são apresentados os seguintes:
efetuar pesquisa dos tipos de gerenciamento do acesso às informações e os modos de criptografia;
analisar o uso de modelos de controle de acesso IAM (Identity Access Management); analisar o uso do modelo de controle de acesso RBAC (Role Basic Access Control) na
gestão de identidades de acesso (IAM);
modelar e implementar as regras de acesso e permissões das informações em um ambiente corporativo;
documentar resultados finais da gestão de segurança obtidos.
1.3 JUSTIFICATIVA
A segurança das informações cresce em espaço e inovações, em decorrência do novo foco de importância de valores no âmbito comercial. Vê-se nos tempos atuais a busca por profissionais qualificados na área da segurança da informação para suprir e estabelecer políticas que, possibilitem e instaurem, uma barreira de defesa e proteção dos dados. Uma forma de exemplificar o peso das informações, neste novo foco de importância, é vendo-a como o sangue no corpo humano, neste foco a informação apresenta-se dispersa por todos os processos de negócio da empresa, sendo necessária para a execução das tarefas e funções de diferentes processos, estando disponível desde o seu centro, a base de dados, até nos pontos mais distantes da empresa, como portais e ambientes de pesquisa. (SÊMOLA, pg. 7, 2003). Em razão das informações possuírem uma característica de serem frágeis, a proteção e segurança em torno deste valor na empresa torna-se contínua. Com a globalização do acesso à internet, e com a facilidade de distribuição de informações por ela, os ataques a estes dados cresce e suas variações de ataques o acompanham. Empresas de segurança atualizam diariamente suas aplicações para prover, aos seus usuários, uma barreira protetora aos dados,
com o intuito de que vírus, hackers e outros tipos de intervenção oriundos da internet, não prejudiquem o usuário. Estas intervenções podem estar interligadas á interferências, sendo elas: físicas, como a má configuração ou falhas dos equipamentos; humanas, como o mau uso das informações ou a má intenção da utilização destas; ou tecnológicas, estando, por exemplo, o computador aberto a web mundial.
A gestão de identidade e acesso, ou IAM (Identity Access Management), possibilita gerenciar através da delegação de permissões o acesso às informações. Esta gerência é controlada por poucos usuários que criam e especificam os tipos de acessos e as permissões a eles atribuídas, limitando o acesso externo e não desejado aos dados armazenados. A gestão de acesso também é contínua, pois os dados a serem acessados e os usuários concebidos dos acessos não são permanentes. Dentro da gestão de acesso existem várias gerências que possibilitam o controle e gerenciamento. Uma das gerências que ganha seu espaço atualmente é o controle de acesso baseado em papéis, com este controle de acesso, as decisões são baseadas no papel que cada usuário possui na empresa (FERRAIOLO; GILBERT; LYNCH, 1993), desta forma a delegação de permissões é interligada com um papel e não diretamente com o usuário. Este tipo de relação e de controle de acesso é muito buscado por empresas do setor comercial e governamentais, ao centralizar o controle e a manutenção dos acessos de acordo a determinada função na organização. (FERRAIOLO; GILBERT; LYNCH, 1993). Este controle possibilita limitar os espaços abertos disponíveis para ameaças externas ou internas, acessarem ou modificarem as informações, por conta da delegação de acesso apenas às permissões que o usuário necessita.
1.4 ESTRUTURA DA MONOGRAFIA
Este trabalho está dividido em seis capítulos. A seguir, será apresentada a estrutura do trabalho:
Capítulo 1 – Introdução: este capítulo apresentou a introdução, problema, os objetivos e a justificativa do trabalho.
Capítulo 2 – Revisão bibliográfica: este capítulo apresenta temas relacionados à Segurança de Informação, assim como Auditoria de Segurança de Informação, Computação na Nuvem, Gestão de Identidade e Acesso (IAM) e o modelo de Controle de Acesso RBAC (Role Basic Access Control).
Capítulo 3 – Metodologia: este capítulo apresenta a metodologia de pesquisa, a proposta da solução e as delimitações do projeto.
Capítulo 4 – Projeto de Gestão de Identidade e Acesso: este capítulo apresenta o desenvolvimento de um estudo de caso, baseando-se em uma empresa de pequeno porte, assim como a definição das ferramentas utilizadas, entre outros.
Capítulo 5 – Validação do Projeto: este capítulo apresenta a modelagem e a implementação da gestão de identidade e acesso.
Capítulo 6 – Conclusões finais: este capítulo apresenta as conclusões deste trabalho e sugestões para trabalhos futuros.
2 REVISÃO DA LITERATURA
Este capítulo apresenta a revisão da literatura, abordando assuntos de segurança da informação, gestão de acesso e identidade, entre outros.
2.1 SEGURANÇA DA INFORMAÇÃO
O interesse e a importância das informações, para as empresas, cresceu ao longo dos anos. De acordo com Sêmola (2003, pag. 3), a informação, que era apenas uma promissora ferramenta na época dos mainframes, passou a auxiliar na prática da moderna gestão, participando ativamente nas ações da empresa, ganhando força atribuída a grande velocidade com o uso dos computadores pessoais, os terminais desktops.
Stallings (2008, pag. 3) caracteriza a transição da forma de segurança da informação nessa reformulação, do uso de armários com fechaduras para o armazenamento nos computadores, utilizando ferramentas automatizadas que possibilitam a proteção.
Conforme Fernandes (2007):
A segurança passou a ser mais que um ato de fechar portas de escritórios ou de cofres de empresas. Devido ao grande número de dados estratégicos que possuem dados como: previsão de vendas, detalhes técnicos de produtos, resultados de pesquisas e arquivos e arquivos pessoais são informações valiosas, às quais se alguma empresa concorrente tiver acesso de forma indevida, tal fato pode acarretar sérios problemas.
Boran (1996), Wadlow (2000) e Abreu (2001) classificam a informação em quatro estruturas:
• Pública: Esta informação pode e normalmente é compartilhada pois não possui valor que inflija nas diretrizes da empresa.
• Interna: Este tipo de informação já pode conter valores ou dados da empresa, deve-se mantê-lo no âmbito organizacional porém caso compartilhado não irá prejudicar a empresa.
• Confidencial: Informação que não deve ser compartilhada fora da empresa, possui valor significativo que pode ocasionar perdas financeiras ou abalo na credibilidade e na imagem da empresa.
• Secreta: Está ligada diretamente as diretrizes da empresa, possui valor muito significativo e é imprescindível o tratamento adequado para não cair em mãos indevidas.
2.1.1 Princípios da segurança da informação
Conforme Stallings (2008, pg. 8-10), Sandhu, Samarati (1996) e Laureano (2005), existem princípios básicos para que serviços e comunicações, realizadas com o uso da internet, garantam requisitos essenciais de segurança, sendo alguns listados a seguir:
Autenticação: verificar se a entidade é realmente quem ela diz ser, garantindo as entidades de ponta, verificando sua autenticidade, e que a conexão não sofra interferência de terceiros fingindo ser uma das partes a fim de interceptar ou alterar a informação.
Autorização: determinação das permissões que a parte terá em relação a informação.
Integridade: a informação deve ser protegida contra modificações intencionais ou acidentais não autorizadas, deve-se garantir que a informação mantenha a sua estrutura.
Confidencialidade ou sigilo: proteger a informação para que seja acessada apenas pela pessoa autorizada, garantindo a identificação e autenticação das partes envolvidas.
Não repúdio: não permitir que uma entidade negue o envio, recebimento, modificação ou execução da informação.
Disponibilidade: garantir que a informação esteja disponível sempre que solicitado ou for necessária.
Sêmola (2003, pag. 45) complementa a lista detalhando ativo sendo todo elemento envolvido na troca de informações, na sua manipulação e processamento, como onde é armazenada e os equipamentos que a manipulam. Já a informação é detalhada como um conjunto de dados transmitido como uma mensagem entre os ativos, podendo ter ainda dois
tipos, sendo comunicativo, na troca de informações por mensagens como e-mail, ou transacional, atribuindo valor monetário à informação neste último.
2.1.2 Criptografia
A criptografia protege os dados armazenados no computador como os dados que trafegam na internet. (CERT.br 2012, pag. 51). É recomendado o seu uso para a fornecer uma forma de controle de acesso, principalmente se os dados são: utilizados por muitos usuários, transmitidos por redes sem proteção ou escritos pelo dono da informação. (CRAMPTON, 2011).
Segundo Tanenbaum (2001), a criptografia já existia no sistema de escrita hieroglífica dos egípcios. Ao longo dos anos vem sendo utilizada principalmente para fins militares e diplomáticos. Na área da computação é importante para a garantia da segurança em todo o ambiente computacional que necessite de sigilo em relação às informações trafegadas e armazenadas.
Na criptografia, o uso de chaves cresceu consideravelmente, desde o uso de chave de encriptação ou associação de esquema de chaves, onde o dono da informação possui uma chave secreta que possibilita a leitura deste arquivo, esta chave é compartilhada, ou fornecida uma chave secundária, ao destinatário da informação. (CRAMPTON, 2011).
Na figura 1 é possível identificar os tipos de atores, informações e objetos envolvidos no processo de criptografia.
Figura 1 – Termos utilizados associados a criptografia
Fonte: CERT.br (2012, pag. 68)
2.1.2.1 Tipos de Criptografia
Parziale e outros (2006) especificam as seguintes técnicas de criptografia e os métodos que os auxiliam.
2.1.2.1.1 Simétrica ou algoritmo da chave secreta
Utiliza-se de uma chave para o processo de criptografia, este processo só ocorre caso os extremos da comunicação aceitem a chave. Existem dois tipos de algoritmo simétrico: Block algorithms: ou algoritmo fechado, realiza o processo de criptografia por bloco de texto, porém o número de possibilidades na criptografia torna-o pouco utilizado.
Stream algorithms: ou algoritmo de mídia, é mais utilizado na encriptação de tráfego de dados telefônicos.
A vantagem para o uso de algoritmo simétrico é a eficiência, são fáceis de implementar, porém a gerência de suas chaves torna-o difícil de implementar.
2.1.2.1.1.1 Data Encryption Standard (DES)
De acordo com Hinz (2000) o DES surgiu na necessidade, em meados da década de 70, de se ter um padrão para o compartilhamento de dados criptografados, após formulações foi aceito pela NIST com a principal característica do uso de operações lógicas em uma quantidade pequena de bits. Prevalece sendo mais rápida por conta de sua codificação baseada em uma chave de 64bits.
2.1.2.1.1.2 AES
Utilizado pelo governo dos estados Unidos da América para a codificação de suas mensagens, possui uma eficiência maior que seu antecessor DES, utiliza chaves com blocos de tamanho 128, 192 ou 256bits.
2.1.2.1.2 Assimétrica ou algoritmo da chave pública
Diferencia-se por utilizar no seu processo de criptografia duas chaves, uma pública de conhecimento de todos, e uma privada guardada pelo dono da informação. Neste processo o remetente irá criptografar o dado com a chave pública do destinatário, quando este dado chegar no seu destino será feito o processo reverso utilizando a chave privada. Como a chave pública é de conhecimento de todos, não há a necessidade de troca de chaves. O inverso também é utilizado, quando o remetente irá criptografar o dado com sua chave privada, todos que realizarem o processo inverso com a chave pública do remetente poderão ler a mensagem, porém ela terá valor legal de que o próprio remetente enviou o dado por ser o único a possuir a chave privada.
2.1.2.1.2.1 Algoritmo RSA
O algoritmo RSA é um dos mais utilizados na criptografia assimétrica e na compreensão de Souza (2010):
RSA [RSA78] é um algoritmo de chaves assimétricas que fundamenta-se em teorias clássicas dos números. Seu nome vem das iniciais dos nomes do professores que inventaram o algoritmo, Rivest, Shamir e Adleman. RSA utiliza um par de chaves, uma pública e outra privada. Todas as mensagens são criptografadas com a chave pública e só podem ser lidas com a chave privada. Este algoritmo é considerado uma das melhores implementações de criptografia assimétrica.
2.1.2.1.3 Função HASH
A função hash utiliza do conceito de que, caso duas hash’s possuam a mesma mensagem, a mensagem é verdadeira. Para este processo o dado é transformado em um novo valor hash, este valor é comparado a uma impressão digital, pois é um valor único, por ter esta característica, desfazer o processo de transformação é praticamente impossível.
Neste processo de criptografia aparece o código de autenticação da mensagem, message authentication code (MAC), que irá ser o validador da mensagem transportada, ao enviar a mensagem é criado um MAC, na recepção é verificado o MAC recebido com o original, caso validado com sucesso a mensagem original conseguiu ser entregue.
2.1.2.1.4 Certificado digital e certificado de autoridade
Para garantir que não aconteça a intervenção de terceiros na troca de chaves, podendo ocorrer exposição de dados, foi criada a validação através de uma terceira aplicação, a autoridade certificadora (CA – certification authority), que além de possuir a chave pública do usuário informa mais detalhes que comprovam a sua veracidade.
2.1.2.1.5 Gerador de número randômicos
Para auxiliar no processo de elaboração de geração de chaves com valores diferentes dos anteriores, os geradores de números randômicos são utilizados, possibilitando uma variação maior e uma consequente menor possibilidade de se criar uma chave ou um valor já utilizado.
2.1.2.2 Criptografia e computação na nuvem
A criptografia fornece a integridade e confiabilidade necessária para os dados que são acessados na nuvem, provendo a privacidade desta informação e a ilegibilidade a terceiros. Também exerce papel no certificado de autorização de base, onde através de chaves, como certificado digital, verifica e valida os usuários para manter a segurança deste ambiente, permitindo que a nuvem possa ser flexível na disponibilidade global de acesso e, assim, mantendo a escalabilidade por proteger o seu funcionamento. (ZISSIS; LEKAS, 2012).
2.1.3 VPN
Com o grande aumento da internet, e do seu uso massivo por empresas e usuários, o foco de uso deste meio está alterando, as empresas percebem uma oportunidade para estender as suas aplicações e as informações da organização através do globo, utilizando de redes seguras, virtuais e privativas, as VPN (Virtual Private Network). Estas redes já estão se tornando padrão por grandes vendedores de tecnologia, facilitando a aderência, economizando custos e aproximando as empresas de seus fornecedores, compradores e usuários. (PARZIALE, et al, 2006, pag. 861-862).
As VPN possibilitam a criação de um túnel seguro para o tráfego das informações, através do uso da internet convencional. Antes de um dado ser transmitido, este é encapsulado dentro de um pacote que irá possuir um cabeçalho. O cabeçalho é responsável por conter a informação de destino do pacote, este irá navegar pela internet até chegar ao seu destino. No destino ele é “desencapsulado” e a informação entregue ao computador de destino, para chegar até o final ambos os lados do túnel devem suportar o mesmo protocolo. (THE GOVERNMENT OF THE HONG KONG, 2008).
Existem funções básicas para que as VPN possibilitem a seguridade dos dados trafegados, sendo confidencialidade, integridade e autenticidade, tendo em vista, respectivamente, a privacidade dos dados, a não adulteração e a identificação e autorização dos meios envolvidos. Desta forma a VPN utiliza-se da criptografia para manter a confidencialidade, a autenticação por parte de certificados e um conjunto de padrões e protocolos em volta do cabeçalho. (ROSSI, FRANZIN, 2000).
2.1.3.1 Tunelamento
Como dito por Chin (1998), “túnel é a denominação do caminho lógico percorrido pelo pacote ao longo da rede intermediária”, desta forma o dado é encapsulado, com o uso de protocolos e criptografia, percorrendo o túnel até seu destinatário. No destino, o pacote é desencapsulado para a sua leitura. Este processo, portanto, é dividido entre encapsulamento do dado, transmissão deste e desencapsulamento no destinatário. (CHIN, 1998).
2.1.3.1.1 Protocolos de tunelamento
Conforme Rossi, Franzin (2000) e Chin (1998), os protocolos mais utilizados no VPN são:
IP Security Tunnel Mode (IPSec): constitui-se como um conjunto de padrões e protocolos para a segurança relacionada ao VPN, foi definido pelo órgão Internet Engineering Task Force (IETF) e tem como fundamento o uso dos cabeçalhos Authentication Header (AH) e Encapsulated Security Payload (ESP), separados ou em conjunto, com o intuito de prover a autenticidade e integridade do pacote. O IPSec pode e é ujtilizando tanto para IPv4 como para IPv6.
Layer 2 Tunneling Protocol (L2TP): Também formulado pela IETF, permite que o pacote seja criptografado e trafegado pela comunicação ponto a ponto.
Point to Point Tunneling Procotol (PPTP): Protocolo desenvolvido pela Microfost, também permite a criptografia e encapsulamento do dado para o tráfego através da internet.
2.2 CLOUD COMPUTING
Cloud computing, ou nuvem computacional, é a rede de computadores espalhadas pelo globo que guardam as informações e deixam elas disponíveis a qualquer momento e em qualquer lugar. O conceito da nuvem pode ser comparado às redes elétricas, nós usuários não percebemos a energia trafegando entre os postes até chegar nas nossas residências, porém ao ligarmos uma lâmpada conseguimos ter essa energia e iluminar o ambiente, da mesma forma as informações na nuvem ficam dispersas e apenas conseguimos visualizá-las através de aplicações. (TAURION, 2009, pag. 10-11).
Leandro (2012, pag. 29) conceitua o termo computação em nuvem como a evolução que descreve o desenvolvimento de muitas das tecnologias e abordagens existentes em computação. A nuvem segrega a infraestrutura básica das aplicações e dos recursos de informação, além dos mecanismos utilizados para entregá-los.
Segundo Buyaa, Yeo, Venugopal, Broberg, Brandic (2009):
A nuvem é um tipo de Sistema paralelo e distribuído que é constituído de uma coleção de computadores virtualizados e interconectados, que são dinamicamente provisionados e representados como um ou mais recursos computacionais unificados, baseados no acordo de serviço estabelecido entre as partes de serviço, provedores e usuários.
Na nuvem as informações permanecem reunidas, facilitando o armazenamento e o acesso aos recursos dispostos nela, permitindo integrações de aplicações com a rede e deixando disponível e transparente os dados. (SILVA, 2009).
A nuvem é atrativa por proporcionar que informações e conhecimentos fluam pela empresa de forma rápida, diferentes ambientes organizacionais visualizam os dados atualizados em um único lugar, fortalecendo a disseminação da informação, que a cada dia torna-se crucial para a sobrevivência da empresa. (TAURION, 2009, pag. 19).
Outra possibilidade da nuvem é fornecer virtualizações de máquinas, de modo que simule um sistema operacional os recursos de software que o sistema que acessa não possui e não necessita. Desta forma a aplicação poderá ser executada sem ter que prover dos recursos computacionais no sistema operacional base. (GOLDEN; SHEFFY, 2008).
Existem parâmetros cruciais para as empresas em relação à nuvem, tais como tempo, custo, disponibilidade e segurança. O provedor da nuvem deve garantir a disponibilidade de seu serviço conforme contrato, assim como o cumprimento dos prazos respectivos a disponibilidade no acesso aos dados de os contratos de serviço, este contrato refere-se ao Service Level Agreement (SLA), amparado no contrato as nuvens apresentam-se ser robustas, confiáveis e provém a disponibilidade necessária. (BUYAA, YEO, VENUGOPAL, BROBERG, BRANDIC, 2009).
Estas definições são vistas na figura 2 criada pela National Institute of Standards and Technology (NIST).
Figura 2– Modelo visual de definição de Computação em Nuvem
Fonte: (NIST, http://www.csrc.nist.gov, 2009).
2.2.1 Características do Cloud Computing e modelos de implantação
De acordo com Dialogic (2010), entre as característica da computação na nuvem se destacam:
Shared Infrastructure ou a infraestrutura compartilhada virtualiza e permite a utilização de serviços físicos como armazenamento e capacidade de navegação.
Dynamic Provisioning ou a provisão dinâmica libera a porção de serviço contratada no instante que é firmado o contrato ou o pagamento.
Network Access ou o amplo acesso é realizado via internet, através de aplicações como navegadores em computadores, notebooks e celulares.
Managed Metering ou o uso sob demanda é realizada de acordo com o uso do usuário, ou do contrato estabelecido, quando mais utilizada a nuvem, e os seus recursos, maior vai ser o custo pago.
Já Australian (2010) e Leandro (2012) listam os seguintes modelos de implantação, como vistos na figura 2:
Private or internal cloud: A nuvem privativa ou interna, é criada em uma organização e a própria organização que deve realizar o gerenciamento com auxílio de aplicações.
Community cloud: A nuvem comunitária é suportada por diversas organizações e a deixam abertas para o uso da comunidade que partilha interesses, como pesquisas, políticas ou missões.
Public cloud: A nuvem pública provém de empresas de grande porte que disponibilizam de forma gratuita o serviço de hospedagem.
Hybrid cloud: O misto das nuvens parte da utilização de diferentes tipos de nuvens que, mesmo sendo ambientes diferentes, possibilita uma entidade única, permitindo a portabilidade de dados e balanceamento de carga entre elas.
2.2.2 Cloud Computing como serviço
Australian (2010), Dialogic (2010) e Leandro (2012) conceituam os tipos básicos de serviços oferecidos na nuvem como:
2.2.2.1 Software as a Service (SaaS)
Oferece aplicações e serviços na forma de aluguel, paga-se mensalidades ou contratos para a utilização de funções, ou sistemas, dispostas pela empresa na nuvem. Não é necessário a instalação de aplicações, o próprio provedor fornece um ambiente de fácil acesso, como através de um navegador. Possui uma dificuldade menor no seu gerenciamento, e não permite o gerenciamento, ou controle, do consumidor na infraestrutura desde ambiente. Exemplos deste serviço são os sistemas de gestão de relacionamento, ou Customer Relationship Management (CRM), e gestão de recursos humanos, ou Human Resources Management (HRM).
2.2.2.2 Platform as a Service (PaaS)
Dispõe de um ambiente para que os usuários que contratarem este serviço possam implantar as suas aplicações e as executar, utilizando do hardware e processamento da empresa contratada. O usuário não terá controle da infraestrutura contratada, mas poderá programar e configurar as aplicações dispostas, através de linguagens, frameworks ou controles dispostos.
2.2.2.3 Infrastructure as a Service (IaaS)
A sua contratação deve-se a necessidade de se obter um espaço para armazenamento centralizado de informações, como também para a utilização do hardware contratado, provendo além do armazenamento e de processamento, redes e outros recursos computacionais, possibilitando uma infraestrutura base para um centro de dados empresarial.
2.3 GERENCIA DE IDENTIDADE E ACESSO
A gerencia de identidade e acesso, ou Identity Access Management (IAM), refere-se a administração de usuários, de uma empresa ou rede, dentro de um sistema. Através desta gerência é possível criar e administrar papéis e permissões a cada usuário, com o auxílio de ferramentas e tecnologias que garantam o controle do acesso aos dados críticos da organização. Desta forma a gerência assegura o cumprimento das políticas corporativas e governamentais estabelecidas na empresa, possibilitando a sua manutenção e o seu ciclo de vida contínuo. (WATERS, 2004).
Kaur (2011) complementa afirmando que IAM provê aos usuários um acesso limitado apenas aos dados pré-dispostos nas permissões, assim aumentando a segurança
destas informações, considerando desde os usuários internos maliciosos, como o acesso externo através do acesso do usuário da empresa.
Messmer (2013) detalha a importância do uso da gerência de identidade e acesso (IAM) nos acessos ao ambiente em nuvem utilizando uma previsão da empresa Gartner, que prevê um investimento bilionário até 2017 relacionado ao acesso seguro. Neste o IAM entra com a possibilidade de gerir os usuários e as permissões com a criação e controle de papéis de acesso.
2.3.1 RBAC
O controle de acesso baseado em papéis, ou Role-Based Access Control (RBAC), tem como concepção a associação de papéis, sendo que usuários são atribuídos aos papéis correspondentes e, por consequência, atribuem as permissões ligadas a eles. Os papéis são criados e moldados para suprirem os cargos existentes na organização e os usuários atribuídos aos cargos dependendo de suas responsabilidades e qualificações. Desta forma usuários poderão ser realocados de papéis facilmente, além de facilitar a atribuição e negação de permissões com a atribuição, ou alteração, dos sistemas incorporados. (SANDHU, 1997).
Desta forma assume-se que as informações dispostas no sistema não pertencem aos usuários, mas sim à organização na qual estão contidas. (PAVLICH-MARISCAL, et al, 2005).
De acordo com Sandhu (1997), o Instituto Nacional de Padrões Tecnológico, ou NIST (US National Institute of Standards and Technology), em um estudo demonstrou que o RBAC adere a várias necessidades de empresas do setor comercial e governamental, por ter esta separação de atribuições conforme o papel do usuário no sistema, por centralizar o controle e a manutenção de acessos em poucos usuários, e pelo fato das empresas verem o seu controle de acesso como único, necessitando de uma adequação flexível de um produto para tal.
2.3.1.1 Introdução RBAC
O modelo de RBAC tem seu início com aparição nos anos 1970 trazendo uma noção diferente da utilizada, uma nova camada chamada de role, ou papel.
RBAC suporta diretamente três princípios conhecidos de segurança: a abstração de dados, a separação de tarefas e a questão do mínimo privilégio. Este último refere-se ao fato de que no modelo de RBAC o usuário só terá as permissões que estão concedidas ao seu papel, limitando e possibilitando o acesso a apenas o que é necessário ao seu trabalho, a abstração de dados é observada pelo fato de permitir a abstração de permissões específicas, como retirar um valor de uma conta, ao invés das permissões habituais de ler, escrever e executar. A separação de tarefas é vista ao assegurar que papéis tenham uma participação mútua em uma determinada tarefa. (SANDHU, 1997).
2.3.1.2 Modelos do RBAC96
O conceito do modelo de RBAC é interpretado de diferentes maneiras, desde um modelo simples aos mais sofisticado, nesta gama de interpretações observa-se quatro conceituais modelos conforme Sandhu (1997, pag. 5):
RBAC0 sendo o modelo básico para implementação do RBAC
RBAC1 e RBAC2, que tem em si contidos o modelo RBAC0, mas adicionando ao RBAC1 o conceito de um papel interagir com outros papéis através de uma permissão, e adicionando ao RBAC2 restrições nas configurações do modelo.
RBAC3 possui todos os modelos atribuídos.
Figura 3– Relação entre os modelos RBAC96
Fonte: Sandhu (1997, pag. 6)
2.3.1.2.1 RBAC0
No conceito base do RBAC, não é vista a parte de hierarquia e restrições. Este modelo é caracterizado pela definição inicial dos usuários, papéis e permissões e pelas interações entre eles.
2.3.1.2.1.1 Papel
Sandhu (1997, pag. 3) denota um papel, ou role, como uma construção semântica, a qual é acrescida de políticas de controle de acesso. Este papel é visto como mais estável pois nas organizações têm a tendência de mudar muito pouco as atividades exercidas, e mesmo assim os usuários e permissões que estão interligados aos papéis são transitórios. Um papel também representa uma competência do usuário associado a ela, uma autoridade ou até responsabilidade. (SANDHU, 1997, pag.5).
Por ser um conceito mais antigo que o próprio controle de acesso, o papel tem uma grande variação e amplitude, porém deve-se focar na perspectiva do controle de acesso. (SANDHU, 1997, pag. 3).
2.3.1.2.1.2 Permissão
A permissão, ou permission, refere-se ao acesso a um ou vários objetos na organização, ela também é vista como um privilégio ou direito de acesso ao determinado objeto. Uma permissão a um objeto concede determinadas ações, como na sua manipulação. Uma permissão pode se referir a uma pequena ação em cima de um objeto, ou ao total acesso a uma determinada rede, desta forma deve-se entender a permissão a ser criada. O modelo RBAC não possui permissão negativa, apenas não é concedido o acesso. (SANDHU, 1997, pag. 5). A permissão, portanto, poderá ser vista por diversas formas dependendo da sua ação, como acesso a uma tabela, coluna, arquivos de sistema ou até atribuição de acesso. (PAVLICH-MARISCAL, et al, 2005).
2.3.1.2.1.3 Objeto
É um dado, um recurso disponível no sistema acessado. (SANDHU, 1997, pag. 5).
2.3.1.2.1.4 Usuário
O usuário, ou user, é representado pela pessoa física que irá ganhar o acesso, porém também pode ser caracterizado como uma máquina inteligente que exerça a mesma função que a pessoa física. (SANDHU, 1997, pag. 5)
2.3.1.2.1.5 Interações
O modelo de RBAC0 possui duas interações com os papéis, os usuários associados, caracterizado por user assignment (UA), e as permissões associadas, como permission assignment (PA), estas relações podem ser de um para um à vários para vários, desta forma um papel poderá ter um ou vários usuários ligados a ele, e este papel poderá ter
uma permissão ou várias permissões de acesso. Ainda neste contexto um usuário poderá estar relacionado a vários papéis, assim como uma permissão. Estas ligações que caracterizam o RBAC, colocando o papel como intermediário impedindo a ligação direta de usuários com as permissões. (SANDHU, 1997, pag. 7).
2.3.1.2.1.6 Sessão
Para cada acesso de um usuário no sistema, este estará ligado a uma sessão, um usuário poderá ter várias sessões abertas caso acesse por diferentes telas ou instâncias da aplicação. Um usuário após ter acesso ao sistema, só conseguirá mudar de papel caso saia da sessão e realize um novo acesso ao sistema, ou caso seja desconectado por inatividade. (SANDHU, 1997, pag. 7).
2.3.1.2.2 RBAC1
A base do modelo RBAC1 é a introdução da hierarquia nos papéis, desta forma é possível refletir a estrutura organizacional separadas pelas suas autoridades e responsabilidades. Por convenção é visto os papéis com maior autoridade na parte superior, conforme figura 4, e os papéis com menor autoridade na parte inferior. As permissões têm uma propriedade de herança entre os papéis na hierarquia, como visto na imagem 4, além de possuir as suas próprias permissões o desenvolvedor júnior possui todas as permissões que o estagiário possui, já o supervisor do projeto possui tanto as permissões do desenvolvedor júnior como as do técnico de testes mais as suas próprias. (SANDHU, 1997).
Figura 4 – Hierarquia entre os papéis de um projeto
Fonte: Sandhu (1997, pag. 9)
Também é possível delimitar as permissões herdadas na hierarquia, como visto na figura 4, o supervisor do projeto herda as permissões do técnico de testes. Caso exista uma permissão que deva ser atribuída ao técnico mas não deve ser atribuída ao supervisor, cria-se um papel superior ao técnico de testes, o técnico de testes 2. Desta forma será atribuída a permissão a este papel, o supervisor continuará a ter as permissões do técnico herdadas porém sem as permissões do técnico 2. Os técnicos de teste que necessitarem a permissão serão ligados ao técnico 2, continuando também a herdar todas as permissões do técnico (SANDHU, 1997, pag. 10)
2.3.1.2.3 RBAC2
No modelo conceitual RBAC2 aparece a questão das restrições, por exemplo estas possibilitam a separação de deveres de uma organização. Com a criação de restrições usuários não poderão ser ligados a papéis mutuamente exclusivos, como no setor financeiro um usuário não pode possuir o papel de responsável pela compra e pela quitação, evitando assim que fraudes venham a acontecer. As restrições também possibilitam a limitação de acessos administrativos e a centralização desses acessos aos gestores responsáveis. (SANDHU, 1997, pag. 11).
Estas restrições de exclusão mútua, separando os deveres na organização, podem ser utilizadas também em permissões, não sendo possível um papel ser ligado a permissão para solicitar e assinar cheques. Desta forma as restrições possibilitam que permissões com grande poder dentro da organização possuam um controle maior na sua liberação, limitando-a. (SANDHU, 1997, pag.13)
2.3.1.2.4 RBAC3
O modelo conceitual RBAC3 abrange todos os três modelos anteriores, tendo toda a questão dos usuários, papéis, permissões e sessões, as suas interações, a questão de hierarquia e a questão de restrições. Pelo fato de conter tanto a hierarquia como a questão de restrições a sua implementação é mais difícil e requer um cuidado maior para que um conceito não impeça a execução e o funcionamento do outro. Por outro lado ao serem utilizados estes conceitos em conjunto permitem uma maior segurança e separação dos papéis e permissões, podendo separar uma equipe em hierarquia limitando o número e o ingresso de determinados papéis ou permissões. (SANDHU, 1997, pag. 14-15)
É possível visualizar o modelo RBAC3 na figura 5 com as interações, papéis, usuários, permissões e onde a hierarquia e as restrições entram em ação.
Figura 5 – Modelo conceitual RBAC3
2.3.1.3 Administrative RBAC97
No modelo RBAC percebe-se a dificuldade em limitar a administração de atribuições em poucos usuários, com a necessidade de se centralizar este controle para manter um padrão alto de segurança foram criadas variações do RBAC. (SANDHU, 1997, pag. 17). Como descrito por Sandhu (1997, pag.18) “Descentralizar os detalhes da administração do RBAC sem perder o controle central sobre o quadro de políticas é um atual desafio para arquitetos e designers de sistemas”.
Um modelo desta administração é a de Moffet e Sloman que definem o elaborado controle com papéis de domínio, gerentes, donos e chefes administrativos que não possuem um controle total, mas sim pequenas atribuições que necessitam de colaboração e aprovação entre eles nas atribuições. (SANDHU, 1997, pag. 18).
Desta forma, para se ter o controle das atribuições dos papéis e das permissões aparecem dois novas variantes, os papéis administrativos, ou administrative roles (AR), e as permissões administrativas, ou administrative permissions (AP). (SANDHU, 1997, pag 18).
2.3.1.3.1 Administração de Permissões e Papéis
A administração de permissão difere-se da permissão na autorização de mudanças nos componentes dos modelos conceituais do RBAC96, desta forma gera novos modelos conceituais com estas alterações, sofisticando estes modelos adicionando a letra A, como em ARBAC0, na nomenclatura evidenciando o uso administrativo nestes. O modelo ARBAC pode ser utilizado para garantir um controle administrativo no modelo conceitual RBAC3. (SANDHU, 1997, pag. 18).
O conceito desta administração está quando um papel ou permissão é requisitado, neste caso é mapeado na hierarquia da solicitação o responsável administrativo, no caso um papel poderá ter o direito para incluir dados mas poderá ter que realizar uma solicitação para a exclusão caso não possua direitos administrativos. (SANDHU, 1997, pag. 20).
2.3.1.3.2 Modelo ARBAC97
Conforme SANDHU, COYNE, GANIA, YOUMAN (1997) O modelo administrativo é separado em três componentes, conforme a interação entre as variantes, como visto abaixo:
URA97: interação entre o usuário (User) e o papel (Role).
PRA97: interação entre a permissão (Permission) e o papel (Role). RRA97: interação entre papéis (Roles).
2.3.1.3.3 URA97
O componente URA97 está ligado diretamente a autorização de inserção de usuários em papéis, através do usuário com papel de controle administrativo, porém não é possível atribuir permissões aos papéis. Para que seja possível a atribuição é necessário que os usuários sejam elegíveis ao papel, ou seja, necessitam já estar com uma determinada condição para que possam ter esta atribuição realizada, e de forma oposta um usuário poderá ter o seu papel revogado porém continuará a pertencer ao seu papel de pré-condição. (SANDHU, 1997, pag. 21-22)
2.3.1.3.4 PRA97
O componente PRA97 está interligado ao componente URA97, seu fundamento segue o mesmo padrão tendo como sua referência a ligação entre papéis e permissões. Um usuário com papel de controle administrativo poderá atribuir ou revogar permissões a outros papéis que estejam em seu círculo de controle, porém não terá como atribuir usuários a papéis. (SANDHU, 1997, pag. 25)
2.3.1.3.5 RRA97
O componente RRA97, conforme Sandhu (1997, pag. 25), por ser a ligação entre papéis, possui uma atribuição diferente, primeiro é identificado o tipo de papel entre:
Habilidades (A): papéis que possuem apenas permissões e outras habilidades atribuídas a eles.
Grupos (G): papéis que possuem apenas usuários e grupos de usuários atribuídos.
UP-Roles (UPR): é relacionado aos papéis que possuem usuários e permissões, além de grupos e habilidades, atribuídas a eles, o nome é atribuído UP por conta dos usuários e permissões presentes no papel.
A importância desta divisão é para a facilidade da busca e atribuição de usuários e permissões, criando assim coleções representadas por apenas uma única unidade, facilitando o seu uso. Para a organização hierárquica é utilizado o componente PRA97 mas utilizando as habilidades no lugar de permissões, criando ARA97, da mesma forma para o controle dos grupos é utilizado o componente URA97, mas atribuindo os grupos no lugar dos usuários. (SANDHU, et al, 1997).
2.4 CONSIDERAÇÕES FINAIS
Neste capítulo foram levantadas informações como a questões de segurança, o fundamento da computação na nuvem e o uso da gerência de identidade, assim como a fundamentação do RBAC, utilizado na gerência proposta. No capítulo 3 é apresentado o método deste trabalho.
3 MÉTODO
No entender de Gil (1999) e Lakatos (1993), ambos citados por (SILVA e MENEZES, 2005) o método científico destina-se no alinhamento do raciocínio, através de processos ou operações mentais, nas investigações do seu desenvolvimento. Da mesma forma Gil (1999) ressalva o elemento principal a ser obtido com o alinhamento do raciocínio, respostas para problemas levantados.
Já Souza (2005) ressalta o ponto de que o método engloba todos os processos do projeto, desde a sua formulação inicial à escrita da conclusão final.
3.1 CARACTERIZAÇÃO DO TIPO DE PESQUISA
A caracterização da pesquisa neste projeto terá como base a abordagem do problema, desta forma existem duas pesquisas que podem ser elaboradas, a pesquisa quantitativa e a pesquisa qualitativa, salienta Silva e Menezes (2005), comtemplando com as definições:
Quantitativa: Baseia-se que os resultados a serem obtidos serão tratados, classificados e analisados de forma quantificada, utilizando recursos estatísticos para a fundamentação.
Qualitativa: Segue o formato de que os dados obtidos serão interpretados na forma natural, por indução do pesquisador.
Neste projeto a caracterização a ser utilizada será a qualitativa, com a utilização dos dados obtidos, através de entrevistas e mapeamento de funções e processos, na etapa do estudo da empresa, sendo utilizados para a inserção da aplicação de apoio com o objetivo de retornar, as informações e fundamentados, o resultado a fim de documentar as melhorias, caso existam, da utilização e inserção do gerenciamento de acesso, assim como o levantamento dos dados da parte de segurança envolvidos no projeto.
3.2 ETAPAS METODOLÓGICAS
As etapas correspondem as fases conseguintes deste projeto, sendo detalhadas da seguinte forma:
Revisão da literatura: nesta etapa serão detalhados os temas, modelos, conceitos e métodos utilizados desde a questão da segurança da informação até a parte de gerência de acesso e identidade.
Elaboração do esquema de gestão de acesso: A elaboração englobará os cenários envolvidos no processo de acesso de um usuário a um certo dado, tendo esta etapa uma elaboração gráfica do processo, desde a sua requisição de acesso, partindo da questão de criptografia e protocolo envolvidos, em que meio este estará acessando, até a forma de como será tratada esta requisição.
Estudo das ferramentas de gestão do acesso: A partir da elaboração gráfica do processo pronta, serão pesquisadas as ferramentas para que possam, em conjunto, possibilitar o funcionamento do fluxo de informações.
Seleção das ferramentas e sistemas a serem utilizados: Serão detalhadas as ferramentas a serem utilizadas no processo descrito na etapa de elaboração do esquema de gestão de acesso, assim como de que forma estas ferramentas serão utilizadas e como influenciará o processo.
Estudo da empresa e formalização da hierarquia organizacional: Nesta etapa será demonstrado o funcionamento do ciclo dos dados na empresa pesquisada, assim como a descoberta dos papéis através da parte gráfica detalhando a hierarquia organizacional da empresa, a evidência das permissões para cada papel e as demais permissões utilizadas.
Aplicação do modelo de RBAC: Com os papéis e permissões apresentados, nesta etapa será realizada a gestão de acesso, com o uso do modelo RBAC.
Validação da gestão e dos usuários: Realizada a aplicação do modelo, serão testados e registrados os usuários e os seus acessos, com a aplicação já ambientada e configurada para o uso no ambiente da empresa estudada.
Levantamento dos resultados finais: Será documentado os resultados gerados com a implantação da gerência de acesso, os pontos positivos e negativos observados pelos funcionários da empresa estudada.
Recomendações e conclusão da monografia: A última etapa descreverá as recomendações de gestão de acesso com base no modelo RBAC, apresentando também a conclusão da implantação e o impacto desta na organização.
Estas etapas podem ser visualizadas na figura 6.
Figura 6 – Etapas metodológicas TCC
3.3 DELIMITAÇÕES
No que se refere às limitações deste trabalho, o projeto de gerência do acesso ás informações, em um ambiente na nuvem, será aplicado diretamente a uma organização, com o intuito de propor e relatar o uso do modelo de RBAC. O projeto terá seu foco no levantamento de dados, esquematização da gerência de identidade e acesso e validação desta, e mesmo tendo a parte de criptografia e cloud computing apresentados, estes não serão implementados, sendo apenas objetos de estudo para a geração do ambiente proposto.
Será exposto no projeto a pesquisa em bases para consultas, será considerado que as bases consultadas já estarão criadas e estruturadas, assim como que a parte de cadastramento, alteração e remoção das informações contidas são realizadas por ações fora do escopo deste projeto.
O projeto delimita-se a validação da esquematização realizada, através do processo manual, fora de um ambiente desenvolvido, para a realização do acesso e a validação desta. Sendo apresentada apenas as imagens e instruções de retorno visando expor a ações decorrentes da esquematização realizada.
4 ESQUEMATIZAÇÃO DO ACESSO AO AMBIENTE NA NUVEM
No capítulo presente é detalhado a esquematização do modelo de acesso ao ambiente na nuvem. Para a realização do esquema é realizada uma descrição inicial do processo de acesso ao ambiente, sendo por tópicos detalhando do macro processo ao processo por completo.
Também é verificado, com o mapeamento final, os principais benefícios e diferenças do modelo proposto com outros tipos de gerência já existentes.
4.1 ESQUEMATIZAÇÃO DA GERÊNCIA
A fim de se estabelecer a gerência de identidade, na figura 7 evidencia-se a comunicação entre o funcionário e o ambiente em nuvem. Conforme na figura 7 o funcionário irá solicitar o acesso ao ambiente na nuvem, esta solicitação irá enviar ao ambiente o login e senha, no ambiente na nuvem será autenticado o funcionário, esta autenticação irá atribuir um token ao funcionário, e neste token estará atribuído a um respectivo papel. Este papel, por sua vez, terá permissões e políticas de segurança vinculadas no sistema.
O funcionário poderá estar atribuído a um papel com o token de acesso, mas poderá abrir diversas sessões de acesso ao mesmo tempo a fim de acessar com outros papéis o sistema. Estas múltiplas sessões ocorrem com o acesso de usuário e senha diferentes, obtendo token com atribuição de um diferente papel dependendo do cadastro na base de dados.
Figura 7 – Esquema de acesso ao ambiente na nuvem
Fonte: Elaboração do autor. (2014).
4.2 ACESSO AO AMBIENTE NA NUVEM
O processo começa com o usuário realizando a tentativa de acesso ao ambiente na nuvem, esta situação é vista na figura 8.
Figura 8 – Negociação de acesso entre usuário e o ambiente na nuvem
Fonte: Elaboração do autor. (2014).
O acesso ocorre em duas partes, a primeira inicia com o usuário informando, nos campos da página de acesso, o seu usuário e senha, ao clicar em acesso irá gerar uma negociação entre as extremidades. Nesta negociação o usuário estará enviando as suas
informações de acesso para o ambiente na nuvem, na nuvem será tratada esta informação de forma a gerar o certificado de acesso do usuário, o seu token de segurança. Este token é então transmitido ao usuário. Com o token o usuário solicita o acesso a um sistema, aplicação, ou dado, esta solicitação irá enviar o token para validação de suas permissões, retornando o acesso ou a rejeição deste. Ambas as negociações, as duas partes de acesso, podem ser visualizadas na figura 9.
Figura 9 – Detalhamento da negociação entre usuário e o ambiente na nuvem
Fonte: Elaboração do autor. (2014).
4.2.1 Solicitação da chave de acesso (token)
A primeira parte deste acesso ocorre com o envio dos dados, usuário e senha, ao ambiente na nuvem, estes dados serão recebidos na unidade de autenticação, para este sistema será chamado de UAU, unidade autenticadora de usuários. A UAU ao receber os dados irá realizar uma pesquisa ao banco de dados dos usuários, neste esquema será chamado de UB, users base ou base de usuários, a pesquisa consiste em validar se, na UB, consta um cadastro correspondente ao login e senha informados.
Se as informações de acesso do usuário correspondem a um dos dados armazenado na base será continuado o processo para a geração de um novo token, sendo
armazenadas as informações do usuário para atribuir ao novo token. Caso não retorne um cadastro correspondente na base de usuários será retornado ao usuário uma mensagem de erro, solicitando que informe novamente as informações de acesso na tela inicial.
Com o resultado positivo de conter o usuário cadastrado no UB, o UAU irá comunicar-se com o UGT, unidade geradora de token, a fim de gerar um novo token para cadastrar as informações do usuário. Este token terá, além das informações do usuário, as informações da data de expiração de utilização e o papel, este atribuído na próxima etapa.
Com o token gerado e as informações atribuídas a ele, o UAU irá realizar uma busca pelo papel onde este usuário está atribuído, esta busca será realizada em conjunto com o UPB, user policy base ou base de políticas do usuário.
O UPB irá verificar, no PB, paper base ou base dos papéis, em qual papel o usuário está atribuído, para esta verificação ele colhe as informações do token e as compara com os dados cadastrados no PB. Caso não seja localizado nenhum registro no PB correspondente ao usuário será enviado ao usuário uma mensagem, nela estará informando para verificar com o setor de TI o seu cadastro. Caso localizado o papel onde está atribuído o usuário, o UPB irá verificar as permissões, estas que serão atribuídas ao papel, junto ao PeB, o banco de permissões. O UPB irá, através do papel, atribuir as permissões a ele para então atribuir o papel ao token.
Com todos os dados coletados, e as informações atribuídas ao token, o UAU irá retornar, através da negociação de acesso, o token ao usuário. Com o token o usuário irá realizar a segunda parte do acesso ao ambiente na nuvem. Todo o processo da primeira parte de acesso está representado na figura 10.
Figura 10 – Mapeamento da primeira parte de acesso ao ambiente na nuvem
4.2.2 Solicitação do acesso ao sistema
A segunda parte do acesso ocorre quando o usuário solicita o acesso a um sistema, aplicação ou dado no ambiente na nuvem. Nesta solicitação o usuário estará enviando o seu token, este será recepcionado pelo UAU que, ao receber o token, irá realizar a validação das informações contidas neste. Serão realizadas três verificações na segunda parte de solicitação de acesso, onde na primeira verificação é realizada a validação em conjunto ao UCT, a unidade de controle de token.
Na UCT serão realizadas três verificações no processo de validação, só será realizada a próxima validação caso a anterior tenha sido validada com sucesso. A primeira validação consiste em verificar a data de validade do token utilizado, sendo esta data inferior a data atual será gerada uma mensagem de alerta ao usuário, na qual estará informando para a renovação do token, esta renovação é realizada na nova solicitação de acesso através da tela inicial.
A segunda verificação consiste em validar as informações do usuário atribuídas ao token, informações como usuário, nome, ramal e outras informações cadastrais. Esta verificação é efetuada através da busca pelo usuário do token no UB, onde, caso conste o cadastro, serão comparados os dados. Da mesma forma como na primeira etapa de acesso, caso o usuário não seja encontrado no UB, será gerado uma mensagem informando para realizar um novo acesso.
A terceira verificação consiste em validar o papel atribuído ao token, a verificação de se o usuário está atribuído a aquele papel ocorre da mesma forma que a primeira etapa de acesso, onde o UAU irá comunicar-se com o UPB passando o usuário atribuído ao token, o UPB irá verificar a existência do usuário em um dos papéis no PB. Com a resposta negativa será gerado uma mensagem para uma nova solicitação de acesso. Caso positiva a resposta, será retornado o papel onde o usuário está atribuído. O UAU irá comparar o papel, atribuído ao token, com o informado pelo UPB, caso sejam diferentes será gerada a mensagem de alerta de novo acesso, caso seja igual o UAU irá passar ao UPB o papel atribuído ao token. O UPB irá verificar para o papel informado as suas permissões no PeB, atribuindo as permissões ao papel, atribuindo o papel ao token e retornando o token ao UAU, encerrando o clico de verificação do token.
O UAU, em posse do token, irá verificar em qual sistema, aplicação ou acesso o usuário está realizando a solicitação de acesso. Com a informação separada irá realizar a verificação da permissão exigida para o acesso solicitado, esta verificação é realizada em conjunto ao SPB, onde o UAU envia o papel atribuído ao token ao SPB. O SPB por sua vez irá verificar no SB, a base de sistemas, se as permissões atribuídas ao papel recebido são as necessárias para o acesso. Caso não possua todas as permissões necessárias irá retornar ao usuário uma mensagem informando a falta de permissões, caso positivo irá retornar ao UAU a liberação do acesso.
Com a resposta o UAU irá retornar ao usuário o acesso ao sistema solicitado, o processo respectivo a segunda parte do acesso é verificada na figura 11.
Figura 11 – Mapeamento da segunda parte de acesso ao ambiente na nuvem
