Hola estimados amigos, tengo un problema en la institucion que
trabajo, respecto a las modificaciones realizadas directamente en la
Base de Datos por parte del DBA y del cual espero sus valiosas
sugerencias:
El DBA posee contraseña de administrador en la Base, lo que le da
privilegios para modificar cualquier registro de esta, por lo que
solicito ayuda para resolver los siguientes cuestionamientos:
1-.¿Cual sería un CONTROL PREVENTIVO que evite que el DBA no ejecute
ninguna acción sobre la DB a menos que haya sido debidamente
autorizado?
2.- Tenemos habilitada la función de auditoría para el Oracle pero se
encuentra habilitada únicamente sobre ciertas tablas, las cuales en mi
opinión, no son de Mayor relevancia. El departamento de TI justifica
que el crecimiento de la Base sería demasiada carga para el
almacenamiento por lo que únicamente se ha habilitado sobre tablas de
parámetros y no sobre tablas que mantienen los registros del CORE del
negocio. ¿Que acción correctiva podría realizar al respecto?
Mati, personalmente el DBA debe tener permisos de Sysadmin, ya que él es quien administra la/las base/s. Se debe llevar un control de cambios como cualquier otro proceso de la compañía. Este persona debe saber y conocer de bases como ningun otro, ademas de ser de confianza, o sea, si tenes alguna duda de la persona, o no te inspira confianza, capas debes poner otra mas.
Saludos, Eduardo.
El 26 de enero de 2012 12:48, Mati Pigigio <mpigi...@gmail.com> escribió:
> Hola estimados amigos, tengo un problema en la institucion que > trabajo, respecto a las modificaciones realizadas directamente en la > Base de Datos por parte del DBA y del cual espero sus valiosas > sugerencias:
> El DBA posee contraseña de administrador en la Base, lo que le da > privilegios para modificar cualquier registro de esta, por lo que > solicito ayuda para resolver los siguientes cuestionamientos:
> 1-.¿Cual sería un CONTROL PREVENTIVO que evite que el DBA no ejecute > ninguna acción sobre la DB a menos que haya sido debidamente > autorizado? > 2.- Tenemos habilitada la función de auditoría para el Oracle pero se > encuentra habilitada únicamente sobre ciertas tablas, las cuales en mi > opinión, no son de Mayor relevancia. El departamento de TI justifica > que el crecimiento de la Base sería demasiada carga para el > almacenamiento por lo que únicamente se ha habilitado sobre tablas de > parámetros y no sobre tablas que mantienen los registros del CORE del > negocio. ¿Que acción correctiva podría realizar al respecto?
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. "
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:
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ó:
> Hola estimados amigos, tengo un problema en la institucion que > trabajo, respecto a las modificaciones realizadas directamente en la > Base de Datos por parte del DBA y del cual espero sus valiosas > sugerencias:
> El DBA posee contraseña de administrador en la Base, lo que le da > privilegios para modificar cualquier registro de esta, por lo que > solicito ayuda para resolver los siguientes cuestionamientos:
> 1-.¿Cual sería un CONTROL PREVENTIVO que evite que el DBA no ejecute > ninguna acción sobre la DB a menos que haya sido debidamente > autorizado? > 2.- Tenemos habilitada la función de auditoría para el Oracle pero se > encuentra habilitada únicamente sobre ciertas tablas, las cuales en mi > opinión, no son de Mayor relevancia. El departamento de TI justifica > que el crecimiento de la Base sería demasiada carga para el > almacenamiento por lo que únicamente se ha habilitado sobre tablas de > parámetros y no sobre tablas que mantienen los registros del CORE del > negocio. ¿Que acción correctiva podría realizar al respecto?
Recuerdo en una empresa en particular, la cual tenia bases de SQL, Oracle y DB2, lo que habian echo era que cada DBA tenia su trabajo cotideano + auditar la actividad uno y revisar el informe de auditoria del otro (que obviamente trabajaban en sectores diferentes), era una solucion muy practica...
Tomemos en cuenta que un DBA si esta bien pensado todo, no debería tener una jornada muy ocupada, y en cualquier caso, es raro que este manoseando todo el tiempo los datos de las bases...
Si gustan puedo preguntar mas en detalle como era eso...
Slds.-
Sender: forosi@googlegroups.com
Date: Thu, 26 Jan 2012 13:35:11 To: <forosi@googlegroups.com>
Reply-To: forosi@googlegroups.com
Subject: Re: [forosi:19552] Modificaciones en la Base de Datos por el DBA
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. "
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:
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ó:
> Hola estimados amigos, tengo un problema en la institucion que
> trabajo, respecto a las modificaciones realizadas directamente en la
> Base de Datos por parte del DBA y del cual espero sus valiosas
> sugerencias:
> El DBA posee contraseña de administrador en la Base, lo que le da
> privilegios para modificar cualquier registro de esta, por lo que
> solicito ayuda para resolver los siguientes cuestionamientos:
> 1-.¿Cual sería un CONTROL PREVENTIVO que evite que el DBA no ejecute
> ninguna acción sobre la DB a menos que haya sido debidamente
> autorizado?
> 2.- Tenemos habilitada la función de auditoría para el Oracle pero se
> encuentra habilitada únicamente sobre ciertas tablas, las cuales en mi
> opinión, no son de Mayor relevancia. El departamento de TI justifica
> que el crecimiento de la Base sería demasiada carga para el
> almacenamiento por lo que únicamente se ha habilitado sobre tablas de
> parámetros y no sobre tablas que mantienen los registros del CORE del
> negocio. ¿Que acción correctiva podría realizar al respecto?
Con cuerdo con Raúl, lo ideal es q las tareas del DBA estén documentadas y registradas en un log, no se deben utilizar los usuarios por defecto de las BD, el dba no debe tener acceso a los log para su alteración. Revisiones periódicas de lo log,
Sender: forosi@googlegroups.com
Date: Thu, 26 Jan 2012 13:35:11 To: <forosi@googlegroups.com>
Reply-To: forosi@googlegroups.com
Subject: Re: [forosi:19552] Modificaciones en la Base de Datos por el DBA
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. "
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:
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ó:
> Hola estimados amigos, tengo un problema en la institucion que
> trabajo, respecto a las modificaciones realizadas directamente en la
> Base de Datos por parte del DBA y del cual espero sus valiosas
> sugerencias:
> El DBA posee contraseña de administrador en la Base, lo que le da
> privilegios para modificar cualquier registro de esta, por lo que
> solicito ayuda para resolver los siguientes cuestionamientos:
> 1-.¿Cual sería un CONTROL PREVENTIVO que evite que el DBA no ejecute
> ninguna acción sobre la DB a menos que haya sido debidamente
> autorizado?
> 2.- Tenemos habilitada la función de auditoría para el Oracle pero se
> encuentra habilitada únicamente sobre ciertas tablas, las cuales en mi
> opinión, no son de Mayor relevancia. El departamento de TI justifica
> que el crecimiento de la Base sería demasiada carga para el
> almacenamiento por lo que únicamente se ha habilitado sobre tablas de
> parámetros y no sobre tablas que mantienen los registros del CORE del
> negocio. ¿Que acción correctiva podría realizar al respecto?
Si usas IMPERVA ya no vas a tener ningun problema con el DBA en cuanto a control de acceso y bitacoras, es una solución pagada pero es muy buena para quitarte dolores de cabeza.
Hay una llamada FortiDB de Fortinet que en realidad no la he evaluado, pero según dicen solo hace bitacoras pero es más barata que la anterior.
Alli seria evaluar costo beneficio, recuerda que las bitacoras las podes tener en un servidor fuera de Oracle en algo tipo SQL server con protección hasta fisica de personas no autorizadas , con estos software y ademas te envian alertas ejm. correo electrónico o teléfono móvil. Estas herramientas ademas les podes automatizar la depuración de la data cuando pasa cierto tiempo.
> Hola estimados amigos, tengo un problema en la institucion que > trabajo, respecto a las modificaciones realizadas directamente en la > Base de Datos por parte del DBA y del cual espero sus valiosas > sugerencias:
> El DBA posee contraseña de administrador en la Base, lo que le da > privilegios para modificar cualquier registro de esta, por lo que > solicito ayuda para resolver los siguientes cuestionamientos:
> 1-.¿Cual sería un CONTROL PREVENTIVO que evite que el DBA no ejecute > ninguna acción sobre la DB a menos que haya sido debidamente > autorizado? > 2.- Tenemos habilitada la función de auditoría para el Oracle pero se > encuentra habilitada únicamente sobre ciertas tablas, las cuales en mi > opinión, no son de Mayor relevancia. El departamento de TI justifica > que el crecimiento de la Base sería demasiada carga para el > almacenamiento por lo que únicamente se ha habilitado sobre tablas de > parámetros y no sobre tablas que mantienen los registros del CORE del > negocio. ¿Que acción correctiva podría realizar al respecto?
