¶ 1. Sobre la seguridad en la comunicación
La Red de Interoperabilidad PISEE ha sido diseñada para facilitar el intercambio seguro de información entre organismos públicos, a través de Internet. Por lo tanto, uno de los pilares fundamentales de su arquitectura es la preservación de la seguridad en la transmisión de información. Garantizando confidencialidad, integridad, autenticidad y el no repudio de los mensajes intercambiados.
A continuación se detallan las medidas de seguridad implementadas en la comunicación entre Nodos de PISEE.
¶ 2. Protocolo MPGA
La Red de Interoperabilidad PISEE ofrece un protocolo de comunicación para intercambiar mensajes entre los Nodos de los organismos del Estado. Este protocolo es el MPGA (Message Protocol for Government Administration) el cual cumple con los aspectos claves exigidos para la comunicación: confidencialidad, integridad, autenticidad y control de acceso.
Sobre este Protocolo se detallarán los siguientes aspectos:
- Canal de comunicación
- Autenticación
- Autorización
- Integridad
- Auditoría
¶ 2.1. Canal de comunicación
El protocolo MPGA de la Red de interoperabilidad de PISEE se utiliza para realizar la conexión entre los nodo:
- Establece una conexión directa entre los nodos de cada organismo.
- La conexión se realiza con HTTP/2 sobre TCP. Al ser HTTP/2 hace obligatorio el uso de HTTPS y realiza también la compresión de las cabeceras.
- Solo se establece conexión mediante autenticación mutua ocupando certificados (mTLS)
Las características de TLS que establecen los Nodos son:
Versión:
TLS 1.2+
Cipher Suites:
tls.TLS_AES_128_GCM_SHA256,
tls.TLS_AES_256_GCM_SHA384,
tls.TLS_CHACHA20_POLY1305_SHA256,
tls.TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,
tls.TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,
tls.TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,
tls.TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
Algoritmo de firma:
SHA256-RSA
¶ 2.2. Autenticación
El protocolo MPGA requiere de que ambos Nodos se autentiquen usando Mutual TLS.
Cada Nodo posee las llaves públicas de los organismos con los que se debe conectar y le permiten validar esta autenticación mutua. Estos certificados se obtienen previamente desde el servidor central de PISEE.
Al tener cada Nodo la lista blanca de sus contrapartes puede validar que solo se establezcan conexiones con aquellos organismos permitidos.
Esto se complementa posteriormente con la validación de la firma del mensaje (véase punto 2.4)
¶ 2.3. Autorización
Tener una conexión directa donde ambas partes se hayan identificado no es suficiente para responder a una solicitud, ya que es necesario saber si el organismo que envía el mensaje a un servicio está o no autorizado para utilizarlo.
El Protocolo MPGA especifica que cuando un Nodo consumidor quiere hacer uso de un servicio expuesto, en un Nodo proveedor, el consumidor debe primero obtener un token de autorización en el servidor central de PISEE.
- El consumidor debe conectarse con el Servidor Central de PISEE, autenticarse y solicitar un token para un servicio.
- Este token solo se emite si el organismo tiene permiso explícito, registrado en la base de datos central de PISEE, para consumir el servicio requerido.
- El Nodo consumidor ahora puede comunicarse con el servicio adjuntando el token obtenido en la cabecera Authorization
- El Nodo del proveedor recibirá el mensaje y sus cabeceras a través de la conexión segura y validará:
- Que venga el token
- Que haya sido emitido por el servidor central de PISEE
- Que no haya sido adulterado.
- Que corresponda al servicio solicitado
- Que no haya expirado
- Si todo está correcto el Nodo proveedor acepta el mensaje y llama al servicio web o api.
El token corresponde a un JWT firmado digitalmente por el Servidor Central de PISEE con la llave privada del tipo ES256
que este posee y los Nodos lo pueden validar porque cuentan con la llave pública. Dentro de ese token se encuentra el scope, el emisor, la fecha de expiración y el organismo consumidor.
Ejemplo:
Header
{
"alg": "ES256",
"typ": "JWT"
}
Payload
{
"scope": "gescod_CodigosUnicosTerritoriales",
"organismo": "7",
"nombreOrganismo": "Nodo Prueba",
"servicio": "gescod_CodigosUnicosTerritoriales",
"tramite": "nombreTramite",
"aud": "Gobierno de Chile",
"exp": 1752266204,
"jti": "01JZXFTY1X97QCMEYHWNVE68W4",
"iss": "DGD",
"sub": "7"
}Sin token o con tokens inválidos los Nodos rechazan los mensajes entrantes.
¶ 2.4. Integridad
Para asegurar la integridad de la información enviada los Nodos encapsulan todo el mensaje HTTP original utilizando el estándar PASETO (Platform-Agnostic Security Tokens), específicamente en su modo de firma digital (public-key version).
- Cada Nodo cuenta con un par de llaves criptográficas de curva elíptica independientes de los certificados TLS.
- El mensaje se firma digitalmente con la clave privada del emisor.
- El receptor verifica la firma usando la clave pública precargada del emisor
Con esto el receptor del mensaje puede validar la integridad del mensaje original, el cual no pudo ser modificado en tránsito sin alterar la firma.
Gracias a este mecanismo el emisor no puede negar la autoría del mensaje.
Dentro del mensaje PASETO se adjunta el ID único de la transacción (véase 2.5)
Además se valida la autenticidad al hacer una triple verificación ya que tanto la firma del mensaje, el token y la conexión mTLS deben coincidir con la contraparte.
¶ 2.5. Auditoría
Todos los mensajes que pasan por los Nodos, tanto consumidor como el proveedor van dejando una traza en el Registro de Trazabilidad de PISEE.
Cuando el Nodo consumidor recibe un mensaje que debe transmitir este crea un ID único de transacción usando:
[id_organismo].[ULID]
id_organismo corresponde al identificador del organismo según el Codificador del éstado https://codificador.digital.gob.cl/codificaciones-del-estado/instituciones
ULID (Universally Unique Lexicographically Sortable Identifier) es un tipo de identificador único diseñado para ser ordenado lexicográficamente y garantizar la seguridad en la concurrencia.
https://www.rfc-editor.org/rfc/rfc9562
Con este identificador se van almacenando en el registro de trazabilidad los siguientes eventos:
- Nodo emisor envía un mensaje
- Nodo receptor recibe el mensaje
- Nodo receptor responde el mensaje
- Nodo emisor recibe la respuesta
Con este ID es posible identificar unívocamente cada transacción y todos sus eventos lo que permite auditar en el registro de trazabilidad el resultado de dicha comunicación.
Descripción de los registros de trazabilidad
| ID |
Donde el ID es un identificador único de la transacción. Este ID se compone de: ID del organismo + ULID. ULID corresponde a una cadena de texto única, compuesta por 48 bits de una marca de tiempo (tiempo UNIX en milisegundos) y 80 bits aleatorios, todo esto convertido en base64, quedando de la siguiente forma: PE-MIN-00525 . 01AN4Z07BY 79KA1307SR9X4MV3 |-------------| |----------| |----------------| ID organismo Timestamp Entropy
|
| Consumidor | Identificador único del organismo consumidor, según lo establecido en el Gestor de Códigos. |
| Proveedor | Identificador único del organismo proveedor, según lo establecido en el Gestor de Códigos. |
| Procedimiento | Identificador del procedimiento administrativo según el Catálogo de Procedimientos Administrativos |
| Servicio | Nombre del servicio web tal como aparece en el catálogo. |
| Funcionario o asesor a honorarios | Funcionario que requiere el dato. |
| Código Respuesta | Código de estado de respuesta HTTP. |
| Tipo Respuesta | Mensaje de la respuesta. |
| Datos Solicitud | Lista de los nombres de los datos solicitados. |
| Nodo Envío | Identificador del Nodo que realiza el envío. |
| Fecha Hora | Fecha y hora del envío, en UTC-0. |
| Autorización | Método de autorización utilizado para solicitar la información. |
| Tipo Traza |
Identificador de la etapa en la interoperabilidad que se está registrando. Las opciones son: 1.- Envío de consulta (la realiza el consumidor del servicio) 2.- Recepción de consulta (la realiza el proveedor del servicio) 3.- Envío de respuesta (la realiza el proveedor del servicio) 4.- Recepción de respuesta (la realiza el consumidor del servicio) |
| Gestión (*) | Gestión que se encarga |
| Plazo (*) | Plazo establecido para la realización de la gestión en cuestión |
| Run (*) | En el caso de que se interoperen datos de carácter sensible, es el rol único nacional del interesado cuyos datos están involucrados en la interacción |
| Token de autorización sensible (*) | En el caso de que se interoperen datos de carácter sensible, acá está el token autorización aprobado por el ciudadano. |
*Gobierno Digital incorporará estos campos a la estructura JSON durante el año 2026.
¶ 3.- Esquema de comunicación entre Nodos
Para mayor claridad del funcionamiento de los nodos este esquema explica dónde se encuentra cada componente de ambos organismos que interoperan.
¶ 4.- Esquema del Nodo con un balanceador
Para que el Nodo pueda establecer el canal seguro entre ambos organismos necesita ser él quien realice el forma exclusiva el Handshake TLS, por lo que sí requiere colocar un balanceador o proxy este solo debe ser del tipo TCP Passthrough.
