Tres aspectos donde una correcta estructura de cableado previene desastres

Categorías relacionadas:
Destacado, Tendencias

desastres-naturales-empresas

El rol de las redes LAN empresariales ha ido evolucionando tanto que hoy la gran mayoría de los sistemas dentro de los edificios están conectados a la red. Además, la red ha pasado de ser solo una infraestructura de comunicación para los diversos dispositivos conectados, a tener un impacto directo en la seguridad personal y publica, ya sea ayudando en la prevención de crisis o permitiendo tomar acciones de manera más rápida y efectiva en momentos críticos.

Leer más...



A un año del sismo, el sector de la construcción debe fortalecerse con el uso de la TI

Categorías relacionadas:
Administración, Administración de proyectos, Administración del riesgo, Destacado, Lo más reciente, Lo más reciente, Tendencias, Tendencias

temblor-2017

Producir más y mejor con los mismos recursos, generando mayor valor para el negocio, que además brinde seguridad y el apoyo necesario, convierte a la tecnología en un papel fundamental en  la visión de países como México, que debería considerar debido a su posición geográfica y sísmica en la que se encuentra el uso de la misma.

Leer más...



DevOps: Cómo dominar la recuperación en caso de desastre

Categorías relacionadas:
Administración, Lo más reciente, Lo más reciente, Principal, Seguridad, Tendencias

De acuerdo a una encuesta del 2015 de la IT Revolution Press, en conjunto con Puppet Labs, las organizaciones que usan DevOps despliegan código 30 veces más rápido que otras, realizando despliegues múltiples cada día. Además, las fallas en los cambios se reducen con DevOps, y los servicios son restaurados hasta 168 veces más rápido de lo que son en organizaciones sin DevOps.

DevOps: Fallar más rápido y recuperarse más rápido

Concentrémonos en aquellos últimos dos puntos por un momento. Una cosa es clara: Adoptar DevOps también tiene sus recompensas desde el punto de la recuperación en caso de desastres, porque las herramientas y procedimientos que usted usa para mover las aplicaciones desde su desarrollo hasta las pruebas, a producción y de vuelta a desarrollo otra vez, también pueden ser aplicados a fallar y recuperarse de desastres e interrupciones de servicio. Las mismas herramientas que automatizan por completo al ciclo de vida DevOps, también pueden ayudarle a aprovechar al máximo el uso de los recursos que ya tiene para efectos de recuperación.

De hecho, hay muchas herramientas de código abierto que ayudan con esta automatización, como Chef y Puppet, que crean, lanzan y despliegan instancias de máquinas virtuales de manera automática y las configuran apropiadamente. Hasta funcionan a través de límites de seguridad, desplegándose en su laptop privada, en su centro de datos o incluso en la nube pública -Amazon Web Services y Microsoft Azure son dos de los principales proveedores de nube pública que respaldan a Chef y a Puppet. Al usar estas herramientas, puede no solo automatizar el despliegue de código nuevo que sus desarrolladores escriben en copias exactas del ambiente de sus máquinas de desarrollo y configuración; también orquestar y lanzar un ambiente de backup en la nube en cuestión de minutos.

Si combina a Puppet y Chef con una herramienta como Oracle Ravello (si su nube pública es Amazon Web Services o Google) en sus despliegues virtuales VMware y KVM, literalmente puede anidar hipervisores para poder ejecutar sus ambientes virtuales en la nube pública al ser desplegados –con networking, addressing y más- de manera automática y sin cambios. Estas son herramientas poderosas tanto desde la perspectiva de DevOps como desde la perspectiva de la recuperación en caso de desastres. Usted puede construir, probar y desplegar software rápidamente, así como mitigar fallas, proporcionar un failover robusto y recuperar soluciones usando las mismas herramientas. Un despliegue continuo se vuelve un failover continuo y una recuperación continua.

El principio más importante de DevOps es que los desarrolladores deberían estar escribiendo códigos y probando sus aplicaciones en una copia del ambiente de producción en donde se ejecutará su código. Usualmente, esto casi se logra usando soluciones de máquinas virtuales y contenedores como Docker operando en laptops o desktops individuales. Esto es mucho mejor, por supuesto, que solo escribir códigos a ciegas en Xcode o Visual Studio, y después enviar paquetes a los administradores de sistemas para que los desplieguen, pero dije ‘casi’ en la oración previa porque incluso este tipo de virtualización no simula en su totalidad las limitaciones de capacidad de un ambiente de producción del mundo real. Es difícil probar una carga real en contraposición a un microservicio en un contenedor operando en una Apple MacBook Air, por ejemplo. Pero la prueba de cargas podría llevarse a cabo de una manera más realista y accionable en contraposición con un servicio de despliegue completo de Azure Stack, por ejemplo.

Los ambientes de recuperación en caso de desastres como espacios potenciales de trabajo en DevOps

Algunas compañías encuentran que, a medida que adoptan DevOps a un nivel más profundo, sus desarrolladores solicitan con mayor frecuencia acceso a los ambientes de repuesto de recuperación en caso de desastres para mitigar esa restricción de “laptop o desktop”. Generalmente, las organizaciones de tamaño mediano y grande tienen inversiones significativas en infraestructuras que son más copias exactas de los ambientes en los que están operando las cargas de trabajo de producción críticas, y que se encuentran en standby en caso de que esas cargas de trabajo necesiten ser portadas en caso de una disrupción o desastre en el servicio.

Hoy en día, permanecen más que nada inmóviles, excepto por unos cuantos ejercicios de recuperación cada año. Pero piénselo: Esto implica bastante capacidad sin utilizar, esperando por un evento que podría pasar solo por unas pocas horas al año. ¿Existe alguna forma de aprovechar las tecnologías de virtualización, el storage area networking y el networking definido por software para que la capacidad de repuesto en caliente de la recuperación en caso de desastres pueda ser usada como “espacio de trabajo” DevOps para probar y planear mientras que permanecen disponibles para sus propósitos originales -aceptar cargas de trabajo tras un failover?

La respuesta es sí. Los hipervisores y las máquinas virtuales pueden cambiar en número en cuestión de segundos, y las redes definidas por software pueden ser redireccionadas e impulsadas a conexiones y puntos finales diferentes a través de scripts de manera automatizada. De hecho, en la mayoría de casos, los datos ya se encuentran accesibles para el ambiente, así que la aplicación regular y las pruebas de operación pueden, de hecho, funcionar con datos reales sin tiempos largos de copia. ¿Podría pedir un mejor desempeño de un ambiente de prueba en el mundo real que, esencialmente, trabaja en una copia exacta de su infraestructura de producción?

En el caso de necesitar un failover, puede hacer que su sistema de monitoreo dispare esos scripts, cambie los puntos finales de almacenamiento y apague las máquinas virtuales -y después tendrá de vuelta a sus repuestos en caliente. Luego de que concluya el “desastre”comilla”, puede restaurar manualmente los servicios revirtiendo todos los cambios que realizaron esos scripts automatizados. PowerShell es una gran manera de hacer esto en ambientes Windows, Hyper-V y VMware, y los scripts Bash son adecuados para Xen y también otros hipervisores. Por supuesto, Puppet, Chef y Ravello también pueden colaborar con este tipo de orquestación.

La idea aquí es conseguir que alguna capacidad no utilizada haga algo útil sin que olvide, en primer lugar, el propósito de su existencia por completo. Los desarrolladores necesitan acceso para realizar pruebas y encontrar problemas de desempeño en las capacidades y cargas más altas de lo que sus máquinas de desarrollo solas pueden soportar. Tener una infraestructura stanby hot sin hacer nada más que ser hot y estar en standy es quizás el extremo opuesto a la adopción de DevOps; con reimaginar este tipo de aplicación, podría tenerlo todo.

Preguntas por hacer

Cuando comience a pensar más respecto a la recuperación continua en caso de desastres, aquí hay unos puntos que debe considerar con su equipo.

¿Cómo hacemos visibles nuestros procedimientos de recuperación en caso de desastres? ¿A quién le pertenece el checklist de procedimientos a seguir? ¿Quién dispara los scripts o quién es responsable de la automatización? ¿Cómo podemos simular la falla de una sola aplicación, una carga de trabajo completa y de la propia infraestructura? ¿Qué tipo de situaciones causarían fallas en cada uno de esos elementos clave?

¿Qué fortalezas naturales puede enfatizar un empleado en base a la recuperación en caso de desastres? Aunque DevOps tiende a integrar los roles de los desarrolladores y las personas de operaciones, naturalmente va a haber empleados con experiencias y tendencias más fuertes orientadas a operaciones, a los que se les debería otorgar el poder de lidiar con la responsabilidad que requiere un failover. Por el lado de los desarrolladores, los programadores deberían ser responsables si es que su código generó un evento de failover, y aquellos programadores que se inclinan a ser superiores en la corrección de fallas podrían asumir más responsabilidad en esta situación.

¿Cómo puedo utilizar mejor los sitios de recuperación en caso de desastres e infraestructura existente por los que ya pagué? ¿Ese ambiente está instalado para construir y demoler la virtualización de manera sencilla? Y si no lo está, ¿qué necesito hacer para llegar a ese estado?

-Jonathan Hassell, CIO (EE.UU.)

 

Leer más...



Ciberdelincuencia aprovecha desastres naturales para lanzar ataques

Categorías relacionadas:
Cómo hacerlo, Continuidad, Del día, Lo más reciente, Lo más reciente, Mejores prácticas, Seguridad, Seguridad, Tendencias, Tendencias

Cada año los desastres relacionados con riesgos meteorológicos, hidrológicos y climáticos no solo han provocado una pérdida importante de vidas humanas y  de cosas materiales, sino la delincuencia organizada está aprovechando este tipo de situaciones para lanzar ataques cibernéticos con la finalidad de causar descontrol o pánico entre la población e incluso robar información confidencial.

En abril de 2013 piratas informáticos utilizaron el Twitter de la agencia de noticias Associated Press y enviaron un mensaje que decía que las explosiones a la Casa Blanca habían lesionado al presidente Barack Obama. Inmediatamente, el Índice Dow Jones cayó más de 100 puntos antes de recuperarse rápidamente. Otro escenario, durante los disturbios en Ferguson, Missouri, en 2014, un ataque DDoS fue lanzado al sitio web y correo electrónico del departamento de policía. 

Kevin Flynn,  director de Marketing de Productos de Blue Coat Systems, opinó que hoy en día, con las infraestructuras físicas y digitales cada vez más conectadas, los efectos de los desastres naturales pueden persistir mucho más allá del daño físico. “Las agencias gubernamentales también deben contar con planes de seguridad para emergencias naturales como terremotos, incendios o huracanes”.

Blue Coat Systems recomendó a las organizaciones y agencias gubernamentales estos cuatro pasos que les permitirán preparase de ataques cibernéticos que pueden presentarse durante una emergencia física.  Con esto asegurará que los recursos públicos y privados no se conviertan en víctimas de cyber-looting, y que el público en general no esté en peligro.

1) Desarrollar una base segura. Herramientas de análisis de seguridad permiten a los gerentes de TI tener una completa visibilidad de todo el tráfico de la red.

2) Definir la  seguridad “para la nube” y “en la  nube”. Durante una emergencia, los edificios pueden ser dañados y los caminos intransitables, así que mantener a los empleados fuera de la oficina y tener servicios cloud son una alternativa clave.

3) Establecer políticas para el acceso web y administración de ancho de banda. Priorizar el acceso a la red se convierte crítico en situaciones de emergencia; el ancho de banda puede ser estrecho. Es importante dar prioridad a las aplicaciones tales como VoIP y caché de información crítica, como las comunicaciones oficiales y videos para verlos desde una memoria caché local.

4) Proteja sus páginas web públicas y medios sociales.  El público en general busca a los organismos gubernamentales para obtener información durante y después de una emergencia. Será fundamental resguardar los recursos de información pública del organismo, firewalls de aplicación Web pueden proteger el sitio web de ataques comunes, el control de entrada / salida y el acceso, así como detectar los patrones de tráfico que no conoce. Facebook y Twitter también pueden ser utilizados para promover información maliciosa.

Leer más...



Diez consejos para evitar los desastres dentro del Centro de Datos

Categorías relacionadas:
Centros de datos, Continuidad, Destacado, Infraestructura, Lo más reciente, Lo más reciente, Protección, Seguridad, Seguridad, Servidores, Tips

Las empresas pueden enfrentar serios desastres en sus centros de datos. Y con el fin de prevenirlos, Andrew Oldfield, director de Mercados Emergentes de Panduit, ofrece diez tips para prevenirlos.

  1. Recuperación de desastres: A menudo, los centros de datos no pueden enfrentar un desastre, y esto es debido a la falta de evaluaciones y pruebas que deben realizarse continuamente. Debido a que los centros de datos son escenarios en rápido cambio, no reflejan necesariamente la necesidad de enfrentar una recuperación ante desastres. Es por ello que los sistemas deben estar en continua revisión para que coincida con las necesidades del negocio actual.

VER MÁS SOBRE ESTA NOTA

Leer más...