Entrega de servicios de TI

4.4 Entrega de servicios de TI

4.4.1 Gestión de la continuidad y disponibilidad del servicio 6.3 Objetivo: Asegurar que los compromisos de continuidad y disponibilidad acordados con los clientes pueden cumplirse bajo todas las circunstancias. Las especificaciones ISO 20000-1 dicen: Se deben identificar los requisitos de disponibilidad y de continuidad del servicio sobre la base de los planes de negocio, los SLAs y las evaluaciones del riesgo. Los requisitos deben incluir los derechos de acceso y los tiempos de repuesta, así como la disponibilidad extremo a extremo de los componentes del sistema. Los planes de disponibilidad y continuidad del servicio se deben desarrollar y revisar al menos una vez al año, para asegurar que los requisitos cumplen lo acordado bajo todas las circunstancias, desde la normalidad hasta la pérdida grave del servicio. Estos planes se deben mantener para asegurar que reflejan los cambios acordados, requeridos por el negocio. Los planes de disponibilidad y de continuidad del servicio se deben probar de nuevo cuando se produzca un cambio importante en el entorno del negocio. El proceso de gestión de cambios debe evaluar el impacto de cualquier cambio sobre los planes de disponibilidad y continuidad del servicio. La disponibilidad se debe medir y registrar. Se debe investigar la indisponibilidad no planificada y se deben llevar a cabo las acciones necesarias. NOTA: Cuando sea posible, se deben predecir problemas potenciales y tomar medidas preventivas. Los planes de continuidad del servicio, la lista de contactos y la base de datos de gestión de la configuración deben estar disponibles incluso en el caso de que no sea posible el acceso normal a las oficinas. El plan de continuidad del servicio debe incluir la actividad de vuelta a la normalidad. El plan de continuidad del servicio debe aprobarse de acuerdo a las necesidades del negocio. Todas las pruebas de continuidad se deben registrar y tras las pruebas fallidas se deben elaborar planes de acción. El Código de buenas prácticas ISO 20000-2 dice: NOTA: Los desastres o fallos del servicio pueden ocurrir por muchas razones, incluyendo la denegación del servicio, ataques, virus, acceso no permitido a las instalaciones o un desastre natural. Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net Generalidades Los requisitos de continuidad y disponibilidad se deberían identificar sobre la base de las prioridades del negocio del cliente, los acuerdos de nivel de servicio y los riesgos evaluados. El proveedor del servicio debería mantener una capacidad suficiente para el servicio junto con planes fácilmente realizables, diseñados para asegurar que los requisitos acordados pueden ser alcanzados en todas las circunstancias, desde el funcionamiento habitual hasta los casos de caídas graves del servicio. El proveedor del servicio debería planificarse para satisfacer los datos conocidos de incrementos y decrementos de volumen de usuarios, picos o caídas previstos de la demanda y cualquier otro cambio futuro conocido. Los requisitos deberían incluir los derechos de acceso y tiempos de respuesta, así como la disponibilidad de los componentes del sistema. La gestión de la disponibilidad y continuidad del servicio deberían trabajar conjuntamente con el objetivo de asegurar que se mantengan los niveles de servicio acordados. Estos requisitos deberían tener una influencia capital en las acciones, esfuerzos y recursos destinados para satisfacer la disponibilidad de los servicios que los soportan. Los procesos que aseguran que se mantiene la disponibilidad requerida, deberían incluir aquellos elementos de la provisión del servicio que estén bajo el control bien del propio cliente o de otros proveedores del servicio. Actividades y supervisión de la disponibilidad La gestión de la disponibilidad debería: a Supervisar y registrar la disponibilidad del servicio. b Mantener datos históricos precisos. c Realizar comparaciones con los requisitos definidos en los SLAs para identificar no conformidades con los objetivos de disponibilidad acordados. d Documentar y revisar las no conformidades. e Predecir la disponibilidad a futuro. f Cuando sea posible, se deberían predecir los posibles problemas y llevar a cabo las acciones preventivas. Se debería asegurar la disponibilidad de todos los componentes del servicio, registrando y llevando a cabo las acciones correctivas. Estrategia de continuidad del servicio El proveedor del servicio debería desarrollar y mantener una estrategia que defina el enfoque general a seguir para satisfacer las obligaciones de continuidad del servicio. Esta estrategia debería incluir la evaluación de riesgos y tener en cuenta los horarios de servicio acordados y los periodos críticos del negocio. El proveedor del servicio debería acordar lo siguiente con cada grupo de clientes y servicios: a Los periodos máximos aceptables de pérdida continuada del servicio. b Los periodos máximos aceptables de degradación del servicio. c Los niveles aceptables de degradación del servicio durante un periodo de recuperación del servicio. La estrategia de continuidad debería ser revisada con una periodicidad acordada, al menos anualmente. Cualquier cambio a la estrategia debería ser acordado formalmente. Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net Planificación y prueba de la continuidad del servicio El proveedor del servicio debería asegurar que: a Los planes de continuidad tienen en cuenta las dependencias entre el servicio y los componentes de los sistemas. b Se registran y mantienen los planes de continuidad del servicio y el resto de documentos requeridos para dar soporte a la continuidad del servicio. c La responsabilidad para activar los planes de continuidad está claramente asignada y los planes establecen claramente la responsabilidad para la toma de las acciones necesarias frente a cada objetivo. d Las copias de seguridad de los datos, los documentos, el software y cualquier equipo y personal necesario para la restauración del servicio están disponibles de forma rápida ante un desastre o un fallo importante del servicio. e Al menos un copia de todos los documentos relativos a la continuidad del servicio debería estar almacenada y ser mantenida en una localización remota y segura, junto al equipamiento que sea necesario para permitir su uso. f El personal conoce y asume su rol para activar yo ejecutar los planes y tiene acceso a la documentación relativa a la continuidad del servicio. Los planes de continuidad del servicio y la documentación relacionada por ejemplo los contratos deberían estar ligados a los procesos de gestión de cambios y gestión de contratos. Los planes de continuidad del servicio y la documentación relacionada por ejemplo los contratos deberían evaluarse respecto al impacto previamente a que se aprueben los cambios en el sistema y en el servicio, y previamente a acordar los nuevos requisitos del cliente o bien cambios en éstos siempre que sean significativos. Se deberían llevar a cabo pruebas con una frecuencia suficiente, para asegurar que los planes de continuidad son efectivos y permanecen así, aun cuando se producen cambios en los sistemas, procesos, personal y necesidades del negocio. El cliente y el proveedor del servicio deberían estar implicados conjuntamente en las pruebas, basadas en un conjunto acordado de objetivos. Los fallos en las pruebas se deberían documentar y revisar para proveer de información a un plan de mejora del servicio. La Figura 4.4.1 muestra cómo se puede visualizar esta parte de la norma en lenguaje BPM. Los procesos de gestión de la disponibilidad y la continuidad del servicio contienen actividades que garantizan la disponibilidad de los sistemas en todo momento. ISO 20000 contempla un sistema combinado de gestión de la disponibilidad y la continuidad del servicio, pero en la práctica se trata de dos procesos diferentes, aunque estrechamente relacionados. La planificación y las pruebas de la disponibilidad y de la continuidad del servicio se pueden realizar como un solo conjunto de actividades, mientras que las actividades de monitorización y gestión de la disponibilidad y de gestión de la continuidad del servicio se deben ejecutar por separado. Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net Incluyendo: - Derechos de acceso - Tiempos de respuesta - Disponibilidad de extremo a extremo de componentes de sistemas Con: - Datos conocidos de aumentos o descensos del volumen de usuarios - Picos y valles de carga de trabajo - Cualquier otro cambio que se pueda producir en el futuro Deberían tener en cuenta: - Dependencias entre componentes de sistemas y servicios - Asignación de la responsabilidad de invocar planes de continuidad - Asignación de responsabilidades sobre objetivos Disponibles cuando no sea posible el acceso normal de oficina, junto con listas de contactos y la CMDB Debería incluir evaluación de riesgos y tener en cuenta: - Horas de servicio acordadas - Períodos críticos de negocio Al menos una revisión al año Los cambios se deben acordar formalmente Incluyendo factores externos cliente y otros proveedores externos de servicios Con acceso rápido a: - Copias de respaldo de datos, documentos y software - Equipos y personal necesarios para restaurar el servicio en caso de fallo grave Al menos una copia de todos los documentos, junto con los equipos necesarios para su uso Planes de negocio SLAs Evaluaciones de riesgos Planes de disponibilidad y continuidad del servicio Requisitos de disponibilidad y continuidad del servicio Requisitos de disponibilidad y continuidad del servicio Mantener la suficiente capacidad del servicio para cumplir los requisitos Conservar y mantener todos los documentos y equipos de continuidad del servicio en un lugar seguro Garantizar que el personal comprende su rol y tiene acceso a documentos de continuidad del servicio Desarrollar, mantener y revisar una estrategia de continuidad del servicio Identificar requisitos de disponibilidad y continuidad del servicio Desarrollar y mantener planes de disponibilidad y continuidad del servicio Interfaces: Mejora continua Actuar: - Sugerir mejoras para SIP Gestión de cambios: - Presentar solicitudes de cambio - Evaluar el impacto de cualquier cambio sobre el plan de disponibilidad y continuidad del servicio - Controlar todos los cambios introducidos en la documentación de disponibilidad y continuidad del servicio - Vincular la documentación con la gestión de cambios Proceso de gestión de contratos: - Vincular la documentación con la gestión de contratos Proceso de gestión de la configuración: - Permitir el acceso a la CMDB cuando no sea posible el acceso normal de oficina - Programar auditorías de configuración después de un desastre Gestión del nivel de servicio: - Acordar Niveles de Servicio para cada grupo de clientes y servicio - Evaluar el impacto sobre la documentación de continuidad del servicio antes de acordar los requisitos del cliente Informes del servicio: - Recibir información Presupuestos y contabilidad: - Presupuesto y contabilidad de todos los componentes Incluyen el regreso a las condiciones normales de operación Figura 4.4.1 Procesos de gestión de la continuidad y disponibilidad del servicio Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net Los procesos de gestión de la disponibilidad y la continuidad del servicio tienen interfaces con los procesos de gestión de cambios y gestión de la configuración. Para garantizar la continuidad del servicio es preciso que sea posible acceder a la CMDB cuando no sea posible el acceso normal de oficina. El proceso de gestión de cambios evalúa el impacto de cualquier cambio sobre el plan de disponibilidad y continuidad del servicio, además de controlar todos los cambios que se introduzcan en la documentación de disponibilidad y continuidad del servicio. Las interfaces entre los procesos de gestión de la disponibilidad y la continuidad del servicio y los procesos de gestión de cambios y gestión de la configuración deberían estar documentadas Figura 4.4.2. Guía La gestión de la continuidad de los servicios de TI ITSCM forma parte de la gestión de la continuidad del negocio BCM y depende de la información que proporciona el proceso BCM. La disponibilidad de los servicios de TI se garantiza combinando medidas de reducción de riesgos, como instalar sistemas fiables con opciones de recuperación sistemas redundantes y de respaldo. La Figura 4.4.3 muestra las actividades de ITSCM. Para iniciar ITSCM hay que hacer lo siguiente: •฀ Definir la política - Esta política tiene que estar basada en la Política de Continuidad del Negocio y se debería implantar lo antes posible. Es necesario comunicar la política a toda la organización para que todos los afectados sean conscientes de la necesidad de ITSCM. La dirección tiene que demostrar su compromiso. •฀ Definir el alcance y las áreas relevantes - Para seleccionar el planteamiento y los métodos de la evaluación de riesgos y del análisis de impacto en el negocio se utilizan condicionantes de aseguramiento, normas de calidad como la serie ISO 9000, normas de gestión de la seguridad como BS 7799 y principios generales de política de negocio. También se identifica la estructura de gestión apropiada, como responsabilidades asignadas y una estructura de procesos que permita hacer frente a posibles desastres. •฀ Asignar recursos - La creación de un entorno de ITSCM puede exigir una inversión considerable en recursos y personal. También es necesario ofrecer formación para que el personal pueda dar soporte a los requisitos y la estrategia. •฀ Establecer la organización del proyecto - Se recomienda emplear un método formal de gestión de proyectos, como PRINCE2 TM , con el apoyo de software de planificación. Antes de analizar los servicios de TI, es aconsejable identificar los motivos por los que la empresa tiene que incluir la gestión de la continuidad de los servicios de TI en su gestión de la continuidad del negocio, así como el impacto potencial de una interrupción grave de los servicios. En algunos casos el negocio puede sobrevivir durante algún tiempo, por lo que lo más importante es restaurar los servicios; en otros, el negocio no puede funcionar sin servicios de TI y debe hacer hincapié en la prevención. La mayor parte de los negocios intentan encontrar un equilibrio entre ambos extremos. Se realiza un análisis de los servicios de TI que son esenciales para el negocio como sistemas de información, aplicaciones ofimáticas, aplicaciones de contabilidad y correo electrónico y que deben estar disponibles según los acuerdos de nivel de servicio. En el caso de algunos servicios Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net Plan de acción Registros de pruebas de continuidad Registros de disponibilidad Registros de faltas de conformidad Registros de acciones correctivas Al menos una vez al año De acuerdo con las necesidades del negocio Incorporar los fallos de las pruebas en un plan de acción Monitorizar y registrar la disponibilidad Investigar faltas de disponibilidad no planificadas Adoptar las acciones correctivas apropiadas Identificar, documentar y revisar faltas de conformidad con los requisitos de disponibilidad Predecir la disponibilidad futura y posibles problemas Adoptar acciones preventivas Revisar los planes de disponibilidad y continuidad del servicio Probar o volver a probar los planes de disponibilidad y continuidad del servicio Registros de pruebas de continuidad En caso de cambio importante Planes de disponibilidad y continuidad del servicio Registros de disponibilidad Requisitos de SLAs Planes probados de disponibilidad y continuidad del servicio Realizar pruebas de continuidad y registrar los resultados Figura 4.4.2 Procesos de gestión de la continuidad y disponibilidad del servicio: Proceso de disponibilidad Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net que no son esenciales, se puede llegar al acuerdo de proporcionar un servicio de emergencia con capacidad y disponibilidad limitadas. No obstante, los niveles de servicio durante la recuperación ante desastres sólo se pueden modificar de común acuerdo con el cliente. Para servicios críticos se debe buscar un equilibrio entre prevención y opciones de recuperación. A este análisis sigue una evaluación de las dependencias entre servicios y recursos de TI. La información de la gestión de la disponibilidad se utiliza para analizar hasta qué punto los recursos de TI desempeñan una función crítica para el soporte de los servicios de TI discutidos Iniciar BCM Análisis de impacto en el negocio Estrategia de continuidad de los servicios de TI Evaluación de riesgos Implantar acuerdos de respaldo Desarrollar planes de recuperación Aseguramiento Educación y concienciación Gestión de cambios Revisión y auditoría Pruebas Formación Inicio Requisitos y estrategia Implantación Gestión operativa Fase 1 Fase 2 Fase 3 Fase 4 Implantar medidas de reducción de riesgos Organización y planificación de la implantación Desarrollar procedimientos Pruebas iniciales Figura 4.4.3 Modelo del proceso de ITSCM según el modelo BCM de la OGC, actualmente centrado en ITSCM Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net anteriormente. La gestión de la capacidad proporciona información sobre la capacidad necesaria. Es preciso determinar la interrupción máxima que pueden sufrir estos servicios, desde la pérdida inicial de servicio hasta su completa restauración. Esta información se usará posteriormente para identificar las opciones de recuperación para cada servicio. Un análisis de riesgos puede ayudar a identificar los riesgos a los que está expuesto un negocio y ofrece a la dirección información muy importante sobre medidas de prevención. Mantener un plan de recuperación ante desastres puede resultar relativamente costoso, por lo que conviene empezar considerando la posibilidad de usar medidas de prevención. Una vez agotadas dichas medidas, hay que determinar si existen todavía riesgos que puedan exigir un plan de contingencia. La Figura 4.4.4 muestra los vínculos entre el análisis de riesgos y la gestión de riesgos; este ejemplo está basado en el Método de Análisis y Gestión de Riesgos de la antigua Agencia Central de Informática y Telecomunicaciones CCTA, la actual OGC. El modelo consta de cuatro pasos: •฀ En primer lugar hay que identificar los componentes de TI relevantes activos, como edificios, sistemas, datos, etc. Para que esta identificación sea eficaz es preciso documentar el propietario y el propósito de cada componente. •฀ El siguiente paso consiste en analizar las amenazas a que están expuestos los activos y sus dependencias, y estimar la probabilidad alta, media o baja de que se produzca un desastre. Por ejemplo, un sistema de alimentación eléctrica poco fiable en una zona con muchas tormentas se puede considerar una amenaza. •฀ A continuación hay que identificar y clasificar la vulnerabilidad alta, media o baja de los activos. Un pararrayos puede ofrecer cierto grado de protección contra las tormentas eléctricas, pero sigue existiendo la posibilidad de que la red y los sistemas informáticos sufran daños graves. •฀ Finalmente, se evalúan las amenazas y las vulnerabilidades en el contexto de los componentes de TI para obtener una estimación de los niveles de riesgo. Hay que distinguir entre reducción de riesgos prevención, acciones de recuperación de la actividad del negocio y opciones de recuperación de TI. Se pueden adoptar medidas de prevención Análisis de riesgos Gestión de ariesgos Activos Amenazas Vulnerabilidades Contramedidas prevención y recuperación Riesgos Figura 4.4.4 Modelo de evaluación de riesgos de la CCTA Fuente: OGC Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net en función de los resultados del análisis de riesgos, teniendo siempre en cuenta los costes de las medidas y los niveles de los riesgos que se intenta prevenir. Si existen riesgos que no se pueden evitar con medidas de prevención, es necesario eliminarlos mediante una planificación de la recuperación. Para garantizar la continuidad del negocio hay que contar con las siguientes opciones de recuperación: •฀ Personal y alojamiento - Tratamiento de instalaciones alternativas, mobiliario, transporte y distancias de desplazamiento, así como el personal básico para dar soporte al negocio. •฀ Redes y sistemas de TI - Las opciones de recuperación se discuten más abajo. •฀ Servicios de soporte: Electricidad, agua, teléfono, correo y servicios de mensajería. •฀ Archivos - Ficheros, documentos, sistemas basados en papel y materiales de referencia. •฀ Servicios de terceros - Proveedores de servicios de Internet y correo electrónico, por ejemplo. Existen diversas opciones para la recuperación de servicios de TI: •฀ No hacer nada - Hay pocos negocios que puedan funcionar eficazmente con este planteamiento. Pese a ello, se debe explorar esta opción en todos los servicios para ver si puede resultar aceptable, por ejemplo, como solución a corto plazo. •฀ Regreso a un sistema manual basado en papel - Esta opción suele ser inaceptable para servicios que sean críticos para el negocio, ya que no habrá suficiente personal con experiencia en el uso de sistemas tradicionales. Sin embargo, los sistemas basados en papel pueden ser una opción viable para servicios de menor importancia. •฀ Acuerdos recíprocos - Esta opción se puede usar si dos organizaciones tienen hardware similar y acuerdan ofrecerse una a otra sus instalaciones en caso de desastre. Para ello es necesario que los dos negocios alcancen un acuerdo y garanticen la coordinación, de modo que ambos entornos sean intercambiables. La gestión de la capacidad tiene que encargarse de que la capacidad reservada para este fin no se utilice para otras cosas o se pueda liberar rápidamente. Esta opción no resulta tan atractiva en los actuales entornos informáticos distribuidos, donde hay una mayor demanda de sistemas con alta disponibilidad y potencia de procesamiento individual, como cajeros automáticos y banca on-line. •฀ Recuperación gradual respaldo en frío - Esta opción puede ser adecuada para negocios que pueden operar durante algún tiempo 72 horas, por ejemplo sin servicios de TI. Permite disponer de una sala de ordenadores vacía en una instalación fija previamente acordada, o bien de una sala de ordenadores móvil que se traslada hasta la sede del negocio instalación portátil. La sala de ordenadores cuenta con alimentación eléctrica, aire acondicionado, instalaciones de red y conexiones telefónicas. Esta opción de recuperación se puede contratar a un suministrador externo. Es necesario establecer acuerdos independientes con suministradores para garantizar la rápida entrega de componentes de TI. La ventaja de este método es que las instalaciones están siempre disponibles. Los beneficios y los costes son distintos para instalaciones fijas y portátiles. •฀ Recuperación intermedia respaldo en templado - Esta opción permite acceder a un entorno operativo similar, en el que los servicios pueden continuar con normalidad tras un breve período de transición 24-72 horas. Existen tres versiones de esta opción: – Interna reserva mutua: Esta opción proporciona una recuperación completa con un tiempo de transición mínimo. Las organizaciones con varios sistemas distribuidos suelen optar por esta variante del planteamiento, que consiste en que parte de la capacidad necesaria está reservada en cada sistema. La gestión de la capacidad se encarga de monitorizar esta Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net capacidad de reserva de modo similar a lo que ocurre en la opción de recuperación por acuerdos recíprocos. – Externa: Un servicio comercial ofrecido a distintos clientes por organizaciones externas de recuperación. Los costes se dividen entre los clientes y dependen del hardware y el software necesarios y del período de cesión de las instalaciones 16 semanas, por ejemplo. Los acuerdos suelen cubrir el período necesario para preparar las instalaciones de respaldo en frío. Este método resulta relativamente caro y es probable que las instalaciones se encuentren a cierta distancia. – Móvil: Esta opción proporciona una caravana con toda la infraestructura necesaria lista para su uso. La caravana funciona como sala de ordenadores y dispone de sistemas de control de ambiente, como aire acondicionado. Las conexiones de electricidad, datos y telecomunicaciones tienen que estar situadas en puntos especiales a cierta distancia del edificio. Entre las ventajas que ofrece esta opción figuran los rápidos tiempos de respuesta y la proximidad a la sede del negocio. Esta opción sólo se puede utilizar con un número limitado de plataformas hardware. Algunos de los principales suministradores de hardware ofrecen este servicio con varias caravanas equipadas con configuraciones de hardware estándar. La caravana visita el negocio en los momentos acordados una vez al año, por ejemplo para probar los acuerdos de recuperación. •฀ Recuperación inmediata arranque en caliente, respaldo en caliente - Esta opción ofrece una recuperación inmediata o muy rápida de los servicios en menos de 24 horas, por ejemplo. Para conseguirlo se utiliza un entorno de producción idéntico, con replicación de los datos o incluso de los procesos de producción, todo ello en estrecha colaboración con la gestión de la disponibilidad. En la mayor parte de los casos es posible combinar distintas opciones. Por ejemplo, una caravana con un centro informático de operaciones arranque en caliente móvil puede ofrecer una solución temporal hasta que se preparen instalaciones portátiles y se reciban los nuevos ordenadores centrales arranque en frío móvil. La operación normal quedará restaurada cuando se haya vuelto a equipar el edificio y se hayan trasladado a él los nuevos ordenadores centrales. Una vez se ha determinado la estrategia de negocio y se han elegido las opciones necesarias, hay que implantar la ITSCM y desarrollar en detalle los planes para las instalaciones de TI. Es necesario crear una organización para implantar los procesos de ITSCM. Dicha organización puede incluir equipos de gestión gestor de crisis, coordinación y recuperación para cada servicio. Debe existir un plan general del máximo nivel en el que se contemplen los siguientes aspectos: •฀ Plan de respuesta de emergencia •฀ Plan de evaluación de daños •฀ Plan de recuperación •฀ Plan de registros vitales qué hacer con los datos, incluyendo registros en papel •฀ Planes de relaciones públicas y gestión de crisis Todos estos planes se utilizan para evaluar emergencias y responder a ellas. A continuación es posible decidir si se debe iniciar el proceso de recuperación del negocio, en cuyo caso hay que activar los planes del siguiente nivel. Esto incluye: •฀ Plan de servicios y alojamiento •฀ Plan de redes y sistemas informáticos Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net •฀ Plan de telecomunicaciones accesibilidad y enlaces •฀ Plan de seguridad integridad de datos y redes •฀ Plan de personal •฀ Planes administrativos y financieros Junto con la gestión de la disponibilidad, se adoptan medidas de prevención para reducir el impacto de una incidencia. Estas medidas pueden incluir: •฀ Uso de alimentación eléctrica de respaldo y SAIs •฀ Sistemas tolerantes a fallos •฀ Almacenamiento en el exterior y sistemas RAID El arranque también puede incluir acuerdos de respaldo que cubran personal, edificios y telecomunicaciones. Incluso durante el período de contingencia, es posible efectuar un arranque restaurando la situación normal y adquiriendo nuevos componentes de TI. Se pueden cerrar por adelantado acuerdos latentes con los suministradores, de manera que existan pedidos firmados para el suministro de componentes en el momento especificado y al precio acordado. Cuando se produce el desastre, el suministrador puede procesar el pedido sin necesidad de tener que preparar un presupuesto. Estos contratos latentes se tienen que actualizar todos los años para que reflejen los nuevos precios y modelos. En la actualización hay que tener en cuenta las líneas base de gestión de la configuración. Para elaborar acuerdos de respaldo se pueden llevar a cabo las siguientes actividades: •฀ Negociar con terceros el uso de instalaciones de recuperación en el exterior •฀ Mantener y equipar las instalaciones de recuperación •฀ Adquirir e instalar hardware de respaldo contratos latentes •฀ Gestionar contratos latentes Los planes de recuperación deben ser detallados y estar sujetos a un control formal de cambios, identificando todos los procedimientos necesarios para su soporte. Se tienen que comunicar a todos aquéllos que participen en los planes o se vean afectados por ellos. En general, un plan de recuperación contempla cambios en la infraestructura y en los niveles de servicio acordados. Por ejemplo, la migración a una nueva plataforma de gama media puede implicar que, en caso de ser necesaria la recuperación, no exista una unidad equivalente en las instalaciones de respaldo para arranque externo en caliente. Por este motivo, la gestión de la configuración desempeña un rol muy importante en la monitorización de las líneas base de configuración especificadas en el plan de recuperación. El plan de recuperación debe incluir todos los elementos relevantes para la restauración de las actividades de negocio y los servicios de TI, como: •฀ Introducción - Describe la estructura del plan y las instalaciones de recuperación previstas. •฀ Actualización - Discute los acuerdos y procedimientos para el mantenimiento del plan y efectúa un seguimiento de cambios en la infraestructura. •฀ Lista de rutas - Si el plan está dividido en secciones, cada una de las cuales especifica las acciones que debe realizar un grupo específico, la lista de rutas indica qué secciones se deben enviar a qué miembros del personal. •฀ Inicio de recuperación - Describe cuándo y en qué condiciones se activa el plan. Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net •฀ Clasificación de contingencias - Si el plan incluye procedimientos para distintas contingencias, dichos procedimientos tienen que estar descritos aquí en términos de gravedad baja, media o alta, duración día, semana o semanas y daño pequeño, limitado o grave. •฀ Secciones especializadas - El plan debe estar dividido en secciones basadas en los seis grupos o áreas que cubre el plan. Dichas áreas son: – Administración: Cómo y cuándo se activa el plan, qué miembros de la dirección y el personal participan, y dónde se encuentra el centro de control. – Infraestructura de TI: Elementos de hardware, de software y de telecomunicaciones que debe ofrecer el sistema de recuperación, procedimientos de recuperación y contratos latentes para la adquisición de nuevos componentes de TI. – Personal: Personal necesario en las instalaciones de recuperación y, si las instalaciones están lejos del negocio, servicios de transporte y alojamiento. – Seguridad: Instrucciones de protección contra robos, incendios y explosiones en las sedes central y remota, junto con información sobre instalaciones externas de almacenamiento como cámaras y almacenes. – Centros de recuperación: Información sobre contratos, personal con funciones específicas, seguridad y transporte. – Restauración: Procedimientos para restaurar la situación normal en el edificio, por ejemplo, condiciones para la activación de dichos procedimientos y contratos latentes. El plan de recuperación proporciona un marco de trabajo para la elaboración de procedimientos de recuperación. Es fundamental que se desarrollen procedimientos eficaces que todo el mundo pueda seguir para participar en la recuperación. Dichos procedimientos deben contemplar: •฀ La instalación y prueba de hardware y componentes de red. •฀ La restauración de aplicaciones, bases de datos y datos. Estos y otros procedimientos relevantes se deben adjuntar al plan de recuperación. Las pruebas iniciales de los planes, procedimientos y componentes técnicos afectados son un aspecto crítico de ITSCM. Las pruebas se deberían realizar en casos bien definidos y con objetivos y criterios de éxito claros. Se tienen que efectuar nuevas pruebas después de cambios importantes y al menos una vez al año. El departamento de TI es responsable de probar la eficacia de los elementos de TI de los planes y procedimientos. Estas pruebas pueden estar anunciadas o no, pero la participación en ellas de miembros apropiados de la dirección del negocio fomentará el entendimiento mutuo y hará que resulte más fácil conseguir el soporte y el compromiso del negocio. Una formación eficaz del personal de TI y otros departamentos, junto con la concienciación de todo el personal y la organización, son esenciales para cualquier proceso de continuidad de los servicios de TI. Es posible que el personal de TI tenga que formar a otros miembros de los equipos de recuperación del negocio para que estén familiarizados con el proceso y puedan proporcionar soporte durante las operaciones de recuperación. La formación y las pruebas deben incluir las instalaciones de contingencia, tanto internas como externas. Los planes se deberían revisar y verificar periódicamente para comprobar que están actualizados. Esto afecta a todos los aspectos de ITSCM. En el área de TI, esta auditoría se debe realizar siempre Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net que se produzca un cambio significativo en la infraestructura de TI, como la introducción de nuevos sistemas, redes y proveedores de servicios. También se deben realizar auditorías si hay algún cambio en la estrategia de negocio o en la estrategia de TI. Las organizaciones con cambios rápidos y frecuentes pueden implantar un programa periódico para verificar los conceptos de ITSCM. Todos los cambios de planes y estrategia se deben implantar bajo la dirección de la gestión de cambios, que desempeña un rol muy importante para mantener actualizados todos los planes de ITSCM y para analizar el impacto de cualquier cambio sobre el plan de recuperación. El aseguramiento consiste en la verificación de que el proceso procedimientos y documentos y sus entregables tienen la calidad adecuada para satisfacer las necesidades de negocio de la empresa. Los factores críticos de éxito CSFs para la gestión de la continuidad de los servicios de TI son: •฀ Un proceso eficaz de gestión de la configuración •฀ El soporte y compromiso de toda la organización •฀ Herramientas eficaces y actualizadas •฀ Formación específica para todos aquéllos que participen en el proceso •฀ Pruebas periódicas del plan de recuperación Los indicadores clave del proceso KPIs son: •฀ Número de defectos detectados en los planes de recuperación •฀ Pérdida de ingresos debida a un desastre •฀ Coste del proceso En caso de que se produzca un desastre, se deben preparar informes de gestión sobre su causa y efecto, así como sobre el resultado de la gestión. Cualquier punto débil que se detecte tendrá que ser corregido con planes de mejora. Los informes de gestión del proceso ITSCM incluyen también informes de evaluación de pruebas de planes de recuperación, que se utilizan para aseguramiento. El proceso informa igualmente sobre el número de cambios introducidos en los planes de recuperación como resultado de cambios significativos en otros procesos. Es posible que se elaboren también informes sobre nuevas amenazas. Por lo que se refiere a la gestión de la disponibilidad, se deben duplicar los elementos esenciales siempre que sea posible y usar sistemas de detección y corrección de fallos para conseguir altos niveles de disponibilidad. Es frecuente que, en caso de avería, se activen sistemas automáticos de reserva. Pese a ello, también se deben adoptar medidas organizativas que puede proporcionar la gestión de la disponibilidad. La gestión de la disponibilidad puede comenzar tan pronto como el negocio haya definido claramente sus requisitos de disponibilidad para el servicio. Se trata de un proceso continuo que sólo termina cuando se retira un servicio. Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net Las entradas del proceso de gestión de la disponibilidad Figura 4.4.5 son: •฀ Requisitos de disponibilidad del negocio. •฀ Evaluación de impacto para todos los procesos de negocio con soporte de TI. •฀ Requisitos de disponibilidad, fiabilidad y capacidad de mantenimiento para los componentes de TI en la infraestructura. •฀ Datos sobre fallos que afecten a servicios o componentes, generalmente en forma de informes y registros de incidencias y problemas. •฀ Datos de monitorización y configuración de servicios y componentes. •฀ Niveles de servicio alcanzados, en comparación con los niveles de servicio acordados para todos los servicios cubiertos por el SLA. Salidas: •฀ Criterios de diseño de disponibilidad y recuperación para servicios de TI nuevos y modificados. •฀ Tecnología necesaria para obtener la capacidad de recuperación necesaria en la infraestructura, con el fin de reducir o eliminar el impacto de componentes defectuosos de la infraestructura. •฀ Garantías de disponibilidad, fiabilidad y capacidad de mantenimiento de los componentes de la infraestructura necesarios para el servicio de TI. •฀ Informes sobre los niveles alcanzados de disponibilidad, fiabilidad y capacidad de mantenimiento. •฀ Requisitos de monitorización de disponibilidad, fiabilidad y capacidad de mantenimiento. •฀ Un plan de disponibilidad para la mejora proactiva de la infraestructura de TI. •฀ Planes de acción y medidas adoptadas como actividades reactivas después de incumplimientos del SLA. Criterios de diseño de disponibilidad y recuperación Planes de acción Medidas adoptadas después de incumplimientos del SLA Gestión de la disponibilidad Requisitos de disponibilidad del negocio Logros de nivel de servicio Datos de monitorización y configuración Datos de incidencias y problemas Requisitos de disponibilidad, fiabilidad y capacidad de mantenimiento Evaluación de impacto en el negocio Planes de mejora de la disponibilidad Monitorización de la disponibilidad Informes sobre niveles alcanzados de disponibilidad, fiabilidad y capacidad de mantenimiento Objetivos específicos acordados de disponibilidad, fiabilidad y capacidad de mantenimiento Evaluación de riesgos y capacidad de recuperación de la infraestructura de TI Figura 4.4.5 Entradas y salidas de la gestión de la disponibilidad Fuente: OGC Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net La gestión de la disponibilidad incluye una serie de actividades clave de planificación y monitorización: •฀ Planificación: – Determinación de los requisitos de disponibilidad – Diseño para la disponibilidad – Diseño para la capacidad de recuperación – Gestión de aspectos de seguridad – Gestión del mantenimiento – Desarrollo del plan de disponibilidad •฀ Monitorización: – Mediciones e informes Antes de cerrar un SLA hay que determinar los requisitos de disponibilidad, incluyendo tanto nuevos servicios de TI como cambios en los servicios existentes. Es necesario decidir lo antes posible si la organización de TI puede cumplir los requisitos y cómo va a hacerlo. Esta actividad tiene que identificar: •฀ Funciones clave de negocio •฀ Definición acordada de parada de los servicios de TI •฀ Requisitos cuantificables de disponibilidad •฀ Impacto cuantificable de paradas imprevistas en los servicios de TI sobre las funciones de negocio •฀ Horario comercial •฀ Acuerdos sobre ventanas de mantenimiento Definir lo antes posible y con claridad los requisitos de disponibilidad es fundamental para evitar que surjan confusiones y diferencias de interpretación. Los requisitos del cliente se tienen que comparar con lo que se puede ofrecer en la realidad. Si existen diferencias, hay que determinar el correspondiente impacto sobre el coste. Las vulnerabilidades que afecten a los niveles de disponibilidad se deben identificar lo antes posible. De esta forma se evitarán costes excesivos de desarrollo, gastos imprevistos en fases posteriores, Puntos Únicos de Fallo SPOF, cobros de costes adicionales por los suministradores y retrasos en las entregas. Un buen diseño, basado en niveles de disponibilidad apropiados, permitirá cerrar contratos de mantenimiento eficaces con los suministradores. El proceso de diseño utiliza diversas técnicas, como Análisis de Impacto de Fallos de Componente CFIA para identificar SPOFs, Método de Análisis y Gestión de Riesgos de la CCTA CRAMM o cualquier otra técnica de gestión de riesgos, así como técnicas de simulación. Si no es posible alcanzar los niveles de disponibilidad acordados, la mejor opción consiste en determinar si se puede mejorar el diseño. El uso de nuevas tecnologías, otros métodos, una estrategia de entrega distinta, un diseño mejor o diferente y herramientas de desarrollo puede facilitar el cumplimiento de los objetivos. Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net Si los requisitos son especialmente exigentes, se puede considerar la posibilidad de usar otra tecnología de tolerancia a fallos, otros procesos gestión de incidencias, gestión de problemas y gestión de cambios o recursos adicionales de Gestión del Servicio. Los recursos financieros disponibles determinan en gran medida las posibles opciones. Es muy complicado conseguir una total disponibilidad sin interrupciones, por lo que hay que considerar períodos planificados de falta de disponibilidad. Dichos períodos se pueden usar para iniciar acciones preventivas, como actualizaciones de hardware y software. Estas ventanas permiten también la implantación de cambios. Si se interrumpe un servicio de TI, es importante que la incidencia se resuelva de forma rápida y eficaz para recuperar los niveles acordados de disponibilidad. El diseño para recuperación incluye, por ejemplo, un proceso eficaz de gestión de incidencias con procedimientos apropiados de escalado, comunicación, respaldo y recuperación. La seguridad y la fiabilidad mantienen una relación muy estrecha. Un mal diseño de seguridad de la información puede afectar a la disponibilidad del servicio, mientras que un diseño eficaz de seguridad de la información hace que sea más fácil conseguir una alta disponibilidad. En la fase de planificación hay que tener en cuenta las cuestiones de seguridad y analizar su impacto sobre la provisión de servicios. Algunas de las cuestiones clave de seguridad son las siguientes: •฀ Determinar quién tiene autorización para acceder a áreas seguras. •฀ Determinar cuáles son las autorizaciones críticas que se pueden conceder. Las mediciones y los informes son dos actividades importantes de la gestión de la disponibilidad, puesto que forman la base para verificar acuerdos de servicio, resolver problemas y definir propuestas de mejora. La falta de disponibilidad de los servicios se puede reducir tratando de limitar cada una de las fases del ciclo de vida extendido de la incidencia, como se ve en la Figura 4.4.6: •฀ Detecciónregistro - El tiempo desde que se produce una incidencia hasta que se detecta. •฀ Diagnóstico - La fase siguiente, que dura hasta que se realiza un diagnóstico. •฀ Reparación - La fase siguiente, necesaria para realizar reparaciones físicas. •฀ Recuperación - El tiempo necesario para que el sistema vuelva a estar operativo. •฀ Restauración - El tiempo necesario para restaurar totalmente el servicio y ponerlo a disposición del cliente. Los servicios se deben recuperar rápidamente si dejan de estar disponibles para los usuarios. El Tiempo Medio de Restauración del Servicio MTRS es el tiempo necesario para que una función servicio, sistema o componente vuelva a estar operativa después de un fallo. Los análisis de la respuesta MTRS a distintos factores son útiles para mejorar el rendimiento y el diseño de servicios. Es posible reducir el tiempo MTRS gestionando cada uno de sus componentes. Es importante que los informes de disponibilidad estén redactados desde la perspectiva del cliente. Estos informes ofrecen fundamentalmente información sobre la disponibilidad del servicio para funciones esenciales de negocio, servicios de aplicaciones, y la disponibilidad de los Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net datos perspectiva de negocio, en lugar de información sobre la disponibilidad de componentes técnicos de TI. El plan de disponibilidad es uno de los productos más importantes de la gestión de la disponibilidad. No se trata del plan de implantación de la gestión de la disponibilidad, sino de un plan a largo plazo que afecta a la disponibilidad durante un período de varios años. Debe describir la situación actual y posteriormente se puede ampliar para que incluya actividades de mejora de los servicios existentes y directrices, así como planes para nuevos servicios y directrices para mantenimiento. Para que el plan sea preciso y completo es necesario un enlace con áreas como la gestión del nivel de servicio, la gestión de la continuidad de los servicios de TI, la gestión de la capacidad, la gestión financiera y el desarrollo de aplicaciones directamente o a través de la gestión de cambios. Para que sea eficiente, la gestión de la disponibilidad tiene que usar diversas herramientas para las siguientes actividades: •฀ Determinar el tiempo de parada •฀ Registrar información histórica •฀ Generar informes •฀ Realizar análisis estadísticos •฀ Realizar análisis de impactos La gestión de la disponibilidad utiliza información procedente de los registros de gestión de incidencias, la CMDB y la base de datos de gestión de la capacidad. La información puede estar almacenada en una base de datos de gestión de la disponibilidad AMDB. Actualmente existe una gran variedad de métodos y técnicas de gestión de la disponibilidad que facilitan la planificación, la mejora y la elaboración de informes. Por ejemplo: •฀ Análisis de Impacto de Fallos de Componente CFIA - Utiliza una matriz de disponibilidad con los componentes estratégicos y sus roles en cada servicio. Una CMDB eficaz, que defina las relaciones entre servicios y recursos de producción, puede resultar muy útil para desarrollar esta matriz. La Figura 4.4.7 muestra un ejemplo de matriz CFIA. Los elementos de configuración INCIDENCIA INCIDENCIA Detectada Tiempo de detección Tiempo de disponibilidad, tiempo entre fallos Factor de fiabilidad Tiempo entre incidencias del sistema Tiempo de parada, tiempo de restauración del servicio Factor de capacidad de mantenimiento Tiempo de registro Tiempo de diagnóstico Tiempo de reparación Tiempo de recuperación Tiempo de restauración Registrada Diagnosticada Reparada Recuperada Restaurada Figura 4.4.6 El ciclo de vida extendido de la incidencia Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net marcados con una “X” son elementos importantes de la infraestructura de TI análisis horizontal. Los servicios que están frecuentemente marcados con una “X” son complejos y muy sensibles a fallos análisis vertical. Este método también se puede aplicar a dependencias de suministradores externos CFIA avanzado. •฀ Análisis del Árbol de Fallos FTA - Es una técnica que permite identificar la cadena de sucesos que conducen al fallo de un servicio de TI. Para cada servicio se genera un árbol empleando símbolos booleanos. El árbol se recorre desde abajo hacia arriba. El método FTA distingue entre los siguientes sucesos: – Sucesos básicos: Entradas del diagrama círculos, como cortes de electricidad y errores de operarios; estos sucesos no se investigan. – Sucesos resultantes: Nodos del diagrama que resultan de una combinación de sucesos anteriores. – Sucesos condicionales: Sucesos que sólo se producen bajo ciertas condiciones, como un fallo del aire acondicionado. – Sucesos disparadores: Sucesos que causan otros sucesos, como un apagado automático iniciado por un SAI. Los sucesos se pueden combinar mediante operaciones lógicas, como: – Operación AND: El suceso resultante se producirá si se producen todas las entradas simultáneamente. – Operación OR: El suceso resultante se producirá si se producen una o más entradas. – Operación XOR: El suceso resultante se producirá si sólo se produce una de las entradas. – Operación de inhibición: El suceso resultante se producirá si no se cumplen las condiciones de la entrada. •฀ Método de Análisis y Gestión de Riesgos de la CCTA CRAMM - Describe una forma de identificar contramedidas justificables para proteger la confidencialidad, la integridad y la disponibilidad de la infraestructura de TI. •฀ Cálculos de disponibilidad - Las métricas descritas anteriormente se pueden usar para alcanzar con el cliente acuerdos sobre disponibilidad de servicios. Estos acuerdos se incluyen en el acuerdo de nivel de servicio. El porcentaje de disponibilidad se calcula restando el tiempo de parada real al tiempo de servicio acordado, dividiendo el resultado por el tiempo de servicio acordado y multiplicando por 100. •฀ Análisis de Interrupción de Servicios SOA - Es una técnica que permite identificar las causas de fallos para investigar la eficacia de la organización de TI y sus procesos, así como para presentar e implantar propuestas de mejora. Tiene las siguientes características: – Amplio alcance: No se limita a la infraestructura, sino que cubre también procesos, procedimientos y aspectos culturales. – Análisis de problemas desde la perspectiva del cliente. – Implantación conjunta a cargo de representantes del cliente y la organización de TI equipo SOA. Entre sus ventajas figuran un planteamiento más eficiente, la comunicación directa entre el cliente y el suministrador, y una base más amplia para propuestas de mejora. •฀ Puesto de Observación Técnica TOP - Cuando se utiliza el método TOP, un equipo especializado de expertos en TI se concentra en un único aspecto de la disponibilidad. Este método puede ser apropiado cuando las herramientas de rutina no proporcionan suficiente soporte. TOP también permite combinar los conocimientos y experiencias de diseñadores y administradores de sistemas. Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net El aspecto más importante de este método es que se trata de un planteamiento eficaz, eficiente e informal que da resultados rápidamente. Los factores críticos de éxito CSFs para la gestión de la disponibilidad son: •฀ El negocio debe tener objetivos y requisitos de disponibilidad claramente definidos. •฀ La gestión del nivel de servicio debe estar preparada para formalizar acuerdos. •฀ Ambas partes deben tener las mismas definiciones de disponibilidad y parada. •฀ Tanto el negocio como la organización de TI deben ser conscientes de los beneficios que aporta la gestión de la disponibilidad. Elemento de Configuración: Ordenador 1 Ordenador 2 Cable 1 Cable 2 Enchufe 1 Enchufe 2 Segmento de Ethernet Router Enlace WAN Router Segmento NIC Servidor Software de sistema Aplicación Base de datos Servicio A B B X X X X X X A B B B X Servicio B B B B B X X X X X X X A B B B X X = Servicio no disponible en caso de fallo A = Configuración a prueba de fallos B = A prueba de fallos, con tiempo de transición = Ningún impacto Figura 4.4.7 Matriz CFIA Servicio interrumpido OR Inhibición ¿Fuera de las horas de servicio? Sistema interrumpido Red interrumpida AND Ordenador interrumpido Aplicación interrumpida Línea normal interrumpida Línea de respaldo interrumpida Figura 4.4.8 Análisis del Árbol de Fallos Fuente: OGC Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net Los siguientes indicadores clave del proceso KPIs muestran la eficacia y la eficiencia de la gestión de la disponibilidad: •฀ Porcentaje de disponibilidad tiempo de disponibilidad de cada servicio o grupo de usuarios •฀ Duración de paradas •฀ Frecuencia de paradas Los informes de disponibilidad para el cliente ya han sido discutidos anteriormente. Las siguientes métricas se pueden utilizar para controlar el proceso: •฀ Tiempos de detección •฀ Tiempos de respuesta •฀ Tiempos de reparación •฀ Tiempos de recuperación •฀ Uso correcto de métodos apropiados CFIA, CRAMM, SOA •฀ Grado de implantación del proceso: servicios, SLAs y grupos de clientes cubiertos por SLAs Es posible determinar algunas métricas para cada servicio, equipo o dominio de la infraestructura entorno de estaciones de trabajo, centro de cálculo y red. 4.4.2 Gestión de la capacidad 6.5 Objetivo: Asegurar que el proveedor del servicio tiene, en todo momento, la capacidad suficiente para cubrir la demanda acordada, actual y futura, de las necesidades del negocio del cliente. Las especificaciones ISO 20000-1 dicen: La gestión de la capacidad debe elaborar y mantener un plan de capacidad. La gestión de la capacidad debe estar dirigida a las necesidades del negocio y debe incluir: a Los requisitos de capacidad, rendimiento y comportamiento, actuales y previstos. b La identificación de píaos, umbrales y costes para las actualizaciones del servicio. c La evaluación de los efectos sobre la capacidad de actualizaciones anticipadas del servicio, peticiones de cambio, y nuevas tecnologías y técnicas. d La previsión del impacto de cambios externos, por ejemplo cambios legislativos. e Los datos y los procesos para poder realizar análisis predictivos. Se deben identificar métodos, procedimientos y técnicas para la monitorización de la capacidad del servicio, el ajuste del comportamiento y de las prestaciones del servicio y la provisión de la adecuada capacidad. El Código de buenas prácticas ISO 20000-2 dice: Los requisitos actuales y esperados del negocio en relación al servicio se deberían conocer en términos de lo que el negocio va a necesitar para dar servicio a sus clientes. Las previsiones de negocio y las estimaciones de carga de trabajo se deberían traducir a requisitos específicos y quedar documentadas. Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net El resultado de las variaciones en la carga de trabajo o en el entorno debería ser predecible; se deberían recoger y analizar datos actuales e históricos de utilización de componentes y recursos, al nivel adecuado, con el fin de dar soporte al proceso. La gestión de la capacidad debería ser el punto focal de todas las cuestiones de rendimiento y capacidad. El proceso debería ofrecer soporte directo al desarrollo de servicios nuevos y a la modificación de los mismos realizando un dimensionamiento y una modelización de servicios. Se debería generar un plan de capacidad donde se documente el rendimiento real de la infraestructura y los requisitos esperados, con la frecuencia suficiente para tener en cuenta el ritmo de cambios de los servicios y de los volúmenes de servicio, la información de los informes de gestión de cambios y del negocio del cliente. Dicho informe debería elaborarse al menos anualmente. Se deberían documentar las opciones existentes junto con su coste para cumplir con los requisitos del negocio, así como las soluciones recomendadas para conseguir los objetivos de nivel de servicio tal como están definidos en el SLA. Debería existir una buena comprensión de la infraestructura técnica y sus capacidades presentes y las que estén proyectadas. Las principales actividades del proceso de gestión de la capacidad consisten en monitorizar, ajustar y ofrecer capacidad. La Parte 1 de ISO 20000 exige explícitamente métodos, procedimientos y técnicas para ejecutar estas actividades una vez elaborado un plan de capacidad Figura 4.4.9. El Código de buenas prácticas recomienda algunos procesos y documentos adicionales. Guía El coste de TI no se debe tanto a las inversiones en capacidad como a su gestión. Por ejemplo, un aumento excesivo de la capacidad de almacenamiento afectará a las operaciones de copia de respaldo en cinta y hará que se tarde más tiempo en encontrar archivos guardados en la red. Una buena gestión de la capacidad permitiría al proveedor de servicios, por ejemplo, detectar que las 18 iniciativas estratégicas de TI para el año en curso harán que se quede obsoleta la actual solución de copias de respaldo. Con esta información, el gestor de la capacidad puede distribuir el coste de la nueva solución de copias de respaldo entre las 18 iniciativas para que se conozca con exactitud el coste de cada una de ellas. Esta forma de actuar es proactiva. Si, por el contrario, no existe gestión de la capacidad, la organización de TI no reaccionará hasta que se haya superado la ventana para copias de respaldo. En este caso el cliente verá a la organización de TI como una fuente de gasto que “no hace más que pedir dinero”, y todo se deberá a que la organización no ha tenido una actitud proactiva al definir las expectativas y asignar costes por adelantado. La gestión de la capacidad consta de tres subprocesos o niveles de análisis de la capacidad: •฀ Gestión de la capacidad del negocio - Su objetivo es comprender las necesidades presentes y futuras del negocio, para lo cual obtiene información del cliente por ejemplo, de planes estratégicos o de marketing y realiza análisis de tendencias. Este subproceso es eminentemente proactivo. •฀ Gestión de la capacidad del servicio - Su objetivo es determinar y comprender el uso de servicios de TI, ya que para garantizar que se pueden alcanzar y cumplir los acuerdos de Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net Producir y mantener un plan de capacidad Tiene en cuenta las necesidades del negocio e incluye: – Requisitos de rendimiento y capacidad presentes y previstos – Escalas de tiempos, umbrales y costes identificados para actualizaciones de servicios – Evaluación de los efectos de actualizaciones previstas de servicios, solicitudes de cambios, nuevas tecnologías y técnicas sobre la capacidad – Impacto previsto de cambios externos – Datos y procesos que permitan realizar análisis predictivos Analizar datos de utilización Documenta: – Rendimiento presente de la infraestructura y requisitos previstos – Opciones para cumplir los requisitos de negocio, indicando su coste Recomienda soluciones para garantizar el cumplimiento de los objetivos específicos del SLA Tiene en cuenta: – El índice de cambio en los servicios y los volúmenes de servicio – La información incluida en los informes de gestión de cambios – El negocio del cliente Dimensionar y modelar servicios Identificar métodos, procedimientos y técnicas Para monitorizar la capacidad del servicio, ajustar el rendimiento del servicio y ofrecer una capacidad adecuada Traducir predicciones y estimaciones en requisitos Capturar datos de utilización Plan de capacidad Requisitos de capacidad Datos sobre utilización presente y pasada Datos sobre utilización presentey pasada Interfaces: Presupuestos y contabilidad: - Presupuesto y contabilidad de todos los componentes Informes del servicio: - Recibir información Mejora continua Actuar: - Sugerir mejoras para SIP Figura 4.4.9 Gestión de la capacidad Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net servicio apropiados es necesario conocer el rendimiento y los picos de carga. Este subproceso tiene fuertes vínculos con la gestión del nivel de servicio en lo que se refiere a la definición y negociación de acuerdos de servicio. •฀ Gestión de la capacidad de los recursos - Su objetivo es determinar y comprender el uso de los componentes y la infraestructura de TI. Los recursos incluyen, por ejemplo, el ancho de banda de red, la capacidad de procesamiento o la capacidad de disco. Es necesario detectar problemas potenciales lo antes posible para poder gestionar estos recursos de manera eficaz. La organización también se tiene que mantener informada de los avances técnicos. La monitorización activa de tendencias es otra actividad de este subproceso. La Figura 4.4.10 ilustra algunas de las actividades esenciales en esta área. El plan de capacidad describe los requisitos de capacidad presentes y futuros de la infraestructura de TI, así como los cambios previstos en la demanda de servicios de TI, sustitución de componentes obsoletos y avances técnicos. El plan de capacidad define también los cambios necesarios para poder ofrecer los niveles de servicio acordados en los SLAs a un coste razonable, junto con los requisitos futuros de nivel de servicio. Debe incluir: •฀ Expectativas de rendimiento •฀ Puntos de actualización •฀ Coste previsto de las actualizaciones de infraestructura coste de capital, recurrente, operativo y de personal Estas cifras se deben actualizar periódicamente en entornos dinámicos. Figura 4.4.10 Actividades iterativas de la gestión de la capacidad Fuente: OGC CDB Monitorización Análisis Ajuste Implantación mediante gestión de cambios Umbrales de utilización de recursos Informes de excepciones de SLM Informes de excepciones de utilización de recursos Umbrales de SLM Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net Hasta cierto punto, el plan de capacidad es la salida más importante de la gestión de la capacidad. Las salidas incluyen con frecuencia un plan anual que está sincronizado con el presupuesto o los planes financieros, así como planes trimestrales con detalles de los cambios previstos de capacidad. Todo ello da como resultado un conjunto coherente de planes en el que el nivel de detalle aumenta a medida que se aproxima el horizonte de planificación. El modelado es una potente herramienta de gestión de la capacidad que se emplea para prever el comportamiento de la infraestructura. Las herramientas existentes para gestión de la capacidad van desde herramientas de medición y estimación hasta completas herramientas para pruebas y prototipos. Las primeras son baratas y se suelen usar en actividades de rutina, mientras que las últimas sólo se utilizan normalmente en proyectos de implantación a gran escala. Entre ambos extremos se encuentran diversas técnicas que son más precisas que una estimación y más baratas que un modelo piloto completo. Entre estas herramientas figuran, por orden creciente de coste, las siguientes: •฀ Norma general •฀ Proyección lineal análisis de tendencias •฀ Modelado analítico •฀ Simulación •฀ Evaluación de líneas de referencia evaluación comparativa la más precisa •฀ Sistema real El dimensionamiento de aplicaciones se centra en los recursos necesarios para la operación de servicios nuevos o modificados como servicios en desarrollo o en fase de mantenimiento, o bien en los servicios que puede ser necesario adquirir si lo solicita el cliente. Estas predicciones incluyen información sobre los niveles de rendimiento previstos, los recursos necesarios y su coste. Esta disciplina es especialmente importante durante las primeras fases de desarrollo del producto y en puntos clave de proyectos de desarrollo. Para la dirección es muy importante disponer de información clara sobre el hardware necesario, así como sobre otros recursos de TI y los costes previstos en esta fase. También facilita la redacción de SLAs o requisitos de nivel de servicio nuevos o modificados. El dimensionamiento de aplicaciones puede exigir un esfuerzo considerable en entornos grandes o complejos. En primer lugar, la gestión de la capacidad acuerda con los desarrolladores los requisitos de nivel de servicio que deberá satisfacer el servicio. Una vez el servicio ha llegado a la fase de entrega y aceptación, se compara su rendimiento con los objetivos específicos de nivel de servicio para garantizar que se pueden cumplir sin problemas. Una de las salidas del dimensionamiento de aplicaciones es el efecto de variaciones de la carga de trabajo. Esta información se puede usar para predecir cuál será la capacidad necesaria si, por ejemplo, el número de usuarios aumenta un 25. Otra característica de la carga de trabajo es la evolución de los requisitos de capacidad con el tiempo picos por díasemanaaño y crecimiento futuro. Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net El objetivo de la monitorización de componentes de la infraestructura es garantizar el cumplimiento de los niveles de servicio acordados. Entre los recursos que hay que monitorizar figuran, por ejemplo, el uso de CPUs, el uso de discos, el uso de la red y el número de licencias. Los datos de la monitorización se tienen que analizar. Un análisis de tendencias permite predecir el crecimiento futuro y detectar posibles “cuellos de botella”, lo que puede llevar a iniciar proyectos de aumento de la eficiencia o a la adquisición de nuevos componentes de TI. Para analizar actividades es preciso tener un conocimiento completo de la infraestructura en su conjunto, de los procesos de negocio y de las relaciones entre los elementos de gestión de la capacidad del negocio, el servicio y los recursos. El ajuste optimiza sistemas para la carga de trabajo real o prevista, a partir de datos de monitorización debidamente interpretados y analizados. El objetivo de la implantación es introducir capacidad nueva o modificada. Si para ello se necesita un cambio, la implantación incluye también el proceso de gestión de cambios. El objetivo de la gestión de la demanda es influir en la demanda de capacidad. Por ejemplo, si un usuario ejecuta durante el día un informe de SQL mal escrito bloqueando la base de datos y generando una cantidad desmesurada de tráfico en la red, el gestor de la capacidad puede recomendar la creación de un trabajo para ejecutar el informe durante la noche, de manera que el usuario lo tenga sobre su mesa por la mañana. La gestión de la demanda proporciona información importante para la elaboración, monitorización y posible ajuste del plan de capacidad y los SLAs. La gestión de la demanda también puede incluir el uso de cobro diferencial para influir en el comportamiento de clientes y usuarios, controlando la demanda en períodos de mucho uso. La creación y población de la base de datos de gestión de la capacidad CDB consiste en recopilar y actualizar información técnica, información de negocio y cualquier otra información que pueda ser relevante para la gestión de la capacidad. Es posible que no se pueda almacenar toda la información de capacidad en una sola base de datos física. Cada administrador de redes o sistemas informáticos puede elegir el planteamiento que considere más conveniente. En muchos casos, la CDB es en realidad un conjunto de bases de datos que contienen toda la información necesaria sobre capacidad Figura 4.4.11. La calidad del proceso de gestión de la capacidad depende de los siguientes factores críticos de éxito: •฀ Previsiones y expectativas de negocio precisas •฀ Comprensión de la estrategia de TI y precisión de su planificación •฀ Conocimiento de tecnologías presentes y futuras •฀ Cooperación con otros procesos •฀ Capacidad para demostrar un buen control de costes Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net El éxito de la gestión de la capacidad viene determinado por los siguientes indicadores clave del rendimiento: •฀ Predictibilidad de la demanda del cliente - Identificación de tendencias y evolución de la carga de trabajo con el tiempo, y precisión del plan de capacidad. •฀ Tecnología - Opciones para medir el rendimiento de todos los servicios de TI, el ritmo de implantación de nuevas tecnologías y la capacidad para cumplir en todo momento los acuerdos fijados en SLAs, aunque se utilicen tecnologías antiguas. •฀ Coste - Reducción del número de compras precipitadas, reducción de la sobrecapacidad costosa o innecesaria, y elaboración temprana de planes de inversión. •฀ Operaciones - Reducción del número de incidencias debidas a problemas de capacidad o rendimiento, capacidad para satisfacer en todo momento la demanda del cliente, y grado de importancia que se concede al proceso de gestión de la capacidad. Los informes de gestión proporcionados por el proceso de gestión de la capacidad incluyen, por una parte, información de control de procesos en términos de: •฀ Características del plan de capacidad •฀ Recursos utilizados para implantar el proceso •฀ Progreso de las actividades de mejora Por otra parte, incluyen también informes de excepciones sobre aspectos tales como: Discrepancias entre la capacidad real y planificada •฀ Tendencias en las discrepancias •฀ Impacto sobre los niveles de servicio •฀ Aumentodescenso esperado de los niveles de capacidad y uso a corto y largo plazo •฀ Umbrales que, en caso de alcanzarse, pueden requerir la adquisición de capacidad adicional Estos informes de gestión de la planificación y el rendimiento de la capacidad tienen que estar a disposición de todas las partes interesadas negocio, aplicación y organización de TI. Previsiones de negocio Datos de servicios Datos técnicos Datos financieros Datos de utilización CDB Informes de gestión Planes de capacidad Informes atécnicos Figura 4.4.11 Fuentes de información para la CDB Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net 4.4.3 Gestión de la seguridad de la información 6.6 Objetivo: Gestionar la seguridad de la información de manera eficaz para todas las actividades del servicio. Las especificaciones ISO 20000-1 dicen: NOTA: ISOIEC 17799 Tecnologías de la Información. Código de prácticas para la gestión de la seguridad de la información, proporciona una guía para la gestión de la seguridad de la información. La dirección, con la autoridad apropiada, debe aprobar una política de seguridad de la información, que debe comunicarse a todo el personal implicado y, cuando sea adecuado, a los clientes. Unos controles adecuados de seguridad deben ayudar a: a Implantar los requisitos de la política de seguridad de la información. b Gestionar los riesgos asociados al acceso al servicio o a los sistemas. Los controles de seguridad deben estar documentados. La documentación debe describir los riesgos a los que están asociados los controles, la manera de utilizarlos y el mantenimiento de los mismos. El impacto de los cambios sobre los controles se debe evaluar antes de que los cambios sean implementados. Los servicios que impliquen el acceso de organizaciones externas a los sistemas de información y a los servicios, deben estar basados en un acuerdo formal que defina todos los requisitos de seguridad necesarios. Las incidencias de seguridad se deben comunicar y registrar tan pronto como sea posible de acuerdo a los procedimientos de gestión de incidencias.Se deben poner en marcha procedimientos para asegurar que todas las incidencias de seguridad son investigadas, y que se toman medidas al respecto. Se deben poner en marcha mecanismos para poder cuantificar y monitorizar los tipos, volúmenes e impacto de las incidencias y el mal funcionamiento de la seguridad. Las acciones de mejora identificadas durante este proceso se deben registrar y servir como información de entrada al plan de mejora del servicio. El Código de buenas prácticas ISO 20000-2 dice: Generalidades La seguridad de la información es el resultado de un sistema de políticas y procedimientos diseñados para identificar, controlar y proteger la información y cualquier equipamiento empleado junto con el almacenamiento, transmisión y procesamiento de dicha información. Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net El personal del proveedor del servicio con roles de especialista en seguridad de la información debería estar familiarizado con la Norma ISOIEC 17799. Tecnologías de la información. Técnicas de seguridad. Código de prácticas para la gestión de la seguridad de la información. Identificación y clasificación de los activos de información El proveedor del servicio debería: a Mantener un inventario de los activos de información por ejemplo, ordenadores, sistemas de comunicación, documentos y otra información que son necesarios para la provisión del servicio. b Clasificar cada activo de acuerdo con su criticidad para el servicio y el nivel de protección que éste requiera, así como nombrar a un propietario que sea el responsable de proporcionar dicha protección. c La responsabilidad para la protección de los activos debería recaer en el propietario de dichos activos, aunque estos pueden delegar las responsabilidades de la gestión diaria de la seguridad. Prácticas para la evaluación de los riesgos de seguridad La evaluación de los riesgos de seguridad debería: a Ser realizada con una periodicidad acordada. b Ser registrada. c Ser mantenida durante los cambios cambios de las necesidades del negocio, de procesos o de configuraciones. d Ayudar a entender en qué podría impactar uno de los servicios gestionados. e Proveer de información para las decisiones referentes a los tipos de controles a establecer. Riesgos para los activos de información Los riesgos para los activos de información se deberían evaluar en función de: a Su naturaleza por ejemplo: funcionamiento defectuoso del software, errores de operación, fallos de comunicación. b Probabilidad. c Impacto potencial para el negocio. d Experiencias pasadas. Seguridad y disponibilidad de la información Al evaluar los riesgos, se debería prestar atención a los siguientes puntos: a Revelación de información sensible a partes no autorizadas. b Información inexacta, incompleta o inválida por ejemplo: información fraudulenta. c Información que quede inservible para su uso por ejemplo: debido a un corte de energía eléctrica. d Daño físico o destrucción de los equipos necesarios para proveer los servicios. También se deberían tener en cuenta los objetivos de la política de seguridad de la información, las necesidades para satisfacer los requisitos específicos de los clientes respecto a la seguridad por ejemplo: niveles de disponibilidad y los requisitos legales o regulatorios que apliquen. Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net Controles Además de otros controles que puedan ser justificables y aconsejados en esta parte de la Norma ISO IEC 20000 por ejemplo: en la continuidad del servicio, los proveedores del servicio deberían aplicar los siguientes controles como una buena práctica en gestión de la seguridad de la información: a La alta dirección debería definir la política de seguridad de la información, comunicarla a su personal y a sus clientes y asegurarse de que se implanta eficazmente. b Los roles y las responsabilidades para la gestión de la seguridad de la información se deberían definir y asignar a un puesto de trabajo. c Un representante del equipo de dirección el rol puede ser desempeñado por un propietario que sea un responsable sénior debería supervisar y mantener la eficacia de la Política de Seguridad de la Información. d El personal que ejerza un rol significativo en seguridad debería recibir formación en seguridad de la información. e Todo el personal debe ser concienciado acerca de la política de seguridad de la información. f Debería haber apoyo de expertos en la evaluación de riesgos y en la implantación de los controles. g Los cambios no deberían comprometer la operación efectiva de los controles. h Se debería hacer un informe de las incidencias de seguridad de la información siguiendo los procedimientos de gestión de incidencias y, también, se debería iniciar una respuesta a dichas incidencias. Documentos y registros Los registros se deberían analizar periódicamente para proporcionar información a la dirección en cuanto a: a Eficacia de la política de seguridad de la información. b Las tendencias que aparezcan en las incidencias de seguridad de la información. c Dar entrada de información a un plan de mejora del servicio. d Tener bajo control el acceso a la información, los activos y los sistemas. La gestión de la seguridad de la información debería estar documentada de una manera fiable. El Código de buenas prácticas para la gestión de la seguridad de la información ISOIEC 17799 ofrece una guía sobre el proceso en la Subsección 6.6 de la norma para la provisión de servicios de TI de calidad. Como consecuencia, la Parte 2 de ISO 20000 especifica que el personal del proveedor de servicios con roles especializados en la seguridad de la información debe estar familiarizado con ISOIEC 17799. ISO 20000 requiere explícitamente una política de seguridad de la información, así como controles de seguridad documentados, registros de incidencias de seguridad y registros de acciones de mejora. Los procedimientos que se exigen explícitamente para la gestión de la seguridad de la información son procedimientos para investigar incidencias de seguridad y emprender las acciones pertinentes Figuras 4.4.12 y 4.4.13. La gestión de la seguridad de la información tiene interfaces con los procesos de gestión de cambios, gestión de incidencias, gestión de la configuración y mejora continua. Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net Incluyen: – Implantación de los requisitos de la política de seguridad de la información – Gestión de los riesgos asociados con el acceso al servicio o a los sistemas Describen: – Los riesgos asociados a los controles – La forma de operación y mantenimiento de los controles Política de seguridad de la información Requisitos de seguridad en SLA Llegar a un acuerdo sobre el acceso de organizaciones externas Definir la política de seguridad de la información Documentar el ISMS Definir y asignar roles y responsabilidades Designar al propietario responsable de proteger los activos de información Aprobar la política de seguridad de la información Comunicar la política al personal afectado y a los clientes Documentar controles de seguridad Controles de seguridad Acuerdos sobre acceso externo ISMS Política de seguridad de la información Roles y responsabilidades asignados Política de seguridad de la información Interfaces: Gestión de problemas: – Intercambiar información de gestión sobre tendencias en incidencias de seguridad de la información – Debería investigar las incidencias de seguridad Proceso de gestión de incidencias: – Comunicar y registrar incidencias de seguridad según el procedimiento de gestión de incidencias – Investigar y gestionar todas las incidencias de seguridad – Monitorizar y cuantificar el tipo, volumen e impacto de las incidencias de seguridad Presupuestos y contabilidad: – Presupuesto y contabilidad de todos los componentes Informes del servicio: – Recibir información Gestión de cambios: – Valorar el impacto de los cambios sobre los controles de seguridad antes de implantar los cambios – Realizar evaluaciones de riesgos para la seguridad durante la introducción de cambios – Evitar que los cambios reduzcan la eficacia de los controles – Emitir solicitudes de cambio Gestión de la configuración: – Identificar y clasificar activos de información – Mantener un inventario de activos de información Mejora continua Actuar: – Sugerir mejoras para SIP – Proporcionar información de gestión sobre tendencias en incidencias de seguridad de la información Figura 4.4.12 Gestión de la seguridad de la información Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net Registros de evaluación de riesgos de seguridad Maintain risk assessment during changes Incluyen el impacto sobre servicios gestionados Los riesgos para activos de información se tienen que evaluar en función de: – Su naturaleza – Su probabilidad – El impacto potencial sobre el negocio – La experiencia previa Con especial atención a: – Divulgación de información a personas no autorizadas – Información inexacta, incompleta o no válida – Información que no se pueda utilizar – Daños físicos de los equipos necesarios Teniendo en cuenta: – Objetivos de la política – Cumplimiento de los requisitos de los clientes – Aplicación de normativas y requisitos legales Debe ser posible recurrir a ayuda experta Analizar registros para informar a la dirección Acerca de: – Eficacia de la política de seguridad de la información – Tendencias detectadas en incidencias de seguridad de la información – Entrada para un plan de mejora del servicio – Control sobre el acceso a información, activos y sistemas Monitorizar y mantener la eficacia de la política de seguridad de la información A intervalos acordados Concienciar al personal e implantar eficazmente la política de seguridad de la información Adquirir conocimientos de ISOIEC 17799 El personal de seguridad debe estar familiarizado con ISOIEC 17799 Formar al personal con roles de seguridad significativos Mantener un inventario de activos de información Clasificar activos por su importancia y nivel de protección Efectuar una evaluación de riesgos de seguridad Política de seguridad de la información Figura 4.4.13 Gestión de la seguridad de la información cont. Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net Guía Las organizaciones y sus sistemas de información no dejan de cambiar, lo que obliga a revisar continuamente las actividades de gestión de la seguridad para garantizar su eficacia. La gestión de la seguridad es un ciclo infinito con fases sucesivas de Planificar, Hacer, Verificar y Actuar, como muestra la Figura 4.4.14. Los requisitos del cliente aparecen en la parte superior derecha como entradas del proceso. La sección sobre seguridad del acuerdo de nivel de servicio SLA define estos requisitos en términos de los servicios de seguridad y del nivel de seguridad exigido. El proveedor de servicios comunica estos acuerdos a la organización mediante un plan de seguridad que define normas de seguridad o acuerdos de nivel operativo. Posteriormente se implanta este plan, se evalúa la implantación y se procede a actualizar el plan y su implantación. La gestión del nivel de servicio informa al cliente sobre estas actividades. De esta forma, el cliente y el proveedor de servicios forman un proceso cíclico completo: el cliente puede modificar los requisitos en función de los informes, mientras que el proveedor de servicios puede ajustar el plan o su implementación según estas observaciones o bien tratar de modificar los acuerdos definidos en el SLA. El proveedor de servicios de TI implanta los requisitos de seguridad del SLA PLANIFICAR: Acuerdos de Nivel de Servicio Contratos de Soporte Acuerdos de Nivel Operativo Políticas internas IMPLANTAR: Aumento de la concienciación Clasificación y gestión de recursos Seguridad del personal Seguridad física Gestión de la seguridad de hardware, redes, aplicaciones, etc. Control de accesos Resolución de incidencias de seguridad CONTROLAR: ¡Organizar Creación del marco de gestión Asignación de responsabilidades EVALUAR: Auditorías internas Auditorías externas Autoevaluaciones Incidencias de seguridad MANTENER: Aprendizaje Mejora Planificación Implantación El cliente define los requisitos de negocio Informes Según SLA Capítulo de seguridadAcuerdo de Nivel de Servicio Acuerdo entre cliente y proveedor Figura 4.4.14 El proceso de gestión de la seguridad Fuente: OGC Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net La actividad de control que aparece en el centro de la Figura 4.4.14 es el primer subproceso de la gestión de la seguridad y está relacionada con la organización y la gestión del proceso. Esto incluye el marco de gestión de la seguridad de la información, que describe los subprocesos: •฀ Definición de planes de seguridad •฀ Implantación de planes de seguridad •฀ Evaluación de los planes de seguridad implantados •฀ Incorporación de la evaluación a los planes anuales de seguridad planes de acción También se tienen en cuenta los informes proporcionados al cliente a través de la gestión del nivel de servicio. Esta actividad define los subprocesos, las funciones de seguridad y los roles y responsabilidades. También describe la estructura organizativa, los acuerdos de presentación de informes y la línea de control quién enseña a quién, quién hace qué, cómo se informa de la implantación. Las siguientes medidas descritas en el Código de buenas prácticas de ISOIEC 17799 se implantan con esta actividad: •฀ Política – Desarrollo e implantación de políticas, conexiones con otras políticas – Objetivos, principios generales y significación – Descripción de los subprocesos – Asignación de funciones y responsabilidades para subprocesos – Conexiones con otros procesos de ISO 20000 y con su gestión – Responsabilidad general del personal – Tratamiento de incidencias de seguridad •฀ Organización de la seguridad de la información – Marco de gestión – Estructura de gestión estructura organizativa – Asignación más detallada de responsabilidades – Creación de un comité de vigilancia de la seguridad de la información – Coordinación de la seguridad de la información – Determinación de herramientas para análisis de riesgos y concienciación, por ejemplo – Descripción del proceso de autorización para instalaciones de TI previa consulta al cliente – Asesoría especializada – Cooperación entre organizaciones, comunicaciones internas y externas – Auditoría independiente de sistemas de información – Principios de seguridad para acceso de terceros – Seguridad de la información en contratos con terceros El subproceso de planificación incluye la definición de la sección sobre seguridad en el SLA en colaboración con la gestión del nivel de servicio, así como las actividades relacionadas con la seguridad en los contratos de soporte. Los objetivos definidos en términos generales en el SLA se detallan ahora para especificarlos en forma de un acuerdo de nivel operativo. Este OLA se puede considerar como el plan de seguridad para una unidad organizativa del proveedor de servicios o como un plan de seguridad específico por ejemplo, para cada plataforma de TI, aplicación y red. El subproceso de planificación también recibe información procedente de los principios de la política del proveedor de servicios del subproceso de control, como “cada usuario debe tener Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net una identificación exclusiva” o “todos los usuarios recibirán en todo momento un nivel básico de seguridad”. Los acuerdos de nivel operativo para seguridad de la información planes de seguridad específicos se elaboran e implantan siguiendo los procedimientos normales. Esto significa que las actividades que se deban ejecutar en otros procesos se tendrán que coordinar con esos procesos. La gestión de cambios utiliza información procedente de la gestión de la seguridad para introducir los cambios necesarios en la infraestructura de TI. El subproceso de planificación se discute con la gestión del nivel de servicio para definir, actualizar y cumplir la sección sobre seguridad en el SLA. El SLA tiene que definir los requisitos de seguridad, utilizando términos medibles siempre que sea posible. La sección sobre seguridad en el acuerdo debe garantizar que se puede verificar el cumplimiento de todas las normas y los requisitos del cliente sobre seguridad. El objetivo del subproceso de implantación es implantar todas las medidas especificadas en los planes. Para facilitar este subproceso se puede utilizar la siguiente lista de comprobación. •฀ Clasificación y gestión de recursos de TI – Información para el mantenimiento de los CIs en la CMDB – Clasificación de los recursos de TI según las directrices acordadas •฀ Seguridad del personal – Tareas y responsabilidades en descripciones de puestos de trabajo – Filtrado – Acuerdos de confidencialidad para el personal – Formación – Directrices para el personal sobre tratamiento de incidencias y puntos débiles detectados en la seguridad – Medidas disciplinarias – Concienciación sobre seguridad •฀ Gestión de la seguridad – Implantación de responsabilidades y separación de puestos de trabajo – Instrucciones de operación por escrito – Normas internas – La seguridad debe cubrir todo el ciclo de vida; tiene que haber directrices de seguridad para desarrollo de sistemas, pruebas, aceptación, operaciones, mantenimiento y retirada – Separación de los entornos de desarrollo y pruebas del entorno de producción – Procedimientos para el tratamiento de incidencias por la gestión de incidencias – Implantación de instalaciones de recuperación – Información para gestión de cambios – Implantación de medidas de protección contra virus – Implantación de medidas de gestión para ordenadores, aplicaciones, redes y servicios de red – Tratamiento y seguridad de soportes de datos •฀ Control de accesos – Implantación de la política de accesos y control de accesos – Mantenimiento de los privilegios de acceso de usuarios y aplicaciones a redes, servicios de red, ordenadores y aplicaciones – Mantenimiento de barreras de seguridad en redes firewalls, servicios de conexión telefónica, puentes y routers Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net – Implantación de medidas para la identificación y autenticación de sistemas informáticos, estaciones de trabajo y ordenadores personales en la red Se necesita una evaluación independiente para valorar el rendimiento, así como para clientes y terceros. Los resultados pueden servir para actualizar e implantar las medidas acordadas con los clientes. La evaluación puede llevar a la adopción de cambios, en cuyo caso hay que definir y presentar una RFC para el proceso de gestión de cambios. Existen tres formas de evaluación: •฀ Autoevaluaciones - Implantadas fundamentalmente por la organización de línea de los procesos. •฀ Auditorías internas - Realizadas por auditores internos de TI. •฀ Auditorías externas - Realizadas por auditores externos de TI. A diferencia de lo que ocurre en las autoevaluaciones, las auditorías no pueden ser realizadas por el mismo personal que participa en los otros subprocesos. De esta forma se garantiza la separación de responsabilidades. Un departamento interno de auditoría se puede encargar de realizar las auditorías. Las evaluaciones también pueden tener lugar en respuesta a incidencias de seguridad. Las actividades principales son: •฀ Verificar la conformidad con la política de seguridad y la implantación de los planes de seguridad. •฀ Realizar auditorías de seguridad en sistemas de TI. •฀ Identificar el uso inadecuado de recursos de TI y actuar en consecuencia. •฀ Encargarse de los aspectos de seguridad de otras auditorías de TI. La seguridad requiere mantenimiento, ya que los riesgos pueden variar debido a cambios en la infraestructura de TI, la organización y los procesos de negocio. El mantenimiento de seguridad incluye el mantenimiento de la sección sobre seguridad en el SLA, así como el mantenimiento de los planes detallados de seguridad acuerdos de nivel operativo. El mantenimiento se efectúa en función de los resultados del subproceso de evaluación y de una valoración de los cambios en los riesgos. Estas propuestas se pueden introducir en el subproceso de planificación o bien en el mantenimiento del SLA en su conjunto. El resultado en ambos casos puede ser la inclusión de actividades en el plan anual de seguridad. Todos los cambios están sometidos al proceso normal de gestión de cambios. Los informes no son un subproceso, sino una salida de los otros subprocesos. Se elaboran para proporcionar información acerca del rendimiento conseguido en materia de seguridad y para informar a los clientes sobre asuntos de seguridad. La presentación de estos informes suele ser uno de los requisitos del acuerdo con el cliente. Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net Los siguientes son algunos ejemplos de informes programados y de los sucesos que pueden incluir: •฀ El subproceso de planificación – Informa sobre el grado de conformidad con el SLA y los KPIs acordados para seguridad. – Informa sobre los contratos de soporte y cualquier problema asociado con ellos. – Informa sobre acuerdos de nivel operativo planes de seguridad internos y los principios de seguridad del propio proveedor en la línea base, por ejemplo. – Informa sobre planes anuales de seguridad y planes de acción. •฀ El subproceso de implantación – Informa sobre el estado de implantación del proceso de seguridad de la información. – Presenta una lista de incidencias de seguridad y de respuestas a esas incidencias, incluyendo opcionalmente una comparación con el período del informe anterior. – Identifica tendencias en incidencias. – Informa sobre el estado del programa de concienciación. •฀ El subproceso de evaluación – Informa sobre el rendimiento de los subprocesos. – Informa sobre el resultado de auditorías, revisiones y evaluaciones internas. – Informa sobre avisos e identificación de nuevas amenazas. Para informar sobre incidencias de seguridad definidas en el SLA, el proveedor de servicios debe tener un canal directo de comunicación con un representante del cliente el responsable de seguridad de la información corporativa, por ejemplo a través del gestor de nivel de servicio, el gestor de incidencias o el gestor de seguridad. También se tiene que definir un procedimiento de comunicación en circunstancias especiales. Salvo en circunstancias especiales, los informes se transmiten a través de la gestión del nivel de servicio. Los factores críticos de éxito son: •฀ Participación del usuario en el desarrollo del proceso. •฀ Responsabilidades claras y separadas. Los indicadores del rendimiento de la gestión de la seguridad son los mismos que los que se discutieron en la Sección 4.3.1 para la gestión del nivel de servicio, ya que se refieren a los asuntos de seguridad cubiertos por el SLA.

4.5 Soporte de servicios de TI