Антишаблоны управления
Во время этапа внедрения облака вы можете столкнуться с антипаттернами. Ознакомьтесь с общими обязанностями и как создать стратегию безопасности на существующих платформах, чтобы избежать этих антипаттернов.
Антишаблон: неправильное понимание общих обязанностей
При внедрении облака не всегда ясно, где заканчивается ваша зона ответственности в отношении различных моделей обслуживания и начинается зона ответственности поставщика облачных служб. Для создания процессов и методик, связанных с рабочими элементами, использующими модели обслуживания, необходимы навыки и знания в области облачных технологий.
Пример: поставщик облачных служб управляет обновлениями
Члены отдела кадров компании используют инфраструктуру как службу (IaaS) для настройки нескольких серверов Windows в облаке. Предполагается, что поставщик облачных служб управляет обновлениями, так как ИТ-специалисты на сайте обычно обрабатывают установку обновлений. Отдел кадров не настраивает обновления, так как они не знают, что Azure не развертывает и не устанавливает обновления операционной системы (ОС) по умолчанию. В результате серверы не соответствуют требованиям и представляют угрозу безопасности.
Предпочтительный результат: создание плана готовности
Ознакомьтесь с информацией об общей ответственности в облаке. Продумайте и создайте план готовности. План готовности может послужить стимулом к обучению и повышению квалификации.
Антишаблон: предполагается, что готовые решения обеспечивают безопасность
Компании, как правило, рассматривают безопасность как функцию, присущую облачным службам. Хотя это предположение часто является правильным, большинство сред должны соответствовать требованиям платформы соответствия требованиям, которые могут отличаться от требований безопасности. Azure обеспечивает базовую безопасность, а портал Azure обеспечивает более расширенную безопасность с помощью Microsoft Defender для облака. При создании подписки необходимо настроить решение для применения стандарта соответствия требованиям и безопасности.
Пример: пренебрежение безопасностью в облаке
Компания разрабатывает новое приложение в облаке. Она выбирает архитектуру на основе нескольких служб по модели "платформа как услуга" (PaaS), а также несколько компонентов IaaS для отладки. После выпуска приложения в рабочей среде компания понимает, что один из серверов переходов был скомпрометирован и передавал данные на неизвестный IP-адрес. Было выяснено, что проблема заключается в общедоступном IP-адресе сервера переходов и пароле, который легко угадать. Компания могла бы избежать этой ситуации, если бы уделила больше внимания безопасности в облаке.
Предпочтительный результат: определение стратегии в отношении безопасности облака
Определите надлежащую стратегию в отношении безопасности облака. Дополнительные сведения см. в руководстве по подготовке к работе с облаком CISO. Ознакомьтесь с этим руководством главным сотрудником по информационной безопасности (CISO). Руководство по готовности к облаку CISO обсуждает такие темы, как ресурсы платформы безопасности, конфиденциальность и элементы управления, соответствие требованиям и прозрачность.
Сведения о защищенных облачных рабочих нагрузках см. в статье об Azure Security Benchmark. Используйте рекомендации CIS Controls версии 7.1 от Центра интернет-безопасности, а также NIST SP800-53 от Национального института стандартов и технологий (США), которые охватывают большинство угроз и мер безопасности.
Используйте Microsoft Defender для облака, чтобы выявлять риски, адаптировать рекомендации и улучшать состояние безопасности в вашей компании.
Реализуйте или поддерживайте автоматизированные требования к соответствию и безопасности компании с помощью Политика Azure и Политика Azure в качестве решения code.
Антишаблон: использование пользовательской платформы соответствия требованиям или управления
Внедрение пользовательской платформы соответствия и управления, которая не основана на отраслевых стандартах, может значительно увеличить время внедрения облака. Это связано с тем, что перевод пользовательской платформы в облачные параметры может быть сложным. Эта сложность может увеличить усилия, необходимые для перевода пользовательских мер и требований в реализуемые средства управления безопасностью. Компании обычно должны соответствовать аналогичным наборам требований к безопасности и соответствию требованиям. В результате большинство собственных платформ обеспечения соответствия и безопасности незначительно отличаются от текущих стандартных платформ. Компании с дополнительными требованиями к безопасности могут рассмотреть возможность создания новых платформ.
Пример: использование собственной платформы безопасности
Руководитель по информационной безопасности компании ставит перед сотрудниками отдела ИТ-безопасности задачу представить стратегию и платформу обеспечения безопасности в облаке. Вместо разработки на базе отраслевых стандартов отдел ИТ-безопасности создает новую платформу, основанную на текущей локальной политике безопасности. Команды AppOps и DevOps испытывают трудности с реализацией подготовленной политики безопасности в облаке.
Azure предлагает более всестороннюю структуру безопасности и соответствия, отличающуюся от собственной платформы компании. Команда по информационной безопасности считает, что средства управления Azure несовместимы с собственными правилами соответствия и безопасности. Если бы собственная платформа была основана на стандартизованных средствах управления, команде не пришлось бы приходить к такому заключению.
Предпочтительный результат: использование существующих платформ
Используйте или создайте существующие платформы, такие как элементы управления CIS версии 7.1 или NIST SP 800-53, перед установкой или внедрением пользовательской платформы соответствия компании. Существующие платформы делают переход на систему безопасности облака более простым и предсказуемым. Дополнительные сведения о реализации платформ см. в параметрах реализации целевых зон Azure.