Proteger tu portal de Power Pages: análisis en profundidad de los permisos de tabla y los ámbitos

By Mirko Peters · 2026-08-11

¡Bienvenido de nuevo al blog del podcast! Al crear aplicaciones web orientadas a clientes en Microsoft Power Platform, la seguridad no puede ser un pensamiento posterior. Power Pages es una herramienta increíble para desplegar rápidamente portales externos robustos conectados directamente a Dataverse. Sin embargo, un gran poder conlleva una gran responsabilidad: en concreto, la responsabilidad de

Automatically translated with AI from the original post. Read the English original

¡Bienvenido de nuevo al blog del podcast! Al crear aplicaciones web orientadas a clientes en Microsoft Power Platform, la seguridad no puede ser un pensamiento posterior. Power Pages es una herramienta increíble para desplegar rápidamente portales externos robustos conectados directamente a Dataverse. Sin embargo, un gran poder conlleva una gran responsabilidad: en concreto, la responsabilidad de asegurarte de que los datos sensibles de tu organización no se filtren accidentalmente al público ni crucen los límites organizativos.

En este artículo vamos a ampliar en profundidad los conceptos fundamentales de seguridad de arquitectura que tratamos en nuestro episodio reciente. Si aún no lo has escuchado, no dejes de consultar el episodio Build Customer Portals with Power Pages and Dataverse, con una guía completa para configurar tu entorno, gestionar identidades externas y desplegar tu primera solución de portal.

Vamos a profundizar en la mecánica de seguridad de Power Pages, empezando por cómo planificar los límites de tus datos y dominar los permisos de tabla.

Introducción a la seguridad de Power Pages

Cuando creas un sitio de Power Pages por primera vez, la plataforma te ofrece un lienzo flexible y muy personalizable. Pero bajo ese lienzo hay una conexión directa con tu entorno de Microsoft Dataverse. Si las configuraciones de seguridad están mal gestionadas, cada registro de tu base de datos podría quedar expuesto a través de un endpoint sin protección o de una vista de lista mal delimitada.

La seguridad en Power Pages se basa en una estrategia de defensa por capas. En la capa externa tienes los mecanismos de autenticación, como Azure AD B2C, las cuentas locales o los proveedores de identidad externos, que garantizan que los usuarios demuestren quiénes son. En la capa interna tienes los roles web y los permisos de tabla de Dataverse. Estos permisos determinan con precisión qué pueden ver, crear, actualizar o eliminar las identidades autenticadas. Hacerlo bien marca la diferencia entre un portal empresarial seguro y una gran brecha de datos esperando a ocurrir.

Planificar los límites de tus datos y los permisos de tabla

Antes de tocar un solo botón en Power Pages Studio, necesitas coger una pizarra y trazar con detalle los límites de tus datos. Probablemente sean los 15 minutos más críticos de todo el ciclo de vida de tu proyecto de portal.

Empieza creando un inventario completo de cada tabla de Dataverse que pienses exponer a tus usuarios externos. Para cada tabla, define el mínimo absoluto de acciones CRUD necesarias. ¿Realmente un cliente necesita poder eliminar una factura, o solo debería tener acceso de lectura y adición? Una vez definidas las acciones, debes determinar el ámbito de filas de cada tabla:

• Ámbito de contacto: el usuario solo puede interactuar con los registros asociados directamente a su registro de contacto.
• Ámbito de cuenta: el usuario puede interactuar con los registros asociados a toda su empresa o cuenta.
• Ámbito global: el usuario puede ver todos los registros de toda la tabla (normalmente reservado para artículos públicos de la base de conocimientos o metadatos).

Al definir estos límites desde el principio, estableces una base de privilegio mínimo antes de crear cualquier configuración en tu entorno de desarrollo.

Entender los ámbitos de contacto y de cuenta

Uno de los puntos de confusión más habituales para los creadores que se inician en Power Pages es entender los matices entre los ámbitos de contacto y de cuenta. Elegir el ámbito equivocado puede arruinar por completo la experiencia de usuario al ocultar datos relevantes de la empresa o, sin querer, exponer información confidencial a personas no autorizadas.

El ámbito de contacto está diseñado para portales de tipo consumidor individual. Si un usuario inicia sesión y envía un ticket de soporte, un permiso con ámbito de contacto garantiza que solo pueda ver los casos en los que figura explícitamente como contacto principal o creador. Si otro usuario de la misma empresa inicia sesión, no verá los tickets de soporte personales de su compañero.

Por otro lado, el ámbito de cuenta está pensado para arquitecturas de portal B2B. En un escenario B2B, quieres que un gestor de cuentas o un responsable principal de compras pueda ver todos los casos, pedidos y facturas asociados a la cuenta matriz de su empresa. Cuando asignas un ámbito de cuenta a un permiso de tabla, el portal evalúa la cuenta principal vinculada al registro de contacto del usuario que ha iniciado sesión y, a continuación, muestra todos los registros secundarios relacionados que pertenecen a esa organización. Definir correctamente esta relación en Dataverse es fundamental para el éxito de un proyecto B2B.

Definir roles web y evitar la trampa del rol Usuarios autenticados

Los roles web son el puente entre tus usuarios autenticados y tus permisos de tabla de Dataverse. De forma predeterminada, Power Pages incluye un rol predefinido llamado "Usuarios autenticados". Aquí es donde muchos administradores caen en una trampa de seguridad peligrosa.

De forma predeterminada, cualquier usuario que inicie sesión correctamente en tu portal se incluye automáticamente en el rol Usuarios autenticados. Si asignas permisos de tabla amplios, o peor aún, permisos de ámbito global, a este rol predeterminado, todas las personas que se registren en tu sitio heredarán de forma inmediata esos privilegios tan abiertos. Se trata de un antipatrón de seguridad muy grave.

En su lugar, crea roles web personalizados y granulares, adaptados a los perfiles concretos de tus usuarios. Por ejemplo:

• CustomerUser: asignado a un ámbito de contacto para tablas operativas como Casos y Pedidos, lo que permite a los usuarios hacer seguimiento de sus propias interacciones.
• AccountManager: asignado a un ámbito de cuenta, lo que da a los responsables designados de la organización visibilidad sobre los activos de toda la empresa.
• KnowledgeBaseViewer: asignado globalmente, pero restringido estrictamente a acciones de solo lectura sobre los artículos de soporte públicos.

Elimina siempre los accesos predeterminados innecesarios y asegúrate de que los usuarios se asignan explícitamente a roles diseñados para un fin concreto, según su relación con la organización.

Reforzar la visibilidad a nivel de campo y proteger la información personal identificable (PII)

Controlar el acceso a nivel de fila mediante los ámbitos de tabla es solo la mitad de la batalla. También debes prestar mucha atención a qué datos son visibles dentro de cada fila y de cada lista. Exponer información personal identificable (PII) como números de teléfono, direcciones particulares, datos financieros o notas internas sobre empleados puede provocar graves incumplimientos normativos (como fallos del RGPD o de la CCPA).

Al crear listas y formularios básicos en Power Pages, asegúrate de depurar tus vistas de columnas sensibles. El hecho de que un campo esté oculto en el diseño del formulario de cara al usuario no significa que no pueda consultarse ni obtenerse mediante las API web subyacentes si los permisos son demasiado amplios. Utiliza vistas independientes y reforzadas (como una "PublicView" designada) que contengan exclusivamente columnas seguras y saneadas. Si determinadas columnas deben permanecer en la tabla de la base de datos, considera implementar la seguridad a nivel de columna en Dataverse para restringir por completo el acceso en el propio motor de base de datos.

Pruebas de penetración de los permisos de tu portal

Nunca des por hecho que tu modelo de seguridad funciona: tienes que demostrarlo. Antes de promocionar cualquier solución de portal a un entorno de pruebas o de producción, debes ejecutar pruebas de penetración rigurosas sobre tus permisos de tabla y tu lógica de enrutamiento.

Configura cuentas de usuario de prueba para cada uno de los roles web que hayas definido. Inicia sesión como un CustomerUser estándar e intenta ver datos que pertenezcan a otro contacto o cuenta. Prueba la manipulación directa de URL y la alteración de GUID, cambiando los identificadores de registro en la barra de direcciones del navegador, para comprobar si el servidor bloquea correctamente las solicitudes no autorizadas. Además, revisa los registros de diagnóstico y de auditoría de tu portal para verificar que los intentos de escalada de privilegios generen las respuestas 403 Forbidden adecuadas.

Conclusiones y buenas prácticas

Asegurar un portal de Power Pages requiere una planificación deliberada, un cumplimiento estricto del principio de mínimo privilegio y un conocimiento profundo de los permisos y ámbitos de tabla de Dataverse. Al alejarte de valores predeterminados peligrosos como el rol Usuarios autenticados, acotar con cuidado el acceso a tablas a los niveles de contacto o cuenta y reforzar la visibilidad a nivel de campo, podrás crear un portal de clientes que sea a la vez muy funcional y excepcionalmente seguro.

Para profundizar aún más en este tema y ver una guía de implementación completa, de principio a fin (que incluye la configuración de identidades externas, el diseño de la arquitectura de la solución y la preparación para el lanzamiento), no dejes de escuchar nuestro episodio complementario del podcast: Build Customer Portals with Power Pages and Dataverse. Gracias por leer y mantente atento a más consejos expertos para dominar Microsoft Power Platform.