Siniestros. Arquitectura Avanzada 2011

Transcripción

1 Siniestros Contingencia Continuidad del negocio BCP DRP Cloud Computing. Virtualización Seguridad Estándares DRaaS RPO RTO Costos Siniestros Arquitectura Avanzada 2011 Natalia Maurer 0

2 INTRODUCCIÓN... 2 SINIESTRO... 2 CONTINGENCIA... 2 PLAN DE CONTINUIDAD DEL NEGOCIO O BCP... 2 PLAN DE RECUPERACIÓN ANTE DESASTRES O DRP... 2 RECUPERACIÓN ANTE DESASTRES O DR... 2 DR EN LA NUBE... 3 VENTAJAS DE HACER DR EN LA NUBE... 3 DESVENTAJAS DE HACER DR EN LA NUBE... 4 SEGURIDAD EN LA NUBE... 4 SAS 70 (STATEMENT ON AUDITING STANDARDS)... 4 SSAE 16 (STATEMENT ON STANDARDS FOR ATTESTATION ENGAGEMENTS)... 5 HIPPA (HEALTH INSURANCE PORTABILITY AND ACCOUNTABILITY ACT)... 5 PCI DSS (PAYMENT CARD INDUSTRY DATA SECURITY STANDARD)... 5 DRAAS (DISASTER RECOVERY AS A SERVICE)... 5 RECOVERY POINT OBJECTIVE (RPO)... 6 RECOVERY TIME OBJECTIVE (RTO)... 6 RENDIMIENTO... 6 CONSISTENCIA... 6 SEPARACIÓN GEOGRÁFICA... 6 PLAN DE DR EN LA NUBE...7 DR TRADICIONAL...7 DR EN LA NUBE...7 ALTERNATIVAS DE DR EN LA NUBE... 8 UN EJEMPLO PRÁCTICO... 8 CONCLUSIÓN... 9 REFERENCIAS

3 Introducción El tema a tratar durante el presente trabajo es siniestros. Empezaremos definiendo algunos términos: Siniestro [RAE] Daño de cualquier importancia que puede ser indemnizado por una compañía aseguradora. [WIKIPEDIA] Se refiere a un accidente o incidente que ha causado graves daños a personas o a la propiedad. Nos ocuparemos de los daños a la continuidad del negocio producidos por una contingencia que inhabilita (o degrada) el centro de cómputos. Contingencia [RAE] posibilidad de que algo suceda o no suceda. Riesgo. Plan de continuidad del negocio o BCP Define las acciones a tomar en caso que una determinada contingencia inhabilite algún área de operaciones o tecnología. El objetivo del plan es permitir la recuperación de las operaciones críticas del negocio. El BCP incluye al plan de recuperación ante desastres o DRP (Disaster Recovery Plan). Plan de recuperación ante desastres o DRP Define las acciones a tomar en caso que una determinada contingencia inhabilite el centro de cómputos. Su objetivo es permitir la recuperación de las operaciones críticas de IT. Es el conjunto de políticas, procedimientos, normas y lineamientos relacionados con la recuperación luego de un desastre natural o inducido por humanos. Recuperación ante desastres o DR Un plan de recuperación ante desastres de IT es crítico para la continuidad del negocio. Si ocurriese un desastre, la supervivencia de la compañía depende de su habilidad para replicar los sistemas de IT y los datos que posee. La recuperación ante desastres desde la perspectiva de IT consiste en asegurarse que los sistemas y los datos pueden recuperarse en caso de una contingencia. Ya sea que un desastre afecte el entorno de producción u ocurra un corte por un período prolongado de tiempo, lo importante es poder recuperarse y tener los sistemas y los datos resguardados y para que vuelvan a estar disponibles. Las alternativas para elegir el DRP que más se ajusta a una empresa dependen de 2 cosas: El RTO (Recovery Time objective): es cuán rápido necesita recuperarse del desastre El presupuesto que tenga la empresa para dedicarle al DRP. Ambas cosas están muy relacionadas. Por ejemplo, si la empresa necesita recuperar sus datos en un período de 7 días, va a ser mucho más barato que si necesita recuperar los datos y la infraestructura en 5 minutos. DR del modo tradicional En una primera instancia, para soportar DR dentro de las instalaciones de la organización debemos: Usar redundancia de los sistemas/datos: por ejemplo usando RAID. Asegurar la provisión constante de energía: sin sobretensiones o picos. 2

4 Proteger a los sistemas de acceso físico no autorizado. Medidas de seguridad para evitar y controlar incendios. Implementar IDS, IPS y otras medidas de seguridad. El próximo nivel en la estrategia organizaciones para DR consiste en: Resguardo de datos usando cintas Resguardo de datos en data centers remotos. Alta disponibilidad de la infraestructura de IT usando una ubicación off-site replicada. Las organizaciones que hacen uso de las estrategias mencionadas, deben incurrir en importantes gastos para configurar el centro de recuperación. También ocurre que estas compañías tienen inconvenientes para prever el crecimiento que van a tener a lo largo del tiempo. DR en la nube En la actualidad, la mayoría de las compañías están analizando varias alternativas para proteger sus datos y duplicar su infraestructura. Una alternativa que salta a la vista es la nube. Los servicios de DR provistos a través de la nube le brindan a la empresa la capacidad y la flexibilidad para hacer resguardos remotos, reducción de costos y alta disponibilidad de los sistemas de IT para permitir la continuidad del negocio. El uso de cloud computing cambia la forma en que se encara la recuperación ante contingencias, bajando el costo al mismo tiempo que reduce el RTO. En la nube los servidores están virtualizados, entonces en lugar de solo resguardar los datos, ahora podemos resguardar el servidor completo off-site. Es sencillo tomar una instantánea del servidor todas las noches, y enviarla off-site. Entonces en este caso estamos hablando de hacer resguardos y recuperarlos en cuestión de horas en lugar de en días. Ventajas de hacer DR en la nube Le permite a la organización enfocar sus inversiones en las actividades del negocio en lugar de usarlas para centros de DR. Permite incrementar la infraestructura, aunque no haya sido previsto durante la planificación del DR. Existes múltiples proveedores de servicios en la nube en múltiples ubicaciones geográficas. Esto permite resguardar en distintas áreas alrededor del mundo. Reduce la necesidad de espacio en data centers, infraestructura IT y recursos de IT. Permite que compañías más pequeñas tengan soluciones de DR que antes solo se encontraban en grandes empresas. Pueden incorporarse recursos a la nube rápidamente con costos que escalan lentamente sin requerir grandes inversiones anticipadas. 3

5 Desventajas de hacer DR en la nube Si la empresa no tiene conexión a internet por interrupciones de servicio, ya sea debido al proveedor o a un DoS distribuido, va a perder su acceso a la nube. Cuestiones de seguridad que hay que tener en cuenta a la hora de decidir qué cosas van a estar en la nube. Es muy importante elegir un proveedor confiable que este alineado con los requisitos de la compañía. Seguridad en la nube Una preocupación común cuando se pasa a la nube es la seguridad en lo que concierne a protección de datos y privacidad, seguridad física y seguridad de las aplicaciones. La mayoría de las empresas tienen un 95% de sus datos no sensibles. La recomendación usual es poner todos los datos no sensibles en la nube y tener un sistema de resguardo distinto para el 5% restante. Es importante asegurarse que el data center que la empresa elija se tome la seguridad en serio. Lo importante es saber en qué data center y en qué servidor se están almacenando los datos. También se puede verificar que estén aplicando las medidas de seguridad necesarias: Ver si son auditados en SSAE 16 o SAS 70 Ver si tienen clientes que son certificados HIPPA o PCI. Si ofrecen firewalls, antivirus y detección de intrusos. SAS 70 (Statement on Auditing Standards) SAS 70 fue el estándar original internacionalmente reconocido para el reporte de los procesos operativos y prácticas de un data center. Hay 2 tipos de reportes SAS 70. El tipo I reporta los controles operacionales. El 4

6 tipo II es más minucioso y reporta qué tan efectivos son dichos controles en un período específico de tiempo (6 meses). SSAE 16 (Statement on Standards for Attestation Engagements) En abril del 2010, el AICPA (American Institute of Certified Public Accountants) anunció el retiro de SAS 70 para ser reemplazado por SSAE 16 y estándares refinados. SSAE 16 es efectivo desde el 11 de junio del 2011.También tiene 2 tipos de informes, el primero mira el diseño y el segundo analiza la efectividad. HIPPA (Health Insurance Portability and Accountability Act) Standard para proteger información sensible de pacientes. Toda compañía que maneja registros de pacientes debe asegurar que se están implementando y siguiendo las medidas se seguridad para proteger los procesos, las redes y el acceso físico a los datos. PCI DSS (Payment Card Industry Data Security Standard) Standard requerido por cualquier compañía que acepta pagos con tarjetas de crédito. La intención es proteger los datos del dueño de la tarjeta construyendo una red segura, protegiendo los datos almacenados, controlando el acceso y manteniendo políticas de seguridad de datos. DRaaS (Disaster Recovery as a Service) Las compañías se están dando cuenta que muchas aplicaciones pueden ponerse a disposición como servicios y DR no es la excepción. Esto da como resultado el modelo de Disaster Recovery as a Service (DRaas) o DR bajo demanda. DRaaS está adquiriendo popularidad entre las empresas, principalmente por su modelo de precios pay as you use (solo luego del desastre se paga por un servicio más poderoso y más caro para correr las aplicaciones) que permite bajar costos y usar plataformas virtuales automatizadas que pueden reducir tiempo de recuperación luego de una falla. Las plataformas virtuales automatizadas implican que en una primera instancia solo se 5

7 sincronizan a la nube una pequeña porción de los datos, pero al detectar un desastre se sincronizan todos los recursos adicionales. Requisitos clave de un servicio de DR Los requerimientos pueden estar basados en decisiones del negocio, como el costo monetario del tiempo de inactividad de los sistemas o la pérdida de datos, o en el rendimiento y la precisión de las aplicaciones. Recovery Point Objective (RPO) Tolerancia de pérdida de datos. En un sistema de DR representa el punto en el tiempo del resguardo de datos más reciente previo al fallo. Recovery Time Objective (RTO) Tiempo de inactividad aceptado del sistema. Incluye el tiempo para detectar el fallo, preparar los servidores que sean necesarios en el sitio alternativo, inicializar la aplicación fallida y realizar la reconfiguración necesaria de la red (para re-rutear los pedidos). Tener un RTO muy bajo permite la continuidad del negocio, permitiendo que una aplicación aparente haber permanecido operativa a pesar del desastre. Rendimiento Impacto en la operación normal luego de la recuperación. Para que un servicio de DR sea útil, debería tener un impacto mínimo en la performance de la aplicación. Consistencia Precisión en los datos de la aplicación y las salidas. El servicio de DR debe asegurar que luego de que ocurre un fallo, la aplicación puede recuperarse en un estado consistente. Separación geográfica El sitio de DR nunca debería ser impactado por el mismo desastre que el primario. Ambos sitios deberían estar geográficamente separados para asegurar que un único desastre no impacte a ambos. 6

8 El nivel de protección de datos y la velocidad de recuperación dependen mecanismo de backup utilizado y la los recursos disponibles en el sitio alternativo. En general, los servicios de DR caen bajo una de las siguientes categorías: Hot Backup Site: proporciona un conjunto de servidores espejados que están en stand-by disponibles para correr las aplicaciones cuando ocurre el desastre, proporcionando RTO y RPO mínimos. Suelen usar replicación asincrónica para prevenir las pérdidas de datos ocasionadas por el desastre. Warm Backup Site: busca mantener el sitio alternativo al día usando replicación sincrónica o asincrónica dependiendo del RPO necesario. También existen servidores en stand-by disponibles en caso de un desastre, pero se mantienen en un estado warm, lo cual significa que puede llevar un tiempo corto que estén online. Cold Backup site: los datos suelen replicarse periódicamente al sitio alternativo, lo cual conlleva un RPO más elevado. Los servidores en el sitio alternativo no están inmediatamente disponibles, sino que pueden pasar horas o días hasta que el hardware está disponible luego del desastre. O sea que el RTO también es más elevado. Es más difícil soportar la continuidad del negocio con este tipo de servicio, pero son una alternativa de mucho menor costo para aplicaciones que no requieren una alta disponibilidad. Plan de DR en la nube El proceso de elaborar un plan de DR empieza con la identificación y priorización de las aplicaciones, los servicios y los datos. Debe determinarse para cada uno el tiempo de inactividad aceptado (downtime) antes de que produzca un impacto significativo en el negocio. Luego la prioridad y el RTO van a determinar la alternativa de DR. Una combinación de costo y objetivos de recuperación son los que marcan distintos niveles de recuperación ante desastres. DR Tradicional Un sitio secundario de DR significa invertir en espacio adicional de data center, conectividad y servidores. También conlleva costos operativos adicionales (energía, HVAC, mantenimiento, personal). Un sitio físico de DR opera solo durante la sincronización de datos o en caso de un desastre. El tiempo que toma ponerlo operativo es mayor que en el caso de DR en la nube, resultando en una pérdida de datos. Si no hay conectividad disponible con el sitio secundario, se pueden llegar a requerir operaciones manuales para iniciar las operaciones en el sitio de DR. DR en la nube Proporciona instantáneas de máquinas virtuales de servidores físicos o virtuales del data center primario. La empresa paga por almacenar las instantáneas en un estado suspendido y la replicación de datos desde el sitio primario y el secundario. Solo paga la IaaS en caso de un desastre para poner online el substituto del sitio primario. El sitio de DR en la nube puede tenerse online en segundos o minutos. Esto se traduce en una pérdida de datos de ese intervalo de tiempo solamente. El sitio de DR en la nube puede dispararse usando una notebook con acceso a internet desde cualquier lado. 7

9 Alternativas de DR en la nube Aplicaciones y DR administrados por el proveedor Una alternativa cada vez más popular es poner tanto el sitio primario como el sitio de DR en la nube, y tener ambos manejados por el proveedor. Esto permite que las empresas tengan todos los beneficios de cloud computing. Se elimina de esta forma la necesidad infraestructura dentro de la compañía. En este caso, la elección del proveedor del servicio y la negociación de los acuerdos de nivel de servicio (SLA) son de vital importancia. Al darle el control al proveedor del servicio, la empresa tiene que estar absolutamente segura de que el proveedor es capaz de brindar servicio ininterrumpido dentro del SLA definido, tanto para el sitio primario como para el de DR. Resguardo y recuperación desde la nube En este caso, las aplicaciones y los datos permanecen dentro de la organización. Los datos son resguardados en la nube y recuperados a hardware de la empresa en caso de un desastre. En otras palabras, el resguardo en la nube se vuelve un substituto del resguardo remoto en cintas. Resguardo y recuperación en la nube Los datos no se recuperan a la infraestructura propia de la empresa, sino a máquinas virtuales en la nube. Esto requiere tanto almacenamiento como recursos en la nube. La recuperación puede realizarse cuando ocurre el desastre o de forma continua (pre-staging). Hacerlo continuamente permite mantener las virtuales relativamente al día a través de resguardos programados, lo cual es de utilidad si se tienen RTOs bajos. Replicación a máquinas virtuales en la nube Para aplicaciones que requieren RTO y RPO agresivos, la replicación es la opción a elegir. La replicación a máquinas virtuales puede usarse para proteger tanto las instancias de producción locales de la empresa como las de la nube. La replicación sirve tanto para cloud-vm-to-cloud-vm como para on-premises-to-cloud-vm. Para que el mecanismo funcione de forma eficiente, sería ideal llevar a cabo una optimización WAN entre la empresa y la nube. También es importante probar el plan de DR periódicamente para asegurarse que funcione correctamente y que se cumplen los requisitos de RTO y RPO. Un ejemplo práctico Tomemos como ejemplo Online Tech (una empresa estadounidense que maneja data centers) y su manejo de recuperación ante desastres. Online Tech movió toda su infraestructura IT (23 servidores) a una nube privada propia a fines del Tomaron sus 23 servidores, los convirtieron en servidores virtuales y en la actualidad corren sus 23 servidores virtuales en 2 servidores físicos y un entorno SAN (storage área network). En lo que respecta a la recuperación ante desastres, lo que hacen es resguardar los 23 servidores virtuales a un data center secundario a 90 kilómetros de distancia y también tienen un servidor separado (un warm site) para levantar esos servidores en caso de que algo le ocurra a su infraestructura primaria. 8

10 La experiencia de Online Tech fue muy positiva. Ellos mencionan las siguientes ventajas: Su trabajo es mucho más sencillo desde que pasaron a la nube, tanto en el despliegue como en sus resguardos diarios. Prueban su DRP cada seis meses y les lleva solamente 4 horas. Su RTO bajó dramáticamente. Bajaron sus costos. Conclusión DRaaS es una solución emergente para organizaciones que quieren controlar su propia infraestructura pero no mantener sistemas de DR ellos mismos. Con DRaaS una organización no construye directamente un sitio para contingencias, sino que confía en un proveedor para que lo haga. Las ventajas que proporciona la nube en cuanto a elasticidad y reducción de costos son beneficios significativos en un escenario de DR. Sin embargo, muchas de las complejidades siguen existiendo y es esencial llevar a cabo el proceso con cuidado y responsabilidad para asegurarse que el plan de contingencia va a funcionar y proveer el nivel de servicio requerido. Referencias