Mati

Esto que puede servir, un solo parrafo de una nota corta (traducción
rápida, perdón por los errores):

"Los administradores de base de datos son la posisción más dificil de
controlar. Si uno quiere que la base de datos funciones, todas las tablas
se deben poder combinar (join). Los DBA debería tener solamente el
privilegio de DBA, ni root ni administrador. Es posible cifrar el contenido
de algunos campos sensibles en la base de datos. Considere las herramientas
que manejan y auditan el acceso a las bases de datos tales como Imperva.
Toda la actividad de las cuentas con privilegios altos debería ser logueada
y revisada diariamente por un tercero independiente"

"Database administrators are the hardest position to control. If you want
the database to work, all tables probably have to join. DBAs should only
have DBA authority, not root or administrator. It may be possible to
encrypt the content of some sensitive fields in the database. Consider
tools that manage and audit database access, such as Imperva. All activity
for accounts with elevated privileges should be logged and reviewed daily
by an independent party. "

De:
http://www.sans.edu/research/security-laboratory/article/it-separatio...

Hay otros documentos interesantes, sobre auditoria. Si sabes que se audita
y controla podes orientarte en los permisos, restricciones y demás ajustes
preventivos, al menos en una parte importante de ellos. Salvo que tengas
algo mejor y explicito en la politica de seguridad de la organización:

Auditing the DBA: What non-technical managers and auditors should know
http://www.absolute-tech.com/download/Auditing_the_DBA_Whitepaper.pdf

http://www.sans.org/reading_room/whitepapers/auditing/conducting-secu...

y otros que son sobre MS SQL
www.appsecinc.com/presentations/Security_Auditing_MSSQL.pdf
http://technet.microsoft.com/en-us/library/cc966507.aspx

Para el punto 1 de tu pregunta:
Restringir los permisos del DBA para que no pueda hacer cambios a la base.
Establecer un perfil alternativo para que si pueda hacerlo y se generen
logs. Habilitarlo sobre pedido documentado y autorizado. Habilitarlo por
tiempo limitado

Punto 2:
En cuanto a lo que digan de IT respecto de espacio y performance, si se
planifica y justifica adecuadamente agregar logs, cifrado, etc. deberías
obtener el apoyo para que se haga y se tome como un requerimiento de
negocio. Nunca van a aceptar o recibir de mucha gana en IT el agregar algo
que cargue a la Base de datos que no les sirva para administrar el
servicio. Si IT y seguridad están separados, siempre tienen intereses que
se oponen, es natural y hasta necesario.

A modo de ejemplo, un sistema SAP de fábrica hace logs de cambio de todos
los registros de cuestiones contables auditables para SOX y también de los
cambios a permisos de usuarios y perfiles de autorización. Digo esto para
que tengas en cuenta que la oposición de IT no tiene fundamento salvo que
las cosas se implementen bien, con recursos adecuados y suficientes para
dar un buen servicio.

Saludos,
Raúl

El 26 de enero de 2012 12:48, Mati Pigigio <mpigi...@gmail.com> escribió: