Diferencias

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

--- manual_del_capacitador_de_integrabilidad [2013/04/10 18:14]
127.0.0.1 [Determinación de los componentes claves del modelo:]
+++ manual_del_capacitador_de_integrabilidad [2019/10/22 13:55] (actual)
@@ Línea 1449: / Línea 1449: @@
 J .D.Warnier planteó la necesidad de simplificar las múltiples relaciones bilaterales entre clientes y proveedores que generan múltiples relaciones entre las distintas bases de datos, por relaciones multilaterales que simplifican y hacen viable el modelo, introduciendo el concepto de una entidad de vinculación, centralización y administración del flujo de información.
+{{ :wiki:relacionesclientesproveedorescoordinador.jpg?nolink&300 |}}
 \\
 ===== El comercio globalizado=====
@@ Línea 1456: / Línea 1456: @@
 Por otra parte, y sin evidencia registrada de haberse tenido en cuenta los trabajos que J.D. Warnier de los 70’s , el mundo comercial en su proceso de globalización guiado en Europa por la European Article Number (EAN) y por otra parte en Estados Unidos por la Uniform Commercial Code (UCC), organizaciones que terminaron confluyendo y fusionándose en la Global Standard conocida como (GS1), llegaron a las mismas conclusiones estructurales en el modelo que se utiliza hoy en día para poder soportar todo el comercio global y su logística, o sea las mismas clases de registro A, B, y C.
+{{ :wiki:componentesmodelocomercialglobal.jpg?nolink |}}
 \\
 La organización GS1 materializa la implementación de los acuerdos multilaterales del modelo de J.D.Warnier administrando los Componentes Clase A, ya que todos los actores deben estar registrados unívocamente a nivel global con **Componentes Clase A = GLN**. Por otra parte todos los productos deben estar definidos por un **GTIN = Componentes Clase B**, donde se reservan rangos de códigos de identificación de productos que están subordinados a cada GLN y finalmente los envíos logísticos o mensajes, **Componentes Clase C = SSCC ** que identifica unívocamente a cada paquete o palet de envío y cuya administración corre por entera cuenta de los actores involucrados en la cadena de valor.
@@ Línea 1467: / Línea 1467: @@
 Si analizamos los casos considerados por la Comisión Europea como modelo de referencia y de buenas prácticas de infraestructura de e- government, podremos observar que muchos han desarrollado modelos de integración que implementan el esquema de relaciones multilaterales, entre otros podemos mencionar el **Crossroads Bank ** de Bélgica o el **X-Road ** de Estonia. El siguiente análisis lo haremos sobre el modelo X-Road dada su simpleza conceptual lo que ayudará a visualizar rápidamente los conceptos buscados sobre Integrabilidad.
+{{ :wiki:xroads.jpg?nolink |}}
 \\
 Amén de los detalles técnicos de la plataforma X-Road desarrollada en Estonia para integrar y compartir datos de organismos públicos y el sector privado, podemos volver a identificar claramente las zonas, módulos o sistemas encargados de soportar a cada uno de esa clase de Componentes A, B y C.
+{{ :wiki:xroadscomponentes.jpg?nolink |}}
 En este caso podemos señalar que:
@@ Línea 1483: / Línea 1484: @@
 Es importante remarcar que a diferencia de los Componentes clase C identificados por J.D.Warnier que es a nivel detallado de todas los mensajes entre cliente y proveedor, los Componentes clase C soportados por el modelo de Estonia son solamente los que generan relaciones cliente-proveedor entre los sistemas de los mismos organismos del estado. Entonces podemos decir que existen otros Componentes clase C correspondientes a las relaciones entre los usuarios y los procesos internos de los propios organismos. También se observa el propio centro de administración del X-Road que se encarga de materializar un modelo de servicios con relaciones multilaterales. Este rol es independiente y no puede ser ejecutado por ninguno de los otros organismos que operan en el modelo.
+{{ :wiki:xroadsrelacionesmultilaterales.jpg?nolink |}}
 Pero el caso de Estonia va más lejos y resuelve el problema de la calidad de los datos y la transparencia de la información al ciudadano.
@@ Línea 1525: / 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 1612: / 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 1637: / 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 1644: / Línea 1640: @@
 Ej. Sistema Unix. Distribuido, flexible.
+{{ :wiki:controlaccesodac.jpg?nolink&300 |}}
 **Separación de Deberes SSD/DSD**
@@ Línea 1649: / 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 1659: / 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 1664: / Línea 1664: @@
 Se generaliza RBAC, permitiendo asignar varias propiedades.
+{{ :wiki:controlaccesoabac.jpg?nolink&300 |}}
 **LRBAC/HRBAC **
@@ Línea 1679: / 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 1685: / 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 1710: / 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 1717: / 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 1722: / Línea 1726: @@
   * Integrabilidad exige que todos los sistemas se subordinen a un servidor de Autenticación externo.
-\\
+{{ :wiki:integrabilidadmabacrelaciones.jpg?nolink |}}
 \\
@@ Línea 1730: / 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 1771: / 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 1802: / 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 1826: / 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 1848: / Línea 1863: @@
 . algo que tengo = **celular**
+{{ :wiki:autenticacionoob.jpg?nolink&300 |}}
 \\
 ===== Flexibilidad entre la seguridad y la usabilidad =====
@@ Línea 1859: / 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 1876: / 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 1909: / 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 1927: / 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 1939: / 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 1953: / Línea 1972: @@
 Coordinador MABAC.
+{{ :wiki:autenticacionjossoymabac.jpg?nolink |}}
 \\
 ====== Referencias ======

Integrabilidad

Herramientas de usuario

Herramientas del sitio

Diferencias

Herramientas de la página