Cualquier sugerencia sobre cómo reducir mis privilegios en la producción pero no hacer que mi trabajo sea excesivamente difícil

Ejecutando SQL Server 2005 y 2008 en Windows 2008 R2.

Vamos a reducir los privilegios en la producción para desarrolladores, y me gustaría hacer lo mismo para mí como DBA , limitando los derechos de producción y elevando cuando sea necesario .

Mi objetivo principal sería eliminar los errores estúpidos: cometidos por DBA , los devoradores tendrán acceso de lectura en la producción a lo sumo. Nos gusta actuar como si fuéramos superhéroes que no pueden cometer un error, pero no tener derechos de producción todo el tiempo tiene sentido y es una buena práctica, recomendada por algunos.

¿Cuál es el mejor enfoque? ¿Qué será menos doloroso de usar día a día y durante las instalaciones?

Actualmente tenemos un grupo de Windows para DBA que tiene derechos para todos nuestros servidores y bases de datos.

También me interesaría reducir los permisos de inicio de sesión remoto / SO, pero estoy más preocupado por los derechos de DB.

Supongo que necesitaríamos privilegios elevados para ejecutar trazas como sa, y posiblemente para una limpieza de propiedad antes de quitar nuestros derechos de SA de inicio de sesión anterior. ¿Qué otros problemas podríamos esperar?

¡Gracias por tu consejo y por compartir tus experiencias!

Idealmente, para una base de datos de producción operativa, no desea que los desarrolladores tengan acceso al servidor ni a ninguna base de datos en él. Ese tipo de cosas es una de las primeras cosas que tendrá que hacer para cumplir con SOX .

Para el tipo de derechos que se ejecutan bajo los ID de usuario, los únicos derechos que en realidad debería tener son db_datareader, db_datawritery explícita GRANT EXECUTE ON x TO y(para cada procedimiento almacenado y la función definida por el usuario xpara la identificación de usuario y).

Si necesita ejecutar rastros en producción, tiene algunos problemas y se necesitará una Gran Muralla de Texto ™ para explicarlo todo. Mi primera recomendación es tener un entorno de control de calidad que esté bloqueado al igual que la producción y, si es necesario ejecutar trazas, restaurar una copia de seguridad del producto db a QA y ejecutar las trazas allí. Nuevamente, si tiene requisitos SOX, HIPAA o PCI-DSS , es mejor que desinfecte los datos de producción antes de restaurarlos a QA.

Actualmente tenemos un grupo de Windows para DBA que tiene derechos para todos nuestros servidores y bases de datos.

Darles inicio de sesión y ver los derechos de datos; sin embargo, para realizar tareas de DBAly, use un inicio de sesión separado con privilegios elevados. Conozco a un cliente financiero que hace esto: los inicios de sesión regulares basados ​​en la autenticación de Windows estaban limitados en el daño que podían hacer inadvertidamente. Las restauraciones y la ejecución de DML requieren la ejecución con el inicio de sesión de autenticación de SQL por separado.

Una agencia gubernamental con la que trabajé utilizó 2 inicios de sesión separados para cada servidor / administrador de base de datos. Entonces, si Tangurenafue mi inicio de sesión de dominio (este inicio de sesión tendría Userprivilegios regulares ), entonces TangurenaAdminsería mi Administratorinicio de sesión por separado . Te metes en problemas si usas tu cuenta de administrador todo el tiempo, pero luego carece de permisos para otras cosas (como no correo electrónico. Oh, dices que eso es algo malo ... ).

La agencia gubernamental actual con la que estoy trabajando tiene cada administrador de servidor / base de datos que tiene privilegios elevados por encima del usuario estándar, pero no del todo administrador (piense en ello como el PowerUsergrupo). Las funciones de administrador de dominio se realizan con una cuenta de administrador de dominio compartido.

Un error común es restaurar la base de datos incorrecta (como QA restaurado en el servidor de producción), y esto no se resolverá mediante derechos restringidos o inicios de sesión múltiples. Hacer cosas potencialmente destructivas en parejas es una forma de minimizar los riesgos.

Supongo que necesitaríamos privs elevados para ejecutar trazas como sa

No. Solo necesita permisos ALTER TRACE:
http://msdn.microsoft.com/en-us/library/ms187611.aspx

Al principio, le sugiero que haga todo el juego de privilegios en un entorno de desarrollo o de control de calidad donde no haya ningún problema si se elimina el acceso por algún tiempo. Deberá ver si las aplicaciones no tendrán problemas de seguridad.

Te diré nuestro enfoque interno:

• Todas las aplicaciones utilizan un único usuario de dominio al que se le otorgan los permisos necesarios en una base de datos (generalmente rol de base de datos db_owner).

• para la lectura ocasional de datos usamos un inicio de sesión SQL. Para ese usuario asignamos el rol de base de datos: db_datareader. Aquí es donde finaliza el acceso para desarrolladores en el clúster de base de datos principal. Para cualquier otra idea que tengan, utilizarán las bases de datos del servidor de informes, que son copias (realizadas mediante Log Shipping) de las bases de datos del servidor principal realizadas a medianoche. Para no matar el servidor de informes con consultas ad hoc asesinas, utilizamos las asignaciones de grupos de recursos para memoria y CPU.

• para el equipo de DBA tenemos un grupo de dominio que tiene todos los privilegios en la máquina y el servidor (administrador en la máquina de Windows y sysadmin en el servidor sql)

• Para las instalaciones, tenemos un usuario SQL que es db_owner en las bases de datos que usamos cuando ejecutamos las actualizaciones: utilizamos desencadenadores DDL para monitorear los cambios de esquema y deberíamos ver qué cambios se realizaron durante la instalación o como un cambio por separado

• existen algunas excepciones ocasionales para desarrolladores experimentados, pero una vez que se satisface su necesidad, eliminamos su acceso: reciben permisos en función de su inicio de sesión de dominio, por lo que podemos monitorear las conexiones en las vistas de seguimiento / ddl y cualquier posible cambio con los activadores ddl.

En cuanto a la forma de hacer todo lo que funciona con los inicios de sesión y los usuarios: en Management Studio, en la carpeta de seguridad del servidor, crea todos los inicios de sesión necesarios, y luego, los asocia con sus bases de datos y les asigna los roles que necesitan. Si escribe la acción en secuencia de comandos, verá que inicialmente se creará un inicio de sesión en el servidor, luego un usuario de la base de datos conectado a ese inicio de sesión y luego se le asignará un rol de base de datos para ese usuario. Puede mantener la secuencia de comandos en su conjunto de secuencias de comandos, de modo que pueda verificar cada vez qué usuarios deben estar en vivo y pateando y cuáles no.

En el servidor SQL, puede crear un usuario de base de datos y asignarlo database rolecon permisos de lectura / escritura / propiedad. Una vez que el usuario migra a producción, puede ir al usuario de la base de datos que migró y desmarcar las funciones que no desea que tenga. Por ejemplo, supongamos que el usuario Stan es miembro de db_owner (propiedad de la base de datos) en la prueba. Una vez que el usuario stan migra a producción, puede sacarlo de db_owner y asignarle solo un rol de db_datareader (solo lectura).

En SQL 2005+ se puede hacer un control más granular con schema. Consulte este enlace en el esquema para obtener más detalles.