Поделиться через

Защита облачных активов

  • Статья

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

Схема, показывающая процесс управления CAF: готовый, администрирование, мониторинг и защита (RAMP).

Управление надежностью

Управление надежностью включает использование избыточности, репликации и определенных стратегий восстановления для минимизации простоя и защиты бизнеса. таблице 1 приведен пример трех приоритетов рабочей нагрузки, требований к надежности (SLO, максимальное время простоя, избыточность, балансировка нагрузки, репликация) и примеры сценариев, которые соответствуют целям уровня обслуживания (SLOS)

Таблица 1. Пример требований к приоритету рабочей нагрузки и надежности.

Приоритет Влияние на бизнес Минимальное время безотказной работы SLO Максимальное время простоя в месяц Избыточность архитектуры Балансировка нагрузки Репликация данных и резервные копии Пример сценария
Высокий уровень (критически важная задача) Немедленное и серьезное влияние на репутацию компании или выручку. 99,99 % 4,32 минуты Много регионов & с множеством зон доступности в каждом регионе Активный-активный Синхронная репликация данных между регионами резервных копий & для восстановления Базовые показатели, критически важные для миссии
Средний Измеримые последствия для репутации компании или доходов. 99.9% 43.20 минут Несколько регионов & и несколько зон доступности в каждом регионе Актив-пассив Асинхронная репликация данных между регионами и создание резервных копий для восстановления. шаблон надежного веб-приложения
Низкий Не влияет на репутацию компании, процессы или прибыль. 99 % 7.20 часов Один регион & несколько зон доступности Избыточность зоны доступности Синхронная репликация данных между зонами доступности и резервные копии для восстановления базовый уровень службы приложений
Базовая конфигурация виртуальных машин

Определение обязанностей по надежности

Обязанности по надежности зависят от модели развертывания. Используйте следующую таблицу, чтобы определить обязанности по управлению инфраструктурой (IaaS), платформой (PaaS), программным обеспечением (SaaS) и локальными развертываниями.

Ответственность На территории компании IaaS (Azure) PaaS (Azure) SaaS
Данные ✔️ ✔️ ✔️ ✔️
Код и среда выполнения ✔️ ✔️ ✔️
Облачные ресурсы ✔️ ✔️ ✔️
Физическое оборудование ✔️

Дополнительные сведения см. в разделе Общая ответственность за надежность.

Определение требований к надежности

Четко определенные требования к надежности критически важны для достижения целевых показателей времени безотказной работы, восстановления и допустимых потерь данных. Выполните следующие действия, чтобы определить требования к надежности:

  1. Приоритизация рабочих нагрузок. Установите высокие, средние (по умолчанию) или низкие приоритеты рабочим нагрузкам в зависимости от критической важности для бизнеса и уровня финансовых вложений. Регулярно просматривайте приоритеты для поддержания согласованности с бизнес-целями.

  2. Назначьте целевой уровень обслуживания (SLO) для всех рабочих нагрузок. Установите целевые показатели времени безотказной работы в соответствии с приоритетом рабочей нагрузки. Для рабочих нагрузок с более высоким приоритетом требуются более строгие цели времени простоя. SLO влияет на архитектуру, стратегии управления данными, процессы восстановления и затраты.

  3. Определите индикаторы уровня обслуживания (SLIs). Используйте SLIs для измерения производительности времени безотказной работы по сравнению с вашим SLO. Примеры включают мониторинг работоспособности служб и частоту ошибок.

  4. назначить целевое время восстановления (RTO) для всех рабочих нагрузок. RTO определяет максимально допустимое время простоя для ваших рабочих нагрузок. RTO должно быть короче, чем допустимое годовое время простоя. Например, время безотказной работы SLO 99.99% допускает менее 52 минут простоя в год (4,32 минуты в месяц). Выполните следующие действия.

    1. оценить количество сбоев. оценить частоту сбоя каждой рабочей нагрузки в год. Для рабочих нагрузок с операционной историей используйте SLIs. Для новых рабочих нагрузок выполните анализ режима сбоя для получения точной оценки.

    2. Оцените RTO. Разделите годовое допустимое время простоя на предполагаемое количество сбоев. Если вы оцениваете четыре сбоя в год, то ваш RTO должен составлять 13 минут или меньше (52 минут / 4 сбоя = 13-минутное RTO).

    3. Проверьте ваше время восстановления. Отслеживайте среднее время восстановления во время тестов отработки отказа и оперативных сбоев. Время восстановления от сбоя должно быть меньше вашего целевого времени восстановления (RTO). Если решение непрерывности бизнес-процессов занимает несколько часов.

  5. Определить цели точки восстановления (RPO) для всех рабочих нагрузок. Определите, сколько потери данных может терпеть ваш бизнес. Эта цель влияет на частоту репликации и резервного копирования данных.

  6. Определение целевых показателей надежности рабочей нагрузки. Целевые показатели надежности рабочей нагрузки см. в рекомендациях Платформы Well-Architected для определения целевых показателей надежности.

Управление надежностью данных

Надежность данных включает репликацию данных (реплики) и резервные копии (копии на определенный момент времени) для обеспечения доступности и согласованности. См. Таблица 2 примеры приоритета нагрузки в соответствии с целевыми показателями надежности данных.

Таблица 2. Приоритет рабочей нагрузки с примерами конфигураций надежности данных.

Приоритет рабочей нагрузки Время простоя SLO Репликация данных Резервные копии данных Пример сценария
Высоко 99,99 % Синхронная репликация данных между регионами

Синхронная репликация данных между зонами доступности		 Высокая частота резервного копирования между регионами. Частота должна поддерживать RTO и RPO. критически важная платформа данных
Средний 99.9% Синхронная репликация данных между регионами

Синхронная репликация данных между зонами доступности		 Резервные копии между регионами. Частота должна поддерживать RTO и RPO. Решение базы данных и хранилища в шаблоне Reliable Web App
Низкий 99 % Синхронная репликация данных между зонами доступности Резервные копии между регионами. Частота должна поддерживать RTO и RPO. Устойчивость данных в базовом веб-приложении с зональной избыточностью

Ваш подход должен согласовываться конфигурациями надежности данных с требованиями RTO и RPO ваших рабочих нагрузок. Выполните следующие действия.

  1. Управляйте репликацией данных. Реплицируйте данные синхронно или асинхронно в соответствии с требованиями RTO (время восстановления) и RPO (точка восстановления) вашей рабочей нагрузки.

    Распределение данных Репликация данных Конфигурация балансировки нагрузки
    Между зонами доступности Синхронная (почти в режиме реального времени) Большинство служб PaaS обрабатывают балансировку нагрузки между зонами в собственном коде
    Между регионами (активный — активный) Синхронный Балансировка нагрузки активно-активная
    По регионам (активный-пассивный) Асинхронный (периодический) Конфигурация "Активный-пассивный"

    Дополнительные сведения см. в разделе Репликация: избыточность данных.

  2. Управление резервными копиями данных. резервные копии предназначены для аварийного восстановления (сбоя службы), восстановления данных (удаление или повреждение), а также реагирование на инциденты (безопасность). Резервные копии должны поддерживать требования RTO и RPO для каждой рабочей нагрузки. Выберите решения резервного копирования, которые соответствуют целям RTO и RPO. Предпочитайте встроенные решения Azure, такие как Azure Cosmos DB и собственные резервные копии базы данных SQL Azure. В других случаях, включая локальные данные, используйте Azure Backup. Дополнительные сведения см. в разделе "Backup".

  3. Проектирование надежности данных рабочей нагрузки. Для проектирования надежности данных рабочей нагрузки см. руководство по секционированию данных Well-Architected Framework и руководства по службам Azure (начните с раздела "Надежность").

Управление надежностью кода и среды выполнения

Код и среда выполнения — это аспекты рабочей нагрузки. Well-Architected Следуйте руководству по самовосстановлению и самосохранению в рамках.

Управление надежностью облачных ресурсов

Для управления надежностью облачных ресурсов часто требуется избыточность архитектуры (повторяющиеся экземпляры служб) и эффективная стратегия балансировки нагрузки. См. таблицу 3 для примеров избыточности архитектуры, согласованной по приоритету рабочей нагрузки.

Таблица 3. Примеры приоритета рабочей нагрузки и избыточности архитектуры.

Приоритет рабочей нагрузки Избыточность архитектуры Подход к балансировке нагрузки Решение для балансировки нагрузки Azure Пример сценария
Высоко Два региона с зонами доступности & Активный-активный Azure Front Door (HTTP)

Диспетчер трафика Azure (не HTTP)		 Платформа базовых приложений, критически важных для выполнения задач
Средний Два региона с зонами доступности & Актив-пассив Azure Front Door (HTTP)

Диспетчер трафика Azure (не HTTP)		 Руководство по архитектуре шаблонов надежных веб-приложений
Низкий Один регион, зоны доступности & Между зонами доступности Шлюз приложений Azure

Добавить Azure Load Balancer для виртуальных машин		 базовый уровень службы приложений
Базовая конфигурация виртуальных машин

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

  1. оценить время работы архитектуры. Для каждой рабочей нагрузки вычислите составное соглашение об уровне обслуживания. Включать только службы, которые могут привести к сбою рабочей нагрузки (критический путь). Выполните следующие действия.

    1. Соберите соглашения об уровне готовности Microsoft для каждой службы на критическом пути вашей нагрузки.

    2. Если у вас нет независимых критических путей, вычислите составное соглашение об уровне обслуживания в одном регионе, умножая проценты времени простоя каждой соответствующей службы. Если у вас есть независимые критические пути, перейдите к шагу 3 перед вычислением.

    3. Если две службы Azure предоставляют независимые критические пути, примените к этим службам формулу независимых критических путей.

    4. Для приложений с несколькими регионами введите композитное соглашение об уровне обслуживания (N) в формулу времени безотказной работы с несколькими регионами.

    5. Сравните вычисляемое время простоя с временем простоя SLO. При необходимости настройте уровни служб или избыточность архитектуры.

    Вариант использования Формула Переменные Пример Объяснение
    Оценка времени простоя в одном регионе N = S1 × S2 × S3 × ... × Un N: Композитное SLA для служб Azure на критическом пути в одном регионе.
    S: процент работоспособности по SLA для каждой службы Azure.
    n: общее количество серверов Azure на критическом пути.    		 N = 99.99% (приложение) × 99.95% (база данных) × 99.9% (кэш) Простая рабочая нагрузка с приложением (99.99%), база данных (99,95%) и кэш (99,9%) в одном критическом пути.
    Оценка независимых критических путей S1 x 1 - [(1 - S2) × (1 - S3)] S: процент времени безотказной работы для служб Azure, предоставляющих независимые критические пути. 99.99% (приложение) × (1 - [(1 - 99.95% база данных) × (1 – 99.9% кэш)]) Два независимых критических пути. Либо база данных (99.95%), либо кэш (99.9%) могут выйти из строя без перерыва в работе.
    Оценка времени простоя в нескольких регионах M = 1 - (1 - N)^R M: оценка времени простоя в нескольких регионах.
    N: составное соглашение об уровне обслуживания (SLA) в одном регионе.
    R: количество используемых регионов.    		 Если N = 99,95% и R = 2, то M = 1 - (1 - 99,95%)^2 Рабочая нагрузка, развернутая в двух регионах.

  2. Настроить уровни служб. Перед изменением архитектуры оцените, могут ли разные уровни служб Azure (SKU) соответствовать вашим требованиям к надежности. Некоторые уровни служб Azure могут иметь разные соглашения об уровне доступности, например управляемые диски Azure.

  3. Добавить избыточность архитектуры. Если текущая оценка времени безотказной работы не соответствует вашему SLO, увеличьте избыточность:

    1. Использовать несколько зон доступности. Настроить рабочие нагрузки для использования нескольких зон доступности. Как зоны доступности повышают время безотказной работы, трудно оценить. Только у ограниченного количества служб есть соглашения об уровне обслуживания, учитывающие зоны доступности. Где соглашения об уровне обслуживания учитывают зоны доступности, используйте их в оценках времени безотказной работы. Некоторые примеры см. в следующей таблице.

      Тип службы Azure Службы Azure с соглашениями об уровне обслуживания для зоны доступности
      Вычислительные платформы Служба приложений
      Служба Azure Kubernetes
      Виртуальные машины
      Хранилище данных Служебная шина Azure
      Учетные записи хранения Azure
      Кэш Azure для Redis
      Уровень "Премиум" для файлов Azure
      База данных Azure Cosmos DB (облачная база данных)
      База данных SQL Azure
      База данных Azure для MySQL
      База данных Azure для PostgreSQL
      Управляемый экземпляр Azure для Apache Cassandra
      Балансировщик нагрузки Шлюз приложений
      Безопасность Брандмауэр Azure

    2. Использовать несколько регионов. Несколько регионов часто необходимы для выполнения требований по времени бесперебойной работы, специфицированных в SLO (спецификации уровня обслуживания). Для распределения трафика используйте глобальные подсистемы балансировки нагрузки (Azure Front Door или диспетчер трафика). Архитектуры с несколькими регионами требуют тщательного управления согласованности данных.

  4. Управление избыточностью архитектуры. Решите, как использовать избыточность: вы можете использовать избыточность архитектуры в рамках ежедневных операций (активно). Кроме того, вы можете использовать избыточность архитектуры в сценариях аварийного восстановления (пассивный). Примеры см. в таблице 3.

    1. Балансировка нагрузки между зонами доступности. Активно использовать все зоны доступности. Многие службы Azure PaaS автоматически управляют балансировкой нагрузки между зонами доступности. Нагрузки IaaS должны использовать внутренний балансировщик для распределения нагрузки между зонами доступности.

    2. Балансировка нагрузки между регионами. Определите, должны ли рабочие нагрузки с несколькими регионами выполняться в режиме активный-активный или активный-пассивный на основе требований к надежности.

  5. Управляйте конфигурациями служб. Последовательно применяйте конфигурации на избыточных экземплярах ресурсов Azure таким образом, чтобы ресурсы функционировали одинаково. Используйте инфраструктуру в качестве кода для обеспечения согласованности. Дополнительные сведения см. в конфигурации повторяющихся ресурсов.

  6. проектирование надежности рабочей нагрузки. Для проектирования надежности рабочей нагрузки см. Well-Architected Framework:

    Надежность рабочей нагрузки Руководство
    Опора надежности высокодоступная многорегиональная архитектура
    проектирование резервирования
    Использование зон доступности и регионов
    Руководство по обслуживанию руководства по службе Azure (начните с раздела "Надежность")

Дополнительные сведения см. в резервирование.

Управление непрерывностью бизнес-процессов

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

  1. подготовиться к сбоям. создание отдельных процедур восстановления для рабочих нагрузок на основе высоких, средних и низких приоритетов. надежности данных, кода и надежности среды выполненияи надежности облачных ресурсов являются основой подготовки к сбою. Выберите другие средства восстановления, чтобы помочь в подготовке непрерывности бизнес-процессов. Например, используйте Azure Site Recovery для серверных рабочих нагрузок, находящихся локально и в виртуальных машинах.

  2. Тестирование и документирование плана восстановления. Регулярно тестируйте процессы переключения на резервные системы и восстановления, чтобы убедиться, что рабочие нагрузки соответствуют целям времени восстановления (RTO) и целям точки восстановления (RPO). Четко документируйте каждый шаг плана восстановления для простой ссылки во время инцидентов. Убедитесь, что средства восстановления, такие как Azure Site Recovery, согласованно соответствуют указанному RTO.

  3. Обнаружить сбои. Принять упреждающий подход для быстрого выявления сбоев, даже если этот метод увеличивает ложные срабатывания. Придать приоритет опыту клиентов путем минимизации простоя и поддержания доверия пользователей.

    1. Мониторинг сбоев. Отслеживать рабочие нагрузки, чтобы обнаружить сбои в течение одной минуты. Используйте работоспособность служб Azure и работоспособность ресурсов Azure и оповещения Azure Monitor , чтобы уведомлять соответствующие команды. Интеграция этих оповещений с инструментами Azure DevOps или УПРАВЛЕНИЯ ИТ-службами (ITSM).

    2. Сбор индикаторов уровня обслуживания (SLI). Отслеживайте производительность, определяя и собирая метрики, которые служат в качестве SLI. Убедитесь, что ваши команды используют эти метрики для измерения производительности рабочей нагрузки по целям уровня обслуживания (SLOS).

  4. Реагируйте на сбои. Согласуйте ответ на восстановление с учетом приоритета рабочей нагрузки. Реализуйте процедуры отказоустойчивости для немедленного перенаправления запросов на резервную инфраструктуру и реплики данных. После стабилизации систем устраните первопричину, синхронизируйте данные и выполните процедуры отката. В статье «Переключение на резерв и возврат» содержатся дополнительные сведения.

  5. Анализировать сбои. определить первопричины проблем, а затем решить проблему. Задокументируйте все уроки и внесите необходимые изменения.

  6. Отказоустойчивость рабочих нагрузок. Для управления аварийным восстановлением рабочих нагрузок см. "Руководство по аварийному восстановлению" в Well-Architected Framework и "Руководства по службам Azure" (начните с раздела "Надежность").

Средства надежности Azure

Вариант использования Решение
Репликация данных, резервное копирование и непрерывность бизнес-процессов руководства по службе Azure (начните с раздела "Надежность")

Краткий справочник:
Azure Cosmos DB
База данных SQL Azure
Хранилище BLOB-объектов Azure
Файлы Azure
Резервное копирование данных Azure Backup
Непрерывность бизнес-процессов (IaaS) Azure Site Recovery
Подсистема балансировки нагрузки в нескольких регионах Azure Front Door (HTTP)
диспетчер трафика Azure (не HTTP)
Балансировщик нагрузки с несколькими зонами доступности Шлюз приложений Azure (HTTP)
Azure Load Balancer (не HTTP)

Управление безопасностью

Итеративный процесс безопасности позволяет выявлять и устранять угрозы в облачной среде. Выполните следующие действия.

Управление операциями безопасности

Управляйте параметрами безопасности для обнаружения угроз в вашем облачном окружении. Выполните следующие действия.

  1. стандартизируйте средства безопасности. использовать стандартные средства для обнаружения угроз, устранения уязвимостей, изучения проблем, защиты данных, защиты ресурсов и обеспечения соответствия требованиям в масштабе. Ознакомьтесь с средствами защиты Azure .

  2. Установите базовый уровень вашей среды. Документируйте нормальное состояние облачной инфраструктуры. Отслеживайте безопасность и документируйте шаблоны сетевого трафика и поведение пользователей. Используйте базовые показатели безопасности Azure и руководства по службе Azure для разработки базовых конфигураций для служб. Этот базовый план упрощает обнаружение аномалий и потенциальных недостатков безопасности.

  3. Применить элементы управления безопасностью. Реализуйте меры безопасности, такие как управление доступом, шифрование и многофакторная проверка подлинности, укрепление среды и снижение вероятности компрометации. Дополнительные сведения см. в статье Управление безопасностью.

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

Дополнительные сведения см. в разделе CAF Secure.

Управление инцидентами безопасности

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

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

  2. Обнаружение инцидентов. Использовать средства управления безопасностью и событиями (SIEM), например Microsoft Sentinel, для централизованной обработки данных безопасности. Используйте возможности оркестрации, автоматизации и реагирования безопасности (SOAR) Microsoft Sentinel для автоматизации рутинных задач безопасности. Интеграция каналов аналитики угроз в SIEM для получения аналитических сведений о тактике злоумышленников, относящихся к облачной среде. Используйте Microsoft Defender для cloud для регулярного сканирования Azure на наличие уязвимостей. Microsoft Defender интегрирует с Microsoft Sentinel для предоставления единого представления событий безопасности.

  3. Реагируйте на инциденты. Немедленно активируйте свой план реагирования на инциденты при обнаружении инцидента. Быстрый запуск исследований и процедур устранения рисков. Активируйте план аварийного восстановления для восстановления затронутых систем и четко сообщите сведения об инциденте команде.

  4. Анализ инцидентов безопасности. После каждого инцидента просмотрите аналитику угроз и обновите план реагирования на инциденты на основе уроков, извлеченных и аналитических сведений из общедоступных ресурсов, таких как MITRE ATT&CK базе знаний. Оцените эффективность средств управления уязвимостями и обнаружения уязвимостей и уточните стратегии на основе анализа после инцидента.

Дополнительные сведения см. в разделе Управление реагированием на инциденты (CAF Secure).

Средства безопасности Azure

Возможности безопасности Решение Майкрософт
Управление удостоверениями и доступом Microsoft Entra ID
Управление доступом на основе ролей Управление доступом на основе ролей в Azure
Обнаружение угроз Microsoft Defender для облака
Управление сведениями о безопасности Microsoft Sentinel
Безопасность и управление данными Microsoft Purview
Безопасность облачных ресурсов базовые показатели безопасности Azure
Управление облаком Политика Azure
Безопасность конечной точки Microsoft Defender для конечных устройств
Безопасность сети Наблюдатель за сетями Azure
Промышленная безопасность Microsoft Defender для Интернета вещей

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

контрольный список CAF Manage