Diferencia entre revisiones de «SIU-Arai/Arquitectura»

De SIU
Saltar a: navegación, buscar
m
(mejoras doc seguridad)
 
(No se muestran 6 ediciones intermedias del mismo usuario)
Línea 7: Línea 7:
 
[[Archivo:Arquitectura.png|centro|sinmarco|1000x1000px]]
 
[[Archivo:Arquitectura.png|centro|sinmarco|1000x1000px]]
 
==Definición de los componentes ==
 
==Definición de los componentes ==
Existen dos componentes que son vitales para el funcionamiento de la plataforma.
+
Existen tres componentes que son vitales para el funcionamiento de la plataforma.
*Arai-Registry: Repositorio central de servicios y aplicaciones
+
*[[SIU-Arai/registry|Arai-Registry]]: Registro de aplicaciones y servicios
*Arai-Usuarios: Proveedor y Administrador de Identidad (término del [[wikipedia:Identity_provider|IdP]] e [[wikipedia:Identity_management_system|IdM]]) para toda la plataforma.  Destaca la provisión del servicio de ingreso único ([https://es.wikipedia.org/wiki/Single_Sign-On Single Sign On])
+
*[[SIU-Arai/usuarios|Arai-Usuarios]]: Proveedor y Administrador de Identidad (término del [[wikipedia:Identity_provider|IdP]] e [[wikipedia:Identity_management_system|IdM]]) para toda la plataforma.  Destaca la provisión del servicio de ingreso único ([https://es.wikipedia.org/wiki/Single_Sign-On Single Sign On])
 +
*[[SIU-Arai/arai-cli|Arai-Cli]]: Librería de cliente de la plataforma, que provee de servicios de bajo nivel facilitando la integración de los componentes
  
 
A partir de allí, es posible encontrarse con otros módulos que la complementan.
 
A partir de allí, es posible encontrarse con otros módulos que la complementan.
* SIU-Huarpe: es el portal de la plataforma, punto de acceso único para los usuarios y concentrador de diversos servicios ofrecidos
+
* [[SIU-Arai/huarpe|SIU-Huarpe]]: es el portal de la plataforma, punto de acceso único para los usuarios y concentrador de diversos servicios ofrecidos
 
* SIU-XXX: toda aplicación del SIU capaz de ser integrada a la plataforma, conocido aquí como módulo.  
 
* SIU-XXX: toda aplicación del SIU capaz de ser integrada a la plataforma, conocido aquí como módulo.  
  
También pueden ir apareciendo en escena futuros módulos o componentes que ofrezcan servicios puntuales.  La plataforma es totalmente flexible en este punto. En todos los casos, los servicios ofrecidos han de implementar protocolos de comunicación basados en el estándar [https://es.wikipedia.org/wiki/Transferencia_de_Estado_Representacional REST]. Esto es lo que permite lograr el despliegue de una arquitectura basada en servicios ([[wikipedia:Service-oriented_architecture|Service Oriented Architecture]]).
+
También pueden ir apareciendo en escena futuros módulos o componentes que ofrezcan servicios puntuales.  La plataforma es totalmente flexible en este punto. En todos los casos, los servicios ofrecidos han de implementar protocolos de comunicación basados en el estándar [https://es.wikipedia.org/wiki/Transferencia_de_Estado_Representacional REST]. Esto es lo que permite lograr el despliegue de una arquitectura basada en servicios ([[wikipedia:Service-oriented_architecture|Service Oriented Architecture]]).
  
==Configuración de dependencias y Servicios ==
+
==Despliegue de la plataforma ==
La plataforma cuenta con ARAI-Registry como  un componente dedicado al manejo del catálogo de dependencias y servicios, así como su configuración. Tomemos como ejemplo la comunicación entre dos módulos, X e Y. Para que esto suceda,  se tiene que resolver una serie de requerimientos como ser la autenticación, la ruta de acceso, entre otros. Se establece que el '''Módulo Y''' ya se encuentra registrado previamente a la plataforma.  
+
La plataforma posee diversos componentes que se deben resguardar y/o facilitar su acceso dependiendo del público objetivo. No tener en cuenta esto puede comprometer la integridad de todos los componentes, módulos y servicios involucrados.
  
[[Archivo:Registry-figura-1.png|no|miniaturadeimagen|612x612px]]
+
El esquema de despliegue recomendado para la plataforma es el que muestra en la siguiente figura[[Archivo:Seguridad-plataforma.png|no|miniaturadeimagen|723x723px|El esquema de despliegue recomendado para la plataforma]]
  
Para lograr esta tarea, por medio de la librería arai-cli cada sistema desarrollado por el SIU cuenta con una serie de comandos de consola que permiten registrar un módulo a la plataforma SIU-Araí.  El primero es '''registry:add''' y lo que realiza es el registro del módulo en el catálogo de servicios de ARAI-Registry.  Al registrar, el módulo indica si se trata de:
+
En el proceso de despliegue de los componentes y servicios, se han de tener en consideración los siguientes factores:
* una aplicación
+
# El portal '''SIU-Huarpe''' es de acceso público, lo pueden utilizar los usuarios desde cualquier origen (se recomienda brindar el acceso desde internet sin restricciones)
* si provee o consume un servicio (como de SSO),
+
# El portal '''SIU-Huarpe''' puede requerir el acceso de las ''API'' de los módulos registrados en la plataforma, pero dichas ''API'' no deben en principio estar disponibles desde mas allá del portal
* si provee y/o consume una API tipo rest
+
# El ''IdP'' (componente parte de '''SIU-Araí: Usuarios''') es el que provee el formulario de autenticación, por lo tanto debe ser de acceso público (con '''FQDN''' propio)
En los casos que sea necesario, el módulo indica también su punto de acceso (conocido como endpoint), así como las credenciales que posee o con las cuales desea consumir algo. <blockquote>Nota: el comando '''registry:add''' sólo se ejecuta la primera vez. Luego se utiliza un comando distinto para mantener sincronizado los datos.</blockquote>
+
# Tanto el ''IdM'' (parte de '''SIU-Araí: Usuarios''') como los módulos '''SIU-XXX''' deben ser accesibles desde la red interna de la institución, pero no de forma pública
[[Archivo:Registry-figura-2.png|no|miniaturadeimagen|732x732px]]
+
# El componente '''SIU-Araí: Registry''' es un componente exclusivo para sincronización de la plataforma y NO DEBE ser expuesto a conexiones fuera de la red de aplicaciones y módulos
  
Una vez ''registrado'' el módulo, se procede a su sincronización con el catálogo de servicios en ARAI-Registry. Para ello se ejecuta otro comando, '''registry:sync''', que se encarga de tomar las definiciones del módulo y procesarlas (si ofrece servicios, informarle sobre posibles consumidores; si los consume, informarle de los puntos de acceso y mecanismos de autenticación, etc). <blockquote>Nota: siempre que los datos de acceso del módulo cambien, se incorporen nuevos proveedores o consumidores, se ha de ejecutar la sincronización para actualizar los datos. ARAI-Registry ''de ninguna forma enviará esta información'' de manera pro-activa, como en el caso del ejemplo para informar al '''Módulo Y'''.</blockquote>[[Archivo:Registry-figura-3.png|no|miniaturadeimagen|732x732px]]
+
==Seguridad de la plataforma ==
 +
 +
'''SIU-Araí''' es concebida como un conjunto de componentes, que trabajando de forma mancomunada, conforman el camino hacia una Arquitectura Orientada a Servicios o [[wikipedia:Service-oriented_architecture|SOA]]. Bajo este esquema, los servicios deben ser de bajo acoplamiento, autónomos, reusables, homogéneos, etc. Para lograr estos y otros factores, '''SIU-Araí''' establece ciertas pautas o mecanismos de trabajo:    
  
A partir de este punto el '''Módulo X''' es capaz de conectarse de forma directa al '''Módulo Y''' para consumir sus recursos (por ej, una API rest). En tal caso, las credenciales del cliente serán conocidas para el servidor, lo que validará el intento de acceso a dicho recurso.<blockquote>Nota: este ejemplo supone que '''Módulo Y''' ya se registró al catálogo de servicios de ARAI-Registry como proveedor de una API rest. También supone que se ejecutó una sincronización en '''Módulo Y''' luego de haberse sincronizado el '''Módulo X'''.</blockquote>
+
* Protección en descubirimiento y configuración de servicios mediante encriptación de datos 
[[Archivo:Registry-figura-4.png|no|miniaturadeimagen|602x602px]]
+
* Protección en la transmisión de los datos mediante encriptación con el uso obligado de HTTPS 
 +
* Protección en la autenticación con el intercambio entre el ''IdP'' y un ''SP'' mediante encriptación de token 
  
El catálogo de servicios ARAI-Registry, como se explicó hasta ahora, no se entromete en la comunicación directa entre los módulos de la plataforma. Simplemente brinda un mecanismo de descubrimiento y configuración de servicios. Toda la comunicación posterior entre módulos, pasa de forma  desapercibida para el resto la plataforma.
+
=== Descubrimiento y configuración de servicios ===
 +
En la plataforma '''SIU-Araí''', el componente '''Registry''' es el responsable de mantener la información de que servicios son ofrecidos y por quienes son consumidos. Esta información es almacenada de forma central, por lo que se ha tomado una serie de recaudos para evitar poner en riesgo la plataforma si se llega a comprometer dicho catálogo central. 
 +
 
 +
* cada módulo y componente de la plataforma se le pueden generar claves de encriptación basadas en la librería de encriptación [https://libsodium.org Sodium] (conocidas también como ''clave para encriptar la sincronización de api REST con Araí'' )
 +
* al realizar una acción de sincronización desde un módulo/componente hacia '''Registry''':
 +
*# ambos cliente/servidor de una API, publican un hash público derivado de la clave de encriptación que queda registrado en el catálogo central
 +
*# si un módulo consume una API y tiene sus datos de acceso como clave, es encriptada antes de ser transmitida
 +
*# si un módulo ofrece una API, obtiene la lista de clientes de dicha API y con su clave desencripta la clave ofuscada del cliente  y la registra localmente para a futuro autenticar el acceso del cliente
 +
 
 +
Para mayores detalles, así como una guía detallada de como instalar ''Sodium'', puede ver esta  [[IT/Sodium|guía de implementación]]. 
 +
 
 +
=== Autenticación ===
 +
Para garantizar que aplicaciones de terceros no hagan un uso irrestricto del mecanismo de autenticación basado en el protocolo ''SAML,'' el componente ''Identity Provider'' o ''IdP'' de la plataforma requiere que se lo configure con un juego de certificados público/privado. Estos operan de la siguiente manera:
 +
* Al instalar el ''IdP'', se le debe configurar el par de certificados público/privado
 +
* Al registrar el ''IdP'' a la plataforma, '''Registry''' aprende cual es el certificado público y lo guarda en el catálogo
 +
* Al registrar un ''SP'' a la plataforma, '''Registry''' informa al cliente el certificado público del ''IdP''. Así aprende como comunicarse de forma segura el ''SP'' con el ''IdP''
 +
* El ''SP'' inicia un intercambio con el ''IdP'', en la negociación se encripta los datos y lo recibe el ''IdP'' solamente si puede desencriptar dichos datos
 +
Este mecanismo de intercambio previo de la clave sumado a la validación posterior, garantizan el uso del ''IdP'' por parte de módulos o ''SP'' autorizados únicamente. Puede ver mas en esta guía
 +
=== Transmisión de los datos encriptados ===
 +
Para que sea posible garantizar que la transmisión de datos entre todos los componentes de la plataforma sea seguro, mínimamente se ha de implementar el protocolo HTTPS. Para lograrlo, se ha de configurar certificados SSL válidos al servidor web de cada módulo o componente. Puede ver mas en esta [[IT/https|guía de implementación]].
  
 
[[SIU-Arai|< Volver]]
 
[[SIU-Arai|< Volver]]

Revisión actual del 17:32 18 abr 2018


Siu-arai.png


 Arquitectura de la plataforma

La siguiente imagen expone el detalle de la arquitectura general de la plataforma, así como la vinculación entre componentes internos, módulos del SIU y aplicaciones o sistemas externos.

Arquitectura.png

Definición de los componentes

Existen tres componentes que son vitales para el funcionamiento de la plataforma.

  • Arai-Registry: Registro de aplicaciones y servicios
  • Arai-Usuarios: Proveedor y Administrador de Identidad (término del IdP e IdM) para toda la plataforma. Destaca la provisión del servicio de ingreso único (Single Sign On)
  • Arai-Cli: Librería de cliente de la plataforma, que provee de servicios de bajo nivel facilitando la integración de los componentes

A partir de allí, es posible encontrarse con otros módulos que la complementan.

  • SIU-Huarpe: es el portal de la plataforma, punto de acceso único para los usuarios y concentrador de diversos servicios ofrecidos
  • SIU-XXX: toda aplicación del SIU capaz de ser integrada a la plataforma, conocido aquí como módulo.

También pueden ir apareciendo en escena futuros módulos o componentes que ofrezcan servicios puntuales. La plataforma es totalmente flexible en este punto. En todos los casos, los servicios ofrecidos han de implementar protocolos de comunicación basados en el estándar REST. Esto es lo que permite lograr el despliegue de una arquitectura basada en servicios (Service Oriented Architecture).

Despliegue de la plataforma

La plataforma posee diversos componentes que se deben resguardar y/o facilitar su acceso dependiendo del público objetivo. No tener en cuenta esto puede comprometer la integridad de todos los componentes, módulos y servicios involucrados.

El esquema de despliegue recomendado para la plataforma es el que muestra en la siguiente figura
El esquema de despliegue recomendado para la plataforma

En el proceso de despliegue de los componentes y servicios, se han de tener en consideración los siguientes factores:

  1. El portal SIU-Huarpe es de acceso público, lo pueden utilizar los usuarios desde cualquier origen (se recomienda brindar el acceso desde internet sin restricciones)
  2. El portal SIU-Huarpe puede requerir el acceso de las API de los módulos registrados en la plataforma, pero dichas API no deben en principio estar disponibles desde mas allá del portal
  3. El IdP (componente parte de SIU-Araí: Usuarios) es el que provee el formulario de autenticación, por lo tanto debe ser de acceso público (con FQDN propio)
  4. Tanto el IdM (parte de SIU-Araí: Usuarios) como los módulos SIU-XXX deben ser accesibles desde la red interna de la institución, pero no de forma pública
  5. El componente SIU-Araí: Registry es un componente exclusivo para sincronización de la plataforma y NO DEBE ser expuesto a conexiones fuera de la red de aplicaciones y módulos

Seguridad de la plataforma

SIU-Araí es concebida como un conjunto de componentes, que trabajando de forma mancomunada, conforman el camino hacia una Arquitectura Orientada a Servicios o SOA. Bajo este esquema, los servicios deben ser de bajo acoplamiento, autónomos, reusables, homogéneos, etc. Para lograr estos y otros factores, SIU-Araí establece ciertas pautas o mecanismos de trabajo:

  • Protección en descubirimiento y configuración de servicios mediante encriptación de datos
  • Protección en la transmisión de los datos mediante encriptación con el uso obligado de HTTPS
  • Protección en la autenticación con el intercambio entre el IdP y un SP mediante encriptación de token

Descubrimiento y configuración de servicios

En la plataforma SIU-Araí, el componente Registry es el responsable de mantener la información de que servicios son ofrecidos y por quienes son consumidos. Esta información es almacenada de forma central, por lo que se ha tomado una serie de recaudos para evitar poner en riesgo la plataforma si se llega a comprometer dicho catálogo central.

  • cada módulo y componente de la plataforma se le pueden generar claves de encriptación basadas en la librería de encriptación Sodium (conocidas también como clave para encriptar la sincronización de api REST con Araí )
  • al realizar una acción de sincronización desde un módulo/componente hacia Registry:
    1. ambos cliente/servidor de una API, publican un hash público derivado de la clave de encriptación que queda registrado en el catálogo central
    2. si un módulo consume una API y tiene sus datos de acceso como clave, es encriptada antes de ser transmitida
    3. si un módulo ofrece una API, obtiene la lista de clientes de dicha API y con su clave desencripta la clave ofuscada del cliente y la registra localmente para a futuro autenticar el acceso del cliente

Para mayores detalles, así como una guía detallada de como instalar Sodium, puede ver esta guía de implementación.

Autenticación

Para garantizar que aplicaciones de terceros no hagan un uso irrestricto del mecanismo de autenticación basado en el protocolo SAML, el componente Identity Provider o IdP de la plataforma requiere que se lo configure con un juego de certificados público/privado. Estos operan de la siguiente manera:

  • Al instalar el IdP, se le debe configurar el par de certificados público/privado
  • Al registrar el IdP a la plataforma, Registry aprende cual es el certificado público y lo guarda en el catálogo
  • Al registrar un SP a la plataforma, Registry informa al cliente el certificado público del IdP. Así aprende como comunicarse de forma segura el SP con el IdP
  • El SP inicia un intercambio con el IdP, en la negociación se encripta los datos y lo recibe el IdP solamente si puede desencriptar dichos datos

Este mecanismo de intercambio previo de la clave sumado a la validación posterior, garantizan el uso del IdP por parte de módulos o SP autorizados únicamente. Puede ver mas en esta guía

Transmisión de los datos encriptados

Para que sea posible garantizar que la transmisión de datos entre todos los componentes de la plataforma sea seguro, mínimamente se ha de implementar el protocolo HTTPS. Para lograrlo, se ha de configurar certificados SSL válidos al servidor web de cada módulo o componente. Puede ver mas en esta guía de implementación.

< Volver