SQL . Proteja sus Datos (Implemente Seguridad en su Servidor de SQL)

...

tener que validar en algunas de las tablas del sistema esa información, checar si es correcto el nombre que le están pasando, si el password corresponde y en caso de que sea asi lo va a dejar conectar.

Estos son los dos tipos de autenticación que tenemos autenticación Windows y autenticación mixta.

Una vez que nosotros ya configuramos el tipo de autenticación con la que vamos a trabajar vamos a ver cuál sería el proceso para que los usuarios precisamente se puedan conectar a este servidor de SQL server.

Cuando un usuario llega a su máquina, este usuario tiene una cuanta en el active directory. Es esta imagen como podemos ver una maquina es el controlador de dominio, ese dominio tiene la BD del directorio activo. En el directorio activo se encuentran los usuarios, los grupos, las unidades organizacionales, todos los objetos del dominio. Entonces cuando un usuario llega a su equipo y se quiere firmar en el, lo que tiene que hacer es escribir su nombre de usuario y su password. Esa información va a ir hacia el controlador de dominio, el domain controler lo que va hacer es verificar si ese nombre de usuario y password existen y si son válidos, y si son válidos lo que va hacer es regresarle un token al usuario.

Que es lo que va a contener este token, un identificador de identidad del usuario, pero también va a tener un identificador de seguridad de los grupos a los que el usuario podría pertenecer. Este token lo que le va a permitirle al usuario, es tratar de acceder a los servidores o a los diferentes elementos y recursos del corporativo, y si en algún momento tiene permisos lo van a dejar conectar de otra forma no lo harían.

Pero en este momento ya se está realizando el proceso de autenticación. Windows ya autentico que este usuario es quien dice ser. Una vez que ese usuario ya recibió su token, en caso de que quisiera se puede conectar al servidor de SQL server. Para que pueda conectarse a servidor de SQL Server. En este servidor previamente se tendría que haber creado un objeto que se llama un Login, este Login puede ser de dos tipos; puede ser un login de Windows o puede ser un login de SQL server.

Si es un login de Windows es por qué ese login que se está creando se está mapeando a una cuanta que exista en el active directory. Si es un login de SQL server esa cuenta no tiene que está en el active directory , es una cuanta que SQL Server va almacenar en sus bases de datos en alguna de las tablas del sistema.

Entonces cuando este usuario que previamente ya se había conectado al controlador de dominio se conecta a SQL Server, lo único que va hacer SQL server es checar si existe un login para ese cid (identificador de seguridad). Ya sea de él o del grupo al que pertenezca, si existe un login en Windows lo va a dejar conectar al servidor si no existe el login no lo va a dejar conecta; a esto se le conoce como una conexión de confianza. SQL está confiando en la autenticación que previamente hiso Windows.

Sin embargo también puede darse el caso que existan usuarios que no puedan pasar atravez de un controlador de dominio y entonces se conecten directamente al servidor de SQL server en ese caso los usuarios tiene que pasarle el nombre de login y pasarle el password. SQL Server lo que va a tener que hacer es checar si existe un login para esa persona que se está queriendo firmar y si el password corresponde. Si es asi, si existe el login y si el password es correcto entonces le va a permitir conectarse a SQL Server. En este caso el que está haciendo la autenticación es el servidor de SQL Server.

Como parte de la creación de este objeto del login si en algún momento el administrador está creando los logins les puede dar permisos, les puede dar derechos para trabajar con este servidor de SQL Server. Dentro del servidor de SQL Server exite algo que se llama roles de servidor. Un roll no es otra cosa más que una forma de agrupar a los