Seguridad

Riversoft® STCP Gemini API da acceso a la configuración, la administración y la supervisión del entorno. Por eso, las credenciales de operador y los tokens deben protegerse como contraseñas de administración. Esta página reúne las buenas prácticas para quienes integran con la API. Los recursos de seguridad del producto (TLS, SSO, MFA y políticas de contraseña) están en Seguridad de Riversoft STCP Gemini.

Transporte

• Publique la API solo por HTTPS: habilite ssl en el config.json de la API, con un certificado válido. Vea Configuración de la API.
• Use la opción -ns (sin TLS) solo en entornos de prueba aislados.
• Valide el certificado del servidor en el cliente. No desactive la verificación (por ejemplo, curl -k).
• Libere el acceso al puerto de la API solo para las redes y los sistemas que lo necesitan.

Credenciales y tokens

• No guarde contraseñas, tokens ni secretos TOTP en el código fuente, en archivos versionados, en el historial del shell, en logs ni en tickets de soporte.
• Guarde las credenciales de la integración en un almacén de secretos o en variables de entorno protegidas.
• Trate el access_token como una contraseña. Es válido durante 60 minutos de forma predeterminada (session_duration, hasta 720 minutos); obtenga un nuevo token cuando expire.
• El token se firma con el api_secret de la API: use un valor fuerte, privado y exclusivo del entorno.
• No reutilice credenciales de producción en entornos de prueba.

Autenticación de dos factores

• Habilite el 2FA de los operadores en el registro de la API (enable2FA). Con él, use el inicio de sesión en POST /oauth/v2/token: la ruta POST /oauth/token no aplica el 2FA. Vea Inicio de sesión local y 2FA.
• Muestre el secreto TOTP y el código QR solo al propio operador, y solo en el primer acceso.
• El desafío acepta tres códigos incorrectos; en el cuarto, el operador se bloquea.
• Si el operador pierde la aplicación autenticadora, restablezca su 2FA mediante el mantenimiento. Se genera un secreto nuevo en el siguiente inicio de sesión.

Single Sign-On

• Los retornos de SAML 2.0 y OAuth 2.0 los envía el proveedor de identidad. No construya códigos de autorización, state ni aserciones SAML manualmente.
• En el SSO, el token llega en la query string de la redirección. Léalo en cuanto cargue la página, elimínelo de la URL y no lo registre en logs.
• En el inicio de sesión por SSO, el 2FA es el que exige el proveedor de identidad, y no el de la API.

Vea Single Sign-On.

Sesión

• Mantenga el token en memoria o en almacenamiento de sesión; no lo guarde en el almacenamiento permanente del navegador.
• Cierre la sesión con DELETE /disconnect/api/v3/logout cuando termine la integración. Después de un inicio de sesión por SSO, redirija el navegador a la dirección recibida en redirect, cuando exista. Vea Sesión y logout.

Permisos

• Use un operador propio para cada integración, en grupos con solo los permisos necesarios (0 sin acceso, 1 lectura, 15 lectura y escritura).
• Limite, en las relaciones del grupo, las instancias, los usuarios y los operadores que la integración puede ver.
• El operador stcpadmin tiene acceso total. Cambie la contraseña predeterminada en el primer acceso y no lo use en integraciones.

Vea Conceptos y arquitectura.

Datos sensibles

• El CONFIG_TXT contiene contraseñas y secretos de las entidades. La API los devuelve enmascarados; no quite la máscara y no registre respuestas completas en logs.
• Al modificar una entidad, reenvíe el valor enmascarado para mantener el guardado. Envíe un valor nuevo solo cuando quiera cambiarlo.
• Las credenciales de supervisión del registro de la API y las credenciales de las bases son datos sensibles.
• La clave usada para cifrar esas contraseñas en la base es el api_secret, que debe ser igual en los demás módulos del entorno. Vea Clave de cifrado de las contraseñas.

Auditoría

Toda llamada hecha por un operador se registra con operador, método, ruta y status HTTP. Consulte el informe de operadores y los informes de auditoría para acompañar los accesos y los cambios.

Checklist de seguridad

• API publicada solo por HTTPS, con validación de certificado.
• Credenciales y tokens fuera del código y de los logs.
• api_secret fuerte y protegido.
• 2FA habilitado para los operadores, con inicio de sesión en POST /oauth/v2/token.
• Contraseña predeterminada del stcpadmin cambiada, y el stcpadmin fuera de las integraciones.
• Operador exclusivo y con permisos mínimos para cada integración.
• Token del SSO eliminado de la URL después de leerlo.
• Respuestas con CONFIG_TXT fuera de los logs.
• Logout al final de la sesión.
• Informes de operadores y de auditoría revisados periódicamente.