Процесс управления доступом

Основные понятия

Доступ – относится к уровню и степени функциональных возможностей услуги или данных, которые пользователь имеет право использовать

Идентичность (Тождественность) – относится к информации о том, как отличить человека, как индивидума, и которая проверяет подлинность его состояния в организации. По определению, Идентичность пользователя уникальна для данного пользователя.

Права – (также называемые привилегии) относятся к фактическим параметрам настройки, посредством чего пользователю предоставляют доступ к услуге или группе услуг.

Типовые права, или уровни доступа, включают:

• чтение,

• запись,

• выполнение,

• изменение,

• удаление

Службы каталогов - относятся к определенному типу инструментария, который используется, чтобы управлять доступом и правами.

Управление доступом (Access Management) – процесс, отвечающий за допуск Пользователей к использованию ИТ-услуг, данных или других Активов.

Управление доступом помогает обеспечить Конфиденциальность, Целостность и Доступность Активов за счет того, что только авторизованные Пользователи имеют возможность получить доступ или модифицировать Активы. Управление доступом иногда упоминается как Управление правами или управление идентификационной информацией.

Цель процесса Управление доступом предоставляет право пользователям, чтобы они были в состоянии использовать услугу или группу услуг.

В этой связи Управление доступом является выполнением политик и действий, определенных в Управлении Безопасностью и Управлении Доступностью.

Действия в рамках процесса:

• Запрос доступа;

• Верификация (проверка подлинности);

• Предоставление прав;

• Мониторинг состояния идентичности;

• Регистрация и отслеживание доступа;

• Удаление или ограничение прав.

Процессы Преобразования Услуг процесс управления изменениями

Основные понятия:

Изменение (Change) – добавление, модификация или удаление чего-нибудь, что имеет влияние на ИТ-услуги.

Область действия изменения должна включать все ИТ-услуги, Конфигурационные единицы, Процессы, Документацию, и т.д.

Различают следующие типы изменений:

• Обычные

• Стандартные

• Срочные

Стандартное Изменение (Standard Change) – предутвержденное Изменение, которое обладает низким Риском, по отношению к обычному, и реализуется в соответствии с определенной Процедурой или Рабочей инструкцией. Например, сброс пароля или предоставление стандартного оборудования новому служащему.

Запрос на изменение не должен использоваться для Стандартного Изменения. Они регистрируются и отслеживаются с использованием различных механизмов, такого, например, как Запрос на обслуживание.

Срочное Изменение (Emergency Change) - Изменение, которое должно быть реализовано как можно скорее. Например, чтобы устранить критический Инцидент.

У Процесса Управления Изменениями должны быть Процедуры для того, чтобы обработать Срочные Изменения.

Изменение услуги (Service change) - добавление, модификация или удаление санкционированной, спланированной или поддерживаемой услуги или компонента услуги и связанной с ней (с ним) документации.

Запрос на Изменение (Request for Change - RFC) - официальное предложение на проведение Изменения.

RFC включает подробности предложенного Изменения, и может быть зарегистрирован на бумаге или в электронном виде.

Комитет по изменениям (Change Advisory Board - CAB) - группа людей, консультирующих Менеджера изменений при выполнении им оценки соответствия, приоритизации и планирования Изменений.

Этот комитет обычно формируется из представителей всех вовлеченных в инициацию и реализацию Изменения сторон – Поставщика ИТ-услуг, Бизнеса и Третьей стороны (заинтересованных сторон), например, Поставщиков

Комитет по срочным изменениям (Emergency Change Advisory Board - ECAB) - группа людей в составе Комитета по изменениям, которые принимают решения по Срочным изменениям.

Необходимость участия в ECAB может быть выявлена непосредственно в ходе совещания и определяется исходя из природы, сути, Срочного изменения.

Модели запросов на изменение (RFC Models) – это маршруты, заранее определяющие шаги по обработке запросов на изменение

Управление изменениями (Change Management) - процесс, отвечающий за контроль Цикла жизни всех Изменений.

Приоритетная задача Управления изменениями - способствовать реализации необходимых Изменений с минимумом нарушений в функционировании предоставляемых ИТ-услуг.

Предназначение процесса Управления Изменениями состоит в том, чтобы гарантировать что:

• Стандартизированные методы и процедуры используются для эффективной и оперативной повторной обработки всех изменений.

• Все изменения в активах услуги и Конфигурационных единицах зарегистрированы в Системе управления конфигурациями (CMS).

• Полный риск для бизнеса оптимизирован.

Предназначение Управления изменениями:

• Отвечать требованиям изменяющегося бизнеса Заказчика, максимизируя ценность и сокращая инциденты, отказы и переделку.

• Отвечать на запросы бизнеса и ИТ об изменении, которое приводит в соответствие услуги с потребностями бизнеса.

Главная цель Управления Изменениями - обеспечение возможности реализации выгодных Изменений с минимальным нарушением предоставления Услуг ИТ.

Цель процесса Управления Изменениями состоит в том, чтобы гарантировать, что изменения зарегистрированы и затем оценены, утверждены, распределены по приоритетам, спланированы, проверены, внедрены, задокументированы и проанализированы управляемым способом.

Общие действия Управления Изменениями включают:

• Планирование и контроль изменений;

• Календарное планирование изменений и релизов;

• Обмен информацией;

• Принятие решения об Изменении и утверждение (санкционирование) Изменения;

• Гарантирование, что есть планы исправления изменений;

• Измерение и контроль;

• Формирование управленческой отчетности;

• Понимание влияния изменения;

• Постоянное улучшение.

Типовые действия по управлению индивидуальными изменениями:

• Создание и регистрация Запроса на изменение (RFC)

• Анализ Запроса на изменение (RFC) и предложение его изменения:

  • Фильтрация изменений (например неполные или неправильно направленные изменения)

• Оценка и оценивание изменения:

  • Установление соответствующего уровня власти (полномочий) для утверждения изменения.

  • Установление соответствующей области интересов (то есть кто должен быть вовлечен в CAB).

  • Оценка и оценивание бизнес обоснования, влияния, стоимости, выгод и риска изменений.

  • Запрос независимой оценки изменения.

• Утверждение изменение:

  • Получение утверждения/отклонения.

  • Информирование об утверждении всех заинтересованных сторон, в особенности инициатора Запроса об Изменении

• Обновления плана

• Координация реализации изменения

• Анализ и закрытие изменения:

  • Сопоставление документации изменения, например отчеты об оценке и базисах

  • Анализ фактического измения и документации на изменение (я)

  • Закрытие документов изменения, когда все действия закончены.

Создание и регистрация Запроса на Изменение

Регистрируемая информация:

• Уникальный номер

• Описание

• КЕ, подлежащие изменению

• Причина (Экономическое обоснование)

• Эффект от внедрения (для бизнеса, технический, финансовый и т.д.)

• Сотрудник, подавший запрос на изменение, и его контактная информация

• Дата и время подачи запроса

• Категория изменения

• Приоритет изменения

• Оценка рисков и план управления рисками

• План возврата в исходное состояние и исправления

• Что потребуется изменить в планах других процессов

• Лицо, принимающее решение по изменению

• Принятое решение и рекомендации

• Утверждающая подпись

• Время и дата утверждения

• Статус

• Запланированное время внедрения.

Анализ Запроса на Изменение

Цель анализа – отфильтровать те Запросы на Изменения, которые:

• Полностью непрактичны.

• Повторяют предыдущие Запросы на изменения, которые были приняты, отклонены или рассматриваются.

• Неполные, например неадекватное описание, без необходимого бюджетного одобрения.

Отфильтрованные Запросы на Изменение возвращаются их Инициаторам с указанием причины возвращения.

Оценка и оценивание изменения

• Семь «R’s» управления изменениями

• Оценка влияния и требуемых ресурсов

• Не бывает изменений без рисков

• Оценивание изменения

• Назначение приоритета.

Семь «R’s» управления изменениями

На следующие вопросы нужно ответить для всех изменений. Без ответов на следующие вопросы не может быть оценено влияние изменения и не будет понятно равновесие рисков и выгод для ИТ-услуги.

1. Кто ПОДАЛ (RAISED) изменение?

2. Какова ПРИЧИНА (REASON) для изменения?

3. Какая ОТДАЧА (RETURN) требуется от изменения?

4. Какие РИСКИ (RISKS) вовлечены в изменение?

5. Какие РЕСУРСЫ (RESOURCES) необходимы для реализации изменения?

6. Кто ОТВЕЧАЕТ (RESPONSIBLE) за сборку, тестирование и реализацию изменения?

7. Каковы ОТНОШЕНИЯ (RELATIONSHIP) между этим изменением и другими изменениями?

Оценка влияния и требуемых ресурсов

Оценку влияния изменений и требуемых ресурсов проводят:

• Комитет по изменениям.

• Комитет по срочным изменениям.

Классификация рисков

Матрица влияния изменений и классификация рисков:

Влияние изменения	Влияние изменения / классификация риска
	Высокое влияние Низкая вероятность Категория риска - 2	Высокое влияние Высокая вероятность Категория риска - 1
	Низкое влияние Низкая вероятность Категория риска - 4	Низкое влияние Высокая вероятность Категория риска - 3
	Вероятность (шанс)

Оценивание изменения

Оценивание изменения на основе его:

• Влияния

• Срочности

• Рисков

• Выгод

• Расходов.

Назначение приоритета

• Назначение приоритета на основе влияния и срочности изменения.

• Учет оценки рисков

• Пример видов приоритетов:

  • Срочное

  • Высокое

  • Среднее

  • Низкое

Утверждение изменения

• Уровень утверждения специфического изменения определяется его типом, размерами или рисками.

• Если возникают споры по утверждению или отклонению изменения, должно быть право обжалования такого решения на более высоком уровне принятия решения.

Модель утверждения изменений

Обновление плана

• Группировка изменений в релиз.

• Изменение графика изменений для выполнения потребностей бизнеса, а не ИТ-подразделения.

• Календарное планирование крупных релизов совместно с бизнесом и заинтересованными сторонами

Координация реализации изменения

• Ответственность за внедрение изменение в соответствии с тем, как оно спланировано.

• Заблаговременная подготовка процедур исправления изменения

• Роль надзора для гарантии тестирования изменений.

Анализ и закрытие изменения

Анализ должен включать любые инциденты, возникшие в результате изменения (если они известны на этом этапе).

Должен быть проведен анализ после внедрения изменения (PIR), чтобы подтвердить, что изменение:

• Достигло своей цели.

• Нет никаких побочных эффектов.

Процесс обработки обычного изменения

Процесс обработки стандартного запроса на изменение

Особенности обработки срочных изменений

• Некоторые подробности срочных изменений могут быть задокументированы ретроспективно.

• Количество предложенных срочных изменений должно быть минимально, потому что они более всего подвержены неудаче.

• Должны быть установлены определенные уровни утверждения срочного изменения, и уровни делегированной власти (полномочий) должны быть четко задокументированы и понятны.

• Распределение утвержденных срочных изменений соответствующей технической группе для сборки.

• Тестирование срочных изменений – обязательно.

• Исправление срочного изменения должно быть предусмотрено.

Взаимосвязи с другими процессами:

• Управление активами услуги и конфигурациями.

• Управление проблемами.

• Управление непрерывностью ИТ-услуг.

• Управление мощностями.

• Управление спросом.