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

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

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

Управление надежностью включает использование избыточности, репликации и определенных стратегий восстановления для минимизации простоя и защиты бизнеса. Таблица 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. Определение индикаторов уровня обслуживания (SLI). Используйте SLI для измерения производительности времени работы в соответствии с вашим SLO. Примеры включают мониторинг работоспособности службы и частоту ошибок.

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

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

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

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

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

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

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

Надежность данных включает репликацию данных (реплики) и резервные копии (копии на определенный момент времени) для обеспечения доступности и согласованности. Смотрите таблицу 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 для каждой рабочей нагрузки. Предпочитайте решения резервного копирования, встроенные в службу Azure, такие как собственные функции резервного копирования в Azure Cosmos DB и Базе данных SQL Azure. Если собственные резервные копии недоступны, включая локальные данные, используйте Azure Backup. Дополнительные сведения см. в разделе "Резервное копирование " и "Центр непрерывности бизнес-процессов Azure".

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 (SLA) для каждой службы из официального документа.

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

   3. Если у вас есть один критический путь, используйте формулу с одним регионом: N = S₁ × S₂ × S₃ × ... × S_n.

   4. Если у вас есть два или более критических пути, используйте формулу независимого пути: N = S_{1 x 1} - [(1 - S₂) × (1 - S₃)].

   5. Сложные рабочие нагрузки часто объединяют оба типа формул. Пример: N = S₁ × S₂ × S₃ × (S₄ x 1 - [(1 - S₅) × (1 - S₆)]).

   6. Для приложений с несколькими регионами используйте формулу для формулы с несколькими регионами: M = 1 - (1 - N)^R

   7. Сравните вычисляемое время простоя с временем простоя SLO. Дефицит требует более высокого уровня соглашений об уровне обслуживания или дополнительного резервирования. Пересчитывайте после каждого изменения. Остановите работу после того, как вычисляемое время простоя превышает SLO.

   Вариант использования	Формула	Переменные	Пример	Объяснение
   Один регион	N = S1 × S2 × S3 × ... × Sn	N = составное соглашение об уровне обслуживания. S = SLA службы Azure. n = количество сервисов на критическом пути.	N = 99.99% (приложение) × 99.95% (база данных) × 99.9% (кэш)	Простая рабочая нагрузка с приложением (99.99%), база данных (99,95%) и кэш (99,9%) в одном критическом пути.
   Независимые пути	S1 x 1 - [(1 - S2) × (1 - S3)]	S = SLA службы Azure.	99.99% (приложение) × (1 - [(1 - 99.95% база данных) × (1 - 99.9% кэш)])	В приложении база данных (99.95%) или кэш (99.9%) может выйти из строя без прерывания в работе.
   Многорегионная	M = 1 - (1 - N)^R	M = соглашение об уровне обслуживания в нескольких регионах. N = соглашение об уровне обслуживания в одном регионе. 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. Использование нескольких регионов. Для удовлетворения уровней обслуживания во время простоя часто требуется несколько регионов. Для распределения трафика используйте глобальные подсистемы балансировки нагрузки (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 для облака, чтобы регулярно проверять Azure на наличие уязвимостей. Microsoft Defender интегрируется с Microsoft Sentinel для предоставления единого представления событий безопасности.

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

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

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

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

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

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

Контрольный список для управления CAF