> For clean Markdown of any page, append .md to the page URL.
> For a complete documentation index, see https://docs.6mm.com/llms.txt.
> For AI client integration (Claude Code, Cursor, etc.), connect to the MCP server at https://docs.6mm.com/_mcp/server.

# Arquitectura de Seguridad de Integración de Socios

Esta página se enfoca en cómo un socio debe diseñar una integración 6MM segura. Para las capas de seguridad más amplias utilizadas en toda la plataforma de trading, véase [Arquitectura de Seguridad de la Plataforma](/es-419/security-compliance/security-architecture).

La arquitectura de seguridad debe acordarse antes de que comience la integración en producción. Afecta cómo los sistemas asociados validan a los usuarios, emiten tokens, almacenan secretos, reciben eventos, monitorean operaciones y responden a incidentes.

<h2 id="recommended-trust-boundary">
  Límite de fideicomiso recomendado
</h2>

| Componente                        | Puede contener                                                                                   | No debe contener                                                           |
| --------------------------------- | ------------------------------------------------------------------------------------------------ | -------------------------------------------------------------------------- |
| Frontend asociado                 | Configuración pública, resultado de entrada de corta duración, estado de la interfaz no sensible | Socio API secreto, clave de firma, credenciales privilegiadas del backend  |
| Backend del socio                 | Mapeo de usuarios, credenciales protegidas, lógica de firma, procesamiento de webhooks           | Secretos expuestos a través de respuestas de clientes o registros públicos |
| 6MM puntos finales de integración | Solicitudes firmadas aprobadas, tokens y entrega por webhook                                     | Suposiciones no verificadas del usuario del lado del socio                 |

El frontend del socio debería llamar al backend del socio para operaciones privilegiadas. El backend valida al usuario socio, llama a 6MM a través del API aprobado o SDK y solo devuelve el resultado de corta duración que necesita el frontend.

<h2 id="security-layers">
  Capas de seguridad
</h2>

| Capa               | Enfoque requerido                                                                                 |
| ------------------ | ------------------------------------------------------------------------------------------------- |
| API Credenciales   | Almacenamiento solo en backend, plan de rotación y control de acceso.                             |
| Firma de solicitud | Manejo consistente contra la protección contra la marca de tiempo, firma y repeticiones.          |
| Incrustar tokens   | Emisión de corta duración, verificaciones de elegibilidad y comportamiento claro de invalidación. |
| Webhooks           | Verificación de firmas, idempotencia, retries y registros de auditoría de eventos.                |
| Operaciones        | Acceso a roles, escalada de incidentes, monitoreo y retención de evidencia.                       |

<h2 id="production-control-plan">
  Plan de control de producción
</h2>

| Área de control                | Evidencia mínima de implementación                                                                                                     |
| ------------------------------ | -------------------------------------------------------------------------------------------------------------------------------------- |
| Almacenamiento de credenciales | Ubicación del administrador secreto, propietario de acceso, separación del entorno y proceso de rotación.                              |
| Entrada de usuario             | Validación de sesión, verificación de elegibilidad, flujo de tokens de corta duración y manejo de fallas.                              |
| Solicitudes firmadas           | Entorno correcto, hora sincronizada, registro de solicitudes y alertas de error de firma.                                              |
| Operaciones de activos         | IDs de negocio únicos, conciliación de tiempos de espera, consultas de estado y ruta de revisión del operador.                         |
| Webhooks                       | Verificación de firma de cuerpo crudo, controles de repetición, almacenamiento de idempotencia y procesamiento seguro para reintentos. |
| Monitoreo                      | Alertas por fallas de autenticación, intentos anormales, lag en el webhook y errores operativos.                                       |
| Respuesta a incidentes         | Propietario nombrado, canal de escalada, retención de evidencia y procedimiento de revocación de credenciales.                         |

<h2 id="launch-review">
  Reseña de lanzamiento
</h2>

Antes de la producción:

1. Dibujar los flujos de datos del usuario, token, solicitud, activo y webhook.
2. Marca dónde se crea, almacena, usa, registra, rota y revoca cada credencial.
3. Probar tokens vencidos, firmas inválidas, tiempos de espera, webhooks duplicados y comportamiento de reconexión.
4. Confirmar que los equipos de soporte pueden localizar una operación a partir de su solicitud o identificador de negocio.
5. Completar la [Lista de Verificación de Lanzamiento de Producción](/es-419/solutions/production-launch-checklist).

<h2 id="recommended-docs">
  Doctores recomendados
</h2>

#### [Secretos y firmas](/es-419/sdk/security/secrets-signing)

Protege Agent SDK credenciales y solicitudes firmadas.

#### [Firma de Solicitud](/es-419/developer-api/request-signing)

Implementa la firma directa de solicitudes API por parte del desarrollador.

#### [Webhook e Idempotencia](/es-419/sdk/security/webhooks-idempotency)

Procesa los eventos de manera segura.