Robusteciendo y auditando DB2

Hola,

En el mundo de la seguridad suelen darse situaciones en las que tratar de mejorar puede conducir, caso de errar, a obtener efectos adversos y perniciosos. Es el caso de aquellas infraestructuras críticas que requieren un férreo control de la seguridad, pero que a su vez, según crece el nivel de seguridad, sufren descensos del rendimiento que pueden hacer incurrir a los negocios en lucro cesante y en la necesidad de adoptar inversiones que pueden superar el coste de los impactos que se prevean, caso que materialicen los riesgos que se esté considerando mitigar.

Un ejemplo de estas situaciones de difícil balance lo protagoniza habitualmente DB2. La vara para medir el grado de seguridad deseado versus los impactos en los negocios y los costes de mitigación tiene que estar muy especialmente afinada, especialmente cuando corre dando soporte a core de negocio en un mainframe. En estos entornos, equivocarse puede costar millones de euros y daños irreversibles a la imagen y la reputación de los negocios que los utilizan, con lo que no son admisibles los errores.

La dificultad de sugerir medidas de seguridad y auditoría en DB2 estriba en la propia complejidad del producto y sobre todo, de las instalaciones donde habita. Instituciones financieras, compañías de seguros, instalaciones centrales de administraciones y gobiernos, control industrial de largo alcance … entornos lo suficientemente críticos como para que antes de determinar qué medidas se proponen se hayan considerado muy seriamente los impactos. No son entornos donde uno pueda llegar alegremente solicitando que se cifre la información de la base de datos, o sugiriendo que se activen a todo trapo los mecanismos de auditoría de lectura y modificación de datos. Recomendaciones drásticas e incompletas de este tipo tardan poco en caerse:

Consultor/auditor: Verá, es que sus datos no están cifrados. Solución: a cifrarlo todo, así nos aseguramos de que cualquier hacker bielorruso que entre en el perímetro de seguridad no pueda llevarse dato alguno.

Negocio/dueño del proceso: ¿Cuánto me cuesta la gracia? ¿en cuánto tiempo recupero la inversión? ¿cuántos euros dejo de ganar si no hago esto que Usted me dice?

Consultor/auditor: Esto, mmmm, aha …

—-

Consultor/auditor: Hay que activar para toda la base de datos los mecanismos de auditoría de lectura y modificación de datos, o de lo contrario, no sabrá quién ha leído un dato o lo que es peor: quién lo ha modificado.

Negocio/dueño del proceso:¿Y quién va a revisar los logs que Usted me dice que hay que generar? ¿Usted sabe que en un online genero 300 gigas de datos, y en un batch tera y medio? ¿cuántas personas tengo que meter en nómina para abordar el análisis? ¿Podría ver su estimación de perjucios económicos en caso de que, por no tener las auditorías activadas, alguien cambie una fecha de vencimientos de mis pólizas de seguros?

Consultor/auditor: Esto, mmmm, aha … (2)

Al hilo de la seguridad y auditoría en DB2, podéis echar un ojo al libro Securing and Auditing Data on DB2 for z/OS, en el que se exponen distintas maneras de abordar el problema no sólo con los mecanismos propios de DB2, sino también con la propia arquitectura de seguridad z/OS. Que nadie piense que el texto resuelve el eterno de problema de qué recomendar cuando auditemos un DB2 o cualquier otra base de datos de alta transaccionalidad, porque eso sólo puede determinarse con un estudio riguroso que enfrente riesgos, sus probabilidades de ocurrencia y la relación impacto-coste que entraña cada uno de los focos de exposición.

Un saludo,