Posterior a consultar con especialistas en este tema, programadores de varias áreas y profesores dimos con la respuesta a la interrogande y la plasmamos en este post.
Solución:
Personalmente, utilizo la suplantación de identidad para tres categorías principales de tareas.
Pruebas
Si necesito probar qué acceso tiene alguien, puedo suplantarme, probar la tarea y ver si funciona. Esto es particularmente útil cuando he otorgado permisos pero el usuario todavía me dice que no puede realizar una tarea determinada.
Recabando información
Hay una serie de vistas / funciones del sistema que le brindan información sobre los permisos de los principales de conexión (incluso cierta información de AD). Como ejemplo, si me hago pasar por un director de base de datos (usuario) y consulto sys.user_token, puedo obtener una lista de todos los grupos de AD de los que son miembros y cuáles les dan acceso a la base de datos actual.
Otorgar acceso a una tarea sin otorgar el permiso
Un ejemplo específico aquí es la capacidad de truncar una tabla. Para truncar una tabla, debe tener el ALTER permiso sobre la mesa. Quiero permitir que algunos trunquen esa tabla, pero no quiero arriesgarme a que le hagan cambios.
- Cree un principal de base de datos (usuario) que haya alterado en la tabla
- Cree un procedimiento almacenado que haga el
TRUNCATEy usosEXECUTE ASpara hacer que el SP se ejecute como el usuario que creé. - Otorgue permisos de ejecución para ejecutar el procedimiento almacenado.
Incluso puede utilizar esta técnica para otorgar permisos de nivel de administrador de sistemas, aunque tiene sus propias dificultades y riesgos.
Editar:
Puedo ver dos posibles razones por las que podrías otorgarle a alguien derechos de suplantación de identidad.
Separe los permisos de la aplicación de los permisos de acceso directo
ApplicationA requiere que el usuario Joe tenga acceso para leer desde cualquier tabla. Pero como parte de las responsabilidades de Joe, también necesita actualizar una tabla de estado en caso de que sea necesario volver a escribir algo. Al otorgar permisos de actualización al usuario UpdatePerms y al otorgarle acceso a Joe para hacerse pasar por él, puede iniciar sesión en SSMS, hacerse pasar por ese usuario y actualizar la tabla. Esto significa que no tiene acceso a actualizaciones a través de la aplicación, pero aún puede realizar esta tarea ocasional.
Requiere pensamiento / acción adicional antes de realizar una tarea
Similar al anterior. Joe necesita poder eliminar filas de una tabla, pero no quieres que lo haga por accidente (o al menos lo haga más difícil). Al requerir que se haga pasar por otro usuario antes de realizar la eliminación, al menos tiene que pensarlo un poco más para que sea menos probable que suceda por error.
Nota: Nunca tuve que hacer ninguno de estos en producción. Parece posibilidades lógicas.
Es posible que desee permitir que un usuario ejecute un proceso almacenado extendido u otra operación privilegiada, pero solo bajo ciertas circunstancias.
Escriba un procedimiento almacenado que contenga EXECUTE AS que realiza la operación con privilegios y luego otorgue permisos al usuario para ese procedimiento almacenado. De esa manera, solo pueden realizar esa operación privilegiada dentro del contexto de ese procedimiento almacenado, que ha escrito para realizar una operación estrictamente limitada.
Agregando a lo que ya se ha dicho en las otras dos respuestas (por @KennethFisher y @REvans), el IMPERSONATE El permiso también permite a un Usuario que no está en el dbo rol de base de datos o sysadmin función del servidor la capacidad de establecer el AUTHORIZATION propiedad de un objeto (uno que tiene esa propiedad, no todos la tienen) a un Usuario que no sea ellos mismos. Por ejemplo:
CREATE ASSEMBLY [AnnoyTsqlPurists]
AUTHORIZATION [SomeoneElse]
FROM 0x4D59.........................;
Para aclarar / enmendar lo que los demás han dicho con respecto a la elevación limitada de permisos a través de EXECUTE AS, se debe notar que EXECUTE AS no está obligado a hacer esas cosas, al menos ya no. Durante el uso EXECUTE AS es la ruta más fácil, ya que le da a un usuario o inicio de sesión la capacidad de actuar como otro usuario o inicio de sesión no controla el contexto de cuándo EXECUTE AS se puede emitir. Es decir, tome el ejemplo de User_A siendo concedido IMPERSONATE User_B con el propósito de poder hacer algo como TRUNCATE TABLE, y luego concedido EXECUTE en un procedimiento almacenado que tiene tanto el EXECUTE AS User = 'User_B'; y TRUNCATE TABLE declaraciones en él. Eso funciona. Sin embargo, no previene User_A de correr EXECUTE AS User = 'User_B'; cuando lo deseen, incluso fuera de ese procedimiento almacenado específico. Y si necesita darle a alguien un permiso más general, como VIEW SERVER STATE, luego pueden hacerse pasar por ese usuario “elevado” para hacer uso de ese permiso elevado fuera de la aplicación deseada mucho más restringida más probable de ese permiso, como obtener datos de un DMV en particular, no todo DMV que requieren ese permiso.
Afortunadamente existe un mecanismo que permite ser muy granular y explícito cuando se desea / necesita permitir que los usuarios sin privilegios hagan “cosas” de nivel superior: firma de módulo. Con este enfoque, configura un inicio de sesión y / o un usuario (basado en clave asimétrica o basado en certificado) que tiene los permisos deseados, pero este inicio de sesión y / o usuario hipocresía ser suplantados ya que no pueden iniciar sesión. Luego, asocia el inicio de sesión y / o el usuario a uno o más módulos (procedimiento almacenado, función (excluyendo TVF en línea), disparador o ensamblaje) a través de ADD SIGNATURE. Finalmente, conceda EXECUTE en el (los) módulo (s) a los usuarios sin privilegios. Ahora los usuarios sin privilegios no tienen acceso al origen de los permisos elevados.
Para obtener más detalles, consulte mis dos respuestas siguientes (y sus enlaces a más respuestas), también aquí en DBA.SE:
-
¿Hay alguna forma en SQL Server de hacer que una tabla solo se pueda insertar mediante un disparador?
-
El procedimiento almacenado puede seleccionar y actualizar tablas en otras bases de datos – permisos mínimos otorgados
Agradecemos que quieras añadir valor a nuestra información asistiendo con tu experiencia en las explicaciones.