Servicios en la nube. Servicio (1)

+

Como adelantamos en un post anterior, la nube, (viene para quedarse) tiene un marco referencial dentro de IT como servicio. Ahora prosigo con temas de arquitectura fundamentales para poder hacer proyectos centrados.

Continuar leyendo “Servicios en la nube. Servicio (1)”

Anuncios

Autenticación en SharePoint 2013. Mi aproximación

 

Vamos hacer un repaso por la autenticación en MOSS13 para poder planificar su alcance, en cada caso.

Introducción

MOSS13 se basa en la creación de Aplicaciones Web. Esto significa un sitio web en el IIS como unidad lógica.

Cómo se ve en el esquema, para crear una Colección de sitios web en MOSS13, necesitamos crear un sitio web en el IIS, enlazarlo a un grupo de Aplicaciones, nuevo y propio, o compartido.

Ese sitio web del IIS tendrá un nombre de dominio único y una base de datos de contenido dedicado.

Tanto al configurar el  IIS como la Base de Datos (SQL Server) tendremos que asociar una cuenta o método de autenticación de MOSS ante el IIS y ante SQL.

Métodos de autenticación

Al crear un sitio web tenemos que contemplar un método de autenticación.

Los métodos de autenticación, lo que hacen, es validar la identidad que nos presenta el usuario. Esa validación se hace ante un proveedor de identidades. Por ejemplo, un AD (Directorio Activo)  o base de datos (SQL).

Esos métodos de autenticación hacer un intercambio de credenciales que afirman una identidad. Nos dice quién es, si es que lo es.

Planificación de la autenticación.

Así que tenemos que establecer los métodos que usaremos para autenticarnos ante una aplicación web de MOSS. La planificación de esa autenticación tiene que pasar por tres elementos:

En primer lugar, el tipo de autenticación, definir que ha de presentar el usuario y que métodos van a transportar hasta el proveedor de identidades, ya sea para una zona o una aplicación web. Para ello, una vez que definimos cada área de seguridad, tenemos que planificar la infraestructura que soportará esa autenticación.

SharePoint 2010

Un caso especial es la planificación es la migración entre MOSS 2010 y 2013. MOSS 2013 tiene, por diseño, el método de notificaciones.

Autenticación: notificaciones

Lo tradicional

Nos movemos en un entorno Windows. Eso significa que estamos en un entorno de AD (Directorio Activo). Presentamos un usuario y password. Dentro de ese entorno, esa seguridad está garantizada. El Directorio Activo decide quién es quién, y qué puede hacer en los activos securizados por el Directorio.

Pero esto no “sale” ente proveedores de identidad de terceros, o en la nube.

 

Notificaciones

Las notificaciones, un conjunto de notificaciones, es un conjunto de elementos específicos de datos del usuario, los que se decidan. Ese conjunto de notificaciones se unifican en un token que se firma digitalmente. Ese token y esa firma digital lo realiza un proveedor de notificaciones.

Esto se basa, en Microsoft, en WIF, Windows Indentity Foundation, que es un conjunto de clases de .Net Framework. Podemos encontrar la autenticación de usuario, de servidor a servidor o de aplicación.

MOSS13 convierte cualquier método de autenticación en notificaciones. Cuentas de usuario, formularios (SAML) o Windows  en tokens. No se puede pasar al modo clásico, sin notificaciones, si no es por medio de PowerShell.

(Las migraciones de MOSS 2010 conservan el método clásico de autenticación y es recomendable el realizar una migración posterior)

 

 

Recorrido de las notificaciones

El comportamiento de MOSS 13 en las notificaciones contra un AD:

 

 

notificaciones

 

Las notificaciones son compatibles con las peticiones de autenticación NTL, Kerberos o básica de Windows, además de los de formularios o SML.

Y eso lo veremos en el siguiente post

Entidades dentro de la computación en nube

En un post anterior sobre los fundamentos de la computación en nube, pusimos las bases para el desarrollo posterior del modelo.

Para este modelo tenemos 3 tipos de entidades. Estos son subdominios, componentes y relaciones.

Los procesos (en verde). Aunque parezca que estamos relacionando, directamente, procesos de ITIL con la nube, lo que hacemos es relacionar procesos operativos IT o requisitos del servicio, o ambos. En cada organización aparecerá de forma diferenciada la concreción. Lo que si tenemos son dos procesos claros. Entrega del servicio y Operaciones del servicio, que son los dos subdominios.

Las capacidades técnicas. (en azul). Son las combinaciones de hardware o software, o ambas, que proveen de la funcionalidad esperada. Los cuatro subdominios de Software, Plataforma, Infraestructura, Soporte y Gestión.

Entrega del servicio

Nos ayudan a traducir los requisitos de los consumidores de la nube y para que el proveedor gestione la entrega durante todo el ciclo de vida del servicio. Este subdominio contiene componentes que representan:

Niveles de servicio que tienen que ser concretados cuando:

1. Se diseñan las capacidades técnicas cuando el proveedor posee o gestiona las capacidades técnicas que permiten el servicio.ç

2. La evaluación de los servicios prestados por el proveedores externo que posee o gestiona las capacidades técnicas que permiten el servicio.

Es de vital importancia el poder realizar una definición y concreción de los requerimientos del servicio en la nube para asegurar la satisfacción del cliente (valor: utilidad + garantía).

En este subdominio nos podemos encontrar las siguientes secciones:

Gestión de las Relaciones con el Negocio (BRM. itil v3)

Este componente representa lo siguiente:

  • La comunicación constante con los consumidores para determinar si se deben añadir nuevos servicios o si los servicios existentes se deben cambiar o retirar . La lista de servicios disponibles para los consumidores se mantiene en un Catálogo de servicios , que se discutirá más adelante en la sección del componente Portal del Consumidor y Proveedor de este artículo.
  • Los requisitos funcionales y de nivel de servicio para los servicios . Los requisitos de nivel de servicio están representadas en detalle por otros componentes dentro del Subdominio de la Entrega del Servicio.
  • Definición y medición de objetivos de nivel de satisfacción del cliente.
  • La planificación de cómo se cumplirán los requisitos funcionales y de nivel de servicio y los niveles de satisfacción del cliente . El plan incluye requisitos claramente definidos y procesos consistentemente aplicados a partir de la entrega de servicios y subdominios Operaciones del servicio, y, a menudo se basa principalmente en el componente del Service Reporting para supervisar el cumplimiento de los requisitos de nivel de servicio . El Componente Relación con el Negocio tiene una estrecha relación con la Gestión del Ciclo de Vida del Servicio y el componente de Gestión de Nivel de Servicio .

Gestión de la Capacidad (CM, itil v3)

Es un proceso en un equilibrio constante entre las necesidades y el ahorro de coste, presente y futuro. Y tiene que representar:

• Los requisitos de capacidad que el servicio debe cumplir en forma diaria, semanal , mensual y anualmente. Tanto en los picos como en las medias que se deben especificar para cada intervalo. Los requisitos de capacidad también deben llamar a horas especificas del pico como de fin de mes , días festivos o requisitos de capacidad a fin de año .
• El plan de cómo son los requisitos que deben cumplirse. El plan define cómo se escalan las capacidades técnicas que permiten el servicio para satisfacer la capacidad, si las capacidades son propiedad y están manejados por la organización o por un proveedor externo o ambos. El plan se aplica al proceso de Request Fulfillment de la organización y depende de los componentes de Fabric Management y de los componentes Deployment y Provisioning para provisionar la nueva capacidad .

Gestión de la Disponibilidad y Continuidad (itil v3, dos procesos)

  • Este componente representa lo siguiente :
    El nivel de disponibilidad que el servicio  tiene que tener después de que se da para su uso por los consumidores. Esto a menudo se expresa en el porcentaje de tiempo que el servicio está disponible durante algún período de tiempo. El nivel de disponibilidad debe especificar si se incluye el tiempo de inactividad planificado. El proveedor de servicio puede definir aún más el requisito de “durante ciertas horas o días” , o “en condiciones normales”.
  • El plan de cómo son los requisitos que deben cumplirse. Al definir el nivel de disponibilidad que el servicio pueda cumplir y qué costo , el proveedor de servicios suele evaluar su capacidad para proporcionar:
    • Disponibilidad: Este es generalmente considerado como el nivel de disponibilidad del servicio en condiciones normales e incluye el tiempo de inactividad que se espera de fallas normales, como un fallo de un servidor.
    • Continuidad: Esto es generalmente considerado como el nivel de disponibilidad del servicio en condiciones anormales o de desastre , e incluye el tiempo de inactividad que se espera de los fallos anormales, como un fallo de centro de datos completamente.

El costo de proporcionar los niveles de servicio , tanto en condiciones normales y anormales de fallo puede variar enormemente. El proveedor generalmente itera su diseño para llegar a un requisito de disponibilidad final que logre el equilibrio adecuado entre lo que los consumidores  desean de nivel de disponibilidad y lo que están dispuestos a pagar por ese nivel de disponibilidad . Para cumplir con los requisitos de disponibilidad y continuidad de un servicio, el plan puede utilizar las capacidades técnicas y gestión de la organización o lo que ofrece un proveedor externo o ambos.

El CSFRM recomienda que las métricas de disponibilidad y planes de disponibilidad y continuidad se definan para cada servicio que se proporciona en una organización. Estos planes están separados, pero relacionados con el BCP.

Gestión de Seguridad de la Información

Este componente representa lo siguiente :

  • La confidencialidad, la integridad y los requisitos de disponibilidad de los datos que es procesado por el servicio (CIA). Mientras que cada servicio puede tener requisitos particulares, es en general un conjunto estándar de todos los requisitos que se utilizan en toda la organización sobre la Seguridad o Plan Director de Seguridad.
  • El plan ha de contemplar cómo estos requisitos se quieren alcanzar a través de la Gestión de acceso, Autenticación, Autorización y Componentes de Protección de Datos.

Política Regulatoria y de Gestión de Cumplimiento

Este componente representa lo siguiente:

  • Los requisitos de cumplimiento normativo del servicio. Los requisitos específicos de cumplimiento varían entre los países y los sectores, y se pueden aplicar a todos los servicios de una organización, a servicios específicos en una organización, o datos específicos en los servicios individuales.

Ejemplos de políticas de regulación que podrían influir en el diseño o la selección de un servicio público son Portabilidad de seguro de salud y Accountability Act ( HIPAA) , Industria de Tarjetas de Pago ( PCI ) , la ley Sarbanes -Oxley (SOX ), la Directiva Europea 95/46/CE , Convergencia internacional de medidas y Normas de capital (Basilea II) , la Ley de Protección de Datos de 1998 , y otros.

La planificación de cómo estos requisitos se quieren alcanzar a través de la administración de acceso , autorización , autenticación , protección de datos , y los componentes de Reporting Services.

Gestión Financiera

Este componente representa lo siguiente:

Las definiciones de los costos de prestar el servicio y lo que los consumidores pagan por el servicio. El costo de proporcionar el servicio no se puede definir sin incorporar el costo de cumplir con los requisitos de los siguientes componentes:

  • Gestión de la Capacidad
  • Disponibilidad y Continuidad Gestión
  • Gestión de Seguridad de la Información
  • Gestión Normativa y Cumplimiento

El plan de cómo estos requisitos se deben cumplir. El proveedor de servicios debe evaluar continuamente sus costos para prestar el servicio y ajustar el coste del servicio a los consumidores, según corresponda. Un objetivo clave para la mayoría de los proveedores de servicios es reducir al mínimo el costo de la entrega de un servicio a sus consumidores. El  componente de Usage and Billing es un elemento clave para la recuperación de los costos de prestar el servicio, mientras que los procesos Service Operations prestados de forma eficiente y el componente de Process Automation son herramientas clave para disminuir el costo de la prestación de un servicio.

Gestión del Nivel de Servicio

Este componente representa lo siguiente:

  • Requisitos para muchos de los procesos que se definen en los componentes del subdominio de Operaciones del servicio en este artículo .
  • Requisitos para muchas de las capacidades técnicas que se definen en los componentes de subdominio de Management and Support en este artículo .
  • El plan de cómo estos requisitos se deben cumplir. Si bien los procesos y requisitos de capacidad técnica pueden diferir entre los servicios, por lo general, no difieren de manera espectacular, porque la mayoría de las organizaciones definen un estándar, y luego tratar de adherirse a é lo más posible .

Este componente es un factor clave para la satisfacción del cliente y los resultados en el acuerdo de nivel de servicio ( SLA ), que se genera a partir de los resultados de muchos de los componentes de este subdominio. Este componente tiene una estrecha relación tanto al componente de Gestión de Relación con el negocios (BRM) y todos los componentes de las Operaciones de servicio.

Lifecycle Service Management

Este componente representa los procesos del ciclo de vida de cada servicio desde la definición de los requisitos a través del diseño e implementación, las operaciones con los componentes de las Operaciones de servicio, y la eventual retirada del servicio. Este componente tiene una estrecha relación tanto al componente de Gestión de Relación con el Negocio y todos los componentes de las Operaciones de servicio.

En el siguiente artículo seguiremos viendo lo que aplica a las Operaciones del Servicio.

Los ahorros ocultos de la nube

Sólo una nota sobre el tema. Mis post siguen el orden de las cuestiones que la vida profesional me plantea y, ese caos aparente, no lo es tanto. Con los tags se podrá, al final, seguir el hijo conductor. Paciencia.

Los costes ocultos de la nube ya lo hemos tratado en otro post para contraponerlos a los ahorros evidentes, que también los tratamos. Ahora me parece interesante hacer valer una consideración que no he visto comentada como tal. Los ahorros ocultos. Se expresan de manera más o menos cuando se dice que hay un gran ahorro en la administración y que ahorramos en personas. Perfecto. Lo que no se evidencia, y ese es cambio de modelo, son dos cosas:

1. Todas las herramientas de administración, seguridad, monitorización, continuidad, disponibilidad, etc. desaparecen.

2. Las inversiones necesarias para realizar un sato tecnológico se concentran en sólo tener claras las necesidades y como volver atrás.

Son ahorros bestiales.

La pregunta es ¿cómo cambia el sector entero de modelo de negocio? Dímelo tú, dirán. Y ese es el estudio que más nos interesa. La palanca será “servicios”.

Vuelvo a las tareas más acuciantes.