Diferencia entre revisiones de «SIU-Arai/Arquitectura»
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 | + | Existen tres componentes que son vitales para el funcionamiento de la plataforma. |
| − | *Arai-Registry: | + | *[[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]]). |
| − | == | + | ==Despliegue de la plataforma == |
| − | 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: | + | 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]] |
| − | + | En el proceso de despliegue de los componentes y servicios, se han de tener en consideración los siguientes factores: | |
| − | + | # 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) | |
| − | + | # 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 | |
| − | + | # 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) | |
| − | + | # 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 | |
| − | + | # 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 [[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: | ||
| − | + | * 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 [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
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.
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
En el proceso de despliegue de los componentes y servicios, se han de tener en consideración los siguientes factores:
- 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)
- 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
- 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)
- 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
- 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:
- 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 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.
