He de confesar que el número 8 ejerce cierta magia sobre mi persona, no es mi número favorito, ni mi número de la suerte, y tampoco comparto la fijación de ciertas culturas orientales con este número, pero he de decir que hay ciertas cosas en él que me fascinan. El que sea un número redondo, literalmente, es una de ellas, mires por donde lo mires siempre será un “8”, y si lo pones en horizontal será un símbolo de infinito, lo que es todavía mejor.
Con 8 bits empezó el mundo digital que hoy conocemos. ¡Qué tiempos aquellos los del famoso procesador Z80 que montaban los modelos más chulos de los 80s! Algún día encontraré tiempo para restaurar mis viejitos ZX Spectrum, que por ahora viven en alguna caja de las que hay por casa.
Llevo ya un rato hablando del “8” y seguro que os estaréis preguntando a que viene todo esto. Básicamente, porque este año 201”8” reabre el TecnoChiringuito del Luso, coincidiendo con los 8 años del lanzamiento de Azure por parte de Microsoft. Además, el número 8 tiene también una relación con la inauguración del TecnoChiringuito del Luso, el 8 de Enero de 2009 para ser más concreto.
Realmente, han pasado 10 años, no 8, desde que empecé a trastear con Azure, porque la “Preview” se lanzó en Octubre de 2008, pero el lanzamiento oficial fue en Febrero de 2010, así que, aprovechando los 8 añitos que cumple este año, me parece un momento ideal para reabrir este foro. Azure cubrirá una buena parte de la temática a la que lo voy a dedicar.
Obviamente alguna cosa de Office 365 caerá también, ya que cada vez hay más relación entre ciertas características de esta plataforma SaaS con Azure, y como todos sabemos Office 365 corre sobre Azure. Aunque, no solo de Azure se hablará por aquí, podéis esperar también alguna otra cosita fuera de la selección Microsoft. 🙂
Como cualquier reapertura, el “local” se merece una obra, un lavado de cara para adecuarlo a los nuevos tiempos. Esto lo llevaré a cabo más adelante, para no dilatar más el momento del re-estreno, y tanto que es así que, ahora mismo aprovecho el hecho de encontrarme encerrado en un vuelo intercontinental de 13h para dar este pistoletazo de salida a la v2.0 del Tecnochiringuito del Luso.
Espero poder contar con vosotros en esta nueva etapa y que os guste lo que por aquí se irá “cocinando”. Bienvenidos de nuevo y a la siguiente ronda invita la casa. Eheh!
Windows Azure Pack es una solución fabulosa para obtener un subconjunto de las funcionalidades disponibles con Azure, en nuestra propia infraestructura. Todo ello apoyado por cosas como Windows Server 2012 R2 y System Center 2012 R2.
Como sería de esperar, en una solución de estas, el “paquete” viene bastante rellenito con multitud de funcionalidades y posibilidades, que no siempre se ven a golpe de click.
Una de las cosas que llaman la atención tras implementar Windows Azure Pack, es que disponemos de 2 formas posibles para el despliegue de máquinas virtuales, lo que vulgarmente se llama IaaS (Infraestructura como servicio) en el idioma de la nube.
Las máquinas virtuales pueden ser “Máquinas virtuales independientes” (Standalone), lo que viene siendo lo mismo que una plantilla de máquina virtual de Virtual Machine Manager, o VM Roles, esta última opción combina las posibilidades del motor de plantillas de VMM con un asistente personalizable de despliegue, resultando en un proceso de creación de máquinas virtuales mucho más rico y lleno de opciones.
Hasta aquí todo es bonito, o eso parece, pero como se dice en mi “pueblo”: Não há bela sem senão.
Una de las características de los VM Roles es el uso de discos diferenciales en la generación de las máquinas virtuales. La idea por detrás de esta opción de diseño consiste en que, ese disco padre (VHD o VHDX) se copia desde la biblioteca de VMM, una sola vez por cada uno de los hosts de Hyper-V en los que se despliega ese “servicio”. VMM va guardando las rutas de estas copias realizadas en cada uno de los nodos de computación durante el primer despliegue y, esto en teoría, acelera no solo el proceso de creación, como también los procesos de escalado, ya que los VM Roles, al contrario de las máquinas independientes, permiten ser escalados a varias instancias similares.
Como desventaja, el uso de los discos diferenciales, hace que muuuuchas máquinas virtuales dependan de un único disco, por lo que si hay un problema con la unidad donde se almacena ese disco (copia de la biblioteca de VMM)… Adivina adivinanza… Pues eso, suicidio en masa de vuestras VMs.
Además, la gestión de estos intrincados de discos padre y discos diferenciales suele ser bastante compleja.
Por otro lado, en un plan más técnico, esta solución también requiere almacenamiento com unas características algo distintas, una vez que ese disco padre, es donde acaban todas las lecturas de las VMs para aquellos sectores que no han cambiado y que se mantienen iguales en todas ellas a lo largo del tiempo, es decir, normalmente el SO, y más concretamente las partes que no sufren actualizaciones.
Con o sin diferencias…
En entornos donde prima la alta disponibilidad esto puede ser un problema y gordo, así que, con el Update Rollup 5 de System Center Virtual Machine Manager 2012 R2 , Microsoft incorporó la posibilidad de modificar este comportamiento para que los despliegues de VM Roles puedan usar discos dedicados, y dotar a nuestra instancias virtuales de alguna independencia, incrementando su fiabilidad.
Esta configuración se implementa mediante una propiedad de “Cloud”, como se indica a continuación:
1. Abrir las propiedades de nuestra “Cloud” en la consola de VMM.
2. Ir al apartado de Custom Properties y pulsar el botón Manage Custom Properties.
3. Elegir como tipo de objeto Cloud y crear una nueva propiedad con el nombre DifferencingDiskOptimizationSupported.
4. Añadir la nueva propiedad a la lista de Assigned Properties y pulsar Ok.
5. En el valor de esta propiedad introducir el valor false y pulsar Ok.
Consola VMM – Dialogo de gestión de propiedades
Una vez realizada esta configuración, todos los VM Roles empezarán a ser creados con discos dedicados. Ahora eso sí, los que ya se habían desplegado previamente mantendrán sus discos diferenciales y su dependencia del disco padre, por lo tanto cuidado con esos borrados.
Si aun así no os queda claro, solo me queda a que juguéis al “Encuentra las diferencias” con la imagen de abajo. 
Consolas de VMM – Custom Properties
¿Qué bonito es mi nuevo Windows Azure Pack?
Peero, pero… ¿Y por qué las máquinas virtuales no se despliegan en alta disponibilidad?
Esta será seguramente una de las primeras preguntas que os hagáis al ver que vuestro primer despliegue de un VM Role, en Windows Azure Pack, no genera un rol de clúster, o sea que se queda en una máquina virtual normal y corriente sin alta disponibilidad.
La pregunta que viene a continuación es: ¿Qué he hecho mal?
Bueno, realmente mal, nada, pero se os ha escapado una configuración que habilita esta posibilidad. Es muy fácil que se os escape esto, porque está documentado en una guía de diagnóstico de problemas en medio de una serie de cosas. Vamos, algo que encontramos si sabemos exactamente lo que vamos buscando. Ya, ya lo sé, no tiene demasiado sentido, pero así es la vida.
VM Role en alta disponibilidad
Para habilitar el despliegue de VM Roles en alta disponibilidad solo tenemos que configurar una propiedad en la definición de nuestra “Cloud”, y esto lo podemos hacer o bien mediante la consola de VMM, o bien mediante PowerShell.
A través de la consola de VMM el proceso es el siguiente:
1. Abrir las propiedades de nuestra “Cloud”.
2. Ir al apartado de Custom Properties y pulsar el botón Manage Custom Properties.
3. Elegir como tipo de objeto Cloud y crear una nueva propiedad con el nombre CreateHighlyAvailableVmRoles.
4. Añadir la nueva propiedad a la lista de Assigned Properties y pulsar Ok.
5. En el valor de esta propiedad introducir el valor true y pulsar Ok.
Consola de VMM – Custom Properties
Si por otro lado lo que buscáis es un poco de aventura, podéis atreveros con PowerShell, tal y como se describe en la página de TechNet que os comenté antes: Deploy a highly available VM Role
¡Olé! A disfrutar de vuestros VM Roles en cluster.
😉
De entre todo lo estándar que pueden ser las PKIs y los certificados, al final siempre llega un momento en que al mezclar cosas de distintas plataformas, la liamos. Y no es un liarla de liarla “parda”, no, no, es simplemente un liarla porque nos encontramos con las diferencias que al final existen, pese a estándares y otras declaraciones de intenciones.
¿Y a que me refiero yo exactamente con esta introducción?
Me refiero a que mientras todo nuestro proceso se desarrolle dentro de una misma plataforma, e.j. OpenSSL o Windows Server ADCS, lo normal es que todo sea maravilloso, el problema empieza con las mezclas. Como siempre, las mezclas acaban en problemas… Bueno, volviendo al tema que nos atañe, que se me va.
Mezclas, es decir, cosas como procesar solicitudes de una plataforma en la otra, por ejemplo. La situación que os describo hoy puede ser muy útil en escenarios del día a día, donde tenemos que generar certificados para multitud de equipos que no tienen plataforma Windows, ni saben de dominios de AD ni nada de esas cosas.
En mi caso concreto, lo hago a menudo para impresoras, switches de red y equipos con plataforma Linux. En estos casos, lo que ocurre es que acabamos con un fichero de texto (.csr), conteniendo la solicitud de certificado generada por el equipo, o por la suite OpenSSL si se trata de una maquina Linux.
Ooops!.. (El Error)
Si intentamos entregar esta solicitud directamente a una CA (entidad certificadora) Windows Server ADCS, a través de la consola de dicha CA (pulsando botón derecho sobre la CA y luego Todas las tareas -> Enviar solicitud nueva…), lo más probable es que acabemos con un mensaje similar a este que vemos abajo:
Error al procesar una solicitud de OpenSSL
¿Qué ha pasado?
Bueno, que nadie entre en pánico, es sencillo. Lo que ocurre es que, las CAs en Windows Server requieren que en la solicitud se les indique la plantilla de certificado a usar para emitir dicho certificado, peeeero, estos equipos al ser completamente independientes al dominio, plataforma y todo lo que le rodea, no disponen de ninguna información acera de dichas plantillas. Por este motivo no queda otra que generar la solicitud sin dicha información, esperando que eso se indique durante el proceso de emisión.
La salvación…
Afortunadamente, existe un comando fantástico en todas las CAs Windows Server, que nos permite hacer el truco, os hablo de certreq. Si no lo conocíais os lo presento:
– certreq.. Estos son nuestros carísimos IT Pros
– IT Pros.. Nuestro queridísimo certreq
certreq es el comando que gestiona las operaciones relacionadas con las solicitudes y emisión de certificados en las CAs Windows Server, y que nos permite especificar que plantilla queremos usar para procesar una determinada solicitud. Así que, nuestra salvación está en este comandito que os indico a continuación:
certreq -submit -attrib "CertificateTemplate:WebServer" SolicitudCert.csr
Esta es la forma de especificar la plantilla que queremos usar para emitir el certificado solicitado mediante el fichero SolicitudCert.csr, a través del atributo CertificateTemplate incluido en la línea de comando.
Y si… me dan miedo las consolas
No pasa nada, afortunadamente tenemos una alternativa a través del portal de la CA, para ello solo tenemos que conectarnos a la URL: https://<ServidorCA>/certsrv, donde <ServidorCA> es el nombre de nuestro servidor que ejecuta el rol de Windows Server ADCS, y el responsable por emitir los certificados en nuestro entorno.
Envío de solicitud a través del portal web de la CA
Navegando por las opciones: Solicitar un certificado -> Solicitud avanzada de certificado -> Enviar una solicitud de certificado con un archivo codificado en base64 CMC o PKCS#10 o una solicitud de renovación con un archivo codificado en base64 PKCS#7, podemos copiar y pegar la solicitud de certificado directamente en la caja de texto, y recoger el resultado, bien instalando dicho certificado en la máquina local, o bien mediante el fichero descargado.
La guinda…
Para terminar solo una pequeña notita. Si acaso no os aparece en el desplegable la plantilla que necesitáis usar para emitir el certificado, debéis aseguraros que esa plantilla tiene permisos de Leer e Inscribirse para la cuenta que estáis usando. Además, se debe realizar la publicación de dicha plantilla después de hacer el cambio, y reiniciar la entidad certificadora.
En el caso de que la plantilla ya tenga asignados esos permisos, para una cuenta o grupo administrativo, y se esté usando esa cuenta, debemos lanzar Internet Explorer dentro de un contexto de seguridad de administración, usando la opción “Ejecutar como Administrador”.
Dicho esto… ¡A mezclar todo el mundo!
A lo largo de nuestras vidas con la tecnología, todos vamos incorporando ciertos truquillos/comportamientos en nuestro día a día con las máquinas, que nos hacen la vida mucho más fácil. Hoy os voy a hablar de uno de esos truquillos, que para mí es fundamental, y que con la incorporación de la nueva interface de Windows 8 y 8.1 me estaba dando algo de guerra, pero primero veamos el escenario…
Si tenéis que dedicar algo de tiempo a las labores de gestión, a bien de la seguridad del entorno de vuestras empresas, lo más normal es que vuestras cuentas de usuario no tengan directamente privilegios de administración de dominio y esas cosas. En mi caso, cada uno de nosotros tiene su usuario de dominio con los permisos necesarios para trabajar y luego una segunda cuenta, “especial”, para las labores que requieren ensuciarse las manos, meter la cabeza en las consolas de los servicios, etc.
Ya veis por donde voy, mí día a día está lleno de ejecuciones “Run As”, o “Ejecutar como”, para seguir la misma nomenclatura que la interface de Windows en castellano.
“Run As”, “Ejecutar como” o “El otro Yo”…
Cuando recurrimos a esta metodología de cuentas de usuario, lo normal es que en los escritorios de los administradores de sistemas veamos una mezcla de aplicaciones y ventanas, ejecutándose tanto con la cuenta normal del usuario como con la cuenta de administrador que le está asignada (consolas y demás herramientas dedicadas al trabajo “duro”).
Esto es algo que se lleva muy bien, en un entorno puramente de escritorio de Windows (como los que teníamos hasta Windows 7, e incluso en el escritorio de Windows 8), pero si incorporamos la nueva interface de Windows 8, con el nuevo menú de Inicio, a nuestra forma de trabajar, necesitamos algunos pequeños retoques para conseguir que todo siga siendo igual de ágil.
En el escritorio, ejecutar una aplicación con una cuenta de usuario distinta (ya sea una cuenta de administración o cualquier otra) es muy sencillo, pulsando la tecla Shift y luego el botón derecho del ratón sobre la aplicación deseada hacemos que esta opción aparezca en el menú contextual.
Opción “Ejecutar como” en el entorno de escritorio
Donde las cosas se complican es cuando tenemos que hacer la misma operación lanzando las aplicaciones desde el menú de Inicio de Windows 8 o 8.1, al pulsar el botón derecho esta opción no está disponible.
Está claro que esta opción no es necesaria en la gran mayoría de escenarios de uso de Windows cliente, me atrevería incluso a decir que más de un 80% de usuarios jamás la necesitará, por lo que el hecho de que esté oculta hace que la interface sea más sencilla y limpia.
Sin embargo, para perfiles como los administradores de sistemas y desarrolladores de aplicaciones, esta funcionalidad es muy útil y en definitiva algo a tener en cuenta. Solo un pequeño paréntesis antes de seguir, me refiero en todo momento a Windows cliente (8 y 8.1) porque en Windows Server (2012 y 2012 R2) esta opción sí que está habilitada por defecto, aunque me imagino que, en general y siguiendo unas buenas prácticas, realizáis las labores de administración desde una estación de trabajo en lugar de hacer RDPs a diestro y siniestro.
En el escenario de administración que os comentaba anteriormente, cuento con mi grupo de iconos en el menú de Inicio de Windows 8 con todas las consolas que necesito. Para conseguir habilitar esta opción y desde ahí poder lanzar estas aplicaciones con el contexto del usuario correspondiente, tenemos que habilitar esta funcionalidad mediante una GPO de Windows.
Estos son los pasos para habilitar la opción con la consola de directivas de equipo local, para realizar la operación a nivel de dominio sería algo similar pero gestionándolo desde la consola de directivas de dominio:
- Abrir la consola de directivas de equipo local, ejecutando gpedit.msc.
- Buscar la directiva en la ruta: Directiva Equipo Local -> Configuración de usuario -> Plantillas administrativas -> Menú Inicio y barra de tareas (Si tenéis la interface en inglés sería: Local Computer Policy -> User configuration -> Administrative Templates -> Start Menu and Taskbar).
Consola de directivas de equipo local
- La directiva que deseamos habilitar es: Mostrar el comando “Ejecutar como otro usuario” en Inicio.
- Seleccionamos Habilitada, aplicamos los cambios, y esto nos activa la opción en el menú de Inicio como se puede ver a continuación.
Directiva: Mostrar "Ejecutar como otro usuario"
Ahora nuestro menú de Inicio, al hacer “botón derecho” o su equivalente en equipos con pantalla táctil, nos presenta la opción deseada, como podemos ver en la imagen de abajo (izquierda – versión táctil; derecha – versión tradicional con ratón).
"Ejecutar como otro usuario" en el menú de Inicio
Para terminar me gustaría dejaros una pequeña nota acerca de la activación de esta opción, al hacer el cambio a la política la activación es inmediata, sin embargo, en equipos miembros de dominio (que será la inmensa mayoría de los casos para el escenario de administración descrito), la opción solo se activará cuando el equipo esté conectado a la red corporativa con acceso a sus controladores de dominio.
Yuhu! A administrar sin parar…
¿Por dónde empiezo?
Ahora que hemos sentado las bases de las plataformas de nube, en la Parte 0 de esta serie, publicada hace ya algún tiempo, es hora de remangarse un poco y empezar a crear cosas en Azure.
Hay algunos elementos que debemos preparar antes de crear nuestra primera máquina virtual, pero como veréis no es nada complicado, y de esta forma empezaremos con un entorno ordenadito que no nos traerá problemas en cuanto empecemos a crecer en la nube.
Grupo de afinidad
El primer concepto que quiero introducir hoy es el de “grupo de afinidad”, este debe ser el primer elemento que creamos en nuestra suscripción de Azure y el que sirve de base a todo lo demás.
El grupo de afinidad tiene dos funciones realmente, una a nivel lógico y otra a nivel más físico, relacionada con la asignación de recursos.
A nivel lógico, los grupos de afinidad permiten agrupar recursos de procesamiento y almacenamiento que tienen una relación entre ellos, por ejemplo, el almacenamiento (VHD) que usa una determinada máquina virtual. En una perspectiva un poco más amplia, podemos considerar también un conjunto de máquinas virtuales relacionadas entre ellas, o que comparten alguna característica común, por ejemplo los recursos asignados a un departamento, u organización, en el caso de que gestionemos varias entidades desde una misma suscripción.
Esta sería la parte lógica que nos ayuda a tener la casa ordenada desde el punto de vista del administrador de recursos en la nube. Por otra parte, el grupo de afinidad tiene también unas implicaciones físicas en lo que toca a la asignación y consumo de recursos, como hemos comentado anteriormente.
Los aspectos principales que los grupos de afinidad nos permiten controlar a nivel físico son el rendimiento y los costes. Un grupo de afinidad está asociado a un determinado CPD de Azure, pero como todos sabemos, en Azure los CPDs están constituidos por contenedores con clusters y racks (cada contenedor se encarga de una serie de servicios concretos de la plataforma), por lo que es interesante tener un poquito más de control sobre la colocación de los elementos de nuestra plataforma dentro del mismo.
Por exagerar un poco el ejemplo para que quede del todo claro, seguro que a ninguno se nos ocurriría crear el almacenamiento de una máquina virtual en el CPD de Chicago y ejecutar la máquina virtual en el CPD de Ámsterdam (aunque quisiéramos no sería posible, pero para que se entienda el concepto). Esto generaría una latencia tremenda perjudicando el rendimiento, además de los costes a nivel de comunicaciones, una vez que en Azure se facturan los datos enviados fuera del CPD.
Al colocar los recursos dentro del mismo grupo de afinidad, no solo estamos agrupándolos en términos lógicos pero también le estamos diciendo a Azure que esos recursos deben colocarse los más próximo posible dentro del CPD, si posible en el mismo cluster o contenedor. Esto reduce la latencia y optimiza el rendimiento del entorno.
La creación del grupo de afinidad es bastante sencilla, solo tenemos que darle un nombre, una descripción (opcional), la suscripción asociada e indicar en que CPD de Azure va a “vivir” este grupo de afinidad. Una vez hecho esto, estamos listos para crear los recursos asociados al grupo de afinidad y Azure se encargará del resto.
Creación de grupo de afinidad en Azure
De momento esta opción solo está disponible a través del portal “antiguo” de Azure, el que se encuentra en producción. El nuevo portal está en Preview por lo que es de esperar que, poco a poco, todo vaya encontrando su lugar allí también. La creación del grupo de afiniddad se realiza entrando a Configuración –> Grupos de Afinidad.
Grupos de afinidad en el portal de Azure
Este fue el primer paso en nuestro viaje hacía la nube, en los proximo pasos nos iremos acercando a nuestro objetivo a través del almacenamiento y la red. Espero que disfrutéis del viaje tanto como yo.
Entradas relacionadas:
Una cosa que me tiene muy entretenido en los últimos tiempos, y por lo visto seguirá manteniendo por bastante tiempo más, es la plataforma de servicios en la nube Windows Azure. O mejor.. ¡Microsoft Azure!
Esto es así porque, a finales del año pasado embarqué en un proyecto que, de entre los requisitos fundamentales para funcionar, tenía esta bonita declaración de intenciones:
“La empresa funcionará sin servidores on-premise, los únicos equipos permitidos en una oficina serán impresoras y electrónica de red. Además, todos los costes de infraestructura servidora tienen que seguir un modelo de costes OPEX”
Suena muy bien, y es muy bonito así en el papel, peeeero esto nos lleva a cuestionar una serie de cosas relacionadas con la nube, fuerte candidata a dar solución a estos escenarios:
- ¿Será posible obtener toda la funcionalidad deseada?
- ¿Qué modelos son los más adecuados para cada componente?
- ¿Realmente, está la tecnología preparada para tan arriesgado escenario?
Está claro, había que estudiar la viabilidad del proyecto, y luego encontrar la forma de implementarlo, claro. En esta serie de posts De “nada” a la “nube” en 0, os cuento mis penas y éxitos en este intento, que ha ido ocupando los minutos de mi vida, extra laboral, durante estos últimos tiempos. Espero que sirvan para hacer más fácil la vida a los que tengáis que pasar por lo mismo.
Antes de conectarnos al portal de Azure y empezar a crear cosas a lo loco, que al final nos pueden costar una que otra marcha atrás, refresquemos algunos conceptos de las plataformas de nube. Probablemente estéis ya familiarizados con algunas de las cosas que hablaremos a continuación, sobre todo si le habéis dedicado algo de tiempo a “la nube”. De todas formas, no está demás clarificar estos conceptos y establecer una base común.
Empecemos con una definición, lo más estándar posible, de los conceptos que caracterizan las plataformas de nube. Os recomiendo la definición del NIST, una vez que, al contrario de muchas definiciones presentadas por algunos fabricantes, es lo más neutral posible y evita que acabemos mezclando churras con merinas.
Definición de Cloud Computing del NIST: http://csrc.nist.gov/publications/nistpubs/800-145/SP800-145.pdf
Cuando intentamos describir y clasificar las plataformas de nube, nos referimos a características, modelos de servicio y modelos de despliegue.
- Características: corresponden a los requisitos que una determinada plataforma tiene que cumplir para que se considere una plataforma de nube.
- Modelos de servicio: tienen en cuenta, sobre todo, el equilibrio entre los componentes del modelo computacional, proporcionados por el proveedor y los gestionados, o controlados, por el cliente.
- Modelos de despliegue: son una clasificación de las plataformas según el uso que se hace de los recursos y por parte de quién.
Sin ánimo de quitar importancia a los modelos de despliegue y características de las plataformas de nube, en este post nos centraremos en los modelos de servicio. Azure es una plataforma que está presente en todos ellos y esto es importante desde el punto de vista de un arquitecto IT, porque permite crear soluciones que usen distintos componentes, disponibles a través de los varios modelos, de forma muy integrada. Estamos hablando, lógicamente de los conceptos de SaaS, PaaS e IaaS, o lo que es lo mismo Software como Servicio, Plataforma como Servicio e Infraestructura como Servicio.
Dentro de los modelos de servicio nos encontramos con las siguientes clasificaciones, cada una de ellas describiendo un tipo de solución enfocada a un perfil distinto.
-
Software como Servicio (SaaS): El proveedor proporciona al cliente aplicaciones terminadas que se ejecutan en su infraestructura de nube. Normalmente estas aplicaciones están accesibles desde múltiples dispositivos, mediante el uso de plataformas web y/o interfaces nativas creadas para un sistema en concreto. En este caso el cliente no necesita gestionar ninguno de los componentes de la infraestructura, preocupándose solamente con las configuraciones de la propia aplicación y sus datos.
-
Plataforma como Servicio (PaaS): La funcionalidad proporcionada al cliente consiste en una plataforma con soporte para lenguajes de programación, herramientas y servicios, sobre los cuales se ejecutan las aplicaciones desplegadas, ya sean desarrollos propios o adquiridos a terceros, construidos para esos componentes específicos. El cliente se encarga de la aplicación (código y todos los componentes empleados durante su desarrollo), sus datos y las configuraciones del entorno en el que está alojada, dejando al proveedor toda la administración de la infraestructura que la soporta (servidores, almacenamiento, red, etc.).
-
Infraestructura como Servicio (IaaS): En este modelo se proporciona al cliente capacidad de procesamiento, almacenamiento, redes y otros recursos computacionales, para que este pueda ejecutar sus servidores y aplicaciones. Normalmente estas plataformas van asociadas con plataformas de virtualización, donde el proveedor se encarga de los componentes físicos y de la capa de virtualización, dejando el control de los sistemas operativos y demás componentes tecnológicos en manos del cliente.
Modelos de servicio y perfiles típicos a los que corresponden
A lo largo de los varios artículos que compondrán la serie, me centraré más en la parte de Infraestructura (IaaS), aunque eso no implica que no haga alguna incursión por el resto de modelos de servicio, al final a todos nos toca quitarnos la gorra de ITero de vez en cuando.
Podemos decir que esta ha sido la Parte 0 de esta serie, el artículo que pretendía ser apenas una Introducción y con el que establecíamos unas bases de las plataformas de nube. Ahora que todos estamos en la misma página, ya podré preparar algo sobre el punto de partida en el viaje a Azure. En breve llegará la Parte 1 – ¿Por dónde empiezo? aquí al TecnoChiringuito, mientras tanto nos tomamos otra a vuestra salud.
Entradas relacionadas:
Hace hoy 10 años exactos, que un jovenzuelo abandonaba su puesto de trabajo de consultor (a.k.a carne barata para venta al mejor postor), y empezaba a dedicarse a labores que hasta ese momento solo le aparecían en sus sueños.
Hace hoy 10 años exactos que empezó un viaje, tal vez el más importante de su vida profesional, o el más exigente quizás, pero seguramente uno muy, muy divertido, y esta es la sensación que se debe tener al mirar hacia atrás, “que me quiten lo bailao”… 
Recuerdo que en esa época, la noticia de la nueva aventura que empezaba cayó como una bomba en mi círculo de amistad, dejando a todos incrédulos, era imposible que ese jovenzuelo aceptara trabajar para “esa corporación”. Ahahah!!! Cuanto ingenuo suelto por el mundo.
La cosa es que hasta una revista me dedicaron, y aunque “los titulares” interesantes estén en portugués creo que se entienden, por eso comparto aquí con vosotros esta edición “súper especial” de Todo Linux:
La vida está hecha de sucesos, de cambios, de inquietudes, de conquistas, y por eso nos adaptamos y buscamos más, algo diferente, nuevo, reto tras reto. Esa fase de mi vida terminó, pero me dejó lazos muy fuertes y recuerdos inolvidables, experiencias que me ayudan a ser quien soy hoy. Era la hora de emprender otros viajes, recorrer nuevos caminos, y esto requiere que algunas ataduras se rompan, por eso el TecnoChiringuito cambia de ubicación. Seguirá siendo el mismo chiringuito, con el mismo buen rollo del que empezó hace 5 años, en Enero de 2009, pero en un sitio distinto, más amplio y con otra decoración (que por cierto se irá “tuneando” con el tiempo).
Estáis todos invitados a una ,vcp (Virtual CoPa), y bienvenidos otra vez a este vuestro rinconcito de tecnología en Internet.
el Luso.
Entre las múltiples posibilidades que nos ofrecen los VHDs, una que llevo mucho tiempo usando pero que todavía no había “documentado” aquí, es la de usar un VHD maestro a partir del cual se generan nuestras instalaciones y despliegues. En mi caso, lo que hago es tener un VHD por cada versión de sistema operativo que suelo usar, tanto para máquinas virtuales como para máquinas físicas. Cuando necesito hacer un despliegue, solo tengo que realizar copias de esos VHDs de referencia a las ubicaciones donde se van a instalar las máquinas virtuales, o a las carpetas donde vamos a almacenar los discos correspondientes a los arranques nativos de la máquina física.
Estos VHD maestros, o de referencia, no son más que un volcado del DVD de instalación a un disco virtual, de tal manera que, cuando se arrancan por primera vez ,se ejecuta el Setup sobre la misma partición, y en pocos minutos tenemos nuestra instalación terminada. La última vez que enseñé esto a alguien, hemos tardado 10 minutos en crearnos una máquina virtual y tenerla funcionando desde cero.
Requisitos
Antes de empezar a crear nuestros VHDs maestros es necesario que tengamos a mano los elementos que nos ayudarán a construirlos. Además, parte de los procedimientos que se describen en este artículo los tenemos que realizar en Windows 7, Windows Server 2008 R2, o las versiones de Windows PE correspondientes a estos (como las que se usan durante la instalación, por ejemplo), ya que los sistemas operativos anteriores no soportan el manejo de VHDs. Estas son las herramientas necesarias y que debemos obtener o instalar previamente:
El AIK y el complemento del AIK se descargan en formato .iso, por lo que tenemos dos opciones a la hora de instalarlos, o bien los grabamos en un DVD o usamos cualquier herramienta que sea capaz de abrir este formato, como WinRAR, PowerISO o similares. Se puede incluso usar una máquina virtual que tengamos funcionando, mapeamos la imagen .iso y el disco donde se quiera dejar el contenido y realizamos la copia. Está claro que este método es más complejo pero si ya lo tenemos montado nos ahorramos la instalación de herramientas adicionales. Bueno, confieso que es el que suelo usar yo. 
El AIK sigue un proceso de instalación como el de cualquier otra aplicación, pero el Complemento del AIK para el SP1 es simplemente un refresco de la imagen de Windows PE contenida en el AIK para Windows 7. La instalación de este complemento consiste en la copia directa a la ruta correspondiente del AIK, sobrescribiendo la versión anterior. Por ejemplo, si nuestro DVD (o ruta donde está montado el .iso) del Complemento, es la unidad D: y el AIK lo tenemos instalado en la unidad C: en “Program Files”, este es el ejemplo del comando que tendríamos que lanzar:
xcopy E:\ "C:\Program Files\Windows AIK\Tools\PETools" /ERDY
Creación del VHD
Este es el primer paso en la ceación de nuestros VHDs maestros, para ello usaremos discos dinamicos, debido al menor espacio ocupado y a la flexibilidad, ya que en cualquier momento se pueden convertir en discos de tamaño fijo. Tenemos dos metodos para crear nuestros VHDs, usando la consola de gestión de discos (diskmgmt.msc), o la herramienta de línea de comando (diskpart).
Los VHDs que creamos para las máquinas virtuales y para arranques nativos del sistema operativo son algo distintos. Los primeros suelen tener la partición de arranque, que se suele crear de forma automática, con un tamaño de 100MB, durante el proceso de instalación, y la de sistema operativo. En el caso de los discos para arranques nativos, estos solo pueden contener una partición, la partición de arranque suele estar en el disco físico.
Los dos formatos de VHD
Como tenemos dos herramientas distintas para crear los discos y dos esquemas de particiones, según el uso que se le vaya a dar a los VHDs, usaremos los dos procesos, uno por cada tipo de VHD.
Empecemos por el VHD maestro para arranques nativos, el que solo puede contener una partición, este lo vamos a crear a través de la consola de gestión de discos. El proceso sería el siguiente:
- En el menú “Action” seleccionar “Create VHD”.
- Introducir la ruta donde vamos a guardar el fichero, el tamaño máximo y seleccionar el tipo de disco virtual “Dynamically Expanding”.
- Inicializar el disco con la opción “Initialize Disk, en el menú contextual
- Seleccionar el tipo de esquema de particiones.
Nota: Actualmente la opción GPT no funciona para el arranque de máquinas virtuales ya que estas no tienen soporte UEFI
- Creamos la partición de sistema operativo, pulsando botón derecho sobre el espacio libre en disco y seleccionando “New Simple Volume”
- En el asistente de creación de volumen indicamos el tamaño de la partición, la letra de unidad que le asignaremos, los parámetros del sistema de ficheros y el nombre del volumen.
Veamos ahora como crear el segundo VHD maestro a través de la línea de comando, el que vamos a usar para nuestras máquinas virtuales y que contiene las dos particiones: Arranque + Sistema Operativo. El proceso a seguir en este caso es:
- Lanzar la herramienta diskpart desde la línea de comando.
- Crear el fichero VHD, indicando la ruta, el tamaño (en MB) y el tipo.
create vdisk file=”Y:\Windows 2008 R2-VM.vhd” type=EXPANDABLE maximum=20480
- Seleccionar el VHD que acabamos de crear.
select vdisk file=”Y:\Windows 2008 R2-VM.vhd”
- Montar el VHD.
attach vdisk
- Crear y formatear la partición de arranque.
create partition primary size=100
format fs=NTFS label=”Boot”
- Crear y formatear la partición de sistema.
create partition primary
format fs=NTFS label=”Windows 2008 R2”
- Asignar una letra de unidad a la partición de sistema.
assign letter=N
Volcado de la instalación al VHD
El siguiente paso de nuestro proceso consiste en volcar la instalación del sistema operativo a estos discos que acabamos de crear. Para realizar este paso necesitamos una de las herramientas (imagex) que está incluida en el Windows AIK. Esta herramienta también es de línea de comando pero su uso es muy sencillo, la podemos encontrar dentro de la carpeta donde hemos instalado el Windows AIK, en la ruta Windows AIK\Tools\[ x86 | amd64 | ia64 ]. En la última carpeta de la ruta, es importante seleccionar la arquitectura adecuada a la máquina donde estamos ejecutando las herramientas.
- Antes de volcar la imagen del sistema operativo tendremos que averiguar cual es el número de índice correspondiente, dentro del fichero de instalación install.wim. Para ello obtendremos el listado completo de imágenes disponibles en ese .wim con un comando similar al que se encuentra abajo, donde D:\ es la ruta del DVD de instalación:
imagex /info D:\sources\install.wim
La salida generada por este comando es algo similar a esto:
ImageX Tool for Windows
Copyright (C) Microsoft Corp. All rights reserved.
Version: 6.1.7600.16385
WIM Information:
—————-
Path: D:\sources\install.wim
GUID: {e23be84e-072c-446c-98ab-e939c3bc4c60}
Image Count: 8
Compression: LZX
Part Number: 1/1
Attributes: 0xc
Integrity info
Relative path junction
Available Image Choices:
————————
<WIM>
<TOTALBYTES>2809390693</TOTALBYTES>
<IMAGE INDEX="1">
<DIRCOUNT>13558</DIRCOUNT>
<FILECOUNT>61518</FILECOUNT>
<TOTALBYTES>10510643622</TOTALBYTES>
<CREATIONTIME>
<HIGHPART>0x01CB8936</HIGHPART>
<LOWPART>0x389E87CA</LOWPART>
</CREATIONTIME>
<LASTMODIFICATIONTIME>
<HIGHPART>0x01CB894F</HIGHPART>
<LOWPART>0x6332A038</LOWPART>
</LASTMODIFICATIONTIME>
<WINDOWS>
<ARCH>9</ARCH>
<PRODUCTNAME>Microsoftr Windowsr Operating System</PRODUCTNAME>
<EDITIONID>ServerStandard</EDITIONID>
<INSTALLATIONTYPE>Server</INSTALLATIONTYPE>
<HAL>acpiapic</HAL>
<PRODUCTTYPE>ServerNT</PRODUCTTYPE>
<PRODUCTSUITE>Terminal Server</PRODUCTSUITE>
<LANGUAGES>
<LANGUAGE>en-US</LANGUAGE>
<DEFAULT>en-US</DEFAULT>
</LANGUAGES>
<VERSION>
<MAJOR>6</MAJOR>
<MINOR>1</MINOR>
<BUILD>7601</BUILD>
<SPBUILD>17514</SPBUILD>
<SPLEVEL>1</SPLEVEL>
</VERSION>
<SYSTEMROOT>WINDOWS</SYSTEMROOT>
</WINDOWS>
<NAME>Windows Server 2008 R2 SERVERSTANDARD</NAME>
<DESCRIPTION>Windows Server 2008 R2 SERVERSTANDARD</DESCRIPTION>
<FLAGS>ServerStandard</FLAGS>
<HARDLINKBYTES>3530249718</HARDLINKBYTES>
<DISPLAYNAME>Windows Server 2008 R2 Standard (Full Installation)</DISPLAYNAM
E>
<DISPLAYDESCRIPTION>This option installs the complete installation of Window
s Server. This installation includes the entire user interface, and it supports
all of the server roles.</DISPLAYDESCRIPTION>
</IMAGE>
…
<IMAGE INDEX="3">
<DIRCOUNT>13558</DIRCOUNT>
<FILECOUNT>61510</FILECOUNT>
<TOTALBYTES>10511024733</TOTALBYTES>
<CREATIONTIME>
<HIGHPART>0x01CB8936</HIGHPART>
<LOWPART>0x389E87CA</LOWPART>
</CREATIONTIME>
<LASTMODIFICATIONTIME>
<HIGHPART>0x01CB894F</HIGHPART>
<LOWPART>0xE1C3B5F4</LOWPART>
</LASTMODIFICATIONTIME>
<WINDOWS>
<ARCH>9</ARCH>
<PRODUCTNAME>Microsoftr Windowsr Operating System</PRODUCTNAME>
<EDITIONID>ServerEnterprise</EDITIONID>
<INSTALLATIONTYPE>Server</INSTALLATIONTYPE>
<HAL>acpiapic</HAL>
<PRODUCTTYPE>ServerNT</PRODUCTTYPE>
<PRODUCTSUITE>Terminal Server</PRODUCTSUITE>
<LANGUAGES>
<LANGUAGE>en-US</LANGUAGE>
<DEFAULT>en-US</DEFAULT>
</LANGUAGES>
<VERSION>
<MAJOR>6</MAJOR>
<MINOR>1</MINOR>
<BUILD>7601</BUILD>
<SPBUILD>17514</SPBUILD>
<SPLEVEL>1</SPLEVEL>
</VERSION>
<SYSTEMROOT>WINDOWS</SYSTEMROOT>
</WINDOWS>
<NAME>Windows Server 2008 R2 SERVERENTERPRISE</NAME>
<DESCRIPTION>Windows Server 2008 R2 SERVERENTERPRISE</DESCRIPTION>
<FLAGS>ServerEnterprise</FLAGS>
<HARDLINKBYTES>3530139554</HARDLINKBYTES>
<DISPLAYNAME>Windows Server 2008 R2 Enterprise (Full Installation)</DISPLAYN
AME>
<DISPLAYDESCRIPTION>This option installs the complete installation of Window
s Server. This installation includes the entire user interface, and it supports
all of the server roles.</DISPLAYDESCRIPTION>
</IMAGE>
…
</WIM>
- Volcar la imagen deseada con ImageX.
imagex /apply d:\sources\install.wim 3 N:
Opciones de la línea de comandos de ImageX
Preparación del arranque
Llegados a este punto lo único que nos queda por hacer es preparar el VHD para que se pueda arrancar desde el mismo. Este paso solo lo tenemos que realizar si se trata de un VHD maestro para máquinas virtuales.
- Escribir el sector de arranque y el Master Boot Record. Para poder realizar este paso tenemos que asignar previamente una letra de unidad a la partición “Boot” que hemos creado antes. A modo de ejemplo, vamos a suponer que hemos asigando la letra M:.
La herramienta que usaremos para preparar el sector de arranque es bootsect.exe y la podemos encontrar dentro del DVD de instalación del sistema operativo en la carpeta \Boot, o en el Windows AIK en la ruta Windows AIK\Tools\PETools\[ x86 | amd64 | ia64 ], una vez más usaremos la carpeta correspondiente a la arquitectura de la máquina donde se esté ejecutando el comando.
bootsect /nt60 M: /mbr
- Marcar la partición de arranque como activa. Aquí también tenemos dos opciones, o bien lo hacemos a través de la consola de gestión de discos, pulsando el botón derecho sobre dicha partición y seleccionando “Mark Partition as Active”, o bien a través de la línea de comando, usando el diskpart.exe. En este último caso, el comando de diskpart que tendremos que usar es “active”, sin parámetros, por lo que tenemos que tener esa partición seleccionada previamente.
Opciones de línea de comandos de Bootsect
- Finalmente crearemos la información de arranque (BCD), con el comando bcdboot.exe. Este comando lo podemos encontrar dentro de la partición de sistema operativo de nuestro VHD, dentro de la carpeta de Windows, más concretamente en %WINDIR%\System32, o en el Windows AIK en la ruta Windows AIK\Tools\[ x86 | amd64 | ia64 ]. Antes de ejecutar el comando es importante que ambas particiones de nuestro VHD se encuentren montadas y mapeadas con letras de unidad. En nuestro ejemplo tenemos:
- Boot – M:
- Windows 2008 R2 – N:
El comando a ejecutar sería el siguiente, donde el parámetro “/s” especifica la partición de arranque donde se escribirá la información:
bcdboot N:\Windows /s M:
Opciones de línea de comandos de BCDboot
¡Enhorabuena Campeones!
Si habéis logrado realizar todo este proceso os podéis considerar unos verdaderos Maestros de los VHDs. Hemos alcanzado nuestro objetivo de tener imágenes de sistema operativo en VHDs maestros, que nos sirvan para hacer despliegues muy rápidos de máquinas físicas o virtuales.
Está claro que esto lo podemos mejorar más todavía, por ejemplo, automatizando el proceso de Setup de Windows con un fichero de respuestas. Otro aspecto que nos puede ser útil es, automatizar este proceso que hemos realizado, y para ello hay un script que está disponible en MSDN, sí todavía os quedan fuerzas lo podéis probar, se llama wim2vhd.
Windows(R) Image to Virtual Hard Disk (WIM2VHD) Converter
¡Saludos virtuales!
Entradas relacionadas:
Technorati Tags: Windows 7,Windows Server 2008 R2,vhd,Virtual Disk
Los candaditos son buenos, nos transmiten seguridad y nos gusta verlos por todas partes, en el navegador, en las carpetas, y si los tenemos en las unidades de disco (internas y externas) ya es la bomba!
Este post es un relato de mis experiencias con el Bitlocker, y su aplicación en escenarios un poco más complejos, combinando esta tecnología de cifrado con instalaciones del sistema operativo en discos virtuales, cifrado de unidades compartidas entre arranques de Windows 7 y Windows Server 2008 R2 y unidades donde se almacenan máquinas virtuales de Hyper-V.
¿Para qué cifrar?
Este fin de semana, mientras cenaba con una amiga y le enseñaba mi flamante Windows Phone 7, me decía “Wow! Increíble, la cantidad de cosas que llevas en el teléfono. Para ti perder el móvil tiene que ser lo peor de lo peor”. La verdad es que le contesté al segundo: “Pues no te creas, al final todo lo que llevo aquí está salvaguardado en otro sitio. Por ejemplo, la información de mis contactos está toda en el servidor de correo de la empresa (Exchange Server), en Facebook y en Windows Live, mis citas de calendario están en el Exchange y en Windows Live, mis correos están en el Exchange y en Hotmail, y las fotos según las estoy sacando ya se están replicando en Skydrive. Además, tengo el móvil protegido con un código y lo puedo borrar remotamente desde cualquier ordenador”.
Llevando estos conceptos al mundo de los PCs, los que habéis estado en alguno de los eventos de nuestra gira del año pasado, seguro que os acordáis de una historia que contaba Chema acerca de dejar el portátil olvidado en el aeropuerto… El siguiente comentario que hacía, a los que contestaban que al darse cuenta que se les había olvidado el cacharrito salían corriendo como alma que se lleva el diablo, era “Seguro que vosotros no tenéis vuestro ordenado cifrado ni hacéis copias de seguridad”. La historia no es tan descabellada y hace un par de años Dell presentaba un informe (Airport Insecurity: The Case of Lost Laptops) sobre este problema, algunos números de los que salían en dicho informe eran impresionantes.
Los más atentos, seguro que os habéis fijado que cuando Chema hacía la pregunta yo me quedaba callado, calladito! He de confesar que por aquel entonces no cumplía con las buenas prácticas, cosa que se solucionó inmediatamente después de la gira. Quedando las copias de seguridad diarias a cargo de mi Windows Home Server y los mandos de seguridad en manos del Bitlocker. Y todo esto para deciros, que lo más importante es la información, no el dispositivo que utilizamos para acceder a ella, pero para conseguir quitar importancia al dispositivo físico es necesario que se cumplan dos cosas en caso de pérdida o robo:
- Exista un mecanismo de seguridad que no permita ver la información que se encuentra en el dispositivo (en este caso el cifrado Bitlocker).
- Exista una copia de seguridad que nos permita de forma rápida y fácil, recuperar esa información en un nuevo dispositivo.
¿Y por dónde empiezo?
Antes de darle al botón, hay que pensar en la estrategia a seguir para cifrar nuestros equipos, pero sobretodo hay que preparar un plan de recuperación para el día que las cosas vayan por mal camino. Esto implica ver donde, y como, vamos a guardar las claves de recuperación para que estén accesibles cuando las necesitemos. En mi caso, independientemente de que esas claves se guarden en AD (por políticas), o no, yo las estoy guardando en un pendrive. Lógicamente que este está cifrado con Bitlocker To Go y su paradero es secreto de estado. Por otro lado, hay una copia de las claves de recuperación (incluida la del pendrive cifrado) en el Mysite del Sharepoint corporativo, en una biblioteca de documentos que solo tiene permisos para mi usuario. En resumen, hay 3 posibilidades de obtener mis claves de recuperación: 1- Pendrive cifrado, 2- Mysite en Sharepoint, 3- Active Directory.
Uno de los requisitos que verifica el asistente de Bitlocker, es que toda la información de la base de datos de arranque (BCD) para el sistema operativo que se quiere cifrar sea correcta. Por este motivo, es muy recomendable que le echéis un vistacillo con bcdedit, para confirmar que todo es correcto, que las rutas están bien y que apuntan a donde tienen que apuntar. Secciones del BCD que son especialmente importantes: {bootmgr}, {current}, recoverysequence, resumeobject y {memdiag}.
No nos olvidemos que para poder cifrar nuestro disco, es necesario tener una partición no cifrada donde instalar el sistema de arranque (bootmgr). Ahora ya sabéis el motivo por el cual, por defecto, Windows 7 y Windows Server 2008 R2 os crean una pequeña partición de 100MB al principio del disco. 🙂
¿Qué unidad debo cifrar?
Y finalmente llegamos a la pregunta del millón… ¿Es suficiente con cifrar una partición de datos? ¿Debo cifrar la unidad del sistema operativo?
La respuesta a esto, como a tantas otras cosas es “Depende”. Depende de donde guardáis información sensible en vuestros equipos, depende del uso que queréis hacer del sistema de cifrado y depende de lo transparente que queréis que este sea para el usuario. En el caso de las particiones de datos, Bitlocker permite definir una contraseña para acceder a las unidades cifradas (o usar el certificado de una smart card), además de la clave de recuperación que obtenemos al cifrar la unidad. Para que estas unidades se puedan desbloquear de forma automática y transparente para el usuario (sin pedirle contraseñas o elementos adicionales) es necesario que nuestra unidad de sistema operativo también esté cifrada, ya que es en ese volumen que se van a guardar los identificadores necesarios para acceder a los demás volúmenes de datos cifrados.
Otro aspecto a tener en cuenta es si vais a tener varios arranques distintos que acceden a una misma partición de datos, como es mi caso, en estos escenarios no poder contar con el desbloqueo automático es muy engorroso, por lo que la mejor opción pasa por cifrar las unidades de sistema operativo.
Nota: en el caso de los dispositivos extraíbles cifrados con Bitlocker To Go, no tenemos este requisito, aunque la partición de sistema. operativo no esté cifrada podemos seguir guardando la información que nos permite el desbloqueo automático.
Las unidades de sistema operativo cifradas pueden ser desbloqueadas mediante, uno (o una combinación) de 3 mecanismos posibles:
- Clave de arranque guardada en el chip TPM
- Código PIN, que incrementa el nivel de seguridad de la opción anterior
- Clave de arranque guardada en un dispositivo USB externo.
La opción más cómoda es la que usa el chip TPM, ya que no supone un cambio perceptible para el usuario en relación a un sistema no cifrado, el PC arranca como siempre sin necesidad de conectar dispositivos adicionales. En este caso, la recomendación es que se establezca un código PIN de arranque para incrementar la seguridad de la solución. Para aquellos casos en que las máquinas no incorporan un chip TPM, la clave de arranque la tendríamos que guardar en un pendrive que habría que conectar siempre durante el proceso de arranque del sistema operativo.
Mi entorno…
Mi portátil, además de ser mi entorno de escritorio que uso a diario, es a la vez mi máquina de demos, por lo que tengo dos arranques distintos, uno con Windows 7 Ultimate y otro con Windows Server 2008 R2 Enterprise y su maravilloso Hyper-V. Las principales carpetas de mi perfil de usuario, en Windows 7, están redirigidas a una partición de datos, que es también un almacén de máquinas virtuales cuando estoy trabajando con Windows Server 2008 R2. En mi caso estaba claro que esta partición había que cifrarla y que además tenía que estar visible desde cualquiera de las instancias de sistema operativo. Para no entorpecer mi trabajo introduciendo la contraseña cada vez que accedo a esa partición y también porque una buena parte de mi perfil está ahí, lo suyo sería usar el mecanismo de desbloqueo automático, está claro que además tenía que cifrar las unidades de sistema operativo. Mi portátil cuenta con un chip TPM por lo que el desbloqueo de las unidades de sistema durante el arranque iba a ser transparente. Finalmente, y de cara a incrementar la seguridad, no prescindo del uso de un código PIN de arranque…
Esta es la “foto” a nivel de Bitlocker que tengo implementada actualmente:
Hasta aquí todo parece muy fácil, así que ahora sí que la vamos a liar… En mi caso las dos particiones de sistema operativo no son particiones físicas, sino discos virtuales. ¡No me quedaba otra que pisar terreno no soportado!
Cuando tenemos nuestros sistemas operativos instalados en VHDs y tenemos que habilitar Bitlocker nos chocamos con que las dos cosas juntas no están soportadas, como se puede ver en el blog del equipo de virtualización:
“Because of these enhancements to core parts of the system, native VHD boot only works for VHDs containing Windows 7 or Windows Server 2008 R2 and not earlier versions of Windows. Native VHD boot in this release does not support BitLocker, or hibernation (which includes resuming from hibernate).”
http://blogs.technet.com/virtualization/archive/2009/05/14/native-vhd-support-in-windows-7.aspx
“Bitlocker no se puede usar para cifrar el volumen del host que contiene los archivos VHD que se usan para el arranque VHD nativo, y bitlocker no se puede usar en los volúmenes incluidos en un VHD.”
http://technet.microsoft.com/es-es/library/dd799282(WS.10).aspx
¿Y ahora qué? Bueno, que no cunda el pánico… Hibernación, hibernación… Ahí está una característica que no uso, siempre duermo la máquina, así que esto para mí no iba a ser un impedimento. No soportado, no soportado… Aquí ya se me presentaba el dilema “ético”, pero como Evangelista me siento en la obligación de probar esto al límite para contároslo todo, tooodo. Teniendo en cuenta que tengo copias de seguridad diarias de mi portátil, tampoco iba a ser un problemón la recuperación en caso de fallo. Así que puse manos a la obra…
Lo primero, cifrar las unidades de sistema operativo. Este proceso es bastante sencillo con la ayuda del asistente de cifrado de Bitlocker (Panel de Control –> Sistema y Seguridad –> Cifrado de unidad Bitlocker). Tuve que habilitar previamente el chip TPM y asumir el control del mismo, esto requiere un reinicio. En el asistente de Bitlocker también elegí la opción de usar un código PIN, que por defecto no aparece, para que tengamos esta opción disponible en nuestro entorno es necesario habilitar una política previamente (Configuración de ordenador –> Plantillas administrativas –> Componentes de Windows –> Cifrado de unidad Bitlocker –> Unidades de sistema operativo). Teniendo en cuenta el incremento a nivel de seguridad que este mecanismo aporta, habilitar esa política es algo que recomiendo que se haga a nivel de dominio.
Política de AD que permite el uso de PIN de arranque.
Una vez terminado el cifrado de las unidades de sistema operativo (C:) con Bitlocker, las claves correspondientes ya están guardadas en mi chip TPM, ya puedo seguir con el cifrado de las demás unidades, en mi caso la de datos que comparto entre los dos sistemas operativos. El cifrado de estas unidades se hace mediante el mismo asistente del paso anterior, seleccionando la opción de desbloqueo automático. Está claro que esto lo hice desde uno de los sistemas operativos (en mi caso desde Windows 7), con lo cual al arrancar por primera vez con el otro (Windows Server 2008 R2), este no sabía cómo acceder al volumen. No pasa nada, cuando nos pida la contraseña se la damos y además marcamos la opción de desbloqueo automático para que no nos la vuelva a pedir.
¡Et voilá!
¡Tchan, tchaaan!… Todo funcionando perfectamente y sin pasos adicionales para acceder a la información. Así da gusto trabajar de forma segura, uno ni se entera que toda su información por debajo está protegida una vez que la experiencia de usuario es igual a la que tenía antes del Bitlocker, sin necesidad de realizar acciones extra. El PIN inicial para mí no es ninguna molestia, todo lo contrario, es lo que me hace sentir seguro cuando uso mi PC, al igual que el PIN de la tarjeta de crédito cuando voy al cajero, o el del móvil cuando lo enciendo.
Aquí os dejo con la “foto” final de mi sistema, este es el mapa de particiones y discos para que tengáis una idea clara de cómo quedó el resultado final:
Mapa de discos y particiones – “Foto” final
¡Ah! Si os estáis preguntando si bitlocker e Hyper-V son compatibles, por eso de tener los vhds de las máquinas virtuales en una partición cifrada, la respuesta es sí, y además de compatible y soportado es recomendable. (http://www.microsoft.com/downloads/details.aspx?FamilyID=2c3c0615-baf4-4a9c-b613-3fda14e84545&DisplayLang=en). De hecho en mi entorno, incluso las máquinas virtuales que tengo configuradas en Windows Server 2008 R2 con arranque automático, y que están almacenadas en la unidad de datos, se arrancan perfectamente como si el volumen no estuviera cifrado.
¡Acordaros, los candaditos son buenos!
950971312360352120990842840360211712771570202840540400
P.D. – A ver quién es capaz de descifrar lo de arriba… 🙂
Technorati Tags: Windows 7,Windows Server 2008 R2,Hyper-V,Bitlocker
