Организация для внедрения облака защиты
Методология организации относится к командной области внедрения облака.
Рис. 1. Средство отслеживания домена — командный домен
Одной из самых больших проблем внедрения облака в оборонной организации является не технология, а организация групп, команд и ролей для поддержки технологии. Традиционные ИТ-операции отличаются от облачных операций. Традиционная модель является централизованной, а центральный центр создает и поддерживает технологический стек. Облако бросает вызов этой модели.
Внедрение облачных технологий предоставляет возможности, обеспечивающие организационные изменения. Одна из этих возможностей — создание кода. Teams может использовать код для создания каждой рабочей нагрузки или службы с помощью скриптов (шаблон ARM, Bicep, Terraform, CLI, PowerShell). Эта возможность является значительным отходом от прошлого, когда инфраструктура должна быть подготовлена через центральную группу, чтобы обеспечить согласованность и свести к минимуму риски. Владельцы миссии могут использовать код и обеспечивать лучшую согласованность. Согласованность позволяет владельцам миссий прогнозировать расходы, соответствовать требованиям безопасности и повышать эффективность развертывания. Тем не менее, есть организационный компонент. Владельцы миссии нуждаются в персонале с навыками автоматизации и написания сценариев, и они должны иметь их в своей команде перед созданием платформы.
Децентрализованное облако позволяет группам создавать собственные автономные решения и внедрять инновации в соответствии с потребностями на уровне миссии. Однако этот подход не будет успешным без эффективного согласования организации. Отсутствие управления и контроля может привести к попаданию конфликтующих рабочих нагрузок в рабочую среду. Важно, чтобы владельцы миссии переосмыслить и определить роли и обязанности
Определение новых ролей
Владельцы миссии должны определить роль и обязанности в облачном брокере. По мере перемещения рабочих нагрузок владельца миссии в облако облачные брокеры должны взять на себя больше ответственности со стороны владельца миссии. Владельцам миссии заманчиво сопоставлять локальные роли и обязанности в облаке, но две операционные модели делают его неэффективным подходом. Важно помнить, что облачные брокеры работают на облачной платформе в течение нескольких месяцев, прежде чем владельцы миссии получат доступ. Владельцы миссии должны помнить о своих знаниях о платформе при определении новых ролей и обязанностей. Владельцам миссии необходимо разрешить облачным брокерам создавать при этом защиту ключевых ресурсов.
Дополнительные сведения см. в разделе Необходимые облачные функции.
Определение обязанностей платформы
Владелец миссии и облачный брокер несут ответственность за платформу. Рекомендуется определить обязанности платформы следующим образом:
Поставщик облачных служб (Azure): как минимум, поставщик облачных служб поддерживает физическую инфраструктуру и защищает ресурсы в центре обработки данных. Этот уровень ответственности соответствует развертыванию инфраструктуры как услуги (IaaS). Ответственность меняется с помощью решений "платформа как услуга" (PaaS) и "программное обеспечение как услуга" (SaaS).
Облачный брокер. Облачный брокер управляет большей частью платформы. Он обеспечивает подключение к локальной сети защиты, управляет решением идентификации (клиентом) и большинством вспомогательных служб.
Владелец миссии. Владелец миссии создает, переносит приложения и управляет ими на платформе. Обязанности включают безопасность кода, надежность приложений, защиту данных и модернизацию.
Назначение финансового надзора
Частой областью, вызывающей озабоченность при внедрении облака, является финансовый надзор. Владельцы миссии должны назначать персонал для управления, мониторинга и прогнозирования затрат. Финансовый надзор, выполняющий эти обязанности, поможет избежать перерасхода. Владельцы миссии должны учитывать частоту получения отчетов о расходах на облако. Брифинг, по крайней мере два раза в месяц, обеспечивает необходимый контроль за внесением изменений, предотвращающих перерасход. Дополнительные сведения см. в разделе:
Определение других облачных функций
Владелец миссии не должен управлять облачным решением как единым блоком. Другие облачные функции, ориентированные на управление, операции, безопасность, автоматизацию и данные, могут потребоваться для выполнения определенных действий на облачной платформе.
Дополнительные сведения см. в разделе:
Следующий шаг
Методология упорядочения является последним шагом в командном домене. Далее приведена готовая методология для домена платформы.