Rastrear cambios de seguridad en una base de datos SQL Server

Configurar un ambiente seguro y a salvo para su instancia SQL Server es una tarea compleja. La seguridad de SQL Server debe ser configurada en la instancia SQL Server, en el sistema operativo, cortafuegos, el programa antivirus, etc. Pero fallar en configurar la seguridad apropiadamente puede traer muchos dolores de cabeza e incluso daños irreversibles.

En términos de seguridad SQL Server, hay amenazas internas y externas, deliberadas e inadvertidas. Veamos un ejemplo. Usted tiene un usuario (técnico de soporte) quien tiene más privilegios en los registros HR de los que debería. Él/ella puede inadvertidamente borrar un artículo de factura o la dirección de un cliente.

Otro ejemplo sería un ambiente de alta seguridad, donde incluso ver datos sensitivos por un usuario sin privilegios puede ser evitado. Un empleado a quien se le han dado más privilegios de los necesarios puede ver registros sensitivos, como números de cuentas de bancos, transacciones o datos personales de salud.

Amenazas externas vienen de hackers, como inyecciones SQL, ataques de fuerza bruta a credenciales débiles, escucha de redes y varios otros ataques. Estos ataques son usualmente más dañinos. A diferencia de los internos, los ataques externos apuntan a bases de datos y tablas enteras. El objetivo de los ataques puede ser el robo y revelación de detalles de tarjetas de crédito y débito de los clientes, detalles personales, nombres y números de seguridad social.

Una fuga de datos sensitivos, cambios y accesos no autorizados, registros perdidos y copias de seguridad de la base de datos que son robadas pueden pasar más en una instancia SQL Server insegura que en un ambiente bien protegido.

Configuraciones Microsoft SQL Server y Windows Server recomendadas

Para configurar la seguridad de SQL Server efectivamente, se recomienda aplicar las siguientes acciones de seguridad antes de correr SQL Server:

• Aplique todos los paquetes de servicio y actualizaciones de Microsoft Windows
• Cree una cuenta dedicada debajo del servicio SQL Server que correrá y asegurarse de que sólo tiene los privilegios necesarios. No use una cuenta con privilegios de administrador para correr el servicio SQL Server
• Dé acceso al anfitrión sólo a los usuarios privilegiados

Consideraciones de seguridad de la instancia SQL Server que reducen el área de ataques potenciales:

• No instale características innecesarias de SQL Server (si ya han sido instaladas, deshabilítelas)
• Aplique todos los paquetes de servicio y actualizaciones Microsoft SQL Server
• Use autenticación Windows si es posible
• Configure los privilegios de acceso para inicios de sesión, usuarios y roles para cumplir con los requerimientos mínimos
• Cambie los puertos por defecto de SQL Server (1433 y 1434)
• Permita el acceso de a los archivos de instalación de SQL Server, las carpetas y las bases de datos sólo si a la cuenta usada para correr el servicio SQL Server
• Monitoree los inicios de sesión exitosos y fallidos. Esto no prevendrá a un atacante, sino que es útil para identificar agujeros de seguridad
• Deshabilite inicios de sesión remotos, a menos que sean necesarios
• Use el Cifrado de Datos Transparente

Privilegios de inicio de sesión, usuario y rol

Cuando se trata de configurar privilegios de acceso para sus usuarios, es necesario primero determinar quién necesita hacer qué. Es recomendado dar a los usuarios los permisos más bajos posibles para evitar cualquier acceso sin privilegios.

Los términos inicio de sesión SQL Server y usuario son frecuentemente mezclados, aunque son bastante diferentes.

Un inicio de sesión SQL Server es una entidad de seguridad definida en una instancia de SQL Server. Usted puede usarlo para conectarse a una instancia de SQL Server, pero si no está mapeado a un usuario de base de datos, usted no podrá conectarse a una base de datos específica. Un inicio de sesión puede ser mapeado a un usuario diferente en cada base de datos.

Un usuario es una entidad de seguridad definida para acceder a una base de datos. Los permisos en bases de datos y objetos de bases de datos (tablas, vistas, etc.) son provistas o denegadas al usuario de la base de datos. Un usuario debe ser mapeado a un inicio de sesión SQL, un certificado o una llave.

Otra entidad de seguridad es un rol SQL Server – un conjunto de permisos que pueden ser asignados o denegados a grupos de usuarios. Los roles proveen una administración más rápida de los permisos para un grupo o usuarios que debería tener el mismo conjunto de privilegios. Un usuario puede ser miembro de múltiples roles. Por defecto, todos los inicios de sesión están asociados al rol público. El rol público no puede ser eliminado y los inicios de sesión no se pueden remover de ahí.

Cuando se trabaja con inicios de sesión y usuarios SQL, considere las siguientes acciones de seguridad:

• Implemente una política de contraseñas fuertes
• Deshabilite o renombre el inicio de sesión “sa”
• Remueva los inicios de sesión sin usar
• Remueva/deshabilite el usuario invitado
• Deshabilite los inicios de sesión anónimos

Como se recomienda, un usuario no debería tener más privilegios que los que necesita para hacer su trabajo. Para habilitar a John Smith sólo para modificar la tabla HumanResources.EmployeeDepartmentHistory y restringirlo para incluso ver datos de otra tabla, usted necesitará hacer lo siguiente:

1. Cree un nuevo inicio de sesión. En SQL Server Management Studio, haga clic derecho en Logins y seleccione New Login

   

2. Ingrese un nombre de inicio de sesión y seleccione el tipo de autenticación (Windows o SQL Server). Si se usa la autenticación de SQL Server, seleccione reforzar la política de contraseñas y que los usuarios no puedan cambiar las contraseñas por sí mismos

   

3. En la pestaña Server Roles, deje sólo el rol público seleccionado

   

4. En la pestaña User mapping, seleccione la base de datos a la que este usuario accederá y deseleccione todos los roles de la base de datos excepto el público

   

5. En Object Explorer, haga clic derecho en la base de datos a la que Jon Smith debería acceder y seleccione Properties

   

6. En el diálogo Table properties haga clic en Search

   

7. Seleccione el usuario [John Smith] y haga clic en OK

   

8. De vuelta en el diálogo Table properties, seleccione las casillas de selección Grant sólo para las operaciones que desea que pueda realizar John Smith – en este ejemplo, para insertar y actualizar los registros

   

Ahora, todo los que John Smith puede hacer desde una aplicación cliente o SQL Server Management Studio es insertar y actualizar datos en la tabla HumanResources.EmploteeDepartmentHIstory.

Los privilegios de usuarios de objetos de bases de datos SQL Server también pueden ser asignados usando sentencias T-SQL. Para el anterior caso, dar permisos para insertar y actualizar datos en la tabla HumanResources.EmployeeDepartmentHistory:

USE AdventureWorks2012;
GRANT INSERT, UPDATE ON HumanResources.EmployeeDepartmentHistory TO JohnSmith;
GO

Algo similar se usa para denegar permisos de objeto:

USE AdventureWorks2012;
DENY INSERT, UPDATE ON HumanResources.EmployeeDepartmentHistory TO JohnSmith;
GO

Permaneciendo seguro

Configurar los permisos apropiados para sus usuarios es sólo el primer paso. Para permanecer seguro usted deberá monitorear configuraciones de seguridad de la instancia y las bases de datos SQL Server, actualizarlas si es necesario e investigar cualquier cambios inesperado en usuarios/inicios de sesión/roles. Es aquí donde ApexSQL Audit puede ayudar.

ApexSQL Audit es una herramienta de cumplimiento de estándares y auditoría SQL Server, construida para cumplir con las regulaciones de auditoría. Provee un amplio rango de posibilidades de auditoría para accesos, cambios y seguridad en instancias, bases de datos, objetos y datos SQL Server. También audita consultas ejecutadas y avisos encontrados en tablas, procedimientos almacenados, funciones y vistas. La información capturada es grabada en un repositorio de auditoría central y usada para crear reportes detallados. ApexSQL Audit puede auditar Microsoft SQL Server 2012, 2008 y 2005, pero note que la instancia central requiere Microsoft SQL Server 2008 o posterior.

Para configurar la auditoría de base de datos y SQL Server usando ApexSQL Audit:

1. Inicie ApexSQL Audit
2. Seleccione la instancia SQL Server y la base de datos que desea auditar
3. Asegúrese de que las operaciones Security están seleccionadas
4. Haga clic en Apply en el menú Filter settings changed

   

   Todos los cambios hechos a usuarios y permisos de objetos de inicio de sesión SQL Server serán auditados y ApexSQL Audit los mostrará en los reportes.

5. Haga clic en Reports en el menú para abrir los reportes locales, o Web reports para abrir el navegador de internet por defecto. Para ver:

   • Cambios de seguridad de SQL Server en todas las entidades de seguridad – inicios de sesión, usuarios, roles – use el reporte Security configuration history

     

   • Inicios y finalizaciones de sesión auditados, use el reporte Logon activity history:

     

   • Cambios en los permisos de la base de datos o el servidor, use el reporte Permission changes:

     

   • Fallos de inicios de sesión – use Unauthorized Access

     

Para asegurarse de que su instancia, base de datos, objetos y datos SQL Server permanecen seguros, rastrear los cambios de permisos y acciones tomadas en los inicios de sesión, usuarios y roles SQL Server es necesario. Cualquier cambio sospechoso o actividad debería ser examinado, ya que es una amenaza potencial a su ambiente. Use ApexSQL Audit para asegurarse de que ningún cabio de seguridad SQL Server pase sin ser notado.

Traductor: Daniel Calbimonte