Ofertas en tecnología

Cómo convertir su Active Directory en un administrador de identidades

Altavoz inteligente Echo Dot

No es una labor simple para absolutamente nadie. cabeza de Seguridad de la Información arrancar un control de ingreso apoyado en permisos, o sea, llevar a cabo un modelo de RBAC (Control de ingreso apoyado en permisos). Las adversidades para poder este audaz propósito no se limitan a la dificultad del propio modelo, y acaban pasando por el tema de la Administración de Elementos Humanos.

En un planeta ideal, todas y cada una de las funcionalidades y responsabilidades de la compañía están realmente bien establecidas y documentadas. Cada uno de ellos sabe precisamente qué llevar a cabo, qué aguardar de sus colegas y qué aguardan sus colegas de él, por el hecho de que los límites y las interfaces de los procesos son claros. Todos y cada uno de los packs de permisos y responsabilidades se asignan a puestos concretos, tal es así que Seguridad de la información logre predecir todas y cada una de las pretensiones de ingreso de los usados y asegurar que todos tengan solo el ingreso fundamental para efectuar su trabajo.

Pese a haber enviado ahora plan de estudios múltiples ocasiones al planeta ideal, jamás me llamaron para una entrevista, con lo que siempre y en todo momento termino haciendo un trabajo en el planeta real. En él, los permisos y responsabilidades no están bien establecidos, y bastante menos documentados. En la mayoría de los casos, disponemos múltiples personas que efectúan distintas permisos en permisos idénticos y personas que hacen lo mismo en distintas permisos.

Aun de esta manera, es viable dibujar un Pareto de este inconveniente y mapear debido ingreso, apoyado en las situaciones, para cerca del 80% de la compañía. Lo que requerimos es un modelo RBAC que maneje bien el 20% sobrante, tal como una solución fácil para hacer de manera automática el ingreso a todo cuanto resulte posible mapear.

Lo que presento ahora es un modelo razonablemente simple de llevar a cabo que usa una característica que prácticamente todas las compañías tienen: un AD. El término se aplica a cualquier solución LDAP o aun a una banco de información relacional, pero como AD ahora tiende a estar libre y escala bien, en tanto que es un sistema distribuido, me semeja una aceptable opción.

Hay unos procedimientos que se deben llevar a cabo para montar esta composición, que necesitan un óptimo conocimiento de la teoría de conjuntos y un óptimo programador.

El primero es detallar una sincronización día tras día de datos de su sistema de RRHH con AD, trayendo a este todos y cada uno de los atributos no privados de los usados, como centro de valor, departamento, puesto, nivel jerárquico, compañía del conjunto al que forma parte. , oficina donde está y enlazada a la compañía. Unas escasas líneas de VBScript o Powershell resuelven este inconveniente.

El segundo paso es construir conjuntos basados ​​en estos atributos. Estos conjuntos corresponden a los Permisos del usuario que podemos encontrar en las resoluciones IDM del mercado, puesto que se usa para agrupar clientes por criterios funcionales. Los integrantes de estos conjuntos tienen que actualizarse todos los días, siguiendo la actualización de los atributos de AD. Ciertos ejemplos de estos conjuntos:

[IDM USER CC 1001] – Ayudantes con atributo departamentoNúmero vale 1001 y en consecuencia forma parte a este centro de valor
[IDM USER CC 1002] – Ayudantes con atributo departamentoNúmero vale 1002 y por ende forma parte a este centro de valor
[IDM USER NIVEL GERENTE] – Usados con nivel gerencial
[IDM USER NIVEL COLABORADOR] – Ayudantes a nivel de analista
[IDM USER VINCULO FUNCIONARIO] – Usados
[IDM USER VINCULO TERCEIRO] – La tercera
[IDM USER TODOS] – Todos y cada uno de los usados de la compañía.

El tercer paso es hacer conjuntos para las apps cuyo ingreso quiere supervisar. Para cada app y cada perfil de ingreso se precisan tres conjuntos diferentes que corresponderían a la permisos de app de resoluciones IDM. El primero es el conjunto UNO MISMO, designado a los accesos que debe recibir de forma automática el usado en función de sus atributos en RRHH. El segundo sería el conjunto. MANUAL, premeditados a accesos auxiliares, concedidos con alguna autorización formal. El tercero sería el conjunto. BLOQUEAR, designado a los accesos que han de ser denegados más allá de que los atributos de HR señalan que han de ser concedidos. Para una app falsa llamada XPTOcon concretes de USUARIO y ADMINISTRADORtendríamos los próximos conjuntos:

[IDM APPL AUTO XPTO ADMIN]
[IDM APPL MANUAL XPTO ADMIN]
[IDM APPL BLOQUEIO XPTO ADMIN]
[IDM APPL AUTO XPTO USUARIOS]
[IDM APPL MANUAL XPTO USUARIOS]
[IDM APPL BLOQUEIO XPTO USUARIOS]

El cuarto paso es vincular personas a apps, incluidos conjuntos de clientes (USUARIO IDM…) en conjuntos de apps de ingreso automático (AUTO APPL IDM), introduciendo personas y conjuntos de clientes en conjuntos de bloqueo (BLOCK APPL IDM) y solo personas en conjuntos de ingreso manual (MANUAL APPL IDM). El esquema se ve de este modo:

La última parte del puzzles es de qué manera calcular quién debería poder ingresar al recurso esperado. La lógica general es buscar recursivamente personas en el conjunto AUTO, MANUAL y BLOQUEO y ofrecer ingreso a personas que se muestran en AUTO o MANUAL y al tiempo no se muestran en BLOQUEO.

conjuntos1

Imagine el próximo ámbito: app XPTO con concretes de USUARIO y ADMINISTRADOR. Todos y cada uno de los usados de la compañía tienen que poder ingresar salvo terceros. Los usados del centro de coste 1234 han de ser gestores de apps. Además de esto, el usado Ticiano Benetti debe poder ingresar de gestor por el hecho de que hace una pasantía en el área del centro de valor 1234. El usado João Absolutamente nadie, pese a ser del centro de valor 1234, no ha de ser gestor, puesto que está asignado por un tiempo a un emprendimiento especifico.

Este ámbito, con salvedades para todos y cada uno de los lados, comunmente es bien difícil de ensamblar en un RBAC, pero en el modelo propuesto es muy deducible y se ve de esta forma:

ejemplo_roles

Este modelo me semeja suficientemente robusto, en tanto que los conjuntos de tipo AUTO abordan el 80% en el que se puede utilizar RBAC; los conjuntos de tipo MANUAL y BLOCK se usan para llevar a cabo salvedades y realizar el 20% que precisa accesos fuera de lo que seleccionaría RBAC puro; y cualquier petición de ingreso efectuada al grupo operativo de seguridad es simple de contestar, usando solo los conjuntos MANUAL y BLOQUEO.

Quizás la mayor virtud de este modelo es la exención de la revisión de ingreso. Para los sistemas integrados en este modelo, solo requerimos comprobar los accesos contenidos en los conjuntos MANUAL y BLOQUEO. Esto quiere decir remover el 80% de los costos en general del oficial de seguridad al producir reportes de ingreso y mensajear con los gestores y dueños del sistema, quién sostiene y quién pierde un perfil.

Evidentemente, aún faltan los complementos para vincular este cálculo de ingreso a los propios sistemas y el esquema de reacción rápida a las contrataciones y despidos. Pero estos son inconvenientes profesionales, bastante menos complejos de solucionar que la arquitectura de ingreso para aguantar salvedades. He estado haciendo un trabajo en este modelo a lo largo de cierto tiempo y me ha ayudado bastante. Quisiera que te asista.

Saludos y hasta el próximo articulo!

Producto anunciado inicialmente en el Blog Ticiano Benetti

Tommy Banks
Estaremos encantados de escuchar lo que piensas

Deje una respuesta

TecnoBreak | Ofertas y Reviews
Logo
Enable registration in settings - general
Shopping cart