Mejor paso:Servicios
Siguiente paso:Servicios

Revisión de seguridad · procurement · arquitectura

Un solo lugar para revisar qué puede demostrar MIRMC hoy, qué está controlado pero incompleto y qué continúa siendo una brecha enterprise explícita.

Capacidad enterprise · evidencia en progreso

Evidencia antes que afirmaciones de marketing enterprise.

Este centro incluye las brechas deliberadamente. Una revisión seria de proveedor necesita saber no solo qué existe, sino dónde MIRMC aún requiere implementación, trabajo contractual o assurance independiente.

Esta es una declaración de madurez de ingeniería, no una certificación de seguridad, opinión legal ni SLA contractual.

5
Implementados
11
Controlados
6
Brechas
2
No certificados

Superficies de revisión

Evidencia que un comprador puede inspeccionar

Centro de Confianza

Registro canónico de controles implementados, controlados, planificados y no certificados.

Matriz de Preparación para Procurement

Respuestas para compradores sobre seguridad y cumplimiento derivadas de evidencia canónica, con exportación JSON y CSV.

Estado Operativo

Salud fresca del runtime y evidencia exacta de candidato Cloudflare, sin uptime inventado.

Seguridad y Divulgación

Límites de divulgación responsable y contacto de seguridad.

Registro de Proveedores

Integraciones core, condicionales y opcionales con evidencia respaldada por código.

Evidencia de Tratamiento de Datos

Actividades de tratamiento, límites de proveedores, categorías de retención y estados de evidencia de residencia sin convertir el código en afirmaciones legales.

Manifiesto de Confianza Machine-readable

Espejo JSON de la clasificación enterprise y estados de controles.

Índice de Integridad de Evidencia

Gate de consistencia entre manifests que detecta cuando Trust, Network, Identity, ejecución o DR se adelantan a su evidencia canónica. Consistencia no equivale a prueba runtime.

Freshness de Evidencia

Mide el desfase de fechas entre ocho dominios de evidencia enterprise respaldados por código. El skew source actual es de un día; esto no es freshness runtime, uptime ni salud productiva.

Evidencia del Network Gateway

Autoridad source v18, fingerprint de binding del release, probes de staging y límites de claims runtime en formato machine-readable.

Evidencia Canary de Identidad

Requisitos del canary aislado SAML/SCIM y claims runtime/proveedor explícitamente false hasta que exista un canary real.

Evidencia de Ejecución del HEAD Exacto

Protocolo de receipt de preflight/build en checkout limpio que separa ejecución de source, despliegue y release productivo.

Evidencia Operacional y DR

Límites de incidentes/SLO más el contrato DR aislado de ocho hashes sin claims de SLA contractual ni restore productivo.

Mapa de Tratamiento Machine-readable

Espejo JSON de actividades de tratamiento y límites explícitos de claims legales/residencia.

security.txt

Registro estándar de descubrimiento para reportes de seguridad.

Paquete actual de revisión

  • Autorización por tenant y límites Agency SaaS.
  • Billing con autoridad de servidor más step-up AAL2 para usuarios enrolados en billing privilegiado.
  • Evidencia Cloudflare-first más fingerprints completos v18 del binding de release del Network Gateway.
  • Protocolo canary SAML/SCIM aislado con pruebas negativas de cross-tenant, concurrencia ETag, privilege ceiling y deprovisioning; el canary runtime sigue sin afirmarse.
  • Protocolo de receipt de ejecución del HEAD exacto en checkout limpio para preflight/typecheck/tests y build Cloudflare opcional; no se inventa un receipt actual desde source.
  • Pack DR aislado hash-bound que liga RPO/RTO al backup exacto, probes de seguridad y cleanup receipt; el restore productivo sigue sin afirmarse.
  • Un gate de integridad entre manifests verifica que los claims source de Trust, Network, Identity, HEAD exacto y DR sigan siendo coherentes; consistencia no equivale a prueba runtime.
  • Un gate de freshness source sigue ocho dominios canónicos con un máximo de siete días de desfase; el skew source actual de un día no es freshness runtime, uptime ni salud productiva.
  • Divulgación de seguridad, límites de live status e inventario de proveedores.
  • 8 actividades de tratamiento mapeadas a 10 límites de proveedores con estados explícitos de evidencia de retención/residencia.
  • 21 preguntas de procurement se generan desde la misma evidencia canónica en vez de una hoja comercial desconectada.
  • Baseline conservador de seguridad HTTP en el borde productivo del Worker.
Actualmente hay 10 registros de proveedores/integraciones documentados. Su presencia en el registro de ingeniería no convierte la lista en un schedule contractual de subprocesadores.

Gates enterprise abiertos

  • SSO enterprise (SAML/OIDC)abierto

    MIRMC ya contiene una base SAML SSO staged para inicio/callback, binding explícito del UUID del proveedor con la organización y guardas negativas cross-tenant. Producción continúa en planned porque todavía no existe un IdP real registrado y verificado, y no se afirma OIDC como implementado.

  • Provisionamiento de ciclo de vida SCIMabierto

    Está staged una base SCIM 2.0 Users por tenant, credenciales de organización hash-only, enlace de primer login ligado a SAML, plano de control AAL2 y precondiciones ETag atómicas opcionales. Producción continúa en planned hasta completar con éxito un canary con IdP y cliente SCIM reales.

  • Enforcement productivo de acceso de redabierto

    MIRMC tiene controles Network Gateway v18 cerrados en source con las nueve superficies privilegiadas registradas evaluadas por red y sin bypass RPC directo conocido en source. ENFORCE productivo continúa planned porque secretos coordinados, conformance de staging, canary medido, evidencia runtime y activación explícita todavía no han sido verificados.

  • Rama main protegidaabierto

    La auditoría del 25 de agosto de 2026 encontró main sin protección ni status checks obligatorios. CODEOWNERS y una política escalonada de ruleset ya están preparados, pero GitHub debe aplicarlos antes de considerar este control implementado.

  • SLA contractual y operaciones maduras de estadoabierto

    Ya existe transparencia operativa en vivo y está definido un modelo de operación de incidentes, pero todavía no se afirman como completos el uptime histórico, la evidencia histórica de incidentes ni compromisos contractuales de uptime/remedios.

  • SOC 2no certificado

    MIRMC no afirma certificación SOC 2 en este registro de confianza.

  • ISO 27001no certificado

    MIRMC no afirma certificación ISO 27001 en este registro de confianza.

  • Pruebas de recuperación y evidencia RPO/RTOabierto

    MIRMC ya tiene objetivos RPO/RTO explícitos de ingeniería y un protocolo aislado de pruebas de restauración, pero esta auditoría todavía no afirma evidencia DR periódica completada ni el cumplimiento verificado de esos objetivos.