Hola!!

Una de las nuevas características de SQL Server 2012 son las Contained Databases , gracias a esta característica podemos parcialmente aislar algunos objetos que por su naturaleza residen en la instancia de bases de datos como lo son los “logins”, si bien en términos de migración y consolidación esta es una gran ventaja, permítanme comentarles algunos aspectos a considerar a nivel de seguridad.

Se debe tener en consideración que si algún usuario en la contained database tiene el permiso de ALTER ANY USER,  tendrá la capacidad de modificar los permisos de los usuarios y dar permisos de conexión a cualquier persona sin conocimiento del Administrador de SQL, usuarios que pertenezca a los roles de bases de datos “db_owner” y “security_admin” obtendrán automáticamente dicho permiso, dando como resultado un hueco de seguridad, por esto tenemos que ser muy cuidadosos con dar estos permisos a usuarios no administradores de SQL.

Otro escenario que debemos considerar es que cuando nos conectamos a un contained database y en esa misma instancia se encuentra alguna base de datos con la cuenta “guest” habilitada,  una vez que el usuario se ha podido conectar a la contained database, también tendrá la capacidad de acceder a esa base de datos, esto en conjunto que el escenario anterior donde una usuario con el permiso de ALTER ANY USER pude dar acceso a cualquier persona para conectarse al servidor, se convierta en un gran problema de seguridad. Es por ello que debemos minimizar el uso de este permiso y constantemente auditar el acceso y uso del permiso ALTER ANY USER en las bases de datos.

Ahora platiquemos de otro escenario, ¿Que sucedería si creamos un usuario en nuestra base de datos de contenido, con el mismo nombre de un login existente en nuestra instancia? Si accedemos a la base por medio de este login y a su vez al momento de conectarnos especificamos la Contained Database como catálogo inicial, lo que obtendríamos sería una negación del servicio para este login, ya que el contexto de seguridad  evalúa usuario y contraseña sobre la Contained Database en lugar de el entrono de logins de SQL.

Para finalizar y tomando en cuenta mis dos recomendaciones anteriores, les expongo lo siguiente. ¿Cual es el impacto de darle “attach” a una base de datos de contenido en una nueva instancia? , al attachar una Contained Database estaremos abriendo una puerta de conexión a los usuarios con password de la Contained Database attchada.  ¿Cómo podemos evitar el riesgo de acceso a usuarios no autorizados a esta instancia? usando la opción de RESTRICTED_USER, ya que esta previene la autenticación para usuarios con passwords de la Contained databases.

Todas estas consideraciones son fácilmente manejables teniendo una adecuada delegación de control de acceso y mejores prácticas de seguridad.

Espero les sean de utilidad estos puntos y para mayor información de este y tros escenarios pueden consultar en TechNet:

http://technet.microsoft.com/en-us/library/ff929055