ES2837523T3 - Aprovisionamiento seguro de sistemas operativos - Google Patents

Aprovisionamiento seguro de sistemas operativos Download PDF

Info

Publication number
ES2837523T3
ES2837523T3 ES17708353T ES17708353T ES2837523T3 ES 2837523 T3 ES2837523 T3 ES 2837523T3 ES 17708353 T ES17708353 T ES 17708353T ES 17708353 T ES17708353 T ES 17708353T ES 2837523 T3 ES2837523 T3 ES 2837523T3
Authority
ES
Spain
Prior art keywords
server
image
operating system
service
public key
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
ES17708353T
Other languages
English (en)
Inventor
Ulrich Mueller
Aleksandr Mikhailovich Gershaft
Christopher W Mccarron
Marwan E Jubran
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Microsoft Technology Licensing LLC
Original Assignee
Microsoft Technology Licensing LLC
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Microsoft Technology Licensing LLC filed Critical Microsoft Technology Licensing LLC
Application granted granted Critical
Publication of ES2837523T3 publication Critical patent/ES2837523T3/es
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/30—Public key, i.e. encryption algorithm being computationally infeasible to invert or user's encryption keys not requiring secrecy
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/60—Software deployment
    • G06F8/61—Installation
    • G06F8/63—Image based installation; Cloning; Build to order
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/44—Program or device authentication
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/57—Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/70—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer
    • G06F21/71—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer to assure secure computing or processing of information
    • G06F21/72—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer to assure secure computing or processing of information in cryptographic circuits
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/70—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer
    • G06F21/78—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer to assure secure storage of data
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0894—Escrow, recovery or storing of secret information, e.g. secret key escrow or cryptographic key storage
    • H04L9/0897—Escrow, recovery or storing of secret information, e.g. secret key escrow or cryptographic key storage involving additional devices, e.g. trusted platform module [TPM], smartcard or USB
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3263—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/12—Details relating to cryptographic hardware or logic circuitry
    • H04L2209/127—Trusted platform modules [TPM]

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Computing Systems (AREA)
  • Mathematical Physics (AREA)
  • Storage Device Security (AREA)
  • Computer And Data Communications (AREA)

Abstract

Un sistema para aprovisionar servidores (104; 302) de manera segura dentro de un entorno informático en la nube (100), el sistema que comprende: uno o más procesadores (914); y una memoria (912), junto con el uno o más procesadores, que tiene instrucciones almacenadas en la misma, que, cuando se ejecutan por el uno o más procesadores, dotan al sistema con un servicio de generación de imágenes (124; 306; 834) para: recibir una notificación de delegación de imagen (122; 318) que identifica un servidor (104; 302) que el servicio de generación de imágenes ha de aprovisionar con una imagen del sistema operativo; generar (326) una imagen del sistema operativo para el servidor; cifrar al menos un volumen del sistema operativo, de la imagen del sistema operativo, utilizando una clave de cifrado de volumen de un mecanismo de cifrado de disco; cifrar la clave de cifrado de volumen utilizando una clave de cifrado protegida que está protegida por el módulo de plataforma de confianza del servidor; y transmitir (328) la imagen del sistema operativo y la clave de cifrado de volumen cifrada al servidor para hacer que el servidor sea aprovisionado con la imagen del sistema operativo; el sistema que comprende además un servicio de administración de servidor seguro (116; 304; 832) configurado para: recibir una solicitud (117; 310) desde el servidor para el aprovisionamiento seguro de un sistema operativo, la solicitud que incluye un identificador del servidor; recuperar una clave pública asociada con un módulo de plataforma de confianza (820, 830) del servidor, en donde la clave pública se recupera de un almacén de datos en el que se almacenó la clave pública antes del despliegue del servidor en una ubicación física actual; autenticar (320) el servidor utilizando la clave pública; en respuesta a una autenticación exitosa del servidor, identificar (316) un servicio de generación de imágenes (124; 306; 834) del entorno informático en la nube en el que delegar la generación de una imagen del sistema operativo; y transmitir la notificación de delegación de imagen (122; 318) al servicio de generación de imágenes identificado para hacer que el servicio de generación de imágenes identificado aprovisione el servidor con una imagen del sistema operativo (130; 328).

Description

DESCRIPCIÓN
Aprovisionamiento seguro de sistemas operativos
Antecedentes
En un sistema informático en la nube, los servidores se pueden extender a través de una amplia área geográfica, incluso globalmente, en un esfuerzo por intentar optimizar el tráfico de red entre el sistema informático en la nube y los usuarios finales del sistema informático en la nube. Si bien algunos de estos servidores están situados dentro de instalaciones que se administran por el operador del sistema informático en la nube y, por lo tanto, se pueden considerar físicamente seguros, otros servidores se pueden situar en instalaciones que se administran por un tercero y, por lo tanto, se pueden considerar que son físicamente inseguros. El aprovisionamiento de servidores dentro de estos entornos físicamente inseguros para dotar a los servidores con un entorno operativo seguro presenta una multitud de problemas complejos que pueden ser difíciles de abordar.
Compendio
Este compendio se proporciona para introducir una selección de conceptos en una forma simplificada que se describen además a continuación en la descripción detallada. Este compendio no se pretende que identifique características clave o características esenciales de la materia objeto reivindicada, ni se pretende que se use de forma aislada como ayuda en la determinación del alcance de la materia objeto reivindicada.
Las realizaciones descritas en la presente memoria incluyen métodos, medios de almacenamiento por ordenador, y sistemas para aprovisionar servidores de manera segura en un entorno informático en la nube. En una realización particular, se puede configurar un servicio de administración de servidor seguro para recibir una solicitud de un servidor para el aprovisionamiento seguro de un sistema operativo. El servicio de administración de servidor seguro puede recuperar entonces una clave pública asociada con un módulo de plataforma de confianza del servidor. En realizaciones, la clave pública se puede recuperar de un almacén de datos en el que se almacenó la clave pública antes del despliegue del servidor en una ubicación física actual. El servicio de administración de servidor seguro puede autenticar el servidor utilizando la clave pública y, en respuesta a una autenticación exitosa, identificar un servicio de generación de imágenes del entorno informático en la nube al que delegar la generación de una imagen del sistema operativo para el servidor. El servicio de administración de servidor seguro puede transmitir entonces una notificación de delegación de imagen al servicio de generación de imágenes identificado para hacer que el servicio de generación de imágenes identificado aprovisione el servidor con una imagen del sistema operativo.
En otra realización particular, un servicio de generación de imágenes de un sistema informático en la nube se puede configurar para recibir una notificación de delegación de imagen que identifica un servidor que el servicio de generación de imágenes ha de aprovisionar con un sistema operativo. El servicio de generación de imágenes puede generar entonces una imagen del sistema operativo para el servidor. Una vez que se ha generado la imagen del sistema operativo, el servicio de generación de imágenes puede cifrar la imagen del sistema operativo utilizando una clave de cifrado de volumen de un mecanismo de cifrado de disco. Además, el servicio de generación de imágenes puede vincular o sellar de manera remota la clave de cifrado de volumen al módulo de plataforma de confianza del servidor. La imagen del sistema operativo cifrada se puede transmitir entonces al servidor para hacer que el servidor sea aprovisionado con la imagen del sistema operativo.
Además, en algunas realizaciones, se puede configurar un servidor para generar la propia imagen del sistema operativo actualizada del servidor. En tales realizaciones, el servidor puede recibir, de un administrador del centro de datos, una indicación de que el servidor se ha de aprovisionar a sí mismo con una imagen del sistema operativo actualizada. En respuesta, el servidor puede crear una imagen de sistema operativo (OS) actualizada y puede aplicar cifrado de disco a la imagen de OS actualizada. El servidor puede sellar entonces una clave de cifrado de volumen utilizada en la aplicación del cifrado de disco en base a los valores de registro de control de plataforma de un estado de sistema esperado del servidor. El servidor también puede generar una imagen del sistema operativo actualizada en el volumen del sistema operativo actualizado; y además puede mover la imagen del OS actualizada a un volumen del sistema operativo en el que reside el sistema operativo actual del servidor.
El documento US 2010/0042992 A1 describe una arquitectura de administración de espacio de trabajo virtual. La arquitectura incluye sistemas cliente, una red y un sistema de administración. El sistema de administración incluye un centro informático y un repositorio de datos. El sistema cliente puede comunicarse de vez en cuando con el sistema de administración a través de la red. Las comunicaciones entre los sistemas clientes y el sistema de administración pueden incluir descargar una copia de un espacio de trabajo del sistema de administración, cargar datos de usuario en el sistema de administración, cargar una imagen de disco del sistema en el sistema de administración, etc. Un administrador puede crear una imagen maestra (o “imagen de disco raíz”) de un espacio de trabajo desde cero o clonando una imagen existente del espacio de trabajo. Entonces, el administrador puede aplicar parches a la imagen maestra, instalar nuevas aplicaciones en la imagen maestra, etc. Habiendo completado tales modificaciones a la imagen maestra, el administrador puede publicar la imagen maestra a una pluralidad de usuarios. Con el fin de asegurar que el proceso de arranque sea un proceso de arranque de confianza, se puede usar el TPM para sellar datos en una configuración de plataforma dada.
El objeto de la presente invención es proporcionar un método y un sistema mejorados para el aprovisionamiento de servidores.
El objeto se logra mediante la materia objeto de las reivindicaciones independientes.
Las realizaciones se definen mediante las reivindicaciones dependientes.
Breve descripción de los dibujos
La presente descripción se describe en detalle a continuación con referencia a las figuras de dibujo adjuntas.
La FIG. 1 es un diagrama de un entorno informático en la nube en el que se pueden emplear diversas realizaciones de la presente descripción.
La FIG. 2 es un diagrama de flujo que representa un flujo de proceso ilustrativo para inicializar un servidor para su despliegue en una fábrica según diversas realizaciones de la presente descripción.
La FIG. 3 es un diagrama de interacción que representa un flujo de proceso ilustrativo para aprovisionar un servidor, según diversas realizaciones de la presente descripción.
La FIG. 4 es un diagrama de interacción que representa un flujo de proceso ilustrativo para actualizar un OS de un servidor, según diversas realizaciones de la presente descripción.
La FIG. 5 es un diagrama de interacción que representa un flujo de proceso ilustrativo para el aprovisionamiento descentralizado de servidores, según diversas realizaciones de la presente descripción.
La FIG. 6 representa un diseño de disco duro de un servidor, según diversas realizaciones de la presente descripción.
La FIG. 7 representa una pluralidad de discos duros de un servidor configurados en un diseño a bandas, según diversas realizaciones de la presente descripción.
La FIG. 8 representa un entorno informático en la nube ilustrativo en el que se pueden implementar las realizaciones de la presente descripción.
La FIG. 9 representa un entorno operativo ilustrativo para implementar las realizaciones de la presente descripción. La FIG. 10 representa un entorno informático distribuido ilustrativo en el que se pueden emplear las implementaciones de la presente descripción.
Descripción detallada
La interconexión de sistemas informáticos ha facilitado los sistemas informáticos distribuidos, tales como los denominados sistemas informáticos “en la nube”. “Informático en la nube” generalmente se refiere a sistemas o recursos para habilitar un acceso de red ubicua, conveniente y bajo demanda a un grupo compartido de recursos informáticos configurables (por ejemplo, redes, servidores, almacenamiento, aplicaciones, servicios, etc.) que se pueden aprovisionar y liberar con un esfuerzo de administración o interacción con el proveedor de servicios reducido. Un modelo en la nube puede estar compuesto por diversas características (por ejemplo, autoservicio bajo demanda, acceso a red amplia, agrupación de recursos, elasticidad rápida, servicio medido, etc.), modelos de servicio (por ejemplo, Software como Servicio (“SaaS”), Plataforma como Servicio (“PaaS”), Infraestructura como Servicio (“IaaS”) y modelos de despliegue (por ejemplo, nube privada, nube comunitaria, nube pública, nube híbrida, etc.).
En un sistema informático en la nube, los servidores se pueden situar dentro de instalaciones físicamente seguras que se administran por un operador del sistema informático en la nube. En tal instalación físicamente segura, el operador del sistema informático en la nube se puede asegurar razonablemente de que un usuario malvado no sea capaz de obtener acceso físico a estos servidores y, por lo tanto, no puede manipular físicamente estos servidores. En un esfuerzo por asegurar la dispersión geográfica de los servicios dentro del sistema informático en la nube, no obstante, los servidores también se pueden situar dentro de instalaciones que se administran por un tercero, más que por el operador del sistema informático en la nube y, por lo tanto, se asume que son físicamente inseguros. En tal instalación físicamente insegura, el operador del sistema informático en la nube no tiene la seguridad de que un usuario malicioso sea incapaz de obtener acceso físico a estos servidores y, por lo tanto, puede necesitar tener en cuenta la posibilidad de tal usuario malvado.
Uno de los pasos para asegurar estos servidores físicamente inseguros es aprovisionar a cada uno de estos servidores con un sistema operativo (OS) digno de confianza. Típicamente, con el fin de instalar un OS digno de confianza en un servidor que se ha de situar dentro de una instalación insegura, el OS inicialmente se aprovisionaría en una instalación físicamente segura y luego se transferiría a la instalación físicamente insegura. Para asegurar la confianza del OS, este aprovisionamiento incluiría instalar primero el OS en un volumen del OS del servidor y luego habilitar el cifrado de disco, tal como, por ejemplo, BitLocker, en el volumen del OS así como en los volúmenes de datos del servidor, mientras que el servidor está en la instalación físicamente segura. El cifrado del disco puede proporcionar un entorno operativo a prueba de manipulaciones protegiendo el OS y los datos en los discos. Además, los procesos de arranque seguro reforzados por microprograma también se pueden habilitar dentro de la instalación físicamente segura para asegurar que los procesos de arranque del servidor no sean manipulados. Una vez que estos servidores se aprovisionan en la instalación físicamente segura, estos servidores se pueden enviar al destino geográfico previsto.
Un problema con el aprovisionamiento descrito anteriormente es que estos servidores pueden languidecer en el envío durante meses antes de llegar finalmente al destino previsto. Durante estos meses intermedios, los parches de software dirigidos a reparar problemas de seguridad con el OS originalmente digno de confianza se pueden omitir haciendo que el OS originalmente digno de confianza ya no sea digno de confianza.
Un mecanismo para intentar instalar un OS digno de confianza que esté actualizado con los parches de software aplicables es aprovisionar de manera remota cada servidor con un OS una vez que el servidor llega al destino previsto. Una vez que se instala el OS, se puede habilitar el cifrado de disco para asegurar el OS. Un problema con este planteamiento, no obstante, es que no se puede asumir que un OS instalado en un disco no cifrado no se haya visto comprometido antes de que se habilite el cifrado de disco. Esto es debido a que un individuo malicioso podría haber comprometido el OS antes de habilitar el cifrado del disco, evitando de este modo eficazmente el cifrado del disco.
A la luz de las consideraciones anteriores, diversas realizaciones de la presente descripción están dirigidas a aprovisionar de manera segura un OS a un servidor remoto que está situado en una instalación físicamente insegura. Con este fin, en una realización de ejemplo particular de la presente descripción, un servidor que se ha de situar dentro de un entorno físicamente inseguro se puede inicializar dentro de un entorno físicamente seguro. Esta inicialización puede comprender inicializar un módulo de cifrado de hardware (por ejemplo, un módulo de plataforma de confianza) del servidor y el almacenamiento de una clave pública asociada con el módulo de cifrado de hardware en una base de datos. El servidor se puede enviar entonces al destino previsto donde, tras encender el servidor, el control del servidor se pasa a un OS de mantenimiento en el servidor. Tal OS de mantenimiento se puede cargar en el servidor de cualquier número de formas (por ejemplo, a través de un proceso de arranque remoto o a través de una imagen del OS de mantenimiento que se instaló en el servidor durante la inicialización tratada anteriormente). El OS de mantenimiento puede solicitar una imagen de OS para el servidor desde un servicio de administración de servidor seguro (SSMS). El SSMS puede, a su vez, delegar la creación de la imagen del OS para el servidor en una instancia de un servicio de generación de imágenes de servidor seguro (SSIS). El SSIS puede generar la imagen del OS adecuada para el servidor y cifrar la imagen del OS utilizando una clave de cifrado de disco asociada con un mecanismo de cifrado de disco del servidor. La clave de cifrado de disco entonces se puede sellar remotamente por el módulo de cifrado de hardware del servidor que se aprovisiona. El OS cifrado se puede transmitir entonces al servidor para su instalación a través de un agente de aprovisionamiento de OS de mantenimiento. Se apreciará que la realización tratada anteriormente está destinada meramente a ilustrar una realización de la presente descripción y no se debería tratar como limitante. Realizaciones adicionales y alternativas a las mismas, se entenderán fácilmente a través de la descripción a continuación.
La FIG. 1 es un diagrama de un entorno informático en la nube 100 en el que se pueden emplear diversas realizaciones de la presente descripción. Se apreciará que el entorno informático en la nube 100 representa solamente una parte de un sistema informático en la nube entero por el bien de la simplicidad y facilidad de explicación. Por tanto, se apreciará que se puede incluir cualquier número de componentes adicionales (por ejemplo, servidores, servicios, instalaciones, etc., adicionales) sin apartarse del alcance de esta descripción.
Como se representa, el entorno informático en la nube 100 incluye ubicaciones físicas de una infraestructura informática en la nube. Estas ubicaciones físicas están representadas por la fábrica 102, la instalación de destino 110 y la instalación físicamente segura 114. Cada una de estas ubicaciones físicas se tratará, a su vez, comenzando con la fábrica 102. La fábrica 102 representa una instalación en la que los servidores (por ejemplo, el servidor 104) se pueden ensamblar inicialmente y/o preparar para su despliegue en otra ubicación física dentro del entorno informático en la nube 100. Aunque no está designado como tal dentro de la representación, se apreciará que la fábrica 102 puede ser una instalación físicamente segura.
Mientras que está en la fábrica 102, el servidor 104 se somete a un proceso de inicialización, como se indica por el bloque 106, para preparar el servidor 104 para su despliegue en el sistema informático en la nube. Durante este proceso de inicialización, se puede inicializar un módulo de cifrado de hardware del servidor 104. Como ejemplo, en una realización, el módulo de cifrado de hardware es un módulo de plataforma de confianza (TPM). Un TPM generalmente incluye una clave de aprobación (EK) embebida que es única para el TPM en el que está embebida la clave de aprobación. Como resultado de la naturaleza única de la clave de aprobación, la clave de aprobación se puede considerar una identidad del TPM. La clave de aprobación de un TPM toma la forma de una clave de cifrado asimétrica. Una clave de cifrado asimétrica utiliza una primera clave para cifrar datos, a la que se hace referencia generalmente como clave pública, y una segunda clave para descifrar datos cifrados, a la que se hace referencia generalmente como clave privada. Por tanto, la clave de aprobación del TPM incluye una parte pública (EKPub) y una parte privada (EKPriv). La EKPriv se mantiene generalmente privada dentro del TPM y, por lo tanto, no se libera fuera del TPM en un esfuerzo para salvaguardar la EKPRiv. No obstante, la EKPub se puede liberar fuera del TPM para ser utilizada para un conjunto prescrito de propósitos, incluyendo, por ejemplo, la autenticación de un servidor en el que se ha instalado el TPM. Por tanto, en algunos casos, el proceso de inicialización llevado a cabo en la fábrica 102 puede incluir la recuperación de la EKPub a partir del TPM. La EKPub se puede almacenar entonces en una base de datos de claves para su uso posterior en el establecimiento de una sesión de comunicación remota, como se describe en mayor detalle a continuación, con el TPM del servidor 104 y para identificar el servidor 104, una vez que el servidor 104 se haya desplegado en el destino previsto. Si bien se describen en la presente memoria realizaciones específicas en referencia a la clave de aprobación de un TPM, se apreciará que se pueden utilizar otro módulo de cifrado de hardware y un equivalente de la clave de aprobación de TPM sin apartarse del alcance de esta descripción.
Un beneficio de almacenar la EKPub para el TPM en la fábrica, como se ha descrito anteriormente, es que la EKPub almacenada se puede utilizar con la confianza de que es verdaderamente la parte pública de la clave de aprobación para el TPM. Además, la EKPub almacenado proporciona la confianza de que este TPM y, por ello, el servidor en el que está instalado el TPM, pertenece al sistema informático en la nube. Por ejemplo, un atacante podría intentar engañar al sistema informático en la nube en el aprovisionamiento de un servidor que no se pretende que sea parte del sistema informático en la nube. Para lograr esto, el atacante podría utilizar un servidor con un TPM comprometido. En tal escenario, el atacante podría desviar la protección proporcionada por el TPM, comprometiendo por ello aspectos del sistema informático en la nube. Estos beneficios se hacen realidad utilizando la EKPub almacenada, en oposición a solicitar la EKPub del TPM una vez que se despliega el servidor. Teniendo este conocimiento a priori de la EKPub, ciertos ataques (por ejemplo, ataque de hombre en el medio (MITMA), ataque de denegación de servicio (DoS), etc.) se pueden evitar o reducir, como se describe en mayor detalle a continuación.
Además de inicializar un módulo de cifrado de hardware del servidor 104 en la fábrica 102, en algunas realizaciones, también se puede instalar un OS de mantenimiento (MOS) durante la inicialización del servidor 104. En otras realizaciones, el MOS se puede cargar una vez que el servidor 104 alcance el destino previsto a través de un proceso de arranque remoto, tal como, por ejemplo, el Entorno de Ejecución Previa al Arranque (PXE) disponible en Intel Corporation de Santa Clara, California. Como se usa en la presente memoria, un MOS es un sistema operativo que se puede cargar completamente en la memoria de un servidor para habilitar la manipulación (por ejemplo, reformateo) del almacenamiento permanente (por ejemplo, un disco duro) que contiene el MOS. Un ejemplo de tal MOS incluye el Entorno de Preinstalación de Windows® (WinPE) disponible en Microsoft Corp. de Redmond, Washington. En las realizaciones, el MOS puede proporcionar la inicialización de diverso hardware, software y/o microprograma del servidor 104 para llevar el servidor a un estado operativo preliminar. En algunas realizaciones, el MOS puede incluir un agente de aprovisionamiento de MOS. El agente de aprovisionamiento de MOS se puede configurar para establecer comunicación con un servicio de administración de aprovisionamiento (por ejemplo, servicio de administración de servidor seguro 116), a través de una red a la que el servidor 104 se acopla comunicativamente en el destino previsto. Tal red puede incluir cualquier combinación de redes cableadas y/o inalámbricas. En las realizaciones, el agente de aprovisionamiento de MOS se puede configurar para administrar aspectos del servidor de aprovisionamiento 104 de manera segura con un sistema operativo como se describe en la presente memoria.
Se observará que, en las realizaciones, la inicialización descrita anteriormente no incluye el servidor de aprovisionamiento 104 con un OS completo, o primario, tal como, por ejemplo, Windows® disponible en Microsoft Corp. de Redmond, Washington. Una razón de esto es que el servidor de aprovisionamiento 104 con un OS primario puede añadir una sobrecarga significativa en la fábrica 102 y también puede requerir refrescos continuos de imagen de la imagen del OS primaria en la fábrica 102, para asegurar que se hayan incorporado las últimas actualizaciones dentro del OS primario. Además, como se ha mencionado anteriormente, el tiempo entre el envío del servidor 104 al destino previsto y el servidor 104 que se arranca en el destino previsto podría ser lo suficientemente grande para que una imagen del OS primario que se aprovisionó en la fábrica 102 que tenga vulnerabilidades de seguridad críticas. Por tanto, un OS primario que se aprovisionó en la fábrica 102 puede que ya no sea digno de confianza en el momento en el que el servidor 104 llega al destino previsto y, por lo tanto, no se puede usar como base para actualizar de manera segura a una imagen del OS actualizada.
Una vez que el servidor 104 se ha inicializado en la fábrica 102, el servidor se puede enviar a un destino previsto (por ejemplo, instalación de destino 110), como se indica por el bloque 108. Se apreciará que el envío del servidor 104 al destino previsto puede incluir un período de tiempo prolongado, por ejemplo, un envío internacional, durante el cual es probable que el servidor 104 languidezca en la aduana mientras atraviesa fronteras internacionales. Además, también se apreciará que el servidor 104 también se podría ver comprometido por un individuo malicioso durante el envío.
Como se ha mencionado anteriormente, el destino previsto (por ejemplo, la instalación de destino) del servidor 104 podría ser una instalación físicamente insegura. Como se usa en la presente memoria, una instalación físicamente insegura se refiere a una instalación que no está sujeta al control del operador del sistema informático en la nube al que se ha de conectar el servidor 104. Una vez que el servidor 104 llega a la instalación de destino 110, el servidor se puede instalar físicamente en la instalación de destino 110, tal como, por ejemplo, uniendo físicamente el servidor 104 a un bastidor de servidores dentro de la instalación de destino 110, acoplando el servidor 104 con una fuente de alimentación, y acoplando el servidor 104 con una red. Una vez instalado, el servidor 104 se puede encender para iniciar un proceso de arranque del servidor 104 (por ejemplo, un proceso de arranque de la interfaz de microprograma extensible unificada (UEFI)). El proceso de arranque del servidor 104 puede habilitar el servidor 104 para, entre otras cosas, iniciar la ejecución del MOS y el agente de aprovisionamiento de MOS mencionados anteriormente. Una vez que el agente de aprovisionamiento de MOS ha comenzado la ejecución, el agente de aprovisionamiento de MOS se puede configurar para enviar una solicitud para el aprovisionamiento de una imagen del OS, como se representa en el bloque 112, a un servicio de administración de servidor seguro (SSMS) 116. Como puede ver, el SSMS 116 está alojado por el servidor 118 y está situado dentro de la instalación físicamente segura 114. Aunque el SSMS 116 se representa como una instancia única instanciada, o alojada, en un único servidor, se apreciará que esto es meramente por simplicidad de representación y que podría haber cualquier número de instancias de SSMS 116 operando dentro del sistema informático en la nube a través de cualquier número de servidores, virtuales o de otro modo. Además, aunque la instalación físicamente segura 114 se representa como una única ubicación, se apreciará que se puede incluir cualquier número de instalaciones físicamente seguras sin apartarse del alcance de la presente descripción. Se apreciará que, cuando se hace referencia a una instalación físicamente segura en la presente memoria, la instalación físicamente segura también se asume que también emplea seguridad de red, de manera que se puede confiar en la instalación en sí misma dentro del sistema informático en la nube.
El SSMS 116 se puede configurar para recibir la solicitud de aprovisionamiento de una imagen del OS del agente de aprovisionamiento de MOS del servidor 104. En respuesta a la solicitud, el SSMS 116 puede seleccionar una instancia de un servicio de generación de imágenes de servidor seguro (SSIS) (por ejemplo, el SSIS 124 alojado por el servidor 126) al que delegar la generación de una imagen del OS para el servidor 104, como se indica en el bloque 120. La selección de la instancia de SSIS por el SSMS se puede basar en cualquier criterio adecuado, o en cualquier combinación de criterios adecuados. Por ejemplo, los criterios se podrían basar en: intereses de balanceo de carga; intereses de ubicación geográfica (por ejemplo, distancia desde la instalación de destino); intereses de proximidad de la red; ancho de banda disponible; disponibilidad de archivos o datos necesarios; estado de parche, etc. Aunque en la realización representada el SSIS 124 está situado dentro de una instalación físicamente segura 114, se apreciará que, en algunas realizaciones, la instancia de SSIS seleccionado se puede situar dentro de un entorno físicamente inseguro. En tales realizaciones, la instancia de SSIS se puede seleccionar en base a un nivel de confianza que el SSMS es capaz de establecer para la instancia de SSIS. El nivel de confianza se podría basar, por ejemplo, en los datos de estado del SSIS seleccionado, que pueden incluir si el servidor en el que está ejecutándose la instancia de SSIS está actualizado con los parches de software aplicables, se ha notificado como robado, está conectado a través de una dirección de red esperada, etc. Además, aunque el SSIS 124 se representa como que está separado del SSMS 116, en algunas realizaciones, el SSMS 116 y el SSIS 124 se pueden combinar en una única instancia de servicio.
En algunas realizaciones, el SSMS 116 se puede configurar para autenticar el servidor 104 antes de gastar recursos en procesar la solicitud de aprovisionamiento. En tales realizaciones, autenticando el servidor 104 antes de gastar recursos en la solicitud de aprovisionamiento, el SSMS 116 puede proteger contra un ataque de denegación de servicio (DoS). Tal ataque de DoS podría incluir una gran cantidad de solicitudes de aprovisionamiento falsas recibidas por el SSMS 116 desde uno o más usuarios maliciosos. A través de este gran número de solicitudes de aprovisionamiento falsas, estos usuarios maliciosos pueden estar intentando inundar el SSMS 116 con un número suficiente de estas solicitudes de aprovisionamiento falsas para hacer que el SSMS 116 sea incapaz de abordar solicitudes legítimas, denegando por ello el servicio del SSMS 116. En las realizaciones, tal autenticación podría utilizar, por ejemplo, la EKPub almacenada previamente.
Una vez que se ha seleccionado una instancia de SSIS, el SSMS 116 puede transmitir (por ejemplo, a través de una red, bus o cualquier otro medio de comunicación adecuado) un mensaje a la instancia seleccionada, el SSIS 124. Tal mensaje, por ejemplo, puede identificar el servidor 104 como objetivo de aprovisionamiento. En respuesta, el SSIS 124 puede recuperar cualquier archivo necesario para generar una imagen del OS objetivo para el servidor 104. Estos archivos se pueden recuperar de un almacén de datos local, un almacén de datos remoto o cualquier combinación de los mismos. Como se usa en la presente memoria, un almacén de datos puede referirse a una base de datos, hoja de cálculo, archivo plano, archivo delimitado o cualquier otro mecanismo que organice datos dentro de un archivo o repositorio para su recuperación. Una vez que se han recuperado los archivos necesarios para la imagen del OS objetivo, el SSIS 124 puede generar una imagen del OS a partir de estos archivos, como se indica por el bloque 128. Para lograr esto, en algunas realizaciones, el SSIS puede crear primero un archivo de disco duro virtual (VHD) que incluye una partición para un volumen del OS en el que situar la imagen del OS. Tal archivo de VHD también puede incluir particiones para un volumen de interfaz de microprograma extensible (EFI), una partición para un volumen del OS de mantenimiento, etc. El cifrado de disco entonces se podría aplicar a la imagen del OS para crear una imagen del OS cifrada (por ejemplo, dentro del volumen del OS del archivo de VHD tratado anteriormente). Se apreciará que el archivo de VHD tratado anteriormente está destinado meramente a ser ilustrativo de un posible mecanismo de entrega y que cualquier otro mecanismo de entrega adecuado se contempla explícitamente en la presente memoria.
En alto nivel, el cifrado de disco (por ejemplo, BitLocker) típicamente cifra un volumen de disco usando una clave simétrica, a la que se hace referencia generalmente como clave de cifrado de volumen, junto con algoritmos de cifrado de bloque (por ejemplo, estándar de cifrado avanzado (AES)). Tal clave de cifrado de volumen se puede generar en el SSIS. La seguridad de la clave de cifrado de volumen puede ser importante para mantener la seguridad del volumen del OS cifrado debido a que se puede utilizar una clave simétrica tanto para el cifrado de datos como para el descifrado de datos cifrados con la clave simétrica.
Además de las consideraciones anteriores, el servidor 104 necesita ser capaz de acceder a la clave de cifrado de volumen utilizada en la producción del volumen del OS cifrado con el fin de descifrar el volumen del OS cifrado. En un esfuerzo por proteger la clave de cifrado de volumen y habilitar al servidor 104 para acceder a la clave de cifrado de volumen, el SSIS 124 puede utilizar una clave pública del TPM del servidor 104 para cifrar la clave de cifrado de volumen, vinculando de este modo la clave de cifrado de volumen al TPM del servidor 104. En algunas realizaciones, tal clave pública, junto con la parte privada de la clave, se podría generar y almacenar en el TPM en la fábrica 102. En tales realizaciones, el SSIS 124 no necesita depender de ninguna información proporcionada por el servidor 104, distinta de la información de identificación proporcionada originalmente. Por tanto, la utilización de una clave pública almacenada puede evitar que un usuario malicioso sea capaz de proporcionar una clave pública falsa en un esfuerzo por comprometer el servidor 104, y posiblemente el resto del sistema informático en la nube, montando un ataque de hombre en el medio (MITMA). Esto puede ser necesario en la realización representada debido a que la instalación de destino 110 en la que se sitúa el servidor 104 puede no ser una ubicación físicamente segura.
No obstante, en algunas realizaciones, la vinculación de la clave de cifrado de volumen al TPM del servidor 104 por sí misma puede no proporcionar suficiente seguridad. Esto es debido a que un atacante con acceso físico al servidor 104 podría usar el Tp M para descifrar la clave de cifrado de volumen y obtener acceso al volumen del OS cifrado. Una capacidad extra proporcionada por un TPM es medir componentes clave tales como microprograma ejecutado, configuración de microprograma y un cargador de arranque del OS del servidor 104 y almacenar estas mediciones en los Registros de Configuración de Plataforma (PCR) del TPM. En algunas realizaciones, para proporcionar seguridad adicional, la clave de cifrado de volumen se puede sellar al TPM del servidor 104. Para lograr esto, el SSIS 124 puede establecer una sesión remota con el TPM del servidor 104 y puede utilizar esta sesión para hacer que el TPM del servidor 104 selle de manera remota la clave de cifrado de volumen en base a valores de PCR seleccionados. En el sellado de la clave de cifrado de volumen al TPM del servidor 104, los valores de PCR seleccionados actúan como una condición para descifrar la clave de cifrado de volumen con el fin de cargar el volumen del OS cifrado. Tales realizaciones pueden evitar eficazmente el acceso del volumen del OS cifrado a menos que los valores de PCR del TPM del servidor 104 coincidan con los valores de PCR designados. Como ejemplo, los registros por defecto usados por BitLocker para su uso con Arranque Seguro de UEFI son el PCR [7] y el PCR [11].
Cuando se sella la clave de cifrado de volumen, los valores esperados para los registros de PCR seleccionados se designarían por el SSIS 124 en el momento de generar la imagen del SO. Debido a que el MOS del servidor 104 puede no ser considerado digno de confianza en el momento del proceso de aprovisionamiento representado, puede no ser deseable solicitar las mediciones de PCR del TPM del servidor 104 para determinar los valores de PCR esperados. Esto es debido a que se podrían proporcionar valores de PCR falsos por un usuario malicioso. Por tanto, en algunas realizaciones un servidor de referencia que está configurado de manera similar al servidor 104, al menos con respecto a cualquier componente medido para los registros de PCR seleccionados (por ejemplo, microprograma UEFI, cargador de arranque, etc.), se puede utilizar para determinar los valores de PCR esperados. Tal servidor de referencia se podría situar dentro de la instalación físicamente segura 114 u otra instalación físicamente segura (por ejemplo, centro de datos, laboratorio de pruebas o cualquier otra ubicación bajo el control físico del operador del sistema informático en la nube). Estos valores de registro esperados se pueden almacenar en un almacén seguro (por ejemplo, el Almacén de Datos de PCR 836 de la FIG. 8) y pueden necesitar ser actualizados cada vez que se introduce un nuevo componente de hardware en el sistema informático en la nube. Debido a que se espera que las mediciones del PCR [7] sean sustancialmente independientes de la versión de microprograma particular del servidor en el que se miden, bajo circunstancias normales, el registro del PCR [7] puede ser un proceso de una sola vez por componente de hardware.
Para realizar el sellado remoto tratado anteriormente, el SSIS 124 puede comunicarse con el TPM a través del agente de aprovisionamiento de MOS del servidor 104. El SSIS 124 puede utilizar una ejecución de comando remota frente al TPM del servidor 104 para enviar mensajes al agente de aprovisionamiento de MOS. Estos mensajes son mensajes de paso a través de TPM que el agente de aprovisionamiento de MOS envía directamente al TPM. El TPM procesa tales mensajes y devuelve respuestas al agente de aprovisionamiento de MOS que devuelve esa respuesta al SSIS 124. Esta disposición permite que el SSIS 124 use directamente el TPM del servidor 104.
En las realizaciones, el servicio de generación de imágenes establece una sesión de autorización aleatorizada con el TPM del servidor 104. En este caso, el servidor de generación de imágenes conoce la EKPub del TPM del servidor 104 y conoce que ésta es una EKPub válida debido a que se almacenó previamente durante la inicialización del servidor en el bloque 106. El SSIS 124 puede usar la clave de aprobación del TPM como el cifrador aleatorizado para la nueva sesión conociendo que solamente ese TPM del servidor 104 podría usar correctamente los mensajes resultantes. Una vez que se establece la sesión de autorización, el SSIS 124 emite un comando al TPM del servidor 104 para sellar la clave de cifrado de volumen para los valores de PCR anticipados para el servidor 104.
En otras realizaciones, se pueden utilizar PCR adicionales o alternativos para sellar la clave de cifrado de volumen. Por ejemplo, el PCR [1] se podría utilizar para asegurar una cierta configuración del BIOS, así que cualquier cambio en la ajustes del BIOS en comparación con el servidor de referencia evitaría que se arranque el OS primario de un servidor. Esto podría ayudar a mitigar algunos vectores de ataque, por ejemplo, deshabilitando los puertos de I/O no usados en la configuración del BIOS.
En algunas realizaciones, se puede incluir un servicio de generación de imágenes con la imagen del OS objetivo para habilitar al servidor 104 para realizar una actualización automática, como se describe en referencia a la FIG. 4, o para generar una imagen para otro servidor par, como se describe en referencia a la FIG. 5.
Una vez que se ha generado la imagen del OS objetivo, la imagen del OS con el cifrado de disco aplicado al volumen del OS se puede transmitir al servidor 104 en la instalación de destino 110. Una vez que la imagen del OS llega al servidor 104, el servidor 104 puede extraer la imagen del OS de una manera similar a la descrita en referencia al bloque 426 de la FIG. 4 y volver a arrancar para completar la instalación.
La FIG. 2 es un diagrama de flujo que representa un flujo de proceso 200 ilustrativo para inicializar un servidor para su despliegue en una fábrica (por ejemplo, la fábrica 102 de la FIG. 1), según diversas realizaciones de la presente descripción. Partes del flujo de proceso 200 (por ejemplo, los procesos representados por los bloques 204-210) se pueden llevar a cabo mediante un proceso de inicialización automatizado realizado en la fábrica para preparar los servidores para su despliegue en los sistemas informáticos en la nube. Como se representa, el flujo de proceso 200 comienza en el bloque 202 donde un servidor se recibe en la fábrica. Una vez que el servidor se recibe en la fábrica, en el bloque 204 se puede inicializar en el servidor un módulo de plataforma de confianza (TPM), o cualquier otro módulo de cifrado de hardware.
Como se ha mencionado anteriormente, un TPM generalmente incluye una clave de aprobación (EK) embebida que es única para el TPM en el que está embebida la clave de aprobación. La clave de aprobación incluye una parte pública (EKPub) que está disponible para su uso fuera del TPM para un conjunto de servicios prescritos y una parte privada (EKPriv) que está asegurada dentro del TPM. En el bloque 206, la EKPub del TPM se puede recuperar del TPM. En el bloque 208, la EKPub se puede almacenar en una base de datos de claves (por ejemplo, el almacén de datos de claves de TPM 838 de la FIG. 8) para su uso posterior en el establecimiento de una sesión de comunicación autenticada con el TPM del servidor, una vez que el servidor se haya desplegado en el destino previsto.
Un beneficio de almacenar la EKPub para el TPM en la fábrica, como se ha descrito anteriormente, es que la EKPub almacenada se puede utilizar con la confianza de que es verdaderamente la parte pública de la clave de aprobación para el TPM. Esto es en oposición a solicitar la EKPub del TPM una vez que se despliega el servidor. Tener la EKPub del TPM almacenada antes del despliegue del servidor puede ayudar en la reducción o eliminación de ciertos ataques (por ejemplo, ataque de hombre en el medio (MITMA), ataque de denegación de servicio (DoS), etc.).
En el bloque 210, se instala en el servidor un OS de mantenimiento (MOS) (por ejemplo, WinPE) junto con un agente de aprovisionamiento de MOS. En las realizaciones, el MOS puede proporcionar la inicialización de diverso hardware, software y/o microprograma del servidor para llevar el servidor a un estado operativo preliminar. El agente de aprovisionamiento de MOS se puede configurar para establecer comunicación con un servicio de administración de aprovisionamiento (por ejemplo, el servicio de administración de servidor seguro 116 de la Figura 1). En las realizaciones, el agente aprovisionamiento de MOS se puede configurar para administrar aspectos del aprovisionamiento de manera segura del servidor con una imagen del OS una vez que el servidor se enciende en el destino previsto.
La FIG. 3 es un diagrama de interacción que representa un flujo de proceso 300 ilustrativo para aprovisionar un servidor, según diversas realizaciones de la presente descripción. Como se puede ver, el diagrama de interacción representa la interacción de tres entidades, un servidor 302, un servicio de administración de aprovisionamiento 304 (por ejemplo, el SSMS 116 de la FIG. 1), y un servicio de generación de imágenes 306 (por ejemplo, el SSIS 124 de la FIG. 1). El flujo de proceso 300 puede comenzar en el bloque 308, donde el servidor 302 se arranca en un OS de mantenimiento (MOS). En las realizaciones, el MOS puede proporcionar la inicialización de diverso hardware, software y/o microprograma del servidor 302 para llevar el servidor 302 a un estado operativo preliminar. Este aprovisionamiento puede ser un aprovisionamiento inicial de un servidor o un aprovisionamiento de un servidor después de la sustitución de hardware (por ejemplo, un disco duro) para actualización o mantenimiento.
En el bloque 310, el MOS del servidor 302, o un agente de aprovisionamiento de MOS del servidor 302, puede enviar una solicitud de acción al servicio de administración 304. En realizaciones donde el flujo de proceso 300 es un aprovisionamiento inicial del servidor 302 en una instalación de destino (por ejemplo, la instalación de destino 110) la solicitud de acción 310 puede ser simplemente una solicitud de aprovisionamiento de un OS primario para el servidor 302. En otras realizaciones donde el servidor 302 ya se ha aprovisionado con un OS primario, la solicitud de acción del bloque 310 puede ser una comprobación de estado que se realiza regularmente por el MOS del servidor 302 tras el arranque del servidor 302. En las realizaciones, la solicitud de acción incluye un identificador del servidor 302 para habilitar el servicio de administración 304 para identificar diversa información de estado asociada con el servidor 302. En tal realización, el identificador podría ser cualquier identificador único incluyendo, pero no limitado a, una parte pública de una clave (por ejemplo, EKPub) del TPM del servidor 302. La solicitud de acción 310 se puede enviar al servicio de mantenimiento 304 en cualquier protocolo adecuado (por ejemplo, protocolo de terminal de hipertexto (HTTP)) sobre cualquier conexión de red adecuada (por ejemplo, Internet).
En el bloque 312, el servicio de administración 304 puede autenticar el servidor 302. En las realizaciones donde el identificador único es la EKPub del TPM del servidor 302, esto se puede lograr verificando la EKPub frente a una base de datos de EKPub conocidas. Como nivel de autenticación adicional o alternativo, en algunas realizaciones, el servicio de administración 304 puede realizar una autenticación de desafío-respuesta del servidor 302. Esto se puede lograr cifrando un mensaje utilizando una clave pública conocida de un par de claves pública-privada protegido por el TPM del servidor 302 y transmitiendo el mensaje cifrado al servidor 302, como desafío. Si el servidor 302 puede descifrar el mensaje y devolver el mensaje descifrado en respuesta al desafío, entonces el servicio de administración 304 puede sentirse sustancialmente seguro en el sentido de que el servidor identificado dentro de la solicitud de acción 310 es verdaderamente el servidor 302.
En el bloque 314, el servicio de administración 304 puede comprobar un estado del servidor 302. Esta comprobación de estado se puede basar en el identificador del servidor 302 que se incluyó dentro de la solicitud de acción 310. Tal comprobación de estado puede incluir, por ejemplo, determinar si el servidor 302 se ha notificado como robado; si el servidor 302 está conectándose usando una dirección IP esperada para determinar, por ejemplo, que el servidor 302 no se ha reubicado inesperadamente; o cualquier otra comprobación de estado adecuada. Además, el servicio de administración 304 también podría realizar un testimonio de ordenador central para asegurar que el OS del servidor 302 está en un buen estado conocido. Además, un TPM también puede incluir capacidades tales como el testimonio remoto que se puede utilizar para confirmar un estado del servidor 302. El testimonio remoto crea una clave de comprobación aleatoria casi infalsificable resumen del hardware y software del servidor. Tal sistema puede permitir que un tercero verifique que el software no se ha cambiado.
En el bloque 316, si el estado del servidor determinado en el bloque 314 es satisfactorio (por ejemplo, el servidor 302 no se ha notificado como robado), el servicio de administración 304 puede seleccionar una instancia de un servicio de generación de imágenes en el cual delegar la creación de una imagen del OS para el servidor 302. Se pueden ejecutar instancias de servicios de generación de imágenes en servidores en todo el sistema informático en la nube, tanto en una agrupación local como fuera de la agrupación local. Como se usa en la presente memoria, una agrupación local se refiere a un conjunto de servidores usados con propósitos de administración dentro del sistema informático en la nube. En algunas realizaciones, podría haber cualquier número de agrupaciones locales en todo el sistema informático en la nube que esencialmente dividen el sistema informático en la nube. La selección de la instancia del servicio de generación de imágenes se puede basar en cualquier criterio adecuado o en cualquier combinación de criterios adecuados. Por ejemplo, los criterios se podrían basar en: intereses de balanceo de carga/programación; intereses de ubicación geográfica (por ejemplo, distancia desde la instalación de destino); proximidad de la red; ancho de banda disponible; disponibilidad de archivos o datos necesarios; etc. En una realización particular, la instancia del servicio de generación de imágenes se selecciona en base a la proximidad geográfica, o la proximidad de la red, al servidor 302. Como se usa en la presente memoria, la proximidad de la red puede incluir cualquier medida de distancia entre dos nodos dentro de una red (por ejemplo, el número de nodos de red intermedios). En tal realización, si no se encuentra una instancia del servicio de generación de imágenes adecuada dentro de una proximidad suficiente, o bien de la red o bien geográfica, del servidor 302, entonces la selección de la instancia de generación de imágenes puede estar por defecto en una instancia de generación de imágenes dentro de la agrupación local del servidor 302.
Una vez que se ha seleccionado una instancia de servicio de generación de imágenes, el servicio de administración 304 puede enviar una notificación de delegación de imagen 318 a la instancia de servicio de generación de imágenes seleccionada, el servicio de generación de imágenes 306. La notificación de delegación de generación de imágenes puede incluir diversa información concerniente a la delegación incluyendo, por ejemplo, cualquier combinación de: un identificador asociado con el servidor 302; un identificador de una versión del OS para la imagen; identificadores de archivos a ser incluidos dentro de la imagen del OS (por ejemplo, un manifiesto); una dirección (por ejemplo, dirección de protocolo de Internet (IP)) para utilizarse en la comunicación con el servidor 302; la EKPub del TPM del servidor 302, etc.
Además, el servicio de administración 304 puede enviar una notificación 320 al servidor 302 de la instancia de servicio de generación de imágenes seleccionada. La notificación 320 puede incluir diversa información concerniente a la delegación de la instancia de servicio de generación de imágenes seleccionada incluyendo, por ejemplo, un identificador asociado con la instancia de servicio de generación de imágenes 306; una dirección (por ejemplo, dirección IP) para utilizarse en la comunicación con el servidor 302, etc.
En el bloque 322, en algunas realizaciones, el servidor 302 puede enviar una solicitud de generación de imágenes al servicio de generación de imágenes 306. Tal solicitud de generación de imágenes también puede incluir un identificador del servidor 302. El identificador del servidor 302 se puede utilizar para, por ejemplo, habilitar el servicio de generación de imágenes 306 para hacer coincidir la solicitud de generación de imágenes 322 con la notificación de delegación de imagen del servicio de administración 304. En otras realizaciones, el servicio de generación de imágenes 306 puede inicializar la comunicación con el servidor 302, en lugar de esperar la solicitud de generación de imágenes del bloque 322. En tal realización, se apreciará que la solicitud de generación de imágenes 322 se podría omitir.
Una vez que la solicitud de generación de imágenes se recibe por el servicio de generación de imágenes 306, el servicio de generación de imágenes 306 puede utilizar la información en la notificación de delegación de imagen 318, o la solicitud de imagen 322, para establecer una sesión de TPM remota con el TPM del servidor 302 en el bloque 324. Para lograr esto, el servidor 302 puede utilizar inicialmente una EKPub del TPM del servidor 302 para autenticar la solicitud de generación de imágenes. En tal realización, la EKPub utilizada por el servicio de generación de imágenes podría ser una EKPub que se almacenó antes del despliegue del servidor 302 en la ubicación física actual del servidor 302 (por ejemplo, el bloque 208 de la FIG. 2). Esto actuaría para asegurar que cualquier mensaje transmitido entre el servicio de generación de imágenes 306 y el servidor 302 se protegería por el TPM del servidor 302, sin depender del servidor 302, que se podría ver comprometido, para proporcionar esta información.
En el bloque 326, el servicio de generación de imágenes 306 genera una imagen del OS objetivo para el servidor 302. El cifrado de disco entonces se aplicaría, utilizando una clave de cifrado de volumen generada por el servicio de generación de imágenes 306, a la imagen del OS para crear una imagen del OS cifrada, de una manera similar a la descrita anteriormente en referencia al bloque 128 de la FIG. 1. Además, la clave de cifrado de volumen se puede proteger sellando la clave de cifrado de volumen al TPM del servidor 302. Esto se puede lograr a través de un comando de sello remoto emitido sobre la sesión remota establecida en el bloque 324. Tal comando de sello remoto se soporta, por ejemplo, por la Especificación de TPM 2.0 establecida por el Grupo Informático de Confianza (Trusted Computing Group) en 2015. Una discusión más detallada de la sesión remota se incluye en referencia a la FIG. 1, anteriormente.
En algunas realizaciones, se puede incluir un servicio de generación de imágenes con la imagen del OS objetivo para habilitar el servidor 302 para realizar una actualización automática, como se describe en referencia a la FIG. 4, o para generar una imagen para otro servidor, como se ha descrito en referencia a la FIG. 5.
Una vez que se ha generado la imagen del OS objetivo en el bloque 326, la imagen del OS objetivo se puede transmitir al servidor 302, como se indica por el bloque 328. Una vez que el servidor 302 ha recibido la imagen del OS objetivo del servicio de generación de imágenes 306, la imagen del OS objetivo se puede extraer en el servidor 302 en el bloque 332, a través de, por ejemplo, el MOS del servidor 302 o el agente de aprovisionamiento de MOS del servidor 302. Este proceso de extracción puede ser similar al proceso descrito con referencia al bloque 426, de la FIG. 4. Después de la extracción de la imagen del OS objetivo, el servidor 302 entonces puede volver a arrancar para completar la instalación de la imagen del OS objetivo.
La FIG. 4 es un diagrama de interacción que representa un flujo de proceso 400 ilustrativo para actualizar un OS de un servidor, según diversas realizaciones de la presente descripción. Como se puede ver, el diagrama de interacción representa la interacción de cinco entidades, un administrador de centro de datos 402, un agente de actualización del OS 404, un servicio de generación de imágenes local 406, un OS de mantenimiento (MOS)/Agente de Aprovisionamiento de MOS 408 y un Agente de Aprovisionamiento de OS/OS actualizado 410. El agente de actualización de OS 404, el servicio de generación de imágenes local 406, el Agente de Aprovisionamiento de MOS/OS de mantenimiento (MOS) 408, y el Agente de Aprovisionamiento de OS/OS actualizado 410, representan entidades que residen en un servidor que se aprovisiona con un OS actualizado (por ejemplo, el servidor 104 de la FIG. 1 o el servidor 302 de la FIG. 3). El flujo de proceso 400 representa una instancia donde el servidor que se actualiza ya se ha aprovisionado inicialmente como se describe en referencia a las FIGS. 1 y 3. Además, el servidor se considera suficientemente de confianza por un servicio de administración de aprovisionamiento (por ejemplo, el SSMS 116 de la FIG. 1 o servicio de administración 306 de la FIG. 3), de una manera similar a la descrita en referencia a los bloques 312 y 314 de la FIG. 3. Se apreciará que, en algunas realizaciones, una interacción inicial entre el servidor que se actualiza y el servicio de administración, similar a la descrita en referencia a los bloques 308-316 de la FIG. 3, puede haber ocurrido antes del bloque 412 o entre los bloques 412 y 414. En tal realización, el servicio de generación de imágenes local 406 correspondería con el servicio de generación de imágenes delegado determinado en el bloque 316 de la FIG. 3.
El flujo de proceso 400 puede comenzar en el bloque 412, donde el administrador del centro de datos 402 transmite (por ejemplo, a través de una red) un desencadenador de actualización. El desencadenador de actualización se puede configurar para hacer que el agente de actualización del OS 404 del servidor inicie la actualización del OS en el servidor. En algunas realizaciones, el desencadenador de actualización puede incluir, por ejemplo, un listado (por ejemplo, manifiesto) de los archivos que se necesitan para generar una imagen del OS actualizada y/o una ubicación de dónde se pueden obtener esos archivos. En el bloque 414, el agente de actualización del OS 404 puede recuperar los archivos del OS actualizados o los archivos necesarios para actualizar la imagen del OS actual.
Una vez que se recuperan estos archivos, en el bloque 416, el control se puede transferir a un servicio de generación de imágenes local 406 que reside en el servidor que se actualiza. En el bloque 418, el servicio de generación de imágenes local 406 puede utilizar los archivos del OS actualizados recuperados por el agente de actualización del OS 404 para generar una imagen del OS local actualizada. El cifrado de disco se aplicaría entonces a la imagen del OS para crear una imagen del OS cifrada, de una manera similar a la descrita en referencia al bloque 326 de la FIG. 3. En al menos una realización, el servicio de generación de imágenes 406 puede crear primero un archivo de disco duro virtual (VHD) en una parte no cifrada de un disco duro local del servidor que se actualiza. Este archivo de VHD puede incluir una partición para el volumen del OS. Tal archivo de VHD también puede incluir particiones para un volumen de interfaz de microprograma extensible (EFI), una partición para un OS de mantenimiento, etc. En otras realizaciones, la imagen del OS se puede almacenar en cualquier ubicación del disco local (por ejemplo, una partición de disco nativo). Además, como se ha mencionado anteriormente, en algunas realizaciones, para proporcionar seguridad adicional, la clave de cifrado de volumen se puede sellar de manera remota por el TPM del servidor, como se describe en referencia al bloque 326 de la FIG. 3. En algunas realizaciones, los valores de PCR esperados usados en el sellado de la clave de cifrado de volumen se pueden establecer en base a los valores de PCR de un estado del sistema esperado del servidor. En otras realizaciones, los valores de PCR se podrían predecir para cambios particulares (por ejemplo, utilizando un almacén de datos de PCR u otro mecanismo que pueda correlacionar cambios del sistema particulares con los valores de PCR esperados). Por ejemplo, el nuevo OS podría utilizar un cargador de arranque diferente que daría lugar a cambios en algunos valores de PCR. En tal ejemplo, la clave de cifrado de volumen se podría sellar a los valores de PCR predichos para el sistema en base al cargador de arranque diferente.
En el bloque 420, una vez que el servicio de generación de imágenes local 406 ha generado la imagen del OS local actualizada, el servicio de generación de imágenes local 406 puede notificar al agente de actualización del OS 404 que está lista la imagen del OS local actualizada. En algunas realizaciones, esta notificación puede incluir una ubicación de la imagen del OS local actualizada dentro de los discos duros del servidor que se actualiza. En respuesta a la notificación en el bloque 420, el agente de actualización del OS puede establecer un archivo de marcador para un MOS del servidor que se actualiza, en un esfuerzo de notificar al MOS la ubicación de la imagen del OS. Una vez que se establece el archivo de marcador, el agente de actualización del OS puede hacer que el servidor vuelva a arrancar.
Tras volver a arrancar, el control del servidor se puede transferir desde el Agente de Actualización del OS 404 al agente de aprovisionamiento de MOS/MOS 408 del servidor. El agente de aprovisionamiento de MOS/MOS 408 puede recuperar el archivo de marcador que se estableció en el bloque 420. El archivo de marcador entonces se puede utilizar para identificar la ubicación de la imagen del OS generada en el bloque 418. El MOS puede, en algunas realizaciones, copiar, por ejemplo, a través de una copia en modo bit, la imagen del OS en un volumen del OS local del disco duro del servidor, sustituyendo de este modo el OS anterior con el OS actualizado. Una copia en modo bit generalmente se refiere a copiar un archivo bit a bit para asegurar una copia exacta del archivo. En otras realizaciones, la imagen del OS actualizada se puede generar en un formato desde el que se pueda arrancar directamente. Por ejemplo, algunos entornos operativos soportan el arranque desde un VHD directamente. En otras realizaciones más, la imagen del OS actualizada puede residir en una partición nativa y el MOS puede cambiar meramente el orden de arranque para hacer referencia a esta partición nativa. Este cambio podría ser de naturaleza temporal, al menos al principio, para permitir volver al OS anterior en el caso de problemas con la imagen del OS actualizada. Además, volviendo a la realización de ejemplo de VHD tratada anteriormente, cualquier volumen de EFI y/o MOS correspondientes, si tales volúmenes están incluidos dentro del archivo de VHD, también se pueden copiar. En el caso de que cualquiera de los tamaños de partición del disco local sea insuficiente, el agente de aprovisionamiento de MOS/MOS 408 puede volver a dividir el disco duro bajo demanda. Se debería señalar, que debido a que el MOS no tendría acceso a la clave de cifrado de volumen, el MOS sería incapaz de desbloquear la imagen del OS cifrada.
Una vez que la imagen del OS actualizada se ha copiado en el disco primario en el bloque 426, el sistema se puede volver a arrancar de nuevo en el bloque 428. Tras la vuelta a arrancar, el control se puede transferir desde el agente de aprovisionamiento de MOS/MOS 408 al agente de aprovisionamiento de Os /OS actualizado, que puede comprobar y preparar los volúmenes de datos del servidor en el bloque 432.
Un paso adicional en el aprovisionamiento de manera segura de un servidor es cifrar los volúmenes de datos. En algunas realizaciones, el cifrado de los volúmenes de datos se puede lograr usando cualquiera de dos planteamientos.
En un primer planteamiento, el cifrado se puede habilitar en los volúmenes de datos durante la inicialización del OS, además, el desbloqueo automático (disponible en BitLocker), o una característica similar de cualquier otra aplicación de cifrado de disco, se puede habilitar en los volúmenes de datos en el OS. Durante el escenario de actualización del OS descrito anteriormente donde un servidor se actualiza a sí mismo, el servicio de generación de imágenes puede inyectar las claves de descifrado para los volúmenes de datos en la imagen del OS recién creada. En tales realizaciones, cuando arranca la imagen del OS recién creada, puede utilizar las claves de descifrado para desbloquear los volúmenes de datos y, en algunas realizaciones, crear nuevos protectores de desbloqueo automático o una característica similar de cualquier otra aplicación de cifrado de disco.
El uso de cifrado de disco (por ejemplo, BitLocker) con un TPM puede tener el efecto secundario de que un servidor puede arrancar en su OS primario si los componentes de arranque no se han modificado. Esto puede exponer una vulnerabilidad a un atacante que tenga acceso físico al servidor debido a que tal atacante puede tener una cantidad infinita de tiempo para encontrar una vulnerabilidad del OS que se ejecuta después de obtener la posesión física del servidor.
Una mitigación de la vulnerabilidad anterior es almacenar las claves de descifrado para los volúmenes de datos fuera del OS en sí mismo. Por tanto, en algunas realizaciones se proporciona una arquitectura en la que el servidor puede recuperar la clave de descifrado correspondiente de los volúmenes de datos de un servicio seguro (por ejemplo, el SSMS 116 de la FIG. 1 o el servicio de administración 304 de la FIG. 3) tras la puesta en marcha después se hayan pasado procedimientos de validación adicionales. Por tanto, en estas realizaciones, el agente de aprovisionamiento de OS, del OS actualizado, se puede configurar para crear una conexión con el servicio de administración tras la puesta en marcha del OS. El servicio de administración puede realizar comprobaciones de políticas para determinar si el servidor es de confianza. Estas comprobaciones de políticas pueden incluir, autenticación del servidor (por ejemplo, en base a la EKPub del TPM del servidor, como se ha descrito anteriormente), determinar si el servidor se ha notificado como robado, determinar si el servidor está conectándose usando una dirección IP esperada, es decir, el servidor no ha sido reubicado inesperadamente; un testimonio remoto utilizando el TPM del servidor, como se ha mencionado anteriormente; etc. En otras realizaciones más, el agente de aprovisionamiento de OS/OS actualizado 410 junto con el servicio de administración podría realizar un testimonio de ordenador central para asegurar que el OS del servidor está en un buen estado conocido.
En algunas realizaciones, las claves de descifrado para los volúmenes de datos se pueden manejar por el agente de aprovisionamiento de OS creando una conexión segura con el servicio de administración, inicialmente en la puesta en marcha, y realizando una autenticación mutua (por ejemplo, certificados autofirmados para el servidor y el servicio de administración).
Si tras la puesta en marcha, los volúmenes de datos no están protegidos actualmente por un mecanismo de cifrado de disco (por ejemplo, en el caso de una instalación por primera vez, recuperación, repartición, etc.), el agente de aprovisionamiento de OS se puede configurar para reformatear los volúmenes, luego habilitar el cifrado de disco, cifrar la clave de descifrado con una clave de cifrado protegida por el TPM para vincular la clave de descifrado al TPM local y enviar la clave de descifrado vinculada al servicio de administración. El servicio de administración puede almacenar la clave cifrada en un almacén seguro (por ejemplo, una base de datos de claves), para su recuperación posterior (por ejemplo, después de la autenticación del servidor como se ha descrito anteriormente).
Si, por otra parte, los volúmenes de datos están protegidos actualmente por un mecanismo de cifrado de disco, el agente de aprovisionamiento de OS puede solicitar las claves cifradas del servicio de administración, descifrar las claves cifradas usando el TPM del servidor y montar los volúmenes.
Volviendo ahora a la FIG. 5, el aprovisionamiento de servidores para un sistema informático en la nube desde una ubicación central puede ayudar a mantener la integridad del sistema informático en la nube; no obstante, la cantidad de ancho de banda que se utiliza por tal escenario puede no ser deseable. Por tanto, en algunas realizaciones, puede ser beneficioso habilitar los servidores que están fuera de la ubicación central, pero dignos de confianza, para aprovisionar servidores que están dentro de una proximidad más cercana, o bien de la red o bien geográfica, a aquellos servidores dignos de confianza (por ejemplo, servidores dentro del mismo bastidor, instalación o dentro de una cierta proximidad geográfica). La determinación de si un servidor es digno de confianza se puede lograr de una manera similar a la descrita en referencia a los bloques 312 y 314 de la FIG. 3. Esto puede ser especialmente beneficioso cuando cada servidor se aprovisiona de manera similar.
La FIG. 5 es un diagrama de interacción que representa un flujo de proceso 500 ilustrativo para el aprovisionamiento descentralizado de servidores, según diversas realizaciones de la presente descripción. Los servidores 1-8 se pueden situar dentro de la misma instalación de destino o entre diferentes instalaciones de destino, pero dentro de una cierta proximidad geográfica o de la red. En una realización particular, cada uno de los servidores 1-8 se puede situar dentro de un único bastidor de servidores. En tal realización, los servidores se considerarían pares dentro del bastidor entre sí. Como se puede ver, el diagrama de interacción representa la interacción de nueve entidades, una agrupación local 502 y los servidores 1-8. Se apreciará que la representación de 8 servidores se selecciona meramente por facilidad de explicación y que se pueden incluir servidores adicionales o menos servidores sin apartarse del alcance de esta descripción.
La primera parte 504 del flujo de proceso 500, representa la agrupación local 502 que recibe una solicitud de imagen desde cada uno de los servidores 1-8. Cada una de las solicitudes de imagen representadas se puede manejar dentro de la agrupación local 502 de una manera similar a la descrita en referencia a la FIG. 3. En respuesta a las solicitudes de imágenes, la agrupación local puede identificar una entidad en la que delegar la generación de imágenes de cada uno de los servidores 1-8. Como se representa dentro de la segunda parte 506 del flujo de proceso 500, las imágenes del OS para los servidores 1 y 2 se generan de una manera centralizada desde dentro de la agrupación local 502.
Cada una de las imágenes del OS puede incluir una instancia de un servicio de generación de imágenes para habilitar cada servidor aprovisionado para aprovisionar entonces los siguientes servidores. Por tanto, una vez que los servidores 1 y 2 han recibido la imagen del OS respectiva, los servidores 1 y 2 se pueden seleccionar entonces por la agrupación local 502 para aprovisionar otros servidores que estén dentro de una proximidad geográfica, o de la red, de los servidores 1 y 2, siempre que los servidores 1 y 2 sigan siendo dignos de confianza. Por tanto, el aprovisionamiento de los servidores 3 y 4 se delega a los servidores 1 y 2, como se representa en la tercera parte 508 del flujo de proceso 500.
De nuevo, cada una de las imágenes del OS puede incluir una instancia de un servicio de generación de imágenes para habilitar a cada servidor aprovisionado para aprovisionar entonces los siguientes servidores. Por tanto, una vez que los servidores 3 y 4 han recibido la imagen del OS respectiva, los servidores 1-4 se pueden seleccionar entonces por la agrupación local 502 para aprovisionar otros servidores que están dentro de una proximidad geográfica, o proximidad de la red, de los servidores 1-4, siempre que los servidores 1-4 sigan siendo dignos de confianza. Por tanto, el aprovisionamiento de los servidores 5-8 se delega a los servidores 1-4, como se representa dentro de la cuarta parte 510 del flujo de proceso 500. Como se puede ver, con cada iteración de imágenes del SO, el número de servicios de generación de imágenes puede duplicarse. Por tanto, si se representaron 16 servidores, entonces los 8 servidores siguientes, los servidores 9-16 (no representados), se podrían aprovisionar por los servidores 1-8 representados.
Se apreciará que, además de aprovisionar inicialmente un OS, las realizaciones descritas anteriormente también se pueden utilizar para instalar de manera segura un OS en un servidor mientras que el servidor tiene instalado un OS existente que no es digno de confianza. Como ejemplo, la generación de imágenes entre la agrupación local y los servidores 1 y 2 puede actuar para devolver esos servidores a un estado digno de confianza. Como otro ejemplo, la generación de imágenes local entre los servidores (por ejemplo, la representada en 508 o 510) también se puede utilizar para devolver un servidor a un estado digno de confianza. El efecto de esto es que, las realizaciones descritas anteriormente se pueden usar para restablecer la confianza en un entorno de servidor en el caso de que un entorno de servidor se haya visto comprometido por una brecha de seguridad (por ejemplo, software malicioso).
Volviendo a la FIG. 6, la FIG. 6 representa un diseño de disco duro 600 de un servidor (por ejemplo, el servidor 104 de la FIG. 1) según diversas realizaciones de la presente descripción. Como se representa, el diseño del disco duro 600 incluye un volumen de EFI 602 en el que puede residir el cargador de arranque del OS. En las realizaciones, el OS de mantenimiento (MOS) (por ejemplo, WinPE) se puede instalar localmente en el disco duro en el volumen de MOS 604. En tales realizaciones, el MOS del servidor se puede configurar en una configuración de arranque dual con el OS primario instalado en el volumen del SO 606. En tales realizaciones, el MOS se puede configurar como el OS por defecto en una configuración de arranque (por ejemplo, datos de configuración de arranque (BCD)) del servidor. En tal configuración, el servidor arrancará inicialmente en el MOS. Una vez que el MOS ha determinado que el OS primario no necesita servicio (por ejemplo, el OS primario está correctamente aprovisionado y actualizado), el MOS puede realizar un arranque de una sola vez en el OS primario. Esta configuración puede asegurar que el MOS se arrancará en caso de que haya cualquier problema con el OS primario. En instancias donde el OS primario hace una acción de reparación de vuelta a arrancar planificada, el OS primario puede configurar la configuración de arranque para realizar un arranque de una sola vez por sí mismo.
En algunas instancias, el servidor podría ser incapaz de arrancar, por ejemplo, si el volumen de arranque de EFI 602 o el volumen de MOS 604 llegan a estar corrompidos, hay un problema físico con el disco duro, o el disco duro se ha sustituido. En el caso de tales instancias, en algunas realizaciones el arranque de red (por ejemplo, arranque de PXE) desde la agrupación local del servidor se puede configurar como una primera opción de arranque para instancias en las que tal arranque de red está disponible. En instancias donde el arranque de red está disponible desde la agrupación local (por ejemplo, a través de VPN, a través del protocolo de terminal de hipertexto seguro (HTTPS) que utiliza UEFI 2.5, etc.), con el fin de proporcionar al MOS local una oportunidad de arrancar primero, un período de gracia durante el cual los servidores que tienen un MOS local durante no intentarán arrancar sobre la red. Tal período de gracia puede ser de corta duración (por ejemplo, del orden de un minuto) aunque la duración puede ser más larga o más corta dependiendo de la configuración. El BIOS de los servidores que tienen una instalación de MOS local se puede configurar para intentar el arranque de red de un MOS primero para habilitar la recuperación de, por ejemplo, una instalación de disco corrompida de otro modo.
El arranque de red desde la agrupación local puede no estar siempre disponible desde la agrupación local del servidor. Por ejemplo, en las instancias de PXE que utilizan un túnel de VPN para conectarse con la agrupación local del servidor, puede que ya no se desee mantener el túnel de VPN y, por lo tanto, se puede eliminar el túnel VPN. En tales realizaciones, un servicio de arranque intermediario que se ejecuta en ubicaciones remotas del sistema informático en la nube puede servir como un retransmisor de MOS. El servicio puede mantener una conexión con la agrupación local del servidor para hacer un seguimiento de los servidores que necesitan ser recuperados. El servicio de arranque de intermediario puede actuar como un servidor MOS para esos servidores y puede proporcionar una imagen de MOS correspondiente. Dependiendo del entorno de red, los servidores pares pueden operar como servidores de protocolo de configuración dinámica de servidor (DHCP) (en caso de que no haya otro servidor de DHCP para responder a las solicitudes de DHCP para estos servidores), o como un servidor de DHCP Intermediario (en caso de que haya un servidor de DHCP en el entorno de red).
La FIG. 7 representa una pluralidad de discos duros 716-722 de un servidor configurado en un diseño a bandas, según diversas realizaciones de la presente descripción. Como se representa, el Volumen D 714a-714d se extiende a través de los discos duros 716-722 disponibles, respectivamente. En los escenarios de instalación descritos anteriormente, se mencionó que, en algunas realizaciones, la imagen del OS se crea en una parte no cifrada del disco duro. Los volúmenes D, E y F pueden ser cualquier otro volumen del servidor y no se tratan con ningún detalle. En el ejemplo representado, el volumen del OS 706 en el primer disco 716 da como resultado espacio en disco en los otros discos que pueden no ser capaces de ser usados por un sistema de administración de disco de un servidor. En tales realizaciones, el diseño de estos volúmenes extra se puede aprovechar reutilizando uno de los volúmenes extra como volumen no cifrado, el volumen de imagen del OS actualizado 712, para almacenar la imagen para la actualización del OS. Para evitar el uso accidental de un volumen no cifrado para datos sensibles, en algunas realizaciones, el volumen de imagen del OS actualizado 712 puede no tener asignada una letra de unidad. Aunque se representan cuatro discos duros, 716-722, se apreciará que este planteamiento puede funcionar para cualquier número de discos duros, mayor que uno. Por ejemplo, si el servidor solamente incluyese el disco duro 716 y 718, el volumen E 718 se podría reutilizar como el volumen de imagen del OS actualizado.
Además, el uso propuesto de una imagen de MOS en el disco duro local puede fallar si hay una corrupción de la imagen de MOS, un fallo completo del disco duro en el que se sitúa la imagen de MOS o una sustitución del disco duro en el que la imagen de MOS se sitúa con un disco vacío. En un esfuerzo por proporcionar una solución más robusta, el diseño de disco 700 se puede reutilizar además proporcionando múltiples volúmenes de MOS 704a-704d, en lugar de meramente incluir un único volumen de MOS 704a en el primer disco 716. Cada uno de los volúmenes de MOS 704b-704d puede incluir un clon del volumen de MOS 704a del primer disco 716. Además, el diseño de disco 700 se puede reutilizar incluso más proporcionando múltiples volúmenes de EFI 702a-702d, en lugar de incluir meramente un único volumen de EFI en el primer disco 716. Cada uno de los volúmenes de EFI 702b-702d puede incluir un clon del volumen de EFI 702a del primer disco 716. Se debería observar que añadir las particiones de EFI y de MOS a todos los discos 716-722 no necesariamente reduce el tamaño de la banda del disco debido a que el volumen D está limitado en tamaño por el tamaño de la banda más pequeña que se determinaría teniendo en cuenta el tamaño del volumen de EFI, el volumen de MOS y el volumen del OS en el disco 716.
La FIG. 8 representa un entorno informático en la nube 800 ilustrativo en el que se pueden implementar realizaciones de la presente descripción. El entorno en la nube 800 incluye el bastidor de servidores 802, la red 804 y la agrupación local 806. La red 804 puede ser cualquier combinación de red cableada y/o inalámbrica. En las realizaciones, el bastidor de servidores 802 puede incluir una parte superior del bastidor (TOR) 808 acoplada comunicativamente con cada uno de los servidores 1-n. La TOR 808 se puede configurar para proporcionar comunicaciones de red entre los servidores 1-n y la agrupación local 806, así como cualquier otro recurso de red. El bastidor de servidores 802 también puede incluir una unidad de distribución de energía (PDU) 810 acoplada eléctricamente con cada uno de los servidores 1-n. La PDU 810 puede proporcionar una fuente de energía a los servidores 1-n para habilitar los servidores 1-n para mantener un estado operativo. Cada uno de los servidores 1-n se representa como que se ha aprovisionado como se ha descrito anteriormente. Por tanto, cada uno de los servidores 1-n incluye un OS primario 812 y 822, un OS de mantenimiento 814 y 824, un servicio de generación de imágenes 816 y TPM 820 y 830. Cada uno de estos componentes se puede configurar para proporcionar la funcionalidad descrita en la presente memoria con respecto a cada uno de estos componentes.
La agrupación local 806 incluye un servicio de administración 832, un servicio de generación de imágenes 834, un almacén de datos de estado de servidor 836, un almacén de datos de claves de TPM 838 y un almacén de datos de PCR 840. El servicio de administración 832 se puede configurar de manera similar al SSMS 116 de la FIG. 1 y al servicio de administración 304 de la FIG. 3. Por tanto, el servicio de administración 832 se puede configurar para administrar el aprovisionamiento seguro de servidores dentro del entorno informático en la nube 800 como se describe en la presente memoria. El servicio de generación de imágenes 834 se puede configurar de una manera similar al SSIS 124 de la FIG. 1 y al servicio de generación de imágenes 306 de la FIG. 3. Por tanto, el servicio de generación de imágenes 834 se puede configurar para generar imágenes del OS (por ejemplo, el OS primario 812 y el OS primario 822) para su despliegue en servidores dentro del entorno informático en la nube 800. El almacén de datos de estado de servidor 836 se puede configurar para almacenar información con respecto a un estado de servidor, tal como, por ejemplo, si el servidor se ha notificado como robado, una dirección IP esperada o un intervalo de direcciones IP que un servidor puede utilizar en la conexión con la agrupación local 806, o cualquier otra información de estado de servidor tratada en la presente memoria. El almacén de datos de claves de TPM 838 se puede configurar para almacenar la EKPub de cada TPM (por ejemplo, el TPM 820 y el TPM 830). Estas EKPub se pueden almacenar en el almacén de datos de claves de TPM 838 de una manera igual o similar a la descrita en la presente memoria. El almacén de datos de PCR 840 se puede configurar para almacenar los valores de PCR esperados con referencias cruzadas con las configuraciones que producirían esos valores de PCR. Tales valores de PCR se pueden utilizar en las operaciones de sellado descritas anteriormente, como se describe en la presente memoria.
Habiendo descrito brevemente una descripción general de las realizaciones de la presente descripción, un entorno operativo ilustrativo en el que se pueden implementar las realizaciones de la presente descripción se describe a continuación con el fin de proporcionar un contexto general para diversos aspectos de la presente descripción. Con referencia inicialmente a la FIG. 9 en particular, se muestra un entorno operativo ilustrativo para implementar realizaciones de la presente descripción y se designa de manera general como dispositivo informático 900. El dispositivo informático 900 es solo un ejemplo de un entorno informático adecuado y no se pretende que sugiera ninguna limitación en cuanto al alcance de uso o funcionalidad de la descripción. Ni se debería interpretar el dispositivo informático 900 como que tiene ninguna dependencia o requisito con relación a uno cualquiera o una combinación de los componentes ilustrados.
La descripción se puede describir en el contexto general del código de ordenador o las instrucciones utilizables por la máquina, incluyendo las instrucciones ejecutables por ordenador, tales como módulos o motores de programa, que se ejecutan por un ordenador u otra máquina, tal como un asistente de datos personal u otro dispositivo de mano. Generalmente, los módulos de programa que incluyen rutinas, programas, objetos, componentes, estructuras de datos, etc. se refieren al código que realiza tareas particulares o implementan tipos de datos abstractos particulares. La descripción se puede poner en práctica en una variedad de configuraciones de sistema, incluyendo dispositivos de mano, electrónica de consumo, ordenadores de propósito general, dispositivos informáticos más especializados, etc. La descripción también se puede poner en práctica en entornos informáticos distribuidos donde las tareas se realizan por dispositivos de procesamiento remotos que se conectan a través de una red de comunicaciones.
Con referencia a la FIG. 9, el dispositivo informático 900 incluye un bus 910 que acopla directa o indirectamente los siguientes dispositivos: una memoria 912, uno o más procesadores 914, uno o más componentes de presentación 916, puertos de entrada/salida 918, componentes de entrada/salida 920 y una fuente de alimentación 922 ilustrativa. El bus 910 representa lo que puede ser uno o más buses (tales como un bus de direcciones, un bus de datos o una combinación de los mismos). Aunque los diversos bloques de la FIG. 9 se muestran con líneas claramente delineadas en aras de la claridad, en realidad, tales delineaciones no son tan claras y estas líneas pueden superponerse. Por ejemplo, uno puede considerar que un componente de presentación, tal como un dispositivo de visualización, sea un componente de I/O también. También, los procesadores generalmente tienen memoria en forma de caché. Reconocemos que tal es la naturaleza de la técnica y reiteramos que el diagrama de la FIG. 9 es meramente ilustrativo de un dispositivo informático de ejemplo que se puede usar en conexión con una o más realizaciones de la presente descripción. No se hace distinción entre tales categorías como “estación de trabajo”, “servidor”, “ordenador portátil”, “dispositivo de mano”, etc., en la medida que todos se contemplan dentro del alcance de la FIG. 9 y de la referencia a “dispositivo informático”.
El dispositivo informático 900 incluye típicamente una variedad de medios legibles por ordenador. Los medios legibles por ordenador pueden ser cualquier medio disponible al que se pueda acceder por el dispositivo informático 900 e incluye medios tanto volátiles como no volátiles, medios extraíbles y no extraíbles. A modo de ejemplo, y no de limitación, los medios legibles por ordenador pueden comprender medios de almacenamiento informático y medios de comunicación.
Los medios de almacenamiento informático incluyen medios volátiles y no volátiles, extraíbles y no extraíbles implementados en cualquier método o tecnología para el almacenamiento de información tal como instrucciones legibles por ordenador, estructuras de datos, módulos de programa u otros datos. Los medios de almacenamiento informático incluyen, pero no se limitan a, RAM, ROM, EEPROM, memoria rápida u otra tecnología de memoria, CD-ROM, discos versátiles digitales (DVD) u otro almacenamiento de disco óptico, casetes magnéticos, cinta magnética, almacenamiento en disco magnético u otros dispositivos de almacenamiento magnético, o cualquier otro medio que se pueda usar para almacenar la información deseada. Los medios de almacenamiento legibles por ordenador excluyen las señales por sí mismas.
Los medios de comunicación incorporan típicamente instrucciones legibles por ordenador, estructuras de datos, módulos de programa u otros datos en una señal de datos modulada, tal como una onda portadora u otro mecanismo de transporte, e incluyen cualquier medio de entrega de información. El término “señal de datos modulada” significa una señal que tiene una o más de sus características establecidas o cambiadas de tal manera que codifique información en la señal. A modo de ejemplo, y no de limitación, los medios de comunicación incluyen medios cableados tales como una red cableada o una conexión cableada directa, y medios inalámbricos tales como medios acústicos, de RF, de infrarrojos y otros medios inalámbricos. Las combinaciones de cualquiera de los anteriores también se deberían incluir dentro del alcance de los medios legibles por ordenador.
La memoria 912 incluye medios de almacenamiento informático en forma de memoria volátil y/o no volátil. Como se representa, la memoria 912 incluye instrucciones 924. Las instrucciones 924, cuando se ejecutan por el procesador o los procesadores 914, están configuradas para hacer que el dispositivo informático realice cualquiera de las operaciones descritas en la presente memoria, en referencia a las figuras tratadas anteriormente. La memoria puede ser extraíble, no extraíble o una combinación de las mismas. Los dispositivos de hardware ilustrativos incluyen memoria de estado sólido, discos duros, unidades de disco óptico, etc. El dispositivo informático 900 incluye uno o más procesadores que leen datos de diversas entidades tales como la memoria 912 o los componentes de I/O 920. El componente o componentes de presentación 916 presentan indicaciones de datos a un usuario u otro dispositivo. Los componentes de presentación ilustrativos incluyen un dispositivo de visualización, altavoz, componente de impresión, componente de vibración, etc.
Los puertos de I/O 918 permiten que el dispositivo informático 900 se acople lógicamente a otros dispositivos que incluyen los componentes de I/O 920, algunos de los cuales pueden estar integrados. Los componentes ilustrativos incluyen un micrófono, palanca de mando, almohadilla de juego, antena parabólica, escáner, impresora, dispositivo inalámbrico, etc.
Con referencia ahora a la FIG. 10, la FIG. 10 ilustra un entorno informático distribuido 1000 ilustrativo en el que se pueden emplear implementaciones de la presente descripción. En particular, la FIG. 10 muestra un sistema de red ilustrativo que comprende una plataforma informática en la nube 1010, donde el sistema soporta el aprovisionamiento del OS seguro descrito anteriormente. Se debería entender que esta y otras disposiciones descritas en la presente memoria se exponen solamente como ejemplos. Se pueden usar otras disposiciones y elementos (por ejemplo, máquinas, interfaces, funciones, órdenes y agrupaciones de funciones, etc.) además de o en lugar de los mostrados, y algunos elementos pueden omitir por completo. Además, muchos de los elementos descritos en la presente memoria son entidades funcionales que se pueden implementar como componentes discretos o distribuidos o junto con otros componentes, y en cualquier combinación y ubicación adecuadas. Diversas funciones descritas en la presente memoria como que se realizan por una o más entidades se pueden llevar a cabo por hardware, microprograma y/o software. Por ejemplo, diversas funciones se pueden llevar a cabo por un procesador que ejecuta instrucciones almacenadas en la memoria.
Los centros de datos pueden soportar el entorno informático distribuido 1000 que incluye la plataforma informática en la nube 1010, el bastidor 1020 y el nodo 1030 (por ejemplo, dispositivos informáticos, unidades de procesamiento o cuchillas) en el bastidor 1020. El sistema se puede implementar con una plataforma informática en la nube 1010 que ejecuta servicios en la nube a través de diferentes centros de datos y regiones geográficas. La plataforma informática en la nube 1010 puede implementar un componente de controlador de estructura 1040 para aprovisionar y administrar la asignación de recursos, despliegue, actualización y administración de servicios en la nube. Típicamente, la plataforma informática en la nube 1010 actúa para almacenar datos o ejecutar aplicaciones de servicio de una manera distribuida. La plataforma informática en la nube 1010 en un centro de datos se puede configurar para alojar y soportar la operación de puntos finales de una aplicación de servicio particular. La plataforma informática en la nube 1010 puede ser una nube pública, una nube privada o una nube dedicada.
El nodo 1030 se puede aprovisionar de una manera similar a los servidores 1-n de la FIG. 8. Por tanto, el nodo 1030 puede incluir un Os primario 1070, un OS de mantenimiento 1072, un servicio de generación de imágenes 1074 y un TPM 1078. Cada uno de estos componentes puede realizar cualquiera de los procesos descritos anteriormente con respecto a cada uno de estos componentes. Además, el nodo 1030 también se puede configurar para realizar una funcionalidad especializada (por ejemplo, nodos de cálculo o nodos de almacenamiento) dentro de la plataforma informática en la nube 1010. El nodo 1030 se puede asignar para ejecutar una o más partes de una aplicación de servicio de un inquilino. Un inquilino puede referirse a un cliente que utiliza recursos de la plataforma informática en la nube 1010. Se puede hacer referencia a los componentes de aplicación de servicio de la plataforma informática en la nube 1010 que soportan a un inquilino particular como infraestructura de inquilino o arrendamiento. Los términos aplicación de servicio, aplicación o servicio se usan indistintamente en la presente memoria y se refieren ampliamente a cualquier software, o partes de software, que se ejecutan en la parte superior de, o acceden a las ubicaciones de dispositivos informáticos y de almacenamiento dentro de, un centro de datos.
Cuando más de una aplicación de servicio separada se está soportando por los nodos 1030, los nodos se pueden dividir en máquinas virtuales. Las máquinas físicas también pueden ejecutar concurrentemente aplicaciones de servicio separadas. Las máquinas virtuales o máquinas físicas se pueden configurar como entornos informáticos individualizados que se soportan por los recursos 1060 (por ejemplo, recursos de hardware y recursos de software) en la plataforma informática en la nube 1010. Se contempla que los recursos se pueden configurar para aplicaciones de servicio específicas. Además, cada aplicación de servicio se puede dividir en partes funcionales de manera que cada parte funcional sea capaz de ejecutarse en una máquina virtual separada. En la plataforma informática en la nube 1010, se pueden usar múltiples servidores para ejecutar aplicaciones de servicio y realizar operaciones de almacenamiento de datos en una agrupación. En particular, los servidores pueden realizar operaciones de datos de manera independiente, pero expuestos como un único dispositivo al que se hace referencia como agrupación. Cada servidor en la agrupación se puede implementar como un nodo.
El dispositivo cliente 1080 puede estar vinculado a una aplicación de servicio en la plataforma informática en la nube 1010. El dispositivo cliente 1080 puede ser cualquier tipo de dispositivo informático, que puede corresponder al entorno informático 1000 descrito con referencia a la f Ig . 10, por ejemplo. El dispositivo cliente 1080 se puede configurar para emitir comandos a la plataforma informática en la nube 1010. En las realizaciones, el dispositivo cliente 1080 puede comunicarse con aplicaciones de servicio a través de un Protocolo de Internet (IP) virtual y un balanceador de carga u otros medios que dirijan las solicitudes de comunicación a los puntos finales designados en la plataforma informática en la nube 1010. Los componentes de la plataforma informática en la nube 1010 pueden comunicarse unos con otros sobre una red (no mostrada), que puede incluir, sin limitación, una o más redes de área local (LAN) y/o redes de área extensa (WAN).
Habiendo descrito diversos aspectos del entorno informático distribuido 1000 y la plataforma informática en la nube 1010, se observa que se puede emplear cualquier número de componentes para lograr la funcionalidad deseada dentro del alcance de la presente descripción. Aunque los diversos componentes de la FIG. 10 se muestran con líneas en aras de la claridad, en realidad, delinear diversos componentes no es tan claro y, metafóricamente, las líneas pueden ser grises o borrosas con mayor precisión. Además, aunque algunos componentes de la FIG. 10 se representan como componentes únicos, las representaciones son ejemplares en su naturaleza y en su número y no se han de interpretar como limitantes para todas las implementaciones de la presente descripción.
Las realizaciones presentadas en la presente memoria se han descrito en relación con realizaciones particulares que están destinadas en todos los aspectos a ser ilustrativas más que restrictivas. Las realizaciones alternativas llegarán a ser evidentes para los expertos en la técnica a la que pertenece la presente descripción sin apartarse de su alcance.
A partir de lo anterior, se verá que esta descripción es una bien adaptada para obtener todos los fines y objetos anteriormente expuestos junto con otras ventajas que son obvias y que son inherentes a la estructura.
Se entenderá que ciertas características y subcombinaciones son de utilidad y se pueden emplear sin referencia a otras características o subcombinaciones. Esto está contemplado por y está dentro del alcance de las reivindicaciones.
En la descripción detallada anterior, se hace referencia a los dibujos que se acompañan que forman parte de la misma, en donde números iguales designan partes iguales en todas partes, y en las que se muestran, a modo de ilustración, realizaciones que se pueden practicar. Se ha de entender que se pueden utilizar otras realizaciones y se pueden hacer cambios estructurales o lógicos sin apartarse del alcance de la presente descripción. Por lo tanto, la descripción detallada anterior no se ha de tomar en un sentido limitativo, y el alcance de las realizaciones se define por las reivindicaciones adjuntas y sus equivalentes.
Se han descrito diversos aspectos de las realizaciones ilustrativas usando términos comúnmente empleados por los expertos en la técnica para trasladar la sustancia de su trabajo a otros expertos en la técnica. No obstante, será evidente para los expertos en la técnica que se pueden poner en práctica realizaciones alternativas con solamente algunos de los aspectos descritos. Con propósitos de explicación, los números, materiales y configuraciones específicos se exponen con el fin de proporcionar una comprensión minuciosa de las realizaciones ilustrativas. No obstante, será evidente para un experto en la técnica que se pueden poner en práctica realizaciones alternativas sin los detalles específicos. En otras instancias, se han omitido o simplificado características bien conocidas con el fin de no oscurecer las realizaciones ilustrativas.
Se han descrito diversas operaciones como múltiples operaciones discretas, a su vez, de una manera que es más útil en la comprensión de las realizaciones ilustrativas; no obstante, el orden de descripción no se debería interpretar como que implica que estas operaciones sean necesariamente dependientes del orden. En particular, estas operaciones no necesitan ser realizadas en el orden de presentación. Además, las descripciones de operaciones como operaciones separadas no se deberían interpretar como que requieran que las operaciones se realicen necesariamente de manera independiente y/o por entidades separadas. Las descripciones de entidades y/o módulos como módulos separados, del mismo modo, no se deberían interpretar como que requieran que los módulos estén separados y/o realicen operaciones separadas. En diversas realizaciones, operaciones, entidades, datos y/o módulos ilustrados y/o descritos se pueden fundir, dividir en subpartes adicionales y/u omitir.
La frase “en una realización” se usa repetidamente. La frase generalmente no se refiere a la misma realización; no obstante, puede. Los términos “que comprende”, “que tiene” y “que incluye” son sinónimos, a menos que el contexto lo dicte de otro modo. La frase “A/B” significa “A o B”. La frase “A y/o B” significa “(A), (B) o (A y B)”. La frase “al menos uno de A, B y C” significa “(A), (B), (C), (A y B), (A y C), (B y C) o (A, B y C).”

Claims (14)

REIVINDICACIONES
1. Un sistema para aprovisionar servidores (104; 302) de manera segura dentro de un entorno informático en la nube (100), el sistema que comprende:
uno o más procesadores (914); y
una memoria (912), junto con el uno o más procesadores, que tiene instrucciones almacenadas en la misma, que, cuando se ejecutan por el uno o más procesadores, dotan al sistema con un servicio de generación de imágenes (124; 306; 834) para:
recibir una notificación de delegación de imagen (122; 318) que identifica un servidor (104; 302) que el servicio de generación de imágenes ha de aprovisionar con una imagen del sistema operativo;
generar (326) una imagen del sistema operativo para el servidor;
cifrar al menos un volumen del sistema operativo, de la imagen del sistema operativo, utilizando una clave de cifrado de volumen de un mecanismo de cifrado de disco;
cifrar la clave de cifrado de volumen utilizando una clave de cifrado protegida que está protegida por el módulo de plataforma de confianza del servidor; y
transmitir (328) la imagen del sistema operativo y la clave de cifrado de volumen cifrada al servidor para hacer que el servidor sea aprovisionado con la imagen del sistema operativo;
el sistema que comprende además un servicio de administración de servidor seguro (116; 304; 832) configurado para:
recibir una solicitud (117; 310) desde el servidor para el aprovisionamiento seguro de un sistema operativo, la solicitud que incluye un identificador del servidor;
recuperar una clave pública asociada con un módulo de plataforma de confianza (820, 830) del servidor, en donde la clave pública se recupera de un almacén de datos en el que se almacenó la clave pública antes del despliegue del servidor en una ubicación física actual;
autenticar (320) el servidor utilizando la clave pública;
en respuesta a una autenticación exitosa del servidor, identificar (316) un servicio de generación de imágenes (124; 306; 834) del entorno informático en la nube en el que delegar la generación de una imagen del sistema operativo; y
transmitir la notificación de delegación de imagen (122; 318) al servicio de generación de imágenes identificado para hacer que el servicio de generación de imágenes identificado aprovisione el servidor con una imagen del sistema operativo (130; 328).
2. El sistema de la reivindicación 1, en donde la clave pública es una parte pública de una clave de aprobación del módulo de plataforma de confianza, y en donde autenticar el servidor utilizando la clave pública comprende un testimonio remoto del servidor utilizando el módulo de plataforma de confianza.
3. El sistema de la reivindicación 1, en donde el servicio de administración de servidor seguro se configura además para:
recuperar información de estado asociada con el servidor, la información de estado que incluye un indicador de uno o más de:
si el servidor ha sido notificado como robado, y
una dirección de protocolo de Internet esperada del servidor; y
validar la información de estado del servidor, en donde identificar el servicio de generación de imágenes del entorno informático en la nube en el que delegar la generación de la imagen del sistema operativo también es en respuesta a la validación exitosa del servidor.
4. El sistema de la reivindicación 1, en donde identificar el servicio de generación de imágenes del entorno informático en la nube, en el que delegar la generación de la imagen del sistema operativo, se basa en la proximidad geográfica o la proximidad de la red del servicio de generación de imágenes al servidor.
5. El sistema de la reivindicación 1, en donde el servicio de administración de servidor seguro se configura además para:
transmitir al servidor una notificación de servicio de generación de imágenes (320) seleccionado que incluye un identificador asociado con el servicio de generación de imágenes identificado para habilitar al servidor para enviar una solicitud de generación de imágenes al servicio de generación de imágenes identificado.
6. El sistema de la reivindicación 1, en donde la solicitud es una primera solicitud, el servidor es un primer servidor y el servicio de generación de imágenes es un primer servicio de generación de imágenes, y en donde el servicio de administración de servidor seguro está configurado además para:
recibir una segunda solicitud de un segundo servidor para el aprovisionamiento seguro de un sistema operativo para el segundo servidor, la segunda solicitud que incluye un identificador del segundo servidor;
identificar un segundo servicio de generación de imágenes situado en el primer servidor en el que delegar la generación de una imagen del sistema operativo para el segundo servidor.
7. Un método implementado por ordenador de aprovisionamiento de servidores de manera segura, el método que comprende:
recibir, en un servicio de administración de servidor seguro, una solicitud (117; 310) de un servidor para aprovisionamiento seguro de un sistema operativo, la solicitud que incluye un identificador del servidor; recuperar una clave pública asociada con un módulo de plataforma de confianza (820, 830) del servidor, en donde la clave pública se recupera de un almacén de datos en el que se almacenó la clave pública antes del despliegue del servidor en una ubicación física actual;
autenticar (320) el servidor utilizando la clave pública;
en respuesta a una autenticación exitosa del servidor, identificar (316) un servicio de generación de imágenes (124; 306; 834) del entorno informático en la nube en el que delegar la generación de una imagen del sistema operativo;
transmitir la notificación de delegación de imagen (122; 318) al servicio de generación de imágenes identificado para hacer que el servicio de generación de imágenes identificado aprovisione el servidor con una imagen del sistema operativo (130; 328);
recibir, por el servicio de generación de imágenes (124; 306; 834), la notificación de delegación de imagen (122; 318) que identifica el servidor (104; 302) que el servicio de generación de imágenes es para aprovisionar con una imagen del sistema operativo;
generar (326) una imagen del sistema operativo para el servidor;
cifrar al menos un volumen del sistema operativo, de la imagen del sistema operativo, utilizando una clave de cifrado de volumen de un mecanismo de cifrado de disco;
cifrar la clave de cifrado de volumen utilizando una clave de cifrado protegida que está protegida por el módulo de plataforma de confianza del servidor; y
transmitir (328) la imagen del sistema operativo y la clave de cifrado de volumen cifrada al servidor para hacer que el servidor sea aprovisionado con la imagen del sistema operativo.
8. El método implementado por ordenador de la reivindicación 7, que comprende además recuperar, en el servicio de generación de imágenes, una clave pública, en donde la clave pública se extrajo del módulo de plataforma de confianza (820, 830) del servidor antes del despliegue (108) del servidor en una ubicación física actual (110).
9. El método implementado por ordenador de la reivindicación 8, en donde la clave pública se incluye dentro de la notificación de delegación de imagen, y en donde recuperar la clave pública comprende extraer la clave pública de la notificación de delegación de imagen.
10. El método implementado por ordenador de la reivindicación 8, en donde recuperar la clave pública comprende recuperar la clave pública de un almacén de datos en el que se almacenó la clave pública (208) después de ser extraída (206) del módulo de plataforma de confianza del servidor.
11. El método implementado por ordenador de la reivindicación 7, que comprende además establecer una sesión de módulo de plataforma de confianza remota con el módulo de plataforma de confianza del servidor utilizando la clave pública, en donde la sesión del módulo de plataforma de confianza remota se utiliza para autenticar el servidor.
12. El método implementado por ordenador de la reivindicación 11, que comprende además:
utilizar la sesión del módulo de plataforma de confianza remota para hacer que la clave de cifrado de volumen sea sellada por el módulo de plataforma de confianza en base a los valores esperados de los registros de control de plataforma del servidor.
13. El método implementado por ordenador de la reivindicación 12, que comprende además recuperar los valores esperados de los registros de control de plataforma de un almacén de datos que correlaciona una pluralidad de configuraciones de servidores con una pluralidad correspondiente de valores esperados de los registros de control de plataforma.
14. El método implementado por ordenador de la reivindicación 7, en donde el servidor es un primer servidor, y en donde el servicio de generación de imágenes reside en un segundo servidor, en donde el primer servidor y el segundo servidor son pares dentro del bastidor y/o
el método que comprende además, tras transmitir la imagen del sistema operativo al servidor, transmitir una notificación de terminación (330) al servicio de administración para habilitar el servicio de administración para delegar el servicio de generación de imágenes para generar una imagen del sistema operativo para otro servidor.
ES17708353T 2016-02-12 2017-02-06 Aprovisionamiento seguro de sistemas operativos Active ES2837523T3 (es)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US15/043,224 US10425229B2 (en) 2016-02-12 2016-02-12 Secure provisioning of operating systems
PCT/US2017/016658 WO2017139217A1 (en) 2016-02-12 2017-02-06 Secure provisioning of operating systems

Publications (1)

Publication Number Publication Date
ES2837523T3 true ES2837523T3 (es) 2021-06-30

Family

ID=58192362

Family Applications (1)

Application Number Title Priority Date Filing Date
ES17708353T Active ES2837523T3 (es) 2016-02-12 2017-02-06 Aprovisionamiento seguro de sistemas operativos

Country Status (5)

Country Link
US (3) US10425229B2 (es)
EP (1) EP3414699B1 (es)
CN (1) CN108604270B (es)
ES (1) ES2837523T3 (es)
WO (1) WO2017139217A1 (es)

Families Citing this family (30)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8949818B2 (en) * 2012-06-29 2015-02-03 Intel Corporation Mechanism for facilitating dynamic and trusted cloud-based extension upgrades for computing systems
US10261920B2 (en) * 2016-09-16 2019-04-16 The United States of America as presented by the Secretary of the Navy Static image RAM drive
US10621351B2 (en) * 2016-11-01 2020-04-14 Raptor Engineering, LLC. Systems and methods for tamper-resistant verification of firmware with a trusted platform module
US20180198620A1 (en) * 2017-01-11 2018-07-12 Raptor Engineering, LLC Systems and methods for assuring data on leased computing resources
US20190012184A1 (en) * 2017-07-04 2019-01-10 Cloudendure Ltd. System and method for deploying cloud based computing environment agnostic applications
US10313315B2 (en) * 2017-08-25 2019-06-04 Bank Of America Corporation Ensuring information security in data transfers by utilizing proximity keys
CN108418817B (zh) * 2018-02-14 2021-02-26 华为技术有限公司 一种加密方法及装置
US10705825B2 (en) * 2018-09-20 2020-07-07 Hewlett Packard Enterprise Development Lp Creation of images
US10965551B2 (en) * 2018-11-21 2021-03-30 Microsoft Technology Licensing, Llc Secure count in cloud computing networks
US11095628B2 (en) 2019-01-24 2021-08-17 Dell Products L.P. Device locking key management system
US11106781B2 (en) * 2019-02-01 2021-08-31 Dell Products L.P. Secondary OS device unlocking system
US11023141B2 (en) * 2019-03-07 2021-06-01 Vast Data Ltd. Resiliency schemes for distributed storage systems
CN110162341A (zh) * 2019-05-16 2019-08-23 济南浪潮高新科技投资发展有限公司 一种uefi引导系统的多启动系统及方法
US11544381B2 (en) * 2019-07-01 2023-01-03 Hewlett Packard Enterprise Development Lp Configuration of server using stored security elements
US11689365B2 (en) * 2019-07-17 2023-06-27 Vmware, Inc. Centralized volume encryption key management for edge devices with trusted platform modules
US11520572B2 (en) * 2019-09-13 2022-12-06 Oracle International Corporation Application of scheduled patches
US11909882B2 (en) 2020-01-30 2024-02-20 Dell Products L.P. Systems and methods to cryptographically verify an identity of an information handling system
JP2023514484A (ja) * 2020-02-13 2023-04-06 インテル・コーポレーション マルチテナント環境における暗号コンピューティング
US11216366B2 (en) 2020-02-13 2022-01-04 Intel Corporation Security check systems and methods for memory allocations
US11604880B2 (en) * 2020-02-25 2023-03-14 Dell Products L.P. Systems and methods to cryptographically verify information handling system configuration
US11397588B2 (en) * 2020-05-28 2022-07-26 Hewlett Packard Enterprise Development Lp Operating system installation mechanism
US11170111B1 (en) * 2020-06-15 2021-11-09 Dell Products L.P. System and method for publishing and configuring a management service interface
CN112395627A (zh) * 2020-11-20 2021-02-23 深圳麦风科技有限公司 加解密方法、装置及存储介质
US11720682B2 (en) * 2020-12-02 2023-08-08 Dell Products, L.P. Systems and methods for bare-metal or pre-boot user-machine authentication, binding, and entitlement provisioning
US11972126B2 (en) 2021-03-26 2024-04-30 Intel Corporation Data relocation for inline metadata
WO2022231796A1 (en) * 2021-04-30 2022-11-03 Microsoft Technology Licensing, Llc Peer booting operating systems on an edge network
US11657158B2 (en) * 2021-05-24 2023-05-23 Dell Products L.P. Systems and methods for extending boot security trust chaining to state changes between boot sessions
US11954045B2 (en) 2021-09-24 2024-04-09 Intel Corporation Object and cacheline granularity cryptographic memory integrity
US20230147827A1 (en) * 2021-11-09 2023-05-11 Dell Products L.P. Edge day zero secure infrastructure identification and attestation
US20230143321A1 (en) * 2021-11-09 2023-05-11 Dell Products L.P. Secure base activation image for edge day zero secure infrastructure provisioning

Family Cites Families (28)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7590739B2 (en) * 1999-11-22 2009-09-15 Akamai Technologies, Inc. Distributed on-demand computing system
US20050149729A1 (en) * 2003-12-24 2005-07-07 Zimmer Vincent J. Method to support XML-based security and key management services in a pre-boot execution environment
US7600005B2 (en) * 2005-11-23 2009-10-06 Sun Microsystems, Inc. Method and apparatus for provisioning heterogeneous operating systems onto heterogeneous hardware systems
SE531992C2 (sv) 2006-02-24 2009-09-22 Oniteo Ab Metod och system för säker programvaruprovisionering
DE102006035662A1 (de) * 2006-07-31 2008-02-14 Infineon Technologies Ag Datenverarbeitungseinrichtung und Verfahren zum Überwachen des korrekten Betriebs einer Datenverarbeitungseinrichtung
JP5446860B2 (ja) * 2007-03-27 2014-03-19 日本電気株式会社 仮想マシン運用システム、仮想マシン運用方法およびプログラム
US8990796B2 (en) 2007-11-16 2015-03-24 Thomas Lamantia Method of automated operating system deployment for a network of multiple data processors
WO2009085977A2 (en) 2007-12-20 2009-07-09 Virtual Computer, Inc. Virtual computing management systems and methods
US9424017B2 (en) 2008-08-29 2016-08-23 Red Hat, Inc. Live operating system installation for Universal Serial Bus devices
US20100082960A1 (en) * 2008-09-30 2010-04-01 Steve Grobman Protected network boot of operating system
US8875125B2 (en) 2009-01-27 2014-10-28 Dell Products L.P. Operation system installation methods and media
US8214653B1 (en) * 2009-09-04 2012-07-03 Amazon Technologies, Inc. Secured firmware updates
US8332496B2 (en) 2009-09-23 2012-12-11 International Business Machines Corporation Provisioning of operating environments on a server in a networked environment
US20110202765A1 (en) * 2010-02-17 2011-08-18 Microsoft Corporation Securely move virtual machines between host servers
US8856504B2 (en) * 2010-06-07 2014-10-07 Cisco Technology, Inc. Secure virtual machine bootstrap in untrusted cloud infrastructures
US8578376B2 (en) 2011-01-04 2013-11-05 International Business Machines Corporation Automatically and securely configuring and updating virtual machines
JP5843459B2 (ja) * 2011-03-30 2016-01-13 インターナショナル・ビジネス・マシーンズ・コーポレーションＩｎｔｅｒｎａｔｉｏｎａｌ Ｂｕｓｉｎｅｓｓ Ｍａｃｈｉｎｅｓ Ｃｏｒｐｏｒａｔｉｏｎ 情報処理システム、情報処理装置、スケーリング方法、プログラムおよび記録媒体
US9064117B1 (en) * 2011-09-20 2015-06-23 Amazon Technologies, Inc. Mobile provisioning device
EP2761523B1 (en) * 2011-09-30 2019-01-02 International Business Machines Corporation Provisioning of operating systems to user terminals
WO2013133842A1 (en) * 2012-03-08 2013-09-12 Empire Technology Development Llc Secure migration of virtual machines
CN103365667B (zh) 2012-03-26 2018-01-26 联想企业方案（新加坡）有限公司 一种在主机系统中安装操作系统的方法和装置
US8868877B2 (en) 2012-04-11 2014-10-21 Dell Products, Lp Creating encrypted storage volumes based on thin-provisioning mode information
JP5782566B2 (ja) * 2012-06-22 2015-09-24 本田技研工業株式会社 ステータ製造装置及びステータ製造方法
US9141400B2 (en) 2012-12-21 2015-09-22 Unisys Corporation Technique for deploying operating systems in a virtualized environment
US9075995B2 (en) 2013-03-11 2015-07-07 Microsoft Technology Licensing, Llc Dynamically loaded measured environment for secure code launch
GB2516842A (en) * 2013-07-31 2015-02-11 Ibm Deployment of software images with distinct configuration logic
MY177609A (en) 2013-12-04 2020-09-22 Mimos Berhad A system and method to secure virtual machine images in cloud computing
WO2015116204A1 (en) 2014-01-31 2015-08-06 Hewlett-Packard Development Company, L.P. Encrypted in-place operating system migration

Also Published As

Publication number Publication date
US20170237560A1 (en) 2017-08-17
CN108604270A (zh) 2018-09-28
WO2017139217A1 (en) 2017-08-17
EP3414699B1 (en) 2020-11-18
US10425229B2 (en) 2019-09-24
US20220329425A1 (en) 2022-10-13
CN108604270B (zh) 2022-03-29
EP3414699A1 (en) 2018-12-19
US11394548B2 (en) 2022-07-19
US12003638B2 (en) 2024-06-04
US20200112435A1 (en) 2020-04-09

Similar Documents

Publication Publication Date Title
ES2837523T3 (es) Aprovisionamiento seguro de sistemas operativos
CA2918596C (en) A secure server on a system with virtual machines
US9626512B1 (en) Validating using an offload device security component
US10382195B2 (en) Validating using an offload device security component
CN108604263B (zh) 用于客户提供的完整性的双重签名可执行镜像
KR101318524B1 (ko) 보안 가상 머신 호스팅 프로세서 및 보안 가상 머신 설정 방법
US10169589B2 (en) Securely booting a computer from a user trusted device
US8589702B2 (en) System and method for pre-boot authentication of a secure client hosted virtualization in an information handling system
US10243739B1 (en) Validating using an offload device security component
US9134990B2 (en) System and method for implementing a secure client hosted virtualization service layer in an information handling system
US9154299B2 (en) Remote management of endpoint computing device with full disk encryption
US20120117381A1 (en) System and Method for Component Authentication of a Secure Client Hosted Virtualization in an Information Handling System
US20140289864A1 (en) Method and apparatus for securing a computer
JP2012190441A (ja) リモートプリブート認証
JP2013528872A (ja) マルチ・テナント・クラウドにおける顧客仮想計算機の保護
US20140344581A1 (en) Secure Upgrades for Field Programmable Devices
US20230229758A1 (en) Automated persistent context-aware device provisioning
CN112955888A (zh) 保护节点组
EP4062302A1 (en) Recovery keys
Sianipar et al. Construction of agent-based trust in cloud infrastructure
US20230353358A1 (en) Disaggregated key management in a distributed system