Roles de Aplicación–Manejo avanzado de la seguridad en SQL Server

Encontré este muy bien artículo en la revista InformIT, cuyos autores son Richard Waymire y Rick Sawtell (http://www.informit.com/library/content.aspx?b=STY_Sql_Server_7&seqNum=51) el cual me he tomado la libertad de traducir y actualizar para toda la comunidad

Trata sobre los Roles de Aplicación (Application Roles)DBSecurity

Los roles de aplicación existen desde la versión 7 de SQL Server, pero son poco difundidos y por lo tanto poco usados. Es similar a otros roles de base de datos pero su función es diferente

Un rol de aplicación tiene el mismo propósito que un rol de base de datos. Es una forma práctica de agrupar usuarios, de modo que los permisos son aplicados a un nivel grupal, de modo que no se tenga que aplicar la seguridad usuario por usuario

Pero se diferencias por que el rol de aplicación puede ser activado por una aplicación. Luego de que un usuario se conecta a la aplicación aplicación se activado el rol de aplicación, se suspenden los permisos del usuario que se conectó a la base de datos y se activan los permisos del rol de aplicación. El usuario solo puede realizar operaciones en la base de datos a través de la aplicación, pero si se conecta a través de otro medio, como por ejemplo Management Studio, no tendrá acceso a los objetos de base de datos

Es importante aclarar que para activar el rol de aplicación se requiere de una clave secreta

Imaginemos una aplicación de planilla de sueldos, en la que los administradores de recursos humanos requieren actualizar información de sueldos y bonos periódicamente. Es preferible que esto lo hagan únicamente a través de la aplicación y no directamente en la base de datos

Cuando la aplicación se inicia, se usa el inicio de sesión del usuario mismo (ya sea con un inicio de sesión de SQL Server o preferiblemente con un inicio de sesión de Windows así ellos ni se dan cuenta de lo que está sucediendo). Una vez conectado a la base de datos se ejecuta el código apropiado (el procedimiento almacenado del sistema sp_setapprole) para activar el rol de aplicación de sueldos. Desde ese momento en adelante, hasta que la aplicación cierre la conexión a la base de datos, se utilizan los permisos del rol de aplicación mientras que los permisos del usuario son desactivados

La mejor parte es que toda la actividad sigue siendo auditada con la información del inicio de sesión del usuario

Ahora examinemos como implementar este tipo de rol. Por lo que veremos, estarán de acuerdo conmigo en que el proceso es relativamente simple, dado lo potente que son. En estos casos vamos a usar Transact SQL, pero todas estas acciones se pueden ejecutar desde Management Studio.

1. Creamos el rol de aplicación, utilizando el procedimiento almacenado del sistema sp_addapprole:

sp_addapprole [@rolename =] ‘rol’, [@password =] ‘contraseña’

Donde:

  • rol es el nombre del rol que se desea crear
  • contraseña es la palabra secreta necesaria para activar el rol, la cual debe estar encriptada en la aplicación que va a invocar el rol de aplicación

NOTAS:

  • Los permisos para el rol de aplicación se asignan exactamente igual a un rol de base de datos convencional
  • Para eliminar un rol de aplicación se utiliza el procedimiento almacenado del sistema sp_dropapprole

2. Una vez creado el rol, para usarlo en la aplicación, se debe ejecutar el procedimiento almacenado del sistema sp_setapprole

sp_setapprole [@rolename =] ‘rol’ , [@password =] {Encrypt N ‘contraseña’} | ‘contraseña’ [,[@encrypt =] ‘estilo_encriptacion’]

donde:

  • rol es el nombre del rol que se desea crear
  • contraseña es la palabra secreta asignada al crear el rol. Encrypt N requiere que la contraseña sea encriptada antes de ser enviada por la red
  • estilo_encriptacion especifica el tipo de encriptación a usar. Hay dos tipos:
    • None, cuando se usa conexión OLEDB
    • odbc, cuando se usa conexión ODBC

3. Pongamos un ejemplo con las sintaxis explicadas líneas arriba, para crear u utilizar un rol de aplicación

USE AdventureWorks2014

–CREAR EL ROL DE APLICACION Y SU CONTASEÑA
EXEC sp_addapprole ‘Planilla’,’c0ntraseñ@’
GO

–ASIGNAR PERMISOS AL ROL DE APLICACION
GRANT EXECUTE ON SCHEMA::HumanResources TO Planilla
GRANT SELECT, INSERT, UPDATE ON SCHEMA::HumanResources TO Planilla

–ACTIVAR EL ROL DE APLICACION
EXEC sp_setapprole ‘Planilla’, ‘c0ntraseñ@’

A partir de la activación del rol, todos los permisos para esta conexión a SQL Server usaran los permisos del rol de aplicación y no del usuario conectado. Pero los registros de actividad y auditoría van a continuar mostrando la información del usuario con el que se inició la sesión, no el rol de aplicación. Así que aun podemos saber que es lo que esta ejecutando el usuario, aun cuando haya habilitado esta funcionalidad

Deja un comentario

Tu dirección de correo electrónico no será publicada.