Descripción general de la arquitectura técnica para equipos de TI que evalúan AccessPoint

Last updated: July 12, 2026 by Steve

Arquitectura técnica

Este documento ofrece una descripción general técnica de la plataforma AccessPoint para arquitectos de soluciones, ingenieros de ciberseguridad y directores de TI que evalúan el producto para su organización. Se basa en la Guía de Arquitectura de Soluciones de AccessPoint (v1.4.1).

Descripción general de la plataforma

AccessPoint es una plataforma de gestión de acceso a la información y privacidad construida sobre Microsoft 365 y Azure. Comenzó como una herramienta de gestión de solicitudes de acceso del interesado (SAR) y ha evolucionado hasta convertirse en una suite integrada de oficina de ATIP/privacidad que cubre todo el ciclo de vida de las solicitudes y el programa de privacidad en su conjunto. Se ejecuta enteramente dentro del propio inquilino de Microsoft 365 y Azure de su organización: no existen servidores externos, bases de datos ni dependencias de nube de terceros en tiempo de ejecución, y todos los datos permanecen en su entorno, bajo su control.

La plataforma está organizada en módulos que comparten un mismo eje de identidad, RBAC, notificaciones, auditoría e informes:

  • Solicitudes de acceso — recepción de ATI/FOIA/GDPR, asignación de tareas a custodios, revisión y redacción de documentos, empaquetado de respuestas e informes estatutarios
  • Evaluaciones de privacidad — un motor configurable de evaluaciones PIA/AIA/de seguridad
  • Incidentes y vulneraciones de privacidad — recepción, contención, riesgo de daño y flujos de trabajo de notificación de vulneraciones
  • Quejas y apelaciones — ciclo de vida de la queja con partes, plazos estatutarios e investigación
  • Registro de riesgos de privacidad — riesgos de estilo ISO 31000, planes de tratamiento e indicadores clave de riesgo
  • Registros de actividades de tratamiento (ROPA) — registros del artículo 30 del GDPR y exportación del registro
  • Registro de compromisos — compromisos de privacidad rastreados con periodicidad y seguimientos

Todos los módulos se basan en paquetes de configuración, sin datos semilla estáticos.

Características clave:

  • Nativo del inquilino — se implementa como una solución de SharePoint Framework (SPFx) y servicios de Azure PaaS dentro de su inquilino existente
  • Sin dependencias de Power Platform — no se requiere licenciamiento de Dataverse, Power Automate ni Power Apps
  • Soberanía de datos — todos los datos residen en la geografía configurada del inquilino de Azure
  • Sin acceso del proveedor en tiempo de ejecución — el editor no puede acceder a sus datos durante la operación normal
  • Licenciamiento de tarifa plana — licenciamiento departamental sin medición por usuario
  • Privacidad desde el diseño — los roles de custodio y colaborador están estructuralmente aislados de la información personal del solicitante y del interesado
  • Configuración en lugar de código — los tipos de solicitud, los códigos de exención y los campos de opción están basados en datos
  • Multilingüe desde el diseño — un sistema de traducción de tres niveles que admite 11 idiomas

Diagrama de arquitectura

Customer's Microsoft 365 Tenant          Customer's Azure Subscription
┌──────────────────────────────┐         ┌─────────────────────────────────────────┐
│                              │         │                                         │
│  SPFx Web Part               │         │  Azure App Service (Linux)              │
│  (SharePoint Online /        │──HTTPS──│  ASP.NET Core 10 Web API               │
│   Teams Personal App /       │  (JWT)  │    ├─ Entra ID JWT validation          │
│   Teams Tab)                 │         │    ├─ Role-based authorization          │
│                              │         │    ├─ PII filter middleware             │
│  Installed from AppSource    │         │    ├─ User upsert from JWT claims      │
│  or Tenant App Catalog       │         │    ├─ License validation middleware    │
│                              │         │    └─ Syncfusion document conversion   │
│                              │         │                                         │
│  SharePoint Tenant Storage   │         │  Azure SQL Database                     │
│  (API URL + Client ID)       │         │  (~186 tables, ~2,900 fields)          │
│                              │         │                                         │
└──────────────────────────────┘         │  Azure Blob Storage                     │
                                         │  (Document files)                       │
        Microsoft Graph API              │                                         │
        ┌──────────────────────┐         │  Application Insights + Log Analytics   │
        │  Mail.Send           │◄────────│  (Telemetry, diagnostics)               │
        │  User.Read.All       │         │                                         │
        │  TeamsActivity.Send  │         │  (opt-in) Azure AI Search               │
        │  TeamsAppInstall     │         └─────────────────────────────────────────┘
        │  Calendars.Read      │
        │  AiEnterprise…Read   │  ← M365 record capture (delegated + app-only Copilot)
        └──────────────────────┘

Inventario de componentes

Componente Tecnología Implementado en Finalidad
Componente web de SPFx TypeScript, React 17, Fluent UI 8, SPFx 1.22.1 SharePoint Online / Teams del cliente Interfaz de usuario para todos los roles
Aplicación de Teams Manifiesto de Teams v1.19, versión de aplicación 1.0.0 Centro de administración de Teams del cliente Aplicación personal, pestaña configurable, notificaciones de fuente de actividad con vínculos profundos
API web C# / ASP.NET Core 10, .NET 10 (~87 controladores, ~88 servicios) Azure App Service (Linux) del cliente Lógica de negocio, acceso a datos, procesamiento de documentos
Base de datos SQL Server (DacPac) Azure SQL Database del cliente Almacén de datos relacional (~186 tablas, ~2900 campos)
Blob Storage Azure Blob Storage Cuenta de Azure Storage del cliente Almacenamiento de archivos de documentos
Monitoreo Application Insights + Log Analytics Suscripción de Azure del cliente Telemetría, diagnóstico, alertas
AI Search (opcional) Azure AI Search Suscripción de Azure del cliente Búsqueda de texto completo en el contenido de documentos; se aprovisiona solo cuando deployAiSearch=true

Qué opera el editor

Servicio Finalidad
Realizer Platform Emisión y validación de claves de licencia (no se transmiten datos del cliente)
Publicación en AppSource Distribución del paquete SPFx
Publicación en Azure Marketplace Plantilla de implementación de infraestructura de Azure
Paquete de la aplicación de Teams Distribución del manifiesto de Teams (carga lateral o tienda de aplicaciones de la organización)

Ningún dato del cliente se transmite ni se almacena en ningún servicio operado por el editor.

Módulos funcionales

Todos los módulos se ejecutan dentro de la misma API web / componente web de SPFx y comparten un mismo eje de identidad, RBAC, comentarios, notificaciones, Mi Día, auditoría, horas, flujo de trabajo de revisión e informes. Cada uno está basado en datos mediante Paquetes de Configuración.

Módulo Resumen
Solicitudes (ATIP/SAR) Recepción de solicitudes → asignación de tareas a custodios → recopilación → respuesta. Tipos, estados, numeración, calendarios y SLA configurables.
Documentos y redacción Espacio de trabajo de documentos por facetas: etiquetas, familias de correo electrónico, seguimiento de lectura, vistas guardadas, vista previa de Syncfusion, canal de redacción con exenciones e ida y vuelta XFDF, empaquetado de respuestas.
Solicitantes / Contactos Identidad reutilizable de solicitante de primera clase, control del flujo de recepción, tarifas y verificación, fusión; consultas; redactor de correspondencia con firewall de información personal.
Evaluaciones de privacidad Motor configurable de PIA/AIA/evaluación de seguridad: plantillas, cuestionarios de detección, delegación de secciones, puntuación/niveles, registro de riesgos, resúmenes de cierre/regulador.
Incidentes de privacidad / vulneraciones Recepción de incidentes, contención, riesgo de daño, reglas de notificación de vulneraciones por régimen, remediación.
Quejas y apelaciones Ciclo de vida de la queja: partes, plazos estatutarios, admisibilidad, investigación, revisión de alegatos.
Riesgos y compromisos Registro de riesgos ISO 31000 con apetito de riesgo, KRI y tareas de tratamiento; registro de compromisos con periodicidad y seguimientos.
ROPA / Sujetos de privacidad Programas/sistemas reutilizables con registros del artículo 30 del GDPR y exportación del registro.
Revisiones Motor configurable de revisión y aprobación secuencial/paralelo, reutilizado en todas las entidades de casos.
Informes y auditoría Informes fijos, generador de informes personalizados, informes estadísticos anuales, paneles de SLA/gestión, libro mayor de auditoría encadenado por hash y paquetes de evidencia listos para uso judicial.
Configuración y plataforma Importación de paquetes de configuración, configuración del inquilino, roles/permisos personalizados, conmutadores de funciones, campos personalizados, tablas de traducción de 11 idiomas.

Modelo de implementación

AccessPoint utiliza un modelo de implementación dividido. El componente web de SPFx se instala desde Microsoft AppSource (o un Catálogo de aplicaciones del inquilino), el paquete de la aplicación de Teams se instala mediante carga lateral o la tienda de aplicaciones de la organización, y el backend de Azure se implementa en la propia suscripción del cliente mediante uno de dos métodos:

  • Azure Portal (recomendado) — implementación con un clic de todos los recursos de Azure (App Service, SQL, Blob Storage, Application Insights) mediante ARM/Bicep. La API se implementa mediante zipdeploy durante la implementación de ARM; el código se descarga una vez desde la CDN del editor y se almacena en el App Service del cliente, sin dependencia externa en tiempo de ejecución. El cliente conserva la propiedad completa del grupo de recursos.
  • Plantilla Bicep + script de PowerShell (manual) — para organizaciones con control de cambios estricto. Un botón Deploy to Azure o el script Deploy-AccessPoint.ps1 implementa la infraestructura, configura la autenticación exclusiva de Entra en SQL, otorga permisos de Microsoft Graph a la identidad administrada, configura las entidades de almacenamiento del inquilino de SharePoint y aprueba las solicitudes de permisos de API de SPFx. Cada paso se puede omitir de forma independiente.

La implementación está reforzada en materia de seguridad de forma predeterminada: TLS 1.3, FTPS deshabilitado, autenticación básica de SCM/FTP deshabilitada y HTTP/2 habilitado. La API incluye su DacPac de base de datos y lo aplica al iniciar mediante un servicio de migración que utiliza DacServices.Deploy(upgradeExisting: true); no realiza ninguna operación en un esquema ya actualizado, y aplica un delta aditivo y no destructivo tras un cambio de esquema (BlockOnPossibleDataLoss = true, DropObjectsNotInSource = false). El resultado de la migración se expone a través de /api/health. Después de la implementación, un administrador otorga consentimiento para la aplicación empresarial de Realizer (notificaciones de Teams), configura el buzón de envío e importa un paquete de configuración específico de la jurisdicción.

Autenticación e identidad

AccessPoint utiliza Microsoft Entra ID como único proveedor de identidad. No existen cuentas de usuario ni contraseñas específicas de la aplicación. El componente web de SPFx obtiene un JWT para la audiencia de la API mediante AadHttpClient; la API valida el emisor, la audiencia, la firma y la caducidad en cada solicitud. Las políticas de MFA y acceso condicional configuradas en el inquilino se aplican en su totalidad.

User (Browser)                SharePoint Online           AccessPoint API
     │                              │                          │
     │  1. Load SPFx web part       │                          │
     │─────────────────────────────►│                          │
     │                              │                          │
     │  2. AadHttpClient.getClient()│                          │
     │  (SPFx acquires token for    │                          │
     │   api://<client-id> audience)│                          │
     │                              │                          │
     │  3. API call + Bearer token  │                          │
     │──────────────────────────────┼─────────────────────────►│
     │                              │                          │
     │                              │  4. Validate JWT:        │
     │                              │     - Issuer (Entra ID)  │
     │                              │     - Audience (api://)  │
     │                              │     - Signature          │
     │                              │     - Expiry             │
     │                              │                          │
     │                              │  5. UserUpsertMiddleware: │
     │                              │     Extract claims →     │
     │                              │     Upsert Users table   │
     │                              │                          │
     │                              │  6. RoleAuthorization:   │
     │                              │     Check UserRoles table│
     │                              │                          │
     │     ◄── JSON response ───────┼──────────────────────────│
Parámetro Valor
Proveedor de identidad Microsoft Entra ID (Azure AD)
Protocolo OAuth 2.0 / OpenID Connect
Tipo de token JWT Bearer
Audiencia api://<client-id> y <client-id> (se aceptan tokens v1 y v2)
Emisor https://login.microsoftonline.com/{tenantId}/v2.0 y https://sts.windows.net/{tenantId}/
Registro de aplicación Un solo inquilino (AzureADMyOrg); ámbito expuesto access_as_user; sin secreto de cliente

Identidad administrada

El App Service utiliza una identidad administrada asignada por el sistema para autenticarse ante los servicios de backend, de modo que no se almacenan secretos de cliente ni certificados en la aplicación:

  • Azure SQL Database — autenticación exclusiva de Entra (la autenticación por contraseña de SQL está deshabilitada)
  • Azure Blob Storage — DefaultAzureCredential (identidad administrada en producción)
  • Microsoft Graph API — ManagedIdentityCredential con permisos de aplicación

Azure rota automáticamente las credenciales de identidad administrada.

Autorización y RBAC

AccessPoint implementa control de acceso basado en roles a nivel de aplicación, almacenado en Azure SQL y aplicado en la capa de la API en cada solicitud.

Rol Ve la información personal del solicitante Administra solicitudes Administra asignaciones Envía documentos Usuario típico
Administrador Sí Solo configuración No No Administrador de TI, propietario del sistema
SAO Sí Sí Sí No Funcionario de acceso y privacidad
Revisor Sí Solo lectura Solo lectura No Asesor jurídico, control de calidad
Custodio No No Asignaciones propias No Funcionario de registros del departamento
Colaborador No No No Tareas propias Experto en la materia
Lector No Solo lectura Solo lectura No Supervisión, auditoría

Puntos de aplicación:

  1. Políticas de autorización de la API — atributos [Authorize(Policy = "...")] de ASP.NET Core en cada acción del controlador
  2. RoleAuthorizationHandler — verifica la tabla UserRoles para conocer la pertenencia a roles del usuario autenticado
  3. ResourceOwnerAuthorizationHandler — valida la propiedad a nivel de recurso (por ejemplo, un colaborador solo puede acceder a sus propias tareas)
  4. PiiFilterMiddleware — elimina los campos de información personal del solicitante de las respuestas JSON para los roles restringidos (custodio, colaborador, lector)

Todos los puntos de conexión de escritura de la API aplican los roles del lado del servidor a nivel de controlador. La reclasificación de documentos tiene en cuenta el alcance: quien recopiló un documento es quien puede reclasificarlo, y una vez cerrada una solicitud, las modificaciones en su grafo de objetos devuelven HTTP 409, con un pequeño conjunto de excepciones deliberadas (correspondencia posterior al cierre, depuración por retención y reapertura). Los roles tienen alcance y se pueden restringir a recursos específicos (alcance global, de solicitud, de asignación o de tarea). Al primer usuario que accede al sistema se le asignan de forma automática los roles de Administrador y SAO.

Residencia y soberanía de datos

Todos los datos residen en el inquilino de Azure del cliente, en la región seleccionada durante la implementación. Ningún dato se transmite ni se almacena en otras regiones, a menos que el cliente configure explícitamente la replicación geográfica de Azure.

Departamentos federales canadienses: para conocer los requisitos de residencia de datos específicos del GC, la asignación de controles ITSG-33 y el cumplimiento de las GC Cloud Guardrails, consulte la Referencia de controles de seguridad de GC.

Ubicaciones de los datos del cliente

Tipo de datos Ubicación de almacenamiento Controlado por
Registros de solicitudes, datos de usuario, registro de auditoría Azure SQL Database Suscripción de Azure del cliente
Documentos cargados Azure Blob Storage Suscripción de Azure del cliente
Telemetría de la aplicación Application Insights / Log Analytics Suscripción de Azure del cliente
Activos del componente web de SPFx CDN de SharePoint Inquilino de M365 del cliente
Configuración del inquilino (URL de la API, ID de cliente) Entidades de almacenamiento del inquilino de SharePoint Inquilino de M365 del cliente

Qué cruza los límites del inquilino

Flujo de datos Dirección Qué se transmite Finalidad
Validación de licencia API → Plataforma del editor Clave de licencia (cadena opaca), ID del inquilino Validar la suscripción activa
Notificaciones por correo electrónico API → Microsoft Graph Contenido de correo electrónico mediante Mail.Send Enviar notificaciones desde el buzón compartido
Notificaciones de Teams API → Plataforma del editor → Microsoft Graph Tipo de actividad, texto de vista previa, ID del destinatario, parámetros de plantilla Enviar notificaciones de fuente de actividad de Teams (mediante proxy a través de la aplicación empresarial multiinquilino del editor porque sendActivityNotification debe ser llamado por la aplicación propietaria del manifiesto de Teams)
Búsqueda de perfil de usuario SPFx → Microsoft Graph Consultas de búsqueda de usuarios Selector de personas, resolución de usuarios

Qué nunca sale del inquilino

  • Los registros de solicitudes y la información personal del solicitante
  • Los documentos cargados
  • El historial de auditoría
  • Los datos de configuración (tipos de solicitud, plantillas, numeración)
  • Las asignaciones de roles

Cifrado

En tránsito

Conexión Protocolo TLS mínimo
Navegador → App Service HTTPS (aplicado, httpsOnly: true) TLS 1.3
SPFx → App Service HTTPS (aplicado por el contexto de SharePoint) TLS 1.3
App Service → Azure SQL TDS con cifrado (Encrypt=True) TLS 1.2+
App Service → Blob Storage HTTPS (identidad administrada) TLS 1.2+
App Service → Microsoft Graph HTTPS TLS 1.2+

El App Service aplica TLS 1.3 como mínimo en la puerta de enlace (se rechazan TLS 1.0/1.1/1.2); las conexiones salientes a los servicios de backend de Azure negocian TLS 1.2 o superior.

En reposo

Almacén de datos Cifrado Gestión de claves
Azure SQL Database Cifrado transparente de datos (TDE) Claves administradas por Microsoft (predeterminado) o claves administradas por el cliente (CMK)
Azure Blob Storage Cifrado del servicio de almacenamiento (SSE), AES-256 Claves administradas por Microsoft (predeterminado) o claves administradas por el cliente (CMK)
Application Insights Cifrado de la plataforma Claves administradas por Microsoft

A nivel de aplicación

Función Mecanismo
Tokens del visor de documentos ASP.NET Core Data Protection (token de estilo WOPI, TTL de 15 minutos, verificación cruzada de inquilino en cada llamada anónima al visor)
Firmas electrónicas de certificación Hash SHA-256 del firmante y la marca de tiempo, almacenado en campos de auditoría

Privacidad desde el diseño

AccessPoint implementa controles de privacidad estructurales que se aplican en la capa de la API, no solo en la interfaz de usuario.

Middleware de filtrado de información personal

Un middleware a nivel de respuesta intercepta todas las respuestas JSON y elimina los campos de información personal para los usuarios con roles restringidos (custodio, colaborador, lector), del lado del servidor, independientemente de lo que solicite el cliente. Campos eliminados: requestorName, requestorEmail, requestorPhone, requestorAddress, subjectName, subjectDateOfBirth.

Ocultamiento de información personal en notificaciones

Cuando se envían notificaciones a custodios o colaboradores, la información personal del solicitante se reemplaza por texto de marcador de posición en el propio contenido de la notificación, incluso si la plantilla de notificación incluye campos de combinación de información personal.

Aislamiento de custodios / colaboradores

  • Los custodios solo ven sus solicitudes asignadas y trabajan a partir de instrucciones depuradas
  • Los colaboradores solo ven sus tareas asignadas
  • Ningún rol puede buscar, explorar ni acceder a solicitudes fuera de su alcance

Registro, monitoreo y auditoría

Application Insights

Toda la telemetría de la API se envía a la instancia de Application Insights del cliente:

Señal Qué se captura
Trazas de solicitudes Método HTTP, ruta, código de estado, duración, ID de correlación
Seguimiento de dependencias Consultas SQL, operaciones de Blob, llamadas a la API de Graph (duración, éxito/error)
Excepciones Excepciones no controladas con seguimientos de pila
Métricas personalizadas Tiempos de procesamiento de solicitudes, duraciones de conversión de documentos

Registro de auditoría

AccessPoint mantiene un registro de auditoría integral en la tabla AuditHistory (Azure SQL), que registra el tipo de entidad, el ID de entidad, la acción (Crear, Actualizar, Eliminar, Cambio de estado), el nombre del campo, los valores anteriores/nuevos, un motivo de cambio opcional (capturado en las transiciones de estado como el cierre y la reapertura), el usuario autenticado y una marca de tiempo UTC. Los registros de auditoría son inmutables: no se pueden modificar ni eliminar a través de la API.

Libro mayor de auditoría encadenado por hash

Además del registro de auditoría a nivel de campo, un AuditLedger de solo adición y a prueba de alteraciones (cadena de hash SHA-256) registra las acciones en todos los módulos. La integridad se puede verificar del lado del servidor, y se puede exportar un paquete de evidencia listo para uso judicial ante una solicitud.

Concurrencia optimista

Las entidades de alta contención (Requests, Documents, CustodianAssignments) llevan cada una un token de concurrencia ROWVERSION de SQL Server. El cliente repite la versión de fila al actualizar; si otro proceso de escritura ha modificado la fila mientras tanto, el guardado se rechaza con HTTP 409 ("Concurrent edit detected") en lugar de sobrescribirlo silenciosamente.

Registro de depuración por retención

Cuando se depuran registros conforme a la política de retención, la depuración elimina los blobs de documentos, los PDF convertidos, las anotaciones y los paquetes de exportación de Blob Storage, además de los registros de la base de datos. La tabla RetentionPurgeLog registra qué se eliminó, cuándo y por quién: un registro de nivel de cumplimiento que sobrevive a la eliminación de los datos.

Log Analytics y alertas

Application Insights está respaldado por un área de trabajo de Log Analytics con retención configurable (90 días de forma predeterminada; configurable entre 30 y 730 días). Los datos se pueden exportar a Microsoft Sentinel o a un SIEM existente. La implementación de Bicep incluye dos alertas de métricas predeterminadas en el App Service:

Alerta Gravedad Condición Ventana
Errores del servidor 2 (Advertencia) Recuento de HTTP 5xx > 5 5 minutos
Latencia alta 3 (Informativo) Tiempo de respuesta promedio > 5 segundos 15 minutos

Los clientes pueden personalizar los umbrales y agregar grupos de acción (correo electrónico, SMS, webhook) en Azure Portal.

←
Previous Introducción a AccessPoint
Next Referencia de controles de seguridad de GC
→