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

Владение Azure или PowerShell на уровне эксперта не требуется. Также предполагается, что у читателя есть опыт работы с информационными технологиями корпоративного класса и достаточный уровень квалификации для работы в центре обработки данных.

Сегодня мы публикуем часть первой главы этой книги. Полную версию вы можете скачать бесплатно по ссылке.

---

Оглавление

• Безопасность облачных систем — 1;
• Защита удостоверений в Azure — 19;
• Безопасность сетей Azure — 53;
• Безопасность данных и хранилищ — 85;
• Защита виртуальных машин от вредоносного ПО — 103;
• Управление ключами в Azure с помощью Key Vault — 119;
• Безопасность Интернета вещей — 155;
• Мониторинг гибридных сред — 175;
• Эксплуатация и управление в облаке — 191;

Безопасность облачных систем

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

Важные факторы, влияющие на безопасность облачных систем

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

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

• Соответствие требованиям
• Управление рисками
• Управление удостоверениями и доступом
• Безопасность операций
• Защита конечных точек
• Защита данных

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

Соответствие требованиям

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

Для того чтобы помочь клиентам соответствовать действующим требованиям, Microsoft использует следующие три методологии.

• Изначальный учет необходимых требований
  
  • Надежная технология
  • Инвестиции в процессы обеспечения соответствия требованиям
  • Сертификация у сторонних организаций
• Помощь клиентам в обеспечении соответствия требованиям
  
  • Прозрачность
  • Возможность выбора
  • Гибкость
• Сотрудничество с компаниями-лидерами в различных отраслях
  
  • Разработка стандартов
  • Сотрудничество с законодательными и регулирующими органами

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

Подробнее: Более подробная информация о том, как Microsoft помогает клиентам обеспечивать соответствие требованиям, приводится в статье.

Управление рисками

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

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

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

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

Управление удостоверениями и доступом

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

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

• Подготовка удостоверений
  
  • Требования к подготовке удостоверений зависят от используемой модели облачных вычислений: программное обеспечение как услуга (SaaS), платформа как услуга (PaaS) или инфраструктура как услуга (IaaS).
  • Оцените возможности безопасной автоматизации подготовки удостоверений с использованием имеющейся локальной инфраструктуры.
• Федерация
  
  • Проанализируйте доступные методы и возможности интеграции этих методов с имеющейся локальной инфраструктурой.
• Единый вход (SSO)
  
  • Проанализируйте требования вашей организации в отношении SSO и возможности интеграции единого входа с используемыми приложениями.
• Управление профилями
  
  • Проанализируйте доступные варианты решения, которые предлагает поставщик облачных служб, и их соответствие требованиям вашей организации.
• Управление доступом
  
  • Оцените возможности управления доступом к данным, которые предлагает поставщик облачных служб.
  • Внедрите управление доступом на основе ролей (RBAC).

Безопасность операций

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

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

• Обучение сотрудников организации в ходе процесса.
• Внедрение отраслевых стандартов и практик в отношении операций, например, стандарта NIST SP 800-531.
• Управление информацией о безопасности в соответствии с отраслевыми стандартами, например, NIST SP 800-612.
• Использование аналитических данных об угрозах, которые предоставляет поставщик облачных служб.
• Непрерывное обновление средств контроля и противодействия рискам для повышения безопасности операций.

Защита конечных точек

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

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

• Своевременно обновляйте программное обеспечение конечных точек.
• Включите автоматическое обновление сигнатур на конечных точках.
• Контролируйте обращения к источникам обновлений программных продуктов.
• Убедитесь, что у конечных пользователей нет прав локальных администраторов.
• Выделяйте пользователям лишь минимальные привилегии, необходимые им для работы, и используйте администрирование на основе ролей.
• Оперативно реагируйте на уведомления от конечных точек.

Обратите внимание. Защита привилегированного доступа — критически важный этап обеспечения безопасности бизнеса. Рекомендуем ознакомиться со статьей о рабочих станциях для привилегированного доступа (PAW) по адресу aka.ms/cyberpaw и узнать больше о методологии Microsoft, предназначенной для защиты самых ценных активов.

Защита данных

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



На диаграмме показаны следующие этапы:

1. Данные хранятся на пользовательском устройстве. Данные находятся на конечной точке, которой может быть любое устройство. Необходимо обеспечить, чтобы данные, хранящиеся на пользовательских устройствах, используемых в рабочих целях (сценарии BYOD), а также на устройствах компании, обязательно были зашифрованы.
2. Данные передаются с устройства пользователя в облако. Данные должны быть защищены и тогда, когда они покидают пользовательское устройство. Существует множество технологий, позволяющих обеспечить защиту данных вне зависимости от расположения, — например, управление правами Azure. Канал передачи данных обязательно должен быть зашифрован. Соответствующие технологии, например, TLS, должны использоваться в принудительном порядке.
3. Данные хранятся в центре обработки данных поставщика облачных служб. Когда данные попадают на серверы поставщика облачных служб, инфраструктура хранения должна обеспечить их избыточность и защиту. Обязательно выясните, как именно у поставщика облачных служб реализовано шифрование данных при хранении, кто несет ответственность за управление ключами и как обеспечивается избыточность данных.
4. Данные передаются из облака в локальную среду. В этом случае действуют рекомендации, приведенные для этапа 2. Необходимо обеспечить шифрование как самого файла, так и транспортного уровня.
5. Данные хранятся в локальной среде. Обеспечение безопасности данных в локальной среде — задача клиента. Критически важный этап ее реализации — шифрование данных, хранящихся в центре обработки данных компании. Ваша инфраструктура должна обеспечивать необходимый уровень шифрования, избыточности данных и управления ключами.

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

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

Я иногда привожу своим друзьям следующий пример. Если в 90-х годах для нового проекта мне требовалось с десяток серверов, то составление планов, их заказ, доставка, размещение, подключение, настройка и развертывание могли занять 4–6 месяцев, и только после этого команда могла приступать к тестированию рабочей версии службы. Сегодня благодаря Azure я могу сделать это за 30 минут, пользуясь одним только телефоном.

Джим Молини
Старший менеджер программ, C+E Security

Разделение ответственности

В традиционном центре обработки данных ответственность за все аспекты инфраструктуры несет сама ИТ-компания. Именно так работали локальные вычислительные среды с момента появления современных клиент-серверных архитектур (и даже раньше, в эпоху мейнфреймов). Если сеть, хранилище или вычислительные системы работали не так, как нужно, то именно ИТ-компания должна была установить причину и исправить проблему.

С подразделениями безопасности ситуация обстояла похожим образом. Отдел безопасности сотрудничал с ИТотделом, и совместными усилиями они обеспечивали защиту компонентов ИТ-инфраструктуры. Отдел безопасности компании устанавливал требования, обсуждал их с ИТ-отделом и определял средства управления, которые ИТинфраструктура и операторы могли бы реализовать. Кроме того, отдел безопасности определял стандарты и регулярно проводил аудит инфраструктуры на предмет соответствия этим стандартам.

Для центров обработки данных, размещенных вне локальных сред, все это остается в силе. Однако с появлением вычислительных сред на базе публичных облаков у ИТ-отделов и отделов безопасности появился новый партнер — поставщик облачных служб. Такой поставщик обладает собственной ИТ-инфраструктурой и обязан обеспечить ее соответствие требованиям безопасности и управляемости.

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

Облачные вычисления

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

Определение облачных вычислений, опубликованное институтом NIST

Какое-то время для термина «облачные вычисления» не было формального определения. Конечно, люди с опытом работы в отрасли под «облаком» понимали Интернет. Для некоторых суть облачных вычислений заключалась именно в предоставлении услуг через Интернет.

Отдельные аналитики использовали термин utility computing («вычисления как коммунальная услуга»), акцентируя таким образом внимание на модели оказания услуги. В рамках коммунальной модели есть определенный набор возможностей, которые доступны всем желающим. Оплата взимается в соответствии с объемом использованных ресурсов. Очень похоже на потребление, например, электричества и газа частными лицами.

В настоящее время официальные органы и компании из множества стран используют определение облачных вычислений, которое опубликовал институт NIST. Они считают его наиболее достоверным и полезным. NIST — это Национальный институт стандартов и технологий США.

Институт NIST опубликовал «пять базовых характеристик» облачных вычислений, а также определение моделей облачных служб и облачного развертывания. Эти формулировки существенно продвинули понимание природы облачных вычислений.

На рисунке показаны пять базовых характеристик, модели облачных служб и модели облачного развертывания.

Характеристики облачных вычислений

NIST выделяет следующие пять базовых характеристик облачных вычислений:

• Возможность самообслуживания по запросу. Возможность облачной платформы предоставить потребителям облачной службы необходимые ресурсы без какого-либо взаимодействия с ними. Пример реализации такой возможности: потребитель заполняет веб-форму, указывая свои требования к ресурсам, а поставщик облачной службы выделяет необходимое.
• Широкие возможности доступа с использованием сети. Возможность обращаться к ресурсам облака практически из любой точки мира с любого устройства. Важно отметить, что широкие возможности доступа через сеть являются частью определения облачных вычислений, и предоставление такого доступа — важное условие успешного развертывания. Но этот пункт не означает, что доступ должен быть открыт всегда и для всех. В ходе знакомства с этой книгой вы узнаете, что средства управления доступом — критически важная часть любой облачной системы.
• Поддержка быстрых изменений. Имеется в виду, что потребители облачных служб могут быстро получать облачные ресурсы по необходимости, а затем возвращать их в пул общих облачных ресурсов, когда эта необходимость отпадает. Облачные службы устроены так, чтобы потребители могли быстро получать и возвращать ресурсы. С точки зрения клиента объем ресурсов, которые можно получить из облака, практически не ограничен. Если потребитель облачной службы считает, что скоро ему понадобится больше ресурсов, он может запросить их у поставщика, чтобы справиться с предстоящей нагрузкой. В основе такой динамичной эластичности лежит именно неограниченность ресурсов с точки зрения потребителя.
• Организация пулов ресурсов. Все потребители облачной службы пользуются ресурсами из общего набора (пула). Серверы, сетевые компоненты и хранилища являются общими для всех пользователей облачной среды. Этот пул ресурсов динамически делится на части так, чтобы у клиентов был доступ только к собственным данным, приложениям и виртуальным машинам. Ввиду этого требования для успешности любой облачной инфраструктуры необходимо реализовать изоляцию на всех уровнях. (Тему изоляции мы рассмотрим подробнее далее в этой главе.)
• Учет объемов потребления. Потребители облачных служб платят только за те ресурсы, которые использовали — так же, как в случае коммунальных услуг, например, при оплате потребления электроэнергии, воды или газа (хотя в этом случае иногда применяется базовая ставка за доступ к службам). Этот пункт также означает, что поставщик облачной службы должен обеспечить прозрачность потребления — предоставлять клиентам информацию об объеме потребления, чтобы они могли планировать свои будущие потребности и расходы.

Модели облачных служб

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

Модели облачных служб:

• Инфраструктура как услуга (laaS).Предоставление базовой физической инфраструктуры, вычислительных систем и хранилищ данных. Владельцем и ответственным за обслуживание такой инфраструктуры является поставщик облачных служб, и именно он обязан поддерживать ее работоспособность, обеспечивать высокую эффективность и безопасность компонентов. В отличие от локальной вычислительной среды, при использовании laaS в ваши обязанности не входит поддержка этих базовых уровней среды для любого решения, которое вы размещаете в инфраструктуре партнера поставщика облачных служб.
• Платформа как услуга (PaaS). Здесь клиент получает все то же, что в случае «платформа как услуга», а также компоненты платформы разработки. В рамках такой модели поставщик облачных служб контролирует не только инфраструктуру, но и операционную систему (либо компоненты, предоставляющие аналогичную функциональность) и среду выполнения (например, платформу веб-сервера), которые необходимы для выполнения приложений, разработанных клиентами. Обеспечение безопасности этих операционных систем (или аналогов) и среды выполнения также является обязанностью поставщика облачных служб, а не клиента.
• Программное обеспечение как услуга (SaaS). Этот вариант также называют «готовые службы». В этом случае обслуживание всей инфраструктуры, платформы и среды приложений является обязанностью поставщика услуги. Подход «программное обеспечение как услуга» позволяет клиентам получить полноценное приложение с набором возможностей, которые обычно присущи локальным решениям. Примерами являются Microsoft Exchange Server (для работы с электронной почтой) и Microsoft SharePoint (для совместной работы). Безопасное развертывание приложения и управление им также относятся к обязанностям поставщика облачных служб.

Модели облачного развертывания

NIST выделяет четыре модели развертывания:

• Публичное облако. Эта модель устроена так, чтобы множество клиентов могли обращаться к общей инфраструктуре из любой точки мира. Все клиенты публичного облака пользуются общими компонентами — серверами, сетевыми устройствами и накопителями. Разумеется, методы развертывания и управления этими физическими компонентами инфраструктуры соответствуют требованиям к облаку. Как мы увидим далее, ключевое условие успешности публичного облака — надежная изоляция: возможность изолировать ресурсы различных клиентов на всех уровнях. Выполнение этого условия является самой главной обязанностью всех поставщиков публичных облачных служб.
• Частное облако. В рамках этой модели развертывания размещением облачной среды управляет ИТ-отдел компании. Частное облако и традиционный центр обработки данных — не одно и то же (хотя эти понятия часто смешивают). Частное облако, в отличие от традиционного локального центра обработки данных, соответствует всем пяти базовым характеристикам облачных вычислений, которые предложены институтом NIST (мы рассмотрели их выше). Требование изоляции применимо и к частным облакам (хотя в этом случае оно может быть менее важно, чем для публичных — это зависит от сценария использования, от имеющегося уровня доверия и разделения на зоны безопасности в инфраструктуре компании, а также от требований компании к защите облачной среды).
  
  Чем же отличается частное облако от публичного? Тем, что компания может управлять всеми составляющими своего частного облака без какой-либо зависимости от других организаций.
• Гибридное облако. Такая модель развертывания обычно подразумевает сочетание публичного и частного облака. Существуют и другие типы гибридных облаков — например, комбинации из публичного и общественного облака или даже двух публичных облаков. В типичном сценарии гибридного облачного развертывания различные компоненты решения размещаются в двух средах — в публичном облаке и в частном облаке.
  
  Рассмотрим в качестве примера трехуровневое приложение, у которого есть внешний веб-интерфейс, промежуточный уровень логики приложения и служебный уровень баз данных. В случае гибридной облачной среды интерфейсные веб-серверы и серверы логики приложения размещаются в публичном облаке, а служебные базы данных — в локальной инфраструктуре. Обычно локальная сеть обменивается данными с публичным облаком через соединение различных сред — например, VPN-подключение или выделенный WAN-канал.
• Общественное облако. Такое облако является разновидностью публичного, но оно открыто не для всех потенциальных пользователей. Общественные облачные инфраструктуры предназначены для использования определенной группой людей — например, правительством региона, штата или страны.

Архитектура безопасности Azure

Как мы уже говорили в этой главе, ответственность за безопасность облака делится между несколькими участниками. Azure не является исключением. Однако при проектировании платформы Azure изначально использовались принципы, которые называются Security Development Lifecycle (SDL), или «жизненный цикл разработки защищенных приложений». В платформе Azure реализовано множество функций, которые повышают защиту расположенных в ней клиентских ресурсов.

Средства обеспечения безопасности встроены в инфраструктуру Azure на различных уровнях: физическая безопасность, безопасность данных, управление удостоверениями и доступом, безопасность приложений. На рисунке 1-4 показаны некоторые базовые компоненты архитектуры Azure.



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

Обратите внимание. Для предоставления пользователям необходимых разрешений администраторы Azure должны использовать управление доступом на основе ролей (RBAC). Подробнее о RBAC можно узнать здесь: azure.microsoft.com/documentation/articles/role-based-access-control-configure.

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

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

Виртуальные машины можно настроить так, чтобы они были доступны через Интернет, или так, чтобы они могли взаимодействовать только с компонентами инфраструктуры Azure. Вы можете защищать ресурсы, доступные в виртуальных машинах (например, на веб-сервере), и ограничивать доступ к этим ресурсам с помощью списков управления доступом (ACL). Чтобы изолировать виртуальные машины в облаке, можно создать несколько виртуальных сетей и управлять передачей трафика между ними с помощью групп безопасности сети (NSG).

Подробнее. Более подробная информация об Azure Active Directory приводится в главе 2, «Защита удостоверений в Azure». Более подробная информация о группах безопасности сети содержится в главе 3, «Безопасность сетей Azure».

Следующий, более глубокий уровень Azure называется структурой Azure. Управлением этой структурой и защитой ее ресурсов занимается Microsoft. Назначение этой структуры — управление вычислительными ресурсами и хранилищем, выделение ресурсов и обеспечение возможности восстановления в случае аппаратного сбоя. Важнейшая задача этого уровня — обеспечить достаточный уровень избыточности и устойчивости к ошибкам для выполнения условий соглашения об уровне обслуживания (SLA).

---

Бесплатно скачать полную версию книги и изучить ее вы можете по ссылке ниже.

> Скачать