🥇Construindo um modelo de gerenciamento de acesso. Parte um, preparatória

Atualmente, trabalho em uma empresa fornecedora de software, especificamente em soluções de gestão de acesso. Minha experiência anterior está do 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 tinha grandes competências em IdM. Aprendemos muito no processo, tivemos que enfrentar muitos desafios para estabelecer um mecanismo funcional de gestão dos direitos dos usuários nos sistemas de informação da empresa.

Unindo minha experiência adquirida do lado do cliente com o conhecimento e competências de fornecedor, quero compartilhar com você, na verdade, um guia passo a passo: como criar em uma grande empresa um modelo de gestão de acesso baseado em funções, e o que isso vai proporcionar no final. Meu guia é dividido em duas partes: a primeira – preparando-se para construir o modelo, a segunda – realmente construindo. Aqui está a primeira parte, a preparatória.

N.B. Construir um modelo baseado em funções – infelizmente, não é um resultado, mas sim um processo. Ou mais precisamente, é parte do processo de criação de um ecossistema de gestão de acesso na empresa. Portanto, prepare-se para um jogo de longo prazo.

Primeiro, vamos definir – o que é gestão de acesso baseada em funções? Suponha que você tenha um grande banco com dezenas ou até centenas de milhares de funcionários (sujeitos), cada um dos quais possui dezenas de direitos de acesso em centenas de sistemas de informação internos (objetos). Agora multiplique o número de objetos pelo número de sujeitos – é esse número mínimo de relações que você precisa construir e depois controlar. É realmente possível fazer isso manualmente? Claro que não – é para isso que surgiram as funções.

A função é um conjunto de permissões necessárias para um usuário ou grupo de usuários realizar determinadas tarefas de trabalho. Cada funcionário pode ter uma ou várias funções, e cada função pode conter de uma a várias permissões que são permitidas ao usuário dentro desse escopo. As funções podem estar vinculadas a cargos específicos, departamentos ou tarefas funcionais dos trabalhadores.

Os papéis são geralmente criados a partir das permissões individuais de cada funcionário em cada sistema de informação. Depois, os papéis de cada sistema formam papéis de negócios globais. Por exemplo, o papel de negócio "gerente de crédito" incluirá vários papéis individuais em sistemas de informação usados no escritório do cliente do banco. Digamos que em sistemas como o principal sistema bancário automatizado, módulo de caixa, sistema de gerenciamento de documentos eletrônicos, gerente de serviços e outros. Os papéis de negócios, em geral, estão ligados à estrutura organizacional – em termos simples, ao conjunto de departamentos da empresa e aos cargos neles. Assim, forma-se a matriz de papéis global (um exemplo é mostrado na tabela abaixo).

Vale ressaltar que construir um modelo de papéis 100% que garanta todos os direitos necessários para cada cargo em uma estrutura comercial é simplesmente impossível. E isso nem é necessário. Afinal, o modelo de papéis não pode ser estático, pois depende de um ambiente em constante mudança. E da alteração nas atividades empresariais da empresa, que, por sua vez, afeta a mudança na estrutura organizacional e nas funções. Além da falta de recursos completos, do não cumprimento das instruções de trabalho, da busca por lucro em detrimento da segurança e de muitos outros fatores. Portanto, é necessário construir um modelo de papéis que possa atender até 80% das necessidades dos usuários em direitos básicos necessários ao assumir um cargo. Os outros 20% poderão ser solicitados posteriormente, se necessário, por meio de pedidos separados.

Claro, você pode perguntar: "E quanto a modelos de papéis 100%? Eles não existem?" Bem, sim, isso ocorre, por exemplo, em estruturas sem fins lucrativos que não são sujeitas a mudanças frequentes, como um instituto de pesquisa. Ou em organizações de defesa com alto nível de proteção, onde a segurança é a prioridade. Acontece também em estruturas comerciais, mas dentro de um único departamento, cuja operação é um processo bastante estático e previsível.

A principal vantagem da gestão de papéis é a simplificação na concessão de direitos, uma vez que o número de papéis é significativamente menor que o número de usuários do sistema de informação. E isso é válido para qualquer setor.

Vamos considerar uma empresa de varejo: nela trabalham milhares de vendedores, mas o conjunto de permissões no sistema N é o mesmo para todos, e para eles será criada apenas uma função. Quando um novo vendedor chega à empresa, a função necessária no sistema é automaticamente atribuída a ele, que já possui todas as permissões necessárias. Da mesma forma, é possível alterar as permissões de mil vendedores de uma só vez, por exemplo, adicionando uma nova opção para geração de relatórios. Não é necessário realizar mil operações, vinculando a nova permissão a cada conta – basta inserir essa opção na função, e ela aparecerá para todos os vendedores ao mesmo tempo.

Outra vantagem da gestão baseada em funções é a exclusão da concessão de permissões incompatíveis. Ou seja, um funcionário que possui uma determinada função no sistema não pode ao mesmo tempo ter outra função cujas permissões não devem se combinar com as da primeira. Um exemplo claro é a proibição da combinação das funções de entrada e controle de operações financeiras.

Todos que estão interessados em como surgiu a gestão de acesso baseada em funções podem
mergulhar em uma excursão pela história
Se olharmos para a história, o setor de TI começou a pensar sobre métodos de gestão de acesso ainda na década de 70 do século XX. Embora os aplicativos fossem bastante simples na época, assim como hoje, todos queriam gerenciar o acesso a eles de maneira conveniente. Conceder, alterar e controlar os direitos dos usuários – simplesmente para facilitar o entendimento de qual acesso cada um deles possui. Mas naquela época não existiam padrões gerais, desenvolviam-se os primeiros sistemas de gestão de acesso, e cada empresa baseava-se em suas próprias ideias e regras.

Hoje, já se conhece muitos modelos diferentes de gestão de acesso, mas eles não surgiram de imediato. Vamos nos concentrar naqueles que trouxeram uma contribuição significativa para o desenvolvimento dessa área.

O primeiro e, provavelmente, o mais simples modelo – Gestão de acesso discrecionária (ou seletiva) (DAC – Controle de acesso discricionário). Este modelo implica o compartilhamento de direitos por todos os participantes do processo de acesso. Cada usuário obtém acesso a objetos ou operações específicas. Essencialmente, aqui, muitos sujeitos de direitos correspondem a muitos objetos. Este modelo foi considerado muito flexível e complicado para manutenção: as listas de acesso tornam-se enormes e difíceis de controlar ao longo do tempo.

O segundo modelo é Controle de acesso mandatório (MAC — Mandatory access control). Neste modelo, cada usuário obtém acesso a um objeto de acordo com a autorização para um determinado nível de confidencialidade dos dados. Consequentemente, os objetos devem ser categorizados de acordo com o nível de confidencialidade. Ao contrário do primeiro modelo flexível, este se mostrou muito rígido e restritivo. Sua aplicação não se justifica quando a empresa possui uma variedade de recursos informacionais: para diferenciar o acesso a diferentes recursos, será necessário introduzir várias categorias que não se sobreponham.

Dada a óbvia imperfeição desses dois métodos, a comunidade de TI continuou a desenvolver modelos que fossem mais flexíveis e, ao mesmo tempo, mais ou menos universais para suportar diferentes tipos de políticas organizacionais de controle de acesso. E foi então que surgiu o terceiro modelo de controle de acesso baseado em funções! Esta abordagem se mostrou a mais promissora, pois requer não apenas a autorização da identidade do usuário, mas também suas funções de trabalho nos sistemas.

A primeira estrutura de modelo de função claramente descrita foi proposta pelos pesquisadores americanos David Ferraiolo e Richard Kuhn do Instituto Nacional de Padrões e Tecnologia dos EUA em 1992. Foi então que o termo RBAC (Controle de Acesso Baseado em Função) foi introduzido. Essas pesquisas e descrições dos componentes básicos, bem como suas inter-relações, formaram a base do padrão INCITS 359-2012, que ainda está em vigor, aprovado pelo Comitê Internacional de Padrões de Tecnologia da Informação (INCITS).

O padrão define o papel como "uma função dentro do contexto da organização com alguma semântica relacionada aos poderes e responsabilidades atribuídos ao usuário designado para o papel". O documento estabelece os principais elementos do RBAC – usuários, sessões, papéis, permissões, operações e objetos, bem como as relações e inter-relações entre eles.

O padrão fornece a estrutura mínima necessária para a construção de um modelo de papel – a combinação de permissões em papéis e, em seguida, a concessão de acesso aos usuários por meio desses papéis. Os mecanismos para formar papéis a partir de objetos e operações são destacados, e a hierarquia de papéis e herança de poderes são descritas. Afinal, em qualquer empresa existem papéis que combinam permissões elementares necessárias para todos os funcionários. Isso pode incluir acesso ao e-mail, ao SED, ao portal corporativo etc. Essas permissões podem ser incluídas em um único papel geral chamado "funcionário", eliminando a necessidade de listar repetidamente todos os direitos elementares em cada um dos papéis de nível superior. Basta indicar a característica de herança do papel "funcionário".

Posteriormente, o padrão foi complementado com novos atributos de acesso relacionados ao ambiente em constante mudança. Foram introduzidas possibilidades de restrições estáticas e dinâmicas. As estáticas implicam na impossibilidade de sobreposição de papéis (aquele mesmo controle e introdução de operações mencionado anteriormente). As restrições dinâmicas podem ser determinadas por parâmetros variáveis, como tempo (horas/dias úteis ou não úteis), localização (escritório/casa), etc.

Vale mencionar especificamente sobre o controle de acesso baseado em atributos (ABAC — Attribute-based access control). Essa abordagem é baseada na concessão de acesso por meio de regras que compartilham atributos. Este modelo pode ser usado de forma independente, mas muitas vezes complementa ativamente o modelo clássico baseado em papéis: a atributos de usuários, recursos e dispositivos, assim como de tempo ou localização podem ser adicionados a um papel específico. Isso permite usar menos papéis, introduzir restrições adicionais e tornar o acesso minimamente suficiente, aumentando assim a segurança.

Por exemplo, um contador pode ter acesso às contas se ele trabalhar em uma determinada região. Assim, a localização do especialista será comparada a um valor de referência específico. Ou pode-se conceder acesso às contas apenas se o usuário se autenticar a partir de um dispositivo registrado como permitido. É um bom complemento para o modelo de papéis, mas não é frequentemente utilizado sozinho devido à necessidade de criar muitas regras e tabelas de permissões ou restrições.

Vou dar um exemplo da aplicação de ABAC da minha "vida passada". Em nosso banco havia várias agências. Os funcionários dos escritórios de atendimento ao cliente nessas agências realizavam operações absolutamente idênticas, mas deveriam trabalhar no sistema principal apenas com contas de sua região. Primeiro, começamos a criar papéis separados para cada região – e acabamos com muitos papéis repetitivos, mas com acesso a diferentes contas! Então, ao utilizar o atributo de localização do usuário e vinculá-lo a um intervalo específico de contas para verificação, reduzimos significativamente o número de papéis no sistema. Como resultado, ficaram papéis apenas para uma agência, que foram replicados para os cargos correspondentes em todas as outras unidades territoriais do banco.

E agora vamos falar sobre os passos preparatórios necessários, sem os quais simplesmente não é possível construir um modelo de papéis funcional.

Passo 1. Criamos o modelo funcional

O primeiro passo é criar um modelo funcional - um documento de alto nível que descreve em detalhes a funcionalidade de cada departamento e de cada cargo. Geralmente, as informações são coletadas a partir de diversos documentos: descrições de cargos e regulamentos de departamentos específicos - seções, gerências e departamentos. O modelo funcional deve ser aprovado por todos os departamentos envolvidos (negócios, controle interno, segurança) e ratificado pela liderança da empresa. Para que serve este documento? Para que o modelo de papéis possa referenciá-lo. Por exemplo, você pretende construir um modelo de papéis com base nos direitos já existentes dos funcionários - extraídos do sistema e 'padronizados'. Assim, ao validar os papéis obtidos com o proprietário do sistema de negócios, pode-se referir a um item específico do modelo funcional que justifique a inclusão de determinado direito no papel.

Passo 2. Auditamos os sistemas de TI e elaboramos um plano de priorização

No segundo estágio, é necessário auditar os sistemas de TI para entender como o acesso é organizado. Por exemplo, na minha empresa financeira, existiam várias centenas de sistemas de informação. Em todos os sistemas havia alguns indícios de gerenciamento de papéis, na maioria das vezes - algumas funções, mas principalmente no papel ou no catálogo do sistema - estavam obsoletas, e o acesso a esses sistemas era concedido com base em solicitações reais de usuários. Naturalmente, é simplesmente impossível construir um modelo de papéis em várias centenas de sistemas de uma só vez; é preciso começar de algum lugar. Fizemos uma análise aprofundada do processo de gestão de acesso para determinar o nível de sua maturidade. No decorrer da análise, desenvolvemos critérios para priorização dos sistemas de informação - criticidade, prontidão, planos de desativação, etc. Com isso, organizamos a sequência para o desenvolvimento/atualização dos modelos de papéis para esses sistemas. E, em seguida, incluímos os modelos de papéis no plano de integração com a solução de Gestão de Identidade, para automatizar o gerenciamento de acesso.

Então, como determinar a criticidade do sistema? Responda as seguintes perguntas:

O sistema está relacionado a processos operacionais cuja execução depende da atividade principal da empresa?
A interrupção do funcionamento do sistema afetará a integridade dos ativos da empresa?
Qual é o tempo máximo de inatividade do sistema, após o qual não é possível restaurar as operações?
Uma violação da integridade da informação no sistema pode levar a consequências irreversíveis, tanto financeiras quanto reputacionais?
Crítica em relação a fraudes. A presença de funcionalidades que, sem controle adequado, podem permitir ações fraudulentas internas/externas;
Quais são os requisitos legais, assim como as regras e procedimentos internos para esses sistemas? Haverá multas por parte dos reguladores em caso de não conformidade?

Em nossa empresa financeira, realizamos uma auditoria dessa forma. A direção elaborou um procedimento de auditoria de Revisão de Direitos de Acesso, para entender os usuários existentes e seus direitos, começando pelos sistemas de informações que estavam na lista de prioridades. O departamento de segurança foi designado como proprietário desse processo. Mas, para obter uma visão completa dos direitos de acesso na empresa, foi necessário envolver os departamentos de TI e negócios no processo. E foi aqui que começaram as disputas, desentendimentos e, às vezes, até mesmo sabotagens: ninguém quer se desviar de suas responsabilidades atuais e se envolver em atividades que, à primeira vista, parecem incompreensíveis.

N.B. Grandes empresas com processos de TI desenvolvidos certamente estão familiarizadas com o procedimento de auditoria de TI - controles gerais de TI (ITGC), que permite identificar falhas nos processos de TI e aprimorar o controle para melhorar os processos de acordo com as melhores práticas (ITIL, COBIT, Governança de TI, etc.). Tal auditoria permite que TI e negócios se compreendam melhor e desenvolvam uma estratégia de desenvolvimento conjunta, analisem riscos, otimizem custos e desenvolvam abordagens de trabalho mais eficazes.

Uma das direções da auditoria é a definição dos parâmetros de acesso lógico e físico aos sistemas de informação. Os dados coletados foram utilizados como base para o uso futuro na construção do modelo de funções. Como resultado dessa auditoria, temos um registro dos sistemas de TI, no qual foram definidos seus parâmetros técnicos e fornecidas descrições. Além disso, para cada sistema foi designado um proprietário da área de negócios, cujos interesses eram atendidos pela sistema: ele era o responsável pelos processos empresariais que este sistema suportava. Também foi nomeado um gerente do serviço de TI, responsável pela implementação técnica das necessidades de negócios em um sistema específico. Os sistemas mais críticos para a empresa e seus parâmetros técnicos foram registrados, assim como os prazos de entrada e saída de operação, entre outros. Esses parâmetros foram muito úteis no processo de preparação para a construção do modelo de funções.

Passo 3 Criamos uma metodologia

A chave para o sucesso de qualquer empreendimento é o método corretamente escolhido. Portanto, tanto para a construção do modelo de funções quanto para a realização da auditoria, precisamos criar uma metodologia na qual descreveremos a interação entre os departamentos, consolidaremos a responsabilidade nos regulamentos da empresa, etc.
Para começar, é necessário investigar todos os documentos existentes que estabelecem a ordem de fornecimento de acesso e direitos. Idealmente, os processos devem ser documentados em vários níveis:

requisitos corporativos gerais;
requisitos para áreas de segurança da informação (dependem das direções de atividade da organização);
requisitos para os processos tecnológicos (instruções, matrizes de acesso, diretrizes metodológicas, requisitos para configurações).

Em nossa empresa financeira, encontramos muitos documentos obsoletos - foi necessário atualizá-los de acordo com os novos processos sendo implementados.

Por ordem da administração, foi criada um grupo de trabalho, do qual fazem parte representantes das áreas de segurança, TI, negócios e controle interno. Na ordem do dia, foram definidos os objetivos da criação do grupo, a direção das atividades, o prazo de existência e os responsáveis de cada parte. Além disso, desenvolvemos uma metodologia para a realização de auditorias e a construção de um modelo de papéis: foram aprovados por todos os representantes responsáveis das áreas e ratificados pela diretoria da empresa.

Documentos que descrevem o processo de trabalho, prazos, responsabilidades, etc. são a garantia de que, no caminho para o objetivo desejado, que inicialmente não é claro para todos, não surgirão questionamentos como "para que fazemos isso, por que precisamos disso, etc." e não haverá oportunidade de "desviar" ou desacelerar o processo.

Passo 4. Registramos os parâmetros do modelo atual de controle de acesso

Elaboramos o chamado 'passaporte do sistema' no que diz respeito ao controle de acesso. Essencialmente, é um questionário sobre um sistema de informação específico, onde estão registrados todos os algoritmos de controle de acesso a ele. As empresas que já implementaram soluções do tipo IdM seguramente estão familiarizadas com esse questionário, pois é com ele que começa a investigação dos sistemas.

Parte dos parâmetros sobre o sistema e os proprietários foi transferida para o questionário a partir do registro de TI (ver passo 2, auditoria), mas novos também foram adicionados:

como é feito o gerenciamento das contas (diretamente no BD ou através de interfaces de programação);
como os usuários realizam o login no sistema (com uma conta separada ou usando contas AD, LDAP ou outras);
quais níveis de acesso ao sistema são utilizados (nível de aplicativo, nível de sistema, uso de recursos de arquivos de rede pelo sistema);
descrição e parâmetros servidores, nos quais o sistema opera;
quais operações de gerenciamento de contas são suportadas (bloqueio, renomeação etc.);
quais algoritmos ou regras são usados para formar o identificador do usuário do sistema;
qual atributo pode estabelecer a conexão com o registro do funcionário no sistema de folha de pagamento (nome, número de registro ou outro);
todos os possíveis atributos da conta e as regras de preenchimento;
quais direitos de acesso existem no sistema (papéis, grupos, direitos atômicos etc., se existem direitos aninhados ou hierárquicos);
mecanismos de separação de direitos de acesso (por cargos, departamentos, funcionalidades, etc.);
existem regras de segregação de deveres (SOD) no sistema, e como elas funcionam;
como os eventos de ausência, transferência, demissão, atualização de dados sobre funcionários, etc., são tratados no sistema.

Pode-se continuar essa lista com detalhamentos de vários parâmetros e outros objetos que estão envolvidos no processo de gestão de acesso.

Passo 5. Criamos uma descrição orientada aos negócios das autorizações

Outro documento que precisamos ao construir o modelo de papéis é um guia sobre todas as possíveis autorizações (direitos) que podem ser concedidas aos usuários no sistema de informação, com uma descrição detalhada da função empresarial subjacente. Muitas vezes, as autorizações no sistema estão codificadas em determinados nomes, consistindo em letras e números, e os funcionários da empresa não conseguem entender o que está por trás desses símbolos. Então, eles vão ao departamento de TI, e lá... também não conseguem responder a perguntas, por exemplo, sobre direitos raramente utilizados. Isso leva à necessidade de realizar testes adicionais.

É bom se a descrição empresarial já existir ou mesmo houver a agregação desses direitos em grupos e funções. Para alguns aplicativos, é uma boa prática criar um guia como este já na fase de desenvolvimento. No entanto, isso não é comum, então novamente vamos ao departamento de TI para coletar informações sobre todos os direitos possíveis e descrevê-los. Nosso guia acabará contendo o seguinte:

nome da autorização, incluindo o objeto ao qual o direito de acesso se aplica;
ação que é permitida fazer com o objeto (visualização, alteração, etc., com a possibilidade de restrição, por exemplo, por critérios territoriais ou por grupo de clientes);
código da autorização (código e nome da função/requisição do sistema que podem ser executadas usando a autorização);
descrição da autorização (descrição detalhada das ações no SI ao aplicar a autorização e suas consequências para o processo;
status da autorização: "Ativo" (se a autorização foi atribuída a pelo menos um usuário) ou "Inativo" (se a autorização não está em uso).

Passo 6 Exportamos dos sistemas os dados sobre usuários e direitos e os comparamos com a fonte de recursos humanos

Na fase final de preparação, é necessário extrair dados dos sistemas de informação sobre todos os usuários e direitos que eles possuem atualmente. Aqui, existem dois cenários possíveis. Primeiro: o setor de segurança tem acesso direto ao sistema e possui meios para extrair relatórios correspondentes, o que acontece raramente, mas é muito conveniente. Segundo: enviamos um pedido para a TI para obter os relatórios no formato necessário. A prática mostra que negociar com a TI e obter os dados necessários na primeira tentativa é difícil. É preciso fazer várias abordagens até que a informação seja obtida na forma e no formato desejados.

Quais dados precisam ser extraídos:

Nome da conta
Nome completo do funcionário ao qual está vinculada
Status (ativa ou bloqueada)
Data de criação da conta
Data do último uso
Lista de direitos/grupos/papéis disponíveis

Assim, recebemos as extrações do sistema com todos os usuários e todos os direitos que lhes foram concedidos. E imediatamente descartamos todas as contas bloqueadas, pois o trabalho na construção do modelo de papel será realizado apenas com usuários ativos.

Em seguida, se a sua empresa não possui meios automatizados para revogar o acesso de funcionários demitidos (o que é comum), ou se há uma automação fragmentada que nem sempre funciona corretamente, é necessário identificar todas as "almas mortas". Refere-se às contas de funcionários já demitidos, cujos direitos não foram bloqueados por algum motivo – elas precisam ser bloqueadas. Para isso, comparamos os dados extraídos com a fonte de pessoal. A extração de pessoal também precisa ser previamente obtida do departamento que gerencia o banco de dados de pessoal.

É preciso separar as contas cujos proprietários não foram encontrados na base de dados de funcionários, ou seja, contas órfãs. Para essa lista, precisamos da data da última utilização: se for recente, ainda teremos que procurar pelos proprietários. Isso pode incluir contas de contratados externos ou contas de serviço que não estão atribuídas a ninguém, mas que estão relacionadas a algum processo. Para esclarecer a propriedade das contas, podemos enviar e-mails para todos os departamentos solicitando respostas. Assim que os proprietários forem encontrados, inserimos os dados deles no sistema: assim, todas as contas ativas são identificadas, e as demais são bloqueadas.

Assim que nossas exportações forem limpas de registros desnecessários e restarem apenas contas ativas, podemos começar a construir o modelo de papéis para um sistema de informação específico. Mas sobre isso falarei no próximo artigo.

Autor: Lyudmila Sevastyanova, gerente de marketing da Solar inRights

Fonte: habr.com