Atualmente trabalho para um fornecedor de software, especificamente soluções de controle de acesso. E minha experiência “de uma vida passada” está ligada ao lado do cliente - uma grande organização financeira. Naquela época, nosso grupo de controle de acesso no departamento de segurança da informação não podia se orgulhar de grandes competências em IdM. Aprendemos muito no processo, tivemos que enfrentar muitos obstáculos para construir um mecanismo funcional de gestão de direitos dos usuários nos sistemas de informação da empresa.
Combinando minha experiência de cliente suada com o conhecimento e as competências do fornecedor, quero compartilhar com vocês essencialmente instruções passo a passo: como criar um modelo de controle de acesso baseado em funções em uma grande empresa e o que isso resultará . Minhas instruções consistem em duas partes: a primeira é preparar-se para construir o modelo, a segunda é realmente construir. Aqui está a primeira parte, a parte preparatória.
NB Construir um modelo, infelizmente, não é um resultado, mas um processo. Ou melhor, até faz parte do processo de criação de um ecossistema de controle de acesso na empresa. Então prepare-se para o jogo há muito tempo.
Primeiro, vamos definir: o que é controle de acesso baseado em funções? Suponha que você tenha um grande banco com dezenas ou mesmo centenas de milhares de funcionários (entidades), cada um dos quais com dezenas de direitos de acesso a centenas de sistemas internos de informações bancárias (objetos). Agora multiplique o número de objetos pelo número de assuntos - este é o número mínimo de conexões que você precisa primeiro construir e depois controlar. É realmente possível fazer isso manualmente? Claro que não – funções foram criadas para resolver esse problema.
Uma função é um conjunto de permissões que um usuário ou grupo de usuários precisa para executar determinadas tarefas de trabalho. Cada funcionário pode ter uma ou mais funções, e cada função pode conter de uma a várias permissões que são permitidas ao usuário dentro dessa função. As funções podem estar vinculadas a cargos, departamentos ou tarefas funcionais específicas dos funcionários.
As funções geralmente são criadas a partir de autorizações individuais de funcionários em cada sistema de informação. Em seguida, as funções de negócios globais são formadas a partir das funções de cada sistema. Por exemplo, a função empresarial de “gerente de crédito” incluirá diversas funções separadas nos sistemas de informação usados no escritório de atendimento ao cliente do banco. Por exemplo, como o principal sistema bancário automatizado, módulo de caixa, sistema de gerenciamento eletrônico de documentos, gerenciador de serviços e outros. As funções empresariais, via de regra, estão vinculadas à estrutura organizacional – ou seja, ao conjunto de divisões da empresa e cargos nelas. É assim que uma matriz global de papéis é formada (dou um exemplo na tabela abaixo).
Vale ressaltar que é simplesmente impossível construir um modelo 100% exemplar, proporcionando todos os direitos necessários aos colaboradores de cada cargo em uma estrutura comercial. Sim, isso não é necessário. Afinal, um modelo não pode ser estático, porque depende de um ambiente em constante mudança. E de mudanças nas atividades empresariais da empresa, o que, consequentemente, afeta mudanças na estrutura e funcionalidade organizacional. E da falta de provisão integral de recursos, e do não cumprimento das descrições de cargos, e do desejo de lucro em detrimento da segurança, e de muitos outros fatores. Portanto, é necessário construir um modelo que possa cobrir até 80% das necessidades do usuário quanto aos direitos básicos necessários quando atribuído a um cargo. E podem, se necessário, solicitar os 20% restantes posteriormente em inscrições separadas.
Claro, você pode perguntar: “Não existem modelos 100% exemplares?” Pois bem, isso acontece, por exemplo, em estruturas sem fins lucrativos que não estão sujeitas a mudanças frequentes - em alguns institutos de pesquisa. Ou em organizações do complexo militar-industrial com alto nível de segurança, onde a segurança está em primeiro lugar. Acontece numa estrutura comercial, mas no âmbito de uma divisão separada, cujo trabalho é um processo bastante estático e previsível.
A principal vantagem da gestão baseada em funções é a simplificação da emissão de direitos, porque o número de funções é significativamente menor que o número de utilizadores do sistema de informação. E isso é verdade para qualquer setor.
Tomemos como exemplo uma empresa de varejo: ela emprega milhares de vendedores, mas eles têm o mesmo conjunto de direitos no sistema N e apenas uma função será criada para eles. Quando um novo vendedor chega à empresa, ele recebe automaticamente a função necessária no sistema, que já possui todas as autoridades necessárias. Além disso, com um clique você pode alterar os direitos de milhares de vendedores de uma só vez, por exemplo, adicionar uma nova opção para gerar um relatório. Não há necessidade de fazer mil operações, vinculando um novo direito a cada conta – basta adicionar esta opção à função, e ela aparecerá para todos os vendedores ao mesmo tempo.
Outra vantagem do gerenciamento baseado em funções é a eliminação da emissão de autorizações incompatíveis. Ou seja, um funcionário que exerce determinada função no sistema não pode exercer simultaneamente outra função, cujos direitos não devem ser combinados com os direitos da primeira. Um exemplo notável é a proibição de combinar as funções de entrada e controle de uma transação financeira.
Qualquer pessoa interessada em saber como surgiu o controle de acesso baseado em funções pode
mergulhe na história
Se olharmos para a história, a comunidade de TI pensou pela primeira vez em métodos de controle de acesso na década de 70 do século XX. Embora os aplicativos fossem bastante simples naquela época, assim como agora, todos queriam realmente gerenciar o acesso a eles de maneira conveniente. Conceda, altere e controle direitos de usuário - apenas para facilitar a compreensão do acesso de cada um deles. Mas naquela altura não existiam padrões comuns, os primeiros sistemas de controlo de acesso estavam a ser desenvolvidos e cada empresa baseava-se nas suas próprias ideias e regras.
Muitos modelos diferentes de controle de acesso são conhecidos agora, mas não apareceram imediatamente. Detenhamo-nos naqueles que deram um contributo significativo para o desenvolvimento desta área.
O primeiro e provavelmente o mais simples modelo é Controle de acesso discricionário (seletivo) (DAC – Controle de acesso discricionário). Este modelo implica a partilha de direitos por todos os participantes no processo de acesso. Cada usuário tem acesso a objetos ou operações específicas. Em essência, aqui o conjunto dos sujeitos de direitos corresponde ao conjunto dos objetos. Este modelo revelou-se demasiado flexível e difícil de manter: as listas de acesso acabam por se tornar enormes e difíceis de controlar.
O segundo modelo é Controle de acesso obrigatório (MAC - Controle de acesso obrigatório). De acordo com este modelo, cada usuário recebe acesso a um objeto de acordo com o acesso emitido a um determinado nível de confidencialidade dos dados. Assim, os objetos devem ser categorizados de acordo com o seu nível de confidencialidade. Ao contrário do primeiro modelo flexível, este, pelo contrário, revelou-se demasiado rígido e restritivo. A sua utilização não se justifica quando a empresa dispõe de muitos recursos de informação diferentes: para diferenciar o acesso aos diferentes recursos, será necessário introduzir muitas categorias que não se sobreponham.
Devido às imperfeições óbvias destes dois métodos, a comunidade de TI continuou a desenvolver modelos que são mais flexíveis e ao mesmo tempo mais ou menos universais para apoiar diferentes tipos de políticas organizacionais de controlo de acesso. E então apareceu o terceiro modelo de controle de acesso baseado em funções! Esta abordagem tem se mostrado a mais promissora porque requer não apenas a autorização da identidade do usuário, mas também de suas funções operacionais nos sistemas.
A primeira estrutura de modelo claramente descrita foi proposta pelos cientistas americanos David Ferrailo e Richard Kuhn, do Instituto Nacional de Padrões e Tecnologia dos EUA, em 1992. Então o termo apareceu pela primeira vez RBAC (controle de acesso baseado em função). Esses estudos e descrições dos principais componentes, bem como suas relações, formaram a base da norma INCITS 359-2012, que ainda hoje vigora, aprovada pelo Comitê Internacional de Padrões de Tecnologia da Informação (INCITS).
A norma define uma função como “uma função de trabalho no contexto de uma organização com alguma semântica associada em relação à autoridade e responsabilidade atribuída ao usuário atribuído à função”. O documento estabelece os elementos básicos do RBAC – usuários, sessões, funções, permissões, operações e objetos, bem como os relacionamentos e interconexões entre eles.
O padrão fornece a estrutura mínima necessária para a construção de um modelo – combinando direitos em funções e, em seguida, concedendo acesso aos usuários por meio dessas funções. São delineados os mecanismos de composição de papéis a partir de objetos e operações, descrita a hierarquia de papéis e herança de poderes. Afinal, em qualquer empresa existem funções que reúnem competências básicas necessárias a todos os colaboradores da empresa. Pode ser acesso a e-mail, EDMS, portal corporativo, etc. Essas permissões podem ser incluídas em uma função geral chamada “funcionário”, e não haverá necessidade de listar todos os direitos básicos repetidamente em cada uma das funções de nível superior. Basta simplesmente indicar a característica hereditária da função de “funcionário”.
Posteriormente, o padrão foi complementado com novos atributos de acesso relacionados ao ambiente em constante mudança. Foi adicionada a capacidade de introduzir restrições estáticas e dinâmicas. Os estáticos implicam na impossibilidade de combinação de funções (mesmo input e controle de operações mencionados acima). As restrições dinâmicas podem ser determinadas alterando parâmetros, por exemplo, tempo (horas ou dias úteis/não úteis), localização (escritório/casa), etc.
Separadamente, deve ser dito sobre controle de acesso baseado em atributos (ABAC - Controle de acesso baseado em atributos). A abordagem baseia-se na concessão de acesso usando regras de compartilhamento de atributos. Este modelo pode ser usado separadamente, mas muitas vezes complementa ativamente o modelo clássico: atributos de usuários, recursos e dispositivos, bem como tempo ou localização, podem ser adicionados a uma determinada função. Isto permite-lhe utilizar menos funções, introduzir restrições adicionais e tornar o acesso o mais mínimo possível, melhorando assim a segurança.
Por exemplo, um contador pode ter acesso a contas se trabalhar em uma determinada região. Em seguida, a localização do especialista será comparada com um determinado valor de referência. Ou você pode conceder acesso às contas somente se o usuário fizer login em um dispositivo incluído na lista de dispositivos permitidos. Um bom complemento para um modelo, mas raramente usado sozinho devido à necessidade de criar muitas regras e tabelas de permissões ou restrições.
Deixe-me dar um exemplo de uso do ABAC da minha “vida passada”. Nosso banco tinha várias agências. Os funcionários dos escritórios dos clientes dessas agências realizavam exatamente as mesmas operações, mas tinham que trabalhar no sistema principal apenas com contas de sua região. Primeiro, começamos a criar funções separadas para cada região - e havia tantas funções com funcionalidades repetidas, mas com acesso a contas diferentes! Então, ao usar um atributo de localização para o usuário e associá-lo a um intervalo específico de contas para revisão, reduzimos significativamente o número de funções no sistema. Com isso, permaneceram funções para apenas uma agência, que foram replicadas para os cargos correspondentes em todas as demais divisões territoriais do banco.
Agora vamos falar sobre as etapas preparatórias necessárias, sem as quais é simplesmente impossível construir um modelo funcional.
Passo 1. Crie um modelo funcional
Você deve começar criando um modelo funcional – um documento de nível superior que descreve detalhadamente a funcionalidade de cada departamento e cada posição. Como regra, as informações chegam a partir de vários documentos: descrições de cargos e regulamentos para unidades individuais - departamentos, divisões, departamentos. O modelo funcional deverá ser acordado com todos os departamentos interessados (negócio, controle interno, segurança) e aprovado pela direção da empresa. Para que serve este documento? Para que o modelo possa se referir a ele. Por exemplo, você vai construir um modelo baseado nos direitos existentes dos funcionários - descarregado do sistema e “reduzido a um denominador comum”. Então, ao concordar com o proprietário do sistema sobre as funções recebidas, você pode se referir a um ponto específico do modelo funcional, com base no qual este ou aquele direito está incluído na função.
Passo 2. Auditamos os sistemas de TI e elaboramos um plano de priorização
Na segunda etapa, você deve realizar uma auditoria nos sistemas de TI para entender como é organizado o acesso a eles. Por exemplo, minha empresa financeira operava centenas de sistemas de informação. Todos os sistemas tinham alguns rudimentos de gerenciamento baseado em funções, a maioria tinha algumas funções, mas principalmente no papel ou no diretório do sistema - eles estavam desatualizados há muito tempo e o acesso a eles era concedido com base nas solicitações reais dos usuários. Naturalmente, é simplesmente impossível construir um modelo em várias centenas de sistemas ao mesmo tempo; é preciso começar de algum lugar. Realizamos uma análise aprofundada do processo de controle de acesso para determinar seu nível de maturidade. Durante o processo de análise, foram desenvolvidos critérios para priorização de sistemas de informação – criticidade, prontidão, planos de descomissionamento, etc. Com a ajuda deles, alinhamos o desenvolvimento/atualização de modelos para esses sistemas. E então incluímos modelos no plano de integração com a solução de gerenciamento de identidade para automatizar o controle de acesso.
Então, como você determina a criticidade de um sistema? Responda a si mesmo às seguintes perguntas:
- O sistema está vinculado aos processos operacionais dos quais dependem as atividades principais da empresa?
- A interrupção do sistema afetará a integridade dos ativos da empresa?
- Qual é o tempo máximo de inatividade permitido do sistema, atingindo o qual é impossível restaurar a atividade após uma interrupção?
- Uma violação da integridade da informação no sistema pode levar a consequências irreversíveis, tanto financeiras como reputacionais?
- Criticidade para fraude. A presença de funcionalidades, se não for devidamente controlada, poderá levar a ações fraudulentas internas/externas;
- Quais são os requisitos legais e as regras e procedimentos internos para estes sistemas? Haverá multas dos reguladores por não conformidade?
Em nossa empresa financeira, conduzimos uma auditoria como esta. A Administração desenvolveu o procedimento de auditoria de Revisão de Direitos de Acesso para examinar primeiro os usuários e direitos existentes nos sistemas de informação que estavam na lista de prioridade mais alta. O departamento de segurança foi designado como proprietário deste processo. Mas para ter uma visão completa dos direitos de acesso na empresa, foi necessário envolver os departamentos de TI e de negócios no processo. E aqui começaram as disputas, os mal-entendidos e às vezes até a sabotagem: ninguém quer fugir das suas responsabilidades atuais e se envolver em algumas atividades, à primeira vista, incompreensíveis.
NB Grandes empresas com processos de TI desenvolvidos provavelmente estão familiarizadas com o procedimento de auditoria de TI - controles gerais de TI (ITGC), que permite identificar deficiências nos processos de TI e estabelecer controles para melhorar os processos de acordo com as melhores práticas (ITIL, COBIT, IT Governança, etc.) Tal auditoria permite que a TI e os negócios se entendam melhor e desenvolvam uma estratégia de desenvolvimento conjunta, analisem riscos, otimizem custos e desenvolvam abordagens de trabalho mais eficazes.
Uma das áreas da auditoria é determinar os parâmetros de acesso lógico e físico aos sistemas de informação. Tomamos os dados obtidos como base para uso posterior na construção de um modelo. Como resultado desta auditoria, tivemos um registo dos sistemas informáticos, no qual foram determinados os seus parâmetros técnicos e fornecidas as descrições. Além disso, para cada sistema foi identificado um proprietário da direção de negócio em cujos interesses ele operava: era ele o responsável pelos processos de negócio que este sistema servia. Foi também nomeado um gestor de serviços de TI, responsável pela implementação técnica das necessidades de negócio de um SI específico. Foram registados os sistemas mais críticos para a empresa e os seus parâmetros técnicos, prazos de comissionamento e descomissionamento, etc.. Estes parâmetros foram muito úteis no processo de preparação para a criação de um modelo.
Passo 3 Crie uma metodologia
A chave para o sucesso de qualquer negócio é o método certo. Portanto, tanto para construir um modelo quanto para realizar uma auditoria, precisamos criar uma metodologia na qual descrevamos a interação entre os departamentos, estabeleçamos responsabilidades nos regulamentos da empresa, etc.
Primeiro você precisa examinar todos os documentos disponíveis que estabelecem o procedimento para conceder acesso e direitos. No bom sentido, os processos devem ser documentados em vários níveis:
- requisitos corporativos gerais;
- requisitos para áreas de segurança da informação (dependendo das áreas de atuação da organização);
- requisitos para processos tecnológicos (instruções, matrizes de acesso, diretrizes, requisitos de configuração).
Na nossa financeira encontramos muitos documentos desatualizados, tivemos que adequá-los aos novos processos que estavam sendo implementados.
Por despacho da administração, foi criado um grupo de trabalho que incluía representantes das áreas de segurança, informática, negócio e controlo interno. O despacho delineou os objetivos de criação do grupo, a direção da atividade, o período de existência e os responsáveis de cada lado. Além disso, desenvolvemos uma metodologia de auditoria e um procedimento para construção de um modelo: foram pactuados por todos os representantes responsáveis das áreas e aprovados pela administração da empresa.
Documentos que descrevem o procedimento de execução dos trabalhos, prazos, responsabilidades, etc. - uma garantia de que no caminho para o objetivo almejado, que a princípio não é óbvio para todos, ninguém terá dúvidas “por que estamos fazendo isso, por que precisamos disso, etc.” e não haverá oportunidade de “saltar” ou retardar o processo.
Passo 4. Corrija os parâmetros do modelo de controle de acesso existente
Estamos a elaborar um chamado “passaporte de sistema” em termos de controlo de acessos. Em essência, trata-se de um questionário sobre um sistema de informação específico, que registra todos os algoritmos de controle de acesso a ele. As empresas que já implementaram soluções de classe IdM provavelmente estão familiarizadas com esse questionário, pois é aqui que começa o estudo dos sistemas.
Alguns parâmetros sobre o sistema e os proprietários foram incluídos no questionário a partir do registro de TI (ver etapa 2, auditoria), mas novos também foram adicionados:
- como as contas são gerenciadas (diretamente no banco de dados ou através de interfaces de software);
- como os usuários fazem login no sistema (usando uma conta separada ou usando uma conta AD, LDAP, etc.);
- quais níveis de acesso ao sistema são usados (nível de aplicativo, nível de sistema, uso de recursos de arquivos de rede pelo sistema);
- descrição e parâmetros dos servidores nos quais o sistema roda;
- quais operações de gerenciamento de contas são suportadas (bloqueio, renomeação, etc.);
- quais algoritmos ou regras são usados para gerar o identificador de usuário do sistema;
- qual atributo pode ser usado para estabelecer uma conexão com o registro de um funcionário no sistema de pessoal (nome completo, número pessoal, etc.);
- todos os atributos possíveis da conta e regras para seu preenchimento;
- quais direitos de acesso existem no sistema (funções, grupos, direitos atômicos, etc., existem direitos aninhados ou hierárquicos);
- mecanismos de divisão de direitos de acesso (por cargo, departamento, funcionalidade, etc.);
- O sistema possui regras de segregação de direitos (SOD – Segregation of Duties) e como funcionam;
- como são processados no sistema os eventos de ausência, transferência, desligamento, atualização de dados de funcionários, etc.
Esta lista pode ser continuada detalhando os diversos parâmetros e outros objetos que estão envolvidos no processo de controle de acesso.
Etapa 5. Crie uma descrição de permissões voltada para os negócios
Outro documento que precisaremos ao construir um modelo é um livro de referência sobre todos os possíveis poderes (direitos) que podem ser concedidos aos usuários no sistema de informação, com uma descrição detalhada da função de negócio que está por trás dele. Freqüentemente, as autoridades do sistema são criptografadas com determinados nomes compostos por letras e números, e os funcionários das empresas não conseguem descobrir o que está por trás desses símbolos. Aí eles vão para o serviço de informática, e lá... também não conseguem responder a pergunta, por exemplo, sobre direitos raramente utilizados. Em seguida, testes adicionais devem ser feitos.
É bom que já exista uma descrição do negócio ou mesmo que haja uma combinação desses direitos em grupos e funções. Para alguns aplicativos, a prática recomendada é criar essa referência no estágio de desenvolvimento. Mas isso não acontece com frequência, então voltamos ao departamento de TI para coletar informações sobre todos os direitos possíveis e descrevê-los. Nosso guia conterá, em última análise, o seguinte:
- nome da autoridade, incluindo o objeto ao qual se aplica o direito de acesso;
- uma ação que pode ser realizada com um objeto (visualização, alteração, etc., possibilidade de restrição, por exemplo, por base territorial ou por grupo de clientes);
- código de autorização (código e nome da função/solicitação do sistema que pode ser executada utilizando a autorização);
- descrição da autoridade (descrição detalhada das ações no SI na aplicação da autoridade e suas consequências para o processo;
- status da permissão: “Ativo” (se a permissão for atribuída a pelo menos um usuário) ou “Não ativo” (se a permissão não for usada).
Passo 6 Baixamos dados sobre usuários e direitos dos sistemas e os comparamos com a fonte de pessoal
Na fase final de preparação, é necessário baixar os dados dos sistemas de informação sobre todos os usuários e os direitos que eles possuem atualmente. Existem dois cenários possíveis aqui. Primeiro: o departamento de segurança tem acesso direto ao sistema e dispõe de meios para baixar relatórios relevantes, o que não acontece com frequência, mas é muito conveniente. Segundo: enviamos uma solicitação à TI para receber relatórios no formato exigido. A experiência mostra que não é possível chegar a um acordo com a TI e obter os dados necessários na primeira vez. É necessário fazer diversas abordagens até que a informação seja recebida na forma e formato desejados.
Quais dados precisam ser baixados:
- Nome da conta
- Nome completo do funcionário a quem está atribuído
- Status (ativo ou bloqueado)
- Data de criação da conta
- Data da última utilização
- Lista de direitos/grupos/funções disponíveis
Assim, recebemos downloads do sistema com todos os usuários e todos os direitos que lhes foram concedidos. E imediatamente deixaram de lado todas as contas bloqueadas, já que o trabalho de construção de um modelo será realizado apenas para usuários ativos.
Então, se a sua empresa não possui meios automatizados de bloqueio de acesso aos funcionários demitidos (isso acontece com frequência) ou possui automação patchwork que nem sempre funciona corretamente, é necessário identificar todas as “almas mortas”. Estamos falando de contas de funcionários já demitidos, cujos direitos não estão bloqueados por algum motivo - precisam ser bloqueados. Para fazer isso, comparamos os dados carregados com a fonte de pessoal. A descarga de pessoal também deve ser obtida antecipadamente no departamento que mantém o banco de dados de pessoal.
Separadamente, é necessário separar contas cujos proprietários não foram encontrados no banco de dados de pessoal, não atribuídos a ninguém - ou seja, sem proprietário. Utilizando esta lista, precisaremos da data da última utilização: se for bastante recente, ainda teremos que procurar os proprietários. Isso pode incluir contas de prestadores de serviços externos ou contas de serviços que não são atribuídas a ninguém, mas estão associadas a quaisquer processos. Para saber a quem pertencem as contas, você pode enviar cartas a todos os departamentos solicitando que respondam. Quando os proprietários são encontrados, inserimos os dados sobre eles no sistema: desta forma, todas as contas ativas são identificadas e as demais são bloqueadas.
Assim que nossos uploads forem limpos de registros desnecessários e apenas as contas ativas permanecerem, poderemos começar a construir um modelo para um sistema de informação específico. Mas vou falar sobre isso no próximo artigo.
Autor: Lyudmila Sevastyanova, gerente de promoção Solar inRights
Fonte: habr.com