Hay dos formas de construir un modelo a seguir en un sistema de información.
Primer enfoque
Los roles se desarrollan en base a un modelo funcional . Este enfoque es posible cuando la organización tiene un departamento especial de tecnólogos, llamémoslo "Departamento tecnológico organizacional (OTO)". En nuestro banco, dicho departamento formaba parte del departamento de TI. El departamento traducirá las necesidades comerciales descritas en el modelo funcional al lenguaje de TI: el lenguaje de derechos / opciones / poderes que se deben proporcionar en el sistema para realizar una funcionalidad específica.
Este enfoque también es bueno cuando se pone en funcionamiento un nuevo sistema y se forman modelos a seguir desde cero. Primero, debe averiguar, junto con el gerente de TI del sistema, cómo se otorgan los derechos, si hay roles o grupos internos en el sistema. Luego, junto con los jefes de las unidades de negocio y los tecnólogos de la relatividad general, es necesario desarrollar roles, incluidos los derechos necesarios. Luego, los roles creados deben coordinarse con el propietario del sistema de la empresa , ya que es responsable de la ejecución de los procesos de negocio, con el departamento de control interno para evitar conflictos entre sistemas y con el departamento de seguridadpara que no se viole la política de seguridad aprobada de la empresa. Después de eso, el sistema puede ponerse en funcionamiento y asignarse derechos de acuerdo con el modelo a seguir aprobado.
Segundo enfoque
Los roles se forman a partir de derechos existentes ya otorgados a los empleados. En la mayoría de los casos, esto es exactamente lo que debe hacer. Los sistemas han estado en funcionamiento durante mucho tiempo y es necesario solucionar el problema de los derechos de usuario que se ha acumulado durante muchos años de funcionamiento. Aquí hay algunas peculiaridades.
Si el sistema no es muy grande y hay pocos derechos diferentes en él, entonces no es difícil identificar derechos comunes superpuestos entre los empleados del mismo puesto. A partir de ellos, puede redactar un rol y luego enviarlo para su aprobación y aprobación al jefe, al propietario del recurso y más adelante en la cadena, como en el primer caso. Si el sistema tiene muchos derechos (poderes) y es utilizado por una gran cantidad de empleados de diferentes departamentos, la tarea se vuelve más complicada. En este caso, las utilidades especializadas acuden al rescate, llamadasMinería de roles que facilitan la tarea. Recopilan los derechos correspondientes para un trabajo específico en un rol estándar que es revisado y aprobado por las partes interesadas.
Construyendo un modelo a seguir usando el segundo enfoque
En nuestra gran empresa financiera, creamos un modelo a seguir utilizando el segundo enfoque para poner orden en los sistemas que ya funcionan. Para aquellos en los que los usuarios tenían pocos derechos, tomamos una muestra autorizada (solo usuarios activos). Hemos desarrollado una plantilla para completar la matriz de roles para cada sistema: recuerde que la matriz de roles son roles (un conjunto de derechos) en relación con los departamentos de la empresa y los puestos en ellos. La plantilla se envió a los propietarios de estos sistemas para que la completaran. Estos, a su vez, recopilaron información de los departamentos en los que se utilizó el sistema y devolvieron la plantilla ya completa para una mayor coordinación con los servicios de seguridad de la información y control interno. La plantilla completa, es decir, la matriz de roles, se utiliza para otorgar acceso basado en roles, así como para su inclusión en un futuro proyecto de automatización.
Desafortunadamente, no existen tales matrices y tales sistemas en los que todos los derechos pueden dividirse sin ambigüedad en roles y los roles están vinculados a posiciones. Porque en este caso obtendrás roles bastante universales, donde algunos de los derechos serán redundantes. O, por el contrario, hay demasiados roles, y esto ya no será basado en roles, sino acceso personal basado en el método discrecional, del que escribimos en la primera parte. A menudo, en organizaciones grandes, los roles pueden no ser necesarios para un puesto, sino para una funcionalidad específica. Por ejemplo, varios empleados pueden ocupar el mismo puesto pero realizar diferentes funciones. Por lo tanto, tiene sentido agregar parte de la misma funcionalidad a los roles básicos que se asignarán por defecto. Y deje algunas de las funciones únicas del empleado para el registro de derechos para solicitudes individuales,que se envían para su aprobación de acuerdo con el procedimiento establecido por la empresa.
Plantilla de ejemplo para completar matrices de roles
Nuestra plantilla se veía así. En la primera hoja de la izquierda (verticalmente) se enumeraron las posiciones y divisiones, y en la parte superior (horizontalmente) los roles. En la intersección, era necesario establecer un marcador que indicara qué departamento necesitaba qué rol / roles. Marcamos con un relleno de color: verde: roles que deben proporcionarse de manera predeterminada, al ser nombrados para un puesto; amarillo: roles que se pueden solicitar para un puesto o departamento específico en una solicitud adicional separada.
En la segunda hoja, colocamos una guía que mostraba el cumplimiento de roles con derechos individuales (poderes).
La tercera hoja contiene una matriz de conflictos de SOD (prohibición de una posible combinación de roles).
Debo decir de inmediato que abordamos el tema de los conflictos de SOD en una primera aproximación, porque es una gran actividad separada con su propio proceso. La prohibición de la combinación de ciertos poderes puede establecerse tanto en el marco de un rol separado como entre roles y en interacciones entre sistemas. Además, es importante configurar el proceso de trabajo con los conflictos de SOD y desarrollar escenarios para responder a ellos. Este es un tema para consideración por separado.
Para sistemas con muchos usuarios y una estructura de derechos bastante diversa, es muy difícil crear una matriz manualmente. Para estos propósitos, usamos herramientas especializadas para construir un modelo a seguir. Minería de roles.... Estas herramientas pueden diferir mucho en la lógica de trabajo, el costo, la usabilidad y otras características. Pero el principio de funcionamiento y objetivos que tienen en común es recopilar información sobre los derechos actuales de un empleado en los sistemas de información, analizar la repetición de estos derechos para empleados con los mismos atributos, combinar estos derechos en roles y, en última instancia, construir un cierto modelo de rol básico que refleje el actual. estado.
Ahora, con el paso del tiempo y trabajando en una empresa que desarrolla software para control de acceso, entiendo que existen métodos más efectivos para construir modelos a seguir en grandes sistemas. Cuanto antes adopte una organización las herramientas de ordenación automatizadas, más fluido y sencillo será el proceso de construcción del modelo a seguir. En este caso, el sistema automatizado será un asistente o una ayuda en la creación de roles. La implementación de sistemas de control de acceso automatizados (IdM / IGA) debe comenzar con la conexión de fuentes de personal y sistemas de destino para cargar datos y su mapeo y análisis. Mediante el uso de herramientas especializadas integradas en las soluciones de control de acceso, puede construir de manera efectiva los procesos necesarios basados en la automatización desde el principio.Esto reducirá significativamente los costos laborales y eliminará la terapia de choque en el futuro. Por ejemplo, el proceso de trabajar con cuentas será mucho más rápido y eficiente, es decir, en la primera etapa:
- bloqueo de cuentas ilegítimas encontradas,
- identificación de cuentas huérfanas,
- identificar y registrar cuentas de empleados externos, etc.
- automatizar la creación de cuentas al contratar un empleado y bloquear las cuentas en caso de despido.
Y ya en la segunda etapa, el uso de sistemas de control de acceso automatizados permite aumentar la eficiencia del trabajo con derechos de usuario y construir un modelo a seguir, en particular:
- aplicar diferentes métodos de comparación de derechos para diferentes usuarios,
- Llevar a cabo minería de roles automatizada e identificación de derechos de coincidencia para ciertas categorías de usuarios con posterior análisis y aprobación Esto hace que sea mucho más rápido y fácil crear las matrices de derechos de acceso necesarias.
Estamos implementando una nueva regulación de derechos de acceso
Llegamos al punto en que la empresa puede empezar a vivir según la nueva normativa de control de accesos: otorgar acceso, modificar y revocar, teniendo en cuenta su nueva estructura. Qué debería estar en este reglamento:
- Los derechos de acceso están determinados por la presencia / ausencia de un modelo a seguir para un sistema de información específico. Como se mencionó anteriormente, es simplemente imposible construir matrices de roles para todos los SI a la vez, debe actuar gradualmente, de acuerdo con el plan aprobado.
- Si todavía no existe un modelo a seguir aprobado en el sistema, entonces los derechos, al menos, deben acordarse con el jefe del departamento y el propietario del recurso.
- Si el modelo a seguir se desarrolla y aprueba, los derechos se asignan / cambian en función de él.
- , .
. , , , .
. -, .
-, , , . IdM/IGA-, , . , , . , . , , . - . , .. , , . , , . . , .
El modelo a seguir no puede ser estático. Ella, como un organismo vivo, debe adaptarse a los cambios que se están produciendo en la organización. ¿Cuál es la razón para corregirlo?
El primero es un cambio en la estructura organizativa y de personal.En las grandes organizaciones, estaba convencido de esto por mi propia experiencia, tales cambios pueden ocurrir casi a diario. Los cambios suelen estar asociados con el cambio de nombre de departamentos y puestos. Al mismo tiempo, la funcionalidad sigue siendo la misma, pero, sin embargo, estos cambios deben reflejarse en el modelo a seguir y todos los ajustes deben realizarse de manera oportuna. Cuando hay una fusión de departamentos o, por el contrario, una división en grupos / departamentos separados, los cambios son más globales. Afectan la funcionalidad de los empleados, que necesita ser revisada, para actualizar el modelo funcional y, en base a él, realizar cambios en los roles existentes. O diseñar e implementar nuevos roles en el modelo a seguir.
El segundo es un cambio en los procesos comerciales de la empresa.Los negocios no pueden ser estáticos: se están introduciendo nuevos procesos y mecanismos que permiten mejorar el trabajo de cada división. Esto mejora el servicio al cliente, aumenta las ventas y ayuda a alcanzar los objetivos estratégicos. La introducción de cada nuevo proceso empresarial debe tenerse en cuenta en el modelo a seguir. Aparecerán nuevos roles, o los existentes deberán modificarse, y deberán incluir nuevas opciones y derechos.
El tercero es cambiar la arquitectura del sistema.Las empresas desmantelan periódicamente los sistemas antiguos y ponen en funcionamiento otros nuevos. Digamos que el sistema antiguo se da de baja y la funcionalidad que los empleados realizaban en él debería transferirse al nuevo sistema. Para hacer esto, deberá revisar todos los roles del sistema antiguo y su relevancia, analizar los roles creados del nuevo sistema y hacer una matriz de comparación de roles antiguos y nuevos. Es muy posible que durante algún período de transición estos roles existan en paralelo hasta que toda la funcionalidad necesaria se transfiera al nuevo sistema y se refine el modelo a seguir. Luego, puede dejar de usar los roles del sistema anterior, revocar el acceso de los usuarios y enviar los datos del sistema anterior al archivo.
Todos los cambios que hemos visto sugieren que se necesita un proceso separado para mantener actualizado el modelo a seguir. Debe tener en cuenta todas las actividades de la organización relacionadas con el acceso a los recursos de información. Debe incluir un proceso para actualizar el modelo a seguir, que se planifica con anticipación para que todos los cambios necesarios se realicen a tiempo. Se trata del inicio de una aplicación para el cambio de rol / roles en modo automático o manual, y la coordinación y aprobación de los cambios y su puesta en marcha con la actualización de los procesos relacionados. Todo esto debe quedar registrado en la normativa de mantenimiento y actualización del modelo a seguir, donde también es necesario indicar quién es el responsable de cada paso del proceso.
Además de los cambios en el modelo a seguir basados en las razones anteriores, se necesita una revisión planificada sistemática de los derechos. En particular, para las empresas financieras, los supervisores exigen tales revisiones periódicas. Las revisiones ayudan a identificar las brechas en el modelo de derechos existente y mejoran el control sobre los derechos de los usuarios. La solución a este problema se simplifica enormemente con los sistemas IGA / IdM, que permiten automatizar el proceso de revisión (recertificación) a una determinada frecuencia.
Resumamos
El control de acceso mediante un modelo basado en roles aumenta el nivel de seguridad de la información de la empresa, ya que el acceso se vuelve más transparente, gestionado y controlado. También reduce la carga sobre el departamento de TI en términos de su administración. ¿Qué se puede hacer más fácilmente con el control de acceso basado en roles?
- Podrá otorgar los mismos derechos a muchos empleados en el mismo puesto o que trabajen en el mismo departamento. Basta con darles el mismo papel.
- Puede cambiar los derechos de los empleados de un puesto rápidamente, con unos pocos clics. Es suficiente agregar o quitar derechos como parte de un rol común.
- Podrá construir una jerarquía de roles y establecer reglas para heredar la autoridad, lo que simplifica la estructura de acceso.
- Podrá ingresar a la división de autoridad (SOD), una prohibición sobre la combinación de un rol con otro.
Sin embargo, la creación de un modelo a seguir por sí solo no resuelve el problema del control de acceso eficaz y de alta calidad en una gran empresa; este es solo uno de los pasos. Si construye un modelo a seguir y se calma con él, después de un tiempo se volverá obsoleto y el gran trabajo realizado será absolutamente inútil. ¿Por qué?
- - , , - .
- - , -.
- .
- C .
- , , , .
- .
Todas estas razones indican que lo importante es el conjunto de medidas de control de acceso. Necesitamos herramientas de automatización, procesos y mecanismos de trabajo, su soporte, desarrollo, actualización y escalado de acuerdo con el ciclo de vida de la empresa.
Autor: Lyudmila Sevastyanova, Gerente de Promoción, Solar inRights