Готовность к внедрению облака для защиты
Методология готовности — это первый шаг в области платформы внедрения облачных технологий.
Рис. 1. Средство отслеживания доменов — домен платформы
Методология готовности ориентирована на создание облачной платформы. Мы называем эту облачную платформу целевой зоной. Целевые зоны являются домом для основных служб, рабочих нагрузок и приложений. Они обеспечивают основу для управления безопасностью и ресурсами. Они обеспечивают миграцию приложений, модернизацию и инновации в корпоративном масштабе. Целевая зона — это место, где развертываются службы, приложения и рабочие нагрузки. Ниже приведены ключевые рекомендации для сборки целевой зоны, которым должен следовать облачный брокер.
Создание безопасной целевой зоны
В целевой зоне облачный брокер создает среды платформы, а владелец миссии управляет средами рабочей нагрузки. Эти среды рабочей нагрузки наследуют элементы управления безопасностью платформы. Целевые зоны являются основой безопасности рабочей нагрузки и должны быть безопасными. Организации обороны часто имеют стандарты соответствия архитектуры, которые применяются к целевым зонам. Облачный брокер будет отвечать за создание целевой зоны в соответствии с этими стандартами. Сведения о целевых зонах см. в разделе:
Ниже приведено несколько общих рекомендаций по архитектуре для развертываний целевых зон.
Размещение брандмауэра между облаком и сетью защиты . Архитектура должна использовать брандмауэр, систему обнаружения вторжений (IDS) и (или) систему предотвращения вторжений (IPS) для защиты сети защиты от атак, исходящих из облака. Он должен находиться в сети защиты и проверять и фильтровать весь трафик, поступающий в сеть защиты из облака. Такое размещение обеспечит барьер между двумя средами.
Проверять весь входящий трафик . Перенаправляйте весь входящий трафик через стек безопасности перед отправкой в приложения. Стек безопасности должен находиться в собственной среде и проверять и фильтровать трафик перед маршрутизацией в облачные приложения.
Изоляция средств управления безопасностью . Создайте отдельную среду для средств управления безопасностью. Как минимум, среда управления безопасностью должна включать сканирование уязвимостей, сканирование узла, защиту конечных точек и централизованное ведение журнала.
Назначить владельца архитектуры . Владельцы миссии должны назначить одного сотрудника для обеспечения безопасности целевой зоны. Этот человек должен отвечать за координацию работы с облачным брокером, управление удостоверениями и доступом, а также за ограничение повышенных привилегий.
Дополнительные сведения см. в разделе:
Определение ожиданий операций и управления
Владельцы миссии и облачные брокеры должны определить ожидания для операций и управления в течение периода сборки целевой зоны. Рабочие нагрузки будут в значительной степени зависеть от платформы на протяжении всего жизненного цикла. Изменения в удостоверении платформы, управлении или конфигурации подключения повлияют на размещенные рабочие нагрузки. Важно синхронизировать ожидания и приоритеты во время сборки платформы, чтобы владельцы миссии и облачные брокеры имели общее представление об успехе. Наличие прочных рабочих отношений до начала работы рабочих сред поможет снизить риски.
Мы предлагаем следующие рекомендации по операциям и управлению:
Создание каналов связи. Владельцы миссии должны установить каналы связи для использования облачным брокером. Обмен данными должен быть частым, согласованным и четким. Владельцы миссии должны также иметь возможность для связи на местах по любым неотложным вопросам вне регулярных заседаний. Общение позволит свести к минимуму риски и техническое отклонение от целей миссии. Ожидания должны быть записаны, объяснены и доступны облачным брокерам. Регулярная синхронизация между облачным брокером и владельцем миссии поможет обеспечить понимание облачным брокером требований к безопасности, производительности и финансовым требованиям владельцев миссии и их рабочих нагрузок.
Выбор операционных измерений . Определите, как будут рассматриваться оперативные меры. Владелец миссии и облачный брокер должны определить способ получения отзывов и внесения улучшений.
Совместное использование основных служб . Облачный брокер в большинстве экземпляров должен предлагать общие службы для использования владельцами миссии. Общие службы включают Виртуальные рабочие столы Azure для безопасных клиентских вычислений и общий набор инструментов DevOps, например Azure DevOps. Облачные брокеры также могут совместно использовать общую платформу данных с системой управления или общую платформу контейнеров. Совместное использование общих служб экономит деньги и повышает соответствие требованиям.
Обсудите автоматизацию инфраструктуры . Высокопроизводительный облачный брокер будет создавать шаблоны "инфраструктура как код" (IaC) для согласованного и быстрого создания безопасных сред рабочих нагрузок. Эти шаблоны IaC могут создавать защищенные виртуальные машины, функции, хранилище и многое другое. Брокер может даже создать всю целевую зону владельца миссии с помощью кода, чтобы обеспечить согласованность и соответствие.
Создание процесса управления изменениями . Изменения необходимы в облаке. На самом деле основным преимуществом облака является возможность ускорить изменения. Ускорение позитивных изменений является целью цифровой трансформации. Очень важно, чтобы владельцы миссии и облачные брокеры научили процесс управления изменениями. Управление изменениями должно учитывать стандартные, обычные и экстренные запросы на изменение. Каждый тип запроса должен иметь собственный процесс, оптимизированный и оптимизированный для согласованности, скорости и безопасности.
Дополнительные сведения см. в разделе:
Следующий шаг
Методология готовности ориентирована на создание облачной платформы. Методология управления фокусируется на регулировании платформы для обеспечения безопасности, затрат и управления.