Seguridad

Seguridad en la nube: responsabilidad compartida entre proveedor y cliente

La seguridad en la nube es una responsabilidad compartida entre el proveedor cloud y el cliente final.

Si nos centramos en el lado del proveedor, éste tiene la responsabilidad de asegurar todo aquello que está en capas inferiores al sistema operativo (red, almacenamiento, infraestructura, hardware, etc).

Desde el lado del cliente es el responsable de securizar su plataforma (sistema operativo), aplicaciones y el acceso a sus datos (siempre y cuando no tenga contratado algún tipo de servicio de mantenimiento/administración global). Por lo tanto, deberá prestar atención en todas aquellas piezas que considera importantes a nivel de seguridad, escogiendo las aplicaciones a instalar, configurando el sistema operativo adecuadamente y monitorizando el acceso a datos de los usuarios.

El proveedor deberá tener un firewall perimetral basado en el tipo de infraestructura que tenga, pero debe dejar disponible en las máquinas virtuales que aloja, la posibilidad de activar un firewall a nivel de sistema operativo. De este modo, es el cliente quien tiene la oportunidad de decidir qué reglas activar y cuáles se adecúan más al servicio que presta.

Si el proveedor cloud da servicios de almacenamiento en nube, es fundamental asegurar la integridad de los datos. Por ejemplo, el proveedor puede utilizar sistemas de firma utilizando hash MD5.

Por último, en los últimos tiempos están apareciendo estándares de seguridad relacionados con la nube: SOC1, SOC2, ISO 27001, FISMA y PCI DSS. En este sentido, el proveedor, en función de su tipo de cliente, debe intentar que sus procesos sigan los procedimientos marcados por estos estándares.

Share

Aspectos de seguridad a tener en cuenta en un entorno virtualizado

El proceso de securizar nuestra infraestructura de virtualización requiere un esfuerzo serio por parte del departamento IT de una empresa. Durante el proceso de implementación de la infraestructura virtual, los responsables de seguridad deben tener en cuenta y ejecutar una serie de tareas críticas: protección de hypervisores, endurecer la seguridad de los sistemas operativos que se ejecutan en las máquinas virtuales alojadas y evaluar los controles de seguridad actuales para comprobar si son aplicables en el nuevo entorno.

Una vez que hemos terminado de desarrollar nuestro entorno de virtualización, aparecen un conjunto de nuevas amenazas que deberemos tener en cuenta. Estas amenazas suelen ir apareciendo conforme nuestra infraestructura va madurando: proliferación sin control de máquinas virtuales (VM sprawl), imágenes de máquinas virtuales latentes (mothballed) y desafíos en lo que se refiere al mantenimiento y administración del inventario de activos e imágenes existentes.

Expansión de imágenes virtuales

Dependiendo de como hayamos establecido los permisos en nuestra infraestructura, es posible que tengamos usuarios que sean capaces de crear clones o imágenes (snapshots) de máquinas virtuales sobre las que llevan la administración. Si no tenemos un cierto control, podemos encontrarnos con un crecimiento desmedido de estos elementos. Por ejemplo puede ocurrir que una determinada imagen de una máquina virtual sea clonado e importado en otra ubicación sin tener nosotros el control.

Pero no sólo debemos tener en cuenta el crecimiento de clones o imágenes. Pensemos en que existen diferentes tipos de virtualización: de servidores, de aplicaciones, VDI, de almacenamiento, etc. Por lo tanto podemos encontrarnos que nuestra infraestructura está compuesta por elementos de diferentes fabricantes que a su vez tengan diferentes perfiles de seguridad.

Monitorizar administradores y el crecimiento de máquinas virtuales

La profileración de máquinas virtuales debe ser una preocupación continua. Por lo tanto deberemos utilizar herramientas que nos permitan controlar nuestro entorno conforme crece y estar alertas antes situaciones de VM sprawl.

Debemos tener un inventario de los accesos con permisos de administración existentes y utilizar herramientas que nos permitan monitorizar la proliferación de credenciales administrativas. De igual modo que en un entorno IT tradicional, el control de credenciales administrativas es algo imperativo en un entorno virtual. Nos deberemos asegurar que los derechos de administración existentes son razonables y apropiados.

También deberemos estar atentos a situaciones en las cuales la reubicación de máquinas virtuales puede romper nuestro modelo de seguridad. Por ejemplo pensemos el caso de una máquina virtual que presta servicios al departamento de contabilidad y sea migrada (por ejemplo con vMotion en un entorno VMware) a una máquina física propiedad de otro departamento, por ejemplo el de calidad. Tambien nos podemos encontrar con situaciones en que un usuario que tenga acceso a imágenes de máquinas virtuales, puede importarlas a servicios cloud como Amazon EC2.

Share

Estados Unidos da pasos hacia la estandarización en la nube con FedRAMP

Las agencias gubernamentales (locales o federales) estadounidenses establecen unos requerimientos legales complejos en lo que se refiere a seguridad para mover sus datos a un proveedor cloud. Hay que tener en cuenta que estas agencias gestionan datos sensibles. Según un informe elaborado por la consultora IDC, las principales preocupaciones de estas agencias a la hora de adoptar soluciones cloud computing son la seguridad, falta de experiencia y los costes.

Con el objetivo de favorecer la adopción del cloud computing en los organismos oficiales, el Gobierno de Estados Unidos ha creado el programa Federal Risk an Authorization Management Program (FedRAMP). Éste intenta estandarizar y mejorar los requerimientos de seguridad y transparencia para la adopción del cloud computing. De este modo se pretende estandarizar la evaluación en lo que respecta a seguridad y monitorización continua de productos y servicios. La evaluación de proveedores esta basada en un proceso de gestión del riesgo que incluye requerimientos de seguridad acordados por varios organismos oficiales.

En la actualidad no hay ningún proveedor certificado por FedRAMP, pero ya existen varios que están interesados en ello (como por ejemplo Microsoft).

Como podemos ver, la estandarización es un proceso a tener en cuenta en el desarrollo del cloud computing y en la diferenciación entre proveedores cloud. De momento, yo sólo conozco movimientos de estandarización (como por ejemplo PCI DSS) en lo que se refiere a seguridad y casi siempre promovidos por entidades gubernamentales o bancarias. Lógico, si tenemos en cuenta la sensibilidad de los datos que manejan.

Share

Servicios cloud de recuperación ante desastres (DR)

Tradicionalmente las empresas se han fijado en los servicios de copias de seguridad y almacenamiento que ofrece la nube, pero últimamente se están fijando en los servicios de recuperación ante desastres (DR). Los proveedores cloud pueden ofrecer servicios DR a sus clientes en su infraestructura como alternativa a la necesidad de construir un sitio de replicación entero.

Pero hechos como la caída que sufrió recientemente Amazon Web Services está haciendo que muchas empresas dejen de considerar como sinómimos a los conceptos continuidad de negocio y cloud.

En un artículo anterior ya hablamos de los desafíos y oportunidades a los que los proveedores cloud deben enfrentarse. A pesar de su redundancia, la nube está basada en equipamiento físico (que es probable que pueda fallar), por lo tanto los proveedores cloud deben disponer de un plan DR (Disaster Recovery) que se active en caso de caídas y permita continuar con el servicio. Los proveedores deben probar que sus servicios de recuperación ante desastres son fiables. De este modo, si construyen servicios accesibles y elásticos (en lo que se refiere a capacidad de recuperación)y respaldados por fuertes acuerdos de nivel de servicio (SLA), pueden obtener nuevos clientes.

En un servicio de recuperación ante desastres, los clientes finales necesitan un SLA que les garantice que, en caso de desastre, su proveedor puede hacer que el servicio y los datos sean accesibles en un determinado periodo de tiempo.

En este sentido, están empezando a surgir servicios de recuperación ante desastres en la nube (Disaster Recovery as a Service – DRaaS) elaborados por fabricantes relacionados con productos para cloud computing y IaaS. Un ejemplo es el ecosistema anunciado recientemente por Zerto, un fabricante de software de productos de virtualización, también conocido como Zerto Cloud Disaster Recovery Ecosystem (ZCE). Este ecosistema se basa en un programa de partnership en el cual los proveedores cloud pueden establecer de forma fiable servicios DR en la nube.

El programa ZCE permite a los proveedores cloud replicar sus datos a nivel de hypervisor, a diferencia de otros servicios de replicación de datos que se basan en arquitectura de almacenamiento. De esta forma, la capa de replicación es agnóstica del tipo y tecnología de almacenamiento utilizado. Uno de los principales requerimientos que existían hasta ahora es que los clientes tuvieran el mismo tipo de almacenamiento que su proveedor cloud DR, lo cual hacía incrementar los costes de implantación.

Al replicar máquinas virtuales a nivel de hypervisor, el servicio es mucho más escalable, flexible y en línea con el paradigma de la tecnología cloud.

Share

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

Share

Bienvenido a Virtualizamos

Virtualizamos es un proyecto de la empresa nerion que nace con el objetivo de convertirse en un portal de referencia en el mundo de la virtualización y el cloud computing.
Suscripción a Virtualizamos
Entradas antiguas por mes
Twitter
nerion - Registro Dominios, Hosting y Housing Profesional