Criamos um modelo de controle de acesso baseado em função. Parte um, preparatória

Agora, trabalho para um fornecedor de software, em particular para soluções de controle de acesso. E minha experiência de “vidas passadas” 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 no IdM. Aprendemos muito no processo, tivemos que preencher vários obstáculos para criar um mecanismo de trabalho para gerenciar os direitos do usuário nos sistemas de informação da empresa.



Tendo combinado minha experiência adquirida no cliente com o conhecimento e as competências do fornecedor, quero compartilhar com você instruções essencialmente passo a passo: como criar um modelo de controle de acesso baseado em funções em uma grande empresa e o que isso dará no final. Minha instrução consiste em duas partes: primeiro - estamos nos preparando para construir um modelo, segundo - estamos realmente construindo. Aqui está a primeira parte, preparatória.



NB: Construir um modelo não é, infelizmente, um resultado, mas um processo. Ou melhor, mesmo parte do processo de criação de um ecossistema de controle de acesso na empresa. Então, sintonize a longo prazo.



Primeiro, vamos definir - o que é controle de acesso baseado em função? Suponha que você tenha um grande banco com dezenas ou mesmo centenas de milhares de funcionários (sujeitos), cada um 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 - esse é o número mínimo de conexões que você precisa primeiro construir e depois controlar. É realista fazer isso manualmente? É claro que não - os papéis pareciam 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 a um usuário nessa função. As funções podem ser vinculadas a posições, departamentos ou tarefas funcionais específicas dos funcionários.







As funções geralmente são criadas a partir de autorizações de funcionários individuais 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, uma função comercial de gerente de crédito incluiria várias funções distintas nos sistemas de informação que são usados ​​no escritório do cliente de um banco. Por exemplo, como o principal sistema bancário automatizado, módulo de caixa, sistema de gerenciamento eletrônico de documentos, gerente de serviços e outros. As funções de negócios, em regra, estão ligadas à estrutura organizacional e de equipe - em outras palavras, ao conjunto de departamentos e posições da empresa neles. É assim que a matriz global de papéis é formada (dou um exemplo na tabela abaixo).







Vale ressaltar que é simplesmente impossível construir um modelo 100%, fornecendo todos os direitos necessários aos funcionários de cada cargo em uma estrutura comercial. Sim, não é necessário. Afinal, um modelo não pode ser estático, porque depende de um ambiente em constante mudança. E da mudança nas atividades de negócios da empresa, que, consequentemente, afeta a mudança na estrutura organizacional e na funcionalidade. E pela falta de provisão total de recursos, e pelo não cumprimento das descrições de cargos, e pelo desejo de obter lucro em detrimento da segurança e de muitos outros fatores. Portanto, é necessário criar um modelo que atenda até 80% das necessidades dos usuários quanto aos direitos básicos necessários quando eles forem nomeados para um cargo. E eles poderão, se necessário, solicitar os 20% restantes posteriormente em solicitações separadas.



Obviamente, você pode perguntar: "O que, não existem modelos 100%?" Bem, por que 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 militares-industriais complexas com um alto nível de segurança, onde a segurança vem em primeiro lugar. Isso também acontece em uma estrutura comercial, mas dentro da estrutura de uma unidade separada, cujo trabalho é um processo razoavelmente estático e previsível.



A principal vantagem do gerenciamento de funções é a simplificação da concessão de direitos, porque o número de funções é significativamente menor que o dos usuários do sistema de informação. E isso é verdade para qualquer setor.



Pegue 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. Um novo vendedor chegou à empresa - ele recebeu automaticamente a função necessária no sistema, que já possui todos os poderes necessários. Você também pode alterar os direitos de milhares de vendedores em um clique, por exemplo, adicionar uma nova opção para gerar um relatório. Você não precisa fazer mil operações, vinculando um novo direito a cada conta - basta adicionar essa opção à função, que aparecerá para todos os vendedores ao mesmo tempo.



Outra vantagem do gerenciamento baseado em funções é a eliminação da emissão de poderes incompatíveis. Ou seja, um funcionário que tem uma certa função no sistema não pode ter simultaneamente outra função, cujos direitos não devem ser combinados com os direitos do primeiro. Um exemplo impressionante é a proibição de combinar as funções de entrada e controle de uma transação financeira.



Qualquer pessoa interessada em como surgiu o controle de acesso baseado em funções pode
mergulhar na história
, - 70- XX . , , , . , – , . , , .



, . , .



, , – () (DAC – Discretionary access control). . . . : .



(MAC — Mandatory access control). . . , , , . , : , , .



- , - . ! , , .



1992 . RBAC (Role-based access control). , INCITS 359-2012, (INCITS).



« , , ». RBAC – , , , , , .



– . , . , , . , , .. «», . «».







, . . ( , ). , , (/ ), (/) ..



(ABAC — Attribute-based access control). . , : , , . , , , , .



, , . . , , . , - .



ABAC « ». . , . – , ! , , . , .



Agora vamos falar sobre as etapas preparatórias necessárias, sem as quais é simplesmente impossível construir um modelo de trabalho.



Etapa 1. Crie um modelo funcional



Vale a pena começar com a criação de um modelo funcional - um documento de nível superior que descreve em detalhes a funcionalidade de cada departamento e cada posição. Como regra, as informações são obtidas de vários documentos: descrições de cargo e regulamentos para divisões individuais - departamentos, departamentos, departamentos. O modelo funcional deve ser acordado com todos os departamentos interessados ​​(negócios, controle interno, segurança) e aprovado pela gerência da empresa. Para que serve este documento? Para que o modelo possa se referir a ele. Por exemplo, você criará um modelo baseado nos direitos existentes dos funcionários - descarregados do sistema e "levados a um denominador comum". Em seguida, ao coordenar as funções recebidas com o proprietário da empresa do sistema, você pode consultar um item específico do modelo funcional,com base na qual esse ou aquele direito está incluído no papel.



2. -



O segundo passo é realizar uma auditoria dos sistemas de TI para entender como o acesso é organizado para eles. Por exemplo, minha empresa financeira estava executando várias centenas de sistemas de informação. Todos os sistemas tinham alguns rudimentos de gerenciamento baseado em funções, a maioria deles com algum tipo de função, mas principalmente no papel ou no manual do sistema - eles estavam desatualizados há muito tempo e o acesso a eles era distribuído com base em solicitações reais do usuário. Naturalmente, é simplesmente impossível construir um modelo em várias centenas de sistemas ao mesmo tempo, você precisa começar de algum lugar. Realizamos uma análise aprofundada do processo de controle de acesso para determinar seu nível de maturidade. Durante a análise, foram desenvolvidos critérios para priorizar os sistemas de informação - criticidade, prontidão, planos de desativação, etc.Com a ajuda deles, construímos uma sequência para o desenvolvimento / atualização de modelos para esses sistemas. E então incluímos modelos no nosso plano de integração do Gerenciamento de Identidades para automatizar o controle de acesso.



Então, como você determina a criticidade de um sistema? Responda a si mesmo as seguintes perguntas:



  • O sistema está vinculado aos processos operacionais dos quais o negócio principal da empresa depende?
  • A interrupção do sistema afetará a integridade dos ativos da empresa?
  • Qual é o tempo de inatividade máximo permitido do sistema, após o qual é impossível restaurar a atividade após uma interrupção?
  • Uma violação da integridade das informações no sistema pode levar a consequências irreversíveis, tanto financeiras quanto de reputação?
  • Criticidade à fraude. Disponibilidade de funcionalidade, com controle insuficiente do qual, é possível executar ações fraudulentas internas / externas;
  • Quais são os requisitos legais, bem como regras e procedimentos internos para esses sistemas? Haverá multas dos reguladores por não conformidade?


Em nossa empresa financeira, realizamos uma auditoria da seguinte forma. A gerência desenvolveu um processo de auditoria de revisão de direitos de acesso para lidar com usuários e direitos existentes primeiro nos sistemas de informações com prioridade máxima. A unidade de segurança foi designada como proprietária desse processo. Mas, para obter uma imagem completa dos direitos de acesso na empresa, era necessário envolver os departamentos de TI e de negócios no processo. E aqui começaram as disputas, mal-entendidos e, às vezes, até a sabotagem: ninguém quer abandonar seus deveres atuais e se envolver em algumas atividades, à primeira vista, incompreensíveis.



NB - - – IT general controls (ITG), - , best practice (ITIL, COBIT, IT Governance .) , , , .







Uma das áreas de 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 dessa auditoria, obtivemos um registro de sistemas de TI, no qual seus parâmetros técnicos foram determinados e descrições. Além disso, para cada sistema, foi identificado um proprietário da linha de negócios, em cujos interesses ele era operado: era ele quem era responsável pelos processos de negócios que esse sistema atendia. Também foi nomeado um gerente de serviço de TI, responsável pela implementação técnica das necessidades de negócios em um SI específico. Os sistemas mais críticos para a empresa e seus parâmetros técnicos, termos de comissionamento e descomissionamento etc. foram registrados.Esses parâmetros foram muito úteis na preparação para a construção do modelo.



Etapa 3 Crie uma metodologia



A chave para o sucesso de qualquer empresa é o método certo. Portanto, tanto para construir um modelo quanto para conduzir uma auditoria, precisamos criar uma metodologia na qual descrevamos a interação entre departamentos, fixemos responsabilidades nos regulamentos da empresa etc.

Primeiro, você precisa examinar todos os documentos disponíveis que estabelecem o procedimento para conceder acesso e direitos. De uma maneira amigável, os processos devem ser documentados em vários níveis:



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


Em nossa empresa financeira, encontramos muitos documentos desatualizados - tivemos que trazê-los de acordo com os novos processos introduzidos.



Por ordem da gerência, foi criado um grupo de trabalho, que incluía representantes das áreas de segurança, TI, negócios e controles internos. A ordem delineou os objetivos de criar o grupo, a direção da atividade, o período de existência e as pessoas responsáveis ​​de cada lado. Além disso, desenvolvemos uma metodologia para a realização de uma auditoria e um procedimento para a construção de um modelo: eles foram acordados por todos os representantes responsáveis ​​das áreas e aprovados pela gerência da empresa.



Documentos que descrevem o procedimento para a execução de trabalhos, termos, responsabilidade, etc. - uma garantia de que, no caminho para o objetivo estimado, que a princípio não é óbvio para todos, ninguém terá perguntas "por que estamos fazendo isso, por que precisamos etc." e não haverá oportunidade de "pular" ou desacelerar o processo.







Etapa 4. Corrija os parâmetros do modelo de controle de acesso existente



Elaboramos o chamado "passaporte do sistema" em termos de controle de acesso. De fato, este é um questionário para um sistema de informações específico, no qual todos os algoritmos para controlar o acesso a ele são registrados. As empresas que já implementaram soluções de IDM provavelmente estão familiarizadas com esse questionário, pois é com ele que a pesquisa de sistemas começa.



Alguns dos parâmetros sobre o sistema e os proprietários entraram no questionário a partir do registro de TI (consulte a etapa 2, auditoria), mas novos também foram adicionados:



  • como as contas são gerenciadas (diretamente no banco de dados ou por meio de interfaces de software);
  • como os usuários efetuam login no sistema (usando uma conta separada ou usando uma conta do AD, LDAP etc.);
  • quais níveis de acesso ao sistema são usados ​​(nível do aplicativo, nível do sistema, uso do sistema dos recursos de arquivos de rede);
  • , ;
  • (, ..);
  • ;
  • (, .);
  • ;
  • (, , ., );
  • ( , , .);
  • (SOD – Segregation of Duties), ;
  • , , , ..


A lista continua, detalhando os vários parâmetros e outros objetos envolvidos no processo de controle de acesso.



Etapa 5. Crie uma descrição de autorização orientada a negócios



Outro documento que precisaremos ao criar um modelo é uma referência a todos os poderes (direitos) possíveis que podem ser fornecidos aos usuários no sistema de informações com uma descrição detalhada da função comercial por trás dele. Freqüentemente, a autoridade no sistema é criptografada com certos nomes que consistem em letras e números, e os funcionários da empresa não conseguem descobrir o que está por trás desses símbolos. Depois, eles vão ao serviço de TI e lá ... eles também não podem responder à pergunta, por exemplo, sobre direitos raramente usados. Então você deve realizar testes adicionais.



É bom se a descrição do negócio já existir ou se houver uma combinação desses direitos em grupos e funções. Para alguns aplicativos, é uma boa prática criar essa referência no estágio de design. Mas isso acontece com pouca frequência; portanto, novamente vamos ao departamento de TI para coletar informações sobre todos os direitos possíveis e descrevê-los. Nosso guia conterá o seguinte:



  • o nome da autoridade, incluindo o objeto ao qual o direito de acesso se aplica;
  • a ação que pode ser realizada com o objeto (visualização, alteração, etc., a possibilidade de restrição, por exemplo, por uma base territorial ou por um grupo de clientes);
  • código de autorização (código e nome da função / solicitação do sistema que pode ser executada usando a autorização);
  • descrição da autoridade (descrição detalhada das ações na SI ao aplicar a autoridade e suas conseqüências para o processo;
  • : «» ( ) « » ( ).


6



Na fase final de preparação, você precisa baixar dados dos sistemas de informação sobre todos os usuários e os direitos que eles têm no momento. Dois cenários são possíveis aqui. Primeiro, o departamento de segurança tem acesso direto ao sistema e possui um meio de carregar os relatórios relevantes, o que é raro, mas muito conveniente. Segundo: enviamos uma solicitação à TI para receber relatórios no formato necessário. A prática mostra que não é possível negociar com a TI e obter os dados necessários na primeira vez. Várias abordagens devem ser adotadas até que as informações sejam recebidas no formato 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


Portanto, recebemos descarregamentos do sistema com todos os usuários e com todos os direitos que foram concedidos a eles. E imediatamente deixe de lado todas as contas bloqueadas, pois o trabalho de criação de um modelo será realizado apenas para usuários ativos.



Então, se sua empresa não possui meios automatizados de fechar o acesso a funcionários demitidos (geralmente esse é o caso) ou se há automação de retalhos que nem sempre funciona corretamente, você precisa identificar todas as "almas mortas". Estamos falando das contas de funcionários já demitidos, cujos direitos não são bloqueados por algum motivo - eles precisam ser bloqueados. Para fazer isso, comparamos os dados baixados com a fonte de pessoal. A descarga de pessoal também deve ser obtida primeiro na unidade que lidera a base de pessoal.



Separadamente, é necessário adiar as contas, cujos proprietários não foram encontrados na base de pessoal, não atribuídos a ninguém - ou seja, sem dono. De acordo com esta lista, precisamos da data do último uso: se for relativamente recente, ainda precisamos procurar os proprietários. Isso pode incluir contas de prestadores de serviços externos ou contas de serviço que não são atribuídas a ninguém, mas estão associadas a qualquer processo. Para descobrir a propriedade das contas, você pode enviar cartas a todos os departamentos com uma solicitação para responder. Quando os proprietários são encontrados, inserimos dados sobre eles no sistema: dessa forma, todas as contas existentes são identificadas e as demais são bloqueadas.



Assim que nossos uploads forem limpos de registros desnecessários e restarem apenas contas ativas, você poderá começar a criar um modelo para um sistema de informações específico. Mas vou falar sobre isso no próximo artigo.



Autor: Lyudmila Sevastyanova, Gerente de promoção, Solar inRights



All Articles