Стандартное руководство по корпоративному управлению: повышение согласованности ресурсов

В этой статье описывается добавление элементов управления согласованностью ресурсов для поддержки критически важных приложений.

Будущие описания

Решения клиентов, инструменты прогнозирования и перенесенная инфраструктура продолжают развиваться. Сейчас бизнес готов начать использовать эти ресурсы в производственных емкостях.

Изменения в текущем состоянии

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

С того времени изменились некоторые факторы, влияющие на систему управления.

  • ИТ-отдел досрочно полностью прекратил использование центра обработки данных аварийного восстановления. В процессе набор ресурсов в рабочем центре данных был идентифицирован как кандидаты на миграцию в облако.
  • Команды по разработке приложений теперь готовы к рабочему трафику.
  • Группа бизнес-аналитики готова к передаче прогнозов и аналитических сведений в операционные системы в рабочем центре обработки данных.

Постепенно улучшайте будущее состояние

Перед началом использования развертываний Azure в производственных бизнес-процессах необходимо завершить работу над облачными операциями. В сочетании с этим необходимо внести дополнительные изменения в систему управления, чтобы обеспечить правильную работу активов.

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

Изменения в материальных рисках

Прерывание бизнеса: Существует важный риск любой новой платформы, вызывающей прерывания критически важных бизнес-процессов. Группа эксплуатации ИТ и команды, выполняемые в различных облачных операциях, относительно неопытны при работе с облаком. Это повышает риск прерывания и должен быть исправлен и регулируется.

Бизнес-риск можно разделить на несколько технических рисков:

  1. В результате внешнего вторжения или атак типа "отказ в обслуживании" бизнес-процессы могут быть прерваны.
  2. Критически важные ресурсы могут быть неправильно обнаружены, поэтому они могут быть некорректно работать.
  3. Необнаруженные или неправильно помеченные ресурсы могут не поддерживаться имеющимися процессами операционного управления.
  4. Конфигурация развернутых ресурсов может не соответствовать ожиданиям производительности.
  5. Журналы могут записываться ненадлежащим образом и сохраняться нецентрализовано, что не позволит устранять проблемы с производительностью.
  6. Политики восстановления могут завершиться ошибкой или выполняться дольше, чем ожидается.
  7. Несогласованные процессы развертывания могут привести к возникновению брешей в системе безопасности с последующими утечками данных и прерываниями работы.
  8. Изменения конфигурации и отсутствие требуемых обновлений могут привести к возникновению брешей в системе безопасности с последующими утечками данных и прерываниями работы.
  9. Конфигурация может не обеспечивать выполнение требований определенных Соглашений об уровне обслуживания или применения восстановления.
  10. Развернутые операционные системы или приложения могут не соответствовать требованиям к укреплению безопасности.
  11. Так как в облаке работает так много команд, существует риск возникновения несогласованности.

Добавочное улучшение операторов политики

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

  1. Все развернутые ресурсы необходимо классифицировать по важности и типу данных. Классификации должны быть проверены командой управления облаком и владельцем приложения перед развертыванием в облаке.
  2. Подсети, содержащие критически важные приложения, должны быть защищены с помощью решения брандмауэра, которое может обнаруживать вторжения и реагировать на атаки.
  3. Средства управления должны проверять требования сетевой конфигурации, определенные командой по управлению безопасностью, и обеспечивать их соблюдение.
  4. Средства управления должны проверять, что все ресурсы, связанные с критически важными приложениями или защищенными данными, включены в мониторинг для оптимизации и наблюдения за истощением ресурсов.
  5. Средства управления должны проверять, что данные журнала соответствующего уровня собираются для всех критически важных приложений или защищенных данных.
  6. Процесс управления должен проверять правильную реализацию резервного копирования, восстановления и соблюдения Соглашения об уровне обслуживания для критически важных приложений и защищенных данных.
  7. Средства управления должны ограничивать развертывания виртуальных машин, разрешая использование только утвержденных образов.
  8. Средства управления должны предотвращать автоматические обновления во всех развернутых ресурсах, поддерживающих критически важные приложения. Нарушения следует рассмотреть с привлечением команд операционного управления и устранить в соответствии с операционными политиками. Ресурсы, которые не обновляются автоматически, необходимо включить в процессы, которые выполняет отдел ИТ-операций.
  9. Средства управления должны проверять теги, относящиеся к классификации затрат, уровню важности, Соглашений об уровне обслуживания, приложений и данных. Все значения должны совпадать с предустановленными значениями, управляемыми командой управления.
  10. Процессы управления предполагают проведение аудита во время развертывания и дальнейших регулярных проверок для обеспечения согласованности всех ресурсов.
  11. Тенденции и уязвимости, которые могут повлиять на облачные развертывания, должны регулярно проверяться командой по обеспечению безопасности для подготовки обновлений средств по управлению безопасностью, используемых в облаке.
  12. Перед выпуском в рабочей среде необходимо добавить все критически важные приложения и защищенные данные в назначенное решение для наблюдения за работоспособностью. Ресурсы, которые невозможно обнаружить в выбранном средстве ИТ-операций, нельзя освобождать для использования в рабочей среде. Чтобы обеспечить возможность обнаружения ресурсов в будущих развертываниях, любые изменения, которые нужны для обеспечения такой возможности, должны быть внесены в соответствующие процессы развертывания.
  13. При обнаружении рабочие группы управления будут масштабировать ресурсы, чтобы обеспечить соответствие активов требованиям к производительности.
  14. Чтобы обеспечить текущее управление развернутыми ресурсами, группа разработчиков Cloud должна утвердить средства развертывания.
  15. Сценарии развертывания должны поддерживаться в центральном репозитории, доступном группе управления облаком для периодической проверки и аудита.
  16. В рамках процессов проверки управления необходимо проверять, чтобы развернутые ресурсы были настроены в соответствии с Соглашением об уровне обслуживания и требованиями к восстановлению.

Поэтапное улучшение методик управления

В этом разделе статьи будет изменен проект MVP по управлению для включения новых политик Azure и реализации службы управления затратами Azure + выставления счетов. Совокупно эти изменения проекта позволят внедрить новые правила корпоративной политики.

  1. Группа облачных операций будет определять средства наблюдения и средства автоматического исправления. Группа управления облаком будет поддерживать эти процессы обнаружения. В этом случае Группа облачных операций выбрала Azure Monitor в качестве основного средства для мониторинга критически важных приложений.
  2. Создайте репозиторий в Azure DevOps для хранения и отслеживания версий всех актуальных шаблонов Resource Manager и конфигураций на основе сценариев.
  3. Реализация хранилища служб восстановления Azure:
    1. Определение и развертывание хранилища служб восстановления Azure для процессов резервного копирования и восстановления.
    2. Создайте шаблон Resource Manager для создания хранилища в каждой подписке.
  4. Обновляйте Политику Azure для всех подписок.
    1. Выполняйте аудит и обеспечение классификации критичности и данных во всех подписках для идентификации любых подписок с критически важными ресурсами.
    2. Выполните аудит использования только утвержденных изображений и примените такую политику.
  5. Реализация Azure Monitor.
    1. После определения критической рабочей нагрузки создайте рабочую область Azure Monitor Log Analytics.
    2. Во время тестирования развертывания группа облачных операций развертывает необходимые агенты и обнаружение тестов.
  6. Обновите Политику Azure для всех подписок с критически важными приложениями.
    1. Выполните аудит использования группы безопасности сети для всех сетевых адаптеров и подсетей и примените такую политику. Сеть и ИТ – безопасность определяют NSG.
    2. Аудит и принудительное использование утвержденных сетевых подсетей и виртуальных сетей для каждого сетевого интерфейса.
    3. Выполните аудит и примените ограничения определяемых пользователем таблиц маршрутизации.
    4. Выполняйте аудит и обеспечивайте развертывание агентов Azure Monitor для всех виртуальных машин.
    5. Аудит и обеспечение того, что хранилища служб восстановления Azure существуют в подписке.
  7. Настройка брандмауэра:
    1. Определите конфигурацию Брандмауэра Azure, которая удовлетворяет требования к безопасности. Или определите совместимое с Azure стороннее устройство.
    2. Создайте шаблон Resource Manager, чтобы развернуть брандмауэр с необходимыми конфигурациями.
  8. Схема Azure.
    1. Создайте схему Azure с именем protected-data.
    2. Добавьте шаблоны "брандмауэр" и "хранилище служб восстановления Azure" в проект.
    3. Добавьте новые политики для подписок, содержащих защищенные данные.
    4. Опубликуйте проект в любой группе управления, в которой будут размещаться критически важные приложения.
    5. Примените новую схему к каждой задействованной подписке так же, как и к имеющимся схемам.

Заключение

Эти дополнительные процессы и изменения в MVP по управлению ресурсами помогают исправлять многие риски, связанные с системой контроля ресурсов. Вместе они добавляют элементы управления восстановлением, масштабированием и мониторингом, которые расширяют возможности облачных операций.

Дальнейшие действия

По мере того как внедрение в облако продолжится и обеспечивает дополнительную ценность для бизнеса, риски и потребности в управлении облаком тоже изменятся. Для вымышленной компании в этом пошаговом окне следующий триггер — когда масштаб развертывания превышает 100 ресурсов в облако или ежемесячные затраты превышают $1 000 в месяц. На этом этапе группа управления облаком добавляет элементы управления затратами.