Lo normal es que a uno no le pregunten sobre este tipo de cosas y que tenga que lidiar con lo que hay para ir, poco a poco, ajustándolo a lo que las buenas prácticas aconsejan.
En lo tocante a usuarios, lo mejor es autenticación de Windows vía Active Directory si la empresa cuenta con él. La administración de los permisos luego se basarían en Domain Local Security Groups y la membresía se maneja en Domain Global Security Groups. Se crean Domain Global groups que representan los roles de las personas. Usualmente esto está ligado a la jerarquía departamental de la compañía. Luego se crean Domain Local groups que representan los recursos. Los grupos que representan roles se llenan con los usuarios que desempeñan el rol; si un usuario pertenece a más de un rol, pues se agrega a más de uno de estos grupos.
Luego a los recursos de red se les asigna permisos usando los Domain Local groups. Estos grupos son los únicos que aparecerán como usuarios de SQL Server, o en el ACL de directorios compartidos, etc. Es a estos grupos a los que se les asigna permisos.
La relación entre roles y recursos: Si el rol A necesita acceso a un recurso B, entonces el Domain Global group de A se hace miembro del Domain Local group de B.
Es importante crear también un grupo de DBA en el Directorio Activo y en éste ingresar las personas que administran las diferentes bases de datos. Como sugiero siempre, crear un usuario llamado "SQLServer_DBA" o similar que esté fuera del grupo y que pueda administrar las bases de datos.
Aunque hoy día las plataformas de bases de datos y particularmente SQL Server, no requieren que cada aplicación tenga su propia base de datos, es importante, tener claridad de los escenarios en los cuales funcionarían esas bases de datos y hacer una planeación adecuada para establecer si con una sola plataforma es suficiente o si debes tener multiples instancias o incluso si requieres alta disponibilidad, entre otros muchos factores. Hoy en día se habla mucho de consolidación de bases de datos y es un tema que requiere muchísima planeación. Recomiendo este link, http://www.simple-talk.com/sql/database-administration/sql-server-consolidation/,este post en mi blog que en esencia es otro link a la guía de planeación de infraestructura de SQL Server 2008 y este documento del SQLCAT sobre consolidación en SQL Server, http://sqlcat.com/sqlcat/b/whitepapers/archive/2010/02/04/sql-server-consolidation-guidance.aspx.
Conocer las mejores prácticas, es una cosa, pero garantizar que se implementen, y que siguen siendo implementadas, es un asunto completamente diferente. Supon que como en tu caso, estas frente un puesto como de DBA para una empresa con miles de instancias de servidores distribuidos en entornos de producción, prueba y desarrollo, cada uno de los cuales fueron instalados y configurados por los administradores diferentes y desarrolladores con diferentes preferencias en el conocimiento de las mejores prácticas... Imagina que te piden que realices una auditoría de todos los servidores para cumplir con ciertos requerimientos establecidos por la empresa… ¿Cómo vas a hacerlo? Si eres hábil, con tecnologías tales como Server Management Objects (SMO) y Windows PowerShell, aun así te enfrentarías a un reto importante que requiere mucho tiempo.
Desde SQL Server 2008 se introduce una nueva característica llamada gestión basada en políticas (policy-based management), y es posiblemente la característica más importante para el DBA.
Aquí os dejo cuatro artículos sobre la administración basada en políticas (policy-based management), que os darán una idea de como funcionan y como se ha de trabajar con estas políticas: (espero que os guste)
Gestión de SQL Server basada en Políticas. SMO. Tema I
La Importación de Políticas. SMO. Tema II
Evaluación de Políticas. SMO. Tema III
Creando y Exportando Politicas. SMO. Tema IV
Fuentes:
Microsoft, msdn, TechNet blog...
Apunte y recopilación por Norman M. Pardell
Puedes consultarme, si deseas cualquier aclaración, pregunta o sugerencia en: Contacto, contestaré tan pronto como me sea posible.
