odca compute iaa_s_masterum_es

Modelo de uso principal de OPEN DATA CENTER ALLIANCESM:Infraestructura informática como servicio REV. 1.0

Copyright © 2012 Open Data Center Alliance, Inc. TODOS LOS DERECHOS RESERVADOS2

Open Data Center Alliance: Infraestructura informática como servicio Rev. 1.0

Tabla de contenido

Aviso legal .......................................................................................................................................................................................................... 6

Reconocimientos ................................................................................................................................................................................................ 6

Terminología y procedencia ................................................................................................................................................................................ 6

1.0 Resumen ejecutivo ........................................................................................................................................................................................ 7

2.0 Objetivo ........................................................................................................................................................................................................ 7

3.0 Taxonomía .................................................................................................................................................................................................... 8

Tabla 3.1: Términos y definiciones ........................................................................................................................................................ 8

4.0 Definición de CIaaS ...................................................................................................................................................................................... 9

Figura 4.0.1 Marco conceptual de ODCA .............................................................................................................................................. 9

4.1 Alcance de CIaaS ................................................................................................................................................................................ 10

Figura 4.1.1 CIaaS en contexto ........................................................................................................................................................... 10

4.2 Cargas de trabajo de CIaaS ................................................................................................................................................................. 11

4.3 Modelos de implementación ................................................................................................................................................................ 11

Tabla 4.3.1 Modelos de la nube.......................................................................................................................................................... 11

4.4 Atributos del servicio de CIaaS ............................................................................................................................................................ 12

Tabla 4.4.1 Atributos de niveles de servicio ........................................................................................................................................ 12

4.5 Capacidades generales ....................................................................................................................................................................... 13

4.6 Indicadores clave de rendimiento de CIaaS .......................................................................................................................................... 15

5.0 Interoperabilidad ......................................................................................................................................................................................... 17

6.0 Impulsores del negocio y escenarios de uso ............................................................................................................................................... 17

6.1 Escenarios de uso comercial ............................................................................................................................................................... 17

Figura 6.1.1 Escenarios de uso modelo de CIaaS ............................................................................................................................... 18

6.2 Desarrollo/Prueba ............................................................................................................................................................................... 19

Tabla 6.2.1 Requisitos para el desarrollo y las pruebas ...................................................................................................................... 19

6.3 Entorno de prueba de esfuerzo de carga ............................................................................................................................................. 20

Tabla 6.3.1 Prueba de esfuerzo de carga ........................................................................................................................................... 20

6.4 Informática distribuida y de alto rendimiento ....................................................................................................................................... 21

Tabla 6.4.1 Requisitos para la informática distribuida y de alto rendimiento ....................................................................................... 21

6.5 Entorno de producción independiente tradicional ................................................................................................................................ 22

Tabla 6.5.1 Producción independiente habilitada para la nube ............................................................................................................ 22

6.6 Entorno de producción empresarial tradicional .................................................................................................................................... 23

Copyright © 2012 Open Data Center Alliance, Inc. TODOS LOS DERECHOS RESERVADOS 3


Tabla 6.6.1 Producción empresarial tradicional .................................................................................................................................. 23

6.7 Entorno de producción empresarial para la nube ................................................................................................................................. 24

Tabla 6.7.1 Producción empresarial en la nube ................................................................................................................................... 24

6.8 Gestión de servicios y federación en la nube ....................................................................................................................................... 24

7.0 Detalles de los atributos del servicio ........................................................................................................................................................... 25

7.1 Funcionalidad ...................................................................................................................................................................................... 25

7.2 Disponibilidad ...................................................................................................................................................................................... 25

7.2.1 Resumen de los niveles de servicio: disponibilidad .................................................................................................................... 25

7.3 Capacidad de recuperación ................................................................................................................................................................. 26

7.3.1 Resumen de los niveles de servicio: capacidad de recuperación ................................................................................................ 26

7.4 Seguridad ............................................................................................................................................................................................ 27

7.4.1 Resumen de los niveles de servicio: seguridad .......................................................................................................................... 28

7.5 Elasticidad ........................................................................................................................................................................................... 29

7.5.1 Resumen de los niveles de servicio: elasticidad ......................................................................................................................... 30

7.6 Servicios de capacidad de gestión ....................................................................................................................................................... 30

7.6.1 Resumen de los niveles de servicio: monitoreo .......................................................................................................................... 31

7.6.2 Resumen de los niveles de servicio: intervalo de muestreo informado ....................................................................................... 31

7.6.3 Resumen de los niveles de servicio: cantidad de tareas automatizadas activas ......................................................................... 32

7.6.4 Resumen de los niveles de servicio: elaboración de informes .................................................................................................... 32

7.7 Rendimiento ........................................................................................................................................................................................ 33

7.7.1 SLA de rendimiento .................................................................................................................................................................. 33

7.7.2 Medición del rendimiento .......................................................................................................................................................... 33

7.7.3 Elaboración de informes de rendimiento .................................................................................................................................... 33

7.7.4 Monitoreo del rendimiento ......................................................................................................................................................... 33

7.7.5 Análisis del rendimiento ............................................................................................................................................................. 34

7.7.6 Interfaz y definición de rendimiento ........................................................................................................................................... 34

8.0 Interfaz del servicio y modelo de referencia ................................................................................................................................................ 34

8.1 Arquitectura conceptual de ODCA ........................................................................................................................................................ 34

Figura 8.1.1 Marco conceptual de ODCA ............................................................................................................................................ 34

8.2 Ciclo de vida básico de la nube ........................................................................................................................................................... 35

8.3 Requisitos de la interfaz del servicio ................................................................................................................................................... 35

8.4 Interfaces requeridas específicas ........................................................................................................................................................ 37

Tabla 8.4.1 Interfaces requeridas específicas..................................................................................................................................... 37



8.5 Instrumentación del servicio ............................................................................................................................................................... 40

Figura 8.5.1 Interfaces ....................................................................................................................................................................... 40

8.6 Ejemplo de escenario de uso: capacidad de recolocación de recursos en la nube pública en un SLA especificado .............................. 41

9.0 Operaciones y gestión ................................................................................................................................................................................ 42

9.1 Información general ............................................................................................................................................................................. 42

9.2 Motivaciones ....................................................................................................................................................................................... 42

9.3 Escenarios de uso de operaciones de CIaaS ........................................................................................................................................ 43

9.3.1 Escenario de uso 1: configuración de control y acceso .............................................................................................................. 43

9.3.2 Escenario de uso 2: capacidades de aprovisionamiento y de anulación de aprovisionamiento ................................................... 44

9.3.3 Escenario de uso 3: Identificación de fallas en el servicio o en el SLA por parte del proveedor ................................................. 45

9.3.4 Escenario de uso 4: Identificación de fallas en el servicio o en el SLA por parte del suscriptor .................................................. 45

9.3.5 Escenario de uso 5: notificación de interrupción o cambio del servicio ..................................................................................... 46

9.3.6 Escenario de uso 6: monitoreo del servicio ............................................................................................................................... 46

9.3.7 Escenario de uso 7: uso y facturación del suscriptor ................................................................................................................. 47

9.4 Niveles de servicio de operaciones y gestión ....................................................................................................................................... 48

Tabla 9.4.1 Niveles de servicio de operaciones y gestión.................................................................................................................... 48

10.0 Arquitectura técnica .................................................................................................................................................................................. 48

10.1 Supuestos y contexto ........................................................................................................................................................................ 48

10.2 Componentes .................................................................................................................................................................................... 48

Figura 10.2.1 Componentes de la arquitectura de CIaaS .................................................................................................................... 49

10.3 Nivel informático ............................................................................................................................................................................... 49

10.3.1 Resumen de los niveles de servicio: atributos de instancias informáticas ................................................................................ 50

10.4 Nivel de almacenamiento................................................................................................................................................................... 50

10.4.1 Requisitos para el almacenamiento en bloque ......................................................................................................................... 50

10.4.1.1 Resumen de los niveles de servicio: atributos del almacenamiento en bloque ............................................................... 50

10.4.2 Requisitos para el almacenamiento de objetos ........................................................................................................................ 51

10.4.3 Entramado de almacenamiento ............................................................................................................................................... 51

10.4.3.1 Resumen de los niveles de servicio: atributos del entramado de almacenamiento ......................................................... 52

10.5 Entramado de red .............................................................................................................................................................................. 52

10.5.1 Resumen de los niveles de servicio: atributos del entramado de red ....................................................................................... 53

10.6 Gestión .............................................................................................................................................................................................. 53

10.6.1 Resumen de los niveles de servicio: gestión ............................................................................................................................ 54

11.0 Consideraciones de seguridad ................................................................................................................................................................... 54



11.1 Requisitos de seguridad ..................................................................................................................................................................... 54

11.2 Pautas de implementación ................................................................................................................................................................. 56

11.2.1 Supuestos ............................................................................................................................................................................... 56

11.2.2 Pautas generales .................................................................................................................................................................... 56

11.2.3 Pautas específicas de los niveles de servicio .......................................................................................................................... 57

11.3 Catálogo de servicios de seguridad.................................................................................................................................................... 57

11.4 Protección contra malware ................................................................................................................................................................ 57

11.5 Control de admisión ........................................................................................................................................................................... 58

11.6 Auditoría y gobierno de seguridad ...................................................................................................................................................... 59

11.6.1 Escenario de uso del gobierno de seguridad ............................................................................................................................ 59

12.0 Consideraciones comerciales .................................................................................................................................................................... 60

13.0 Consideraciones regulatorias .................................................................................................................................................................... 60

14.0 RFP Requirements .................................................................................................................................................................................... 60

15.0 Próximos pasos y resumen de acciones industriales requeridas ................................................................................................................ 63

15.1 Acciones industriales requeridas ....................................................................................................................................................... 63

15.2 Desarrollo de requisitos futuros de CIAAS ......................................................................................................................................... 63

16.0 Referencias............................................................................................................................................................................................... 64

Modelos de uso de ODCA ......................................................................................................................................................................... 64

Otras fuentes ............................................................................................................................................................................................ 65

Notas finales ............................................................................................................................................................................................. 66



Aviso legalCopyright © 2012 Open Data Center Alliance, Inc. TODOS LOS DERECHOS RESERVADOS.

Este “Modelo de uso principal de Open Data Center AllianceSM: Infraestructura informática como servicio” es propiedad de Open Data Center Alliance, Inc.

AVISO PARA LOS USUARIOS QUE NO SON PARTICIPANTES DE OPEN DATA CENTER ALLIANCE: los usuarios que no son participantes de Open Data Center Alliance solo tienen derecho a revisar y a hacer referencia a este documento o a citarlo. Toda cita o referencia a este documento debe otorgarle a Open Data Center Alliance, Inc. completa potestad y debe reconocer los derechos de propiedad de Open Data Center Alliance, Inc. con respecto a este documento. Dichos usuarios no pueden revisar, alterar, modificar, editar, hacer derivaciones o de otro modo enmendar este documento de ninguna manera.

AVISO PARA LOS USUARIOS QUE SON PARTICIPANTES DE OPEN DATA CENTER ALLIANCE: el uso de este documento por parte de los participantes de Open Data Center Alliance está sujeto a los estatutos y otras políticas y procedimientos de Open Data Center Alliance.

OPEN DATA CENTER ALLIANCESM, ODCASM, y el logotipo® de OPEN DATA CENTER ALLIANCE son nombres comerciales, marcas registradas, marcas de servicio y logotipos (en conjunto “Marcas”) de propiedad de Open Data Center Alliance, Inc. y se encuentran reservados todos los derechos sobre ellos. Se encuentra estrictamente prohibido el uso sin autorización.

Este documento y su contenido se proporcionan “TAL COMO ESTÁN” y están sujetos a todas las limitaciones establecidas aquí.

Los usuarios de este documento no pueden hacer referencia a ninguna metodología, estadística, requisito u otros criterios recomendados o iniciales que puedan encontrarse en este documento o en cualquier otro documento distribuido por Alliance (“Modelos iniciales”) de ninguna manera que implique que el usuario o sus productos o servicios cumplen o han pasado por pruebas o certificaciones para demostrar su cumplimiento con cualquiera de estos Modelos iniciales.

Las propuestas o recomendaciones contenidas en este documento, incluidos, entre otros, el alcance y contenido de cualquier metodología, estadística, requisito u otros criterios propuestos, no implican que se le pedirá a Alliance en el futuro desarrollar un programa de prueba, cumplimiento o certificación para verificar cualquier implementación o cumplimiento futuros de dichas propuestas o recomendaciones.

Este documento no le otorga a ningún usuario de este documento ningún derecho a usar ninguna de las marcas de Alliance.

Toda otra marca de servicio, marca comercial y nombre comercial al que se haga referencia en este documento son propiedad de sus respectivos dueños.

Publicado en noviembre de 2012.

ReconocimientosODCA desea agradecer las importantes contribuciones de contenido y conocimientos previos al grupo de Enterprise Cloud Leadership Council del TM Forum, CloudScaling y Atos.

Terminología y procedenciaParte del contenido de este documento ha sido recopilado, con autorización, de productos de trabajo externos a ODCA. Se han realizado todos los esfuerzos necesarios para compatibilizar la terminología y la nomenclatura. Sin embargo, en los casos en los que haya alguna diferencia, prevalecerá la terminología de ODCA.

MODELO DE USO principal de OPEN DATA CENTER ALLIANCESM:Infraestructura informática como servicio REV. 1.0


1.0 Resumen ejecutivoDado el amplio espectro de consumidores de productos de la nube y de sus requisitos de infraestructura informática, existe una amplia variedad de capacidades que los proveedores de servicios podrían ofrecer para satisfacer estas necesidades de servicios informáticos y, en última instancia, para ofrecer experiencias de uso de aplicaciones rentables y excelentes a los usuarios finales.

Claramente, los proveedores de servicios no pueden cumplir con todas las permutaciones posibles de demanda y capacidades, en particular, en los casos extremos, donde la falta de escala o volumen limita la capacidad de los proveedores de servicios de lograr economías de escala.

Para poder cumplir con los requisitos de infraestructura informática para el amplio espectro de consumidores de servicios, se requiere un marco común alrededor del cual se pueda definir, aprovisionar, monitorear y gestionar la infraestructura como servicio. Se puede definir un conjunto común de principios, estadísticas y marcos arquitectónicos, lo que da como resultado capacidades, niveles de servicios y atributos de servicios uniformes entre varios proveedores, y al mismo tiempo permite a los proveedores individuales innovar y diferenciarse.

Para el año 2014, Open Data Center Alliance (ODCA) y sus miembros desean ver un mercado sólido, con cobertura completa para todos los escenarios de uso que se contemplan en este documento. Más aún, la mayoría de los proveedores debería ofrecer servicios para por lo menos la mitad de los escenarios de uso. Este Modelo de uso principal de ODCA: Infraestructura informática como servicio (CIasS) tiene como objetivo ayudar a facilitar el potencial para esto, al establecer un marco de requisitos para servicios de infraestructura informática interoperables y abiertos.

A la fecha, los esfuerzos de ODCA se han enfocado en las principales inquietudes de los consumidores y proveedores de servicios. Los modelos de uso originales resultantes se enfocaron en temas específicos, como la gestión de identidades y mediciones, entre otros. El objetivo de esta nueva ronda de modelos de uso es continuar desarrollando estos temas de enfoque específicos y proveer una plataforma sobre la cual poder colocar todos los temas juntos de una manera más holística. Los modelos de uso principales harán referencia a los modelos de uso publicados anteriormente y los sustentarán.

Este documento sirve para una variedad de públicos. Las personas que toman decisiones comerciales y que buscan soluciones específicas, y los grupos de TI empresariales involucrados en la planificación, las operaciones y las adquisiciones encontrarán útil este documento. Los proveedores de soluciones y vendedores de tecnología se beneficiarán de su contenido ya que podrán comprender mejor las necesidades de los clientes y personalizar las ofertas de productos y servicios. Las organizaciones de normalización encontrarán útil la información a la hora de definir estándares abiertos relevantes para los usuarios finales.

2.0 ObjetivoEste documento y los modelos de uso de apoyo a los que hace referencia describen los requisitos para lograr una infraestructura informática como servicio completa. Existen aspectos de este modelo de uso donde los requisitos son más estrictos que los que se encuentran hoy en día en las nubes públicas populares. Es importante comprender que este documento especifica requisitos empresariales suficientes como para desplazar centros de datos empresariales establecidos. Este marco común se requiere para que los servicios de CIaaS puedan ser evaluados, adquiridos y desechados por empresarios de un modo tal que se refleje la visión de las firmas miembro de ODCA de un mercado sólido y activo para finales del año 2014.

El área de Infraestructura como servicio (IaaS) es bastante amplia y se puede segmentar en tres ofertas distintas de “servicio”: informática, almacenamiento y red; cada una de ellas se ofrece en una variedad de modelos de uso. Mientras que las áreas de servicios de red y almacenamiento son esenciales para los modelos de servicios de nube generales, los cimientos de la informática en la nube se basan fundamentalmente en las capacidades de ”informática como servicio”. Por lo tanto, este documento aborda el área de la informática de IaaS con más profundidad que para las áreas de red y almacenamiento. ODCA abordará estas otras áreas de IaaS en trabajos futuros.



3.0 Taxonomía

Término Definición

Aplicación para la nube Las aplicaciones para la nube han sido diseñadas y desarrolladas con el único propósito de poder funcionar en entornos de nube.

Agente de servicios de la nube Un agente de servicios de la nube es una entidad que gestiona el uso, el rendimiento y la entrega de servicios de nube y negocia las relaciones entre los proveedores y los suscriptores de la nube. En general, un agente de servicios de la nube puede proporcionar servicios divididos en tres categorías: mediación del servicio, agrupación del servicio y arbitraje del servicio.1

Federación en la nube Un concepto de agrupación del servicio, caracterizado por las características de interoperabilidad, que aborda los problemas económicos de la dependencia de un proveedor y de la integración de proveedores.2

Proveedor de la nube Una organización que proporciona servicios de nube y cobra una tarifa a los suscriptores de la nube. Un proveedor de la nube ofrece servicios a través de Internet. Un suscriptor de la nube podría ser su propio proveedor de la nube, como por ejemplo, en las nubes privadas.

Agencia de normalización de la nube

Una entidad responsable de establecer y mantener los estándares de instrumentación de la nube contemplados en este modelo de uso.

Suscriptor de la nube Una persona u organización que ha sido autenticada en una nube y que mantiene una relación comercial con un proveedor de la nube.

Ventana de mantenimiento Un período designado de antemano por el proveedor de la nube, durante el cual se realiza un mantenimiento preventivo que, de no hacerse, podría provocar una interrupción del servicio.3

Objetivo de compatibilidad de recuperación (RCO)

El RCO define una medición de la compatibilidad de los datos comerciales distribuidos después de que ocurra un desastre u otro evento que interrumpa la continuidad del negocio.6

Objetivo de punto de recuperación (RPO)

El período máximo tolerable en el que los datos pueden perderse en un servicio de TI debido a un incidente importante.4

Objetivo de tiempo de recuperación (RTO)

La duración del tiempo y un nivel de servicio dentro de los cuales un proceso comercial debe ser restablecido, luego de una interrupción, para evitar consecuencias inaceptables.5

Aplicación tradicional Un programa o sistema que no ha sido diseñado específicamente (o remediado) para utilizar de manera transparente las capacidades únicas de la informática en la nube.

Carga de trabajo Una imagen de máquina o una instancia de máquina virtual, junto con la información necesaria sobre el diseño técnico (por ejemplo, cantidad de núcleos, RAM), la configuración de red y el almacenamiento de datos directamente asociados con la máquina virtual (VM). La VM es la abstracción de todos los elementos que constituyen la carga de trabajo.

Tabla 3.1: Términos y definiciones

Copyright © 2012 Open Data Center Alliance, Inc. TODOS LOS DERECHOS RESERVADOS

4.0 Definición de CIaaSPara trabajar en un marco común, usamos la definición de Infraestructura como servicio que ofrece el Instituto nacional de estándares y tecnología (NIST).

“Infraestructura como servicio (IaaS). La capacidad que se otorga al consumidor es el aprovisionamiento de procesamiento, almacenamiento, redes y otros recursos informáticos fundamentales donde el consumidor puede implementar y ejecutar software arbitrario, que puede incluir sistemas operativos y aplicaciones. El consumidor no gestiona ni controla la infraestructura subyacente de la nube, pero tiene control sobre los sistemas operativos, el almacenamiento y las aplicaciones implementadas, y tiene un control posiblemente limitado de determinados componentes de red (por ejemplo, firewalls del host)”.7

Específicamente, enfocamos el trabajo de este modelo de uso principal en un contenedor informático de la nube de uso general, que incluye las capacidades necesarias de soporte de almacenamiento y de red para hacerlo más útil. Sin embargo, el énfasis de este modelo de uso está puesto en las capacidades informáticas. Tal como se ilustra en el marco conceptual que se encuentra a continuación, estos cimientos nos permitirán analizar por separado las soluciones de Infraestructura como servicio (IaaS), Plataforma como servicio (PaaS) y Software como servicio (SaaS) de más alto nivel en áreas más elevadas de la pila. Además, si bien en este documento se abordan los requisitos de red y almacenamiento, los requisitos específicos para los modelos de uso de almacenamiento como servicio y red como servicio serán abordados en el futuro.

Figura 4.0.1 Marco conceptual de ODCA v1.0

Rendimientoy capacidad

Aplicaciones y SO deentrega de software

Configuración

Evento

Seguridad

Consume/suscribe

Proporciona

Instalación

Aplicaciones para la nube

Web Base de datos

PaaS

SaaS

Interoperabilidad de servicios web y de datos

IaaS

Aplicaciones para la nube y tradicionales

Recursosinformáticos Almacenamiento Red

Espacio físico, enfriamiento, energía

Catálogo de servicios accionable (IU y API)

Procesos comerciales

Instrumentación y gestión

dinámicas de servicios com

pletos

Usuariofinal

Desarrollo deaplicaciones

Operacionesde TI

El marco conceptual de ODCA ilustrado anteriormente muestra que los servicios de CIaaS pueden ser usados tanto para aplicaciones “tradicionales” como para aplicaciones “para la nube”. De hecho, este documento incluye escenarios de uso modelo para ambos tipos de aplicaciones. Sin embargo, es importante que definamos primero a qué nos referimos cuando hablamos de aplicaciones tradicionales y para la nube.

• Para la nube: las aplicaciones para la nube han sido diseñadas y desarrolladas con el único propósito de poder funcionar en entornos de nube. Se encuentran libres de las dependencias y los supuestos con los que cargan las aplicaciones tradicionales y heredadas, y al mismo tiempo pueden explotar de manera completa las ventajas inherentes de la nube. También se han usado otros términos para hacer referencia a estas aplicaciones, entre las que se incluyen, aplicaciones nativas de la nube, con arquitectura para la nube, con origen en la nube o habilitadas en la nube. Sin embargo, los atributos usados para describir dichas arquitecturas generalmente incluyen las siguientes características:8,9

º Capacidad de composición: las aplicaciones se distribuyen y se conectan de manera dinámica.

º Elasticidad: la capacidad de escalar, pero también de reducir su tamaño según la carga.

º Capacidad de evolución: esta característica está relacionada con la portabilidad y hace referencia a la capacidad de reemplazar la tecnología subyacente existente o las decisiones de los proveedores con otras, a medida que cambian las necesidades del mercado o del negocio, con un mínimo impacto en el negocio.

9



º Capacidad de extensión: las aplicaciones se implementan y prueban de manera gradual. Es decir, existe la posibilidad de ampliar fácilmente la aplicación en el futuro.

º Granulación de mediciones y facturación

º Clientes múltiples: varios suscriptores de la nube pueden estar usando la misma infraestructura y los mismos recursos subyacentes del proveedor de la nube, con confiabilidad, seguridad y rendimiento uniforme.

º Capacidad de portabilidad: las aplicaciones se pueden ejecutar en prácticamente cualquier lugar, con cualquier proveedor de nube y desde cualquier dispositivo.

º Autoservicio

• Tradicionales: dicho de manera simple, son programas o sistemas que no han sido diseñados específicamente (o remediados) para utilizar de manera transparente las capacidades únicas de la informática en la nube. En cambio, estas aplicaciones pueden migrarse para ser ejecutadas en un contexto de nube, pero la materialización del valor de dichas instancias será limitada.

4.1 Alcance de CIaaSCIaaS requiere los siguientes elementos:

• Instancias informáticas (pueden o no ser virtuales, aunque las máquinas virtuales [VM] son típicas)

• CPU y recursos de memoria

• Componentes de red

• Almacenamiento

Estos elementos serán implementados en diferentes configuraciones para cumplir con una amplia gama de capacidades y atributos de servicio. No es nuestro objetivo definir la implementación técnica en este modelo de uso. En cambio, buscamos definir las capacidades requeridas en términos y medidas simples.

Inst

rum

enta

ción

Contenedor

Servidor

Almacenamiento

Red

Inst

rum

enta

ción

Contenedor

Servidor

Almacenamiento

Red

Suscriptor de la nube

Agente de serviciosde la nube

Proveedor dela nube 2



Inst

rum

enta

ción

Contenedor

Servidor

Almacenamiento

Red

Figura 4.1.1 CIaaS en contexto

10



4.2 Cargas de trabajo de CIaaS10

Genéricamente, una carga de trabajo es un encapsulamiento de lo siguiente:• Procesos de aplicaciones

•Datos

• Información de configuración

• Estado

Esto también incluye metadatos que describen las relaciones entre estos elementos. Para los servicios de Infraestructura como servicio (IaaS), el encapsulamiento de la carga de trabajo es generalmente la máquina virtual.

Las mejores prácticas11 indican que las descripciones y los niveles de servicios deben ser uniformes, a fin de garantizar la transparencia y de comparar y contrastar de manera justa a los proveedores de la nube. Adicionalmente, los modelos de facturación, entre otros, deberían ser comparables en diferentes entornos. Estos son funcionamientos prácticos y claves de la interoperabilidad de la nube. Para obtener más información sobre este tema, consulte el Modelo de uso principal de ODCA: marco comercial12 y el Modelo de uso principal de ODCA: marco regulatorio.13

4.3 Modelos de implementaciónA menos que se especifique de otra manera, se da por sentado que los requisitos descritos en este documento se aplican a todos los posibles modelos de adquisición e implementación en la nube:

11


Tabla 4.3.1 Modelos de nube

Modelo Definición

Nube privada La infraestructura de la nube funciona únicamente para una organización (suscriptor de la nube). Puede ser gestionada por la organización misma (una nube privada interna de la empresa) o por un tercero, y puede encontrarse en el sitio de la organización (nube privada interna gestionada) o en un sitio externo (nube privada externa gestionada) (según la definición del NIST11).

Nube de la comunidad La infraestructura de la nube se comparte entre varias organizaciones y admite una comunidad específica o una industria vertical que tiene inquietudes compartidas (por ejemplo, la misión, los requisitos de seguridad, la política y las cuestiones de cumplimiento). Puede ser gestionada por las organizaciones o por un tercero y puede encontrarse dentro del sitio o fuera de este. Los miembros pueden tener perfiles de utilización correlativos o similares (según la definición del NIST).

Nube sectorial La demanda puede estar altamente correlacionada entre los miembros de una nube de la comunidad, y esto podría socavar su economía. Por lo tanto, una nube sectorial es una nube de la comunidad para múltiples industrias donde los picos y caídas en la demanda pueden suavizarse, para permitir una mayor cantidad de oportunidades de optimización.14

Nube pública La infraestructura de la nube se encuentra disponible para el público en general o para un grupo industrial grande y es de propiedad de una organización que vende servicios de nube (según la definición del NIST).

Nube híbrida La infraestructura de la nube se compone de dos o más nubes que se mantienen como entidades únicas, pero que están unidas por una tecnología que permite la portabilidad de aplicaciones y datos (por ejemplo, la recolocación de recursos en la nube pública para equilibrar la carga entre las nubes) (según la definición del NIST).

Mercado de la nube Intercambios profesionales de servicios de nube por miembros (proveedores y suscriptores de la nube) que acuerdan reglas comunes y también aceptan ser auditados y certificados por auditores de nube externos para garantizar la uniformidad y calidad.

http://www.opendatacenteralliance.org/docs/ODCA_Commercial_Framework_MasterUM_v1.0_Nov2012.pdf

http://www.opendatacenteralliance.org/document-sections/category/71-docs?download=455:regulatory_framework




4.4 Atributos del servicio de CIaaSUna oferta de CIaaS será definida usando los atributos de aseguramiento de servicio que figuran a continuación; la mayoría de ellos, según el Modelo de uso de ODCA: Unidades de medida estándares para IaaS.15 Adicionalmente, incluimos 2 términos más: funcionalidad e interoperabilidad.

•Disponibilidad: el grado de tiempo de actividad para la solución, teniendo en cuenta, por ejemplo, las probabilidades de contención de recursos.

•Rendimiento: el grado hasta el que se asegura la solución para proporcionar un nivel de salida.

•Capacidad de recuperación: los objetivos de punto de recuperación y de tiempo de recuperación de la solución.

• Seguridad: el grado de protección de la solución (por ejemplo, cifrado, tripwire, red de área local virtual o VLAN, filtros de puertos, etc.).

•Capacidad de gestión: el grado de automatización y control disponible para gestionar la solución.

• Prioridad del SLA del cliente: el diseño de contención del servicio para manejar los picos de demanda.

• Funcionalidad: los servicios esenciales provistos por el proveedor de la nube al suscriptor de la nube.

• Interoperabilidad: el grado hasta el cual el suscriptor de la nube puede hacer todo lo siguiente:16,17

º Migrar cargas de trabajo de una nube a otra (incluido entre los proveedores de la nube).

º Vincular nubes dispares.

º Comparar proveedores de la nube según el costo y las capacidades.

º Utilizar interfaces de gestión uniformes.

Los atributos del servicio se pueden describir en términos de múltiples niveles de servicio. Específicamente, cada uno de estos atributos se puede definir en los niveles de servicio bronce, plata, oro y platino, que se describen en la tabla a continuación. El objetivo de este modelo de uso principal es que los niveles de servicio se puedan combinar y unir entre los distintos atributos de servicio, pero no dentro de ellos. Es decir, es posible tener un servicio de nube con una disponibilidad de nivel bronce, pero con un rendimiento de nivel oro. Sin embargo, se deben cumplir todos estos elementos que conforman el nivel de servicio de un atributo dado. Por ejemplo, se deben cumplir todos los subrequisitos para el rendimiento de nivel oro para que el servicio califique como servicio de nivel oro en su rendimiento (consulte la sección 7.0 Detalles de los niveles de servicio).

Nivel de servicio Posición Descripción

Bronce Básica Representa el requisito corporativo más bajo, equivale posiblemente a un nivel razonablemente alto para un cliente comercial entre pequeño y mediano.

Plata Equivalente empresarial Representa una calidad más alta que el nivel bronce, y un equilibrio con costos más altos, dentro del rango del SLA.

Oro Equivalente a sector empresarial o mercado crítico

Representa una preferencia por una calidad de servicio superior dentro del rango del SLA.

Platino Equivalente a seguridad crítica o militar

Representa el requisito corporativo máximo contemplado, y llega hasta el límite más bajo de las necesidades de seguridad crítica o militar.

Tabla 4.4.1 Atributos de los niveles de servicio

Se supone que los niveles de servicio más bajos corresponden a precios de proveedores de nube más bajos.

Los niveles de servicio se definieron específicamente usando medidas cualitativas y cuantitativas alineadas con el Modelo de uso de ODCA: Unidades de medida estándares para IaaS.15 Nota: los niveles de servicio para la “interoperabilidad” se definen en el Modelo de uso de ODCA: Guía para la lograr la interoperabilidad entre nubes,17 y la “funcionalidad” de CIaaS se define aquí por primera vez.

Dado el amplio rango de requisitos y capacidades de CIaaS, una buena manera de comprender los atributos de servicios específicos para CIaaS es mediante ejemplos. Estos se presentan en una sección posterior.

http://www.opendatacenteralliance.org/document-sections/category/71-docs?download=458:standard_units_of_measure



http://www.opendatacenteralliance.org/docs/ODCA_Interop_Across_Clouds_Guide_Rev1.0_BD.pdf

http://www.opendatacenteralliance.org/docs/ODCA_Interop_Across_Clouds_Guide_Rev1.0_BD.pdf



4.5 Capacidades generalesCIaaS debe incluir las siguientes capacidades operativas y de gestión generales como también lo destaca el grupo de TM Forum.18 ODCA ha extendido estos requisitos para mejorar la seguridad y adaptarlos dentro de la empresa.

Gestión de operaciones de TI:

Nota: el punto 4 que figura a continuación es un requisito de ODCA, adicional a aquellos de TM Forum.

1. El servicio debe admitir un amplio espectro de sistemas operativos x86, incluidos Windows (SO para equipos de escritorio y servidores), Solaris x64 y Linux (distribuciones líderes) en versiones de 32 y 64 bits.

2. El servicio debe admitir controles de aislamiento de red para tráfico entrante y saliente.

3. El servicio debe admitir la implementación de componentes web, de aplicaciones, de base de datos y de servicio de infraestructura, como los componentes del Protocolo ligero de acceso a directorios (LDAP).

4. El servicio debe alinearse con los procesos de la Biblioteca de infraestructura de tecnología de la información (ITIL) para la gestión de configuración, incidentes y cambios.

Gestión de red:

1. El proveedor de servicios debe proporcionar opciones para la conectividad de red del consumidor, como la red privada virtual (VPN) de Internet y líneas arrendadas. Más aún, el proveedor de servicios debe articular cualquier otra restricción, condición o requisito de red, como la traducción de dirección de red (NAT), la superposición de direcciones IP y los controles de latencia.

2. El servicio debe incluir instrumentación para proporcionarle al consumidor un panorama del ancho de banda, el rendimiento y la latencia. Estos deberían estar disponibles a través de las interfaces de servicio (incluida la interfaz del usuario del portal de servicios y la interfaz de programación de aplicaciones [API]).

Gestión de seguridad:

Nota: los puntos 3 a 5 que figuran a continuación son requisitos de ODCA, que se agregan a aquellos de TM Forum.

1. El proveedor de servicios debe proporcionar arquitectura, diseño, política y otros elementos que demuestren el grado en el cual el servicio del suscriptor de la nube es segregado de otros suscriptores. Esto se aplica a servicios de nube de un solo cliente o de clientes múltiples.

2. El proveedor de nube deber afirmar formal y explícitamente que la seguridad de procesamiento, de la red y del almacenamiento cumplen con los requisitos del nivel contratado por el suscriptor de la nube (bronce, plata, oro o platino). Adicionalmente, el proveedor de la nube debe admitir una verificación independiente.

3. El suscriptor debe cumplir con los procedimientos y las políticas de seguridad implementados por el proveedor para cumplir con el nivel de aseguramiento real de la nube.

4. En un entorno de nube gestionado, ciertos software usados por el suscriptor dentro de la nube deben integrarse con las herramientas de monitoreo provistas en la nube que aseguran la integridad de esta. Esto incluye los software de prevención y detección de intrusiones, registros de umbrales de acceso y más.

5. El monitoreo de las aplicaciones es controlado por los suscriptores y se puede ejecutar de manera local en la nube, y también se puede conectar a la infraestructura de monitoreo del suscriptor. El monitoreo de la seguridad en el nivel de la aplicación es responsabilidad del suscriptor (Nota: en tipos de servicios de valor más elevado, un firewall de aplicación puede formar parte de la oferta del proveedor).

Gestión de la carga de trabajo:

Nota: el punto 4 que figura a continuación es un requisito de ODCA, adicional a aquellos de TM Forum.

1. El servicio debe proporcionar flexibilidad de volumen y permitirle al consumidor aumentar o disminuir los recursos que se consumen.

2. El servicio debe ser capaz de integrarse con las herramientas de gestión de la nube del consumidor, de manera programada y a través de las API estándares.

3. El servicio debe permitirle al consumidor cambiar las reglas y los parámetros de la política de carga de trabajo cuando este lo desee y dentro de criterios específicos.

4. El servicio debe proporcionar un portal de gestión de servicios de nube.

http://www.opendatacenteralliance.org/docs/tmforum_tr174enterprisegrade_computeiaasrequirements.pdf



Gestión de cumplimiento:

1. El proveedor debe aceptar, cumplir y permitir el cumplimiento de las políticas y los marcos regulatorios, las auditorías externas e internas, las certificaciones y los estándares mínimos y la gestión de resultados. Los proveedores pueden ser sancionados en el caso de falta de control.

2. Pueden existir requisitos procedimentales y técnicos basados en el sector del suscriptor de nube o en el país en el que este opera o tiene clientes. Esto también puede incluir requisitos, como datos que deben permanecer en el país de origen o pruebas de recuperación ante desastres prescriptivas o regulares. Es posible que se requiera que el suscriptor de la nube proporcione evidencia de cumplimiento, y por lo tanto, puede necesitar la asistencia del proveedor para proporcionarla.

Gestión de problemas:

1. Cada parte debe haber establecido un análisis efectivo del origen de los incidentes, relacionado con los servicios consumidos o contratados, para prevenir la recurrencia de impactos negativos en el servicio.

Gestión de continuidad del servicio:

Nota: el punto 2 que figura a continuación es un requisito de ODCA, adicional a los de TM Forum.

1. Cada parte debe tener procesos efectivos para garantizar que los servicios de TI puedan recuperarse y continuar, incluso, después de que ocurran incidentes graves. Esto también incluirá la continuidad del negocio de proveedores de materiales.

2. El proveedor de la nube debe garantizar que un suscriptor de nube externo no pueda impactar en el suscriptor de la nube, como en situaciones de “vecino ruidoso”.

Gestión de vulnerabilidad:

Nota: los puntos 2 a 4 que figuran a continuación son requisitos de ODCA, que se agregan a TM Forum.

1. El proveedor de la nube debe establecer una práctica regular para identificar, clasificar, remediar y mitigar las vulnerabilidades, incluida la gestión de parches. Además, el proveedor debe notificar al suscriptor de la nube cualquier acción o incidente, conocido o sospechado, que pueda poner en riesgo los activos o los datos del suscriptor de la nube a través del servicio del proveedor.

2. El proveedor de la nube trabaja estrechamente con su proveedor de servicios de Internet (ISP) y con organizaciones de seguridad internacionales y regionales, para prevenir ataques por Internet a los clientes o a su infraestructura. El proveedor tiene un equipo de respuesta ante riesgos y un equipo de operaciones de seguridad que se encuentran capacitados para responder rápidamente ante ataques y para evitar que sus clientes sufran algún impacto. Más aún, para los servicios de nivel oro y platino, los Ataques de denegación de servicio (DOS) y los Ataques distribuidos de denegación de servicio (DDOS) se contienen al filtrar los servidores atacantes tan pronto como sea posible en la infraestructura del ISP.

3. Para los niveles de servicio plata, oro y platino, el suscriptor cuenta con un sistema de gestión de vulnerabilidades en el sitio y aplica parches de seguridad de manera oportuna, según se define en el Modelo de uso de ODCA: Garantía del proveedor.19

4. Para los niveles de servicio oro y platino, el suscriptor realiza análisis de sus registros de aplicaciones y accesos, y comunica patrones identificados al proveedor, para mejorar la precisión de los filtros del proveedor.

Servicio de monitoreo:

Nota: el punto 2 es un requisito de ODCA, adicional a los de TM Forum.

1. El proveedor de la nube debe monitorear el entorno, incluido los eventos, la capacidad, la seguridad y la utilización, para garantizar que se cumplan los SLA. Los datos de monitoreo del proveedor deben proporcionarse según las API estandarizadas.

2. Si los análisis y el monitoreo de los niveles de la aplicación apuntan a la infraestructura, las estadísticas de la infraestructura deben ser de fácil acceso y disponibilidad para realizar análisis de origen de los problemas, para resolver los problemas y para proporcionar advertencias tempranas de los problemas que pueden llegar a ser prevenibles.

Gestión de incidentes:


1. Cada parte debe informar a la otra sobre los incidentes que pueden afectar a cada una. Se deben establecer acuerdos predefinidos sobre la prioridad de un incidente y el nivel de esfuerzo requerido por el proveedor de la nube durante un incidente. Se deben establecer interfaces automatizadas y estandarizadas para gestionar incidentes.

http://www.opendatacenteralliance.org/docs/Security_Provider_Assurance_Rev%201.1_b.pdf



2. Tenga en cuenta que los incidentes que deben comunicarse también incluyen aquellos donde el suscriptor de la nube debe informar al proveedor de la nube sobre incidentes que puedan afectar a otros suscriptores externos.

3. Cuando se producen incidentes más serios, tal como se acordó en un contrato entre el proveedor y el suscriptor, el proveedor de la nube debe notificar a los clientes afectados dentro de las 48 horas.

4. Se deben acordar las respuestas ante incidentes entre ambas partes para que estas sean lo más efectivas posible. Las actividades coordinadas ayudan a prevenir la degradación de servicios al evitar las acciones que generan conflictos.

Gestión de cambios:

1. Cada parte notificará a la otra cuando un cambio en la configuración u otro aspecto operativo pueda afectar las capacidades del servicio de la otra parte. La gestión proactiva se requiere para garantizar un entorno estable.

Gobierno:


1. El proveedor debe cumplir y permitir el cumplimiento de las políticas y los marcos regulatorios, las auditorías externas e internas, las certificaciones y los estándares mínimos y los controles de seguridad. Cuando no se cumplen los requisitos, se pueden establecer sanciones y la extinción de contratos.

2. Para los niveles de servicio oro y platino, el contrato entre el subscriptor y el proveedor, por lo general, estipulará limitaciones jurisdiccionales o geográficas de la ubicación en donde pueden almacenarse y procesarse los datos del suscriptor, incluida la ubicación de las cintas de copias de seguridad y de los sitios secundarios.

3. Para los niveles oro y platino, el proveedor debe notificar al suscriptor de la casa matriz o de la jurisdicción legal, si tiene una casa matriz estadounidense que se rige por la Ley Patriota de los EE. UU. (US PATRIOT ACT).

Aprovisionamiento de servicios:

1. El proveedor debe contar con mecanismos automatizados eficaces para solicitar, aprovisionar, gestionar y medir el uso de los servicios, cuando sea posible.

4.6 Indicadores clave de rendimiento de CIaaSUn indicador clave de rendimiento (KPI) es un término técnico de TI que se usa para hacer referencia a un tipo de medida de rendimiento. Una manera muy común de elegir un KPI es aplicar un marco de gestión (por ejemplo, el cuadro de mando integral) y consolidar una cantidad de perspectivas y estadísticas del SLA en un conjunto más pequeño de indicadores generales. Algunos tipos de KPI incluyen lo siguiente:20

• Indicadores cuantitativos; prácticamente cualquier elemento que sea numérico y relevante para el contrato de servicios y los objetivos del negocio.

• Indicadores prácticos que interactúan o se alinean con los procesos empresariales.

• Indicadores direccionales que especifican si un servicio o una organización están mejorando o no.

• Los indicadores accionables son aquellos indicadores del control de una organización que son suficientes como para poder afectar el cambio.

• Los indicadores financieros son aquellos que podrían incluir gastos, ahorros y créditos de servicio por fallas en el SLA, etc.

Los indicadores clave de rendimiento, en términos prácticos y para un desarrollo estratégico, son objetivos que deben alcanzarse y que otorgarán más valor al negocio.

Principios de los KPI:

• Los KPI deben definir títulos o etiquetas de medidas específicas y no ambiguas.

• Los parámetros de los KPI ayudan a conformar el SLA.

• Los KPI tienen marcas de agua altas y bajas, sobre las que se establecen los SLA.

• Los KPI pueden tener varias dimensiones, y algunas de ellas se pueden compartir, como por ejemplo:

º La visión del suscriptor de la nube para evaluar la calidad del servicio.

º La visión del proveedor de la nube para gestionar los servicios generales.

º Una visión compartida de algunos elementos.



Los indicadores clave de rendimiento para CIaaS se corresponden estrechamente con los atributos del servicio. Se definen para proporcionar una manera efectiva de medir el servicio. También son importantes para los suscriptores de la nube cuando realizan compras de servicios, y para los proveedores de la nube cuando evalúan sus servicios. Los KPI deben enfocarse en una cantidad pequeña de estadísticas principales y significativas que sean rentables y útiles.

KPI asociados con los atributos del servicio

Estos son los KPI que serán usados diariamente por los suscriptores de la nube para garantizar que el servicio se proporcione de conformidad con los requisitos y para hacer un seguimiento de las desviaciones de la norma. Se pueden describir fácilmente, usando los elementos y niveles de servicio deseados de las secciones “Atributos del servicio” y “Consideraciones comerciales” de este documento. Sin embargo, los temas principales de los KPI incluyen lo siguiente:21

• Capacidad contratada y provista

• Utilización y uso de la capacidad

• Parámetros de rendimiento

• Invocación de acciones automatizadas y definidas

•Disponibilidad del servicio

•Niveles de servicio admitidos (bronce, plata, oro y platino)

• Parámetros de continuidad del servicio (RTO, RPO, RCO)

• Clasificación de datos y estadísticas de retención

• Controles de seguridad

• Informes definidos y estadísticas de auditoría

Ejemplo

KPI: El servicio se encuentra disponible como se espera

Puede incluir:• Tiempo de actividad del sistema• Tiempo de actividad de la red• Tiempo de actividad del almacenamiento• Tiempo de respuesta ante incidentes

Marca de agua baja: Nivel de aceptación mínimo

Marca de agua alta: Logro objetivo

Logro realSLA agregado y ejecutado

KPI de valor comercial adicionales y sugeridos para suscriptores de la nube

Los suscriptores de la nube deben considerar el desarrollo de KPI internos, que pueden usarse para evaluar el valor producido por sus negocios a partir de la adopción de CIaaS. Estos son opcionales, pero pueden incluir lo siguiente:22

• Estadísticas que miden el rendimiento del servicio de acuerdo con los planes de TI y de negocios estratégicos.

• Estadísticas sobre riesgos y cumplimiento en lo que respecta a requisitos regulatorios, de seguridad y de gobierno corporativo para el servicio.

• Estadísticas que miden las contribuciones financieras del servicio al negocio.



5.0 InteroperabilidadLa interoperabilidad está relacionada con la portabilidad de cargas de trabajo, la interconectividad de las nubes y la capacidad de integrar sistemas. La interoperabilidad es importante para los suscriptores de la nube porque ayuda a prevenir la dependencia de un proveedor y al mismo tiempo garantiza la flexibilidad al suscriptor. Permite que las decisiones de servicio informático estén menos asociadas con las prioridades del negocio. La interoperabilidad también es importante para los proveedores de la nube porque ayuda a prevenir descalificaciones por parte de clientes potenciales que teman depender de un proveedor.

Tal como se analiza en el Modelo de uso de ODCA: Guía para la lograr la interoperabilidad entre nubes,17 existen dos aspectos clave de la interoperabilidad: la portabilidad de las cargas de trabajo y la interconectividad de sistemas. Cada uno de estos aspectos tiene su propio conjunto de requisitos únicos.

• La portabilidad debe ser desencadenada según sea necesario, como un evento, que incluya el mantenimiento del acceso a los datos y el control de la carga de trabajo, y que permita una configuración y reconfiguración dinámicas.

• La interconectividad aborda la necesidad de que las aplicaciones y los servicios establezcan y preserven de manera continua, conexiones complejas entre diferentes sistemas.

6.0 Impulsores del negocio y escenarios de usoEl objetivo de este modelo de uso principal no es definir en detalle lo que los proveedores de servicios proporcionan en términos de arquitectura técnica precisa. Algunos consumidores desean que los proveedores proporcionen una infraestructura de nivel “empresarial”, es decir, una infraestructura informática que pueda reemplazar una infraestructura interna gestionada y provista por una empresa y que pueda usarse de manera intercambiable. Sin embargo, las economías y los beneficios reales del modelo de nube provienen de enfoques donde las aplicaciones están diseñadas y desarrolladas desde la base para aprovechar los servicios comunes de productos disponibles a través de múltiples proveedores. Existen dos enfoques para tener en cuenta: ¿debería la nube adaptarse a los requisitos de la empresa heredados, como en el caso de las aplicaciones tradicionales, o debería la empresa adaptarse a la nube, como en el caso de las aplicaciones para nubes?

La respuesta es ambas. Las grandes empresas tienen respectivamente grandes carteras de aplicaciones, muchas de las cuales han sido diseñadas e implementadas dentro de entornos informáticos distribuidos tradicionales. Estas empresas no tienen ni el deseo ni la justificación económica para refactorizar su propiedad entera de aplicaciones para aprovechar de manera óptima el modelo de entrega de la nube. Con el tiempo, se puede esperar que las empresas se adapten al modelo de entrega de la nube. Sin embargo, esto será un viaje extenso. Existe una oportunidad para que los proveedores de servicios ofrezcan una amplia gama de capacidades y niveles de servicios, que abarca desde una infraestructura informática de “nivel empresarial” a una capacidad de consumo completamente masivo.

Garantizar que los proveedores de servicios ofrezcan entornos, servicios y herramientas asociadas que permitan a las empresas funcionar de manera efectiva y eficiente en estos entornos híbridos será la clave, ya que la penetración de la informática en la nube aumenta y las empresas también continúan aprovechando al máximo sus inversiones existentes.

6.1 Escenarios de USO comercialEn esta sección, proponemos algunos ejemplos de escenarios de uso comercial para la implementación de CIaaS. Para cada uno, presentamos los atributos generales del servicio de los escenarios de uso. Estos atributos generales están elaborados de manera más detallada en otra parte de este documento. Para obtener información más detallada, consulte las secciones “Arquitectura técnica” y “Niveles de servicio”.

Los escenarios de uso contemplados aquí no tienen como objetivo ser exhaustivos, sino más bien, ser representativos de los tipos de problemas comerciales para los que los servicios de CIaaS son apropiados. Existen otras innumerables combinaciones posibles de requisitos. El marco de CIaaS propuesto por este modelo de uso principal deber permitir al lector describir de manera similar otros escenarios de uso.

KPI de relación adicionales y sugeridos para proveedores de la nube

A continuación figuran algunos KPI sugeridos, a los que los proveedores de la nube deben realizarles seguimientos para garantizar la satisfacción de los clientes y para evaluar los servicios en comparación con sus pares.22 De ser posible, los proveedores de la nube también deben mantener un diálogo abierto y continuo con los suscriptores de la nube empresarial, en lo que respecta a los KPI de "valor comercial" que se mencionaron anteriormente. Estos son opcionales, pero pueden incluir lo siguiente:

• Estadísticas que monitorean los procesos claves de TI que soportan el servicio.

• Estadísticas que miden la satisfacción del cliente.



Figura 6.1.1 Escenarios de uso modelo de CIaaS

Escenariosde uso

de CIaaS

ProducciónNo relacionado

con la producción

Desarrolloestratégico

Pruebasy desarrollos

ad hoc

Control decalidad

Base Variable

Independiente Empresarial EmpresarialDistribución

Tradicional Para la nube

Desarrollo/prueba

Pruebade carga

Tradicional Para la nube

Por momentos, también haremos referencia a los entornos de nubes híbridas. Existe un requisito para que los profesionales de operaciones de TI puedan gestionar y medir la ejecución de sistemas detrás del firewall e informar sobre ella, de manera uniforme y compatible con los sistemas de la nube, ya sean tradicionales o para la nube. El sector puede y debe proporcionar esta capacidad para que los suscriptores de la nube puedan funcionar en entornos híbridos.

Tenga en cuenta que los escenarios de uso que figuran a continuación no diferencian entre los escenarios internos que usan los empleados y los escenarios externos que usan los clientes o el público. Sin embargo, es razonable asumir que cuando se indican niveles de servicios de atributos múltiples, los requisitos que usan los clientes y el público excederán, con frecuencia, a aquellos escenarios internos que usan los empleados. La criticidad del negocio también se indica para cada ejemplo.

La mayoría de los escenarios de uso que figuran a continuación se mencionan y se expanden en escenarios previamente documentados por el grupo Enterprise Cloud Leadership Council (ECLC) de TM Forum.

Para los escenarios de uso de producción que se incluyen a continuación, la prioridad del SLA del cliente surgió como resultado de los siguientes supuestos de escenarios:

• Para eventos y solicitudes de prioridad alta, tal como se acordó entre el proveedor y el suscriptor de la nube.

• Tiempo de respuesta: bronce, 4 horas; plata, 1 hora; oro, 10 minutos; platino, de manera inmediata o instantánea.

A continuación, presentamos un simple diagrama que ilustra la jerarquía de escenarios de uso descritos en este modelo de uso. Las aplicaciones tradicionales y para la nube se describen en otra parte.


6.2 Desarrollo/PruebaEsta es una subclase de uso de CIaaS no relacionado con la producción. Para este ejemplo, suponemos cargas de trabajo tradicionales o que no sean para la nube. A continuación presentamos la descripción del ECLC:

Este es uno de los escenarios de uso más obvios y accesibles para CIaaS, ya que los entornos de prueba y desarrollo son típicamente temporales y desechables. Al adoptar CIaaS para las tareas de desarrollo y prueba, los entornos pueden segregarse, o aislarse de manera lógica, más fácilmente de la producción; lo que ayuda a eliminar interdependencias y consecuencias negativas que deriven de interacciones inadvertidas con los sistemas de producción. Estos entornos también pueden proporcionarse e implementarse mucho más rápido que lo que sería factible con sistemas físicos, lo que permite mejorar la agilidad del negocio y el tiempo de salida al mercado.

Los requisitos para las tareas de desarrollo y prueba en la nube pueden dividirse aún más en otras tres subclases: desarrollo estratégico, pruebas y desarrollos ad hoc y control de calidad.

•Desarrollo estratégico: grandes esfuerzos de desarrollo de software a largo plazo, esenciales para el negocio del suscriptor de la nube.

• Pruebas y desarrollos ad hoc: desarrollo de software informal, experimental y a corto plazo que no es esencial para el negocio del suscriptor de la nube.

•Control de calidad: las pruebas formales de software por parte del suscriptor de la nube, como parte del control de calidad, la integración de sistemas u otras pruebas de software formales similares que son esenciales para el negocio del suscriptor de la nube. Esto requerirá una mayor uniformidad de rendimiento y resistencia por parte del servicio de nube.

Tabla 6.2.1. Requisitos para el desarrollo y las pruebas

19


Requisito(O: opcional; N: necesario)

Desarrollo estratégico Pruebas y desarrollos ad hoc

Control de calidad

Criticidad del negocio Baja o media Baja Baja o media

Atributo del servicio Nivel Nivel Nivel

Disponibilidad Bronce o plata Bronce Bronce o plata

Rendimiento Bronce Bronce Bronce o plata

Capacidad de recuperación Bronce o plata Bronce Bronce o plata

Seguridad Plata u oro Plata Plata u oro

Elasticidad Bronce Bronce Bronce

Capacidad de gestión Plata Bronce o plata Plata

Prioridad del SLA del cliente Bronce Bronce Bronce

Interoperabilidad Plata Bronce Plata


6.3 Entorno de prueba de tensión de cargaEsta también es una subclase de uso de CIaaS no relacionado con la producción. Para este ejemplo, suponemos cargas de trabajo tradicionales o que no sean para la nube. De la descripción del ECLC sobre el escenario de uso con el mismo nombre:

“Este escenario de uso emerge como un habilitador clave para los negocios en línea y para otros negocios que requieren un escalamiento masivo. Como una extensión de las tareas de desarrollo y prueba, la prueba de carga es un dominio especializado que puede usarse para detectar debilidades algorítmicas que solo surgen en sistemas a escala. Si bien una aplicación puede funcionar según lo esperado, ya sea como una unidad simple o como parte de un clúster pequeño, al duplicar o aumentar de manera exponencial la cantidad de nodos de procesamiento pueden producirse resultados inesperados. CIaaS le permite al desarrollador simular este escalamiento, usando un recurso externo o interno compartido que elimina el gasto de capital que se requeriría para proporcionar la capacidad necesaria para los niveles de carga hipotéticos. Además, los sistemas cliente-servidor pueden beneficiarse de la nube al aprovechar la capacidad de CIaaS de simular grandes cantidades de clientes para aumentar la carga en sus servidores”.

Asimismo, ahora existen medios por los cuales las secuencias de comandos de prueba reflejan patrones de transacciones de usuarios reales que ocurren de manera simultánea y que provocan una tensión en los servicios subyacentes de IaaS de diferentes maneras. Las pruebas de tensión de carga deben incorporar patrones de uso de usuarios reales a partir de sistemas de monitoreo de usuarios reales para implementar estas pruebas.

Tabla 6.3.1. Prueba de tensión de carga

20



Prueba de tensión de carga

Criticidad del negocio Baja

Atributo del servicio Nivel

Disponibilidad Bronce

Rendimiento Oro (la fidelidad con el entorno de producción objetivo es un factor clave)

Capacidad de recuperación Bronce

Seguridad Bronce o plata

Elasticidad Plata u oro

Capacidad de gestión Plata

Prioridad del SLA del cliente Bronce

Interoperabilidad Bronce



6.4 Informática distribuida y de alto rendimientoLas aplicaciones de Informática distribuida y de alto rendimiento (HPC) pueden ser tradicionales o para la nube. Debido a su patrón informático distribuido, paralelo o inherente, las aplicaciones distribuidas generalmente se ajustan bien a las arquitecturas de nube. Para este ejemplo, suponemos que la aplicación distribuida es una aplicación para la nube. Sin embargo, un sistema distribuido, tradicional y que no sea para la nube no debe tener requisitos substancialmente diferentes.

De la descripción del ECLC para las aplicaciones de informática distribuida:

“Si bien la informática distribuida antecede a la informática en la nube, la nube se puede usar para optimizar los modelos de uso basados en la distribución. Teniendo en cuenta que la informática clásica distribuida se almacenaba tradicionalmente en una granja estática de servidores informáticos físicos, CIaaS ofrece una gestión dinámica de capacidad, que permite que la distribución lógica se expanda y contraiga según la demanda del negocio y los costos o beneficios marginales, para habilitar nodos de procesamiento paralelos adicionales”.

Los requisitos para la informática distribuida y de alto rendimiento en la nube pueden dividirse aún más en otras dos subclases: capacidad de distribución base y distribución variable.

Tabla 6.4.1. Requisitos para la informática distribuida y de alto rendimiento


Capacidad de distribución base

Capacidad de distribución variable

Criticidad del negocio Alta Media o alta

Atributo del servicio Nivel Nivel

Disponibilidad Oro o platino Bronce

Rendimiento* De bronce a oro De bronce a oro

Capacidad de recuperación Bronce Bronce

Seguridad Oro o platino Oro o platino

Elasticidad Bronce Oro o platino

Capacidad de gestión Plata Plata

Prioridad del SLA del cliente Oro o platino Bronce

Interoperabilidad Plata u oro Plata u oro

Supuestos adicionales:

En los dos subtipos de escenario de uso mencionados anteriormente, suponemos explícitamente que en el modelo operativo, el suscriptor de la nube realiza su propia gestión y soporte desde el sistema operativo.

Ambos subtipos de escenarios de uso suponen cargas de trabajo de producción empresariales.

*Tenga en cuenta que el rendimiento puede ser tan bajo como de nivel bronce para las distribuciones de economías de bajo costo, según los requisitos del suscriptor de la nube y la sensibilidad del precio.



6.5 Entorno de producción independiente tradicionalEste entorno puede ser pensado como una implementación monolítica. Es un subtipo de las cargas de trabajo tradicionales o heredadas, migradas a la nube. Por ejemplo, una aplicación de producción de un equipo o departamento que es importante, pero no esencial para las operaciones diarias del negocio. La descripción del ECLC para una producción independiente es adecuada.

“Las aplicaciones con dependencias externas mínimas pueden ejecutarse más o menos aisladas de los entornos corporativos. Si bien se puede requerir una solución puente para integrarlas con servicios de identidades u otros servicios de directorios, o para conectarlas a otros flujos de trabajo del negocio, estas aplicaciones pueden funcionar bien en cualquier ubicación. Estos tipos de aplicaciones pueden ser adecuadas para implementarse en un entorno de CIaaS, ya que esto les permitiría beneficiarse de la migración o la extensión hacia otras ubicaciones geográficas para mejorar la productividad o los costos (estrategias follow-the-moon/follow-the-sun [seguir la luna/seguir el sol])”.

Este es un tipo específico de requisito de producción. Sin embargo, como sucede con otros escenarios de producción empresarial, el servicio, en este caso, es considerado como esencial para la misión. La pérdida del servicio informático tendrá impactos materiales negativos en el suscriptor de la nube, como una pérdida de ingresos o daño a la reputación.

Los entornos de producción independientes tienen como objetivo la cobertura de aplicaciones de grupos o departamentos que son consideradas de producción a los fines del soporte y la recuperación, pero tienen un impacto limitado en el negocio. Ejemplos de estos entornos son los servidores de archivos internos, los servidores web y los sitios de colaboración. La pérdida de estos servicios se considera un inconveniente más que una interrupción a las operaciones del negocio y las soluciones manuales, si bien son posibles, son poco deseadas.

Tabla 6.5.1 Producción independiente habilitada para la nube


Producción independiente habilitada para la nube

Criticidad del negocio De baja a media


Disponibilidad Plata o superior

Rendimiento Plata o superior

Capacidad de recuperación Plata o superior

Seguridad Plata o superior

Elasticidad Bronce

Capacidad de gestión Plata

Prioridad del SLA del cliente Plata



6.6 Entorno de producción empresarial tradicional Estos entornos son, en general, sistemas informáticos distribuidos heredados que se han migrado a la nube, pero que no han sido completamente remediados como para formar parte de la nube. Esta es una subclase de uso de producción.

Las aplicaciones empresariales difieren de las aplicaciones de producción independientes en su alcance e importancia para la organización. Estas son aplicaciones esenciales para la misión que afectan la reputación y el flujo de ingresos de una organización. La pérdida del entorno de producción empresarial tendría como resultado una pérdida significativa de ingresos o daño a la reputación del suscriptor. Ejemplos de estos son los sistemas de transacciones de grandes volúmenes (Planificación de recursos empresariales, ERP), los sitios web de clientes, los sitios de integración de socios y los sistemas de procesamiento de datos financieros donde las opciones de procesamiento manual no son posibles debido al volumen o a la naturaleza de las transacciones.

Estas aplicaciones tienen dependencias externas y requisitos de integración. Es posible que se requieran soluciones puente para integrarlas con servicios de identidades u otros servicios de directorios, o para conectarlas a otros flujos de trabajo del negocio. Es posible que no puedan explotar completamente la elasticidad de la nube. En comparación con las aplicaciones “independientes”, estas aplicaciones son más grandes y más complejas y, posiblemente, no sean adecuadas para la migración de una ubicación geográfica a otra, debido al tamaño o volumen de los datos requeridos.

Tabla 6.6.1 Producción empresarial tradicional


Producción empresarial tradicional

Criticidad del negocio De media a alta


Disponibilidad Oro o platino

Rendimiento Oro o platino

Capacidad de recuperación Oro o platino

Seguridad Oro o platino

Elasticidad Bronce o plata

Capacidad de gestión Oro

Prioridad del SLA del cliente Oro o platino

Interoperabilidad Plata u oro



6.7 Entorno de producción empresarial para la nube Este entorno puede ser considerado como un conjunto de sistemas informáticos que, aunque no están basados completamente en PaaS, han sido diseñados para la nube desde el comienzo. Estos sistemas pueden incluir aplicaciones web más nuevas, pueden aprovechar una mayor automatización y pueden consultarle al servidor de la infraestructura sobre la capacidad disponible, los servicios y demás. Esta es una subclase de uso de producción.

Las aplicaciones para la infraestructura son aplicaciones más nuevas desarrolladas para tolerar las fallas de los componentes subyacentes de la infraestructura. Estas aplicaciones usan los servicios de los proveedores de infraestructura para recuperarse de las interrupciones de funcionamiento de los componentes o pueden escalarse según sea necesario para afrontar las demandas de carga de trabajo de las aplicaciones. Al igual que con la variante de la informática distribuida tradicional, la pérdida de la aplicación de producción daría como resultado una pérdida significativa de ingresos o daño a la reputación del suscriptor. La diferencia es que la aplicación tiene una arquitectura para ser ejecutada en una infraestructura con un nivel más bajo de servicio, confiabilidad y disponibilidad. Estas aplicaciones también pueden distribuirse en los recursos de múltiples proveedores.

Estas aplicaciones tienen dependencias internas y externas, y requisitos de integración.

Tabla 6.7.1 Producción empresarial para la nube


Producción empresarial para la nube

Criticidad del negocio Media o alta


Disponibilidad Plata o superior

Rendimiento Bronce o superior

Capacidad de recuperación Oro o platino

Seguridad Oro o platino

Elasticidad Oro o platino

Capacidad de gestión Oro o platino

Prioridad del SLA del cliente Oro o platino

Interoperabilidad Oro o platino

6.8 Gestión de servicios y federación en la nubeLa gestión de servicios y la federación en la nube son una parte importante del ecosistema de la nube y serán abordados en una actualización futura del Modelo de uso principal de ODCA: Infraestructura informática como servicio (CIaaS).

http://www.opendatacenteralliance.org/docs/ODCA_Compute_IaaS_MasterUM_v1.0_Nov2012.pdf



7.2.1 Resumen de los niveles de servicio: disponibilidadElementos Bronce Plata Oro Platino

Disponibilidad general 99 % 99.9 % 99.9 % 99.99 %

Ventana de mantenimiento Fija Fija Flexible Flexible

Frecuencia de interrupciones no planificadas y permisibles* 2 1 0 0

RTO por incidente** 60 min 30 min 0 min 0 min

Duración de las interrupciones objetivo no planificadas y acumuladas

120 min 30 min 0 min 0 min

Interrupciones de conectividad a Internet, no planificadas y permisibles

3 2 0 o 1 0

Sanción por violación del SLA Ninguna Sí Sí Sí

* Cantidad de interrupciones dentro de una ventana de tiempo especificada y alineada con períodos de facturación. Todos los créditos por sanción existentes se aplicarán al ciclo de facturación correspondiente. El objetivo aquí es abordar comportamientos intermitentes o temporales, donde las interrupciones y las interferencias sean muy breves, pero puedan impactar materialmente en el rendimiento de la carga de trabajo o la calidad del servicio.

**Tiempo total de duración por incidente de interrupción

7.0 Detalles de los atributos del servicioCada uno de los atributos del servicio presentados anteriormente se explica con más detalle a continuación. Cada atributo se subdivide en uno o más elementos. Juntos, los valores de los elementos determinan el nivel de servicio de ese atributo. Se deben cumplir todos los elementos que conforman el nivel de servicio de un atributo dado. Por ejemplo, deben cumplirse todos los subrequisitos para el rendimiento de nivel oro para que el rendimiento se considere en el nivel de servicio oro. Los siguientes supuestos rigen para cada sección de atributos del servicio a continuación:

Estandarización: los servicios del proveedor de la nube son uniformes y estandarizados.

Se encuentra disponible la documentación.

7.1 FuncionalidadLa infraestructura debe admitir servicios de nube básicos y funcionales, según la definición del NIST. El proveedor debe admitir al menos la versión n.º 1 de la última actualización de los estándares de servicios de nube actuales y futuros, que se encuentran especificados aquí o que son proporcionados como respuesta a los requisitos de ODCA por las Organizaciones de desarrollo de estándares (SDO).

7.2 DISPONIBILIDADEn el Modelo de uso de ODCA: Unidades de medida estándares para IaaS,15 ODCA ha definido la disponibilidad como el grado de tiempo de actividad para la solución, teniendo en cuenta, por ejemplo, las probabilidades de contención de recursos. Esto debe entenderse como un servicio general en su totalidad. Existen algunos aspectos generales que se deben abordar con respecto a la disponibilidad de CIaaS. El alcance de la disponibilidad de CIaaS incluye lo siguiente:

• Cantidad de disponibilidad general, por ejemplo el número de nueves.

• Conexión desde los Puntos de presencia (POP) o puntos de conexión de Internet del proveedor.

• La manera en que se definen las ventanas de mantenimiento, por ejemplo, de manera fija si lo elige el proveedor de la nube o de manera flexible si lo elige el suscriptor de la nube.

• La posibilidad de definir “ventanas de tiempo críticas” estaría disponible en las versiones flexibles.

• Tenga en cuenta que las ventanas de mantenimiento planeadas y acordadas por contrato no cuentan para los objetivos de disponibilidad.

• La duración de la interrupción objetivo en oposición a la cantidad de interrupciones. Algunas cargas de trabajo pueden manejar de mejor manera las interrupciones cortas, incluso aunque existan muchas. Otras cargas necesitan tener la menor cantidad de interrupciones posibles, lo que genera un tiempo de inactividad más largo para cada una de ellas.

• Existencia de sanciones especificadas por contrato e impuestas en caso de violación del SLA, como se muestra en la tabla a continuación.




7.3 Capacidad de recuperaciónODCA ha definido la capacidad de recuperación como los objetivos de tiempo de recuperación y punto de recuperación de la solución.15 Esto debe entenderse para la recuperación del servicio general en su totalidad. Existen algunos aspectos generales que se deben abordar con respecto a la capacidad de recuperación de CIaaS. El alcance de la capacidad de recuperación de CIaaS incluye lo siguiente:

• Copias de seguridad y restauración con o sin revisiones graduales

• Tiempo medio para la recuperación

• Cantidad o frecuencia de puntos de recuperación

7.3.1 Resumen de los niveles de servicio: capacidad de recuperación

Elementos(O: opcional; N: necesario)

Bronce Plata Oro Platino

Copia de seguridad de los datos

Sin copia de seguridad

Una copia Dos copias Tres copias

Dispersión geográfica de las copias de seguridad de los datos

Ninguna Un sitio Dos sitios Tres sitios y fuera del sitio

RTO para la restauración de datos

N/C Dentro de las doce horas de la restauración del servicio

Dentro de las nueve horas de la restauración del servicio

Dentro de las seis horas de la restauración del servicio

Replicación de datos Ninguna Ninguna Instantánea, al menos cuatro veces al día

Sincrónica y asincrónica a sitios remotos

Frecuencia de la copia de seguridad

N/C Semanal, completa Diaria, gradual; semanal, completa

Diaria, completa

RTO para la restauración de instancias informáticas

Responsabilidad del suscriptor

60 minutos 15 minutos 10 minutos

RCO para datos distribuidos Ninguno 80 % 90 % 100 %



7.4 SeguridadODCA ha definido a la seguridad como el alcance de la protección del proveedor de la nube o de la solución de la nube. A continuación se encuentra el detalle de los elementos de seguridad que se deben abordar:

• Antivirus y protección contra malware (con actualizaciones de definiciones dentro de las 24 horas)

• Existe un proceso de gestión de vulnerabilidades y está completamente probado para garantizar que no haya ningún impacto en los host objetivo

• Aislamiento de red y firewall de los sistemas del suscriptor de la nube

• Control de acceso físico al centro de datos de la nube

• Protocolos de seguridad usados para la administración remota (por ejemplo, SSL, SSH y RDP)

• Se eliminan todas las contraseñas predeterminadas y el acceso de invitado

• Uso de Acuerdos de confidencialidad (NDA) para el personal del proveedor de la nube

• Uso de los procesos de la Biblioteca de infraestructura de tecnología de la información (ITIL) para la gestión de configuración, incidentes y cambios

•Gestión de identidades para los activos del suscriptor

• Retención y eliminación gestionadas de los datos

•Monitoreo de eventos e incidentes de seguridad

• Prevención de intrusiones en la red

• Registro de todos los eventos en el ámbito de la administración (requiere acceso controlado a los registros)

• Principio de supervisión doble (Four-eye principle) para los cambios claves del administrador

• El proveedor de la nube tiene un plan de continuidad técnica implementado y probado

• Red controlada y documentada por completo

•Opción para realizar pruebas de penetración en sistemas hospedados

• Segmentación física de hardware (servidor, almacenamiento, red, etc.) para garantizar el aislamiento de todos los otros sistemas

• Comunicación cifrada entre el proveedor y el suscriptor de la nube para la gestión

• Autenticación de varios factores

• Capacidad del suscriptor de la nube de definir límites geográficos para el hospedaje

• Cifrado del almacenamiento en el nivel de número de unidad lógica (LUN)

• Sin acceso administrativo para el personal del proveedor de la nube

• Cifrado de alta seguridad para todos los datos al vuelo y en reposo



7.4.1 Resumen de los niveles de servicio: seguridad

Elementos (O: opcional; N: necesario) Bronce Plata Oro Platino

Antivirus y protección contra malware con actualizaciones de definiciones dentro de las 24 horas

N N N N

Existe un proceso de gestión de vulnerabilidades y se pone a prueba completamente para garantizar que no haya ningún impacto en los host objetivo

N N N N

Aislamiento de red y firewall de los sistemas del suscriptor de la nube N N N N

Control de acceso físico al centro de datos de la nube N N N N

Protocolos de seguridad usados para la administración remota (por ejemplo, SSL, SSH y RDP)

N N N N

Se eliminan todas las contraseñas predeterminadas y el acceso de invitado N N N N

Uso de Acuerdos de confidencialidad (NDA) para el personal del proveedor de la nube N N N N

Uso de los procesos de la Biblioteca de infraestructura de tecnología de la información (ITIL) para la gestión de configuración, incidentes y cambios

N N N N

Gestión de identidades para los activos del suscriptor (Consulte el Modelo de uso principal de ODCA: Guía de interoperabilidad para la gestión de identidades)

N N N N

Retención y eliminación gestionadas de los datos N N N N

Monitoreo de eventos e incidentes de seguridad N N N N

Prevención de intrusiones en la red O N N N

Registro de todos los eventos en el ámbito de la administración (requiere acceso controlado a los registros)

O N N N

Principio de supervisión doble (Four-eye principle) para los cambios claves del administrador

O N N N

El proveedor de la nube tiene un plan de continuidad técnica implementado y probado O N N N

Red controlada y documentada por completo O N N N

Opción para realizar pruebas de penetración en sistemas hospedados O O N N

Segmentación física de hardware (servidor, almacenamiento, red, etc.) para garantizar el aislamiento de todos los otros sistemas

O O N N

Comunicación cifrada entre el proveedor y el suscriptor de la nube para la gestión O O N N

Autenticación de varios factores de la nube para el acceso administrativo del proveedor N N N N

Oferta de capacidad de autenticación de varios factores para la nube para el acceso administrativo del suscriptor

O O N N

Capacidad del suscriptor de la nube de definir límites geográficos para el hospedaje O O N N

Cifrado del almacenamiento en el nivel de número de unidad lógica (LUN) O O N N

Sin acceso administrativo para la nube para el personal del proveedor O O O N

Cifrado de alta seguridad para todos los datos al vuelo y en reposo O O O N

http://www.opendatacenteralliance.org/document-sections/category/71-docs?download=676:HODCA_%20IdM_%20InteropGuide_Rev1%200_final




7.5 ElasticidadODCA define la elasticidad como la capacidad de configuración y expansión de la solución (coincide con la taxonomía según el NIST7,23). Básicamente, es la capacidad de escalar y reducir la capacidad según la carga de trabajo del suscriptor. Existen algunos aspectos generales que se deben abordar con respecto a la elasticidad de CIaaS.

El alcance de la elasticidad de CIaaS incluye lo siguiente:

• Capacidad para escalar y reducir el tamaño

• La definición de una o más políticas que controlan cómo debe ser escalada la aplicación del suscriptor de la nube

• Capacidad de respuesta, como la velocidad del escalamiento dinámico

• Configuración de clones

• Configuración del entorno, como los elementos de seguridad y de red

• Ejecución de tareas adicionales desencadenadas

• Proporción posible, hasta X veces la cantidad inicial de instancias

• Capacidad de automatización, a través de una API

•Notificación

•Manejo de excepciones

Niveles de servicio

La capacidad de escalar depende de los recursos informáticos, la red, la cuota de almacenamiento y el plazo de arrendamiento.

Aumento (capacidad de respuesta e índice de aumento)

• Tanto los suscriptores como los proveedores tienen la responsabilidad de planificar en función de las necesidades de capacidad y de predecir respectivamente, pero el enfoque, por supuesto, se centra en las responsabilidades del proveedor.

• Un área que se podría considerar para la diferenciación potencial del proveedor es la forma de arbitrar la contención del suscriptor. Es decir, ¿qué sucedería si varios clientes compiten por una cantidad limitada de recursos? ¿Quién debería poder obtener los recursos? ¿Deberían considerarse otras cuestiones económicas de mercado? ¿Quizás quienes pagan por los niveles oro o platino tienen prioridad?

• Los proveedores de la nube tienen oportunidades adicionales para la diferenciación a través de una combinación de opciones, como por ejemplo:



7.5.1 Resumen de los niveles de servicio: elasticidad

Elementos Bronce Plata Oro Platino

Admite escalamiento horizontal

Sí o no Sí Sí Sí

Admite escalamiento vertical Sí o no Sí o no Sí o no Sí o no

Capacidad de automatización a través de una API

Sí o no Sí Sí Sí

Crecimiento (escalamiento horizontal)

<=10 % <=10 % 25 % dentro de las 2 horas

50 % dentro de las 24 horas

100 % dentro de las 2 horas

> 1000 % dentro del mes

Capacidad de respuesta Dentro de los cinco días hábiles

Dentro del día hábil

Del 300 al 1000 % dentro del mes

7.6 Servicios de capacidad de gestiónODCA define la capacidad de gestión como el grado de automatización y disponibilidad de control para gestionar la solución. Existen algunos aspectos generales que se deben abordar con respecto a la capacidad de gestión de CIaaS. Tenga en cuenta que esta sección aborda la gestión de las diferentes características del servicio que figuran a continuación y no las características en sí mismas.

El alcance de la capacidad de gestión de CIaaS incluye lo siguiente:

Monitoreo del rendimiento, los eventos y la disponibilidad de:

• infraestructura

º recursos informáticos

º almacenamiento

º red

•máquinas virtuales, cuando se usan

• regiones y zonas de disponibilidad

• aplicaciones y los servicios

• correcciones

Esto abarca la gestión del comportamiento automatizado, desencadenado por los problemas en los servicios de nube, como las secuencias de comandos que se ejecutan en respuesta a una pérdida de paquetes inaceptablemente alta o a una recolocación automática de la capacidad en la nube pública si la utilización impacta en el umbral designado. Para ser claros, esto no incluye la funcionalidad de corrección dada, sino que solo incluye la gestión de dicha funcionalidad.

• Tareas programadas y automatizadas

• Escalamiento automatizado (elasticidad de demanda y suministro)

• Autorecuperación de aplicaciones y servicios



•Notificación

º Se debe utilizar un modelo publicación y suscripción

º Debe admitir varios canales para recibir mensajes, como SMS, correo electrónico, localizador, cola de mensajes y demás

• Elaboración de informes de rendimiento, eventos y disponibilidad

•Gestión de copias de seguridad y recuperación de datos

API de servicios web para la integración y la recuperación de datos: el suscriptor de la nube debe poder crear secuencias de comandos de lo que necesita. Esto incluye la habilitación del monitoreo del nivel de aplicación, donde el monitoreo de la infraestructura debe tener capacidad de extensión o de adaptar de otra manera la gestión y el monitoreo del nivel de aplicación.

Niveles de servicioA continuación figuran los niveles de capacidad y funcionalidad sugeridos para determinados elementos de capacidad de gestión. A los fines de realizar calibraciones y comparaciones, se han especificado umbrales, en la medida de lo posible, para cada nivel de servicio. A menos que se especifique de otra manera, estos umbrales se definen por instancia informática. Tenga en cuenta que un proveedor de la nube puede consolidar los eventos para el servicio en general. A fin de realizar una comparación, aquí se indican para cada instancia.

Monitoreo

Monitores de rendimiento y eventos:

• Tenga en cuenta que el monitoreo básico abarca estadísticas de rendimiento del sistema central tal como informan típicamente los sistemas operativos modernos. Utilización de memoria y CPU, red y E/S de disco, etc.

• Para cada nivel, puede haber una cantidad ilimitada de monitores definidos, pero inactivos. Sin embargo, solo un máximo fijo de monitores puede estar activo y generando informes en cualquier momento, como se muestra a continuación.

7.6.1 Resumen de los niveles de servicio: Monitoreo

7.6.2 Resumen de los niveles de servicio: intervalo de muestreo informado

Elementos Bronce Plata Oro Platino

Básicos Sí Sí Sí Sí

Monitores personalizados: definidos Ilimitados Ilimitados Ilimitados Ilimitados

Monitores de clientes: activos 5 10 30 50

Nivel de servicio Intervalo de muestreo informado (minutos)

Bronce 15

Plata 10

Oro 5

Platino 1 minuto o mejor

Frecuencia o intervalos de la recopilación de datos:

• Esto se refiere a los datos que son expuestos o que se encuentran disponibles para el suscriptor de la nube. La resolución de datos real y mantenida por el proveedor de la nube en segundo plano queda a criterio del proveedor de la nube.

• Al especificar la frecuencia de la recopilación de datos, garantiza que esta se concilie de manera adecuada con los umbrales de capacidad de recuperación y disponibilidad del servicio.



Notificación:

• Funciones estándares disponibles para todos los niveles de servicio.

Corrección:

• La corrección en este contexto se refiere simplemente a la gestión de las acciones de corrección o recuperación automatizadas del servicio. No se trata de la corrección en sí, sino más bien de la gestión de las capacidades de corrección.

Tareas programadas o automatizadas:

7.6.3 Resumen de los niveles de servicio: cantidad de tareas automatizadas activas

7.6.4 Resumen de los niveles de servicio: Elaboración de informes

Nivel de servicio Cantidad de tareas automatizadas activas

Bronce 5

Plata 10

Oro 30

Platino 50

Elaboración de informes:

• Para ser claros, esto se trata de la elaboración de informes de los datos de rendimiento y eventos, y no de los datos de aplicaciones reales del suscriptor de la nube.

•ODCA anticipa que las consideraciones de costo y almacenamiento pueden limitar el período durante el cual los datos de informes de alta resolución y fidelidad pueden retenerse de manera rentable. Por lo tanto, nuestra recomendación general es que el período más reciente de entre 10 y 20 % (aproximadamente) para cada período de duración total que se encuentra a continuación debe tener una resolución total. El período restante puede tener una resolución agregada o reducida.

Elementos Bronce Plata Oro Platino*

Alta resolución (días) 1 20 90 1 año o mejor

Resolución reducida (días; período de duración total) 10 180 365 5 años o mejor

*Tenga en cuenta que puede existir una diferencia importante en el nivel platino, debido a los requisitos regulatorios de los diferentes sectores y jurisdicciones.

Copia de seguridad

• Existe una oportunidad para la diferenciación del proveedor, como la cuota de almacenamiento.

• Intervalo de copia de seguridad; consulte la sección “Capacidad de recuperación”.

• Período de retención de datos; consulte la sección "Capacidad de recuperación".

Disponibilidad:

• Es igual que los objetivos de tiempo de actividad general que aparecen en la sección “Disponibilidad” de este documento.



7.7 Rendimiento

7.7.1 SLA de rendimientoSe hace referencia al rendimiento en varios documentos de ODCA. Estas secciones definen los requisitos desde la perspectiva del suscriptor y del proveedor.

Catálogo de servicios: los parámetros de rendimiento son parte de los atributos del producto y en consecuencia, así son definidos. Se requiere una API para permitir el acceso mediante programación. Se requiere una interfaz de usuario para un acceso humano conveniente.

La arquitectura debe proporcionar elementos que informen estos valores que figuran a continuación. Para poder manejar estas diferentes actividades, se deben dividir los valores de rendimiento en diferentes áreas de procesamiento:

•Medición del rendimiento

• Elaboración de informes de rendimiento

•Monitoreo del rendimiento

• Análisis del rendimiento

• Interfaz y definición del rendimiento

La arquitectura debe proporcionar interfaces para todos los métodos mencionados anteriormente.

7.7.2 Medición del rendimientoTodas las áreas de red, almacenamiento, servidores y niveles deben proporcionar interfaces para medir el rendimiento de forma granular. La plataforma de CIaaS también debe permitir que la medición del rendimiento en los niveles de la aplicación sea de fácil implementación o adaptación, en caso de que no sea un aspecto integrado de la oferta. La función de análisis debe incluir hasta un intervalo de un milisegundo como mínimo.

Granularidad de medición que debe exponer el proveedor de la nube: puede ser amplia para los niveles de servicio más bajos, y más detallada para los niveles de servicios más altos.

Mientras más alto sea el nivel de servicio, más grande debe ser el alcance de la medición. Las medidas de los componentes no correlativas y simples son adecuadas para los niveles de servicio más bajos; se esperan medidas correlativas y completas para los niveles de servicio más altos.

Mientras más alto sea el nivel de servicio, más estadísticas deberá exponer el proveedor de la nube.

7.7.3 Elaboración de informes de rendimiento La arquitectura debe proporcionar una interfaz para elaborar informes sobre el rendimiento. Debido a la naturaleza variable del rendimiento, puede que no sea posible elaborar informes definitivos respecto de si el sistema puede proporcionar los valores máximos contratados si no se observa que la aplicación del suscriptor alcanza estos valores. Por lo tanto, la arquitectura debe proporcionar un método para investigar si todos los elementos y todos los niveles pueden alcanzar sus valores de rendimiento. Dichas pruebas deben ser de dos tipos: una prueba que se ejecute en horas no pico en el sistema y de una manera “similar a la medición de entrada y salida (IO)” y una ejecución automática que el proveedor o el suscriptor puedan programar con una API que se encuentre marcada en todos los niveles de E/S y que vuelva a informar los valores de latencia y de ida y vuelta, y así sucesivamente. La arquitectura del proveedor debe tener elementos centrales, por ejemplo, en la forma de un almacén de datos donde se puedan generar informes personalizables y desde donde se puedan descargar los datos. Se encuentra disponible un nivel de presentación para que los suscriptores generen estos informes. El grado de elaboración de informes se relaciona con el nivel de servicio del atributo de rendimiento dado y acordado por contrato. Esta es un área de posible diferenciación para los proveedores de la nube.

7.7.4 Monitoreo del rendimientoSe requieren interfaces de monitoreo para enviar eventos al suscriptor y para integrarlas en las herramientas de monitoreo del suscriptor. Dada la importancia de estas interfaces, el monitoreo de su estado continuo es esencial.



Aplicaciones y SO deentrega de software

Configuración

Evento

Seguridad

Consume/suscribe

Proporciona

Instalación


Web Base de datos

PaaS

SaaS

Interoperabilidad de servicios web y de datos

IaaS



Espacio físico, enfriamiento, energía

Catálogo de servicios accionable (IU y API)


Instrumentación y gestión

dinámicas de servicios com

pletos

Usuariofinal

Desarrollo deaplicaciones

Operacionesde TI

34


7.7.5 Análisis del rendimiento La arquitectura debe admitir o proporcionar herramientas para analizar el rendimiento en un nivel más profundo. Con este fin, el suscriptor de la nube debe poder iniciar investigaciones y ejecuciones automáticas dentro de la capacidad del suscriptor de la nube y solo dentro de los parámetros operativos y de seguridad acordados por contrato.

7.7.6 Interfaz y definición de rendimientoLa arquitectura debe proporcionar una interfaz en la forma de una API a la cual el suscriptor pueda consultar para verificar las capacidades. Ya que la carga de trabajo de cada suscriptor es única, posiblemente sea difícil definir términos universales y concretos del SLA. Por ejemplo:

Una aplicación con lecturas aleatorias del 80 % y escrituras aleatorias del 20 % con un tamaño de bloque de 8 KB no es tan diferente de una con lecturas secuenciales del 20 % y escrituras secuenciales del 80 % con un tamaño de bloque de 32 KB. Estos tipos de valores no son generalmente prácticos para definir aplicaciones reales complejas con diversos perfiles de ejecución.

Para crear un valor de rendimiento comparable, debe existir algún tipo de comparación o punto de referencia. Las investigaciones permiten crear puntos de referencia personalizados que sean específicos para una aplicación, pero no pueden ejecutarse cuando la aplicación se encuentra en funcionamiento, como por ejemplo durante el manejo de transacciones, y solo muestran un punto simple en el tiempo.

Los puntos de referencia genéricos, por un lado, pueden sugerir características de rendimiento más amplias, pero con frecuencia, no representan el comportamiento de las aplicaciones reales, y de manera similar, no pueden ejecutarse simultáneamente con la aplicación misma. Ejemplos de puntos de referencia generales son SPC, SPECint, IOMeter, NetBench y IOZone. Tenga en cuenta que los puntos de referencia generales no son específicos para las necesidades del cliente, pero le permiten al suscriptor comparar diferentes ofertas de diferentes proveedores.

8.0 Interfaz del servicio y modelo de referencia

8.1 Arquitectura conceptual de ODCA

Figura 8.1.1. Marco conceptual de ODCA


8.2 Ciclo de vida básico de la nubeA continuación, presentamos un resumen de los pasos esenciales del ciclo de vida que están asociados con los servicios de infraestructura informática. Estos pasos se describen con más detalle en el Modelo de uso principal de ODCA: Instrumentación del servicio.21

1. Descubrimiento: el suscriptor de la nube obtiene una lista de servicios disponibles del proveedor de CIaaS. Este paso podría ser facilitado de manera opcional por un agente de servicios de la nube.

2. Negociación: el proveedor y el suscriptor de la nube negocian el contrato y los términos para los servicios de CIaaS. (Nota: Consulte los Modelos de uso de ODCA: Marco comercial12 y Marco regulatorio13 para obtener una cobertura detallada de las consideraciones y los requisitos relevantes). Este paso podría ser intermediado de manera opcional por un agente de servicios de la nube.

3. Aprovisionamiento: el suscriptor de la nube envía los requisitos al proveedor de la nube para el servicio que necesita. El proveedor de servicios de nube responde la solicitud de servicio.

4. Creación de instancias: el paso puede o no ser requerido en una situación dada. Esto implica que el suscriptor de la nube tome cualquier medida manual necesaria que facilite su uso del servicio de CIaaS.

5. Uso: el uso del servicio por parte del suscriptor de la nube hasta que dicho servicio se modifique o se dé por finalizado. Esto incluye la gestión del servicio, incluido el inicio, la suspensión, el monitoreo, la elaboración de informes, etc.

6. Modificación: este es un paso adicional donde el suscriptor de la nube vuelve a evaluar sus requisitos y puede negociar para modificar el servicio. Un ejemplo puede ser aumentar la capacidad de elasticidad que permite recolocar los recursos en la nube pública más allá de los niveles ya acordados.

7. Finalización: la finalización del servicio, de conformidad con el contrato negociado.

8.3 Requisitos de la interfaz del servicioComo sucede con cualquier arquitectura orientada al servicio, la interfaz de servicios de CIaaS debe proporcionar una separación entre la interfaz de un servicio y su implementación subyacente. Esto ocurre para garantizar que los suscriptores de nube (y sus aplicaciones) puedan interoperar en el conjunto más amplio posible de proveedores de la nube. Dichas interfaces, también, permitirán el fácil intercambio de proveedores de la nube con una modificación mínima o nula del código de la aplicación, etc.

En términos simples, el precio de entrada para los proveedores de la nube es desarrollar sus ofertas sobre estándares abiertos e interoperables para, tan siquiera, ser considerados por los empresarios como un candidato. En los casos en los que estos estándares no existen o existen en poca cantidad, se espera que los proveedores de soluciones y servicios colaboren en su desarrollo.

Para preservar la inversión en el desarrollo, la lógica de los sistemas y de las aplicaciones se separa de la infraestructura subyacente a través del uso de interfaces de software. Cada una de estas interfaces define un contrato entre el proveedor y el consumidor del servicio. Esta separación se basa en una Arquitectura orientada a servicios (SOA) válida. Estos pasos aislarán efectivamente al suscriptor de la nube de los protocolos específicos del proveedor, las identidades del servidor, las bibliotecas de utilidades y el proveedor de servicios, lo que da como resultado un software más fácil de desarrollar, más duradero y que se puede usar en matrices más amplias de entornos informáticos.

Como marco general, nos enfocaremos de manera predeterminada en las interfaces de servicios abiertas, para poder facilitar la adopción y la portabilidad de los servicios. No se puede sobrevalorar la importancia de las interfaces abiertas. Tal como lo analizó Buyya y otros, una interfaz estándar para CIaaS permitirá lo siguiente:22

•Que los consumidores interactúen con la infraestructura de informática en la nube sobre una base ad hoc.

•Que los integradores ofrezcan servicios de gestión avanzada.

•Que los agregadores ofrezcan una interfaz común y única a varios proveedores.

•Que los proveedores ofrezcan una interfaz estándar que sea compatible con las herramientas disponibles.

•Que los vendedores de nubes ofrezcan interfaces estándares para la entrega de servicios dinámicamente escalables en sus productos.

35


http://www.opendatacenteralliance.org/docs/ODCA_Service_Orch_MasterUM_v1.0_Nov2012.pdf




Objetivos

Las interfaces de los servicios de CIaaS deben admitir los objetivos de la interoperabilidad:

• Portabilidad de cargas de trabajo entre las nubes y los proveedores de la nube.

• Interconectividad de diferentes servicios e infraestructuras de nube.

• Interfaces de gestión uniforme, tanto automatizadas como manuales.

• Interoperabilidad entre proveedores de la nube dispares.

Alcance

La perspectiva del suscriptor de la nube (también conocido como el receptor de los servicios) se aborda inicialmente en esta versión del Modelo de uso principal de ODCA: CIaaS. La perspectiva del suscriptor de la nube y de los proveedores de soluciones se agregará en revisiones posteriores.

Supuestos

El Modelo de uso principal de ODCA: CIaaS se usa como el enfoque inicial para definir la instrumentación de servicios básicos, y los modelos de uso de ODCA Catálogo de servicios24 y Unidades de medida estándares para IaaS15 se usan como base. Las referencias y definiciones que se pueden usar, por lo tanto, se elaboran a partir de esos modelos de uso compatibles con el Formato abierto de virtualización (OVF) de Distributed Management Task Force (Grupo de trabajo de administración distribuida, DMTF).25

Compatible con la Interfaz de gestión de datos de nube (CDMI) de la Storage Networking Industry Association (Asociación de la industria de redes de almacenamiento, SNIA).26

Requisitos de interfaz generales

Para poder adoptar y operar de manera flexible y dinámica servicios basados en la nube, estas interfaces de servicios deben ser capaces de lograr una integración en los sistemas de automatización del suscriptor de la nube y, preferentemente, sin la intervención innecesaria de alguna persona (también se deben considerar las etapas de aprobación y flujo de trabajo). Esto significa que las interfaces de servicios deben ser abiertas para no limitar a los posibles usuarios de la nube con restricciones de costos o licencias especiales sobre el uso de la interfaz, y para permitir el funcionamiento automatizado de sistemas y servicios.

Las interfaces deben interactuar con flujos de trabajo y desencadenantes de la instrumentación del servicio estandarizados, de manera uniforme, predecible y global, y según las cualidades definidas del servicio. Esto hace referencia al impacto en cada uno de los elementos de configuración (CI) del Catálogo de servicios, en los procesos de operaciones y pedidos, y en la seguridad y el cumplimiento de cada CI. Si alguna interfaz se encuentra restringida o cuenta con una licencia especial u otro prerrequisito, la apertura y la capacidad de adopción del servicio de nube en general se ven debilitadas. Cualquier limitación podría restringir la base de posibles usuarios del servicio de nube y representa una dependencia o una desviación de los estándares abiertos, lo que implica un freno para los usuarios, en el sentido de que es más difícil transportar sus servicios hacia afuera de ese entorno de nube.

Requisitos adicionales:

• La capacidad para proporcionar servicios informáticos, de datos y de red en una interfaz estandarizada.

• Enfoque de Transferencia de estado representacional (RESTful).

• Capacidad de extensión para integrarse a otros servicios de nube de Lo que sea como servicio (XaaS) y para admitirlos.

• Funcionar como una aplicación front-end completa para la gestión de infraestructura interna del proveedor de CIaaS.

• Proporcionar un conjunto de métodos de gestión, semántica y sintaxis de comprensión común.

• Cobertura del ciclo de vida entero de CIaaS.

• Soporte con capacidad de extensión para entidades comunes o conjuntos de entidades, como por ejemplo:27

º Plantillas de sistema

º Sistemas

º Configuración de máquina

º Plantilla de máquina

º Imagen de máquina

º Administración de máquina

36


http://www.opendatacenteralliance.org/docs/Compute_IaaS_MasterUM_v1.0_Oct2012.pdf

http://www.opendatacenteralliance.org/document-sections/category/71-docs%3Fdownload%3D445:service-catalog

http://www.opendatacenteralliance.org/document-sections/category/71-docs%3Fdownload%3D458:standard_units_of_measure


º Máquina

º Volumen, red, trabajo, medición, evento

º El mantenimiento y el desarrollo continuo de las interfaces de servicio deben ser no intrusivos, para permitir operaciones sostenidas sin impacto, o deben contar con requisitos para el tiempo de inactividad.

8.4 Interfaces requeridas específicas

Tabla 8.4.1 Interfaces requeridas específicas

37


Sistema Subsistema

Portal de la nube

Pedido del consumidor a partir del Catálogo

Compras

Navegador

Elaborador de informes

Administrador de usuarios

Instrumentador

Calculador de costos

Interfaz del administrador técnico

Portal de servicios

Sistema de seguridad

Administrador de credenciales

Administrador de usuarios

Administrador de reclamaciones y token

Administrador de derechos y privilegios

Administrador de identidades

Administrador de intrusiones

Administrador de eventos e incidentes de seguridad

Servicios de directorio

Configurador de servicios

Catálogo de servicios

Catálogo de consumidores

Motor de reglas

Creación de paquetes de trabajo

Sistema de flujo de trabajo

Distribuidor de paquetes de trabajo

Monitor de paquetes de trabajo

Elaborador de informes de paquetes de trabajo

Bus de servicios empresariales



Sistema Subsistema

Sistema de facturación

Tablas de tarifas

Tablas de tarifas de activos, incluidos los modelos de licencias

Tablas de consumo real de servicios

Tablas de SLA

Tablas de contratos

Motor de cálculos

Mesa de ayuda y gestión del conocimiento

Gestión de incidentes

Gestión de problemas

Elaboración de informes

Bases de datos de conocimiento

Gestión de configuración

Base de datos de activos

Base de datos de grupos IP

Catálogo de servicios

Plantillas de configuración

Registros de configuración reales

Grupos de licencias (hardware, software, licencia de acceso de cliente)

Registros de consumo

Instrumentación

Motor de implementación de paquetes de trabajo: recursos informáticos

Creador de colas: monitoreo y gestión

Creador de colas: mesa de ayuda

Creación de registros de capacidad

Desencadenamiento de informes de SLA

Motor de implementación de paquetes de trabajo: monitoreo y gestión

Motor de implementación de paquetes de trabajo: hipervisor

Motor de implementación de paquetes de trabajo: almacenamiento

Motor de implementación de paquetes de trabajo: red

Gestión de licencias

Grupo de licencias de hardware

Grupo de licencias de software

Modelos de licencias

Licencias asignadas

Licencias disponibles

Licencias devueltas



Sistema Subsistema

Configuración conectable del sistema

Plantillas de configuración del sistema para implementaciones automatizadas

Replicación entre sitios de alta disponibilidad

Integración de sistemas entre el proveedor de servicios y los consumidores

Gestión de certificacionesGestión de certificaciones de seguridad de los clientes

Gestión de certificaciones de los proveedores de servicios

Gestión y monitoreo

Administrador de incidentes

Administrador de problemas

Monitor de eventos

Monitor de configuraciones

Gestión de capacidades

Monitor de disponibilidad

Monitor de SLA

Monitor de red

Monitor de almacenamiento

Administrador de hipervisores

Seguimiento y elaboración de informes de licencias

Agente de servicios de la nube

Asignador de servicios

Módulo de integración de servicios



8.5 Instrumentación del servicioLa ilustración a continuación representa una cantidad de interfaces. Además contiene tres planos: los planos de proveedor de soluciones, proveedor de la nube y suscriptor de la nube. Estos planos contienen los mismos elementos, pero varían en los detalles. No se encuentran organizados en ningún orden particular en la ilustración, ya que el suscriptor de la nube puede estar federando servicios entre varios proveedores de la nube (incluidos su propio departamento de TI y uno o más proveedores de la nube). Por otro lado, los proveedores de la nube pueden federar ellos mismos dichos servicios a partir de proveedores externos. Por lo tanto, las relaciones de los planos pueden variar según las circunstancias particulares. Lo que es importante es que existen interfaces entre los tres niveles, que deben ser instrumentadas y, según el escenario en particular, las responsabilidades y las propiedades pueden variar.

Figura 8.5.1 Interfaces

La instrumentación de servicios debe abarcar lo siguiente:

•Descubrimiento del servicio

• Implementación del servicio

• Configuración

• Capacidad

•Monitoreo y gestión de sistemas

• Pedidos

• Facturación

• Elaboración de informes

•Gestión de identidades


Catálogo de servicios accionable (IU y API) InstalaciónEspacio físico, enfriamiento, energía


Web Datos Mensaje

PaaS

SaaSInteroperabilidad de servicios

web y de datos

IaaS



Servicios

Corrección

Operacionesde aplicaciones

Gestión deservicios

Integración

Mesa deayuda

Instrumentaciónde servicioscompletos


Aplicaciones y SOde entrega de

software

Configuración

Evento

Seguridad

Desarrollo de aplicacionesUsuario final

Servicios

Monitoreo

Asignaciónde recursos

Corrección

Optimizacióny ajuste

Proveedor de soluciones

Suscriptor de servicios

Proveedor de servicios



Existen algunos componentes comunes a cada tipo de servicio, como se muestra a continuación. Estos componentes ayudan a estandarizar lo que el consumidor de la nube ve para las interfaces de servicio, instrumentación, mediciones, gestión y usuarios finales.

• Cada servicio tendrá un esquema que describirá los parámetros asociados con el servicio mismo y, específicamente, los atributos opcionales y requeridos asociados con la solicitud del servicio.

• Cada componente del servicio debe tener una descripción del SLA estandarizada y asociada con este. Esto identifica de manera única el servicio y describe los parámetros asociados con la provisión de una solicitud de este.

• Cada servicio debe contar con métodos conformados que calculen, elaboren informes y presenten unidades de medida estándares que describan los servicios y el rendimiento de esos servicios.

• Una vez que se solicite el servicio, existirá un conjunto de códigos de respuesta estándar del sector para informar sobre el estado de aprovisionamiento o de las solicitudes de servicio.

Vale la pena destacar las descripciones centrales que se pueden aplicar a un servicio; ambas son igualmente importantes en los escenarios de uso para los suscriptores de la nube. La primera es una definición de los atributos principales de un servicio que usa la terminología común que se describe en este documento. La segunda se trata de los parámetros de SLA que describen la rapidez con la que se puede proveer un servicio. El siguiente ejemplo ilustra la segunda definición.

8.6 Ejemplo de escenario de uso: capacidad de recolocación de recursos en la nube pública en un SLA especificadoUn objeto común de estado de aprovisionamiento es importante. Los suscriptores de la nube, con frecuencia, gestionan sus propias secuencias de comandos de aprovisionamiento y flujo de trabajo para solicitar servicios externos. Se necesitan códigos de estado, notificaciones y otras semánticas comunes para las acciones del proveedor de la nube para permitir el desarrollo de procesos que se automaticen de modo tal que sean independientes del proveedor de servicios. Tenga en cuenta el escenario de uso de la nube en "modo de recolocación de recursos en la nube pública".

Un suscriptor de la nube tiene una aplicación comercial que experimenta una alta demanda. Desea recolocar sus recursos en un proveedor externo y necesita capacidad adicional en 10 minutos. Posiblemente tenga relaciones contractuales establecidas con cinco proveedores de la nube para lograr, de esta manera, la recolocación. Al consultar los tiempos de respuesta de los SLA para cada proveedor de la nube, puede elegir el tiempo de respuesta más adecuado para sus necesidades, en lugar de arriesgarse a realizar una recolocación de recursos desde un centro de datos sobrecargado a otro que esté sufriendo los mismos problemas de capacidad temporales.

Para resolver este ejemplo, podríamos analizar el aprovisionamiento de una máquina virtual básica que ejecuta una versión empresarial de Linux.

Primero, le consultamos al proveedor de servicios para ver si contamos con un servicio que coincida con esa descripción y si podemos recibir un objeto del SLA asociado con ese servicio.

Entonces, para nuestra VM con Linux, el objeto del SLA puede describirse como figura a continuación, en un pseudocódigo:

<Service Provider>ACME Cloud Corp</>

<Service>VM Ware VM</>

<Service>RHEL 6.1</>

<Service Location></>

<Service Price Model></>

<Service Provisioning Time>10 minutes</A>

Cada proveedor de servicios debe identificarse de manera única.

Una forma de describir de forma única cada oferta de servicio.

Ubicaciones donde se ofrece este servicio.

Precio del servicio: esta sería una referencia a la unidades de precios acordadas.

Este es un atributo clave: el tiempo que pasa desde la solicitud hasta el aprovisionamiento, que resulta útil para la planificación del flujo de trabajo, etc.



Esto describe el SLA de aprovisionamiento del proveedor de la nube al suscriptor. Se necesita un objeto descriptivo para describir el servicio en sí mismo y todos los atributos que están disponibles para la personalización, por ejemplo:

Estos atributos son solo un ejemplo.

<Service>VM Ware VM</>

<Service>RHEL 6.1</>

<Allowed Memory>1GB, 2GB, 4GB, 8GB</>

<Allowed VCPU>1, 2, 4, 8 </>

<Allowed Storage>10GB, 50GB, 100GB, 500GB, 1000GB</>

Entonces, ahora tenemos un servicio que tiene un objeto de SLA que describe cómo un proveedor de servicios proporcionará este servicio y un objeto de configuración que describe qué opciones puede solicitar un cliente.

Supongamos ahora que el suscriptor de la nube realiza un pedido. Identifica al servicio con un identificador (ID) único y solicita el servicio, usando los atributos de configuración disponibles.

El proveedor de servicios acepta el mensaje y responde con una confirmación del objeto del SLA y con una referencia única de la solicitud de servicio para poder hacer un seguimiento de este proceso.

En cualquier punto, la persona que solicitó el servicio puede hacer una consulta al proveedor de servicios con la referencia de solicitud de servicio, y recibir un código de estado de comprensión común para indicar cuál es el progreso del proceso de aprovisionamiento y si existe algún problema.

9.0 Operaciones y gestión

9.1 Información generalEl uso de un proveedor de CIaaS requiere capacidades que le permitan al consumidor integrar, automatizar, monitorear y medir los recursos de una manera completamente autónoma y al mismo tiempo asegurarse cierto nivel de capacidad de respuesta y uniformidad por parte del proveedor. Si bien una interfaz de usuario que proporcione acceso a estas capacidades siempre es bienvenida, la habilidad para programar rápidamente una interfaz con estas capacidades termina siendo más importante que una interfaz de usuario. Esta sección cubre las capacidades de alto nivel en las áreas de integración, automatización, monitoreo, medición y respuesta para las operaciones y la gestión de CIaaS.

9.2 MotivacionesIntegración: la capacidad de incorporar el flujo de trabajo de gestión y operaciones de un proveedor de CIaaS en los procesos de flujo de trabajo de los suscriptores de la nube. Esto incluye requisitos de autenticación, autorización, otros controles de acceso, notificaciones, gestión, cumplimiento y gobierno, control de cambios y funciones de gestión de incidentes de servicios; todos estos requisitos deben poder integrarse en algún nivel con el flujo de trabajo del consumidor, ya sea de forma manual o automatizada.

Automatización: la capacidad de acceder de manera programada y de automatizar las capacidades provistas por el proveedor de CIaaS. Esto incluye eliminar toda interacción de canal manual durante las operaciones y la gestión de las capacidades consumidas de CIaaS, y también todo aprovisionamiento y retiro de las capacidades de CIaaS.

Notificación: la capacidad de ser notificado cuando ocurren cambios de aprovisionamiento, configuración, control de acceso, facturación, interrupciones o dificultades del servicio y en otras actividades. Esto permite conocer, elaborar informes y auditar las actividades operativas que ocurren dentro del ámbito del proveedor de CIaaS en nombre del consumidor, más allá de lo que se puede detectar durante el monitoreo.

Monitoreo: la capacidad de consultar y comprender el estado y las características operativas de las capacidades de CIaaS provistas desde el nivel general y más alto (“Su capacidad está activa”) hasta el nivel más específico y detallado ("Aquí es donde se observa cómo funciona su capacidad”). El monitoreo de escenarios de uso mantiene modelos basados en eventos y en investigaciones para comunicar incidentes y estados.



Medición: la capacidad de medir el rendimiento histórico y actual, y el costo de las capacidades de CIaaS provistas y que se consumen. La medición difiere del monitoreo al agregar las dimensiones de costo y elaboración de informes de CIaaS en oposición al rendimiento monitoreado.

Respuesta: la capacidad del proveedor de proporcionar una interacción o respuesta preventiva, preferente, confiable, repetible, y bien comprendida sobre los problemas de entrega del servicio, y la capacidad tanto del consumidor como del proveedor de investigar e identificar problemas de entrega del servicio.

9.3 Escenarios de uso de operaciones de CIaaSSe presentan los siguientes escenarios de uso de operaciones:

• Configuración de control y acceso

• Capacidades de aprovisionamiento y de anulación de aprovisionamiento

• Identificación de fallas en el servicio o en el SLA por parte del proveedor

• Identificación de fallas en el servicio o en el SLA por parte del consumidor

•Notificación de interrupción o cambio del servicio

•Monitoreo del servicio

• Uso y facturación del suscriptor

• Asignación de impulsores del negocio

Supuestos

Los siguientes supuestos se aplican a todos los escenarios de uso descritos en esta sección:

• La gestión de instalaciones es poco transparente en relación con el consumo de las capacidades de CIaaS.

9.3.1 Escenario de uso 1: configuración de control y acceso Impulsores del negocio: integración, automatización

Objetivo: permitir a los suscriptores de la nube que agreguen o eliminen cuentas de usuarios y les asignen varios niveles de capacidad de aprovisionamiento para promover el consumo de autoservicio de las capacidades de CIaaS sin requerir la interacción directa del personal de operaciones del suscriptor.

Supuesto 1: el suscriptor de la nube se ha registrado para el servicio de nube y el proveedor le ha proporcionado una cuenta de administración inicial.

Escenario de éxito 1: el administrador del suscriptor de la nube puede agregar una nueva cuenta y asignar permisos de acceso y metadatos del suscriptor a la cuenta. El suscriptor puede cambiar los permisos para una cuenta existente.

Pasos:

1. El proveedor de la nube proporciona documentación clara y herramientas que definen el alcance de las características de personalización y configuración disponibles para configurar una cuenta.

2. El suscriptor de la nube identifica credenciales específicas y metadatos opcionales para una nueva cuenta. Los elementos pueden ser los siguientes:

a. Nombre de usuario

b. Correo electrónico

c. Contraseña

d. Metadatos (como el código de facturación del suscriptor)

3. El suscriptor de la nube configura o cambia los permisos de la cuenta para consumir, controlar y monitorear las capacidades de CIaaS provistas por el proveedor, o cambia los metadatos para la cuenta.

4. El dueño de la cuenta es notificado mediante correo electrónico sobre la disponibilidad de la cuenta o los cambios de configuración.

5. El dueño de la cuenta puede consumir inmediatamente los servicios del proveedor.



Condición de falla 1: no se puede crear una cuenta nueva ni aplicar los permisos deseados.

Manejo de fallas 1: se notifica a la cuenta administrativa del suscriptor de la nube. Se corrige según el acuerdo de soporte.

Escenario de éxito 2: el administrador del suscriptor de la nube elimina una cuenta de usuario.

Pasos:

1. El proveedor de la nube proporciona documentación clara y herramientas que definen el alcance de las características de personalización y configuración disponibles para eliminar una cuenta.

2. La cuenta de administración del suscriptor de la nube elimina la cuenta de usuario.

3. La cuenta de usuario deja de estar disponible inmediatamente.

4. La cuenta de usuario puede permanecer intacta a los fines de conservar antecedentes.

Condición de falla 1: falla la eliminación de la cuenta.

Manejo de fallas 1: se notifica a la cuenta administrativa del suscriptor. Se corrige según el acuerdo de soporte.

9.3.2 Escenario de uso 2: capacidades de aprovisionamiento y de anulación de del aprovisionamientoImpulsores del negocio: integración, automatización

Objetivo: capacidades de CIaaS o aprovisionamiento o anulación del aprovisionamiento de autoservicio.

Supuesto 1: se ha creado, configurado y autenticado una cuenta de usuario adecuada con permisos relevantes.

Escenario de éxito 1: el usuario solicita o elimina la capacidad de CIaaS (como una instancia informática) y la capacidad es provista o eliminada según el SLA relevante.

Pasos:

1. El usuario del suscriptor de la nube solicita el aprovisionamiento o la eliminación de la capacidad de CIaaS.

2. El proveedor de la nube crea recursos y proporciona acceso a la cuenta de usuario del suscriptor o elimina recursos de la disponibilidad de la cuenta de usuario del suscriptor.

3. Los recursos se encuentran o no se encuentran disponibles en la cuenta de del usuario, según corresponda.

4. Se notifica a la cuenta del usuario sobre el cambio de servicio.

5. El proveedor de la nube comienza o detiene la facturación para los recursos, según corresponda.

Condición de falla 1: no se puede crear o eliminar la capacidad.

Manejo de fallas 1: el proveedor y el suscriptor de la nube son notificados sobre la falla según el SLA. Se usan interfaces para habilitar el análisis claro del motivo de la falla.

Escenario de éxito 1: el usuario cambia la configuración del servicio de una capacidad ya provista, como por ejemplo, detener o iniciar una instancia informática, y el cambio ocurre en el recurso provisto, de conformidad con el SLA.

Pasos:

1. La cuenta del usuario del suscriptor de la nube solicita la modificación de los recursos de CIaaS provistos.

2. El proveedor de la nube aplica el cambio en los recursos adecuados.

3. Los recursos ahora se modifican tal como lo solicitó la cuenta del usuario.

4. Se notifica a la cuenta del usuario sobre la modificación de los recursos.

5. El proveedor de la nube modifica la facturación de los recursos, según corresponda.



Condición de falla 1: no se puede modificar una capacidad.

Manejo de fallas 1: el proveedor y el suscriptor de la nube son notificados sobre la falla según el SLA. Se usan interfaces para habilitar el análisis claro del motivo de la falla.

9.3.3 Escenario de uso 3: identificación de fallas en el servicio o en el SLA por parte del proveedorImpulsores del negocio: integración, automatización, monitoreo, respuesta

Objetivo: identificación clara y notificación al suscriptor sobre los problemas de las capacidades que pueden impactar en el suscriptor y establecimiento de las expectativas de corrección de los problemas.

Supuesto 1: el suscriptor y el proveedor acordaron un SLA y un plan de comunicación para las excepciones de servicio y del SLA.

Escenario de éxito 1: el proveedor identifica la falla del servicio o del SLA antes o inmediatamente después de que el problema impacta en el suscriptor. Se proporcionan al suscriptor los detalles del problema, el alcance del impacto y el plan de corrección.

Pasos:

1. El proveedor de la nube identifica problemas relacionados con la oferta del servicio.

2. El proveedor de la nube identifica el impacto en el suscriptor.

3. El proveedor de la nube notifica al suscriptor acerca del problema, el impacto o potencial impacto en el suscriptor y el plan de corrección.

4. El suscriptor de la nube toma las medidas comerciales adecuadas según el impacto.

5. El proveedor de la nube corrige el problema.

6. El proveedor de la nube notifica al suscriptor de la nube sobre la resolución del problema.

7. El suscriptor de la nube toma las medidas comerciales adecuadas según la resolución.

9.3.4 Escenario de uso 4: identificación de fallas en el servicio o en el SLA por parte del suscriptorImpulsores del negocio: integración, automatización, monitoreo, respuesta

Objetivo: notificar al proveedor de la nube sobre problemas con las capacidades suscritas que impactan en el suscriptor. Obtener expectativas de corrección de los problemas.

Supuesto 1: el suscriptor y el proveedor de la nube acordaron un SLA y un plan de comunicación para las excepciones de servicio y del SLA.

Escenario de éxito 1: el suscriptor de la nube identifica la falla del SLA o del servicio. Los detalles del problema y el alcance del impacto se proporcionan al proveedor de la nube. El suscriptor de la nube recibe la expectativa de corrección del problema.

Pasos:

1. El suscriptor de la nube identifica problemas relacionados con la oferta de servicio.

2. El suscriptor de la nube identifica y comunica el impacto al proveedor de la nube.

3. El proveedor de la nube notifica al suscriptor de la nube el plan de acción para abordar el problema.

4. El suscriptor de la nube toma las medidas comerciales adecuadas según el impacto.

5. El proveedor de la nube corrige el problema.

6. El proveedor de la nube notifica al suscriptor de la nube sobre la resolución del problema.

7. El suscriptor de la nube toma las medidas comerciales adecuadas según la resolución.



9.3.5 Escenario de uso 5: notificación de interrupción o cambio del servicioImpulsores del negocio: integración, control, respuesta

Objetivo: Notificar al suscriptor de la nube acerca de los cambios o interrupciones del servicio del proveedor de la nube que puedan afectarlo.


Escenario de éxito 1: El proveedor de la nube notifica al suscriptor de la nube acerca de los cambios o interrupciones planificados del servicio. El suscriptor de la nube tiene el tiempo suficiente para preparar a la empresa para el evento de cambio o interrupción del servicio. El cambio o la interrupción del servicio del proveedor de la nube se realiza según lo planificado con el impacto esperado en el suscriptor de la nube.

Pasos:

1. El proveedor de la nube notifica al suscriptor de la nube acerca del cambio o la interrupción planificados del servicio e indica, como mínimo, lo siguiente:

a. Fecha y hora en que se producirá

b. Duración del evento

c. Impacto esperado en el suscriptor

d. Plan de restauración si el evento falla

e. Ruta de remisión a una instancia superior para impactos esperados e inesperados en el suscriptor durante el evento

2. El suscriptor de la nube prepara la empresa para el evento planificado.

3. El proveedor de la nube realiza el evento planificado.

4. Durante el evento, el suscriptor de la nube evalúa el impacto en el negocio y remite los problemas según el Escenario de uso 4.

5. El proveedor de la nube completa el evento planificado.

a. Si no tiene éxito, las capacidades del servicio se restauran al estado anterior para el suscriptor de la nube.

6. El proveedor de la nube notifica al suscriptor el resultado del evento.

9.3.6 Escenario de uso 6: monitoreo del servicioImpulsores del negocio: monitoreo, respuesta

Objetivo: El proveedor y el suscriptor de la nube pueden monitorear en detalle el estado de los recursos proporcionados por el proveedor para garantizar las operaciones e identificar o depurar posibles problemas con los recursos suscritos.


Escenario de éxito 1: El suscriptor de la nube puede acceder al estado interno y externo del recurso suscrito. Los estados interno y externo se pueden capturar y comunicar entre el suscriptor y el proveedor de la nube.

Pasos:

1. El proveedor de la nube ofrece la documentación sobre el acceso y el monitoreo del estado interno y externo del recurso, según corresponda. Esto puede incluir, en otras cosas, lo siguiente:

a. Estado general, condición e historial de los recursos suscritos.

b. Excepciones o eventos claves que ocurren a un recurso suscrito.

c. Registros de actividad detallados para cada recurso suscrito.

2. Acceso del suscriptor de la nube al estado interno y externo del recurso, según sea necesario.

3. Según sea necesario, el suscriptor o el proveedor de la nube capturan el estado del recurso y se notifican acerca de él.



Condición de falla 1: Estado interno o externo del recurso no disponible.

Manejo de fallas 1: El suscriptor de la nube notifica al proveedor de la nube para obtener una corrección.

Escenario de éxito 2: El proveedor de la nube monitorea de forma automática el estado interno y externo de los recursos del suscriptor de la nube, y le notifica los posibles problemas a medida que los descubre.

Pasos:

1. El proveedor de la nube monitorea el estado interno y externo del recurso para encontrar posibles problemas.

2. Si es necesario que el proveedor de la nube tome medidas, el suscriptor de la nube recibe una notificación según el Escenario de uso 5.

3. Si se indica al suscriptor de la nube que tome medidas, el proveedor notifica al suscriptor la detección a partir del monitoreo y permite que los estados interno y externo del recurso suscrito estén disponibles para el suscriptor.

4. El suscriptor de la nube determina si la medida es necesaria y actúa en consecuencia.

5. Según sea necesario, el suscriptor o el proveedor de la nube capturan el estado del recurso y se notifican acerca de él.

Condición de falla 1: El proveedor de la nube no puede monitorear los recursos del suscriptor de la nube.

Manejo de fallas 1: El proveedor de la nube notifica al suscriptor de la nube su incapacidad de monitorear y de corregir consecuentemente los problemas.

9.3.7 Escenario de uso 7: uso y facturación del suscriptorImpulsores del negocio: monitoreo, respuesta

Objetivo: El suscriptor de la nube puede acceder a los datos actualizados de facturación y uso de recursos en modo de autoservicio según el SLA y los términos comerciales. El proveedor de la nube puede facturar al suscriptor por los recursos consumidos según los términos comerciales y en la periodicidad acordada.

Supuesto 1: El suscriptor y el proveedor de la nube acordaron un SLA y los términos comerciales.

Escenario de éxito 1: El suscriptor de la nube accede a la información actual e histórica de facturación y uso.

Pasos:

1. El suscriptor de la nube se autentifica con el proveedor de la nube mediante una cuenta con permisos de acceso para solicitar información de uso y facturación.

2. El suscriptor de la nube accede a la información de uso y facturación según sea necesario.

Condición de falla 1: No es posible acceder a la información de facturación o uso.

Manejo de fallas 1: El suscriptor de la nube notifica al proveedor para obtener una corrección.

Escenario de éxito 2: El proveedor de la nube factura al suscriptor de la nube según los términos comerciales acordados. El suscriptor de la nube paga al proveedor.

Pasos:

1. El proveedor de la nube calcula una facturación apropiada para los recursos consumidos por el suscriptor de la nube, según los términos comerciales.

2. El proveedor de la nube entrega la factura al suscriptor de la nube para que se realice el pago.

3. El suscriptor de la nube paga la factura según los términos comerciales.

4. El proveedor de la nube ofrece una ruta de remisión a una instancia superior para las discrepancias de facturación.

5. El proveedor de la nube conserva el historial de uso y facturación para el suscriptor de la nube.



9.4 Niveles de servicio de operaciones y gestión

Tabla 9.4.1 Niveles de servicio de operaciones y gestión

Requisito (O: opcional, N: necesario)


S.I.1 Documentación formal de todas las interfaces de servicio, GUI y líneas de comandos en el estándar de documentación elegido por el proveedor de la nube.

Esta documentación debe proporcionar detalles suficientes para permitir que el suscriptor de la nube opere y gestione los escenarios de uso anteriores.

N N N N

S.I.2 Igual que S.I.1, pero con una interfaz de servicio web mediante programación formalmente documentada según el estándar elegido por el proveedor de la nube, lo que permite al suscriptor de la nube interconectarse a través de programas que utilizan llamadas API de servicio web.

O N N N

S.I.3 Igual que S.I.2, pero con el aprovisionamiento de credenciales de seguridad replicada (proporcionar un grupo duplicado de nombre de usuario, contraseña o credenciales de membresía de grupo con un proceso de sincronización regular) para mejorar la experiencia de inicio de sesión del usuario.

O N N N

S.I.4 Igual que S.I.3, pero con el aprovisionamiento de credenciales de seguridad completamente federadas para lograr una capacidad de inicio de sesión único sin inconvenientes.

O O O N

S.I.5 Igual que S.I.4, pero con una documentación formal de la interfaz de servicio en un formato estándar reconocido del sector completamente alineado con los conceptos incluidos en los Modelos de uso de ODCA, Unidades de medida estándares para IaaS15 y el Catálogo de servicios.24

O O O N

S.I.6 Igual que S.I.5, pero con la habilidad de admitir una conexión de la interfaz de servicio completamente automatizada, y la reconexión, la orquestación y la interconexión a gran escala.

O O N N

S.I.7 Igual que S.I.6, pero con la habilidad de interconectarse sin inconvenientes con múltiples proveedores de la nube.

O O O N

10.0 Arquitectura técnica

10.1 Supuestos y contextoEsta sección contiene los requisitos de arquitectura técnica para CIaaS.

Siempre que sea posible, el contenido será independiente de la tecnología y de la generación de tecnología.

El proceso de selección y aprovisionamiento del servicio es completo hasta el punto en que el suscriptor de la nube pueda crear y administrar uno o más contenedores.

Las solicitudes de servicio pueden ser originadas directamente por una persona en la organización del suscriptor de la nube a través del portal web, o pueden originarse a partir de algún tipo de nivel de orquestación.

10.2 ComponentesLa figura a continuación representa una descripción lógica de los componentes incluidos en el alcance. Los componentes en conjunto forman el contenedor de recursos informáticos. Es probable que este contenedor de equipos sea una máquina virtual, pero esto no es obligatorio.



Figura 10.2.1 Componentes de la arquitectura de CIaaS

10.3 Nivel informáticoEl contenedor de recursos informáticos, o la instancia informática, debe poder hospedar una imagen del SO especificado por el suscriptor. Esta imagen puede ser proporcionada por el consumidor del servicio, el proveedor del servicio o un tercero. No es necesario que esto sea una máquina virtual.

El contenedor se especifica en las unidades que se describen debajo y tiene atributos, como:

• Subprocesos de ejecución de CPU (se verá como la cantidad de CPU host del sistema operativo invitado)

•Memoria asignada (en gigabytes)

Servicios/atributos necesarios:

• Capacidad para iniciar, detener y suspender en un momento dado arbitrario.

• Portabilidad (consulte también el Modelo de uso de ODCA: Migración de la carga de trabajo a larga distancia10)

•Debe poder consultar el estado del contenedor: creado, no existente, iniciado, detenido, suspendido.

•Debe poder consultar los recursos informáticos asignados (CPU y memoria asignada).

Servicios y atributos recomendados:

• Capacidad de consultar los límites de sobresuscripción de los recursos de CPU y memoria.

• Capacidad de consultar el estado o la contención de sobresuscripción de los recursos de CPU y memoria.

Servicios/atributos opcionales:

• Informar la ubicación geográfica o jurisdiccional del contenedor. En realidad, las consideraciones de ubicación geográfica se aplican principalmente a los datos en los que existan requisitos regulatorios. A veces, esto también se aplicará al contenedor de recursos informáticos y a los datos. Por último, es posible que sea necesario gestionar la ubicación de un contenedor de recursos informáticos para gestionar la localidad en los almacenes de datos por motivos de rendimiento y latencia. Mientras que se incluye aquí como “opcional”, será necesario para algunos sectores, como los mercados de capital.

• Una unidad de medida estándar para la ubicación física. Esto será especialmente importante para los sectores altamente regulados, o donde los suscriptores de la nube sean sensibles a los requisitos de privacidad europeos o a las implicaciones de la Ley Patriota de los Estados Unidos (USA PATRIOT Act). La información de ubicación más importante es la jurisdicción; aunque generalmente se refiere a una ubicación geográfica, no siempre es lo mismo. Por lo tanto, la unidad que se utiliza debe referirse a la jurisdicción. El código de país ISO 3166-1 se refiere a la jurisdicción y puede utilizarse para especificar con precisión la ubicación real del contenedor o del almacenamiento.

• La habilidad de escalar la CPU y la memoria de forma independiente. En la mayoría de los escenarios, los proveedores de servicio desean proporcionar contenedores de recursos informáticos de tamaño fijo ya que esto simplifica la gestión de capacidad, el aprovisionamiento y la determinación de cargos. Un proveedor de servicios puede ofrecer de forma opcional la habilidad de escalar la CPU y la memoria por separado. Esta capacidad puede suponer un sobreprecio. Es posible que el SLA entre el suscriptor y el proveedor de la nube especifique de qué forma se proporcionará la capacidad adicional (por ejemplo, escala horizontal o vertical).

Entramado de red

Contenedor de recursos informáticos

Nivel de almacenamiento

Gest

ión

Entramado de almacenamiento

Almacenamientoen bloque

Almacenamientode objetos

http://www.opendatacenteralliance.org/docs/Long_Distance_Workload_Migration_Rev1.0_b.pdf



10.3.1 Resumen de los niveles de servicio: atributos de instancias informáticas

Atributos de instancias informáticas(O: opcional; N: necesario)


Habilidad para iniciar, detener, suspender N N N N

Portabilidad N N N N

Consulta sobre el estado del contenedor N N N N

Consulta sobre los recursos informáticos N N N N

Consulta sobre los límites de sobresuscripción O N N N

Consulta sobre el estado de sobresuscripción O N N N

Informes de la ubicación del contenedor O O O N

Unidad estándar de ubicación física O O O N

Escala independiente de la CPU y la memoria O O O N

10.4 Nivel de almacenamiento

10.4.1 Requisitos de almacenamiento en bloqueUn contendor o una máquina virtual deben tener un almacenamiento en bloque persistente o uno no persistente. Pueden tener ambos.

• El almacenamiento no persistente no persiste en los eventos del ciclo de energía del contenedor de recursos informáticos, pero persiste en los reinicios de la imagen de la máquina, es decir en el reinicio del sistema operativo hospedado.

• El almacenamiento persistente se conserva hasta que se elimina o se destruye de forma explícita.

• El almacenamiento puede existir o ser aprovisionado independientemente del contenedor de recursos informáticos.

• Las múltiples asignaciones de almacenamiento pueden tener niveles y atributos de servicio independientes.

• Las asignaciones de almacenamiento en bloque pueden estar dedicadas a un único contenedor de máquina o dispositivo de inicio, o pueden destinarse a otros contenedores de recursos informáticos, no necesariamente para el acceso simultáneo, como los clústeres.

10.4.1.1 Resumen de los niveles de servicio: atributos del almacenamiento en bloque

Atributos del almacenamiento en bloque(O: opcional; N: necesario)


Proporciona almacenamiento en bloque N N N N

El almacenamiento no persistente persiste en los reinicios de imagen N N N N

El almacenamiento persistente se conserva hasta la eliminación/destrucción

N N N N

Almacenamiento aprovisionable independientemente del contenedor N N N N

Múltiples asignaciones con niveles de servicio independientes N N N N

Asignación configurable para instancias informáticas N N N N



10.4.2 Requisitos para el almacenamiento de objetosEl almacenamiento de objetos está fuera del alcance del Modelo de uso principal de ODCA: Infraestructura informática como servicio (CIaaS).

10.4.3 Entramado de almacenamientoLos entramados de almacenamiento son entramados que vinculan componentes. Los entramados son construcciones lógicas que se asignan a construcciones físicas. Los entramados proporcionan conectividad y hospedan servicios de un nivel más alto. Tenga en cuenta que aún deben cumplirse los requisitos de protección de datos. Un entramado originado en varios dispositivos físicos debe permitir, igualmente, el mismo nivel de protección de acceso que un solo dispositivo físico.

El nivel de entramado de almacenamiento puede incluir una o más tecnologías implementadas y gestionadas por el proveedor de servicio. Los ejemplos incluyen Canal de fibra e iSCSI.

Servicios requeridos

Entre los servicios que se deben admitir en el nivel de almacenamiento se incluyen los siguientes:

• Persistencia

•Habilidad de realizar consultas sobre los niveles, los atributos y las capacidades de servicio

• Aislamiento

• Control de acceso

Servicios recomendados

Entre los servicios que deberían proporcionarse, aunque no son necesarios se incluyen los siguientes:

• Aislamiento confiable (vinculado al control de acceso). Tenga en cuenta que esto es necesario para los niveles oro y platino. Lo que no es necesario es que el aislamiento sea físico, si el aislamiento lógico ofrece la suficiente confiabilidad de aislamiento.

• Identificación (control de acceso)

Servicios opcionales

Los servicios opcionales que se ofrecen en el nivel de almacenamiento otorgan capacidades adicionales más allá del transporte y la persistencia básicos.

En general, las capacidades se incluyen en las siguientes categorías:

•Disponibilidad de datos (replicación, creación de reflejo, instantánea, etc.)

• Seguridad y cifrado de datos

•Optimización de la capacidad (desduplicación de la compresión de datos, aprovisionamiento delgado, etc.)

• La desduplicación puede ser una cuestión de seguridad. En los entornos de seguridad crítica, esto debe mencionarse de forma explícita en el SLA. El suscriptor de la nube debe tener la opción de inhabilitarla (en niveles oro y platino)

• El aprovisionamiento delgado puede ser una cuestión de seguridad. Se debe indicar de forma explícita en el SLA y el suscriptor debe tener la opción de inhabilitarlo (en los niveles oro y platino)

Capacidades de migración

Se espera que exista algún mecanismo para consultar qué servicios opcionales se aplicaron a una asignación de almacenamiento específica. Por ejemplo, si un servicio de almacenamiento ofrece la compresión de datos en el lugar, es posible que el consumidor del servicio quiera saberlo, ya que esto puede hacer que la compresión de objetos de almacenamiento en áreas más elevadas de la pila sea redundante. Por otro lado, el proveedor debe saber si la compresión tiene algún sentido (que no es lo que ocurre si el suscriptor cifra todos los datos antes del almacenamiento).



10.4.3.1 Resumen de los niveles de servicio: atributos del entramado de almacenamiento

Atributos del entramado de almacenamiento(O: opcional; N: necesario)


Persistencia N N N N

Consulta sobre los detalles de servicio N N N N

Aislamiento N N N N

Control de acceso N N N N

Aislamiento confiable O N N N

Identificación O N N N

Consulta sobre servicios opcionales O O O N

10.5 Entramado de redAl igual que los entramados de almacenamiento, los entramados de red son entramados que vinculan componentes. Los entramados son construcciones lógicas que se asignan a construcciones físicas. Los entramados proporcionan conectividad y hospedan servicios de un nivel más alto.

Un entramado de red externo incluye una o más conexiones de red al contenedor de la máquina y proporciona el transporte de datos entre extremos. Los extremos son máquinas o consumidores de servicio, de forma que un transporte puede ser de máquina a máquina o de máquina a suscriptor de la nube o a agente de servicios de la nube. Es posible que los entramados de red externos sean entramados basados en IP, pero esto no es necesario. El proveedor de la nube puede proporcionar de forma opcional capacidades de mayor nivel, como balanceadores de carga, para reunir las características de servicio deseadas.

Los proveedores necesitan escalabilidad, determinación del tamaño adecuado, calidad de servicio (QoS); y los suscriptores de la nube necesitan la facilidad y familiaridad de las simples redes Ethernet. La virtualización de la red ofrece esto. Es virtualización verdadera ya que proporciona un nivel de abstracción neto que separa las cuestiones del proveedor y del suscriptor de la nube.28

La virtualización de la red es un habilitador crítico de grandes centros de datos en la nube. Simplifica las redes y evita las complejas tecnologías adicionales que en la actualidad son controladas por los administradores de red. Lo mejor de todo es que de por sí reproduce las fortalezas de los sistemas de productos. En lugar de comprar equipos y dispositivos de red cada vez más caros, es mucho más económico escalar los equipos económicos mediante técnicas de red de nivel 3, y luego utilizar los niveles de abstracción para ocultar todo.28 Esas características alinean las redes virtuales con la visión de Alliance y con los requisitos estratégicos de la nube que exigen sus miembros.

Servicios/atributos necesarios:

• Servicios de transporte: ancho de banda, latencia, QoS, recolocación de recursos en la nube pública (escalar y reducir el tamaño).

• Control de acceso: definir el acceso en términos de quién puede acceder al contenedor.

Servicios/atributos recomendados:

• Consumidor del servicio de administración del firewall. El proveedor de servicios tendrá un conjunto de configuración necesario, y las reglas de firewall se aplicarán a la implementación.

• SLA por contenedor de máquina o cliente.

Servicios/atributos opcionales:

• Balanceadores de carga: servidores y aplicaciones de máscara. Ampliar el rendimiento para las aplicaciones.

• Servicios de resiliencia/redundancia: ancho de banda a pedido, protección de la ruta de transporte.



• Servicios de VPN: VPN basada en IPSec (túnel seguro para la conexión de VPN a través de Internet).

• Servicio de seguridad: habilidad para proteger el servidor en función de puertos y protocolo.

• Servicio de monitoreo: habilidad para controlar las capturas, las conversaciones, etc. en el paquete a pedido.

10.5.1 Resumen de los niveles de servicio: atributos del entramado de red

Atributos del entramado de red(O: opcional; N: necesario)


Servicios de transporte N N N N

Control de acceso N N N N

Gestión del firewall O N N N

SLA por contenedor O N N N

Balanceadores de carga O O O N

Servicios de resiliencia O O O N

Servicios de VPN O O O N

Servicios de monitoreo O O O N

10.6 GestiónLos niveles de gestión incluyen lo siguiente:

•Gestión de recursos y configuración

• Agrupación de recursos

• Asignación de recursos

• API: basada en estándares, propietaria

•Gestión de estado de recursos: informes de control y estado

•Monitoreo del rendimiento y medición del uso de los recursos

• Seguridad de recursos: control de acceso, agrupación/asignación

Para lograr un enfoque consistente entre los proveedores de servicio, se requiere una vista federada de la información de gestión del sistema. Este nivel agrupa las capacidades de gestión, monitoreo y elaboración de informes en los atributos de servicio. El propósito de este nivel es ofrecer un formato de información coherente entre los proveedores de servicio, mediante las interfaces de servicio que se describen en otra sección de este documento.

Interfaces admitidas necesarias

El suscriptor de la nube requiere un conjunto de interfaces para gestionar la infraestructura informática. Deben existir interfaces para realizar toda la gama de tareas de gestión requeridas, así como para instrumentar y ver el funcionamiento de los elementos de la infraestructura. Todo esto es necesario para todos los niveles de servicio.

•Detección del servicio

• Instrumentación (implementación del servicio)

• Configuración



• Capacidad

•Gestión y monitoreo de los sistemas

• Pedidos

• Facturación

• Elaboración de informes

•Gestión de identidades

10.6.1 Resumen de los niveles de servicio: gestión

Gestión(O: opcional; N: necesario)


Todas las capacidades de instrumentación del servicio dentro de una sola nube

N N N N

Todas las capacidades de instrumentación del servicio en todas las nubes de un único proveedor de la nube

O O N N

Todas las capacidades de instrumentación del servicio en diferentes proveedores de la nube

O O O N

Consulte también la sección separada Interfaz de servicio y Modelo de referencia de este documento para obtener más información.

11.0 Consideraciones de seguridadNota: Todas las referencias al servicio de nivel platino se basan en el supuesto de que la definición del Modelo de uso de ODCA: Garantía del proveedor 19

se actualizará para reflejar la definición del NIST.

11.1 Requisitos de seguridadLos siguientes requisitos se alinean con el Modelo de uso de ODCA: Garantía del proveedor:19

Antivirus, antimalware y antirootkit con actualizaciones de definiciones en 24 horas.

Proteja contra ataques típicos, como “Blue Pill” y algunos ataques a la red de bajo nivel, como el árbol de expansión (spanning-tree) entre otros. Esto es necesario, incluso, en el nivel bronce, ya que es una parte integral de la infraestructura. Es fundamental para parte de la infraestructura de control de la nube y es responsabilidad EXCLUSIVA del proveedor de la nube.

Existe un proceso de gestión de vulnerabilidades y está completamente probado para garantizar que no haya ningún impacto en el destino y las aplicaciones: Solo se requiere para algunos componentes de la plataforma, como la infraestructura, el hipervisor y el almacenamiento. El proveedor de la nube debe ofrecer evidencia al suscriptor de la nube acerca del estado actual de la plataforma (los detalles de los informes dependen del nivel de servicio).

Aislamiento de red y firewall de los sistemas del suscriptor de la nube con gestión: Esto es necesario para todos los niveles de servicio. Sin embargo, el aislamiento debe ser garantizado de forma automática por la plataforma. El suscriptor de la nube puede separar aún más la red y definir reglas de firewall. Esto puede ser diferente para los distintos niveles de SLA. El suscriptor de la nube debe gestionar el conjunto de reglas de firewall en los niveles oro y platino, y el proveedor de la nube debe hacerlo en los niveles bronce y plata. El proveedor de la nube garantizará un conjunto de reglas predeterminado seguro.

Control de acceso físico al centro de datos de la nube: Necesario para todos los niveles. Es posible contar con diferentes tipos de centro de datos para diferentes niveles de servicio (1, 2, 3 y 4).





Protocolos de seguridad utilizados para la administración remota, como SSL, SSH y RDP: Necesario para todos los niveles de servicio.

Se eliminan todas las contraseñas predeterminadas y el accesos de invitado: Necesario para todos los niveles de servicio.

Uso necesario de Acuerdos de confidencialidad (NDA) para el personal del proveedor de la nube: Necesario para todos los niveles de servicio. Esto también incluirá un acuerdo de privacidad de los datos en la Unión Europea, por ejemplo.

Alineación necesaria con la Biblioteca de infraestructura de tecnología de la información (ITIL): procesos para la gestión de configuración, incidentes y cambios. Necesario para todos los niveles de servicio.

Gestión de identidades para los activos del suscriptor: Solo se aplica para la API o los servicios de gestión de la nube. Mecanismos de autenticación para niveles bronce, plata, oro y platino según se describe en el Modelo de uso de ODCA: Garantía del proveedor.19

Gestión de la retención y la eliminación de la datos: Tal como se describe en el Modelo de uso de ODCA: Garantía del proveedor,19

además de finalizar y eliminar el servicio de la nube (Modelo de uso principal de ODCA: Instrumentación del servicio21).

Monitoreo de eventos e incidentes de seguridad: Se limita a la infraestructura del proveedor de la nube, por debajo del sistema operativo. Mecanismos para niveles bronce, plata, oro y platino según se describe en el Modelo de uso de ODCA: Garantía del proveedor.19

Prevención de intrusiones en la red (NIPS): En IaaS, la NIPS solo se requiere en el nivel físico, en la red o en el hipervisor y no en el nivel de VM. Como tal, es responsabilidad del proveedor de la nube.

Registro de todos los eventos en el ámbito de la administración: Necesario para todos los niveles de servicio en la infraestructura de la nube. Debe implementarse según se define en el Modelo de uso de ODCA: Garantía del proveedor19 para eventos administrativos del suscriptor de la nube, como el servicio de API de gestión de la nube.19

Principio de supervisión doble (Four-Eye Principle) para los cambios administrativos claves: Debe implementarse según se define en el Modelo de uso de ODCA: Garantía del proveedor.19 Un cambio administrativo clave se define como cualquier cambio que realiza el proveedor de la nube que puede afectar el servicio o la seguridad de uno o más suscriptores de la nube.

El proveedor de la nube tiene un plan de continuidad implementado y probado: Debe implementarse según se define en el Modelo de uso de ODCA: Garantía del proveedor,19 y necesita abordar la tecnología, los procesos y el personal.

Red controlada y documentada por completo: Debe implementarse según se define en el Modelo de uso de ODCA: Garantía del proveedor.19 La documentación de alto nivel y un mapa de la red son necesarios.

Debe existir documentación detallada que contenga detalles acerca de los procedimientos operativos de los procesos y la certificación de seguridad, así como información sobre la seguridad de la infraestructura de gestión de la nube, como un concepto de seguridad del cliente. El nivel de detalle de esta documentación puede variar de acuerdo con el nivel de servicio.

Cuando se utiliza un código personalizado, los sistemas deben desarrollarse con un estándar seguro de codificación del ciclo de vida del desarrollo de software:29 para CIaaS la mayoría del software será software comercial por lo que el proveedor de la nube tiene un control limitado sobre el software. El proveedor de la nube debe contar con un proceso de ingeniería definido para el diseño, la implementación y el desarrollo de la infraestructura de la nube. Este proceso debe incluir seguridad.

Opción para pruebas de penetración en los sistemas y las aplicaciones hospedados: Cualquier prueba de penetración realizada por el proveedor o por el suscriptor debe informarse por adelantado a las partes involucradas. El suscriptor puede realizar la prueba de penetración solo en los componentes de la VM (instancia informática), y no directamente en otros componentes, como LUN o dispositivos de red físicos subyacentes aunque compre esos servicios.

Solo el proveedor de la nube puede realizar la prueba de penetración sobre otros componentes, incluidos los componentes de gestión, como el catálogo de servicio y la instrumentación del servicio, etc. A pedido, el proveedor de la nube debe proporcionar los resultados o la certificación de la prueba al suscriptor de la nube, según el NDA.

Segmentación física de hardware, como servidor, almacenamiento, red, etc., para garantizar el aislamiento de todos los otros sistemas: Debe implementarse según se define en el Modelo de uso de ODCA: Garantía del proveedor.19













Comunicación cifrada entre el proveedor y el suscriptor de la nube: Debe implementarse según se define en el Modelo de uso de ODCA: Garantía del proveedor.19 Esto probablemente se implementará en nubes privadas externas independientemente del nivel de servicio, como a través de VPN de sitio a sitio.

Autenticación de varios factores: Debe implementarse según se define en el Modelo de uso de ODCA: Garantía del proveedor.19 Es posible que se necesiten diferentes métodos para la infraestructura de la nube, así como para la API de gestión de la nube que también está disponible para el suscriptor de la nube.

Capacidad del suscriptor de la nube para definir límites geográficos para el hospedaje: Debe implementarse según se define en el Modelo de uso de ODCA: Garantía del proveedor.19

Cifrado de almacenamiento en el nivel de número de unidad lógica (LUN): Debe implementarse según se define en el Modelo de uso de ODCA: Garantía del proveedor.19 Es posible que en este momento existan limitaciones técnicas que dificultan algunas situaciones. En ese caso, el suscriptor de la nube debe poder cifrar el sistema de archivos de la VM individual.

Sin acceso administrativo para el personal del proveedor de la nube: Relevante solo para el contenido de la VM. El proveedor de la nube tiene acceso administrativo a todos los demás componentes, como migración y mantenimiento. Nivel de servicio platino: Consulte el supuesto general al comienzo de esta sección.

El cifrado de alta seguridad es necesario para todos los datos al vuelo y en reposo: Para las VM y los datos persistentes, esto es responsabilidad del suscriptor de la nube En la API de gestión de la nube esto ya está cubierto por los requisitos de protocolos de seguridad.

Para los datos no persistentes, por ejemplo datos al vuelo, o dentro de los dispositivos o del almacenamiento de la red del proveedor, los requisitos se ajustan al Modelo de uso de ODCA: Garantía del proveedor.19 Nivel de servicio platino: Consulte el supuesto general en la parte superior del documento.

Además de estos requisitos de seguridad, el proveedor de la nube puede proporcionar servicios de valor agregado adicionales, como dispositivos de seguridad previamente configurados (VM, Módulos de seguridad de hardware [HSM] virtuales y Módulos de plataforma confiable virtuales, [vTPM]) que puede utilizar el proveedor de la nube.

11.2 Pautas de implementación:

11.2.1 Supuestos:Los niveles de servicio bronce y plata pueden hospedarse en los mismos hardware y software de infraestructura que tienen las separaciones lógicas.

El nivel oro puede hospedarse en el mismo hardware y en la misma infraestructura solo con otros clientes de nivel oro. No se comparte el hardware ni la infraestructura entre los niveles oro, plata o bronce.

El nivel platino tiene un hardware y un software de infraestructura por separado para cada suscriptor de la nube, como se indica a continuación:

• El proveedor de la nube no tiene acceso administrativo: "no está gestionado".

• El proveedor de la nube tiene acceso administrativo para el hardware y el software de infraestructura, o “está gestionado”.

11.2.2 Pautas generales:La separación lógica (control de acceso) y el sistema de protección de servicios se aplican a todos los componentes.

El aprovisionamiento de identidades (ciclo de vida) se implementará de acuerdo con los escenarios de uso del Modelo de uso de ODCA: Aprovisionamiento de identidades basado en la nube.30

El acceso privilegiado a tareas de administración, aprovisionamiento de servicio, auditoría, elaboración de informes, etc. se implementará de acuerdo con los escenarios de uso del Modelo de uso de ODCA: Acceso privilegiado de usuarios a la Infraestructura como servicio (IaaS).31

Es posible compartir entre los niveles de servicio los recursos de Información de seguridad y gestión de eventos (SIEM) para el personal, las consolas administrativas, etc.; las sondas de red (NIPS/Sistema de detección de intrusos en una red [NIDS], etc.) deben estar separadas para los niveles bronce/plata, oro y platino. Los niveles bronce y plata pueden compartir las sondas de red.

Seguridad de red: Las mitigaciones de nivel 2 y 3 deben implementarse en todos los firewall, enrutadores e interruptores físicos y lógicos para el almacenamiento y la red.






http://www.opendatacenteralliance.org/docs/Cloud_Based_Identity_Provisioning_%20b.pdf


http://www.opendatacenteralliance.org/docs/Infrastructure_as_a_Service_(Iaas)_Privileged_User_Access_Rev_1.0_b.pdf



11.2.3 Pautas específicas de los niveles de servicio:Bronce y plata:

VM: pueden compartir la misma instancia de hardware e hipervisor con otras VM.

Almacenamiento: todos los LUN pueden compartir el mismo hardware, por ejemplo, interruptores, puertas de enlace, ejes y Unidades de estado sólido (SSD).

Red: hardware compartido: físico y virtual. Se configuran VLAN diferentes para cada cliente.

Firewall virtual: lo comparten todos los clientes y lo gestiona el proveedor de la nube.

Herramientas de gestión: pueden compartir la misma instancia.

Oro:

VM: pueden compartir las mismas VM de instancia de hardware e hipervisor solo en el mismo nivel de servicio oro.

Almacenamiento: pueden compartir el mismo hardware, por ejemplo, interruptores, puertas de enlace, ejes y SSD solo con otros clientes de nivel oro.

Red: hardware compartido, físico y virtual, solo con suscriptores de nivel oro. Se configuran VLAN diferentes para cada cliente.

Firewall virtual: cada cliente gestiona su propia instancia de firewall virtual. Herramientas de gestión: se comparten solo con otros suscriptores de nivel oro.

Platino:

VM: instancias de hardware e hipervisor separadas para cada cliente.

Almacenamiento: hardware separado (interruptores, puertas de enlace, ejes, SSD, etc.) para cada cliente.

Red: hardware separado para cada cliente.

Herramientas de gestión: instancia separada para cada cliente.

11.3 Catálogo de servicios de seguridadPara conocer los elementos básicos del catálogo de servicios, consulte también el Modelo de uso principal de ODCA: Instrumentación de servicio.21 Aquí se cubrirán los atributos de seguridad más específicos.

Para los niveles de servicio oro y platino, el catálogo de servicios del proveedor debe enumerar la ubicación geográfica y jurisdiccional de los servicios, para que el suscriptor cumpla las restricciones regulatorias del lugar.

Para el nivel de servicio oro, la entrada del catálogo referida al servicio de copia de seguridad debe indicar si el suscriptor puede realizar la gestión clave de las cintas de copia de seguridad. Para el nivel platino, la gestión clave de las cintas de copia de seguridad debe estar a cargo del suscriptor, el catálogo de servicios debe indicar si las cintas de copia de seguridad pueden entregarse al suscriptor para que las almacene en sus instalaciones.

11.4 Protección contra malwareEl software malintencionado (malware) es una de las amenazas más significativas de la informática en la nube, en especial debido a la velocidad con la que un sistema infectado puede propagar el malware a un grupo informático altamente virtualizado y denso. Esto puede provocar la denegación del servicio debido al tráfico legítimo causado por estos hosts infectados con malware que intentan propagarse o iniciar ataques contra otros servicios.

El malware en el hipervisor informático no prolifera tanto como en la VM. Esto se debe a la naturaleza limitada de la superficie de ataque. Sin embargo, la propagación del malware puede provocar interrupciones del servicio en la infraestructura subyacente debido a la contención de red o de E/S.

El Modelo de uso de ODCA: Garantía del proveedor19 recomienda utilizar protección contra malware y antivirus en todos los niveles de seguridad, desde bronce hasta platino. Sin embargo, es posible que esto sea difícil de lograr en el nivel de recursos informáticos o del hipervisor, ya que las plataformas y los productos antimalware y antivirus, en general, no cubren este segmento de la pila.






Como consecuencia, deben realizarse controles para proteger la infraestructura subyacente contra los ataques. Los firewall ya son necesarios en todos los niveles de seguridad. Esto ofrece una protección básica a la infraestructura subyacente. En el nivel plata y en los niveles superiores, los sistemas de prevención de intrusiones deben aplicar las firmas apropiadas para detectar y evitar ataques basados en firmas.

Además, el proveedor de la nube debe garantizar que se proporcione la segregación y protección adecuadas a los clientes en el caso de que se produzca un ataque de malware en el entorno de otro suscriptor.

La protección contra malware, como los firewall de aplicaciones web, debe implementarse para proteger los servicios de gestión de uso público. La infraestructura subyacente de hipervisor y de back-end debe ser un medio que garantice la integridad de la plataforma.

11.5 Control de admisiónCualquier interfaz de gestión que se exponga al suscriptor de la nube debe, al menos, cumplir los requisitos de seguridad definidos por los niveles de servicio bronce, plata, oro y platino. Además, la exposición de estas interfaces es diferente en las nubes públicas y privadas, y es posible que requiera medidas de seguridad adicionales, como una interfaz expuesta al público. La gestión del usuario de estas interfaces se define en el Modelo de uso de ODCA: Acceso privilegiado de usuarios a la Infraestructura como servicio (IaaS),31 y debe respetar las correspondientes definiciones del nivel de aseguramiento. Los mecanismos de autenticación necesarios para los niveles bronce, plata, oro y platino se describen en detalle en el Modelo de uso de ODCA: Garantía del proveedor.19

Esta sección especifica de forma más detallada los requisitos para estas interfaces. Tipos de interfaces:

Portal de servicios (basado en la Web):

Bronce: protocolos de seguridad, mínimos controles de complejidad de contraseña (no hay renovaciones forzadas ni controles de reutilización), interfaz pública, sistema compartido.

Plata: protocolos de seguridad, reglas de prácticas recomendadas de complejidad de contraseña, autenticación opcional de dos factores basada en token de software, interfaz privada virtual, sistema compartido.

Oro: protocolos de seguridad, autenticación de dos factores e interfaz privada o pública virtual, como una conexión directa dedicada.

Platino: protocolos de seguridad, autenticación de dos o más factores (incluye biometría), interfaz privada, como una conexión directa dedicada.

El sistema debe admitir el Lenguaje de marcado de aserción de seguridad (SAML) para aceptar la federación entre los sistemas del proveedor y el suscriptor de la nube, así como de forma interna.

El portal de servicio en esta instancia aprovisiona y anula el aprovisionamiento de nuevas VM, amplía el almacenamiento, la memoria y otros dispositivos, así como la facturación, la elaboración de informes de incidentes y la disponibilidad de estadísticas de servicio que no se investigan a través de las API.

API de gestión de la nube:

Igual que lo que se mencionó antes. Todas las interfaces basadas en servicios web deben utilizar seguridad XML o autenticación mutua entre pares. La autenticación y la autorización deben poder gestionarse a través del portal de servicio de la nube.

Acceso al sistema virtual:

SSH, RDP u otro ki12 jm55access para los hosts. El suscriptor de la nube debe utilizar controles de protocolos de seguridad, como SSH y RDP, al acceder a las máquinas virtuales.

Consola de servicio de la VM:

Igual que lo que se mencionó antes para el nivel de seguridad platino y para protocolos no seguros o protocolos sin cifrado de alta seguridad. Debe utilizarse un host bastión para acceder a la consola de servicio. El equipo bastión debe admitir el registro de eventos de autenticación y el registro de pulsaciones del teclado. El acceso a la consola de servicio debe utilizar el mismo backend de Gestión de identidades (IDM), y debe integrarse a través del Inicio único de sesión (SSO).

Otras interfaces:

Las demás interfaces que no pueden integrarse al portal de servicio de la nube deben admitir el mismo nivel de seguridad que el portal de servicio. El acceso a este servicio debe utilizar el mismo backend de IDM, y debe integrarse a través del SSO.





11.6 Auditoría y gobierno de seguridadUna auditoría y gobierno de seguridad efectivos y eficaces requieren un enfoque proactivo del suscriptor y del proveedor de los servicios de la nube, independientemente de los siguientes sectores:

• La gestión que tiene a cargo y es responsable de admitir y proporcionar íntegramente instrucciones y de regir el gobierno de TI que incluye al personal, los procesos, los procedimientos, el sistema, las tecnologías, las redes y la información.

• La seguridad se considera un requisito empresarial alineado con las metas estratégicas, los objetivos empresariales, los planes de gestión de riesgos y los requisitos y las políticas de cumplimiento.

•Decisiones basadas en los riesgos para la gestión de riesgos, las obligaciones regulatorias y la comercialización en donde se realiza una evaluación integral del riesgo seguida de un plan de gestión de riesgos.

• Los requisitos de seguridad se implementan a través de políticas y procedimientos.

• El personal con acceso a la información cuenta con conocimiento y capacitación. Comprenden sus responsabilidades diarias para proteger y preservar la confidencialidad, la integridad y la disponibilidad de la información. La capacitación en la comprensión de la seguridad se realiza de forma rutinaria y consistente.

•Garantizar el cumplimiento de los requisitos regulatorios aplicables (como privacidad, seguridad, continuidad del negocio) y de los requisitos de la política del suscriptor de la nube. Este cumplimiento debe poder auditarse y debe ser consistente al momento de la aplicación. Consulte el Modelo de uso de ODCA: Marco regulatorio13 que ofrece un flujo de procesos para comprometerse con las agencias reguladoras y que gestiona los requisitos asociados con el gobierno y el cumplimiento durante el ciclo de vida de la nube.

11.6.1 Escenario de uso del gobierno de seguridadEl siguiente modelo de uso demuestra de qué forma la auditoría y el gobierno de seguridad pueden lograrse en una CIaaS según el Modelo de uso de ODCA: Marco regulatorio.13

Actores: suscriptor de la nube, proveedor de la nube, agencia reguladora, auditor externo

Objetivos:

1. Garantizar que los suscriptores de la nube tengan la capacidad de evaluar de forma eficiente la implementación de sus propias políticas y de las obligaciones regulatorias locales, federales, internacionales e industriales que utilizan un enfoque estandarizado y repetible al comprometerse y adquirir los servicios de los proveedores de la nube.

2. Garantizar que los suscriptores de la nube puedan exigir o especificar requisitos claves de sus propias políticas y de las obligaciones regulatorias que deberán cumplir los proveedores de la nube para los sectores industriales verticales a los que desean ofrecer servicios.

3. Garantizar que los proveedores de la nube puedan demostrar de forma eficiente su capacidad para cumplir con las políticas del suscriptor de la nube y con las obligaciones regulatorias locales, federales, internacionales e industriales a partir de perspectivas geográficas, jurisdiccionales e industriales de forma auditable.

Consideraciones:

1. Se asume que las agencias reguladoras, las obligaciones regulatorias y los estándares del sector primario, locales, federales e internacionales pueden identificarse con facilidad, y se indica que habrá algunas tareas necesarias de monitoreo y mantenimiento de los requisitos regulatorios.

2. Por último, el suscriptor de la nube tiene la responsabilidad de garantizar el cumplimiento de sus propias políticas y de todas las regulaciones geográficas y basadas en el sector.

Escenario de éxito 1: El proveedor de la nube debe demostrar fehacientemente que cumple con las regulaciones geográficas y basadas en el sector aplicables para cumplir las necesidades de los suscriptores de la nube. Este cumplimiento debe poder auditarse y debe ser consistente al momento de la aplicación.

El proveedor de la nube puede implementar cambios y nuevos requisitos regulatorios y adherirse a ellos con un impacto mínimo en los suscriptores de la nube existentes.

El suscriptor o el proveedor de la nube recibe una notificación de cualquier cambio material de las regulaciones, leyes y requisitos de cumplimiento que se aplique a sus propias políticas o a la ubicación geográfica y al sector de manera formal y oportuna, de forma que la sociedad del suscriptor y el proveedor de la nube puede acordar qué cambios de servicio, de existir alguno, son necesarios para cumplir con los cambios materiales de las normas o leyes.




Nota: La eficiencia del sector mejorará si los proveedores de la nube cuentan con una declaración legal en la cual los suscriptores de la nube pueden confiar con respecto al cumplimiento de las leyes y regulaciones locales y nacionales específicas.

Condición de falla 1: El proveedor de la nube no puede demostrar ni mantener las regulaciones o los requisitos de cumplimiento de estándares aplicables, como privacidad, seguridad y continuidad del negocio, ni puede cumplir con los requisitos de la política del suscriptor de la nube.

Manejo de fallas: Para todas las condiciones de falla, tanto el proveedor como el suscriptor de la nube deben evaluar su incapacidad de cumplir con los requisitos regulatorios y de cumplimiento de estándares aplicables, y tomar acciones correctivas.

Requisitos:

• Los suscriptores de la nube deben desarrollar un programa de cumplimiento corporativo y de gestión de riesgos constante.

• Los suscriptores de la nube deben comprender las implicaciones de la ubicación geográfica de los datos, las consideraciones de propiedad de los datos, las restricciones de acceso y los aprovisionamientos, así como de las obligaciones regulatorias que rigen la protección, la privacidad, la propiedad y los flujos de datos.

• Los proveedores de la nube deben comprender las necesidades legales, regulatorias y de cumplimiento de cada sector del mercado objetivo de sus suscriptores de la nube para poder ajustar los servicios para que cumplan las necesidades específicas de ese sector. Dado que los proveedores de la nube pueden colaborar con los suscriptores de la nube para que cumplan mejor con sus obligaciones, los proveedores de la nube estarán mejor posicionados para atraer y retener negocios, y para desarrollar una sólida reputación con las agencias reguladoras aplicables.

El correcto ejercicio de los requisitos regulatorios en las instituciones del suscriptor de la nube incluye las siguientes obligaciones:

• Contar con una política relacionada con la subcontratación de actividades comerciales importantes.

• Contar con un adecuado plan de gestión de riesgos para satisfacer las obligaciones y gestionar los riesgos que presenta el acuerdo de subcontratación.

• Contar con un proceso de monitoreo suficiente para gestionar la subcontratación de las actividades comerciales importantes.

• Contar con un acuerdo legalmente vinculante para la subcontratación de las actividades comerciales importantes, a menos que las agencias reguladoras correspondientes acuerden lo contrario.

•Garantizar el cumplimiento de todas las leyes y estatutos aplicables que rigen la ubicación y el tipo de negocio llevado a cabo, como las leyes de privacidad de datos, las leyes de secreto bancario y la Ley Gramm-Leach-Bliley.

• Consultar con las agencias reguladoras correspondientes antes de celebrar acuerdos para subcontratar actividades comerciales importantes con proveedores de la nube que realizan sus actividades fuera del país del suscriptor de la nube.

•Notificar a las agencias reguladoras correspondientes antes de celebrar acuerdos para subcontratar actividades comerciales importantes.

12.0 Consideraciones comercialesConsulte el Modelo de uso principal de ODCA: Marco comercial12 para obtener más información.

13.0 Consideraciones regulatoriasConsulte el Modelo de uso principal de ODCA: Marco comercial12 para obtener más información.

14.0 Requisitos de solicitudes de propuesta (RFP)A continuación se presentan los requisitos que Alliance cree que deben incluirse en las solicitudes de propuesta que se realizan a los proveedores de la nube para garantizar que los servicios propuestos admitan CIaaS.

Requisito de principio de ODCA: el servicio es abierto y se basa en estándares. Describir de qué forma el servicio cumple con este principio y las limitaciones para con el principio de ODCA.

Modelo de uso 1.0 de CIaaS de ODCA: Gestión de operaciones de TI. El servicio debe admitir un amplio espectro de sistemas operativos x86, incluidos Windows (SO para equipos de escritorio y servidores), Solaris x64 y Linux (distribuciones líderes) en versiones de 32 y 64 bits.





Modelo de uso 1.0 de CIaaS de ODCA: Gestión de operaciones de TI: este servicio debe admitir controles de aislamiento de red para el tráfico de entrada y de salida.

Modelo de uso 1.0 de CIaaS de ODCA: Gestión de operaciones de TI: el servicio debe admitir la implementación de componentes web, de aplicaciones, de base de datos y de servicio de infraestructura, como los componentes del Protocolo ligero de acceso a directorios (LDAP).

Modelo de uso 1.0 de CIaaS de ODCA: Gestión de operaciones de TI: el servicio debe admitir la alineación con los procesos de la Biblioteca de infraestructura de tecnología de la información (ITIL) para la gestión de configuración, incidentes y cambios.

Modelo de uso 1.0 de CIaaS de ODCA: Gestión de red: el proveedor de servicios debe proporcionar opciones para la conectividad de red del consumidor, como la VPN de Internet y líneas arrendadas. Más aún, el proveedor de servicios debe articular cualquier otra restricción, condición o requisito de red, como la traducción de dirección de red (NAT), la superposición de direcciones IP y los controles de latencia.

Modelo de uso 1.0 de CIaaS de ODCA: Gestión de red: el servicio debe incluir instrumentación para proporcionarle al consumidor un panorama del ancho de banda, el rendimiento y la latencia. Estos deberían estar disponibles a través de las interfaces de servicio (incluida la interfaz del usuario del portal de servicios y la interfaz de programación de aplicaciones [API]).

Modelo de uso 1.0 de CIaaS de ODCA: Gestión de seguridad: El proveedor de servicio debe proporcionar arquitectura, diseño, política y otros elementos que demuestren el grado en el cual el servicio del suscriptor de la nube es segregado de otros suscriptores. Esto se aplica a servicios de nube de un solo cliente o de clientes múltiples.

Modelo de uso 1.0 de CIaaS de ODCA: Gestión de seguridad: el proveedor de la nube debe afirmar formal y explícitamente que la seguridad de procesamiento, de la red y del almacenamiento cumplen con los requisitos del nivel contratado por el suscriptor de la nube (bronce, plata, oro o platino). Adicionalmente, el proveedor de la nube debe admitir una verificación independiente.

Modelo de uso 1.0 de CIaaS de ODCA: Gestión de seguridad: en un entorno de nube gestionado, ciertos software usados por el suscriptor dentro de la nube deben integrarse con las herramientas de monitoreo provistas en la nube que aseguran la integridad de esta. Esto incluye los software de prevención y detección de intrusiones, registros de umbrales de acceso y más.

Modelo de uso 1.0 de CIaaS de ODCA: Gestión de la carga de trabajo: el servicio debe proporcionar flexibilidad de volumen y permitirle al consumidor aumentar o disminuir los recursos que se consumen.

Modelo de uso 1.0 de CIaaS de ODCA: Gestión de la carga de trabajo: el servicio debe ser capaz de integrarse con las herramientas de gestión de la nube del consumidor, de manera programada.

Modelo de uso 1.0 de CIaaS de ODCA: Gestión de la carga de trabajo: el servicio debe permitirle al consumidor cambiar las reglas y los parámetros de la política de carga de trabajo cuando este lo desee y dentro de criterios específicos.

Modelo de uso 1.0 de CIaaS de ODCA: Gestión de la carga de trabajo: el servicio debe proporcionar un portal de gestión de servicios de nube.

Modelo de uso 1.0 de CIaaS de ODCA: Gestión de cumplimiento: el proveedor debe aceptar, cumplir y permitir el cumplimiento de las políticas y los marcos regulatorios, las auditorías externas e internas, las certificaciones y los estándares mínimos y la gestión de resultados. Los proveedores pueden ser sancionados en el caso de falta de control.

Modelo de uso 1.0 de CIaaS de ODCA: Gestión de cumplimiento: pueden existir requisitos procedimentales y técnicos basados en el sector del suscriptor de la nube o en el país en el que este opera o tiene clientes. Esto también puede incluir requisitos, como datos que deben permanecer en el país de origen o pruebas de recuperación ante desastres prescriptivas o regulares. Es posible que se requiera que el suscriptor de la nube proporcione evidencia de cumplimiento, y por lo tanto, puede necesitar la asistencia del proveedor para proporcionarla.

Modelo de uso 1.0 de CIaaS de ODCA: Gestión de problemas: el proveedor de la nube debe haber establecido un análisis efectivo del origen de los incidentes, relacionado con los servicios consumidos o contratados, para prevenir la recurrencia de impactos negativos en el servicio.

Modelo de uso 1.0 de CIaaS de ODCA: Gestión de continuidad del servicio: el proveedor de la nube debe tener procesos efectivos para garantizar que los servicios de TI puedan recuperarse y continuar, incluso, después de que ocurran incidentes graves. Esto también incluirá la continuidad del negocio de proveedores de materiales.

Modelo de uso 1.0 de CIaaS de ODCA: Gestión de continuidad del servicio: el proveedor de la nube debe garantizar que un suscriptor de nube externo no pueda impactar en el suscriptor de la nube, como en situaciones de “vecino ruidoso”.

Modelo de uso 1.0 de CIaaS de ODCA: Gestión de vulnerabilidad: El proveedor de la nube debe establecer una práctica regular para identificar, clasificar, remediar y mitigar las vulnerabilidades, incluida la gestión de parches. Además, el proveedor debe notificar al suscriptor de la nube cualquier acción o incidente, conocido o sospechado, que pueda poner en riesgo los activos o los datos del suscriptor de la nube a través del servicio del proveedor.



Modelo de uso 1.0 de CIaaS de ODCA: Gestión de vulnerabilidad: El proveedor de la nube trabaja estrechamente con su proveedor de servicios de Internet (ISP) y con organizaciones de seguridad internacionales y regionales, para prevenir ataques por Internet a los suscriptores o a su infraestructura. El proveedor tiene un equipo de respuesta ante riesgos y un equipo de operaciones de seguridad que se encuentran capacitados para responder rápidamente ante ataques y para evitar que sus clientes sufran algún impacto. Además, para los servicios oro y platino, los ataques de denegación de servicio (DOS) y de denegación de servicio distribuida (DDOS) se contienen filtrando los servidores de ataque lo antes posible en la infraestructura del ISP.

Modelo de uso 1.0 de CIaaS de ODCA: Gestión de vulnerabilidad: Para los niveles de servicio plata, oro y platino, el suscriptor cuenta con un sistema de gestión de vulnerabilidades en el sitio y aplica parches de seguridad de manera oportuna, según se define en el Modelo de uso de ODCA: Garantía del proveedor.

Modelo de uso 1.0 de CIaaS de ODCA: Gestión de vulnerabilidad: Para los niveles de servicio oro y platino, el suscriptor puede realizar análisis de sus registros de aplicaciones y accesos, y comunica patrones identificados al proveedor, para mejorar la precisión de los filtros del proveedor.

Modelo de uso 1.0 de CIaaS de ODCA: Servicio de monitoreo: El proveedor de la nube debe monitorear el entorno, incluido los eventos, la capacidad, la seguridad y la utilización, para garantizar que se cumplan los SLA. Los datos de monitoreo del proveedor deben proporcionarse según las API estandarizadas.

Modelo de uso 1.0 de CIaaS de ODCA: Servicio de monitoreo: Si los análisis y el monitoreo de los niveles de la aplicación apuntan a la infraestructura, las estadísticas de la infraestructura deben ser de fácil acceso y disponibilidad para realizar análisis de origen de los problemas, para resolver los problemas y para proporcionar advertencias tempranas de los problemas que pueden llegar a ser prevenibles.

Modelo de uso 1.0 de CIaaS de ODCA: Gestión de incidentes: El proveedor de la nube debe informar al suscriptor de la nube acerca de los incidentes que pueden afectarlo. Se deben establecer acuerdos predefinidos sobre la prioridad de un incidente y el nivel de esfuerzo requerido por el proveedor de la nube durante un incidente. Se deben establecer interfaces automatizadas y estandarizadas para gestionar incidentes.

Modelo de uso 1.0 de CIaaS de ODCA: Gestión de incidentes: Cuando se producen incidentes más serios, tal como se acordó en un contrato entre el proveedor y el suscriptor, el proveedor de la nube debe notificar a los clientes afectados dentro de las 48 horas.

Modelo de uso 1.0 de CIaaS de ODCA: Gestión de incidentes: Las respuestas a los incidentes deben estar acordadas entre el suscriptor y el proveedor para que sean lo más eficaces posible. Las actividades coordinadas ayudan a prevenir la degradación de servicios al evitar las acciones que generan conflictos.

Modelo de uso 1.0 de CIaaS de ODCA: Gestión de cambios: El proveedor de la nube debe notificar al suscriptor de la nube siempre que un cambio en la configuración o en otro aspecto operativo afecte las capacidades del servicio de la otra parte. La gestión proactiva se requiere para garantizar un entorno estable.

Modelo de uso 1.0 de CIaaS de ODCA: Gobierno: El proveedor debe cumplir y permitir el cumplimiento de las políticas y los marcos regulatorios, las auditorías externas e internas, las certificaciones y los estándares mínimos y los controles de seguridad. Cuando no se cumplen los requisitos, se pueden establecer sanciones y la extinción de contratos.

Modelo de uso 1.0 de CIaaS de ODCA: Gobierno: Para los niveles de servicio oro y platino, el contrato entre el subscriptor y el proveedor, por lo general, estipulará limitaciones jurisdiccionales o geográficas de la ubicación en donde pueden almacenarse y procesarse los datos del suscriptor, incluida la ubicación de las cintas de copias de seguridad y de los sitios secundarios.

Modelo de uso 1.0 de CIaaS de ODCA: Gobierno: Para los niveles oro y platino, el proveedor debe notificar al suscriptor de la casa matriz o de la jurisdicción legal, si tiene una casa matriz estadounidense que se rige por la Ley Patriota de los EE. UU. (US PATRIOT ACT).

Modelo de uso 1.0 de CIaaS de ODCA: Aprovisionamiento de servicios: El proveedor debe contar con mecanismos automatizados eficaces para solicitar, aprovisionar, gestionar y medir el uso de los servicios, cuando sea posible.





15.0 Próximos pasos y resumen de acciones industriales requeridasCon la intención de otorgar instrucciones sobre cómo crear e implementar soluciones abiertas, de múltiples proveedores e interoperables, hemos identificado áreas específicas en las que Alliance cree que debe haber especificaciones abiertas, estándares formales o de hecho, o implementaciones comunes independientes de la propiedad intelectual (independientes de PI). Dado que Alliance tiene una recomendación específica sobre la especificación, los estándares o la implementación abierta, esta ha sido convocada en otro lugar en este modelo de uso principal. En otros casos, ODCA trabajará con el sector para evaluar y recomendar especificaciones en futuras versiones de este documento.

15.1 Acciones industriales requeridasEste modelo de uso principal hace referencia a los requisitos de otros modelos de uso de ODCA y los incorpora (consulte la sección "Referencias"). Esos requisitos deben considerarse integrados en los requisitos generales de CIaaS. Como consecuencia, las acciones industriales requeridas para todos los documentos de referencia de ODCA están incluidas aquí, y son de esta forma acciones industriales requeridas para CIaaS.

Acciones industriales específicas que vale la pena destacar:

• Los proveedores de soluciones y de servicios deben garantizar que sus ofertas de servicio y de productos distingan claramente entre capacidades centrales y diferenciadores. Los proveedores deben hacer referencia a sus ofertas y asignarlas a este y a otros documentos de ODCA. También debe indicarse de forma clara qué capacidades coinciden con el sector en general y cuáles son los diferenciadores únicos de ese proveedor.

• Las organizaciones de desarrollo de estándares (SDO) deben desarrollar y promocionar con determinación las interfaces y los procesos que facilitarán ofertas completas de CIaaS sin interrupciones que sean independientes de los proveedores.

• Los proveedores de servicios deben comunicar claramente de qué forma se asignan sus ofertas en relación con el Modelo de uso principal de ODCA: Marco comercial, 12 y cómo funcionan juntos los diferentes elementos de la arquitectura.

• Los clientes de la nube deben preparar de forma proactiva a sus organizaciones para los cambios en el modelo operativo y otras posibles interrupciones que puedan surgir al introducir los servicios de CIaaS de un proveedor externo.

• Las SDO deben desarrollar una semántica común estándar del sector para el aprovisionamiento de la nube.

• El sector debe desarrollar estándares de almacenamiento de objetos junto con las SDO.

• La virtualización de la red debe madurar, y deben desarrollarse estándares para esa virtualización de red.

• Los proveedores de soluciones y de servicios deben encontrar la forma de habilitar el uso compartido de estadísticas entre los sistemas y las herramientas de monitoreo de forma estandarizada y abierta, ya sea a través de API, adaptadores, extensiones o medios semejantes.

• La eficiencia del sector mejorará si los proveedores de la nube cuentan con una declaración legal en la cual los suscriptores de la nube pueden confiar con respecto al cumplimiento de las leyes y regulaciones locales y nacionales específicas.

Los proveedores de servicios y de soluciones deben tener en cuenta la visión real de monitoreo del usuario para controlar las secuencias de comandos de prueba de carga, ya que esas secuencias de comandos son los que mejor reflejan las combinaciones de transacciones que ocurren en función del uso real del usuario.

La transparencia es un concepto que requiere de atención específica. Los proveedores de servicios y de soluciones deben facilitar informes de incidentes, estadísticas, etc. de forma más sencilla y accesible, incluso publicando las estadísticas ellos mismos.32 Esa transparencia, sin embargo, debe ir más allá de los componentes de la infraestructura que no sean muy accionables o que no estén directamente relacionados con la experiencia del usuario. Una transparencia que mejore la experiencia del usuario final y el impacto comercial será más valorada por los suscriptores de la nube.

15.2 Desarrollo de los próximos requisitos de CIaaSLa versión 1.0 de este modelo de uso principal se ha enfocado en los requisitos de un único suscriptor de la nube comprometido con un único proveedor de la nube. Al reconocer la función de los agentes de servicios de la nube, la federación en la nube y los mercados en la nube, se ha elaborado poco acerca de la forma en que estos afectan los requisitos de CIaaS. Las próximas versiones del Modelo de uso principal de ODCA: Infraestructura informática como servicio (CIaaS) deben abordar esas cuestiones.

El almacenamiento de objetos no estaba incluido en la versión 1.0. Es posible que se trate en las próximas revisiones.



16.0 Referencias

MODELOS DE USO DE ODCAModelo de uso de ODCA: Cloud Based Identity Governance and Auditing (Gobierno y auditoría de identidades basados en la nube) http://www.opendatacenteralliance.org/document-sections/category/71-docs?download=677:HW_ODCA_Identity_Gov_Auditing_Rev1.0_final

Modelo de uso de ODCA: Cloud Based Identity Provisioning (Aprovisionamiento de identidades basado en la nube) http://www.opendatacenteralliance.org/document-sections/category/71-docs?download=679:ODCA_Identity_Provisioning_Rev1%200_final

ODCA Developing Cloud-Capable Applications White Paper (Notas técnicas sobre el desarrollo de ODCA de aplicaciones compatibles con la nube) http://www.opendatacenteralliance.org/index2.php?option=com_productsearch&view=lightbox&proid=17&ie=UTF-8&oe=UTF-8&q=prettyphoto&iframe=true&width=60%&height=90%

Modelo de uso principal de ODCA: Commercial Framework (Marco comercial) http://www.opendatacenteralliance.org/docs/ODCA_Commercial_Framework_MasterUM_v1.0_Nov2012.pdf

Modelos de uso de ODCA: Conceptual Overview and Document Map (Información general conceptual y asignación de documentos) http://www.opendatacenteralliance.org/document-sections/category/71-docs?download=454:conceptual_overview_and_document_map

Modelo de uso de ODCA: Guide to Interoperability Across Clouds (Guía para lograr la interoperabilidad entre nubes) http://www.opendatacenteralliance.org/docs/ODCA_Interop_Across_Clouds_Guide_Rev1.0.pdf

Modelo de uso de la ODCA: Identity Management Interoperability Guide (Guía de interoperabilidad para la gestión de identidades) http://www.opendatacenteralliance.org/document-sections/category/71-docs?download=676:HODCA_%20IdM_%20InteropGuide_Rev1%200_final

Modelo de uso de ODCA: Infrastructure as a Service (IaaS) Privileged User Access [Acceso privilegiado de usuarios a la Infraestructura como servicio (IaaS)] http://www.opendatacenteralliance.org/document-sections/category/71-docs?download=678:HW_ODCA_%20IdM_PrivAccess_Rev1.0_final

Modelo de uso de ODCA: Long Distance Workload Migration (Migración de la carga de trabajo a larga distancia) http://www.opendatacenteralliance.org/docs/Long_Distance_Workload_Migration_Rev1.0_b.pdf

Modelo de uso de ODCA: Provider Assurance (Garantía del proveedor) http://www.opendatacenteralliance.org/docs/Security_Provider_Assurance_Rev%201.1_b.pdf

Modelo de uso de ODCA: Regulatory Framework (Marco regulatorio) http://www.opendatacenteralliance.org/document-sections/category/71-docs?download=455:regulatory_framework

Modelo de uso maestro de ODCA: Service Orchestration (Instrumentación del servicio) http://www.opendatacenteralliance.org/docs/ODCA_Service_Orch_MasterUM_v1.0_Nov2012.pdf

Modelo de uso de ODCA: Single Sign On Authentication (Autenticación de inicio de sesión único) http://www.opendatacenteralliance.org/document-sections/category/71-docs?download=680:ODCA_idM_SingleSign_Rev1.0_final

Modelo de uso de ODCA: Standard Units of Measure for IaaS (Unidades de medida estándares para IaaS) http://www.opendatacenteralliance.org/document-sections/category/71-docs?download=458:standard_units_of_measure

Modelo de uso de ODCA: VM Interoperability in a Hybrid Cloud Environment (Interoperabilidad de la VM en un entorno de nube híbrido) http://www.opendatacenteralliance.org/docs/ODCA_VMInteroperability_Rev.1.1_Final.pdf

http://www.opendatacenteralliance.org/document-sections/category/71-docs?download=677:HW_ODCA_Identity_Gov_Auditing_Rev1.0_final

http://www.opendatacenteralliance.org/document-sections/category/71-docs?download=679:ODCA_Identity_Provisioning_Rev1%200_final

http://www.opendatacenteralliance.org/document-sections/category/71-docs?download=679:ODCA_Identity_Provisioning_Rev1%200_final

http://www.opendatacenteralliance.org/index2.php?option=com_productsearch&view=lightbox&proid=17&ie=UTF-8&oe=UTF-8&q=prettyphoto&iframe=true&width=60%25&height=90%25




http://www.opendatacenteralliance.org/document-sections/category/71-docs?download=454:conceptual_overview_and_document_map

http://www.opendatacenteralliance.org/docs/ODCA_Interop_Across_Clouds_Guide_Rev1.0.pdf



http://www.opendatacenteralliance.org/document-sections/category/71-docs?download=678:HW_ODCA_%20IdM_PrivAccess_Rev1.0_final









http://www.opendatacenteralliance.org/document-sections/category/71-docs?download=680:ODCA_idM_SingleSign_Rev1.0_final

http://www.opendatacenteralliance.org/document-sections/category/71-docs?download=680:ODCA_idM_SingleSign_Rev1.0_final



http://www.opendatacenteralliance.org/docs/ODCA_VMInteroperability_Rev.1.1_Final.pdf



Otras fuentesCloud Computing: Principles and Paradigms (Informática en la nube: Principios y paradigmas); Buyya, Broberg, Goscinski; John Wiley & Sons; 2011; pág. 130

Cloud Federation (Federación en la nube); Kurze, y otros; http://www.aifb.kit.edu/images/0/02/Cloud_Federation.pdf

Cloudscaling Infrastructure-as-a-Service Builder’s Guide, Network Edition: The Case for Network Virtualization (Guía del desarrollador de la infraestructura como servicio de escala en la nube, Edición de red: El caso de la virtualización de red) (v1.0.4, cuarto trimestre de 2010)

Cloud Management for Communications Service Providers (Gestión de la nube para proveedores de servicios de comunicaciones) del grupo DMTF http://www.dmtf.org/sites/default/files/standards/documents/DSP2029%20_1.0.0a.pdf

NIST Cloud Computing Reference Architecture (Arquitectura de referencia de la informática en la nube de NIST) http://www.nist.gov/customcf/get_pdf.cfm?pub_id=909505

NIST Cloud Specific Terms and Definitions (Términos y definiciones específicos de la nube de NIST) http://collaborate.nist.gov/twiki-cloud-computing/pub/CloudComputing/ReferenceArchitectureTaxonomy/Taxonomy_Terms_and_Definitions_version_1.pdf

NIST Definition of Cloud Computing http://csrc.nist.gov/publications/nistpubs/800-145/SP800-145.pdf

ODCA Proposal Engine Assistant Tool (Herramienta de ayuda del motor de propuestas de ODCA, PEAT) http://www.opendatacenteralliance.org/ourwork/proposalengineassistant

TR174 Addendum A-Cloud Business Models (Modelos comerciales de la nube; Apéndice A TR174 de TM Forum) http://www.opendatacenteralliance.org/docs/tmforum_tr174addendum_cloudbusinessmodels.pdf

TR174 Enterprise-Grade External Compute IaaS Requirements (Virtual Private Cloud) [Requisitos de CIaaS externa de grado empresarial (Nube privada virtual); TR174 de TM Forum] http://www.opendatacenteralliance.org/docs/tmforum_tr174enterprisegrade_computeiaasrequirements.pdf

TR174 Addendum C Enterprise-Grade Virtual Private Cloud from a State-of-the-Art Reference Implementation (Nube privada virtual de grado empresarial a partir de una implementación de referencia de vanguardia; Apéndice C TR174 de TM Forum) http://www.opendatacenteralliance.org/docs/tmforum_tr174enterprisegrade_referenceimplementation.pdf

http://www.aifb.kit.edu/images/0/02/Cloud_Federation.pdf

http://www.dmtf.org/sites/default/files/standards/documents/DSP2029%20_1.0.0a.pdf

http://www.nist.gov/customcf/get_pdf.cfm?pub_id=909505


http://www.opendatacenteralliance.org/ourwork/proposalengineassistant

http://www.opendatacenteralliance.org/ourwork/proposalengineassistant



Notas finales1. NIST Cloud Computing Reference Architecture (Arquitectura de referencia de la informática en la nube de NIST) http://www.nist.gov/customcf/

get_pdf.cfm?pub_id=909505

2. Cloud Federation http://www.aifb.kit.edu/images/0/02/Cloud_Federation.pdf

3. Maintenance Window http://en.wikipedia.org/wiki/Maintenance_window

4. Recovery Point Objective (Objetivo de punto de recuperación) http://en.wikipedia.org/wiki/Recovery_point_objective

5. Recovery Time Objective (Objetivo de tiempo de recuperación) http://en.wikipedia.org/wiki/Recovery_time_objective

6. Recovery Consistency Objective (Objetivo de compatibilidad de recuperación) http://en.wikipedia.org/wiki/Recovery_consistency_objective

7. NIST Definition of Cloud Computing (Definición de la informática de la nube según NIST) http://csrc.nist.gov/publications/nistpubs/800-145/SP800-145.pdf

8. Cloud Native (Aplicaciones nativas de la nube del blog de Paul Fremantle) http://pzf.fremantle.org/2010/05/cloud-native.html

9. ODCA Developing Cloud-Capable Applications White Paper (Notas técnicas sobre el desarrollo de ODCA de aplicaciones compatibles con la nube) http://www.opendatacenteralliance.org/index2.php?option=com_productsearch&view=lightbox&proid=17&ie=UTF-8&oe=UTF-8&q=prettyphoto&iframe=true&width=60%&height=90%

10. Modelo de uso de ODCA: Long Distance Workload Migration (Migración de la carga de trabajo a larga distancia) http://www.opendatacenteralliance.org/docs/Long_Distance_Workload_Migration_Rev1.0_b.pdf

11. The NIST Definition of Cloud Computing (Definición de la informática en la nube de NIST) http://www.nist.gov/itl/cloud/upload/cloud-def-v15.pdf

12. Modelo de uso principal de ODCA: Commercial Framework (Marco comercial) http://www.opendatacenteralliance.org/docs/ODCA_Commercial_Framework_MasterUM_v1.0_Nov2012.pdf

13. Modelo de uso de ODCA: Regulatory Framework (Marco regulatorio) http://www.opendatacenteralliance.org/document-sections/category/71-docs?download=455:regulatory_framework

14. Development Program and Priorities (Programa y prioridades de desarrollo de ODCA) http://www.opendatacenteralliance.org/docs/ODCA_Development%20and%20Program%20Priorities_final.pdf

15. Modelo de uso de ODCA: Standard Units of Measure for IaaS (Unidades de medida estándares para IaaS) http://www.opendatacenteralliance.org/document-sections/category/71-docs?download=458:standard_units_of_measure

16. Modelo de uso de ODCA: VM Interoperability in a Hybrid Cloud Environment (Interoperabilidad de la VM en un entorno de nube híbrido) http://www.opendatacenteralliance.org/docs/ODCA_VMInteroperability_Rev.1.1_Final.pdf

17. Modelo de uso de ODCA: Guide to Interoperability Across Clouds (Guía para lograr la interoperabilidad entre nubes) http://www.opendatacenteralliance.org/docs/ODCA_Interop_Across_Clouds_Guide_Rev1.0.pdf

18. TM Forum’s TR174 Enterprise-Grade External Compute IaaS Requirements (Virtual Private Cloud) [Requisitos de CIaaS externa de grado empresarial (Nube privada virtual); TR174 de TM Forum] http://www.opendatacenteralliance.org/docs/tmforum_tr174enterprisegrade_computeiaasrequirements.pdf

19. Modelo de uso de ODCA: Provider Assurance (Garantía del proveedor) http://www.opendatacenteralliance.org/docs/Security_Provider_Assurance_Rev%201.1_b.pdf

20. “Performance Indicators” (Indicadores de rendimiento) http://en.wikipedia.org/wiki/Performance_indicator

21. Model de uso principal de ODCA: Service Orchestration (Instrumentación de servicio) http://www.opendatacenteralliance.org/docs/ODCA_Service_Orch_MasterUM_v1.0_Nov2012.pdf

22. Cloud Computing: Principles and Paradigms (Informática en la nube: Principios y paradigmas); Buyya, Broberg, Goscinski; John Wiley & Sons; 2011; pág. 130

23. NIST Cloud Specific Terms and Definitions (Términos y definiciones específicos de la nube de NIST) http://collaborate.nist.gov/twiki-cloud-computing/pub/CloudComputing/ReferenceArchitectureTaxonomy/Taxonomy_Terms_and_Definitions_version_1.pdf



http://www.aifb.kit.edu/images/0/02/Cloud_Federation.pdf

http://en.wikipedia.org/wiki/Maintenance_window

http://en.wikipedia.org/wiki/Recovery_point_objective

http://en.wikipedia.org/wiki/Recovery_time_objective

http://en.wikipedia.org/wiki/Recovery_consistency_objective

http://csrc.nist.gov/publications/nistpubs/800-145/SP800-145.pdf

http://csrc.nist.gov/publications/nistpubs/800-145/SP800-145.pdf

http://pzf.fremantle.org/2010/05/cloud-native.html




http://www.nist.gov/itl/cloud/upload/cloud-def-v15.pdf





http://www.opendatacenteralliance.org/docs/ODCA_Development%20and%20Program%20Priorities_final.pdf

http://www.opendatacenteralliance.org/docs/ODCA_Development%20and%20Program%20Priorities_final.pdf








http://en.wikipedia.org/wiki/Performance_indicator



http://collaborate.nist.gov/twiki-cloud-computing/pub/CloudComputing/ReferenceArchitectureTaxonomy/Taxonomy_Terms_and_Definitions_version_1.pdf

http://collaborate.nist.gov/twiki-cloud-computing/pub/CloudComputing/ReferenceArchitectureTaxonomy/Taxonomy_Terms_and_Definitions_version_1.pdf



24. Modelo de ODCA: Service Catalog http://www.opendatacenteralliance.org/document-sections/category/71-docs?download=445:service-catalog

25. Compatible with DMTF’s Open Virtualization Format (OVF) http://dmtf.org/standards/ovf

26. Compatible with SNIA’s Cloud Data Management Interface (CDMI) http://www.snia.org/cdmi

27. Cloud Management for Communications Service Providers http://www.dmtf.org/sites/default/files/standards/documents/DSP2029%20_1.0.0a.pdf

28. Cloudscaling Infrastructure-as-a-Service Builder’s Guide, Network Edition: The Case for Network Virtualization (Guía del desarrollador de la infraestructura como servicio de escala en la nube, Edición de red: El caso de la virtualización de red)

29. There are many options for secure software coding standards, such as https://www.owasp.org, http://www.mcafee.com/us/resources/data-sheets/foundstone/ds-secure-software-dev-life-cycle.pdf, and http://csrc.nist.gov/publications/nistpubs/800-64-Rev2/SP800-64-Revision2.pdf

30. Modelo de uso de ODCA: Cloud Based Identity Provisioning (Aprovisionamiento de identidades basado en la nube) http://www.opendatacenteralliance.org/docs/Cloud_Based_Identity_Provisioning_%20b.pdf

31. Modelo de uso de la nube: Infrastructure as a Service (IaaS) Privileged User Access http://www.opendatacenteralliance.org/docs/Infrastructure_as_a_Service_(Iaas)_Privileged_User_Access_Rev_1.0_b.pdf

32. Como a través de http://trust.salesforce.com

https://www.owasp.org

http://www.mcafee.com/us/resources/data-sheets/foundstone/ds-secure-software-dev-life-cycle.pdf

http://www.mcafee.com/us/resources/data-sheets/foundstone/ds-secure-software-dev-life-cycle.pdf

http://csrc.nist.gov/publications/nistpubs/800-64-Rev2/SP800-64-Revision2.pdf

http://csrc.nist.gov/publications/nistpubs/800-64-Rev2/SP800-64-Revision2.pdf





http://trust.salesforce.com

odca compute iaa_s_masterum_es

Technology

servicio de ciaas

definicin de ciaas

alcance de ciaas

tabla de contenido aviso

modelos de implementacin

infraestructura informtica

marco conceptual

cargas de trabajo