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 (v2.1.0).

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
• Registros de video y audio — grabaciones revisadas en el mismo espacio de trabajo de documentos: cargas reanudables de hasta 2 GB, transcripciones y subtítulos, tachado basado en tiempo (recuadro, desenfoque, pixelado, silenciar, pitido, distorsión de voz, retención) con una excepción en cada marca, detección y seguimiento de rostros dentro del inquilino, y copias de divulgación MP4/MP3 con las marcas grabadas y un manifiesto hash
• 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
• Asistencia con IA (opcional) — sugerencias y generación de borradores respaldadas por Azure OpenAI que se ejecutan enteramente en la propia suscripción del cliente: resúmenes de documentos, sugerencias de tachado con IA, generación de borradores fundamentada, clasificación de recepción, prellenado de respuestas de evaluación, búsqueda semántica y detección de duplicados, un asistente por caso consciente del estatuto (Ask AccessPoint — citas en las que se puede hacer clic, conversaciones guardadas, un modo Mi carga de casos), respuestas de datos de «Ask AccessPoint», un manual de la jurisdicción que fundamenta las respuestas de procedimiento, traducción automática y un resumen diario — todo opcional por inquilino, registrado solo con metadatos, con divulgación de actividad de IA por registro

Todos los módulos se basan en paquetes de jurisdicció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 selección están basados en datos
• Multilingüe desde el diseño — un sistema de traducción de tres niveles que admite 11 idiomas
• Instantes en UTC, días de calendario en la zona del usuario — cada marca de tiempo se almacena como un instante UTC, pero los hechos de calendario estatutarios (fecha de recepción, fecha límite, vencido, días restantes) se calculan sobre el calendario local de quien llama, a partir de la zona horaria que el elemento web envía con cada solicitud

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    │
│                              │         │    └─ AccessPoint document engine      │
│                              │         │                                         │
│  SharePoint Tenant Storage   │         │  Azure SQL Database                     │
│  (API URL override,          │         │  (224 tables, 3,474 fields)            │
│   optional)                  │         │                                         │
└──────────────────────────────┘         │  Azure Blob Storage                     │
                                         │  (Documents, converted PDFs, renditions)│
        Microsoft Graph API              │                                         │
        ┌──────────────────────┐         │  Application Insights + Log Analytics   │
        │  Mail.Send           │◄────────│  (Telemetry, diagnostics)               │
        │  User.ReadBasic.All  │         │                                         │
        │  TeamsActivity.Send  │         │  (opt-in) Azure AI Search               │
        │  TeamsAppInstall     │         │  (opt-in) Azure OpenAI                  │
        │  Calendars.Read      │         │  (opt-in) Azure Document Intelligence   │
        │  AiEnterprise…Read   │         │  (opt-in) Azure AI Speech               │
        │  OnlineMeeting…Read  │         │  (opt-in) Defender for Storage          │
        │                      │         │  (opt-in) Container Apps media job      │
        │                      │         └─────────────────────────────────────────┘
        └──────────────────────┘  ← M365 record capture (delegated + app-only Copilot)

Inventario de componentes

Qué opera el editor

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 Jurisdicción.

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, además de las opciones opcionales de AI Search, Azure OpenAI, Document Intelligence, Azure AI Speech, Defender for Storage, procesamiento de medios, aislamiento de red y el contenedor de evidencia WORM) 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. Una elección obligatoria de tipo de implementación protege las reimplementaciones: Nueva instalación crea el servidor SQL con prioridad Entra (el principal que realiza la implementación se convierte en el administrador inicial de Entra, con autenticación exclusiva de Entra desde el origen — nunca existe ninguna credencial de SQL), mientras que Actualizar instalación existente conserva la configuración de aplicación del operador y no toca el acceso a la base de datos. 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, reafirma la autenticación exclusiva de Entra en SQL (una salvaguarda: la plantilla ya la aplica), concede permisos de Microsoft Graph a la identidad administrada (la alternativa con script a la página Finalizar instalación del editor), configura la anulación opcional de la URL de la API mediante entidad de almacenamiento de SharePoint, y aprueba las solicitudes de permisos de API de SPFx. Cada paso se puede omitir de forma independiente.

Los permisos de Graph normalmente se conceden a través de la página Finalizar instalación del editor: la implementación emite una salida finishSetupUrl que un administrador de Entra del cliente abre para conceder cada permiso de identidad administrada en un único pase idempotente (se vuelve a ejecutar después de las actualizaciones para incorporar nuevos permisos).

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, HTTP/2 habilitado y Microsoft Defender for SQL activado de forma predeterminada (con opción de exclusión). 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 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. PermissionService:   │
     │                              │     resolve roles +      │
     │                              │     permission grants    │
     │                              │                          │
     │     ◄── JSON response ───────┼──────────────────────────│

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 (el servidor se crea con prioridad Entra; nunca existe ninguna credencial de SQL)
• Azure Blob Storage — DefaultAzureCredential (identidad administrada en producción)
• Microsoft Graph API — ManagedIdentityCredential con permisos de aplicación
• Recursos opcionales (AI Search, Azure OpenAI, Document Intelligence, Azure AI Speech, las colas de almacenamiento del trabajo de medios) — exclusivamente con identidad administrada, con la autenticación local/por clave deshabilitada; la cuenta de Speech y el trabajo de medios tienen cada uno su propia identidad administrada para el acceso al almacenamiento, y una imagen del trabajador reflejada por el cliente se extrae con la identidad del trabajo mediante una concesión AcrPull

Azure rota automáticamente las credenciales de identidad administrada.

Autorización y RBAC

AccessPoint implementa un modelo de permisos granular y configurable por inquilino, almacenado en Azure SQL y aplicado en la capa de la API en cada solicitud: un catálogo de códigos de permiso atómicos definido por el producto (por ejemplo, request.modify, document.view, redaction.approve, request.view.pii) se agrupa en roles, y cada acción del controlador está condicionada a un código de permiso.

Puntos de aplicación:

1. Atributos [RequirePermission(code)] — un proveedor de políticas dinámico asigna cada acción del controlador a un código de permiso del catálogo
2. PermissionService — resuelve los permisos efectivos de quien realiza la llamada (roles permanentes unidos a las concesiones de relación por destino), con comprobaciones limitadas por objeto a nivel de solicitud/documento/asignación/tarea
3. Comprobaciones de titularidad a nivel de recurso — por ejemplo, un Colaborador solo puede acceder a sus propias tareas; un Custodio, solo a sus propias asignaciones
4. PiiFilterMiddleware — elimina los campos de PII del solicitante de las respuestas JSON para cualquier usuario que no tenga el permiso de ver la PII del solicitante

Todos los puntos de conexión de escritura de la API aplican los permisos 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). Las asignaciones de roles permanentes tienen un alcance definido (global, de solicitud, de asignación o de tarea), pueden tener una duración limitada de forma opcional, y los roles de relación nunca se escriben como asignaciones permanentes: se derivan por destino a partir de los registros de trabajo subyacentes. Al primer usuario que accede al sistema se le asigna de forma inicial el rol de Administrador, y una salvaguarda del lado del servidor impide eliminar al último Administrador activo.

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

Qué cruza los límites del inquilino

Qué nunca sale del inquilino

• Los registros de solicitudes y la información personal del solicitante
• Los documentos cargados, las grabaciones, las transcripciones y las copias divulgadas
• El historial de auditoría
• Los datos de configuración (tipos de solicitud, plantillas, numeración)
• Las asignaciones de roles
• Las indicaciones y las respuestas de Asistencia con IA: cuando Asistencia con IA está implementada, el recurso de Azure OpenAI se ejecuta en la propia suscripción y región del cliente; Microsoft no entrena modelos con el contenido, y el contenido de las indicaciones y las respuestas no se almacena (solo los metadatos de uso, para el medidor de presupuesto y la divulgación de la participación de la IA de la exportación de auditoría del caso)
• Las notificaciones integradas en la aplicación y por correo electrónico/Outlook — el feed integrado se sirve desde la propia API del cliente; el correo electrónico se envía desde el propio buzón compartido del cliente mediante Mail.Send. Ninguna de las dos transita por el editor. Solo la fuente de actividad de Teams, que es opcional, envía algún dato fuera del inquilino, y eso también se puede minimizar o eliminar (véase más abajo)

Uso compartido de datos de notificación de Teams (opcional)

De acuerdo con la promesa de soberanía de datos, el único dato del inquilino que sale del límite para las notificaciones es una carga útil opcional de actividad de Teams, y se puede minimizar o eliminar por completo. Cada notificación se entrega en hasta tres canales; dos siempre permanecen dentro del inquilino (el feed integrado, servido desde la API del cliente, y el correo electrónico/Outlook, enviado desde el propio buzón compartido del cliente). La fuente de actividad de Teams es una comodidad: en su modo predeterminado, la API del cliente envía (POST) una pequeña carga útil a la aplicación multiinquilino del editor, que llama a Graph sendActivityNotification (que debe ser invocado por la aplicación propietaria del manifiesto de Teams). El editor no almacena nada de eso y solo registra los GUID del destinatario y del inquilino.

Campos en la carga útil predeterminada de Teams (retransmitida por el editor) y lo que elimina el interruptor Minimizar:

La PII del solicitante nunca está en la carga útil — no existe ningún campo de nombre/correo electrónico del solicitante, y las notificaciones a Custodios/Colaboradores tienen la PII oculta desde el origen en cualquier caso. Dos controles restringen esto aún más:

• Minimizar (Notifications:TeamsMinimalPayload, un interruptor de inquilino) reemplaza previewText, topicText y actorName con marcadores de posición neutros, de modo que los nombres, los títulos y el texto libre nunca salen del inquilino — solo lo hacen los identificadores de enrutamiento/vínculo profundo. No se requiere ningún cambio en el manifiesto.
• Eliminar (Notifications:TeamsRelayMode=Direct) hace que la API del cliente llame ella misma a Graph sendActivityNotification con su identidad administrada, de modo que ninguna carga útil llega al editor. Requiere el rol de aplicación TeamsActivity.Send en la identidad administrada de la API y que el webApplicationInfo.id del manifiesto de Teams apunte a la propia aplicación del cliente; consulte la Guía de implementación.

Cifrado

En tránsito

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

A nivel de aplicación

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, además de los campos de identidad/contacto del representante y las notas de verificación de identidad.

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:

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 generar una exportación de auditoría del caso (anteriormente «paquete de evidencia») lista para uso judicial para 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

Un único motor RetentionService dispone de los registros que han superado su plazo en cinco registros: solicitudes, evaluaciones, incidentes, quejas y riesgos de privacidad independientes, impulsado por un RetentionPeriodMonths + RetentionStartPoint por tipo (NULL = conservar indefinidamente, el valor predeterminado). Los registros que no deben superar su plazo quedan excluidos por construcción (una evaluación En vigor, un riesgo Aceptado, un riesgo vinculado a un caso), y un registro expirado del que todavía depende otro caso abierto se rechaza del lado del servidor; la elegibilidad se vuelve a evaluar en el momento de la purga. Cuando se purga un registro, el motor 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 — EntityName identifica de qué registro proviene, junto con una instantánea de su número, tipo, fecha de cierre y cantidad de documentos —, un rastro de nivel de cumplimiento que sobrevive a la eliminación de los datos y que nunca se purga a sí mismo.

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:

Cuando se proporciona una dirección de correo electrónico de alerta en el momento de la implementación, se crean junto a ellas alertas de consulta programada para errores de autenticación de SQL, fallos del trabajo de medios y un estancamiento de la cola de medios. Los clientes pueden personalizar los umbrales y agregar grupos de acción (correo electrónico, SMS, webhook) en Azure Portal.