Seguridad

Modelo de seguridad

Riversoft® STCP DirectLink aplica los controles de la transferencia gestionada de archivos (MFT) a todos los protocolos y conectores: solo los usuarios autenticados intercambian archivos, los datos viajan cifrados, cada operación se valida contra las reglas del usuario y todo queda registrado. La seguridad se organiza en capas:

Protocolos y conectores

Los protocolos y conectores de Riversoft® STCP DirectLink usan conexiones cifradas y autenticación por usuario. Los mecanismos varían según el protocolo y las políticas de seguridad del entorno.

TLS 1.2 y TLS 1.3

El portal, la API REST, AS2, Webhook, FTPS y los conectores de nube (Amazon S3, Azure Blob Storage, Google Cloud Storage y Oracle Cloud Object Storage) usan TLS 1.2 o TLS 1.3.

SFTP

SFTP (SSH File Transfer Protocol) usa un canal seguro SSH-2. La autenticación puede hacerse con usuario y contraseña o con un par de claves pública y privada. Los algoritmos y las políticas de seguridad se negocian al establecer la conexión.

El SFTP Server acepta autenticación de dos factores (2FA) y MFA, según la configuración del usuario.

AS2

AS2 (Applicability Statement 2) está orientado al intercambio de documentos entre organizaciones. Usa TLS 1.2 y 1.3, certificados X.509, S/MIME, firma digital, MDN (Message Disposition Notification) y MIC (Message Integrity Check).

• El MDN comprueba la entrega del mensaje y puede ser síncrono o asíncrono, con firma digital.
• La combinación de MIC y firma digital garantiza el no repudio del envío y de la recepción.
• Se admiten EDI, EDIFACT, X12, XML, JSON, archivos binarios y otros tipos de contenido.
• El MDN puede cifrarse en el envío y en la recepción, según la configuración del usuario.
• El usuario puede autenticarse en el servicio AS2 con un token Bearer.

FTPS, Webhook y almacenamiento en la nube

Autenticación en Riversoft STCP DirectLink Portal

El acceso al portal puede realizarse:

• Directamente, con el usuario y la contraseña de STCP. Cuando la configuración lo exige, el inicio de sesión se completa con un segundo factor (MFA): PIN enviado por correo electrónico o SMS, o código TOTP de una aplicación autenticadora.
• Mediante SSO (Single Sign-On), con Google, Microsoft, Apple o cualquier proveedor de identidad compatible con OAuth 2.0 y 2.1/OpenID Connect o SAML 2.0.

Después del inicio de sesión, la sesión se mantiene con la cookie __Host-dirl_session, emitida con los atributos HttpOnly, Secure y SameSite=Strict. El cierre de sesión elimina la cookie. Por eso, el portal debe publicarse por HTTPS.

Protección contra automatización

El administrador puede habilitar Cloudflare Turnstile en el inicio de sesión, el primer acceso y la recuperación de contraseña. Con el recurso habilitado, el portal muestra la verificación de Cloudflare antes de enviar las credenciales, y la solicitud solo se procesa con un token válido. El token es de un solo uso y caduca en 300 segundos. Las integraciones que llaman a estas rutas directamente deben seguir el contrato de la API.

Autenticación en la API

A partir de la versión 9, las rutas protegidas de la API (carga, listados, informe y cierre de sesión) aceptan solo un token Bearer. La autenticación Basic (usuario y contraseña) se acepta solo en el inicio de sesión.

Cuando el header Authorization y la cookie están presentes, el header tiene prioridad. El token caduca tras el tiempo indicado en expires_in.

El token autentica al usuario, pero no concede el acceso por sí solo: la API también aplica las reglas del usuario en el servidor STCP (conexión habilitada, ventana horaria, filtros y límite de sesiones). Por eso, un token válido puede recibir 403.

Token de suplantación

Las integraciones técnicas que necesitan una credencial de larga duración pueden usar un token de suplantación (impersonation), generado por el administrador en la interfaz de supervisión. El token tiene un identificador de sesión registrado para el usuario; la API verifica ese identificador en cada llamada, y se rechaza un token cuyo identificador no esté registrado. Detalles en Tokens OAuth.

La API puede seguir OAuth 2.1. Vea Compatibilidad con OAuth 2.1.

Autenticación por JWT de confianza

Para integrar Riversoft STCP DirectLink con portales de servicios, el portal emite un token JWT para el usuario, firmado con su clave privada, y lo intercambia por un token Bearer de Riversoft STCP DirectLink (token exchange, RFC 8693). Riversoft STCP DirectLink valida el JWT de origen con la configuración del proveedor JWT registrada por el administrador.

    sequenceDiagram
    autonumber
    participant PS as Portal de servicios
    participant DL as API Riversoft STCP DirectLink
    PS->>PS: Emite el JWT del usuario (clave privada)
    PS->>DL: POST /auth/token (token exchange, subject_token = JWT, provider)
    DL->>DL: Valida firma, issuer, audience y vigencia
    DL->>DL: Verifica el usuario y las reglas de acceso
    DL-->>PS: access_token (Bearer)
    PS->>DL: Llamadas a las rutas protegidas con Authorization: Bearer
  

Solicitud de intercambio del token

curl -X POST "https://<dominio>/directlink/v2/auth/token" \
  --data-urlencode "grant_type=urn:ietf:params:oauth:grant-type:token-exchange" \
  --data-urlencode "subject_token_type=urn:ietf:params:oauth:token-type:jwt" \
  --data-urlencode "subject_token=<jwt-de-origen>" \
  --data-urlencode "provider=<proveedor-jwt>"

• provider es el identificador del proveedor JWT registrado por el administrador. También puede enviarse en el header X-STCPDIRECTLINK-JWT-ISSUER; si se envían ambos, prevalece el campo del formulario. El valor no necesita ser igual a la claim iss.
• El único subject_token_type aceptado es urn:ietf:params:oauth:token-type:jwt.
• El usuario identificado en las claims debe existir en el servidor STCP y corresponder al perfil configurado.

Estructura del token de origen

Header

Payload (claims)

La clave pública (o el material de validación) que verifica la firma la registra el administrador en la configuración del proveedor JWT. Los campos kid y alg deben corresponder a los de la clave registrada. Proteja la clave privada del portal de servicios.

Enlace seguro y código de seguridad

El enlace seguro enviado a destinatarios externos identifica el correo electrónico o el celular vinculado al archivo. La descarga solo se libera con el código de seguridad (PIN), que se envía únicamente a ese correo electrónico o celular. Vea el flujo en Conceptos y arquitectura.

La vigencia la define el administrador:

Gestión de contraseña

El usuario define o restablece la contraseña en dos etapas:

1. Solicita el enlace de cambio en Primer acceso u Olvidó la contraseña.
2. Confirma la nueva contraseña en Cambio de contraseña, con el PIN de seguridad enviado al correo electrónico registrado.

Clave de cifrado de las contraseñas

Las contraseñas guardadas en la base de configuración se cifran con una clave que debe ser la misma en todos los módulos del entorno. Vea cómo definir la clave y qué hacer para cambiarla en Configuración: clave de cifrado de las contraseñas.

Buenas prácticas

• Publique Riversoft STCP DirectLink solo por HTTPS (la cookie de sesión exige Secure).
• En las integraciones, obtenga el token una vez y reutilícelo hasta que caduque; no envíe la contraseña en cada llamada.
• Guarde los tokens, incluidos los de suplantación, en un almacén de secretos y defina su rotación.
• Habilite solo los modos de autenticación que el entorno necesita.
• Considere habilitar Cloudflare Turnstile en el inicio de sesión, el primer acceso y la recuperación de contraseña.
• Implemente el límite de solicitudes (rate limiting) en el firewall perimetral: la API no lo aplica.
• Use el hash SHA-256 del archivo (h o X-STCPDIRECTLINK-HASH) para validar la integridad de las cargas.
• Proteja la clave privada usada para firmar los JWT de origen.
• Use la misma clave de cifrado (applConfigPassPhrase) en todos los módulos del entorno. Vea Clave de cifrado de las contraseñas.

Privacidad

El portal de Riversoft STCP DirectLink usa solo la cookie de sesión __Host-dirl_session, necesaria para mantener el inicio de sesión, y no usa cookies de seguimiento. La cookie se elimina al cerrar la sesión.

Cuando Cloudflare Turnstile está habilitado, la verificación la realiza Cloudflare, que recibe el token del desafío y la dirección IP del usuario.