viernes, 31 de agosto de 2007

Auditorias, Protocolos de Terminación. Sayonara Baby!.

Todo lo que comienza, termina. Así que para toda acción, tarea, proceso, etc. iniciado dentro de un sistema se deben de aplicar los procesos análogos de terminación, finalización, conclusión, etc. Destacando, que toda la documentación relacionada con ellos es y será requerida en cualquier trabajo de auditoria serio.

Aunque el planteamiento es sencillo, el trabajo y complejidad asociados al mismo no es nada despreciable. En muchos sistemas se trata la terminación de cualquier tarea, como un “apagado” o finalización de la misma sin más procesos asociados, no exisitiendo protolos de terminacion que puedan ser auditados.

Y una de las respuestas más comunes al preguntar sobre el tema a los administradores en un auditoria es un lánguido silencio.

El ámbito de aplicación de los protocolos de terminación dentro de las IT es global y si se analiza detenidamente, el resultado, indica que su aplicación es un elemento imprescindible para la correcta gestión de cualquier proceso emprendió.

Una de las características mas destacables de estos procesos es su globalidad ya que para su aplicación, se debe de proceder a una extensa recopilación de información asi como de la modificación y actualización de cualquier proceso asociado, produciéndose en ocasiones nodos, i-nodos, n-nodos de relación y árboles de trabajo bastante complejos.

Todo esto, es la “teoría”, y si queremos añadir complejidad al asunto, podríamos aplicar reglas de “coste” a los nodos y las reducciones asociadas, pero normalmente estos procesos, acortan el “papeleo” y flujos de trabajos, pero en contra, aporta ilegibilidad a las tareas y procesos a realizar.

Y como toda “teoría” nos aporta una primera aproximación a los requerimientos que necesitaremos para aplicar.

Veamos varios ejemplos prácticos.

-BBDD

Uno de las situaciones mas típicas, dar de baja una base de datos de un entorno de explotación (contabilidad, personal, marketing, etc.). Partiríamos de la creación de una plantilla tipo asociada a la tarea, en la cual recopilaríamos toda la información relacionado con la identificación de la BBDD, luego pasaríamos a la recopilación de los datos asociados a su explotación, aplicaciones asociadas, capas de ejecución, listado de usuarios o grupos de acceso, áreas de almacenamiento (soportes ) y ejecución (unidades de computo, servidores) tipos y sensibilidad de los datos contenidos en la misma (LOPD), servicios y procesos asociados a la ejecución de la misma, aplicaciones de monitorización, seguridad y Backups! Y terminaríamos con las referencias relativas a los soportes de copia y su proceso de extinción de datos (que cintas Backup se utilizan y su proceso de extinción, borrado, destrucción o sobré escritura) y dejamos para el final lo mas importante, la firma de al menos dos responsables en la ejecución de la tarea, uno que seria el técnico, técnicos asignados y otro el responsable del Dep. Asociado.


-Hardware

Seguiríamos el mismo proceso, generación de documentos tipo, identificación del elemento, recopilación de la información operativa, servicios y procesos asociados al elemento, consideraciones relativas a la seguridad del mismo, impacto en el entorno de explotación, documentos y modificaciones operativas a actualizar o modificar , tratamiento y destino final del equipamiento destino y la constancia de los responsables involucrados en el proceso, así como la certificación de la finalización de todas las tareas iniciadas.


-Aplicaciones

Los mismos pasos y protocolos que en el ejemplo de la BBDD.

Para las Cuentas de Red, Correo Electrónico, Puesto de Trabajo lo trataremos en el proximo post, ya que en el tratamiento de estos procesos intervienen una serie de consideraciones jurididas, que deben de ser tomadas en cuenta.

jueves, 30 de agosto de 2007

Disastrer Recovery
Vmware White Papers

Continuando con el artículo anterior, hoy nos toca una pequeña guia de continuidad de negocio con las recomendaciones de VMware sobre Backups, Restore y Disaster Recovery.

Esta en ingles, pero nos muestra de una manera clara, los procedimientos basicos y los planteamientos a utilizar para planificar nuestras operaciones de recuperación de operatividad, (sistemas arriba) ante esas situaciones que nunca ocurren.


http://www.vmware.com/pdf/esx_backup_wp.pdf


El único problema es que la forma de backup que nos muestra es sobre los discos virtuales, asi que solo podremos aplicar estas politicas sobre una parte de nuestro plan de continuidad de negocio. El como hacer para copiar y salvaguardar datos y aplicaciones tendremos que esperar un poquito, haber que se les ocurre. Mientras tanto seguiremos con nuestro querido NetBackup.

miércoles, 29 de agosto de 2007

Backupss Virtuales,
Vmware, R5, NetBakup

Ahora que todo el mundo se ha apuntado a virtualizacion. Se virtualiza todo! empresas, CPDs, servidores, aplicaciones, proyectos, trabajos, nominas, cargos, personal, etc.

Je je!

Nos asalta una pequeña duda, vale! y ahora como hacemos las copias de seguridad nuestros queridos Backuuuups! de los, datos, aplicaciones que hemos virtualizado?.

Una vez que hemos instalado VMware o Micro R2, nos damos cuenta que en las maquinas virtuales no podemos asignares ningún dispositivo de copia o cinta, ya que es un virtual_hardware que no es soportado. Así que, como hacemos nuestras copias de seguridad?

Bueno, nuestros amigos de Spectra (Micro) acaban de publicar una pequeña guía para solucionar en parte este problema. Pero como buena Spectra y siguiendo en su afan por dominar el mundo, solo publican la guía para R2 (no son tan tontos para solucionarles la papeleta de las copias de seguridad a VM o Xen).

Asi que una pequeña recopilación de whitepapers de Spectra con las recomendaciones de continuidad de negocio y backups de seguridad!

Protecting Virtualized Environments with System Center Data Protection Manager 2007

Y una pequeña aclaracion de lo que hace y como lo hace, utilizando

System Center Data Protection Manager 2007

mas conocido como DPM 2007 (cuidado con las analogías).

Pero si tenemos a VMware vitrualizando, como lo hacemos? como seguimos con eso de la continuidad de negocio y la generación de copias de seguridad.

Vale! nuestros amigos de Veritas, disponen de dos juguetes, Backup Exec y NetBackup,

Backup Exec

Es el primero, es el baratito y dentro de la configuración nos aporta una preciosa opción de realizar las copias no a soporte físico, sino a un fichero y este se puede ser apuntado a una unidad de red (así que el servidor de esa unidad dispondrá de las librerías de copia y sera el encargado de realizar las mismas) pros y contras?

Pros.

Pues que bien ya podemos hacer copias!

Contras.

Mucha capa intermedia, script de limpieza y dependencia del perfecto estado y acceso a las unidades de red, por parte de las maquinas virtuales, amen! del enorme gasto de espacio en disco requerido, si tenemos una infraestructura medianamente decente.

En caso de sistemas de virtual arrays, ya nos podemos olvidar de este sistema.

Net BackUp

La version cara y compleja. Pero la que mas posibilidades aporta.

Si utilizamos su versión de media libreri, nos proporciona un servidor central de librerías que es el que se encarga de las copias y los demás clientes, virtuales o físicos se conectan a media y le envían su plan de copia.

Pros.

Se hacen las copias, sin importa el numero de clientes, gestión centralizada, consola de control única o con permisos, completo control de las acciones de backup y restauración, planificación de ventanas de copia según la prioridad de los clientes, etc, etc.

Contras.

La consola es una pesadilla (miles de opciones), problemas de conexión de los clientes al media (conexiones pilladas), mucha licencias, media, clientes, consumo de ancho de banda entre clientes y medias, algun que otro cuelge, etc.

Pero bueno eso es lo que tenemos y lo bueno es que nos permite “salvar” la situación de una manera elegante.

lunes, 27 de agosto de 2007

Políticas de confidencialidad en las IT
Lo que es confidencial y como hacer que lo sea!

Aprovechando que el tema del robo de información esta de moda, gracias a los últimos acontecimientos en la formula 1 entre dos famosas escuderías y ante la recurrencia del “temita” en las cenas veraniegas, sobre “cómo es posible que con tanto dinero en los boxes se pueda robar información (si a los gobiernos les roban planos de armas nucleares, el robo de un plano de un F1, esta chupado!)”. Vamos a tratar una pequeña introducción de cómo esta el tema de la gestión de la confidencialidad dentro de las empresas.

Bueno! Para comenzar, destacamos, que si existe una cosa cierta, es que las empresas no tienen, para nada claro lo que es la gestiona de información confidencial (datos, documentos, etc.) y que se escuchan y aplican políticas de confidencialidad mas cercas a leyendas urbanas (o de Internet), que a una realidad jurídica practica. Pero esto es España!, así que no debemos sorprendernos.

Muchas empresas parten de planteamientos de aplicación de la confidencialidad completamente errónea, ya que confunden la aplicación de la LOPD (en estos momentos de obligado cumplimiento) con un contrato de confidencialidad sobre todos los contenidos y documentos de la empresa (apreciación bastante grave!).

Así, cuando un nuevo empleado entra en una empresa, se le suele hacer firmar uno o dos documentos tipo (normalmente descargados de Internet sin leerlos) . Uno sobre la propia LOPD, si el empleado en cuestión va trabajar con información “sensible” listados de clientes, nominas, afiliaciones, etc y un segundo documento en el cual se autoriza a la propia empresa al tratamiento de los datos confidenciales del propio empleado (la nomina, afiliación sindical, etc.), también destacamos en al algunas caso las empresas ni siquiera se molestan en entregan las copias numeradas y conformadas de aceptación mutua (una copia para la empresa, una para el empleado y en caso de necesidad, una tercera para registrar en el organismo pertinente), incurriendo automáticamente en “mala fe” con los problemas que esto les supone en caso de la necesidad de realizar acciones jurídicas posteriores.

La verdad es que las empresas aplican estos documentos como las aspirinas “que una, vale, para todo” y también presuponen que estos conceptos se aplican a todo el ámbito documental de la empresa.

Bueno, pues esa no es la realidad, esos documentos sirven para lo que sirven y nada mas, son solo para la LOPD.

Para la gestión de la confidencialidad, las empresas deben a aplicar un concepto completamente distinto.

Se parte de definir un documento tipo, más cercano a la cesión de información y colaboración entre empresas con intercambio de tecnologías o conocimientos que al pobre planteamiento anterior.

Un ejemplo Aquí

como se puede apreciar, los acuerdos de confidencialidad que se suelen aplicar, poco tienen que ver con las consideraciones anteriores, ya que no se esta tratando información, sino tecnología y conocimientos y su gestión es completamente distinta.

Una vez descritos los ámbitos de aplicación, las empresas deben de proceder a una gestión correcta y responsable de sus conocimientos y esto se demuestra a través de la creación y aplicaron de protocolos de actuación sobre sus conocimientos, tecnologías y sobre los documentos que los van a contener.

Esto es.

Partiendo de lo más básico, el propio documento, consistiría en definir plantillas documentales tipo, en las cuales se indica el nivel de confidencialidad del contenido del mismo y su tratamiento.

Una vez definido el contenedor de la información, en este caso el documento, se deben definir todos los procesos asociados al mismo.

Muchas organizaciones aplican la políticas generales, definiendo por sistema todos y cada uno de los documentos generados por los Dep. Clave como confidenciales. Este es un planteamiento “cómodo” pero poco efectivo ya que los documentos iniciales, revisiones y correcciones posteriores deben de ser conservados en su totalidad, con lo que la cantidad de documentos a manejar es ingente y se pierde el control sobre los mismos con facilidad, debido a su rapido incremento.

Una segunda aproximación, y es esta la más correcta, parte del desarrollo real de un plan de gestión de seguridad documental, en el cual se definirán los siguientes puntos a cumplir:

-Generación de Plantillas tipo, asociadas a los distintos niveles de confidencialidad las cuales informaran del nivel del documento y su tratamiento.

-Tipo y estado de los documentos, indicando la categorización de los mismos y su estado actual en los procesos asociados.

-Políticas de nivel de acceso por parte del personal, departamentos, así como las acciones que los mismos pueden realizar sobre los procesos relacionados, (modificaciones, revisiones, revocaciones, etc).

-Zonas y protocolos de almacenamiento, unidades de red, almacenes de datos, etc, así como las políticas de seguridad asociadas (log de control de actividad, etc).

-Procesos de gestión y ordenación asignados, inclusión, exclusión de los distintos documentos, dentro de índices de procesos, documentales, etc.

- Procesos de copia de seguridad, integración dentro de los planes de copia de seguridad y salvaguarda, integridad referencial de los soportes a utilizar y de los datos a almacenar.

-Políticas de Acceso físico a los soportes, salvaguarda de los mismos y planes y procesos de contingencia y seguridad asociada a los mismos.

Ósea en pocas palabras, lo que muy pocas empresas utilizan o gestionan. Aunque existen excepciones, ya que todos estos procedimientos se aplican de manera rutinaria dentro las empresas de ámbito bancario o de determinadas corporaciones.

Y como final

Bye, Bye Sun, hola Java!

Un gigante cambia de nombre.

miércoles, 1 de agosto de 2007

Lo que hay que ver! o leer

En este bonito dia de verano, me ha llegado esta bonita notica publicada en el theinquirer.

IBM se Ahorra 250 Millones gracias a Linux

Y como toda noticia en la que se menciona la palabra Linux, parece un poquitin partidista (partidista linux) y como no! Cuanto menos cahonda!.

El ella se habla de la migración a Linux de varios cientos de servidores por parte de IBM y el consiguiente ahorro para sus clientes, la utilización de tecnología de virtualizacion y una apuesta clara por el Open Source (de IBM?) por parte de los chicos de azul. Bueno si se ha trabajo algo con IBM, una de las cosas que te queda claro es que son una multinacional y su función es ganar dinero (el tuyo), así que lo de Linux, ejem! Serán nuestros amigos de Red Hat, en sus versiones Entreprise, en lo referente a la virtualizacion, no creo que utilicen nada liberado (ellos ya tienen su propio software propietario de virtualizacion) y lo que si es una buena noticia, es que se ahorrara energía en los CPDs (ya que las nuevas arquitecturas sobre blade, tienen unos consumos energéticos y térmicos espectaculares, eso si bajo premisa de migracion a sus sistemas de virtualizacion).

Así que el marcador final es, Open Source 0, Linux 0 y Big Green 1.

PD.

No creerse todo lo que se dice o se lee en internet.