Seguridad y Auditoria de un Centro de Procesamiento de Datos

Publicado el en Artículos, Redes, Seguridad

Twitter14Google+1Facebook3LinkedIn0StumbleUpon0tumblrEmail

En este artículo hablaremos un poco de la Seguridad y Auditoría de un Centro de Procesamiento de Datos. La definición que se tiene de forma general para un Centro de Procesamiento de Datos (CPD), es aquella ubicación donde se concentran los recursos necesarios para el procesamiento de la información de una organización. Dichos recursos consisten esencialmente en unas dependencias debidamente acondicionadas, computadoras y redes de comunicaciones.

En general, la función de la Seguridad y Auditoría en los Centros de Procesamiento de Datos en la empresa es garantizar que los sistemas de ordenador salvaguardan los “bienes” de la organización, mantienen la integridad de los datos y alcanzan los objetivos de la empresa de un modo eficaz y efectivo.

En estos se deben de tener en cuenta algunas consideraciones especiales, dado que en ellos se concentran datos y aplicaciones informáticas en espacios muy reducidos, lo que los hace excepcionalmente propensos a problemas potenciales, tanto lógicos como físicos, que pueden afectar a su seguridad y funcionamiento.

Entre los factores más importantes que motivan la creación de un CPD se puede destacar el garantizar la continuidad del servicio a clientes, empleados, ciudadanos, proveedores y empresas colaboradoras, pues en estos ámbitos es muy importante la protección física de los equipos informáticos o de comunicaciones implicados, así como servidores de bases de datos que puedan contener información crítica.

El diseño de un centro de procesamiento de datos comienza por la elección de su ubicación geográfica, y requiere un equilibrio entre diversos factores, solo por mencionar algunos podemos hablar de Coste económico, Infraestructuras disponibles, riesgo, acometida eléctrica, Medidas de seguridad en caso de incendio o inundación, Aire acondicionado, Cableado de red y teléfono, Instalación de alarmas, control de temperatura y humedad, Cerraduras electromagnéticas, Cámaras de seguridad, Tarjetas de identificación y un largo etc.

Como vemos, la creación de un Centro de procesamiento de datos, de una forma correcta es compleja, y su administración también lo es.

Seguridad Física

Entran dentro de esta categoría todas las medidas para asegurar la integridad física de los equipos almacenados. Desde la verja exterior hasta los mecanismos de extinción de incendios. Son muchos los factores que intervienen. Los centros de procesamiento de datos suelen tener buenas características de seguridad física, ya que si son suficientemente serios, se diseñan con la seguridad en mente. No obstante suele ser común encontrarse sorpresas en las siguientes áreas:

  • Control de acceso. Especialmente en las zonas “cero”, es decir, aquellos compartimentos del centro de procesamiento de datos que albergan la infraestructura más valiosa. En una infraestructura de este tipo es deseable siempre tener control en tiempo real de quién entra a dónde, y para qué. No encontrarse con un sistema de control de acceso que genere los registros adecuados y los conserve convenientemente es motivo de incidencia. Se van implantando poco a poco sistemas biométricos y siguen siendo válidos los mecanismos de acceso con tarjetas inteligentes. No hay que limitarse a la hora de pedir logs de los sistemas de control, y no es de extrañar que surjan problemas. Por increíble que parezca, este es un tema donde siempre aparecen incidencias.
  • Pruebas de mecanismos de detección y alarma. Todos los responsables de seguridad física te enseñarán extintores, la sala de contraincendios, los sensores de humedad, de temperatura, de detección de humo y de movimiento. Pero no todos pueden enseñarte pruebas fehacientes de que estos sistemas están siendo probados regularmente y que funcionan como es debido. En muchos países, y por motivos de legislación, es obligatorio realizar pruebas periódicas de los sistemas, pero no hay que asumir que esto pasa en todos los sitios y que las pruebas son exhaustivas. Es recomendable dedicar tiempo a esto.
  • Acceso de mercancías y personal de proveedores. No sería la primera vez que llegar a las zonas cero del centro de procesamiento de datos es imposible si se pretende la intrusión a través de las vías de acceso convencionales, pero sencillo o relativamente sencillo si se utilizan los accesos especiales para equipamiento y proveedores. A modo de ejemplo, si se adquieren grandes servidores, no vas a meterlo por el torno de acceso de los empleados y a maniobrarlo por los pasillos. Para esto existen accesos especiales, generalmente un muelle de carga y descarga donde las mercancías son gestionadas. Estos puntos de acceso deben ser mirados con lupa, aquí se pueden encontrar desde “fulanos” con destornillador en mano caminando solos por la zona cero a puertas del muelle abiertas de par en par y con gente metiendo y sacando cajas, por citar algunos ejemplos.
  • Ausencia de seguridad perimetral o seguridad perimetral insuficiente. Aunque suene a broma, es algo que puede suceder. No es la primera vez que un centro de procesamiento de datos tiene medidas internas de seguridad físicas excepcionales y que luego, al darse uno una vuelta por allí, descubre que todo está protegido por una verja que un niño de 7 años puede saltarse, o que hay una ventana abierta por la que entrar y quitarse de encima la mayoría de controles de acceso. Si has quedado a las 9 para auditar, procura estar allí a las 8 u 8.30 y date una vuelta por fuera. Las sorpresas están al acecho.
  • Gestión de energía y continuidad. Es un tema amplio de tratar, y en definitiva engloba todo lo que tiene que ver con el aprovisionamiento energético del centro de procesamiento de datos; en estos centros se consume muchisima energía, y por tanto, requiere de medidas especiales para asegurar que el flujo energético esté garantizado ante cualquier tipo de incidente, y que en el peor de los casos, el suministro pueda ser establecido por medios alternativos. Por norma general el centro de procesamiento de datos suele tener dos o más acometidas de proveedores de energía eléctrica independientes, para no depender exclusivamente de un único proveedor, y es frecuente que internamente se hagan abastecimientos a zonas teniendo en cuenta si requieren máxima resiliencia eléctrica o no. Cuando todo va mal y se pierde completamente el fluido eléctrico, es normal contar con una batería de generadores diesel para garantizar el suministro en caso de contingencia eléctrica grave. Se sugiere que se hagan pruebas continuas de estos generadores. Un esquema unifilar que muestre la redundancia eléctrica suele ayudar igualmente. Como no vamos a andar apagando servidores para ver si aquello funciona, lo ideal sería solicitar acceso a un rack con tomas independientes eléctricas y hacer una visita a la sala de cuadros eléctricos para determinar si eso verdaderamente opera con acometidas independientes o no.
  • Ausencia de compartimentación. Especialmente relevante en el caso de data centers públicos o destinados al uso de múltiples clientes. En estos casos es de esperar que cada cliente tenga su infraestructura en una jaula y que la cerradura esté, lógicamente, cerrada. Mal asunto si al visitar nuestra infraestructura fuera posible tirar de un cable de la competencia.

También suelen encontrase otros numeroso tipo de problemas en los centros de procesamiento de datos, como jardines (:P); uno muy común es encontrar equipamiento/cuarto de herramientas para el departamento de informática, donde guardan cualquier cosa como monitores, viejas impresoras, etc.; otro error común es encontrar que el cableado pasa por todos lados menos por donde debe, puertas del rack abierta o sin puertas, servidores sin orden, cableado sin etiquetar, aire acondicionado sin suficiente potencia, un largo etc.

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.

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 procesamiento 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 centro de procesamiento de datos 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. Como dato, mirar 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.
  • Operaciones de seguridad. El gran ausente en muchas ocasiones. En un centro de procesamiento de datos tiene que haber operaciones de seguridad, sí o sí. Un centro de procesamiento de datos 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, ver los últimos incidentes de severidad máxima, y comprueba qué se hizo, cómo y por quién.
  • Segregación de entornos. 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. Hay que dedicar 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. Hay que comprobar que en general los datos en tránsito y en reposo están cifrados allí donde es susceptible interceptarlos, por ejemplo, en las copias de seguridad, 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 hacer sospechar son la ausencia de herramientas centralizadas para la gestión de red y la ausencia de diagramas de red.
  • Gestión de cambios. Se puede pensar 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 centro de procesamiento de datos. 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. Solicitar evidencias de la aprobación de un cambio determinado, por ejemplo, un diferencial de código en un programa COBOL del core, y comprobar 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 centro de procesamiento de datos 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 de 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. Tratar de comprender cómo acceden las terceras partes a la infraestructura es importante, y cuáles son las limitaciones de su acceso. En aquellos casos donde el desarrollo lo hacen empresas 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, hay que cerciorarse de tener absolutamente claro quién accede y cómo. Hay que revizar 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 centros de procesamiento de datos 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 hay que destacar 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 que los entornos multicliente son reacios a facilitar información, y no suelen ser permisivos con la ejecución de pruebas alegando que allí hay datos de más gente, así que aquí hay que ser cuidadosos y selectivos con las pruebas a realizar. En el momento que parte de la infraestructura es propiedad de una tercera parte, hay que asumir que se pierde parte del control, con lo que es imposible estar seguros al 100% de las cosas. Se debe pedir un test de intrusión reciente, revisiones de seguridad o análisis de aplicaciones puede servir para darnos claridad. Una vez más, aunque ya sabemos que compliance is not security, nunca está de más ojear informes regulatorios que puedan existir -y que de hecho suelen existir-, ni tampoco huelga preguntar por los sistemas de gestión de la seguridad y su alcance.
  • Continuidad y recuperación. Aspectos esenciales de un centro de procesamiento de datos. Las máquinas se rompen, la electricidad se pierde. Las tuberías se estropean. Y los servicios pueden quedar interrumpidos. Algunas cosas que deben ser obligatoriamente inspeccionadas son la presencia de mecanismos creíbles para que los servicios tengan la disponibilidad local adecuada, como por ejemplo, alta disponibilidad, así como los procedimientos existentes para garantizar la “resurrección” de los servicios en el centro de procesamiento de datos alternativo. Pedir los resultados de las pruebas de recuperación más recientes es siempre una buena idea, y la falta de las mismas equivale a alerta roja. Conviene también echar un ojo a cómo se gestiona la continuidad de la actividad, es decir, todo lo relacionado con disponibilidad del personal, de equipos y salas para gestionar emergencias, etc.

Seguridad Perimetral

Para ver el video debe tener Flash Player 10

La infraestructura y el estándar TIA-942

En abril de 2005, la Telecomunication Industry Association publica su estándar TIA-942 con la intención de unificar criterios en el diseño de áreas de tecnología y comunicaciones. Este estándar que en sus orígenes se basa en una serie de especificaciones para comunicaciones y cableado estructurado, avanza sobre los subsistemas de infraestructura generando los lineamientos que se deben seguir para clasificar estos subsistemas en función de los distintos grados de disponibilidad que se pretende alcanzar. En su anexo G (informativo) y basado en recomendaciones del Uptime Institute, establece cuatro niveles (tiers) en función de la redundancia necesaria para alcanzar niveles de disponibilidad de hasta el 99.995%.

A su vez divide la infraestructura soporte de un centro de procesamiento de datos en cuatro subsistemas a saber:

  • Telecomunicaciones
  • Arquitectura
  • Sistema eléctrico
  • Sistema Mecánico

Uno de los mayores puntos de confusión en el campo del uptime (tiempo disponible de los sistemas) es la definición de datacenter confiable; ya que lo que es aceptable para una persona o compañía no lo es para otra. Empresas competitivas con infraestructuras de datacenter completamente diferentes proclaman poseer alta disponibilidad; esto puede ser cierto y dependerá de la interpretación subjetiva de disponibilidad que se realice para el tipo de negocio en que se encuentre una compañía.

Lo cierto es que para aumentar la redundancia y los niveles de confiabilidad, los puntos únicos de falla deben ser eliminados tanto en el datacenter como en la infraestructura que le da soporte.

Los cuatro niveles de tiers que plantea el estándar se corresponden con cuatro niveles de disponibilidad, teniendo que a mayor número de tier mayor disponibilidad, lo que implica también mayores costos constructivos.

Esta clasificación es aplicable en forma independiente a cada subsistema de la infraestructura (telecomunicaciones, arquitectura, eléctrica y mecánica). Hay que tener en cuenta que la clasificación global del datacenter será igual a la de aquel subsistema que tenga el menor número de tier. Esto significa que si un datacenter tiene todos los subsistemas tier IV excepto el eléctrico que es tier III, la clasificación global será tier III.

Es importante tener en cuenta esto porque cuando se pretende la adecuación de datacenters actuales a tier IV, en lugares como América Latina, hay limitaciones físicas difíciles de salvar en los emplazamientos edilicios actuales. Prácticamente para lograr un datacenter tier IV hay que diseñarlos de cero con el estándar en mente como guía. Un ejemplo claro de esto es que es muy difícil lograr la provisión de energía de dos subestaciones independientes o poder lograr las alturas que requiere el estándar en los edificios existentes (3 m mínimo sobre piso elevado y no menor de 60 cm entre el techo y el equipo más alto).

La norma describe, resumidamente, los distintos tiers de la manera que sigue:

Tier I: centro de procesamiento de datos básico

Un datacenter tier I puede se susceptible a interrupciones tanto planeadas como no planeadas. Cuenta con sistemas de aire acondicionado y distribución de energía; pero puede o no tener piso técnico, UPS o generador eléctrico; si los posee pueden no tener redundancia y existir varios puntos únicos de falla. La carga máxima de los sistemas en situaciones críticas es del 100%.

La infraestructura del centro de procesamiento de datos deberá estar fuera de servicio al menos una vez al año por razones de mantenimiento y/o reparaciones. Situaciones de urgencia pueden motivar paradas más frecuentes y errores de operación o fallas en los componentes de su infraestructura causarán la detención del centro de procesamiento de datos.

La tasa de disponibilidad máxima del centro de procesamiento de datos es 99.671% del tiempo.

Tier II: componentes redundantes

Los centro de procesamiento de datos con componentes redundantes son ligeramente menos susceptibles a interrupciones, tanto planeadas como las no planeadas. Estos centros de procesamiento de datos cuentan con piso falso, UPS y generadores eléctricos, pero están conectados a una sola línea de distribución eléctrica. Su diseño es “lo necesario más uno” (N+1), lo que significa que existe al menos un duplicado de cada componente de la infraestructura. La carga máxima de los sistemas en situaciones críticas es del 100%. El mantenimiento en la línea de distribución eléctrica o en otros componentes de la infraestructura pueden causar una interrupción del procesamiento.

La tasa de disponibilidad máxima es 99.749% del tiempo.

Tier III: mantenimiento concurrente

Las capacidades de un centro de procesamiento de datos de este tipo le permiten realizar cualquier actividad planeada sobre cualquier componente de la infraestructura sin interrupciones en la operación. Actividades planeadas incluyen mantenimiento preventivo y programado, reparaciones o reemplazo de componentes, agregar o eliminar elementos y realizar pruebas de componentes o sistemas, entre otros. Para infraestructuras que utilizan sistemas de enfriamiento por agua significa doble conjunto de tuberías.

Debe existir suficiente capacidad y doble línea de distribución de los componentes, de forma tal que sea posible realizar mantenimiento o pruebas en una línea, mientras que la otra atiende la totalidad de la carga. En este tier, actividades no planeadas como errores de operación o fallas espontáneas en la infraestructura pueden todavía causar una interrupción. La carga máxima en los sistemas en situaciones críticas es de 90%.

Muchos centros de procesamiento de datos tier III son diseñados para poder actualizarse a tier IV, cuando los requerimientos del negocio justifiquen el costo.

La tasa de disponibilidad máxima es 99.982% del tiempo.

Tier IV: tolerante a fallas

Este centro de procesamiento de datos provee capacidad para realizar cualquier actividad planeada sin interrupciones en las cargas críticas, pero además la funcionalidad tolerante a fallas le permite a la infraestructura continuar operando aun ante un evento crítico no planeado. Esto requiere dos líneas de distribución simultáneamente activas, típicamente en una configuración system + system; eléctricamente esto significa dos sistemas de UPS independientes, cada sistema con un nivel de redundancia N+1. La carga máxima de los sistemas en situaciones críticas es de 90% y persiste un nivel de exposición a fallas, por el inicio una alarma de incendio o porque una persona inicie un procedimiento de apagado de emergencia o Emergency Power Off (EPO), los cuales deben existir para cumplir con los códigos de seguridad contra incendios o eléctricos.

La tasa de disponibilidad máxima es 99.995% del tiempo.

Hay que tener en cuenta que para un tier IV se contempla que la única parada que se produce es por la activación de un EPO y esto sólo sucede una vez cada cinco años.

No obstante para la exigencia que demanda un tier IV algunas empresas u organizaciones manifiestan necesitar una disponibilidad de “cinco nueves”, esto significa un 99,999% de disponibilidad. Esto es poco más de cinco minutos anuales sin sistemas.

El estándar TIA 942 y la categorización de tiers se encuentran en pleno auge en América Latina. Esto es bueno porque lleva al replanteo de las necesidades de infraestructura de una manera racional y alineada con las necesidades propias de disponibilidad del negocio en que se encuentran las organizaciones.

Licencia de Creative CommonsSeguridad y Auditoria de un Centro de Procesamiento de Datos by Expresión Binaria is licensed under a Creative Commons Reconocimiento-NoComercial-CompartirIgual 3.0 Unported License


Fuentes consultadas: Wikipedia | Auditoria física de un Centro de Procesamiento de Datos | Auditoria lógica de un Centro de Procesamiento de datos | Estándar TIA-942 | Intypedia

Seguridad y Auditoria de un Centro de Procesamiento de Datos 2.00/5 (40.00%) 1 voto

Tags: , ,

Deje un comentario

Cuanto es 19 + 16 ?
Please leave these two fields as-is:
IMPORTANTE! Necesitas resolver la operación matemática para poder continuar.