Diferencias

Muestra las diferencias entre dos versiones de la página.

--- manual_del_capacitador_de_integrabilidad [2013/04/10 18:30]
127.0.0.1 [Buenas Prácticas de e-government]
+++ manual_del_capacitador_de_integrabilidad [2019/10/22 13:55] (actual)
@@ Línea 1527: / Línea 1527: @@
 El tema de la calidad de datos y el de transparencia requiere disponer de la capacidad para poder integrar en un sólo front-end la información proveniente de múltiples sistemas. A este tipo de Componentes de integración “virtual” los llamaremos Componentes Clase D.
+{{ :wiki:xroadscomponentestransparencia.jpg?nolink |}}
 \\
 Hace 100 años en el apogeo del desarrollo rural, era común el desarrollo autosuficiente donde integradamente se atendían todas las necesidades. Aquí el concepto es INTEGRADO, AUTOSUFICIENTE pero al mismo tiempo aISLAdo. En la actualidad el desarrollo Urbano, es totalmente dependiente de la infraestructura de servicios de todo tipo y por ello necesariamente INTEGRABLE.
+{{ :wiki:evolucionmundofisico.jpg?nolink&300 |}}
 En el mundo material es posible integrar productos de distintos proveedores y conectar cañerías de distintas tecnologías, viejas y nuevas para lograr que los servicios sean prestados. Lo paradójico es que el en mundo virtual donde parece que todo es posible, aplicaciones de distintos proveedores permanecen aun hoy en día aisladas y se insiste en que la única solución es volver a desarrollar todo en nuevas soluciones más integradas que no son otra cosa que islas más grandes. La otra paradoja es que si bien lo que está dentro de su alcance lo integran muy bien, lo que no cubren queda totalmente fuera de posibilidad de ser tratado e integrado.
-\\
 Otro ejemplo de la falta de Integrabilidad es que tanto las capas funcionales como las bases de datos y las aplicaciones, sus Workflows e interfaces web para el usuario, sólo están siendo utilizadas dentro de cada uno de los propios productos o sistemas isla, pero poco se las aplica para, realmente, dar Integrabilidad a las aplicaciones entre sí, posibilitando un modelo de Integrabilidad en el que los productos se complementen verticalmente y compitan horizontalmente.
+{{ :wiki:evolucionmundodigital.jpg?nolink |}}
 Este modelo de integrabilidad le brinda al usuario un sistema como “un todo” además de otras características como la flexibilidad y robustez tan necesaria cuando de “sistemas urbanos” estamos hablando.
 Este modelo de integrabilidad se puede presentar también a mayor detalle, logrando vincular 3 capas fundamentales como son los procesos, las aplicaciones y los datos.
 En este nivel de integrabilidad un proceso puede combinar y reutilizar transacciones de distintas aplicaciones las cuales son expuestas en las actividades del workflow mediante la utilización de servicios web transaccionales. Es así que una actividad del proceso puede estar involucrando varias transacciones soportadas por varias aplicaciones. Estas aplicaciones estarían interactuando con una o varias bases de datos, locales o remotas.
+El usuario opera un solo front-end, el que a su vez está interactuando con varias aplicaciones y varias bases de datos.
-El usuario opera un solo front-end, el que a su vez está interactuando
+{{ :wiki:modelodecapaskenorr.jpg?nolink |}}
-con varias aplicaciones y varias bases de datos.
 \\
 **Conclusiones:**
@@ Línea 1614: / Línea 1608: @@
   * Para el usuario se presentan actividades dentro de un Workflow donde utiliza de manera transparente múltiples aplicaciones.
+{{ :wiki:nivelesdeintegrabilidad.jpg?nolink |}}
 \\
 ====== Anexo: White Paper MABAC (Multi Level Attribute Based Access Control) ======
@@ Línea 1639: / Línea 1633: @@
 El administrador define quien está autorizado a operar un recurso, es un modelo Centralizado, rígido y no integrable.
+{{ :wiki:controlaccesomac.jpg?nolink&300 |}}
 \\
 **Discretionary Access Control (DAC) **
@@ Línea 1646: / Línea 1640: @@
 Ej. Sistema Unix. Distribuido, flexible.
+{{ :wiki:controlaccesodac.jpg?nolink&300 |}}
 **Separación de Deberes SSD/DSD**
@@ Línea 1651: / Línea 1646: @@
 Se mantiene distribuido, pero existen políticas que previenen a un usuario de actividades incompatibles. Permite reglas por Defecto.
+{{ :wiki:controlaccesossdydsd.jpg?nolink&300 |}}
 **Identity Based Access Control (IBAC) **
-Los perm isos se asocian a un usuario en particular
+Los permisos se asocian a un usuario en particular
+{{ :wiki:controlaccesoibac.jpg?nolink&300 |}}
 **Role Based Access Control (RBAC) **
@@ Línea 1661: / Línea 1658: @@
 Se separa la asignación,tanto a lo recursos como los usuarios se le asigna una propiedad (Ej . Rol).
+{{ :wiki:controlaccesorbac.jpg?nolink&300 |}}
 **Attribute Based Access Control (ABAC) **
@@ Línea 1666: / Línea 1664: @@
 Se generaliza RBAC, permitiendo asignar varias propiedades.
+{{ :wiki:controlaccesoabac.jpg?nolink&300 |}}
 **LRBAC/HRBAC **
@@ Línea 1681: / Línea 1680: @@
 Permite utilizar por ejemplo <= nivel1 o > director etc.
+{{ :wiki:controlaccesolrbacyhrbac.jpg?nolink&300 |}}
 **Multi Level Attribute Based Access Control (MABAC)**
@@ Línea 1687: / Línea 1687: @@
 Generaliza ABAC, permitiendo agrupaciones de recursos, además de usuarios.
+{{ :wiki:controlaccesomabac.jpg?nolink |}}
 \\
 **Recursos ** Una instancia de proceso puede asignar dinámicamente un recurso
+{{ :wiki:controlaccesomabacrecursos.jpg?nolink |}}
 \\
 **Usuarios ** Una sesión puede asignar dinámicamente a un usuario
+{{ :wiki:controlaccesomabacusuarios.jpg?nolink |}}
 \\
 **Conclusiones sobre los modelos**
@@ Línea 1712: / Línea 1712: @@
 MABAC se implementa en el Servidor Coordinador del Modelo de Integrabilidad.
+{{ :wiki:integrabilidadmabac.jpg?nolink |}}
 \\
 ===== Multi Level Attribute Based Access Control (MABAC) =====
@@ Línea 1719: / Línea 1720: @@
 externos a la organización, en grandes cantidades y donde la autorización de los mismos está subordinada a diferentes fuentes auténticas.
+{{ :wiki:inegrabilidadmabaccapas.jpg?nolink |}}
 \\
 El primer paso es separar Autenticación de Autorización, y es uno de los requisitos que debe cumplir todo sistema que pretenda operar en un modelo de Integrabilidad:
@@ Línea 1724: / Línea 1726: @@
   * Integrabilidad exige que todos los sistemas se subordinen a un servidor de Autenticación externo.
-\\
+{{ :wiki:integrabilidadmabacrelaciones.jpg?nolink |}}
 \\
@@ Línea 1732: / Línea 1734: @@
 **SUJETO - ATRIBUTOS DEL USUARIO: ** el modelo MABAC utiliza distintos atributos para representar los agrupamientos más comunes que se utilizan emplean en las organizaciones:
+{{ :wiki:integrabilidadmabacatributospersonas.jpg?nolink&300 |}}
 \\
 **AUTORIZACION de Usuarios EXTERNOS**
@@ Línea 1773: / Línea 1776: @@
 \\
 ===== MABAC (Sujeto – Atributos – Recursos)=====
+{{ :wiki:integrabilidadmabaccomponents.jpg?nolink |}}
 A continuación puede verse como se definen los atributos del usuario que permiten representar el organigrama de puestos, Comités, Grupos, Equipos.
+{{ :wiki:integrabilidadmabacatributosusuario.jpg?nolink |}}
 \\
 **Recursos de CONTROL: (canal de eventos) **
+{{ :wiki:integrabilidadmabacatributoscontrol.jpg?nolink |}}
 \\
 **Recursos de INFORMACION: (canal de información) **
+{{ :wiki:integrabilidadmabacatributosanalisis.jpg?nolink |}}
 **Recursos de FUNCIONES: (canal de interacción) **
+{{ :wiki:integrabilidadmabacatributosfunciones.jpg?nolink |}}
 \\
 **Recursos de PROCESOS: (canal de procesos) **
+{{ :wiki:integrabilidadmabacatributosprocesos.jpg?nolink |}}
 En resumen el modelo MABAC está diseñado para soportar la AUTORIZACIÓN de USUARIOS, con los atributos propios de las organizaciones, con respecto a RECURSOS de información, cubriendo los distintos perfiles funcionales que brindan los sistemas informáticos.
@@ Línea 1804: / Línea 1814: @@
   * Servicios de generación de Tickes del usuario que son utilizados en el protocolo de comunicación entre los servidores (actores).
+{{ :wiki:autenticacionldap.jpg?nolink |}}
 La seguridad de acceso del Modelo de Integrabilidad sigue atentamente las tendencias en materia de seguridad que utilizan las entidades bancarias. Estas instituciones financieras basan su estratégica
@@ Línea 1828: / Línea 1840: @@
 Una lista parcial por ejemplo:
+{{ :wiki:autenticacionmultifactor.jpg?nolink |}}
 \\
 La utilización de estos mecanismos multifactor agregan complicaciones y molestias en la operación y deben ser analizadas tanto desde el punto de vista de la seguridad como desde la usabilidad.
@@ Línea 1850: / Línea 1863: @@
 . algo que tengo = **celular**
+{{ :wiki:autenticacionoob.jpg?nolink&300 |}}
 \\
 ===== Flexibilidad entre la seguridad y la usabilidad =====
@@ Línea 1861: / Línea 1874: @@
   * Punto de vista del Servicio: el coordinador define si el servicio requiere 1 o 2 factores.
-\\
 La combinación dinámica de ambas perspectivas genera la flexibilidad necesaria.
+{{ :wiki:autenticaciondecisionusuario.jpg?nolink |}}
 \\
 ===== Autenticación del usuario por dos factores (Servicios SMS) =====
@@ Línea 1878: / Línea 1890: @@
 . algo que tengo = **celular**
+{{ :wiki:autenticacionsms.jpg?nolink&300 |}}
 \\
 Autorización del usuario operador (Servicios SMS)
+{{ :wiki:autenticacionsmsautorizacion.jpg?nolink&300 |}}
 \\
 Flexibilidad entre seguridad y usabilidad
+{{ :wiki:autenticacionsmsusuarioservicio.jpg?nolink |}}
 \\
@@ Línea 1911: / Línea 1926: @@
 Hay dos artículos que requieren especial tratamiento para ser atendidos y requieren el trabajo interrelacionado de al menos tres actores del Modelo de Integrabilidad; Servidor Autenticador; Servidor Coordinador y la Persona Involucrada.
+{{ :wiki:leycoordinadormultilateral.jpg?nolink |}}
 Estos artículos especiales son:
-\\
 **//Artículo 5° - Consentimiento // **
+{{ :wiki:leyart5consentimiento.jpg?nolink&300 |}}
 **//Artículo 11° - Cesión // **
+{{ :wiki:leyart11cesion.jpg?nolink&300 |}}
 \\
 Como puede observarse de la letra de la ley, se requiere de una acción (dar consentimiento registrable) por parte de la persona involucrada, como hecho previo a la exposición de los datos.
@@ Línea 1929: / Línea 1945: @@
 Repasemos por un momento el modelo de autenticación por 2 factores
-\\
+{{ :wiki:autenticacionoobcompleta.jpg?nolink&300 |}}
 El operador del sistema (mesa de entrada) realizó esta operación de autenticación sobre el Servidor Autenticador, y esto le da derechos para acceder a determinados recursos de información entre los que se
@@ Línea 1941: / Línea 1957: @@
   * registrar en los registros de auditoría con sellado de tiempo, **Trusted timestamping**, la decisión sobre el consentimiento solicitado.
+{{ :wiki:autorizacionoobconsentimiento.jpg?nolink&300 |}}
 \\
 De esta manera el servidor coordinador se convierte en la fuente auténtica del registro de los consentimientos otorgados por las personas para el acceso a su información personal.
@@ Línea 1955: / Línea 1972: @@
 Coordinador MABAC.
+{{ :wiki:autenticacionjossoymabac.jpg?nolink |}}
 \\
 ====== Referencias ======

Integrabilidad

Herramientas de usuario

Herramientas del sitio

Diferencias

Herramientas de la página