Контроль УЭ

Контроль УЭ

Цель контроля конфигураций - обеспечить запись в CMDB только авторизованных и распознаваемых УЭ по их получении. Процедуры должны защищать целостность данных компании, систем и процессов. Когда обрабатывается Изменение, изменяемые компоненты проходят через некоторое количество спланированных/согласованных состояний. Примеры этих состояний: «зарегистрирован», «пригоден для использования», «инсталлирован», «используется», «снят с эксплуатации», «для устранения», «устранен», «проходит Изменение». Следует ввести процедурный и технический контроль, чтобы сделать неавторизованное Изменение практически невозможным.
Следует управлять Лицензиями и обновлять общее количество лицензий по мере добавления, обновления, вывода из эксплуатации или списания УЭ. Требуются процедуры для обеспечения правильной оплаты всех необходимых лицензий, приостановки проплаты по недействительным лицензиям и правильности соблюдения организацией всех юридических ограничений, связанных с купленным ПО.
Постоянные процессы контроля конфигураций:.
■ регистрация всех новых УЭ и их версий;.
■ обновление записей об УЭ в связи с.
Изменениями статуса УЭ (например, от разработки к тестированию, от тестирования к эксплуатации, из эксплуатации в архив);.
обновлением атрибутов;.
Изменениями во владении или в ролях;.
новыми версиями документации вследствие Изменений, сборок и Релизов;.
контролем лицензий;.
связыванием УЭ с относящимися к нему записями об Инцидентах, Проблемах, Изменениях и Релизах;.
■ обновление RFC: относящиеся к нему УЭ, статус и описание внедрения (см. главу 8, Рисунок 8.3);.
■ обновление и архивирование УЭ и связанных с ними учетных записей во время их удаления/списания;.
■ защита целостности конфигураций;.
■ обновление CMDB после периодического сравнения существующих элементов с теми, которые записаны в CMDB, для обеспечения доступности точной информации.
Регистрация новых УЭ и их версий.
Процесс регистрации начинается с заказа элемента или с заказа разработок: Некоторые организации используют процесс закупок для обеспечения того, что УЭ добавляются тогда, когда они заказываются. Поставщики также могут участвовать в маркировке УЭ до их отправки. Таким образом, заказ и доставка УЭ происходит под контролем Управления конфигурациями.
Все доставки должны быть записаны, и их содержание проверено. См. параграф 7.6.4 (Учет статуса конфигурации) для получения рекомендаций по проверке. Если программное или аппаратное обеспечение не удовлетворяет условиям проверки, необходимо инициировать действия по исправлению ситуации и обновлению атрибутов и данных о лицензиях.
ПО собственной разработки.
При разработке программного обеспечения собственными силами момент «получения» ПО обычно является моментом его готовности к вводу в эксплуатацию. Рекомендуется использовать DSL, где хранятся все УЭ типа ПО и соответствующая документация в их эталонном состоянии с контролем качества. Регистрационные процедуры должны обеспечить ввод в CMDB сведений обо всем авторизованном ПО и сопутствующей документации по УЭ до перевода УЭ из библиотеки разработки в DSL. Статус УЭ должен быть изменен при поступлении в DSL (например, с «планируемого» на «существующий»), В идеале это обновление CMDB будет проводиться автоматически утилитой или средством поддержки, выполняющим перенос в библиотеку. Неавторизованные или испорченные элементы не должны допускаться в DSL.
Для УЭ типа ПО, управление конфигурацией которых выполнялось на этапах разработки с помощью CMDB, вначале потребуется только Изменение статуса, а не повторный ввод. Если для разработки и эксплуатации УЭ используется общая база данных, необходимо применить контроль доступа, чтобы предоставить доступ только соответствующему персоналу - например, персоналу группы разработки необходимо иметь доступ только к УЭ в разработке. Если используется другое средство или база данных, эти УЭ должны быть перенесены в новую CMDB. В идеале эти УЭ не должны повторно вводиться оператором.
Готовые УЭ.
Необходимо спланировать процедуры для готовых УЭ, включая аппаратное обеспечение, коммуникационное оборудование, документацию, пакеты ПО, ПО операционных систем и утилиты. Управление изменениями должно обеспечить правильную регистрацию в CMDB всех новых авторизованных УЭ перед их доставкой и изменение их статуса после доставки, установки, тестирования и приемки. Необходимо проверить авторизацию доставленных УЭ. Процедуры инсталляции не должны начинаться до успешного прохождения такой проверки.
Новые УЭ и версии от сборки до релиза.
Хороший контроль сборки и Релиза обеспечит правильную сборку и распространение обновленных версий программного и аппаратного обеспечения в целевые среды, которые совместимы с Релизом. В ходе Управления конфигурациями и Управления релизами должны вестись записи и создаваться отчеты о версиях программного и аппаратного обеспечения и документации, являющихся результатом процессов сборки и Релиза. Сюда входят:.
■ сведения о целевой среде, в которой будет проходить сборка;.
■ ссылки на мастер-копии всех компонентов сборки и средств сборки;.
■ сведения о среде, в которой будет проходить Релиз;.
■ ссылки и доступ к предыдущим записям о Релизах и конфигурациях.
После успешного прохождения проверок, связанных с контролем качества ПО, это ПО становится авторизованным для приемки и копирования в DSL. Необходимо обеспечить, чтобы ПО не было испорчено или изменено во время процессов копирования и распространения.
Статусы УЭ меняются по мере их перехода от доставки к эксплуатации. В идеале CMDB должна обновляться автоматически, когда изменяется статус УЭ и Релизов. Соответствующая документация, такая как сертификаты о тестировании и лицензии, должна быть помещена в контролируемую библиотеку документов.
Изменения в атрибутах УЭ в CMDB должны быть обновлены вместе с соответствующим RFC, который авторизовал Изменение этого атрибута. Если необходимо скорректировать атрибуты (например, после аудита), необходимо оформить запись об Изменении для отслеживания обновлений атрибутов.
Для многих организаций сложно контролировать Изменения во владении и ролях, особенно там, где есть большая текучесть кадров или используется работа подрядчиков. Процедуры для обновления CMDB в связи с Изменениями во владении важны для обеспечения того, что уведомления о Запросах на Изменение, Инцидентах и Проблемах, связанных с УЭ, будут направлены соответствующему персоналу.
Чтобы обеспечить авторизацию всех элементов ИТ-инфраструктуры процессом Управления изменениями, в CMDB проводится запись всех авторизованных Изменений и улучшений. После того как Изменение внедрено, CMDB должна быть изменена, чтобы показать Изменение в статусах УЭ, которых затронуло Изменение.
Контроль лицензий.
Управление конфигурациями должно подтвердить, что безопасные мастер-копии ПО, документация, данные, лицензии и соглашения о поставках, гарантиях и сопровождении размещены внутри системы Управления конфигурациями или DSL.
Соглашения и условия, связанные с закупкой ПО, могут наложить правовые ограничения на организацию (например, запрет на изготовление неавторизованных копий). Следовательно, независимо от того, кто выполняет внедрение, особенно важно, чтобы в CMDB обновлялись сведения о том, кто хранит копии элементов ПО. Это поможет организации выполнить юридические обязательства, а также поможет аудиторам и Службе Service Desk проверять наличие неавторизованных копий.
Обновление и архивирование записей о конфигурациях, снятых с эксплуатации/списанных УЭ.
Планирование и контроль за удалением и устранением УЭ часто важен по финансовым причинам и причинам, связанным с безопасностью. Должны существовать процедуры для списания оборудования или ПО, чтобы обеспечить правильное списание активов организации и обновление соответствующих учетных записей (например, количество лицензий, количество рабочих станций, поддерживаемых поставщиком). CMDB должна обновляться, а статус УЭ должен отражать последнее состояние в жизненном цикле, т.е. «снят с эксплуатации» или «в архиве».