En el examen DP-300, la sección de autenticación y autorización pregunta cómo diseñas 'quién puede entrar a la base de datos' y 'qué puede hacer una vez dentro.' Estos conceptos corresponden a Autenticación y Autorización respectivamente. En el entorno de Azure SQL cada uno opera en una capa completamente diferente. El examen evalúa la capacidad de elegir la opción correcta para un escenario concreto, no la memorización pura.
SQL Authentication vs Microsoft Entra ID Authentication
Imagina dos formas de entrar a un edificio de oficinas: un código PIN emitido por la administración del propio edificio, o un carnet emitido por Recursos Humanos de la empresa matriz. SQL Authentication es la primera opción. El motor de la base de datos almacena y valida por sí mismo los nombres de usuario y contraseñas. Es compatible con el modelo familiar del SQL Server local y con clientes heredados, pero debes gestionar por separado la rotación de contraseñas y deshabilitar cuentas cuando los empleados se van.
Microsoft Entra ID authentication es el modelo del carnet corporativo. El sistema de identidad central de tu organización gestiona la autenticación, por lo que no se almacena ninguna contraseña en el motor SQL. Cuando la cuenta de Entra ID de un empleado se deshabilita al marcharse, el acceso a SQL queda revocado automáticamente. MFA, Acceso Condicional y gestión de permisos basada en grupos están disponibles de forma nativa.
Submodos de Entra ID: (inicio de sesión silencioso mediante federación con AD local), (credenciales de Entra ID directamente), (inicio de sesión interactivo con MFA — aparece con más frecuencia en el examen), y (no interactivos, para aplicaciones y servicios).
!Autenticación SQL vs autenticación de Microsoft Entra ID
Login, User y Contained User
Para entrar a un restaurante del barrio, primero cruzas la puerta (credencial de entrada) y luego te asignan una mesa (asignación de asiento). La seguridad de SQL Server sigue exactamente estas dos etapas.
Un es una entidad de seguridad a nivel de servidor almacenada en la base de datos . Otorga el derecho de conectarse a la instancia de SQL Server. Un es una entidad de seguridad a nivel de base de datos. Debes mapear un Login a un User dentro de una base de datos específica para que esa entidad pueda acceder a las tablas. El problema surge al mover la base de datos a otro servidor: el User sigue existiendo dentro de la base de datos, pero el Login correspondiente está ausente en el nuevo servidor — el 'usuario huérfano' (orphaned user).
Los resuelven esto. La información de autenticación reside dentro de la propia base de datos de usuario, no en master, por lo que la base de datos puede moverse a cualquier servidor sin romper la autenticación — enfoque recomendado para Azure SQL Database. Crea un usuario de Entra ID como Contained User con . Registra un grupo completo de Entra ID y todos sus miembros obtienen acceso de una vez.
Modelo de Permisos Basado en Roles
En una oficina de 100 personas, repartir llaves individuales para cada sala es inviable. En su lugar, emites tarjetas por rol — 'Tarjeta del Equipo de Ventas,' 'Tarjeta del Equipo de Dev' — de modo que cuando alguien cambia de equipo, solo se intercambia la tarjeta.
Fixed Server Roles a nivel de servidor: (autoridad completa), (crear, modificar, eliminar bases de datos), (gestión de Logins + GRANT/REVOKE/DENY). Nota crítica del examen: puede conceder permisos que él mismo no posee, habilitando efectivamente una escalada de privilegios al nivel de sysadmin — el examen evalúa este riesgo con frecuencia.
Fixed Database Roles a nivel de base de datos: (todo), (SELECT en todas las tablas), (INSERT/UPDATE/DELETE), (gestión de roles + GRANT/REVOKE), (solo agregar o eliminar cuentas de usuario). Azure SQL Database no admite porque PaaS elimina el ámbito a nivel de servidor — usa User-Defined Database Roles en su lugar.
GRANT, DENY y REVOKE
Un administrador de almacén concede al empleado A acceso a una sala de almacenamiento. Más tarde llega inventario sensible. ¿Cómo bloquea la entrada de A sin eliminar todos sus permisos?
asigna un permiso. elimina un permiso concedido o denegado explícitamente. rechaza explícitamente un permiso. La regla decisiva: DENY siempre tiene prioridad sobre GRANT. Aunque una entidad herede GRANT a través de la pertenencia a un rol, un DENY directo sobre el mismo objeto gana. Agregar permite al receptor transferir el mismo permiso a otros usuarios — útil para delegar, pero puede crear cadenas de permisos difíciles de rastrear. Un GRANT a nivel de esquema se aplica a todos los objetos de ese esquema; un GRANT a nivel de objeto apunta a tablas o vistas específicas. El privilegio mínimo siempre empieza desde el ámbito más estrecho.
Managed Identity — Sin Contraseñas en tu Código
Un desarrollador embebe usuario y contraseña en la cadena de conexión y por error sube ese archivo a un repositorio público. Managed Identity elimina este riesgo desde la raíz.
Managed Identity es una identidad basada en Entra ID asignada automáticamente a un recurso de Azure — una máquina virtual, App Service o Azure Functions. La plataforma Azure emite y rota tokens automáticamente, por lo que ninguna contraseña o certificado necesita vivir en el código ni en archivos de configuración. System-Assigned Managed Identity comparte el ciclo de vida de su recurso. User-Assigned Managed Identity puede compartirse entre varios recursos. Para usarla con Azure SQL, configura la Managed Identity como administrador de Entra ID en el servidor SQL, o regístrala como Contained User y asigna los roles adecuados.
Comparación de Métodos de Autenticación
| Escenario | Método Recomendado | |-----------|--------------------| | App heredada, mismo modelo que SQL local | SQL Authentication | | Login con cuenta de organización y MFA | Entra ID Universal with MFA | | Inicio de sesión automático con credenciales de dominio AD local | Entra ID Integrated | | App de Azure conecta a SQL sin almacenar credenciales | Managed Identity | | Autenticación entre servicios, gestión de secretos aceptable | Service Principal |
La diferencia fundamental entre SQL Authentication y Entra ID authentication es dónde viven las credenciales. SQL Authentication las guarda en el motor de base de datos; Entra ID las guarda en el sistema de identidad central. Para alinear el acceso a la base de datos con el ciclo de vida del empleado — incorporación, baja, cambio de rol — Entra ID authentication es la única opción viable.
Trampas Comunes del Examen
Si un bibliotecario tiene una llave maestra para cada libro de la biblioteca, eso no es privilegio mínimo. El examen DP-300 construye con frecuencia trampas alrededor de opciones con permisos excesivos.
"Eliminar la gestión de contraseñas SQL, usar cuentas de empresa" — elige Entra ID authentication. "Todas las tablas legibles, sin modificaciones" — elige (no , que viola el privilegio mínimo). "Delegar solo concesión y revocación de permisos, sin acceso a datos" — elige , no (que solo agrega o elimina cuentas de usuario). "Conectar app de Azure a SQL sin credenciales en el código" — elige Managed Identity (Service Principal requiere gestión de secretos). falla en Azure SQL Database porque PaaS elimina el ámbito a nivel de servidor. puede conceder permisos más allá de los propios, creando una ruta de escalada al nivel de sysadmin.
Resumen para el Examen
"Eliminar gestión de contraseñas SQL, login con cuenta de empresa" -- Microsoft Entra ID authentication "App de Azure conecta a SQL sin credenciales en el código" -- Managed Identity "Inicio de sesión automático con credenciales de dominio AD local" -- Entra ID Integrated (requiere federación AD) "Login interactivo con MFA" -- Universal with MFA "Mover base de datos a otro servidor, autenticación intacta" -- Contained Database User "Registrar grupo de Entra ID en una base de datos" -- CREATE USER [nombre-grupo] FROM EXTERNAL PROVIDER "Privilegio mínimo de solo lectura" -- db_datareader "Gestionar permisos solamente, sin acceso a datos" -- db_securityadmin "Solo agregar o eliminar cuentas de usuario" -- db_accessadmin "DENY siempre tiene prioridad sobre GRANT" -- Regla de prioridad de DENY "Delegación de permisos a nivel de servidor, rol peligroso" -- securityadmin (efectivamente nivel sysadmin) "CREATE SERVER ROLE falla en Azure SQL Database" -- PaaS, usar User-Defined Database Role
Microsoft Entra ID = ciclo de vida de identidad central, Managed Identity = sin secretos en el código, Contained User = migración de BD segura, DENY = siempre gana