Comprar un límite de control evidenciado
Una plataforma de autenticación puede anunciar funciones, registros de auditoría y aislamiento de inquilinos, pero esas etiquetas no establecen cómo se comportan los controles en los flujos de trabajo previstos por el comprador. Una evaluación de adquisiciones debe preguntar quién puede leer, exportar, cambiar y administrar los datos de qué cliente, cómo los cambios en el ciclo de vida afectan el acceso y qué evidencia registra esas acciones. Una demostración exitosa por parte de un administrador no es una prueba negativa de acceso no autorizado.
Guía de identidad multiinquilino de Azure distingue autenticación, autorización y derechos comerciales. Utilice esas distinciones para estructurar las preguntas de los compradores en lugar de asumir una función de inicio de sesión que cubra todos los recursos y acciones. Este artículo es un marco de requisitos, no una afirmación de que EmailAuth u otra plataforma designada implemente los controles propuestos. No se accedió a ningún inquilino, no se cambió el permiso ni se compró ningún producto.
Primero defina la matriz de acceso del comprador
Enumere los roles de usuario y servicio esperados, las relaciones de inquilinos y los recursos antes de revisar los nombres de roles de un proveedor. Incluya configuración de dominio, informes de autenticación, datos sin procesar, exportaciones, integraciones, administración de usuarios y configuraciones comerciales cuando sea relevante. Para cada combinación, indique si se debe permitir leer, crear, modificar, eliminar o exportar. Los límites previstos por el comprador son la referencia con la que se puede evaluar el comportamiento del producto.
No asuma que “solo lectura” excluye la exportación o que el “administrador de inquilinos” se limita a un inquilino sin evidencia. Los equipos de servicios compartidos pueden necesitar legítimamente varios clientes, mientras que los usuarios de clientes individuales deberían ver sólo su alcance aprobado. Registre esas excepciones explícitamente. Un papel amplio aceptado para una prueba no debería convertirse silenciosamente en el diseño de acceso a la producción. Exigir al proveedor que asigne roles reales a la matriz del comprador e identifique distinciones no respaldadas.
Verificar el enlace del inquilino más allá de la interfaz
un inquilino selector o un elemento de navegación oculto no es prueba suficiente de aislamiento. La identidad autenticada debe estar autorizada para el recurso solicitado en el límite del lado del servidor. Los requisitos deben cubrir lecturas directas, búsquedas, exportaciones, escrituras y trabajos en segundo plano, incluidas referencias a recursos propiedad de otro inquilino. Utilice accesorios sintéticos con datos visiblemente diferentes para que sea detectable un resultado accidental de inquilino cruzado.
La guía de Azure advierte que una mala configuración de la federación puede otorgar acceso a inquilinos no deseados. Por lo tanto, la revisión debe incluir cómo se asocian las identidades con los inquilinos, quién puede cambiar esa asociación y cómo un usuario que pertenece a varios inquilinos selecciona el alcance. No infiera la propiedad únicamente a partir de un sufijo de correo electrónico ni asuma que un identificador de inquilino proporcionado por el cliente autoriza su uso. El proveedor real debe explicar y demostrar su modelo compatible.
Pregunte qué registra realmente el registro de auditoría
Documentación del registro de auditoría de Microsoft Entra describe registros de actividad para cambios en ese entorno de identidad. Es un ejemplo útil de un modelo de registro de auditoría oficial, no una evidencia de que otra plataforma registre los mismos eventos. Un comprador debe solicitar el catálogo exacto de eventos del producto, las definiciones de campos, los controles de acceso, el comportamiento de retención y las opciones de exportación relevantes para sus propios requisitos.
Pregunte si los registros identifican suficientemente al actor, el objetivo, la acción, el tiempo, el resultado y el contexto del inquilino para investigar un cambio. Distinga la actividad del usuario de la actividad de identidad del servicio y las acciones exitosas de los intentos denegados. No asuma que cada intento fallido de autorización se registra simplemente porque aparecen cambios administrativos. Del mismo modo, es posible que un registro que muestre que se envió una solicitud no muestre si se completó el cambio resultante. Exija ejemplos reales con datos confidenciales redactados y limitaciones indicadas.
Revisar el acceso y la integridad del registro como controles
Un registro de auditoría puede contener en sí mismo información confidencial sobre la identidad y el cliente. Defina quién puede verlo, buscar entre inquilinos, exportarlo y configurar su retención. Un administrador que puede cambiar una configuración y borrar la única evidencia presenta un modelo de responsabilidad diferente al de uno con registros conservados de forma independiente. Pregunte al proveedor cómo funcionan esos controles, pero no afirme inmutabilidad o resistencia a la manipulación sin evidencia actual.
La retención debe especificarse según los términos reales respaldados por el producto y las obligaciones del comprador, no por un período universal inventado. Aclare qué eventos están disponibles en la interfaz, API y archivo exportado y si esas vistas tienen la misma cobertura. Revise el manejo de zonas horarias y los identificadores para que los registros puedan correlacionarse sin depender de nombres que puedan cambiar. No se recuperaron registros de auditoría para este manuscrito.
Pruebe los cambios del ciclo de vida y el acceso al servicio
La reducción de roles, la desactivación de usuarios y la revocación de credenciales son eventos separados. RFC 7643 describe el atributo activo SCIM dejando su significado definitivo al proveedor del servicio. Esto ilustra por qué un comprador no puede asumir que una actualización de aprovisionamiento revoca todas las sesiones existentes o las credenciales de integración. Requerir una explicación actual de la sesión del producto y el comportamiento de acceso no interactivo.
El plan de aceptación debe incluir un usuario cuyo rol se reduce mientras existe una sesión, una identidad deshabilitada, una integración con alcance limitado y un administrador autorizado. Verificar el resultado de acceso previsto en cada caso, incluyendo exportaciones y operaciones directas de recursos. Se trata de comprobaciones propuestas para un entorno aislado autorizado, no de permiso para probar el servicio de producción de un proveedor o el inquilino de otro cliente. Aquí no se realizó tal acción.
Una hoja de trabajo de aceptación del comprador
Cree una hoja de trabajo con los requisitos, el motivo comercial, el reclamo del proveedor, la configuración admitida, la identidad del dispositivo, el inquilino, la acción, el resultado esperado, la evidencia real y la limitación no resuelta. Mantenga las pruebas de las acciones permitidas separadas de las pruebas de las acciones denegadas. Incluya la versión del producto, la fecha de la prueba y el entorno para que el resultado siga siendo interpretable después del lanzamiento. Si una función está planificada en lugar de implementada, registre ese estado sin tratarla como cobertura actual.
Para los registros de auditoría, agregue el evento esperado y la referencia del registro observado para cada acción donde se requiera el registro. Una prueba que niega correctamente el acceso pero no produce la evidencia de auditoría esperada tiene un resultado diferente de una que satisface ambos criterios. Registrar quién acepta alguna limitación y si se aprueba un control compensatorio. No convierta la puntuación de la lista de verificación de adquisiciones en una garantía de seguridad futura.
Diagnóstico ficticio: un espectador que sabe exportar
Un comprador ficticio ve una demostración de un proveedor en la que un espectador no puede editar la configuración del dominio. Inicialmente, el comprador marca la función de solo lectura como satisfactoria. Sin embargo, la matriz prevista también prohíbe las exportaciones masivas de datos sin procesar de clientes. La demostración nunca probó exportaciones, solicitudes directas de recursos o acceso al informe de otro inquilino. La restricción observada cubre sólo una acción.
La respuesta propuesta es solicitar evidencia autorizada basada en elementos fijos de las operaciones faltantes y revisar los registros de auditoría resultantes. Si el producto no puede separar la visualización de la exportación, el comprador debe decidir si esa limitación es aceptable en lugar de cambiar el nombre del papel y asumir que el riesgo desapareció. Este es un ejercicio de adquisición ficticio, no un hallazgo sobre EmailAuth ni ningún proveedor designado.
Mantenga limitada la conclusión de compra
Una conclusión útil identifica los requisitos cumplidos por la evidencia, los requisitos no cumplidos, las limitaciones aceptadas por el propietario y las pruebas aún abiertas. Distingue las opciones de configuración del comportamiento inherente del producto y no promete un aislamiento perfecto de un conjunto de pruebas finito. La decisión se puede informar sin afirmar que todas las versiones o configuraciones futuras estén cubiertas.
El catálogo requiere una matriz de acceso y pruebas negativas para lecturas, exportaciones, escrituras y cambios en el ciclo de vida entre inquilinos. Esas pruebas originales permanecen abiertas. La revisión de especialistas humanos, la aplicabilidad de las fuentes, las rutas de producción, la accesibilidad y la autorización del propietario también permanecen abiertas. Este borrador proporciona el método de evaluación, no una recomendación de compra basada en evidencia ejecutada, y no se ha realizado ningún compromiso comercial ni concesión de acceso.