нет и никогда не будет. а это имеет значение?
сугубо с точки зрения проведения всех этих задач.
где оно будет фиксироваться не так важно, можно хоть спец.рассылку сделать для ИТ-отдела.
общая методика change request примерно такая:
- фиксировать общую причину изменений(плановое, экстренный security fix и т.п.)
- все изменения должны тестироваться(на 1 выделенной единице, но по возможности - на "лабораторном стенде")
- для всех изменений должна быть написана чёткая процедура отката в предыдущее состояние(бекап конфигов и т.п.) до начала работ. в случае со сторонним ПО - обязательное чтение мануалов по обновлению от вендора.
- порядок обновления после тестирования
- периодичность проверки обновлений ОС или стороннего ПО.
Я эту проблему решила тупо написанием политики управления изменениями, кусок про обновления выглядит примерно так(в твоем случае видимо потребует сильного изменения, т.к. это написано с учётом требований одного узкопрофильного ИБ-стандарта)
1. Общие положения
1.1. Настоящая Политика регламентирует процесс внесения изменений в любые технические ресурсные единицы информационно-вычислительной сети (ИВС) Компании.
1.2. Требования настоящей Политики распространяются на всех сотрудников Технической дирекции Компании.
1.3. Ответственность за исполнение требований данной Политики возлагается на Группу системного администрирования.
1.4. Целью данной Политики является формализация процесса внесения изменений в конфигурации серверов, рабочих станций, межсетевых экранов, сетевого оборудования и технологических продуктов Компании.
1.5. Нарушение данной Политики может привести к нарушению хода производственных и технологических процессов Компании, компрометации ИВС Компании, материальному и репутационному ущербу для Компании.
2. Общие требования для всех процедур изменений
2.1. Для любого изменения должна быть описана процедура восстановления исходного состояния системы.
2.2. Перед любым изменением должно быть проведено тестирование, подтверждающее отсутствие негативных изменений в общем уровне безопасности ИВС.
2.3. Перед любым изменением программного обеспечения должно быть проведено исследование (чтение специализированных рассылок вендоров, поиск информации об уязвимостях на специализированных ресурсах) на отсутствие уязвимостей после обновления компонента.
3. Установка обновлений операционных систем и прикладного программного обеспечения серверов, рабочих станций, сетевого оборудования.
Запрос на обновление осуществляется сотрудником Группы системного администрирования путём регистрации задачи(issue) в системе управления проектами в проекте «Системное администрирование».
Обязательные параметры задачи:
• Tracker: Change request
• Subject: краткое описание задачи
• Description: подробное описание задачи. Должно включать в себя: имя хоста, тип обновления (ОС, ПО, фирменное ПО сетевого оборудования), причина обновления (плановое, экстренное, тестирование функционала), предполагаемого исполнителя, предполагаемую дату исполнения.
3.2. Задача передается на проверку Руководителю группы Информационной Безопасности (ИБ). После проверки и, при необходимости, уточняющих вопросов, Руководитель группы ИБ передаёт задачу предполагаемому исполнителю или отклоняет запрос.
3.3. В случае одобрения изменений, исполнитель реализует изменения, зафиксированные в задаче в соответствии с утвержденным списком изменений, фиксирует в задаче системное время начала и окончания внесения изменений и переводит задачу в статус закрытой.
