{"id":87793,"date":"2020-07-10T13:41:57","date_gmt":"2020-07-10T11:41:57","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/stroim-rolevuyu-model-upravleniya-dostupom-chast-pervaya-podgotovitelnaya"},"modified":"2020-07-10T13:41:57","modified_gmt":"2020-07-10T11:41:57","slug":"stroim-rolevuyu-model-upravleniya-dostupom-chast-pervaya-podgotovitelnaya","status":"publish","type":"post","link":"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/stroim-rolevuyu-model-upravleniya-dostupom-chast-pervaya-podgotovitelnaya","title":{"rendered":"Construyendo un modelo de rol para la gesti\u00f3n de acceso. Parte uno: preparatoria.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Actualmente trabajo en una empresa proveedora de software, espec\u00edficamente en soluciones de gesti\u00f3n de acceso. Mi experiencia 'de una vida pasada' est\u00e1 relacionada con el lado del cliente: una gran organizaci\u00f3n financiera. En ese entonces, nuestro grupo de control de acceso en el departamento de seguridad de la informaci\u00f3n no pod\u00eda presumir de tener grandes competencias en IdM. Aprendimos mucho en el proceso y tuvimos que enfrentar numerosos desaf\u00edos para establecer un mecanismo funcional de gesti\u00f3n de derechos de usuarios en los sistemas de informaci\u00f3n de la empresa.
\n\"Construyendo
\nAl combinar mi arduo aprendizaje del lado del cliente con los conocimientos y competencias del proveedor, quiero compartir con ustedes, en esencia, una gu\u00eda paso a paso: c\u00f3mo crear un modelo de gesti\u00f3n de acceso basado en roles en una gran empresa y qu\u00e9 resultados podr\u00e1 ofrecer. Mi gu\u00eda consta de dos partes: la primera, prepar\u00e1ndonos para construir el modelo; la segunda, construy\u00e9ndolo propiamente dicho. Aqu\u00ed tienen la primera parte, la preparatoria.
\n<\/a><\/noindex>
\nN.B.<\/b> Construir un modelo de roles es, desafortunadamente, un proceso y no un resultado. M\u00e1s bien, es parte del proceso de creaci\u00f3n de un ecosistema de gesti\u00f3n de acceso en la empresa. As\u00ed que prep\u00e1rense para un juego a largo plazo.
\n<\/i>
\nPrimero, definamos: \u00bfqu\u00e9 es la gesti\u00f3n de acceso basada en roles? Supongamos que tienen un gran banco 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\u00f3n internos (objetos). Ahora multiplique el n\u00famero de objetos por el n\u00famero de sujetos; ese es el m\u00ednimo de relaciones que deben establecer inicialmente y luego controlar. \u00bfEs realmente posible hacerlo manualmente? Por supuesto que no; por eso surgieron los roles.<\/p>\n

Un rol es un conjunto de permisos necesarios para que un usuario o grupo de usuarios realice ciertas tareas laborales. Cada empleado puede tener uno o varios roles, y cada rol puede contener desde uno hasta muchos permisos que se permiten al usuario en el marco de ese rol. Los roles pueden estar vinculados a puestos espec\u00edficos, departamentos o tareas funcionales de los empleados.<\/p>\n

\"Construyendo
\n
\nLos roles generalmente se crean a partir de los poderes individuales de un empleado en cada sistema de informaci\u00f3n. Luego, de los roles de cada sistema se forman los roles de negocio globales. Por ejemplo, el rol de negocio de \u00abgerente de cr\u00e9dito\u00bb incluir\u00e1 varios roles individuales en los sistemas de informaci\u00f3n que se utilizan en la oficina del cliente del banco. Por ejemplo, en sistemas como el sistema bancario automatizado principal, el m\u00f3dulo de caja, el sistema de gesti\u00f3n documental electr\u00f3nica, el servicio de gesti\u00f3n y otros. Los roles de negocio generalmente se vinculan a la estructura organizativa \u2013en t\u00e9rminos sencillos, al conjunto de departamentos de la empresa y de los cargos en ellos. As\u00ed se forma la matriz de roles global (un ejemplo se presenta en la tabla a continuaci\u00f3n).<\/p>\n

\"Construyendo
\n
\nCabe destacar que construir un modelo de roles al 100%, asegurando todos los derechos necesarios para los empleados de cada cargo en una estructura comercial, es simplemente imposible. Y no es necesario. De hecho, el modelo de roles no puede ser est\u00e1tico, ya que depende del entorno en constante cambio. Y del cambio en la actividad empresarial de la empresa, que, por lo tanto, influye en la modificaci\u00f3n de la estructura organizativa y las funciones. Y de la falta de recursos suficientes, y del incumplimiento de las descripciones de cargo, y de la b\u00fasqueda de beneficios a expensas de la seguridad, y de muchos otros factores. Por lo tanto, se debe construir un modelo de roles que pueda satisfacer hasta el 80% de las necesidades de los usuarios en los derechos b\u00e1sicos necesarios al asumir un cargo. Los otros 20% podr\u00e1n, si es necesario, solicitarlos m\u00e1s tarde mediante solicitudes separadas.<\/p>\n

Por supuesto, puedes preguntar: \u00ab\u00bfY no existen modelos de roles al 100%?\u00bb Bueno, s\u00ed, eso ocurre, por ejemplo, en estructuras no comerciales, que no est\u00e1n sujetas a cambios frecuentes, \u2013en alg\u00fan instituto de investigaci\u00f3n. O en organizaciones de la industria de defensa con un alto nivel de seguridad, donde la seguridad es primordial. Tambi\u00e9n puede suceder en una estructura comercial, pero dentro de un departamento espec\u00edfico, cuyo trabajo es un proceso bastante est\u00e1tico y predecible.<\/p>\n

La principal ventaja de la gesti\u00f3n de roles es la simplificaci\u00f3n de la entrega de derechos, dado que el n\u00famero de roles es significativamente menor que el de los usuarios del sistema de informaci\u00f3n. Y esto es cierto para cualquier industria.<\/p>\n

Tomemos una empresa de retail: en ella trabajan miles de vendedores, pero todos tienen los mismos permisos en el sistema N, y solo se crear\u00e1 un rol para ellos. Cuando llega un nuevo vendedor a la empresa, se le asigna autom\u00e1ticamente el rol adecuado en el sistema, donde ya est\u00e1n todos los permisos necesarios. Tambi\u00e9n, con un solo clic, se pueden cambiar los derechos de miles de vendedores a la vez, por ejemplo, agregar una nueva opci\u00f3n para generar informes. No es necesario realizar mil operaciones vinculando el nuevo permiso a cada cuenta, basta con a\u00f1adir esta opci\u00f3n al rol, y aparecer\u00e1 para todos los vendedores al mismo tiempo.<\/p>\n

Otra ventaja de la gesti\u00f3n por roles es la exclusi\u00f3n de la asignaci\u00f3n de permisos incompatibles. Es decir, un empleado que tiene un rol determinado en el sistema no puede tener simult\u00e1neamente otro rol cuyos derechos no deben combinarse con los del primero. Un claro ejemplo es la prohibici\u00f3n de combinar las funciones de ingreso y control de una operaci\u00f3n financiera.<\/p>\n

Todos los interesados en saber c\u00f3mo surgi\u00f3 la gesti\u00f3n de roles de acceso pueden
\n sumergirse en un recorrido hist\u00f3rico<\/b>
\n Si miramos al pasado, la comunidad de TI reflexion\u00f3 por primera vez sobre los m\u00e9todos de gesti\u00f3n de acceso en los a\u00f1os 70 del siglo XX. Aunque las aplicaciones eran bastante simples en ese momento, al igual que ahora, todos deseaban gestionar c\u00f3modamente el acceso a ellas. Proporcionar, cambiar y controlar los derechos de los usuarios era simplemente para facilitar la comprensi\u00f3n de qu\u00e9 acceso ten\u00eda cada uno de ellos. Pero en esa \u00e9poca no exist\u00edan est\u00e1ndares comunes, se desarrollaban los primeros sistemas de gesti\u00f3n de acceso, y cada empresa se basaba en sus propias concepciones y reglas.<\/p>\n

Hoy en d\u00eda, existen muchos modelos diferentes de gesti\u00f3n de acceso, pero no aparecieron de inmediato. Nos centraremos en aquellos que han hecho una contribuci\u00f3n significativa al desarrollo de esta \u00e1rea.<\/p>\n

El primer y, probablemente, el modelo m\u00e1s sencillo es La gesti\u00f3n de acceso discrecional<\/b> (DAC \u2013 Control de acceso discrecional). Este modelo implica que todos los participantes en el proceso de acceso comparten los derechos. Cada usuario tiene acceso a objetos u operaciones espec\u00edficos. En esencia, aqu\u00ed hay m\u00faltiples sujetos de derechos que corresponden a m\u00faltiples objetos. Este modelo ha sido considerado demasiado flexible y complicado de mantener: las listas de acceso con el tiempo se vuelven enormes y dif\u00edciles de controlar.<\/p>\n

El segundo modelo es Control de acceso obligatorio (MAC \u2013 Mandatory access control)<\/b>. En este modelo, cada usuario tiene acceso a un objeto de acuerdo con la autorizaci\u00f3n a un cierto nivel de confidencialidad de los datos. En consecuencia, los objetos deben clasificarse seg\u00fan su nivel de confidencialidad. A diferencia del primer modelo flexible, este result\u00f3 ser demasiado estricto y restrictivo. Su aplicaci\u00f3n no se justifica cuando una empresa tiene numerosos recursos de informaci\u00f3n diversos: para delimitar el acceso a los diferentes recursos, ser\u00e1 necesario introducir muchas categor\u00edas que no se cruzar\u00e1n.<\/p>\n

Dada la obvia imperfecci\u00f3n de estos dos m\u00e9todos, la comunidad de TI continu\u00f3 desarrollando modelos m\u00e1s flexibles y, al mismo tiempo, m\u00e1s o menos universales para soportar diferentes tipos de pol\u00edticas organizativas de control de acceso. Y fue entonces cuando apareci\u00f3 \u00a1el tercer modelo de control de acceso basado en roles!<\/b> Este enfoque result\u00f3 ser el m\u00e1s prometedor, ya que exige no solo la autorizaci\u00f3n de la identidad del usuario, sino tambi\u00e9n sus funciones laborales en los sistemas.<\/p>\n

La primera estructura de modelo de roles claramente descrita fue propuesta por los cient\u00edficos estadounidenses David Ferraiolo y Richard Kuhn del Instituto Nacional de Est\u00e1ndares y Tecnolog\u00eda de EE. UU. en 1992. Fue entonces cuando apareci\u00f3 por primera vez el t\u00e9rmino RBAC (Control de acceso basado en roles). <\/b>Estas investigaciones y descripciones de los componentes b\u00e1sicos, as\u00ed como sus interrelaciones, sentaron las bases del est\u00e1ndar vigente hasta hoy INCITS 359-2012, aprobado por el Comit\u00e9 Internacional de Est\u00e1ndares de Tecnolog\u00eda de la Informaci\u00f3n (INCITS).<\/p>\n

El est\u00e1ndar define el rol como \"una funci\u00f3n dentro de la organizaci\u00f3n con cierta sem\u00e1ntica relacionada con los poderes y responsabilidades asignadas al usuario designado a ese rol\". El documento establece los elementos principales del RBAC: usuarios, sesiones, roles, permisos, operaciones y objetos, as\u00ed como las relaciones e interacciones entre ellos.<\/p>\n

El est\u00e1ndar proporciona la estructura m\u00ednima necesaria para construir un modelo de roles: la agrupaci\u00f3n de permisos en roles y luego la concesi\u00f3n de acceso a los usuarios a trav\u00e9s de esos roles. Se definen mecanismos para la formaci\u00f3n de roles a partir de objetos y operaciones, as\u00ed como la jerarqu\u00eda de roles y la herencia de poderes. En cualquier empresa existen roles que agrupan los poderes elementales necesarios para todos los empleados. Esto puede incluir acceso al correo electr\u00f3nico, al CMS, al portal corporativo, etc. Estos poderes pueden incluirse en un rol general llamado \"empleado\", de manera que no sea necesario enumerar todos los permisos elementales en cada uno de los roles de nivel superior repetidamente. Basta con indicar la caracter\u00edstica de herencia del rol \"empleado\".<\/p>\n

\"Construyendo
\n
\nM\u00e1s tarde, el est\u00e1ndar fue complementado con nuevos atributos de acceso relacionados con un entorno en constante cambio. Se introdujo la posibilidad de establecer restricciones est\u00e1ticas y din\u00e1micas. Las est\u00e1ticas implican la imposibilidad de combinar roles (la introducci\u00f3n y el control de operaciones mencionados anteriormente). Las restricciones din\u00e1micas pueden estar determinadas por par\u00e1metros cambiantes, como el tiempo (horas\/d\u00edas laborales\/no laborales), la ubicaci\u00f3n (oficina\/casa), etc.<\/p>\n

Es importante mencionar el control de acceso basado en atributos (ABAC \u2014 Control de acceso basado en atributos).<\/b> Este enfoque se basa en proporcionar acceso mediante reglas de uso compartido de atributos. Este modelo puede usarse de manera independiente, pero a menudo complementa activamente al cl\u00e1sico de roles: a un rol espec\u00edfico se le pueden agregar atributos de usuarios, recursos y dispositivos, as\u00ed como tambi\u00e9n del tiempo o la ubicaci\u00f3n. Esto permite utilizar menos roles, introducir restricciones adicionales y hacer que el acceso sea lo m\u00e1s m\u00ednimo posible, aumentando as\u00ed la seguridad.<\/p>\n

Por ejemplo, se puede permitir el acceso a las cuentas a un contable si trabaja en una regi\u00f3n espec\u00edfica. Entonces, la ubicaci\u00f3n del especialista se comparar\u00eda con un valor de referencia determinado. O se puede otorgar acceso a las cuentas solo si el usuario se autentica desde un dispositivo registrado como permitido. Es un buen complemento al modelo de roles, pero se utiliza raramente por la necesidad de crear muchas reglas y tablas de permisos o restricciones.<\/p>\n

Perm\u00edtanme dar un ejemplo de aplicaci\u00f3n de ABAC de mi 'vida pasada'. En nuestro banco hab\u00eda varias sucursales. Los empleados de las oficinas de clientes en estas sucursales realizaban operaciones id\u00e9nticas, pero deb\u00edan trabajar en el sistema principal solo con las cuentas de su regi\u00f3n. Al principio, comenzamos a crear roles separados para cada regi\u00f3n, y obtuvimos una gran cantidad de roles repetidos con acceso a diferentes cuentas. Luego, al usar el atributo de ubicaci\u00f3n del usuario y vincularlo a un rango espec\u00edfico de cuentas para la verificaci\u00f3n, reducimos significativamente el n\u00famero de roles en el sistema. Como resultado, quedaron roles solo para una sucursal, que se replicaron para los puestos correspondientes en todas las dem\u00e1s divisiones territoriales del banco.<\/p>\n

Ahora hablemos sobre los pasos preparatorios necesarios sin los cuales simplemente no se puede construir un modelo de roles funcional.<\/p>\n

Paso 1. Creamos el modelo funcional<\/h2>\n

\nLo primero es crear un modelo funcional: un documento de alto nivel que describa detalladamente la funcionalidad de cada departamento y cada puesto. Generalmente, la informaci\u00f3n proviene de diversos documentos: descripciones de puestos y regulaciones de los distintos departamentos: secciones, direcciones, departamentos. El modelo funcional debe ser aprobado por todos los departamentos interesados (negocios, control interno, seguridad) y ratificado por la direcci\u00f3n de la empresa. \u00bfPara qu\u00e9 sirve este documento? Para que el modelo de roles pueda referenciarlo. Por ejemplo, si se va a construir un modelo de roles basado en los derechos existentes de los empleados, los cuales fueron extra\u00eddos del sistema y \u00abunificados\u00bb. Entonces, al coordinar los roles obtenidos con el propietario del negocio, se puede hacer referencia a un punto espec\u00edfico del modelo funcional, que justifique la inclusi\u00f3n de un derecho u otro en el rol.<\/p>\n

Paso 2. Auditar los sistemas de TI y elaborar un plan de priorizaci\u00f3n<\/h2>\n

\nEn la segunda etapa, es necesario realizar una auditor\u00eda de los sistemas de TI para entender c\u00f3mo se organiza el acceso a ellos. Por ejemplo, en mi empresa financiera hab\u00eda varias centenas de sistemas de informaci\u00f3n. Todos los sistemas ten\u00edan algunos indicios de gesti\u00f3n de roles, en la mayor\u00eda hab\u00eda ciertos roles, pero eran principalmente te\u00f3ricos o estaban documentados en manuales que estaban desactualizados, y el acceso se conced\u00eda en funci\u00f3n de las solicitudes efectivas de los usuarios. Naturalmente, construir un modelo de roles en varias centenas de sistemas es pr\u00e1cticamente imposible, hay que empezar por alg\u00fan lado. Realizamos un an\u00e1lisis exhaustivo del proceso de gesti\u00f3n de accesos para determinar su nivel de madurez. Durante el an\u00e1lisis, se establecieron criterios de priorizaci\u00f3n para los sistemas de informaci\u00f3n: criticidad, disponibilidad, planes para su desactivaci\u00f3n, etc. Con ellos, organizamos la secuencia para el desarrollo\/actualizaci\u00f3n de los modelos de roles de estos sistemas. Luego, incluimos los modelos de roles en el plan de integraci\u00f3n con la soluci\u00f3n de Gesti\u00f3n de Identidades, para automatizar la gesti\u00f3n de accesos.<\/p>\n

Entonces, \u00bfc\u00f3mo se determina la criticidad de un sistema? Responda las siguientes preguntas:<\/p>\n