Actualmente traballo para un provedor de software, concretamente para solucións de control de acceso. E a miña experiencia "dunha vida pasada" está relacionada co lado do cliente: unha gran organización financeira. Daquela, o noso grupo de control de acceso no departamento de seguridade da información non podía presumir de grandes competencias en IdM. Aprendemos moito no proceso, tivemos que dar moitos golpes para poder construír un mecanismo de traballo para xestionar os dereitos dos usuarios nos sistemas de información da empresa.
Combinando a miña experiencia de cliente tan gañada co coñecemento e as competencias dos provedores, quero compartir con vostede instrucións básicas paso a paso: como crear un modelo de control de acceso baseado en funcións nunha gran empresa e o que isto dará como resultado. . As miñas instrucións constan de dúas partes: a primeira está a prepararse para construír o modelo, a segunda está a construír. Aquí está a primeira parte, a parte preparatoria.
NB Construír un modelo a seguir, por desgraza, non é un resultado, senón un proceso. Ou mellor dito, mesmo parte do proceso de creación dun ecosistema de control de accesos na empresa. Entón, prepárate para o xogo durante moito tempo.
En primeiro lugar, imos definilo: que é o control de acceso baseado en roles? Supoñamos que tes un banco grande con decenas, ou mesmo centos de miles de empregados (entidades), cada un dos cales ten decenas de dereitos de acceso a centos de sistemas de información bancaria (obxectos) internos. Agora multiplica o número de obxectos polo número de suxeitos: este é o número mínimo de conexións que necesitas primeiro para construír e despois controlar. É realmente posible facelo manualmente? Por suposto que non: creáronse papeis para resolver este problema.
Un rol é un conxunto de permisos que necesita un usuario ou grupo de usuarios para realizar determinadas tarefas de traballo. Cada empregado pode ter un ou máis roles, e cada rol pode conter de un a moitos permisos que se lle permiten ao usuario dentro dese rol. Os papeis poden estar vinculados a postos, departamentos ou tarefas funcionais específicas dos empregados.
Os roles adoitan crearse a partir das autorizacións individuais dos empregados en cada sistema de información. Despois fórmanse roles comerciais globais a partir dos roles de cada sistema. Por exemplo, a función empresarial "xestor de crédito" incluirá varios roles separados nos sistemas de información que se utilizan na oficina de clientes do banco. Por exemplo, como o principal sistema bancario automatizado, módulo de caixa, sistema de xestión de documentos electrónicos, xestor de servizos e outros. Os roles empresariais, por regra xeral, están ligados á estrutura organizativa, é dicir, ao conxunto de divisións e posicións da empresa nelas. Así é como se forma unha matriz de roles global (poño un exemplo na táboa seguinte).
Paga a pena notar que é simplemente imposible construír un modelo 100%, proporcionando todos os dereitos necesarios para os empregados de cada posto nunha estrutura comercial. Si, isto non é necesario. Despois de todo, un modelo a seguir non pode ser estático, porque depende dun ambiente en constante cambio. E dos cambios nas actividades comerciais da empresa, que, en consecuencia, afectan aos cambios na estrutura organizativa e na funcionalidade. E pola falta de plena dotación de recursos, e polo incumprimento das fichas de postos de traballo, e polo afán de lucro a costa da seguridade, e por moitos outros factores. Polo tanto, é necesario construír un modelo a seguir que poida cubrir ata o 80% das necesidades dos usuarios para os dereitos básicos necesarios cando se lles asigna un posto. E poden, se é necesario, solicitar o 20% restante máis tarde en solicitudes separadas.
Por suposto, podes preguntar: "Non existen modelos 100% a seguir?" Ben, por que, isto ocorre, por exemplo, en estruturas sen ánimo de lucro que non están suxeitas a cambios frecuentes, nalgún instituto de investigación. Ou en organizacións complexas militar-industriais cun alto nivel de seguridade, onde a seguridade é o primeiro. Ocorre nunha estrutura comercial, pero no marco dunha división separada, cuxo traballo é un proceso bastante estático e previsible.
A principal vantaxe da xestión baseada en roles é a simplificación da emisión de dereitos, porque o número de roles é significativamente menor que o número de usuarios do sistema de información. E isto é certo para calquera industria.
Tomemos unha empresa de venda polo miúdo: emprega a miles de vendedores, pero teñen o mesmo conxunto de dereitos no sistema N, e só se creará un rol para eles. Cando un novo vendedor chega á empresa, asígnaselle automaticamente o papel necesario no sistema, que xa ten todas as autoridades necesarias. Ademais, cun só clic podes cambiar os dereitos de miles de vendedores á vez, por exemplo, engadir unha nova opción para xerar un informe. Non é necesario facer mil operacións, vinculando un novo dereito a cada conta; só tes que engadir esta opción ao rol e aparecerá para todos os vendedores ao mesmo tempo.
Outra vantaxe da xestión por roles é a eliminación da emisión de autorizacións incompatibles. É dicir, un empregado que ten un determinado papel no sistema non pode ter simultaneamente outro papel, cuxos dereitos non deben combinarse cos dereitos do primeiro. Un exemplo rechamante é a prohibición de combinar as funcións de entrada e control dunha transacción financeira.
Calquera persoa que estea interesada en como chegou a ser o control de acceso baseado en roles pode
mergullo na historia
Se miramos á historia, a comunidade informática pensou por primeira vez nos métodos de control de acceso nos anos 70 do século XX. Aínda que daquela as aplicacións eran bastante sinxelas, igual que agora, todos querían xestionar comodamente o acceso a elas. Concede, cambia e controla os dereitos dos usuarios, só para facilitar a comprensión de que acceso ten cada un deles. Pero daquela non había estándares comúns, estaban a desenvolverse os primeiros sistemas de control de acceso e cada empresa baseábase nas súas propias ideas e regras.
Agora coñécense moitos modelos de control de acceso diferentes, pero non apareceron inmediatamente. Detémonos nos que contribuíron significativamente ao desenvolvemento desta zona.
O primeiro e probablemente o máis sinxelo modelo é Control de acceso discrecional (selectivo). (DAC – Control de acceso discrecional). Este modelo implica o reparto de dereitos por todos os participantes no proceso de acceso. Cada usuario ten acceso a obxectos ou operacións específicas. En esencia, aquí o conxunto de suxeitos de dereitos correspóndese co conxunto de obxectos. Atopouse que este modelo era demasiado flexible e moi difícil de manter: as listas de acceso acaban por ser enormes e difíciles de controlar.
O segundo modelo é Control de acceso obrigatorio (MAC - Control de acceso obrigatorio). Segundo este modelo, cada usuario recibe acceso a un obxecto de acordo co acceso concedido a un determinado nivel de confidencialidade dos datos. En consecuencia, os obxectos deben clasificarse segundo o seu nivel de confidencialidade. A diferenza do primeiro modelo flexible, este, pola contra, resultou demasiado estrito e restritivo. Non se xustifica o seu uso cando a empresa dispón de moitos recursos de información diferentes: para diferenciar o acceso a distintos recursos, haberá que introducir moitas categorías que non se solaparán.
Debido ás evidentes imperfeccións destes dous métodos, a comunidade informática continuou desenvolvendo modelos máis flexibles e ao mesmo tempo máis ou menos universais para soportar diferentes tipos de políticas de control de acceso organizativos. E entón apareceu o terceiro modelo de control de acceso baseado en roles! Este enfoque demostrou ser o máis prometedor porque require non só a autorización da identidade do usuario, senón tamén as súas funcións operativas nos sistemas.
O primeiro modelo de estrutura claramente descrito foi proposto polos científicos estadounidenses David Ferrailo e Richard Kuhn do Instituto Nacional de Estándares e Tecnoloxía dos Estados Unidos en 1992. Entón apareceu por primeira vez o termo RBAC (Control de acceso baseado en roles). Estes estudos e descricións dos principais compoñentes, así como as súas relacións, constituíron a base da norma INCITS 359-2012, que segue vixente na actualidade, aprobada polo Comité Internacional de Estándares de Tecnoloxías da Información (INCITS).
O estándar define un rol como "unha función de traballo no contexto dunha organización con algunha semántica asociada con respecto á autoridade e responsabilidade asignada ao usuario asignado ao rol". O documento establece os elementos básicos do RBAC: usuarios, sesións, roles, permisos, operacións e obxectos, así como as relacións e interconexións entre eles.
O estándar proporciona a estrutura mínima necesaria para construír un modelo de rol: combinando dereitos en roles e despois concedendo acceso aos usuarios a través destes roles. Descríbanse os mecanismos para a composición de roles a partir de obxectos e operacións, descríbense a xerarquía de roles e a herdanza de poderes. Despois de todo, en calquera empresa hai roles que combinan poderes básicos que son necesarios para todos os empregados da empresa. Pode ser o acceso ao correo electrónico, EDMS, portal corporativo, etc. Estes permisos pódense incluír nun rol xeral chamado "empregado" e non será necesario enumerar todos os dereitos básicos unha e outra vez en cada un dos roles de nivel superior. Basta con indicar simplemente a herdanza característica do papel de "empregado".
Máis tarde, o estándar complementouse con novos atributos de acceso relacionados co entorno en constante cambio. Engadiuse a capacidade de introducir restricións estáticas e dinámicas. Os estáticos implican a imposibilidade de combinar roles (a mesma entrada e control das operacións mencionados anteriormente). As restricións dinámicas pódense determinar modificando parámetros, por exemplo, o tempo (horas ou días laborables/non laborables), a localización (oficina/fogar), etc.
Por separado, hai que dicir sobre control de acceso baseado en atributos (ABAC - Control de acceso baseado en atributos). O enfoque baséase en conceder acceso mediante regras de compartición de atributos. Este modelo pódese usar por separado, pero moitas veces complementa activamente o modelo clásico: atributos de usuarios, recursos e dispositivos, así como a hora ou a localización, pódense engadir a un determinado rol. Isto permítelle utilizar menos roles, introducir restricións adicionais e minimizar o acceso posible e, polo tanto, mellorar a seguridade.
Por exemplo, un contador pode ter acceso ás contas se traballa nunha determinada rexión. A continuación, compararase a localización do especialista cun determinado valor de referencia. Ou pode dar acceso ás contas só se o usuario inicia sesión desde un dispositivo incluído na lista de permitidas. Unha boa adición a un modelo a seguir, pero raramente se usa por si só debido á necesidade de crear moitas regras e táboas de permisos ou restricións.
Permíteme darche un exemplo de uso de ABAC da miña "vida pasada". O noso banco tiña varias sucursais. Os empregados das oficinas dos clientes destas sucursais realizaron exactamente as mesmas operacións, pero tiveron que traballar no sistema principal só con contas na súa rexión. En primeiro lugar, comezamos a crear roles separados para cada rexión, e había tantos roles con funcións repetidas, pero con acceso a contas diferentes. Despois, ao utilizar un atributo de localización para o usuario e asociándoo a un rango específico de contas para revisar, reducimos significativamente o número de roles no sistema. Como resultado, os roles mantivéronse só para unha sucursal, que foron replicados para os postos correspondentes en todas as demais divisións territoriais do banco.
Agora imos falar dos pasos preparatorios necesarios, sen os cales é simplemente imposible construír un modelo a seguir.
Paso 1. Crea un modelo funcional
Debería comezar creando un modelo funcional: un documento de nivel superior que describa en detalle a funcionalidade de cada departamento e cada posto. Como regra xeral, a información inscríbese a partir de varios documentos: descricións de traballo e regulamentos para unidades individuais: departamentos, divisións, departamentos. O modelo funcional deberá ser consensuado con todos os departamentos interesados (empresa, control interno, seguridade) e aprobado pola dirección da empresa. Para que serve este documento? Para que o modelo poida referirse a el. Por exemplo, vai construír un modelo baseado nos dereitos existentes dos empregados: descargado do sistema e "reducido a un denominador común". Despois, ao acordar os roles recibidos co propietario do sistema, pódese referir a un punto específico do modelo funcional, en base ao cal se inclúe este ou aquel dereito no rol.
Paso 2. Auditamos sistemas informáticos e elaboramos un plan de priorización
Na segunda etapa, debe realizar unha auditoría dos sistemas informáticos para comprender como se organiza o acceso a eles. Por exemplo, a miña empresa financeira operaba varios centos de sistemas de información. Todos os sistemas tiñan algúns rudimentos de xestión baseada en roles, a maioría tiñan algúns roles, pero sobre todo en papel ou no directorio do sistema: estaban desactualizados durante moito tempo e o acceso a eles concedíase en función das solicitudes reais dos usuarios. Por suposto, é simplemente imposible construír un modelo a seguir en varios centos de sistemas á vez; tes que comezar nalgún lugar. Realizamos unha análise en profundidade do proceso de control de accesos para determinar o seu nivel de madurez. Durante o proceso de análise desenvolvéronse criterios de priorización dos sistemas de información: criticidade, preparación, plans de desmantelamento, etc. Coa súa axuda, aliñamos o desenvolvemento/actualización de modelos para estes sistemas. E despois incluímos modelos no plan de integración coa solución de Identity Management para automatizar a xestión de accesos.
Entón, como se determina a criticidade dun sistema? Responde as seguintes preguntas:
- ¿Está conectado o sistema aos procesos operativos dos que dependen as actividades fundamentais da empresa?
- A interrupción do sistema afectará á integridade dos activos da empresa?
- Cal é o tempo de inactividade máximo permitido do sistema, alcanzando o cal é imposible restablecer a actividade despois dunha interrupción?
- Unha violación da integridade da información no sistema pode levar a consecuencias irreversibles, tanto financeiras como reputacionais?
- Criticidade ante a fraude. A presenza de funcionalidades, se non se controla adecuadamente, pode levar a accións fraudulentas internas/externas;
- Cales son os requisitos legais e as normas e procedementos internos para estes sistemas? Haberá multas dos reguladores por incumprimento?
Na nosa empresa financeira, realizamos unha auditoría coma esta. A dirección desenvolveu o procedemento de auditoría Access Rights Review para analizar primeiro os usuarios e dereitos existentes naqueles sistemas de información que estaban na lista de prioridade máis alta. O departamento de seguridade foi asignado como propietario deste proceso. Pero para ter unha imaxe completa dos dereitos de acceso na empresa, foi necesario implicar no proceso aos departamentos informáticos e empresariais. E aquí comezaron as disputas, os malentendidos e ás veces mesmo as sabotaxes: ninguén quere romper coas súas responsabilidades actuais e involucrarse nalgunhas actividades, a primeira vista, incomprensibles.
NB As grandes empresas con procesos informáticos desenvolvidos probablemente estean familiarizadas co procedemento de auditoría informática - Controis xerais de TI (ITGC), que permite identificar as deficiencias nos procesos informáticos e establecer un control para mellorar os procesos de acordo coas mellores prácticas (ITIL, COBIT, IT). Gobernanza, etc.) Esta auditoría permite que TI e empresas se comprendan mellor entre si e desenvolvan unha estratexia de desenvolvemento conxunta, analice os riscos, optimice os custos e desenvolva enfoques de traballo máis eficaces.
Unha das áreas da auditoría é determinar os parámetros de acceso lóxico e físico aos sistemas de información. Tomamos os datos obtidos como base para un uso posterior na construción dun modelo a seguir. Como resultado desta auditoría, tivemos un rexistro de sistemas informáticos, no que se determinaban os seus parámetros técnicos e se describiron. Ademais, para cada sistema identificábase un propietario da dirección de negocio en cuxos intereses se operaba: era el quen era o responsable dos procesos comerciais aos que servía este sistema. Tamén se nomeou un responsable de servizos informáticos, responsable da implantación técnica das necesidades empresariais dun SI específico. Rexistráronse os sistemas máis críticos para a empresa e os seus parámetros técnicos, prazos de posta en servizo e baixa, etc.. Estes parámetros foron moi útiles no proceso de preparación para a creación dun modelo a seguir.
Paso 3 Crear unha metodoloxía
A clave do éxito de calquera empresa é o método correcto. Polo tanto, tanto para construír un modelo a seguir como para realizar unha auditoría, cómpre crear unha metodoloxía na que describamos a interacción entre departamentos, establezamos a responsabilidade na normativa da empresa, etc.
En primeiro lugar cómpre examinar todos os documentos dispoñibles que establecen o procedemento de concesión de acceso e dereitos. En boa forma, os procesos deberían documentarse a varios niveis:
- requisitos xerais corporativos;
- requisitos para as áreas de seguridade da información (dependendo das áreas de actividade da organización);
- requisitos para procesos tecnolóxicos (instrucións, matrices de acceso, directrices, requisitos para configuracións).
Na nosa empresa financeira atopamos moitos documentos desactualizados, tivemos que traelos de acordo cos novos procesos que se están implantando.
Por orde de xestión creouse un grupo de traballo no que se integraron representantes de seguridade, informática, empresa e control interno. A orde delineaba os obxectivos da creación do grupo, a dirección da actividade, o período de existencia e os responsables de cada bando. Ademais, desenvolvemos unha metodoloxía de auditoría e un procedemento para construír un modelo a seguir: foron acordados por todos os representantes responsables das áreas e aprobados pola dirección da empresa.
Documentos que describan o procedemento de realización dos traballos, prazos, responsabilidades, etc. - unha garantía de que no camiño cara ao obxectivo querido, que nun principio non é obvio para todos, ninguén terá preguntas "por que facemos isto, por que o necesitamos, etc". e non haberá oportunidade de "saltar" ou ralentizar o proceso.
Paso 4. Corrixe os parámetros do modelo de control de acceso existente
Estamos elaborando un denominado “pasaporte de sistema” en materia de control de acceso. En esencia, trátase dun cuestionario sobre un sistema de información específico, que rexistra todos os algoritmos para controlar o acceso a el. As empresas que xa implementaron solucións de clase IdM probablemente estean familiarizadas con tal cuestionario, xa que aquí é onde comeza o estudo dos sistemas.
Algúns parámetros sobre o sistema e os propietarios entraron no cuestionario do rexistro de TI (ver o paso 2, auditoría), pero tamén se engadiron outros novos:
- como se xestionan as contas (directamente na base de datos ou a través de interfaces de software);
- como os usuarios inician sesión no sistema (usando unha conta separada ou usando unha conta AD, LDAP, etc.);
- que niveis de acceso ao sistema se utilizan (nivel de aplicación, nivel de sistema, uso do sistema dos recursos de ficheiros de rede);
- descrición e parámetros dos servidores nos que se executa o sistema;
- que operacións de xestión de contas son compatibles (bloqueo, cambio de nome, etc.);
- que algoritmos ou regras se utilizan para xerar o identificador de usuario do sistema;
- que atributo se pode usar para establecer unha conexión co rexistro dun empregado no sistema de persoal (nome completo, número de persoal, etc.);
- todos os posibles atributos da conta e regras para cumprilos;
- que dereitos de acceso existen no sistema (roles, grupos, dereitos atómicos, etc., hai dereitos aniñados ou xerárquicos);
- mecanismos de división de dereitos de acceso (por cargo, departamento, funcionalidade, etc.);
- O sistema ten regras para a segregación de dereitos (SOD – Segregation of Duties) e como funcionan?
- como se procesan no sistema os eventos de ausencia, traslado, despedimento, actualización de datos dos empregados, etc.
Esta lista pódese continuar con detalles sobre os distintos parámetros e outros obxectos que interveñen no proceso de control de acceso.
Paso 5. Crea unha descrición dos permisos orientada á empresa
Outro documento que necesitaremos á hora de construír un modelo a seguir é un libro de consulta sobre todos os poderes (dereitos) posibles que se poden outorgar aos usuarios no sistema de información cunha descrición detallada da función empresarial que se apoia. A miúdo, as autoridades do sistema están cifradas con certos nomes que consisten en letras e números, e os empregados das empresas non poden descubrir o que se esconde detrás destes símbolos. Despois van ao servizo de informática, e alí... tampouco poden responder á pregunta, por exemplo, sobre dereitos pouco utilizados. Despois hai que facer probas adicionais.
É bo se xa hai unha descrición da empresa ou mesmo se hai unha combinación destes dereitos en grupos e roles. Para algunhas aplicacións, a mellor práctica é crear tal referencia na fase de desenvolvemento. Pero isto non ocorre a miúdo, polo que volvemos acudir ao departamento de TI para recoller información sobre todos os dereitos posibles e describilos. A nosa guía, finalmente, conterá o seguinte:
- nome da autoridade, incluído o obxecto ao que se aplica o dereito de acceso;
- unha acción que se permite realizar cun obxecto (ver, cambiar, etc., a posibilidade de restrición, por exemplo, por base territorial ou por grupo de clientes);
- código de autorización (código e nome da función/solicitude do sistema que se pode executar mediante a autorización);
- descrición da autoridade (descrición detallada das accións no SI ao aplicar a autoridade e as súas consecuencias para o proceso;
- estado do permiso: "Activo" (se o permiso está asignado a polo menos un usuario) ou "Non activo" (se non se utiliza o permiso).
Paso 6 Descargamos datos sobre usuarios e dereitos dos sistemas e comparámolos coa fonte de persoal
Na fase final de preparación, cómpre descargar datos dos sistemas de información sobre todos os usuarios e os dereitos que teñen actualmente. Aquí hai dous escenarios posibles. Primeiro: o departamento de seguridade ten acceso directo ao sistema e ten os medios para descargar informes relevantes, o que non ocorre a miúdo, pero é moi cómodo. Segundo: enviamos unha solicitude a TI para recibir informes no formato requirido. A experiencia demostra que non é posible chegar a un acordo con TI e obter os datos necesarios a primeira vez. É necesario realizar varias aproximacións ata que a información se reciba na forma e formato desexados.
Que datos hai que descargar:
- Nome da conta
- Nome completo do empregado a quen está asignado
- Estado (activo ou bloqueado)
- Data de creación da conta
- Data do último uso
- Lista de dereitos/grupos/roles dispoñibles
Así, recibimos descargas do sistema con todos os usuarios e todos os dereitos que se lles concederon. E inmediatamente deixaron de lado todas as contas bloqueadas, xa que o traballo na construción dun modelo a seguir realizarase só para os usuarios activos.
Entón, se a túa empresa non ten medios automatizados para bloquear o acceso aos empregados despedidos (isto ocorre con frecuencia) ou ten unha automatización de mosaicos que non sempre funciona correctamente, debes identificar todas as "almas mortas". Estamos a falar das contas dos empregados xa despedidos, cuxos dereitos por algún motivo non están bloqueados: hai que bloquealos. Para iso, comparamos os datos cargados coa fonte do persoal. A descarga de persoal tamén deberá obterse previamente do departamento que manteña a base de datos de persoal.
Por separado, é necesario deixar de lado as contas cuxos propietarios non se atoparon na base de datos de persoal, non se asignaron a ninguén, é dicir, sen propietario. Usando esta lista, necesitaremos a data do último uso: se é bastante recente, aínda teremos que buscar os propietarios. Isto pode incluír contas de contratistas externos ou contas de servizos que non están asignadas a ninguén, pero que están asociadas a ningún proceso. Para saber a quen pertencen as contas, pode enviar cartas a todos os departamentos solicitándolles que respondan. Cando se atopan os propietarios, introducimos datos sobre eles no sistema: deste xeito, todas as contas activas son identificadas e o resto son bloqueados.
Tan pronto como as nosas cargas se eliminen de rexistros innecesarios e só queden contas activas, podemos comezar a construír un modelo a seguir para un sistema de información específico. Pero falarei sobre isto no seguinte artigo.
Autor: Lyudmila Sevastyanova, xerente de promoción Solar inRights
Fonte: www.habr.com