Auditoría de centros de procesamiento de datos. Parte 3: Aspectos contractuales y de gestión energética

ÍNDICE

Auditoría de centros de procesamiento de datos. Parte 1: Seguridad física

Auditoría de centros de procesamiento de datos. Parte 2: Seguridad lógica

Auditoría de centros de procesamiento de datos. Parte 3: Aspectos contractuales y de gestión energética

Auditoría de centros de procesamiento de datos. Parte 3: Aspectos contractuales y de gestión energética

Buenas,

Tercera y última entrega. Hoy hablaremos, un poco más brevemente, de dos aspectos adicionales que pueden ser sujeto de un proceso de auditoría de un CPD. Especialmente importantes los asuntos contractuales, que a la larga siempre están presentes en un proceso de compra de tecnología o en la prestación de servicios de mantenimiento, y que adquieren especial relevancia en operaciones de externalización, habida cuenta de que en este tipo de operativas es posible abandonar el modelo de propiedad por el modelo de uso de recursos, con lo que se pierde control sobre la adquisición de equipos y sobre los contratos que giran a su alrededor.

También, dependiendo de la legislación y según el estilo de gestión de la organización, los preceptos de gestión energética pueden tener valor especial, ya sea por alineamiento con política interna o sistemas de gestión medioambiental, o incluso por la fiscalidad ventajosa que en muchas jurisdicciones tiene la explotación energética eficiente de CPDs. Y evidentemente, por el impacto positivo que siempre acarrea la gestión eficiente en la cuenta de resultados.

Aspectos contractuales

No existen pócimas mágicas en este apartado y tampoco pretende este ser un artículo donde se expliquen todas y cada una de las posibilidades existentes. Hay infinidad de maneras de afrontar esta tarea, pero en todas ellas se trata de hacer lo mismo: obtener cierto nivel de confianza en los acuerdos contractuales necesarios para operar el CPD sin que resultenn lesivos para los intereses de la organización.

A mí me ha ido bien recomendando que se establezca en el flujo del proceso de compras tantos puntos de control como áreas queramos que participen en el proceso y asesoren adecuadamente al comprador. En este caso, los departamentos de Seguridad y Gobierno deberían participar en las compras para poder suministrar a los decisores información valiosa sobre lo que se va a comprar desde el punto de vista de la seguridad, el gobierno y el cumplimiento.

El ejemplo típico que se puede presenciar estos días es la contratación de servicios en la nube. Imaginemos que la organización «A» ha decidido que, por cuestiones de rentabilidad, le es mucho más favorable sacar el proceso de nóminas de la organización, algo además relativamente frecuente en grandes organizaciones y que ha sido acelerado con la disponibilidad de servicios SAP, Oracle y similares que pueden contratarse en un modelo as a service. En este caso el negocio suele quedarse en la siguiente valoración: comparar el coste total de explotación resultante de mantener el servicio en propiedad frente al coste de la externalización de la infraestructura y el software. En paralelo se le suele echar un vistazo a los SLAs (es decir, si la cosa va mal, qué repercusión tiene esto sobre mi disponibilidad, cuánto tiempo se puede quedar el servicio sin operación, etc.), los modelos de soporte y eventualmente, se puede tirar de un Dun & Bradstreet o similar para ver qué proyección económica tiene el proveedor cara al futuro. Rara vez se va más allá, a no ser que otras áreas participen en el proceso.

Como podéis imaginar, la intervención de un departamento de Seguridad puede alertar al negocio de muchas cosas que van más allá de los costes y los SLAs primarios, lo cual puede servir para que los compradores adquieran un servicio en mejores condiciones globales, no sólo económicas. Así por ejemplo:

– Se pueden evaluar los riesgos de externalizar un proceso que contiene información con cierto nivel de criticidad y sensibilidad

– Se puede evaluar a priori la seguridad solicitando evidencias sobre cómo se gestiona por parte del proveedor de servicios

– Se puede sugerir la inclusión de cláusulas de auditabilidad

– Se pueden advertir problemas potenciales de conflicto de interés por la ausencia de controles de segregación en la solución a contratar

Aunque este es sin duda objecto de una labor de auditoría con mucho más alcance -como por ejemplo la auditoría de un proceso de compras- es recomendable, al menos, indagar en los mínimos y tener una idea clara de cómo se gestionan los contratos en un CPD, haciendo especial hincapié en niveles de servicio, condiciones, garantías y seguridad del proveedor. A grosso modo, algunas de las áreas que suelen encerrar sorpresas son:

– Los servicios de mantenimiento de terceros, y concretamente, los niveles de servicio y condiciones de reposición de materiales y traslado de técnicos en caso de incidencias

– Las condiciones para que el proveedor establezca distintos niveles de criticidad en eventos de disrupción operacional así como los tiempos de respuesta resultantes. Ojo a los eventos de seguridad

– La ausencia de cláusulas de auditabilidad en los procesos de externalización, lo que impide realizar verificaciones de seguridad y auditoría en caso de contratarse

– La declinación de responsabilidad del proveedor en caso de que exista un incidente de seguridad en la infraestructura y el software que mantiene para nosotros

– Políticas de gestión de cambios que no se acomoden a nuestras necesidades (especiamente, instalación de parches y actualizaciones)

– La ausencia o deficiencia de las operaciones de seguridad en el servicio: cortafuegos, IDS e IPS, SIEM, etc.

– La ausencia o deficiencia de mecanismos de continuidad de servicios, locales y remotos.

Son tan sólo algunos ejemplos. Conviene dedicar tiempo a ver este tema con profundiad, y articular, en cooperación con el área Legal, las cláusulas mínimas que deben ser incorporadas.

Gestión energética

En el área de gestión energética el objetivo principal que se persigue es combinar el ahorro con la aplicación de medidas favorables con el medio ambiente. Es frecuente encontrar en la literatura referencias a dos conceptos: Power Usage Effectiveness (PUE) y Data Center Efficiency (DCE) como indicadores de gestión energécitca en un CPD.

Matemáticamente son conceptos muy sencillos de obtener: PUE equivale a la relación entre la carga energética total del CPD respecto a la carga total necesaria para alimentar los equipos de TI, con lo que se calcula dividiendo ambos. DCE es el resultado, en porcentaje, de la operación inversa, es decir, qué porcentaje de energía es necesario para alimentar el equipamiento TI respecto al total de las instalaciones.

Así, por ejemplo, si la potencia necesaria para la alimentación de equipamiento de TI es de 10 KW y la potencia total del CPD es de 12 KW, tendremos que el PUE es de 1.2, mientras que el DCE será del 83%, lo que implica que estamos en un CPD muy eficiente. Si la carga TI es de 10 KW y la potencia total del CPD es de 35 KW, el PUE se dispara a 3.5 mientras que el DCE se reduce al 29%, lo que implica que estamos ante un CPD muy ineficiente, en el que gran parte de la energía no se destina a la tarea fundamental de un CPD, que es el alojamiento y operación de tecnología.

Orientativamente, suelen considerarse como válidos los siguientes valores y calificaciones energéticas:

– PUE 3.0 y DCE del 33%: Centro muy ineficiente
– PUE 2.5 y DCE del 40%: Centro ineficiente
– PUE 2.0 y DCE 50%: Centro intermedio
– PUE 1.5 y DCE 67%: Centro eficiente
– PUE 1.2 y DCE 83%: Centro muy eficiente

A la vista de estas definiciones, la ecuación es clara: cuanto menor es el PUE, más ahorramos. Y esto no es porque lo diga yo: menor PUE significa que el gasto energético en lo que no es alimentación TI -en igualdad de carga de equipamiento- es menor, con lo que la factura energética es también menor.

Como podéis imaginar, el grueso de la energía no estrictamente dedicada a los elementos de TI es principalmente la refrigeración, y por tanto, es el factor que casi siempre hace que el PUE suba o baje. Es fundamental por tanto tener un control muy estricto sobre las condiciones de refrigeración y concretamente, sobre los flujos de aire. Esta disciplina se puede complicar todo lo que se quiera y más, y es muy recomendable documentarse al respecto para averiguar la contidad de parámetros que pueden afectar a la circulación de aire dentro de un CPD. Creedme que es una disciplina compleja, y que existen empresas especializadas en este tipo de optimización.

Otro aspecto a tener en cuenta es determinar cuáles son los umbrales de refrigeración que se hayan definido: más de una ve he entrado en un CPD que en vez de un centro de proceso parecía una cámara de congelación de Pescanova, con el consiguiente despilfarro energético. Entre el frío polar y el calor sahariano siempre hay un término medio en el que la operación no queda comprometida, y cada vez se prefieren más las localizaciones donde se puede aprovechar la baja temperatura ambiente y la presencia de agua cercana para reducir el uso de acondicionadores de aire.

Por último conviene recordar que lograr la eficiencia energética en un CPD no es sólo problema del dueño del CPD. Igual que es nuestra obligación como propietarios la de interesarnos por lograr la eficiencia, por los motivos descritos, es tambien nuestra obligación conducir a los proveedores en esa dirección.

Un saludo, y hasta la próxima ;)

Auditoría de centros de procesamiento de datos. Parte 2: Seguridad lógica

ÍNDICE

Auditoría de centros de procesamiento de datos. Parte 1: Seguridad física

Auditoría de centros de procesamiento de datos. Parte 2: Seguridad lógica

Auditoría de centros de procesamiento de datos. Parte 3: Aspectos contractuales y de gestión energética

Hola,

Retomamos nuestro hilo de auditoria de CPDs interrumpido por las vacaciones navideñas. Hoy tocaremos la segunda parte, una de las más importantes, que tiene que ver con seguridad lógica. Definir la seguridad lógica como aquella que compete a lo que no es estrictamente físico, y que como su propio nombre indica, deriva de las condiciones lógicas de los distintos sistemas que componen el proceso de negocio en estudio. El caso típico es la seguridad de los sistemas operativos, la reglas de un cortafuegos o la configuración de seguridad de un dispositivo de red, aunque hay muchos aspectos que no estando puramente vinculados a la seguridad lógica tienen impacto en ella. Veremos algunos ejemplos más adelante.

El enfoque nuevamente, tal y como explico en la primera parte, es contaros lo que suele ir mal, para ayudaros a enfocar los análisis en caso de tener que emitir una opinión de las condiciones de un CPD sin disponer para ello de excesivos recursos. Si queréis tener una guía completa podéis emplear las referencias bibliográficas incluidas en el primer artículo. Haceos cargo que cada uno de los escenarios que comento da, por sí mismo, para poder ejecutar una auditoría en profundidad, con lo que me es imposible narrar todo lo que hay que ver y analizar para cada uno de los aspectos. Prefiero mencionar los tópicos, y que cada cual pondere en cada caso la cantidad de esfuerzo que quiere dedicar a cada aspecto.

Lo que suele ir mal

En mi experiencia la mayoría de CPDs suelen tener buena seguridad física, y es en la seguridad lógica donde suelen pinchar. Es común observar deficiencias en los siguientes aspectos:

  • Actualización de los sistemas. Englobamos aquí todos los problemas relacionados con la falta de actualización de los elementos del centro de datos: sistemas operativos, aplicaciones, firmware … Conviene siempre obtener evidencias de que los sistemas se están actualizando, y es deseable poder verificar con alguna herramienta de análisis de vulnerabilidades la fiabilidad de lo que nos cuentan con los papeles por delante. Atentos a este punto, no existe CPD en todo el universo que tenga todos y cada uno de los elementos actualizados.
  • Configuración de seguridad. Otro clásico. En este apartado incluimos la ausencia de seguridad que deriva de la falta de militarización de los componentes puestos en producción. Ejemplos típicos son la ausencia de fortificación de los sistemas operativos, o dejarse por ahí usuarios por defecto. Es un campo denso, y por tanto, conviene obtener justificación de cómo se fortifican los servicios. Generalmente es aceptable obtener una lista de procedimientos de fortificación por sistema, y verificar aleatoriamente alguno de los elementos para ver que se están aplicando. Si queréis una pista, echad un ojo a los accesos web de los routers y switches, los servicios en escucha en los sistemas operativos y las políticas de contraseñas de los elementos. Sacaréis algo siempre.
  • Motorización operacional. Son todas las actividades que ocurren en la sala de control del CPD, y que generalmente tienen que ver con la motorización operativa, es decir, la que se encarga de que las cosas están funciones con normalidad en el natural desenvolvimiento de la actividad. Aunque estrictamente hablando estos procesos son operativos, cuando son insuficientes también son menores las posibilidades de capturar eventos de seguridad que tengan reflejo en el funcionamiento normal de los procesos de negocio o que causen disrupciones, como por ejemplo, los DDoS. Dedicad un buen rato a hablar con el jefe de sala, y sentaos con los operadores para ver que se monitoriza, de qué manera, y cómo se reacciona ante incidentes. Pedir el registro de incidencias es siempre aconsejable para ver que allí se está trabajando con seriedad y no mirando las pantallas.
  • Operaciones de seguridad. El gran ausente en muchas ocasiones. En un CPD tiene que haber operaciones de seguridad, sí o sí. Un CPD que no disponga de operaciones de seguridad es simplemente inconcebible. Este saco es tremendamente amplio, pero aquí entran todos los mecanismos usuales de prevención y reacción ante incidentes de seguridad: IDS/IPS, firewalls, honeypots, gestión antifraude, SIEM, DLPs, etc. Hay que dedicar tiempo a entender bien lo que hay en funcionamiento, qué se esta monitorizando, por quién y cómo se garantiza que la propia infraestructura de seguridad sirva para su propósito y no esté expuesta a intromisiones o ataques. Alerta roja si nadie es capaz de contarte en unos minutos al menos qué hay en funcionamiento para prevenir incidentes de seguridad. Una vez más, registro de incidentes de seguridad, iros a los últimos incidentes de severidad máxima, y comprobad qué se hizo, cómo y por quién.
  • Segregación de entornos. Otro clásico. Por motivos diversos, que van desde la ignorancia o los errores hasta los intentos de reducción de costes mal enfocados, es relativamente frecuente toparse con entornos que no están debidamente segregados desde el punto de vista lógico. Tener entornos de producción, aceptación, soporte, desarrollo y pruebas compartiendo los mismos discos en distintas particiones es normal, pero también es posible cometer errores de configuración que permitan el salto entre particiones. Generalmente el peligro deriva de la posibilidad de tener desarrolladores accediendo a producción, ya que podrían obtener información que no deben conocer, o incluso modificar componentes. También es posible que se produzcan accesos no autorizados y manipulación de los datos desde otros entornos, como los de soporte, lo cual es especialmente problemático si el soporte lo hace alguna contrata externa. No hay reglas de oro en este capítulo, pero hay que ser férreo cuando se analice este aspecto. Yo suelo sentarme con la gente de desarrollo, y les pido que intenten conectar a bases de datos de producción, o simplemente, que tiren unos pings en la consola para ver si pueden acceder a las máquinas, caso que la segregación esté hecha de esta manera.
  • Datos reales en entornos no controlados. Conviene cerciorarse de que los entornos no controlados, generalmente desarrollo y pruebas, no contienen datos reales, o que contemplan medidas de enmascaramiento para impedir que los datos reales de la producción acaben en las memorias USB de los desarrolladores. El principal problema aquí es precisamente ese, que los juegos de datos que se empleen en desarrollo y procedan de los entornos de producción y que no hayan sido convenientemente enmascarados para impedir fugas de información. También es posible encontrarse ficheros y clones de bases de datos en entornos no controlados. Dedicad tiempo a entender cómo se obtienen los juegos de datos de desarrollo y pruebas, y que en caso de ser datos reales, están enmascarados.
  • Cifrado. Amplísimo campo, imposible de tratar en profundidad. Comprobad que en general los datos en tránsito y en reposo están cifrados allí donde es suspectible interceptarlos, por ejemplo, en las copias de seguridad de la cintoteca, o la posibilidad de interceptar el tráfico de explotación, que podría contener datos confidenciales como usuarios y contraseñas.
  • Compartimentalización de la red. Fundamental. Las redes tienen que tener suficiente segmentación no sólo para poder soportar adecuadamente la segregación de entornos, sino la creación de zonas con distintos requisitos de seguridad. La ausencia de zonas y compartimentalización es un problema de la mayor relevancia, y suele tener su expresión típica en aquellos casos en los que se compromete una máquina determinada, y que por ausencia de segregación, este compromiso faculte el salto a otros segmentos y servicios ajenos al originalmente comprometido que pueden provocar compromisos en cadena. También es frecuente sufrir pérdida operativa en eventos de mantenimiento a consecuencia de una mala compartimentalización, que puede obligar a detener servicios que no son objeto de mantenimiento por el mero hecho de residir en los mismos segmentos de la red en mantenimiento. Aunque no es una regla matemática que se cumpla al 100%, en la gran mayoría de ocasiones la gestión de redes o bien es un desastre soberano o bien es excelente, siendo raro el término intermedio. Cosas que deben haceros sospechar de que hay un chiringuito en ciernes son la ausencia de herramientas centralizadas para la gestión de red y la ausencia de diagramas de red, aunque cuidados con estos últimos, los maestros del Visio y el Powerpoint pueden pintar mucho y ejecutar poco.
  • Gestión de cambios. Muchos pensaréis que de entrada es un tema más procedimental que de seguridad lógica, pero las consecuencias sobre la misma son evidentes. Además del citado problema de la falta de actualización otros muchos ejemplos son posibles, algunos frecuentemente olvidados al revisar la seguridad de un CPD. La colocación de código malicioso en la producción por la falta de herramientas de inspección automática del código, o la colocación de programas en producción sin ningún tipo de supervisión por la propia ausencia de una gestión de cambios es una posibilidad que ocurre con cierta habitualidad. Aunque la regulación no implica seguridad, este asunto es siempre tratado en gobierno de TI y cumplimiento, así que echar un ojo a informes al respecto nunca está de más. Solicitad evidencias de la aprobación de un cambio determinado, por ejemplo, un diferencial de código en un programa COBOL del core, y comprobad que está autorizado convenientemente, y que lo que hay en producción es un calco de la versión del programa en desarrollo correspondiente.
  • Accesos privilegiados. En un CPD es necesario tener accesos privilegiados para poder operar los servicios. Es una consecuencia natural del empleo de servicios que contemplan gestión de usuarios, como por ejemplo, los sistemas operativos, aunque el acceso privilegiado puede venir definido por otros aspectos, como por ejemplo, segmentos de red determinados en la explotación que son capaces de acceder a servicios críticos. Sea como fuere estos accesos son necesarios, con lo que es de vital importancia comprobar que están bien gestionados. No es sólo una cuestión de verificar que las contraseñas se rotan periódicamente y que la gente no las tiene pegadas en post it en los monitores, es de capital importancia determinar cómo se puede acceder con cuentas privilegiadas a los servicios. Especialmente preocupante si se habilitan accesos remotos para facultar la intervención fuera de horas de oficina o teletrabajo. Cualquier respuesta no inmediata o no concluyente a las preguntas quién accede, cómo y dónde se guardan los logs de estos accesos que quiero verlos es sinónimo de emergencia. Pedir una lista de los usuarios con privilegios altos en un servicio y una explicación de quién es quién suele ser revelador.
  • Accesos remotos de terceras partes. Tratad de comprender cómo acceden las terceras partes a la infraestructura, y cuáles son las limitaciones de su acceso. En aquellos casos donde el desarrollo lo hacen contratas externas, donde también es posible que se ocupen del mantenimiento, es crucial entender cómo acceden y cuál es su nivel de privilegio. Aunque es normal que estos accesos se hagan con cabeza, mediante conexiones VPN o circuitos MPLS dedicados, cercioraos de tener absolutamente claro quién accede y cómo. Revisad si los accesos se monitorizan, especialmente en funciones de soporte. Pedir una lista de terceras partes y detalles de conectividad, y no obtener respuesta inmediata, es síntoma de alerta.
  • Entornos multicliente (multitenancy). En casos de CPDs públicos o semipúblicos es posible que los servicios sean utilizados por varios clientes. Es un tema de compartimentalización tanto de red como de los propios servicios y sus entornos, así como el de los accesos privilegiados que se concedan al cliente, aunque quiero destarcar de modo independiente por la creciente adopción de estos modelos. No queremos que el root de la competencia pueda ver nuestros datos, ni viceversa. Ni queremos que nuestra base de datos pueda ser accedida desde la partición y las aplicaciones de otro cliente. Tema complejo de resolver, ya qu