Mejora la seguridad de tu ESXi sustituyendo los certificados autofirmados
Por defecto, VMware viene instalado con una serie de certificados autofirmados (no emitidos por una autoridad certificadora) para establecer conexiones seguras entre los clientes y los servidores.
Estos certificados pueden ser seguros si son utilizados en una red privada. Pero si son utilizados para conectarse a través de Internet (por ejemplo si nos conectamos a nuestra infraestructura de virtualización con un cliente vSphere), es más seguro utilizar un certificado emitido por una autoridad de certificación (CA). En este caso, durante el proceso de conexión, la CA certifica que el certificado utilizado es auténtico.
Tanto los certificados autofirmados como los firmados por una CA aseguran que los datos viajan encriptados, pero los usuarios no están seguros de que realmente se están conectando a tu servidor vSphere.
Cómo reemplazar los certificados autofirmados
En primer lugar emitiremos una solicitud que enviaremos a la autoridad de certificación que elijamos (por ejemplo Thawte, Verisign, GeoTrust, etc.). Durante la solicitud generaremos un fichero de clave privada (.key). La CA nos enviará la clave pública (.crt) que será enviada al cliente cuando se inicie la conexión con nuestra infraestructura de virtualización.
Ambos ficheros (.key y .crt) deben ser copiados en nuestro host ESXi. Para realizar la copia de dichos ficheros en el host deberemos utilizar el interfaz vSphere CLI (vCLI) que puede ser descargado de forma gratuita desde la web de VMware.
Una vez descargado e instalado vCLI en nuestro ordenador, abriremos una consola MS-DOS (cmd) de Windows y nos colocaremos en la carpeta de instalación mediante el comando cd (normalmente C:\Archivos de Programa\VMware\VMware vSphere CLI\bin).
El siguiente paso es ejecutar una serie de comandos para copiar los ficheros .key y .crt a nuestro host ESXi (los ficheros deben estar alojados en el directorio de instalación de vCLI):
vifs --server youresxiserver.example.com --put yourkey.key /host/ssl_key
vifs --server youresxiserver.example.com --put yourkey.crt /host/ssl_cert
Para finalizar reiniciaremos el interfaz de gestión. Nos logueamos por SSH en nuestro host ESXi y ejecutamos los siguientes comandos (nos tenemos que asegurar antes de que no está configurada la opción de arranque/parada automática de máquinas virtuales ya que se pueden reiniciar automáticamente nuestras máquinas virtuales):
service mgmt-vmware restart
service vmware-vpxa restart
Tipos de proveedores PaaS ¿Qué proveedor PaaS elijo?
El modelo cloud de Plataforma como servicio (PaaS) permite a los desarrolladores de aplicaciones implementar su código utilizando su framework de desarrollo preferido (stack) sin tener que provisionar máquinas virtuales o administrar sistemas operativos. De este modo se reducen posibles problemas derivados de la administración.
Podemos diferenciar tres tipos de proveedores Pass:
- Aquellos que dan servicio para un único lenguaje de programación.
- Plataformas multi-lenguaje.
- PaaS híbrido que utiliza varias nubes para implementar y desplegar las aplicaciones.
Por lo tanto, ¿qué proveedor cloud PaaS debería elegir?
Lenguaje de programación específico
Hace unos años, cuando comenzaron a surgir proveedore cloud PaaS, era muy habitual que la mayoría de éstos sólo dieran servicio para un único lenguaje de programación. Por ejemplo proveedores de plataformas Java, Ruby o Python como PiCloud.com.
Si únicamente trabajas con único lenguaje de programación, este tipo de proveedores puede ser adecuado. La principal ventaja es que ofrecen soporte especializado en el lenguaje de programación que prestan.
Multi-lenguaje
La tendencia actual es trabajar con un mix de plataformas cloud de programación. A mayor número de lenguajes disponibles, mayor flexibilidad para el desarrollador. Pero podemos no encontrar el mismo nivel de personalización basado en el lenguaje (por ejemplo librerías para poder distribuir código a través de servidores cloud).
En este grupo de proveedores nos podemos encontrar con Cloud Foundry o DotCloud. Por ejemplo, DotCloud permite utilizar como motor de base de datos a Postgres, MySQL y MongoDB. De este modo, el desarrollador puede trabajor con múltiples bases de datos sin tener que instalar, administrar o mantenerlas.
PaaS Híbrido
Un proveedor PaaS híbrido permite a los usuarios administrar cargas de trabajo de sus aplicaciones, como si fuera una única plataforma PaaS, en un proveedor cloud externo y/o en su propia infraestructura de cloud privada. Un ejemplo de proveedor PaaS híbrido es CloudBees AnyCloud.
Un caso de uso de un PaaS híbrido puede ser un entorno en el que tengamos una base de datos Oracle que no puede ser replicada en la nube. Por lo tanto, podemos tener la parte de aplicativo corriendo en un proveedor PaaS externo que accede a nuestra base de datos Oracle.
La principal desventaja de este modelo es que es necesaria la configuración y mantenimiento de la capa de abstracción y de nuestra infraestructura IT.
OpenStack, ¿la mejor elección para construir arquitecturas IaaS?
En un artículo anterior hablábamos sobre la posible salida de Citrix del proyecto OpenStack tras abrir el código de su plataforma IaaS CloudStack. La cuestión ahora es si OpenStack corre el riesgo, al igual que otras tecnologías o proyectos, de haber sido sobrepromocionado y no cumplir todas las expectativas que se esperaban de él.
OpenStack fue un proyecto inicialmente desarrollado por NASA y Rackspace. En la actualidad cuenta con más de 150 empresas y organizaciones participando del proyecto y se ha convertido en la herramienta de software más popular para crear entornos IaaS. Aún así, como plataforma cloud comercial, se encuentra todavía por detrás de Amazon Elastic Cloud Compute (EC2) en número de usuarios.
La combinación de centrarse únicamente en ser una plataforma IaaS (que permite asignación de recursos, registro de imágenes de máquinas y almacenamiento de datos), amplio soporte en la industria y la fuerte presencia de competidores hacen a OpenStack fuerte y débil a la vez:
- Si los proveedores cloud se centran únicamente en ofrecer servicios de tipo IaaS bajo plataforma OpenStack, están utilizando una tecnología utilizada por muchos competidores de servicios cloud. No hay modo de diferenciarese en servicio, únicamente en precio o características similares.
- A diferencia de otros sistemas IaaS como Eucalyptus o Nebula, la arquitectura OpenStack no se ha centrado en la compatibilidad con EC2. La API de OpenStack se está moviendo del modelo EC2, pero la comunidad de OpenStack promete mantener la compatibilidad con EC2 para aplicaciones antiguas. Por lo tanto, es posible mantener aplicaciones en OpenStack que se ejecuten en EC2 y viceversa, pero también es posible construir aplicaciones basadas en OpenStack que no sean compatibles con EC2, incluso por accidente.
- Existen diferencias persistentes entre las plataformas EC2 y OpenStack en términos de gestión de imágenes y almacenamiento. Esto significa que puede ser más complicado dar soporte a clientes que utilicen nubes OpenStack y EC2. Los proveedores cloud que adopten OpenStack no pueden esperar que la migración de aplicaciones a EC2 se haga sin realizar cambios en las aplicaciones o en sus propios entornos.
- DevOps (integración entre el desarrollo de aplicaciones cloud y el aprovisionamiento de recursos cloud) en OpenStack es incompleto y fragmentado. Por lo tanto, es posible que aplicaciones PaaS o SaaS no puedan ser implementadas fácilmente bajo una arquitectura OpenStack.
Sería injusto decir que todas estos problemas son únicos de OpenStack. De hecho, la mayoría de estos problemas están relacionados con el propio modelo IaaS. Pero deberemos tener en cuenta todos los posibles problemas asociados a OpenStack antes de decidir si lo adoptamos para construir nuestra plataforma cloud.
Del modelo P2V a V2C. ¿Qué debemos tener en cuenta si nos movemos a la nube?
Antes de la explosión de servicios en la nube, y con las tecnologías de virtualización maduras, las empresas se preocupaban de cómo migrar sus servidores físicos a plataformas de virtualización. A este modelo lo conocemos como physical-to-virtual (P2V).
En P2V los responsables IT se preocupan de qué servidores físicos se adaptan mejor a un entorno de virtualización. Existen herramientas que permiten automatizar el proceso de virtualización y, salvo alguna excepción, la mayoría de servidores físicos pueden ser virtualizados.
En la actualidad, con cada vez más proveedores cloud en el mercado, el modelo ha cambiado a ser virtual-to-cloud (V2C). De igual modo que en P2V, no todas las máquinas virtuales (VM) se adaptan a un entorno cloud. En este sentido, los responsables IT deberían considerar varios aspectos:
Costes de transferencia
El modelo cloud computing, basado en capacidades ilimitadas, reemplaza la relación entre hardware y costes por otro basado en el consumo de recursos (CPU, red, memoria, almacenamiento, etc.). Este modelo permite a las empresas conseguir grandes ahorros de costes.
Antes de iniciar un proceso V2C, deberemos prestar atención a cuantos recursos utilizan nuestras máquinas virtuales (prácticamente todas las plataformas de virtualización nos permiten obtener métricas). De este modo, podremos calcular nuestros costes y prevenir sorpresas una vez que nuestra máquina virtual haya sido migrada a la nube.
Monitorización y verificación
Antes de mover tus máquinas virtuales a un proveedor cloud, planifica como vas a monitorizarlas. De este modo podremos asegurarnos que nuestro proveedor se ajusta a nuestras expectativas.
Herramientas de migración
Mientras que existen muchas herramientas en el mercado para realizar migraciones tipo P2V, existen pocas para realizar migraciones V2C.
En la actualidad existen soluciones (como Racemi, AppZero y Citrix NetScaler), pero éstas son dependientes de una plataforma en concreto y tienden a ser unidireccionales. Es decir, podemos mover máquinas virtuales a la nube pero no en sentido contrario. Es posible que tengamos que cambiar de proveedor o nuestras necesidades requieran de traer las máquinas virtuales de vuelta a nuestro data center.
Conexión entre proveedor y cliente
El modelo cloud falla cuanta la capacidad de red entre el proveedor y nuestra red no se ajusta a nuestra demanda. Por ejemplo, podemos tener un servicio de Exchange en la nube y tener un rendimiento muy bajo si la red entre nuestro Outlook y el servidor no es capaz de soportar toda la demanda de nuestros usuarios.
Por lo tanto, los responsables IT deberán establecer sistemas de monitorización y medida del uso de red para poder vigilar el estado y adelantarse a posibles cambios en la demanda.
5 preguntas a tener en cuenta a la hora de contratar servicios cloud
A estas alturas el término cloud computing es conocido y también los beneficios que puede aportar a las empresas. Pero, ¿los servicios cloud se adaptan a nuestras necesidades? En el día de hoy os presentamos cinco preguntas elaboradas por Symantec que hay que tener en cuenta a la hora de decidirse a contratar servicios cloud.
1.- ¿Encuentras dificultades a la hora de realizar el presupuesto en nuevas tecnologías?
Las pequeñas empresas pueden lograr una disminución significativa en el coste de propiedad (TCO) de recursos IT si adoptan servicios cloud. Gracias a los servicios en la nube, no es necesario adquirir licencias o servidores físicos. Asimismo, costes relacionados con el mantenimiento de los servidores disminuyen prácticamente a 0 ya que es el proveedor de servicios quien los soporta. A estos costes le tendríamos que añadir los asociados con el espacio necesario para alojar servidores y la electricidad consumida por dichos servidores.
2.- ¿Encuentras dificultades a la hora de administrar tu infraestructura de red y ordenadores?
Es bastante común que las pequeñas empresas tengan en un único servidor alojado su servicio de e-mail, página web comporativa, servidor de archivos, programas de facturación o gestión, etc. Además es probable que el servidor sea administrado por un responsable IT con demasiado trabajo o, en ocasiones, con escasos conocimientos. Podemos comparar esta situación con un servicio suministrado a través de Internet, alojado en un CPD con el último equipamiento y administrado por expertos IT.
Uno de los beneficios de una infraestructura cloud computing es que los ordenadores de los clientes requieren menos software instalado, evitando posibles problemas relacionados con la administración o actualizaciones.
3.- ¿Tienes dificultades a la hora de estar actualizado en lo que se refiere a tendencias como movilidad o implementando cambios en tu infraestructura?
Si contratas un servicio cloud, su infraestructura es más flexible y capaz de responder a cambios en lo que se refiere a hardware, software, seguridad o mantenimiento. En la nube, la norma es una adopción del cambio más rápida.
Adicionalmente, adoptar la movilidad en tus empleados es más sencillo cuando las aplicaciones y recursos de la empresa están alojados en la nube. Tus usuarios simplemente se conectan a través de un navegador web desde un portátil o smartphone. Además se facilita la colaboración entre empleados, permitiendo a varios usuarios trabajar conjuntamente sobre proyectos o documentos. No digamos la posibilidad de realizar reuniones online.
4.- ¿Quieres tener más tiempo para centrarte en tu negocio?
Una infraestructura cloud te permite tener más tiempo libre para centrarte en el core de tu negocio. Con menos servidores y ordenadores que administrar, puedes tener tiempo para establecer estrategias que den a la empresa las herramientas y procesos necesarios para crecer.
Un buen departamento IT es realmente aquel que ayuda a la empresa a utilizar la tecnología para avanzar en los objetivos de la empresa.
5.- ¿Necesitas proteger los activos digitales de tu empresa?
Los servicios en la nube permiten mejorar la seguridad de la empresa. En algunos casos, los empleados sólo acceden a datos alojados en un servicio en la nube, sin tener que almacenar datos localmente. Sin embargo, muchas empresas consideran que una solución híbrida es la que se adapta mejor a sus necesidades. En esta solución, utilizan ciertos datos alojados en la nube y otros alojados en su propia infraestructura. Pero debemos tener en cuenta que si alojamos datos en nuestra infraestructura, deberemos protegernos de ataques externos como virus, malware 0 accesos no autorizados, y en ciertos casos establecer sistemas de encriptación o de copias de seguridad.
La seguridad no sólo alcanza a la protección de los datos, si no también a la continuidad del negocio. Un proveedor cloud seguramente tendrá centros de datos replicados con políticas de continuidad de negocio. Sin embargo, es necesario alcanzar y comprender los acuerdos de nivel de servicio (SLA), así como las medidas que toma nuestro proveedor de servicio a la hora de proteger nuestros datos.
Bienvenido a Virtualizamos
