Contenido del curso
José Bernardo Navas Pleitez
student•
hace 6 días
Contenido del curso
José Bernardo Navas Pleitez
Harry Uran Molina
Pablo Núñez
Pablo Núñez
Manuel Francisco Duarte Garcia
Mario Antonio Magaña Ruiz
Luis Angel Mendoza Herrera
Rubens A. Rangel Gomez
Comparto resultados de desafio de gestion de usuarios
Analista_Ventas
CREATE LOGIN Analista_Ventas WITH PASSWORD = 'Segur0P@ss2024!';
-- CREAR EL USER EN LA BASE DE DATOS TIENDALATAM, MAPEADO AL LOGIN
USE TiendaLatam;
GO
CREATE USER Analista_Ventas FOR LOGIN Analista_Ventas;
CREATE ROLE Rol_Reportes;
GRANT SELECT ON VW_VentasPorPais TO Rol_Reportes;
GRANT SELECT ON VW_ProductosTopVentas TO Rol_Reportes;
GRANT SELECT ON VW_ClientesSinPedido TO Rol_Reportes;
DENY SELECT ON Pedidos TO Rol_Reportes;
DENY SELECT ON Clientes TO Rol_Reportes;
ALTER ROLE Rol_Reportes ADD MEMBER Analista_Ventas;
EXECUTE AS USER = 'Analista_Ventas';
SELECT * FROM VW_VentasPorPais; -- ✓ permitido
SELECT * FROM Pedidos; -- ✗ denegado
REVERT;
EXECUTE AS USER = 'Analista_Ventas';
SELECT * FROM VW_ProductosTopVentas; -- ✓ permitido
SELECT * FROM Pedidos; -- ✗ denegado
REVERT;
EXECUTE AS USER = 'Analista_Ventas';
SELECT * FROM VW_ClientesSinPedido; -- ✓ permitido
SELECT * FROM Pedidos; -- ✗ denegado
SELECT * FROM Clientes; -- ✗ denegado
REVERT;
SELECT USER_NAME() AS UsuarioActual;
SELECT TOP 5 * FROM VW_VentasPorPais;
SELECT * FROM Pedidos;
REVERT;
GRANT EXECUTE ON SP_ConsultarVentasPorPais TO Analista_Ventas;
APP_TiendaLatam
CREATE LOGIN APP_TiendaLatam WITH PASSWORD = 'Contraseña@SI2026!';
-- CREAR EL USER EN LA BASE DE DATOS TIENDALATAM, MAPEADO AL LOGIN
USE TiendaLatam;
GO
CREATE USER APP_TiendaLatam FOR LOGIN APP_TiendaLatam;
CREATE ROLE Rol_APP_TiendaLatam;
GRANT EXECUTE ON SP_CierreDeMes TO Rol_APP_TiendaLatam;
GRANT EXECUTE ON SP_ConsultarVentasPorPais TO Rol_APP_TiendaLatam;
DENY SELECT ON Pedidos TO Rol_APP_TiendaLatam;
DENY SELECT ON Clientes TO Rol_APP_TiendaLatam;
ALTER ROLE Rol_APP_TiendaLatam ADD MEMBER APP_TiendaLatam;
-- PROBAR: CONECTARSE COMO APP_TiendaLatam Y VERIFICAR QUE SE PUEDE HACER
EXECUTE AS USER = 'APP_TiendaLatam';
SELECT USER_NAME() AS UsuarioActual;
DECLARE @Resultado BIT;
EXEC SP_ConsultarVentasPorPais @FechaInicio = '2025-01-01', @FechaFin = '2025-12-31',@HayResultados = @Resultado OUTPUT;
DECLARE @Resultado BIT;
EXEC SP_ConsultarVentasPorPais @FechaInicio = '2023-01-01', @FechaFin = '2024-12-31', @HayResultados = @Resultado OUTPUT;
DECLARE @Resultado BIT;
EXEC SP_ConsultarVentasPorPais 'AR', '2024-01-01', '2024-12-31', @HayResultados = @Resultado OUTPUT; ;
DECLARE @Resultado BIT;
EXEC SP_ConsultarVentasPorPais 'AR', '2024-01-01', '2024-12-31', @HayResultados = @Resultado OUTPUT;
SELECT * FROM Pedidos; -- ✗ denegado
SELECT * FROM Clientes; -- ✗ denegado
REVERT;
-- CIERRE MENSUAL
EXECUTE AS USER = 'APP_TiendaLatam';
DECLARE @Resultado NVARCHAR(20);
EXEC SP_CierreDeMes
@Anio = 2024,
@Mes = 1,
@Resultado = @Resultado OUTPUT;
PRINT 'Resultado: ' + @Resultado;
SELECT * FROM ResumenMensual ORDER BY Anio, Mes, CodigoPais;
SELECT * FROM LogCierres ORDER BY FechaHora DESC;
SELECT * FROM Pedidos; -- ✗ denegado
SELECT * FROM Clientes; -- ✗ denegado
¿Cómo pruebo permisos de otro usuario rápidamente?
La forma más eficiente y segura es utilizar el comando EXECUTE AS USER = 'nombre_usuario'. Esto funciona como un simulador de identidad. En lugar de tener que cerrar tu sesión de administrador, pedirle la contraseña al usuario (lo cual es una pésima práctica de seguridad) y volver a conectarte, SQL Server te permite ponerte la máscara de ese usuario temporalmente.
Mientras estés bajo este contexto, cualquier consulta que lances será evaluada con los permisos exactos de esa persona. Si intentas hacer un SELECT a una tabla prohibida, verás el mismo error de acceso denegado que ellos verían. Una vez que termines tus pruebas de auditoría, simplemente ejecutas el comando REVERT para quitarte la máscara y recuperar instantáneamente tus privilegios de administrador. Es una herramienta invaluable para depurar problemas de acceso en producción sin interrumpir el flujo de trabajo.
respecto al deny: Ese DENY es tu red de seguridad. En el ejemplo, el rol tiene acceso a las vistas, pero las tablas subyacentes siguen ahí, esperando. Si alguien con permisos elevados o un cambio accidental en el rol expone la tabla, el DENY actúa como un muro infranqueable que bloquea el acceso incluso si otros permisos intentan abrir la puerta.
¿Ves la diferencia entre "no dar permiso" y "prohibir explícitamente" cuando se trata de datos críticos?
Ese DENY es tu red de seguridad. En el ejemplo, el rol tiene acceso a las vistas, pero las tablas subyacentes siguen ahí, esperando. Si alguien con permisos elevados o un cambio accidental en el rol expone la tabla, el DENY actúa como un muro infranqueable que bloquea el acceso incluso si otros permisos intentan abrir la puerta.
¿Ves la diferencia entre "no dar permiso" y "prohibir explícitamente" cuando se trata de datos críticos?
En el caso que se quiera implementar RLS, sin afectar la ejecucion de las consultas y sobrecargar al servidor como seria lo ideal para validar los permisos?
con los trigger como se dan los permisos?
¿Cómo pruebo permisos de otro usuario rápidamente?
La forma más eficiente y segura es utilizar el comando EXECUTE AS USER = 'nombre_usuario'. Esto funciona como un simulador de identidad. En lugar de tener que cerrar tu sesión de administrador, pedirle la contraseña al usuario (lo cual es una pésima práctica de seguridad) y volver a conectarte, SQL Server te permite ponerte la máscara de ese usuario temporalmente.
Mientras estés bajo este contexto, cualquier consulta que lances será evaluada con los permisos exactos de esa persona. Si intentas hacer un SELECT a una tabla prohibida, verás el mismo error de acceso denegado que ellos verían. Una vez que termines tus pruebas de auditoría, simplemente ejecutas el comando REVERT para quitarte la máscara y recuperar instantáneamente tus privilegios de administrador. Es una herramienta invaluable para depurar problemas de acceso en producción sin interrumpir el flujo de trabajo.
Controlar el acceso en SQL Server mediante logins, users y roles personalizados es fundamental para aplicar el principio de mínimo privilegio y proteger la información. Esta estrategia permite que cada usuario tenga solo los permisos estrictamente necesarios, evitando riesgos de seguridad, accesos indebidos o borrados accidentales. La creación de roles centraliza permisos, facilita la administración y, al combinar vistas con DENY sobre tablas sensibles, se asegura un acceso seguro y controlado. En pocas palabras, implementar seguridad por capas no solo protege los datos, sino que también simplifica la gestión y auditoría de permisos a largo plazo.