Acuerdos de niveles de servicios para Cloud Computing, factor crítico de éxito 2

Por Adrián Palma

Si no has leído la primera parte no te la pierdas

En esta segunda entrega trataremos todo lo relacionado con las responsabilidades a tomar en cuenta en la elaboración de un SLA además de los requisitos que se deben tener en cuenta para la elaboración de los SLA y modelos de entrega en la nube y casos de uso.

Requisitos del los SLA

Al evaluar un SLA se deben de tomar en cuenta las siguientes responsabilidades:

1. Seguridad: un cliente debe comprender sus requisitos de seguridad y qué controles son necesarios para cubrir dichos requisitos. Un proveedor debe comprender lo que debe ofrecer al consumidor para permitir los controles  correspondientes.
2. Encripción de datos: los datos deben ser encriptados mientras que se encuentren en movimiento y mientras se encuentran en reposo. Los detalles de los algoritmos de encripción  y las políticas de control de acceso deberían especificarse.
3. Privacidad: las principales preocupaciones relacionadas con la privacidad están relacionadas con los requisitos como la encripción, la conservación y la eliminación de datos. Un SLA debería aclarar cómo el proveedor  aísla los datos y las aplicaciones en un entorno multi-tenant.
4. Conservación y eliminación de datos: ¿cómo comprueba su proveedor que cumple con las leyes para la retención y las políticas de eliminación de datos?
5. Borrado y destrucción de hardware: ídem #4.
6. Cumplimiento regulatorio: Si las regulaciones deben implementarse según el tipo de datos, el proveedor  debe ser capaz de probar que cumple con las mismas.
7. Transparencia: en el caso de datos y aplicaciones críticas, los proveedores deben notificar por adelantado a los clientes cuando no se respetan los términos del SLA. Esto incluye las cuestiones de infraestructura, como las interrupciones y los problemas de performance, además de los incidentes relativos a la seguridad.
8. Certificación: el proveedor debería responsabilizarse por el suministro de la certificación necesaria y por mantenerse al día.
9. Definiciones de performance: ¿Qué significa uptime? ¿Todos los servidores en todos los continentes están disponibles? ¿O sólo uno está disponible? Vale la pena aclarar estas definiciones. (Se sugiere estandarizar la terminología del performance para que esto resulte más sencillo.)
10. Monitoreo: por cuestiones de posibles incumplimientos, quizá desee determinar una organización que actué como un tercero que se haga cargo del monitoreo  que sea neutral para monitorear el desempeño del proveedor.
11. Auditabilidad: dado que el consumidor es responsable por los incumplimientos que ocurrieran y provocaran pérdida de datos o de disponibilidad, es vital que el consumidor pueda auditar los sistemas y procedimientos del proveedor. El SLA debería dejar claro cómo y cuándo tendrán lugar dichas auditorías. Estas pueden ser perjudiciales y costosas para el proveedor.
12. Métricas: estas son algunas de las cosas tangibles que pueden monitorearse cuando suceden y realizar la auditoría después. Las métricas de un SLA deben definirse objetivamente y con claridad. A continuación encontrará una lista de las métricas comunes.
13. Suministro de un SLA legible por máquina: esto puede permitir una selección dinámica y automatizada de un agente nube. En otras palabras, si su SLA requiere que el agente utilice el proveedor más económico posible para algunas tareas pero el más seguro para otras, este tipo de automatización lo hace posible. (Este tipo de servicio no se encuentra fácilmente disponible aún, pero es algo para tener en cuenta al contribuir con el análisis de estandarización del SLA de la nube.
14. Interacción humana: el autoservicio a pedido es una de las características principales de la computación en nube, pero su SLA debería tener en cuenta que cuando usted necesita un ser humano, podrá contar con uno.

Algunas de las métricas de performance comunes (para la observación #12) son las siguientes

• Rendimiento: velocidad de respuesta del sistema.
• Confiabilidad: disponibilidad del sistema.
• Balanceo de la carga: cuando contribuye la elasticidad.
• Durabilidad: probabilidad de perder los datos.
• Elasticidad: cuánto puede crecer un recurso.
• Linealidad: performance del sistema a medida que aumenta la carga.
• Agilidad: rapidez de repuesta del proveedor ante las variaciones de carga.
• Automatización: porcentaje de solicitudes administradas sin intervención humana.
• Tiempos de respuesta del servicio al cliente.

Algunas normas fundamentales sobre la responsabilidad

• La regla de los nueves. Una métrica común relacionada con la responsabilidad es la cantidad de nueves que ofrece un proveedor (por ejemplo, si el servicio está disponible el 99.99999 % del tiempo (cinco nueves) entonces las interrupciones totales del sistema son de unos 5 minutos cada 12 meses). El problema es, ¿Qué es una interrupción? (Puede resultar una situación muy negativa si el proveedor llega a decidir lo que es una interrupción.)

 

• Las capas de las nubes. Muchos ofrecimientos nube están construidos sobre otras ofertas de nube — esto es muy bueno para la flexibilidad y la potencia pero cada proveedor adicional hace que el sistema sea menos confiable. (Como si se estimara cada uno a cinco nueves, entonces el sistema en su conjunto es menor a cinco nueves.)
• Distancia entre su aplicación y sus datos. Nuevamente, a medida que la cantidad de proveedores aumenta, otros factores que pueden afectar la responsabilidad se afirman. No sólo se encuentra usted afectado cuando uno de los sistemas cae, también se ve afectado cuando cae la red entre ellos.

Requisitos y modelos de entrega, casos de uso

A continuación se presentan 2 tablas dos tablas las cuales nos presentan los requisitos del SLA y modelos de entrega en la nube y los requisitos del SLA y los escenarios de los casos de uso:

• Requisitos del SLA y modelos de entrega en la nube. Esta tabla compara los requisitos del SLA que analizamos (encripción de datos, privacidad, certificación, etc.) con los modelos de entrega PaaS, IaaS, y SaaS.

 

• Requisitos del SLA y escenarios de casos de uso.Esta tabla compara los requisitos del SLA con los siete escenarios de casos de uso:
  1. Usuario final con la nube.
  2. Empresa con la nube con el usuario final.
  3. Empresa con la nube.
  4. Empresa con la nube con la empresa.
  5. Nube privada(en las instalaciones del cliente).
  6. Cambio de vendors de la nube.
  7. Nube híbrida.

En conclusion

• La computación en nube no es factible sin administración de servicio, control, medición, monitoreo, SLA y comparaciones, aplicaciones, despliegue, y administración del ciclo de vida.
• La transparencia y la comunicación significativas por parte de los proveedores de la nube es una necesidad.
• Si existe un estándar actual para cumplir con un requisito, los usuarios de la nube deben insistir para que los proveedores lo utilicen; si no, estos deben insistir para que la comunidad desarrolle uno.

Mientras que las organizaciones utilicen servicios en la nube, las responsabilidades de ambos, elcliente y el proveedor, deben establecerse claramente en un acuerdo de nivel de servicio. Un SLA define cómo el cliente utilizará los servicios y cómo el proveedor los entregará. Es fundamental que el consumidor de los servicios comprenda completamente todos los términos del SLA del proveedor, y que el consumidor evalúe las necesidades de su organización antes de firmar cualquier acuerdo.

 

Adrián Palma es licenciado en Informática cuenta con mas de 23 años de experiencia en TI y Seguridad Informática, tiene las certificaciones CISSP,CISA,CISM,CRISC,BSA, conferencista a nivel internacional y catedrático del diplomado de Seguridad en el ITESM, Ex presidente de la ALAPSI Internacional y actualmente director de educación de la misma. adrian.palma@integridata.com.mx