Saltar al contenido principal
Matcher implementa controles de seguridad integrales para proteger los datos de conciliación financiera. Esta guía cubre autenticación, autorización, aislamiento de inquilinos, cifrado y características de cumplimiento.

Descripción general


La arquitectura de seguridad de Matcher está construida en varias capas. Cada solicitud de API pasa por múltiples puntos de control de seguridad antes de llegar a sus datos.
1
Primero, TLS cifra la conexión.
2
Luego la autenticación verifica quién es usted:
  • El aislamiento de inquilinos asegura que solo vea sus propios datos.
  • RBAC verifica si tiene permiso para realizar la acción.
3
Finalmente, el sistema registra todo para propósitos de auditoría.

Protección por capas

CapaProtección
TransporteCifrado TLS 1.2+
AutenticaciónTokens JWT vía lib-auth
Aislamiento de inquilinosPostgreSQL con esquema por inquilino
AutorizaciónControl de acceso basado en roles
AuditoríaLogs inmutables de solo anexión
AlmacenamientoCifrado en reposo

Autenticación


Matcher usa la biblioteca compartida lib-auth para autenticación, soportando OAuth 2.0 y control de acceso basado en JWT.

Métodos de autenticación soportados

MétodoCaso de uso
OAuth 2.0 + JWTAutenticación de usuario vía IdP
Client CredentialsAutenticación servicio a servicio
API KeysAcceso programático

Estructura del token JWT

{
  "sub": "user_123",
  "tenant_id": "tenant_001",
  "roles": [
    "reconciliation_admin"
  ],
  "permissions": [
    "ingestion:import:create",
    "matching:job:run",
    "exception:item:resolve"
  ],
  "iat": 1705749600,
  "exp": 1705753200,
  "iss": "https://auth.example.com"
}

Encabezados requeridos

Todas las solicitudes de API deben incluir autenticación:
curl -X GET "https://api.matcher.example.com/v1/contexts" \
 -H "Authorization: Bearer $JWT_TOKEN" \
 -H "X-Request-ID: req_abc123"

Validación de token

Matcher valida los tokens en cada solicitud:
  1. Verificación de firma: Valida la firma JWT contra la clave pública
  2. Verificación de expiración: Rechaza tokens expirados
  3. Validación de emisor: Confirma que el token es de un emisor confiable
  4. Extracción de inquilino: Extrae tenant_id para aislamiento de esquema

Autenticación servicio a servicio

Para servicios backend que se integran con Matcher:
# Solicitar token
curl -X POST "https://auth.example.com/oauth/token" \
 -H "Content-Type: application/x-www-form-urlencoded" \
 -d "grant_type=client_credentials" \
 -d "client_id=matcher-service" \
 -d "client_secret=$CLIENT_SECRET" \
 -d "scope=matcher:read matcher:write"

Respuesta

{
  "access_token": "eyJhbGciOiJSUzI1NiIs...",
  "token_type": "Bearer",
  "expires_in": 3600,
  "scope": "matcher:read matcher:write"
}

Autorización (RBAC)


El control de acceso basado en roles protege todos los endpoints de API. Los permisos son granulares y siguen el patrón dominio:recurso:acción.

Estructura de permisos

<contexto_delimitado>:<recurso>:<acción>
Ejemplos:
  • ingestion:import:create - Crear importaciones
  • matching:job:run - Ejecutar trabajos de coincidencia
  • exception:item:resolve - Resolver excepciones

Lista completa de permisos

Ingesta

PermisoDescripción
ingestion:import:createCargar archivos de transacciones
ingestion:import:readVer estado de importación
ingestion:import:cancelCancelar importaciones en progreso
ingestion:source:createCrear fuentes de datos
ingestion:source:readVer configuración de fuente
ingestion:source:updateModificar configuración de fuente
ingestion:source:deleteEliminar fuentes de datos

Coincidencias

PermisoDescripción
matching:job:runEjecutar trabajos de coincidencia
matching:job:readVer estado de trabajo
matching:job:cancelCancelar trabajos en ejecución
matching:match:readVer resultados de coincidencias
matching:match:confirmConfirmar coincidencias propuestas
matching:match:rejectRechazar coincidencias propuestas
matching:rule:createCrear reglas de coincidencia
matching:rule:updateModificar reglas de coincidencia
matching:rule:deleteEliminar reglas de coincidencia

Excepciones

PermisoDescripción
exception:item:readVer excepciones
exception:item:resolveResolver excepciones
exception:item:assignAsignar excepciones
exception:item:escalateEscalar excepciones
exception:routing:manageConfigurar reglas de enrutamiento

Gobernanza

PermisoDescripción
governance:report:readVer reportes
governance:report:createGenerar reportes
governance:report:exportExportar datos de reportes
governance:audit:readVer logs de auditoría
governance:context:createCrear contextos
governance:context:updateModificar contextos
governance:context:deleteEliminar contextos

Administración

PermisoDescripción
admin:user:manageGestionar acceso de usuarios
admin:role:manageGestionar roles
admin:tenant:configureConfigurar ajustes del inquilino
admin:system:monitorVer salud del sistema

Roles integrados

RolPermisosCaso de uso
reconciliation_viewerAcceso de solo lectura a coincidencias y excepcionesAuditores
reconciliation_analystVer + resolver excepcionesEquipo de finanzas
reconciliation_adminAcceso completo excepto admin del sistemaLíderes de equipo
system_adminTodos los permisosAdministradores de TI

Aislamiento de inquilinos


Matcher usa aislamiento de esquema por inquilino en PostgreSQL, proporcionando una fuerte separación de datos entre inquilinos.

Cómo funciona

Cuando llega una solicitud, Matcher extrae el ID del inquilino del token JWT (nunca de parámetros de consulta o encabezados que usted controla). Luego establece la conexión de base de datos para usar el esquema de ese inquilino, por lo que cada consulta se ejecuta en completo aislamiento.
Incluso si existiera un bug en la capa de aplicación, la base de datos impone la separación.
Detalles de implementación
  1. ID de inquilino solo desde JWT: Nunca aceptado desde parámetros de solicitud
  2. Selección automática de esquema: Aplicado vía auth.ApplyTenantSchema()
  3. Aislamiento de consultas: Todas las consultas tienen alcance al esquema del inquilino
  4. Sin acceso entre inquilinos: La base de datos impone el aislamiento

Estructura del esquema de base de datos

Base de datos: matcher_db
├── tenant_001 (esquema)
│ ├── transactions
│ ├── matches
│ ├── exceptions
│ ├── audit_logs
│ └── ...
├── tenant_002 (esquema)
│ ├── transactions
│ ├── matches
│ ├── exceptions
│ ├── audit_logs
│ └── ...
└── shared (esquema)
 ├── field_map_templates
 ├── rule_templates
 └── system_config

Garantías de aislamiento

GarantíaImplementación
Aislamiento de datosEsquemas PostgreSQL separados
Alcance de consultassearch_path establecido por conexión
Sin suplantación de inquilinoInquilino solo desde JWT
Separación de auditoríaTablas de auditoría por inquilino

Verificar aislamiento de inquilino

# Esto retorna solo datos para el inquilino en el JWT
curl -X GET "https://api.matcher.example.com/v1/contexts" \
 -H "Authorization: Bearer $TOKEN"

Pista de auditoría


Todas las acciones se registran en un log de auditoría inmutable de solo anexión para cumplimiento y análisis forense.

Eventos auditados

CategoríaEventos
AutenticaciónLogin, logout, refresh de token, intentos fallidos
Acceso a datosVer coincidencias, ver excepciones, exportar datos
Modificación de datosCrear coincidencia, resolver excepción, actualizar reglas
ConfiguraciónCrear contexto, modificar fuente, cambiar configuración
AdministraciónGestión de usuarios, cambios de roles, otorgamiento de permisos

Estructura del log de auditoría

{
  "id": "audit_001",
  "timestamp": "2024-01-20T10:30:00Z",
  "tenant_id": "tenant_001",
  "user_id": "user_123",
  "user_email": "analyst@company.com",
  "action": "exception:item:resolve",
  "resource_type": "exception",
  "resource_id": "exc_001",
  "details": {
    "resolution_type": "FORCE_MATCH",
    "matched_transaction": "txn_456",
    "notes": "Verificado con extracto bancario"
  },
  "ip_address": "192.168.1.100",
  "user_agent": "Mozilla/5.0...",
  "request_id": "req_abc123",
  "outcome": "SUCCESS"
}

Consultar logs de auditoría

Use el endpoint de logs de auditoría para recuperar registros de auditoría.
Referencia de API: Listar logs de auditoría

Retención de logs de auditoría

EntornoRetenciónArchivo
Producción7 añosAlmacenamiento frío después de 1 año
Staging90 díasSin archivo
Desarrollo30 díasSin archivo

Cifrado de datos


Cifrado en tránsito

Todos los datos transmitidos hacia y desde Matcher están cifrados usando TLS.
RequisitoConfiguración
ProtocoloTLS 1.2 o superior
Suites de cifradoSolo cifrados fuertes
CertificadoCertificado válido firmado por CA
HSTSHabilitado con max-age de 1 año

Cifrado en reposo

Tipo de datosMétodo de cifrado
Base de datosPostgreSQL TDE (Cifrado de datos transparente)
Almacenamiento de archivosCifrado AES-256
RespaldosCifrados antes de almacenamiento
SecretosVault con cifrado de sobre

Cifrado de campos sensibles

Campos sensibles específicos se cifran a nivel de aplicación:
{
  "settings": {
    "encryption": {
      "encrypt_fields": [
        "counterparty_account",
        "reference",
        "external_id"
      ],
      "key_id": "key_prod_001"
    }
  }
}

Gestión de claves

PrácticaImplementación
Rotación de clavesRotación automática cada 90 días
Almacenamiento de clavesHashiCorp Vault o AWS KMS
Control de accesoPrincipio de mínimo privilegio
AuditoríaTodo acceso a claves se registra

Cumplimiento SOX


Matcher mantiene registros para los requisitos de auditoría SOX (Sarbanes-Oxley).

Características de control SOX

ControlCaracterística de Matcher
Segregación de funcionesRBAC con permisos granulares
Gestión de cambiosPista de auditoría para todos los cambios de configuración
Control de accesoAutenticación JWT con aplicación de roles
Pista de auditoríaLogs inmutables con retención de 7 años
Integridad de datosChecksums y validación de transacciones

Principio de cuatro ojos

Imponga aprobación dual para acciones sensibles:
{
  "settings": {
    "governance": {
      "require_approval": {
        "exception_write_off": true,
        "high_value_match": true,
        "threshold_amount": 100000.0
      },
      "approver_role": "reconciliation_admin"
    }
  }
}

Seguridad de API


Limitación de tasa

Proteja contra abuso con límites de tasa:
Tipo de endpointLímite
Operaciones de lectura1000/minuto
Operaciones de escritura100/minuto
Generación de reportes10/minuto
Cargas de archivos20/minuto

Encabezados de límite de tasa

X-RateLimit-Limit: 1000
X-RateLimit-Remaining: 950
X-RateLimit-Reset: 1705753200

Lista de IPs permitidas

Restrinja el acceso a la API a rangos de IP conocidos:
{
  "settings": {
    "security": {
      "ip_allowlist": [
        "10.0.0.0/8",
        "192.168.1.0/24",
        "203.0.113.50"
      ],
      "enforce_allowlist": true
    }
  }
}

Firma de solicitudes

Para entornos de alta seguridad, habilite la firma de solicitudes:
# Generar firma
TIMESTAMP=$(date +%s)
SIGNATURE=$(echo -n "$TIMESTAMP$REQUEST_BODY" | openssl dgst -sha256 -hmac "$SECRET_KEY" | cut -d' ' -f2)

curl -X POST "https://api.matcher.example.com/v1/matches" \
 -H "Authorization: Bearer $TOKEN" \
 -H "X-Timestamp: $TIMESTAMP" \
 -H "X-Signature: $SIGNATURE" \
 -d "$REQUEST_BODY"

Mejores prácticas


Otorgue a los usuarios solo los permisos que necesitan. Comience con acceso mínimo y agregue permisos según sea necesario.
Implemente rotación automática para claves de API y credenciales de servicio. Use tokens de corta duración cuando sea posible.
Mantenga los logs de auditoría habilitados y revíselos regularmente. Configure alertas para actividad sospechosa.
Restrinja el acceso a la API a rangos de IP conocidos, especialmente para entornos de producción.
Requiera MFA para cuentas de usuario. Use autenticación basada en certificados para cuentas de servicio cuando sea posible.
Realice revisiones periódicas de acceso. Elimine el acceso rápidamente cuando los usuarios cambien de rol o se vayan.
Habilite el cifrado a nivel de campo para datos de transacciones sensibles más allá del cifrado de base de datos.
Configure monitoreo y alertas en tiempo real para eventos de seguridad. Investigue anomalías de inmediato.

Próximos pasos