Estamos construyendo un modelo a seguir para el control de acceso. Primera parte, preparatoria

Ahora trabajo para un proveedor de software, en particular para soluciones de control de acceso. Y mi experiencia de "vida pasada" está relacionada con el lado del cliente: una gran organización financiera. En ese momento, nuestro grupo para el control de acceso en el departamento de seguridad de la información no podía presumir de grandes competencias en IdM. Aprendimos mucho en el proceso, tuvimos que llenar un montón de obstáculos para construir un mecanismo de trabajo para administrar los derechos de los usuarios en los sistemas de información de la empresa.



Después de combinar mi experiencia adquirida en el cliente con el conocimiento y las competencias del proveedor, quiero compartir con ustedes esencialmente instrucciones paso a paso: cómo crear un modelo de control de acceso basado en roles en una gran empresa, y lo que finalmente proporcionará. Mi instrucción consta de dos partes: primero, nos estamos preparando para construir un modelo, segundo, en realidad estamos construyendo. Aquí está la primera parte, preparatoria.



Nota: La construcción de un modelo a seguir, lamentablemente, no es un resultado, sino un proceso. O más bien, incluso parte del proceso de creación de un ecosistema de control de acceso en la empresa. Así que sintonice a largo plazo.



Primero, definamos: ¿qué es el control de acceso basado en roles? Suponga que tiene un banco grande con decenas o incluso cientos de miles de empleados (sujetos), cada uno de los cuales tiene decenas de derechos de acceso a cientos de sistemas de información (objetos) bancarios internos. Ahora multiplique el número de objetos por el número de sujetos, es decir, el número mínimo de conexiones que necesita para construir primero y luego controlar. ¿Es realista hacer esto manualmente? Por supuesto que no, los roles parecían resolver este problema.



Un rol es un conjunto de permisos que un usuario o grupo de usuarios necesita para realizar ciertas tareas de trabajo. Cada empleado puede tener uno o más roles, y cada rol puede contener de uno a muchos permisos que se permiten a un usuario dentro de este rol. Los roles pueden estar vinculados a puestos específicos, departamentos o tareas funcionales de los empleados.







Los roles generalmente se crean a partir de autorizaciones de empleados individuales en cada sistema de información. Luego, los roles comerciales globales se forman a partir de los roles de cada sistema. Por ejemplo, un rol comercial de gerente de crédito incluiría varios roles distintos en los sistemas de información que se utilizan en la oficina del cliente de un banco. Por ejemplo, en el sistema bancario automatizado principal, módulo de caja, sistema de gestión de documentos electrónicos, administrador de servicios y otros. Los roles comerciales, por regla general, están vinculados a la estructura organizativa y del personal, en otras palabras, al conjunto de departamentos de la empresa y los puestos en ellos. Así es como se forma la matriz de roles global (doy un ejemplo en la tabla a continuación).







Vale la pena señalar que es simplemente imposible construir un modelo 100% a seguir, proporcionando todos los derechos necesarios a los empleados de cada puesto en una estructura comercial. Si, no es necesario. Después de todo, un modelo a seguir no puede ser estático, porque depende de un entorno en constante cambio. Y del cambio en las actividades comerciales de la empresa, que, en consecuencia, afecta el cambio en la estructura y funcionalidad de la organización. Y por la falta de una provisión completa de recursos, y por el incumplimiento de las descripciones de trabajo, y por el deseo de obtener ganancias a expensas de la seguridad, y de muchos otros factores. Por lo tanto, es necesario construir un modelo a seguir que pueda cubrir hasta el 80% de las necesidades de los usuarios de los derechos básicos necesarios cuando son nombrados para un puesto. Y podrán, si es necesario, solicitar el 20% restante más adelante en solicitudes separadas.



Por supuesto, puede preguntar: "¿Qué, no hay modelos 100% a seguir?" Bueno, por qué sucede esto, por ejemplo, en estructuras sin fines de lucro que no están sujetas a cambios frecuentes, en algunos institutos de investigación. O en organizaciones militares-industriales complejas con un alto nivel de seguridad, donde la seguridad es lo primero. También ocurre en una estructura comercial, pero dentro del marco de una unidad separada, cuyo trabajo es un proceso bastante estático y predecible.



La principal ventaja de la gestión de roles es la simplificación de la concesión de derechos, porque el número de roles es significativamente menor que el de los usuarios del sistema de información. Y esto es cierto para cualquier industria.



Tome una empresa minorista: emplea a miles de vendedores, pero tienen el mismo conjunto de derechos en el sistema N, y solo se creará un rol para ellos. Un nuevo vendedor llegó a la empresa: se le asignó automáticamente el papel necesario en el sistema, que ya tiene todos los poderes necesarios. También puede cambiar los derechos de miles de vendedores con un solo clic, por ejemplo, agregar una nueva opción para generar un informe. No necesita realizar miles de operaciones, vincular un nuevo derecho a cada cuenta; solo necesita agregar esta opción al rol, y aparecerá para todos los vendedores al mismo tiempo.



Otra ventaja de la gestión basada en roles es la eliminación de la emisión de poderes incompatibles. Es decir, un empleado que tiene un cierto rol en el sistema no puede tener simultáneamente otro rol, cuyos derechos no deben combinarse con los derechos del primero. Un ejemplo sorprendente es la prohibición de combinar las funciones de entrar y controlar una transacción financiera.



Cualquier persona interesada en cómo surgió el control de acceso basado en roles puede

Ahora hablemos sobre los pasos preparatorios necesarios, sin los cuales es simplemente imposible construir un modelo a seguir que funcione.

Paso 1. Crear un modelo funcional

Vale la pena comenzar con la creación de un modelo funcional: un documento de nivel superior que describa en detalle la funcionalidad de cada departamento y cada puesto. Como regla, la información proviene de varios documentos: descripciones de trabajo y regulaciones para divisiones individuales: departamentos, departamentos, departamentos. El modelo funcional debe ser acordado con todos los departamentos interesados ​​(negocios, control interno, seguridad) y aprobado por la gerencia de la compañía. ¿Para qué sirve este documento? Para que el modelo a seguir pueda referirse a él. Por ejemplo, va a construir un modelo a seguir basado en los derechos de los empleados existentes: descargado del sistema y "llevado a un denominador común". Luego, al coordinar los roles recibidos con el propietario del negocio del sistema, puede referirse a un elemento específico del modelo funcional,sobre la base de que este o aquel derecho está incluido en el rol.

2. -

El segundo paso es realizar una auditoría de los sistemas de TI para comprender cómo se organiza el acceso a ellos. Por ejemplo, mi compañía financiera estaba ejecutando varios cientos de sistemas de información. Todos los sistemas tenían algunos rudimentos de gestión basada en roles, la mayoría de ellos tenían algún tipo de roles, pero principalmente en papel o en el manual del sistema: estaban desactualizados hace mucho tiempo y el acceso a ellos se distribuía en función de las solicitudes reales de los usuarios. Naturalmente, es simplemente imposible construir un modelo a seguir en varios cientos de sistemas a la vez, hay que comenzar en alguna parte. Realizamos una revisión en profundidad del proceso de control de acceso para determinar su nivel de madurez. Durante el análisis, se desarrollaron criterios para priorizar los sistemas de información: criticidad, preparación, planes de desmantelamiento, etc.Con su ayuda, hemos construido una secuencia para el desarrollo / actualización de modelos a seguir para estos sistemas. Y luego incluimos modelos a seguir en nuestro plan de integración de Identity Management para automatizar el control de acceso.



Entonces, ¿cómo se determina la criticidad de un sistema? Responde las siguientes preguntas:

• ¿El sistema está vinculado a los procesos operativos de los que depende el negocio principal de la empresa?
• ¿La interrupción del sistema afectará la integridad de los activos de la compañía?
• ¿Cuál es el tiempo de inactividad máximo permitido del sistema, después del cual es imposible restaurar la actividad después de una interrupción?
• ¿Una violación de la integridad de la información en el sistema puede tener consecuencias irreversibles, tanto financieras como de reputación?
• Crítica al fraude. Disponibilidad de funcionalidad, con un control insuficiente del cual, es posible llevar a cabo acciones fraudulentas internas / externas;
• ¿Cuáles son los requisitos legales, así como las normas y procedimientos internos para estos sistemas? ¿Habrá multas de los reguladores por incumplimiento?

En nuestra compañía financiera, realizamos una auditoría de la siguiente manera. La gerencia ha desarrollado un proceso de auditoría de Access Right Review para tratar con los usuarios y derechos existentes primero en los sistemas de información de mayor prioridad. La unidad de seguridad fue designada como propietaria de este proceso. Pero para obtener una imagen completa de los derechos de acceso en la empresa, era necesario involucrar a los departamentos de TI y de negocios en el proceso. Y aquí comenzaron las disputas, los malentendidos y, a veces, incluso el sabotaje: nadie quiere separarse de sus deberes actuales y participar en algunas, a primera vista, actividades incomprensibles.



nótese bien - - – IT general controls (ITG), - , best practice (ITIL, COBIT, IT Governance .) , , , .







Una de las áreas de auditoría es determinar los parámetros de acceso lógico y físico a los sistemas de información. Tomamos los datos obtenidos como base para su posterior uso en la construcción de un modelo a seguir. Como resultado de dicha auditoría, obtuvimos un registro de los sistemas de TI, en el que se determinaron sus parámetros técnicos y se dieron descripciones. Además, para cada sistema, se identificó un propietario de la línea de negocios, en cuyo interés se operaba: era él quien era responsable de los procesos de negocios a los que servía este sistema. También se nombró un gerente de servicios de TI, responsable de la implementación técnica de las necesidades comerciales en un SI específico. Se registraron los sistemas más críticos para la empresa y sus parámetros técnicos, términos de puesta en servicio y desmantelamiento, etc.Estos parámetros fueron muy útiles para preparar el modelo a seguir.

Paso 3 Crear una metodología

La clave del éxito de cualquier negocio es el método correcto. Por lo tanto, tanto para construir un modelo a seguir como para realizar una auditoría, necesitamos crear una metodología en la que describamos la interacción entre los departamentos, fijemos la responsabilidad en las regulaciones de la compañía, etc.

Primero, debe examinar todos los documentos disponibles que establecen el procedimiento para otorgar acceso y derechos. De manera amistosa, los procesos deben documentarse en varios niveles:

• requisitos corporativos generales;
• requisitos para las áreas de seguridad de la información (dependiendo de las áreas de actividad de la organización);
• requisitos para procesos tecnológicos (instrucciones, matrices de acceso, pautas, requisitos para configuraciones).

En nuestra compañía financiera, encontramos muchos documentos obsoletos, tuvimos que ponerlos de acuerdo con los nuevos procesos que se están introduciendo.



Por orden de la gerencia, se creó un grupo de trabajo, que incluía representantes de las áreas de seguridad, TI, negocios y control interno. El orden describió los objetivos de crear el grupo, la dirección de la actividad, el período de existencia y las personas responsables de cada lado. Además, hemos desarrollado una metodología para realizar una auditoría y un procedimiento para construir un modelo a seguir: fueron acordados por todos los representantes responsables de las áreas y aprobados por la gerencia de la compañía.



Documentos que describen el procedimiento para llevar a cabo el trabajo, términos, responsabilidad, etc. - una garantía de que en el camino hacia la meta deseada, que al principio no es obvio para todos, nadie tendrá preguntas "por qué estamos haciendo esto, por qué lo necesitamos, etc." y no habrá oportunidad de "saltar" o ralentizar el proceso.

Paso 4. Arregle los parámetros del modelo de control de acceso existente

Elaboramos el llamado "pasaporte del sistema" en términos de control de acceso. De hecho, este es un cuestionario para un sistema de información específico, en el que se registran todos los algoritmos para controlar el acceso al mismo. Las empresas que ya han implementado soluciones IdM probablemente estén familiarizadas con dicho cuestionario, ya que es con él que comienza la investigación de sistemas.



Algunos de los parámetros sobre el sistema y los propietarios fluyeron al cuestionario desde el registro de TI (consulte el paso 2, auditoría), pero también se agregaron otros nuevos:

• cómo se administran las cuentas (directamente en la base de datos o mediante interfaces de software);
• cómo los usuarios inician sesión en el sistema (usando una cuenta separada o usando una cuenta AD, LDAP, etc.);
• qué niveles de acceso al sistema se utilizan (nivel de aplicación, nivel de sistema, uso del sistema de recursos de archivos de red);
• , ;
• (, ..);
• ;
• (, .);
• ;
• (, , ., );
• ( , , .);
• (SOD – Segregation of Duties), ;
• , , , ..

La lista sigue y sigue, detallando los diversos parámetros y otros objetos que están involucrados en el proceso de control de acceso.

Paso 5. Crear una descripción de autorización orientada a los negocios

Otro documento que necesitaremos al construir un modelo a seguir es una guía de todos los poderes (derechos) posibles que se pueden proporcionar a los usuarios en el sistema de información con una descripción detallada de la función comercial que está detrás de él. A menudo, la autoridad en el sistema está encriptada con ciertos nombres que consisten en letras y números, y los empleados de negocios no pueden entender qué hay detrás de estos símbolos. Luego van al servicio de TI y allí ... tampoco pueden responder la pregunta, por ejemplo, sobre los derechos raramente utilizados. Entonces tienes que realizar pruebas adicionales.



Es bueno si la descripción del negocio ya existe o si existe una combinación de estos derechos en grupos y roles. Para algunas aplicaciones, es una buena práctica crear tal referencia en la etapa de diseño. Pero esto sucede con poca frecuencia, por lo que nuevamente acudimos al departamento de TI para recopilar información sobre todos los derechos posibles y describirlos. Nuestra guía eventualmente contendrá lo siguiente:

• el nombre de la autoridad, incluido el objeto al que se aplica el derecho de acceso;
• la acción que se permite realizar con el objeto (ver, cambiar, etc., la posibilidad de restricción, por ejemplo, por una base territorial o por un grupo de clientes);
• código de autorización (código y nombre de la solicitud de función / sistema que se puede ejecutar utilizando la autorización);
• descripción de la autoridad (descripción detallada de las acciones en IS cuando se aplica la autoridad y sus consecuencias para el proceso;
• : «» ( ) « » ( ).

6

En la etapa final de preparación, debe descargar datos de los sistemas de información sobre todos los usuarios y los derechos que tienen en este momento. Dos escenarios son posibles aquí. Primero, el departamento de seguridad tiene acceso directo al sistema y tiene un medio para cargar los informes relevantes, lo cual es raro, pero muy conveniente. Segundo: enviamos una solicitud a TI para recibir informes en el formato requerido. La práctica muestra que no es posible negociar con TI y obtener los datos necesarios la primera vez. Se deben tomar varios enfoques hasta que la información se reciba en la forma y formato deseados.



Qué datos deben descargarse:

• Nombre de la cuenta
• Nombre completo del empleado a quien está asignado
• Estado (activo o bloqueado)
• Fecha de creación de cuenta
• Fecha de último uso
• Lista de derechos / grupos / roles disponibles

Entonces, recibimos descargas del sistema con todos los usuarios y con todos los derechos que se les otorgaron. E inmediatamente deje de lado todas las cuentas bloqueadas, ya que el trabajo para construir un modelo a seguir se llevará a cabo solo para usuarios activos.



Luego, si su empresa no tiene medios automatizados para cerrar el acceso a los empleados despedidos (este es a menudo el caso) o si hay una automatización de mosaicos que no siempre funciona correctamente, debe identificar todas las "almas muertas". Estamos hablando de las cuentas de los empleados ya despedidos, cuyos derechos no están bloqueados por alguna razón, deben bloquearse. Para hacer esto, comparamos los datos descargados con la fuente de personal. La descarga de personal también debe obtenerse primero de la unidad que dirige la base de personal.



Por separado, es necesario posponer las cuentas, cuyos propietarios no se encontraron en la base de personal, no se asignaron a nadie, es decir, sin propietario. Según esta lista, necesitamos la fecha del último uso: si es bastante reciente, aún tenemos que buscar a los propietarios. Esto puede incluir cuentas de contratistas externos o cuentas de servicio que no están asignadas a nadie, pero que están asociadas con cualquier proceso. Para averiguar la propiedad de las cuentas, puede enviar cartas a todos los departamentos con una solicitud de respuesta. Cuando se encuentran los propietarios, ingresamos datos sobre ellos en el sistema: de esta manera, se identifican todas las cuentas existentes y el resto se bloquea.



Tan pronto como nuestras cargas se borren de registros innecesarios y solo queden cuentas activas, puede comenzar a construir un modelo a seguir para un sistema de información específico. Pero hablaré de esto en el próximo artículo.



Autor: Lyudmila Sevastyanova, Gerente de Promoción, Solar inRights