Acuerdos de Niveles de Servicios: factor crítico de éxito en la nube 1

Por Adrián Palma

1ª de 2 partes.

 

En este artículo abordaré uno de los temas más apremiantes y menos tocados alrededor del modelo de cómputo en la nube: lo relacionado con los acuerdos de niveles de servicio, casos de uso  y posibles repercusiones que tiene la protección de datos personales bajo esta nueva modalidad de IT.

Los acuerdos de niveles de servicio (SLA, por sus siglas en inglés) son un factor crítico de éxito para la contratación de servicios proporcionados por un tercero, por lo mismo son la base para la entrega de servicios de cloud computing.

Un SLA se define como: “ Un documento que contractualmente contiene las cláusulas obligatorias que documentan el funcionamiento estándar y el acuerdo de calidad de servicio por el cliente y por el proveedor de servicios”. El propósito primario de los SLA es especificar y clarificar las expectativas del funcionamiento, establecer la responsabilidad, y detallar los remedios y consecuencias si el funcionamiento o la calidad del servicio de los estándares  no son los acordados por ambas partes.

• El SLA es un acuerdo entre el cliente y el proveedor que cuantifica el servicio aceptable del  nivel de servicio mínimo y aceptable desde la perspectiva del cliente.
• El SLA es probablemente el documento más importante en una relación de  cliente/proveedor.
• Un SLA, cuando está propiamente escrito, es distinguido por ser claro, con un lenguaje simple y con un enfoque a las necesidades y a lo que el cliente  requiere.
• El SLA debe ser de mutuo acuerdo por parte de los proveedores y de los clientes para poder solventar cualquier diferencia entre ambos.
• El SLA define los roles del cliente y del proveedor.
• Como resultado, el cliente debe entender exactamente qué es lo que ellos esperan hacer y qué es lo que el proveedor está de acuerdo en hacer en el nombre del cliente.
• El SLA debe ser tan  preciso como sea posible.

Para el caso específico de los SLA en la nube estos deberán contener:

• La lista de servicios que proporciona el proveedor y una definición completa de cada servicio.
• Las métricas para determinar si el proveedor está suministrando los servicios tal como lo prometió y un mecanismo de auditoría para monitorear el servicio.
• Las responsabilidades del proveedor, el consumidor y los recursos disponibles para ambos si los términos de los SLA no se cumplen.
• Una descripción de cómo el SLA se modificará a través del tiempo.

Básicamente hay 2 tipos de SLA para el cómputo en la nube. El primero son los SLA listos para la venta y el segundo son los SLA personalizados. Recomiendo que los clientes que procesen tanto datos sensitivos como críticos revisen detalladamente dichos SLA porque lo más seguro es que no  estarán en cumplimiento de todos sus requerimientos y expectativas. De modo que antes de ir a la nube es necesario primero determinar cuán sensitivos y críticos son los datos, aplicaciones e infraestructura tecnológica que se piensa montar en un esquema de Cloud.

Por ejemplo, las nubes públicas a menudo ofrecen SLA no negociables  que pueden ser en la mayoría de los casos  no aceptables para quienes poseen aplicaciones o datos sensitivos o críticos.

Un concepto de suma importancia y relevancia es el de los Services Level Objectives ( OLS, por sus siglas en inglés) que definen las condiciones objetivamente medibles para el servicio. Algunos ejemplos son los parámetros de rendimiento, la frecuencia y la sincronización de la corriente de datos ( Streaming de datos ), los porcentajes de disponibilidad para máquinas virtuales y otros recursos y las instancias o valoraciones de las urgencias para clasificar la importancia de los diferentes OLS (como “la disponibilidad es más importante que el tiempo de respuesta”).

Otro punto importante a tomar en cuenta es que lo que se espera de los OLS debería variar según los datos y las aplicaciones a los que tienen acceso las aplicaciones que están hospedadas en la misma nube o en nubes diferentes.

Del mismo modo, para que los SLA y los OLS funcionen de manera adecuada, estén actualizados, sean monitoreados y realmente medibles es necesario tener un proceso de Service Level Management (SLM), el cual se basará en la forma de reunir y administrar la información de performance en la nube. Dicha información servirá para que:

• El proveedor de la nube utilice el SLM para tomar decisiones relacionadas con su infraestructura. Por ejemplo, si el performance no siempre cumple con los requisitos del cliente, el proveedor puede reubicar el ancho de banda o agregar más hardware o, en su defecto, satisfacer a un cliente a expensas de otro. Para los proveedores el SLM ha sido diseñado para ayudar a tomar las mejores decisiones con base a los objetivos de la organización y las realidades técnicas.
• El cliente de la nube utiliza el SLM para decidir cómo desea usar los servicios de la nube; por ejemplo, si agregar o no más máquinas virtuales y a qué precio se determinará que esa opción es demasiado cara como para justificar los beneficios que conllevan. Para los clientes, el SLM los ayuda a tomar decisiones en el modo en el que utilizarán la nube.

Factores a considerar en los SLA.

1. Los objetivos del negocio: una organización debe definir porqué utilizará los servicios de la nube antes de definir exactamente cuáles usará. Esta parte está más relacionada con cuestiones del negocio que del área técnica: algunas funciones podrían tener recortes de presupuesto o perder el control de su infraestructura por la contratación de los servicios de la nube.
2. Las responsabilidades de ambas partes: es importante definir el balance de las responsabilidades entre el proveedor y el cliente. Por ejemplo, el proveedor será responsable por los aspectos de Software-as-a-Service (Software como Servicio), pero el consumidor puede generalmente ser responsable por su VM, la cual contiene software registrado y contiene datos sensitivos.
3. Continuidad del Negocio/Recuperación de Desastres: el cliente asegura que el proveedor tiene una protección contra desastres adecuada. Dos ejemplos me vienen a la mente: el almacenamiento de datos valiosos en la nube como backup y cloud bursting (se intercambian cuando los centros de datos internos no pueden encargarse del procesamiento de las cargas).
4. Redundancia: evaluar qué tan redundante es la infraestructura del proveedor.
5. Mantenimiento: uno de los aspectos más agradables del uso de la nube es que el proveedor es responsable de la administración del mantenimiento de la infraestructura. Pero cuando los proveedores realizan las tareas de mantenimiento, los consumidores deberían estar preocupados porque:

• ¿Los servicios no estarán disponibles durante este tiempo?
• ¿Estarán disponibles los servicios pero el performance será mucho menor?
• ¿El cliente tendrá la oportunidad de comparar sus aplicaciones con el servicio actualizado?

1. Ubicación de los datos: existen regulaciones con ciertos tipos de datos que sólo pueden almacenarse en ubicaciones físicas determinadas. Los proveedores pueden responder a esos requisitos con la garantía de que los datos del cliente serán almacenados solamente en ciertas ubicaciones y con la posibilidad de ser auditados.
2. Embargo de datos: si por cumplimiento de la ley se embarga el equipo de un proveedor para capturar los datos y las aplicaciones que pertenecen a un cliente en particular, dicho embargo probablemente afecte a otros clientes que utilicen al mismo proveedor. Hay que evaluar la posibilidad de que una tercera parte más proporcione backup adicional.
3. Fallas del proveedor: hay que tener planes de contingencia tomen en cuenta la situación financiera de los proveedores.
4. Jurisdicción: de nuevo, hay que conocer y entender las leyes que se aplican a un proveedor, al igual que comprender las leyes que se aplican al cliente.

10.  Intermediarios y Revendedores: si el proveedor es un intermediario  o un revendedor de servicios de la nube, debe comprender las políticas de su proveedor y al actual proveedor.

Continuará………….

 

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