Безопасность Azure для облачных приложений

Подсказка

Это фрагмент из электронной книги «Архитектура облачных нативных приложений .NET для Azure», доступен на .NET Docs или как бесплатный загружаемый PDF-файл, который можно прочитать в автономном режиме.

Скачать в формате PDF

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

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

Моделирование угроз

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

• Каково влияние потери этих данных?
• Как ограничить ущерб от внедрения плохих данных в эту службу?
• Кто должен иметь доступ к этим данным?
• Существуют ли политики аудита вокруг процесса разработки и выпуска?

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

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

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

Более вероятные угрозы, такие как нарушенные контроллеры доступа, разрешающие Id атаки с инкрементированием (заменяющие Id=2 на Id=3 в URL) или внедрение SQL, более привлекательны для создания защиты от. Меры по предотвращению этих угроз достаточно разумны, чтобы избежать неловких уязвимостей в безопасности, которые могут повредить репутации компании.

Принцип наименьших привилегий

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

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

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

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

Тестирование на проникновение

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

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

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

Контроль

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

Защита сборки

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

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

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

Создание защищенного кода

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

Существует множество способов сделать код .NET более безопасным. Следующие рекомендации, такие как рекомендации по безопасному программированию для .NET , являются разумным шагом, чтобы обеспечить безопасность кода с нуля. OWASP top 10 — это еще одно бесценное руководство по созданию защищенного кода.

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

Встроенная безопасность

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

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

Сетевая инфраструктура Azure

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

По умолчанию, большинство ресурсов PaaS Azure имеют только самую базовую и разрешительную настройку сети. Например, любой пользователь в Интернете может получить доступ к службе приложений. Новые экземпляры SQL Server обычно ограничены, чтобы внешние стороны не могли получить к ним доступ, но диапазоны IP-адресов, используемые самой Azure, разрешены. Таким образом, хотя сервер SQL защищен от внешних угроз, злоумышленнику нужно настроить только плацдарм Azure, откуда он может запускать атаки на все экземпляры SQL в Azure.

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

Рис. 9-1. Виртуальная сеть в Azure.

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

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

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

Продолжая иллюстрацию принципа наименьших привилегий, не каждый ресурс внутри виртуальной сети должен взаимодействовать с каждым ресурсом. Например, в приложении, которое предоставляет веб-API через учетную запись хранения и базу данных SQL, маловероятно, что база данных и учетная запись хранения должны взаимодействовать друг с другом. Любой обмен данными между ними будет проходить через веб-приложение. Таким образом, группу безопасности сети (NSG) можно использовать для запрета трафика между двумя службами.

Политика запрета связи между ресурсами может быть раздражающей при реализации, особенно если вы имеете опыт использования Azure без ограничений на трафик. В некоторых других облаках концепция групп безопасности сети гораздо более распространена. Например, политика по умолчанию в AWS заключается в том, что ресурсы не могут обмениваться данными между собой, пока не включены правила в NSG. Хотя и медленнее развивать это, более ограничительная среда обеспечивает более безопасную среду по умолчанию. Использование надлежащих методик DevOps, особенно с помощью Azure Resource Manager или Terraform для управления разрешениями, может упростить управление правилами.

Виртуальные сети также могут быть полезны при настройке связи между локальными и облачными ресурсами. Виртуальную частную сеть можно использовать для простого подключения двух сетей. Такой подход позволяет запускать виртуальную сеть без какого-либо шлюза для сценариев, где все пользователи находятся на сайте. Существует ряд технологий, которые можно использовать для установления этой сети. Проще всего использовать VPN типа "сеть — сеть ", который можно установить между многими маршрутизаторами и Azure. Трафик шифруется и туннелируется через Интернет по той же стоимости за байт, что и любой другой трафик. В сценариях, когда требуется больше пропускной способности или больше безопасности, Azure предлагает службу Express Route , которая использует частный канал между локальной сетью и Azure. Это более затратно и трудно установить, но и более безопасно.

Управление доступом на основе ролей для ограничения доступа к ресурсам Azure

RBAC — это система, которая предоставляет удостоверение приложениям, работающим в Azure. Приложения могут получать доступ к ресурсам с помощью этого удостоверения вместо использования ключей или паролей или в дополнение к ним.

Субъекты безопасности

Первым компонентом в RBAC является субъект безопасности. Субъект безопасности может быть пользователем, группой, служебным субъектом или управляемым удостоверением.

Рис. 9-2. Различные типы субъектов безопасности.

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

Субъект безопасности может применяться к большинству ресурсов. Этот аспект означает, что учетную запись безопасности можно присвоить контейнеру, работающему в Azure Kubernetes, позволяя ему получить доступ к секретам, хранящимся в Key Vault. Функция Azure может принять разрешение, позволяющее ему взаимодействовать с экземпляром Active Directory для проверки JWT для вызывающего пользователя. После включения служб с субъектом-службой их разрешения можно детально управлять с помощью ролей и областей.

Роли

Субъект безопасности может взять на себя множество ролей или, используя более сарториальную аналогию, носить много шляп. Каждая роль определяет ряд разрешений, таких как "Чтение сообщений из конечной точки служебной шины Azure". Эффективный набор разрешений субъекта безопасности — это сочетание всех разрешений, назначенных всем ролям, которые имеет субъект безопасности. Azure имеет большое количество встроенных ролей, и пользователи могут определять свои собственные роли.

Рис. 9-3. Определения ролей RBAC.

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

Более детализированные встроенные роли, такие как участник зоны DNS , имеют права, ограниченные одной службой. Субъекты безопасности могут принимать любое количество ролей.

Области применения

Роли можно применять к ограниченному набору ресурсов в Azure. Например, применяя область к предыдущему примеру чтения из очереди Azure Service Bus, вы можете сузить разрешение до одной очереди: "Чтение сообщений из конечной точки Azure Service Bus blah.servicebus.windows.net/queue1"

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

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

Отрицать

Ранее для RBAC допускались только правила типа 'allow'. Это поведение усложнило сборку некоторых рамок. Например, предоставление субъекту безопасности доступа ко всем учетным записям хранилища, кроме одной, требовало бы явного разрешения для потенциально бесконечного списка учетных записей хранилища. Каждый раз при создании новой учетной записи хранения следовало бы добавить её в этот список учетных записей. Это добавило затраты на управление, которые, безусловно, не были желательными.

Правила запрета имеют приоритет над правилами допуска. Теперь представление той же области "разрешить все, кроме одной" можно представить двумя правилами: "разрешить все" и "запретить этот конкретный". Запретить правила не только упрощают управление, но и позволяют ресурсам, которые являются дополнительными безопасными, запрещая доступ всем пользователям.

Проверка доступа

Как вы можете себе представить, наличие большого количества ролей и областей может сделать определение эффективного разрешения субъекта-службы довольно сложным. Накладывание правил отказа на это только увеличивает сложность. К счастью, у нас есть калькулятор разрешений, который может показать действующие разрешения для любого сервисного принципала. Обычно он находится на вкладке IAM на портале, как показано на рис. 9-3.

Рис. 9-4. Калькулятор разрешений для службы приложений.

Защита секретов

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

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

Azure Key Vault

Azure Key Vault предоставляет централизованное расположение для хранения паролей, таких как базы данных, ключи API и сертификаты. После ввода секрета в хранилище он никогда не отображается снова, и команды для извлечения и просмотра их намеренно сложны. Информация в сейфе защищена с использованием программного шифрования или сертифицированных аппаратных модулей безопасности стандарта FIPS 140-2 уровня 2.

Доступ к хранилищу ключей предоставляется через RBACs, что означает, что не только любой пользователь может получить доступ к информации в хранилище. Предположим, что веб-приложение хочет получить доступ к строке подключения к базе данных, хранящейся в Azure Key Vault. Чтобы получить доступ, приложениям необходимо использовать учетную запись службы. В рамках принятой роли они могут считывать секреты из сейфа. Существует ряд различных параметров безопасности, которые могут дополнительно ограничить доступ приложения к хранилищу, так что оно не сможет обновлять секреты, а только читать их.

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

Kubernetes

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

Создание секрета так же просто, как поиск версии base64 для хранения значений:

echo -n 'admin' | base64
YWRtaW4=
echo -n '1f2d1e2e67df' | base64
MWYyZDFlMmU2N2Rm

Затем добавьте его в файл секретов с именем secret.yml , например, который выглядит примерно так:

apiVersion: v1
kind: Secret
metadata:
  name: mysecret
type: Opaque
data:
  username: YWRtaW4=
  password: MWYyZDFlMmU2N2Rm

Наконец, этот файл можно загрузить в Kubernetes, выполнив следующую команду:

kubectl apply -f ./secret.yaml

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

Альтернативой использованию встроенных секретов Kubernetes является доступ к секретам в Azure Key Vault изнутри Kubernetes. Самый простой способ сделать это — назначить роль RBAC контейнеру, который ищет загрузку секретов. Затем приложение может использовать API Azure Key Vault для доступа к секретам. Однако этот подход требует изменений в коде и не соответствует шаблону использования переменных среды. Вместо этого можно внедрить значения в контейнер. Этот подход на самом деле более безопасный, чем использование секретов Kubernetes напрямую, так как к ним можно получить доступ пользователям в кластере.

Шифрование при передаче и хранении

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

В пути

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

TLS — это сложный протокол и просто зная, что подключение использует TLS недостаточно для обеспечения безопасности. Например, TLS 1.0 является хронически небезопасным, и TLS 1.1 не намного лучше. Даже в версиях TLS существуют различные параметры, которые могут упростить расшифровку подключений. Лучше всего проверить, использует ли подключение к серверу up-to-date и правильно настроенные протоколы.

Эта проверка может выполняться внешней службой, например тестом SSL-сервера лабораторий SSL. Тестовое выполнение для типичной конечной точки Azure в данном случае конечной точки служебной шины дает почти идеальный показатель A.

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

Рис. 9-5. Отчет SSL Labs, показывающий оценку A для конечной точки шины службы.

Хотя этот уровень шифрования не будет достаточно для всех времен, он должен вдохновить уверенность в том, что подключения TLS Azure довольно безопасны. Azure продолжит развивать свои стандарты безопасности по мере улучшения шифрования. Приятно знать, что есть кто-то, кто следит за стандартами безопасности и обновляет Azure по мере улучшения стандартов.

В покое

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

Хранение

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

Если служба хранилища Azure хорошо зашифрована, она обеспечивает основу для шифрования большинства остальных компонентов. Служба хранилища Azure шифруетсяс использованием FIPS 140-2и 256-битного AES. Это высоко ценимая технология шифрования, будучи предметом обширного академического исследования за последние примерно 20 лет. В настоящее время нет известной практической атаки, которая позволит кому-то без знания ключа считывать данные, зашифрованные AES.

По умолчанию ключи, используемые для шифрования службы хранилища Azure, управляются корпорацией Майкрософт. Существует обширная защита, чтобы предотвратить вредоносный доступ к этим ключам. Однако пользователи с определенными требованиями к шифрованию также могут предоставлять собственные ключи хранилища , управляемые в Azure Key Vault. Эти ключи могут быть отозваны в любое время, что эффективно сделает содержимое учетной записи 'Storage' недоступным.

Виртуальные машины используют зашифрованное хранилище, но можно предоставить другой уровень шифрования с помощью таких технологий, как BitLocker в Windows или DM-Crypt в Linux. Эти технологии означают, что даже если образ диска утек со хранилища, его будет почти невозможно прочитать.

Azure SQL

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

Параметры шифрования хранятся в master базе данных и при запуске считываются в память для оставшихся операций. Это означает, что master база данных должна оставаться незашифрованной. Фактический ключ управляется корпорацией Майкрософт. Однако пользователи с точными требованиями к безопасности могут предоставлять собственный ключ в Key Vault так же, как и для службы хранилища Azure. Хранилище ключей предоставляет такие службы, как смена ключей и отзыв.

Часть названия TDS "Прозрачность" объясняется тем, что для использования зашифрованной базы данных не требуется никаких изменений в клиенте. Хотя этот подход обеспечивает хорошую безопасность, утечка пароля базы данных достаточно для того, чтобы пользователи могли расшифровать данные. Существует другой подход, который шифрует отдельные столбцы или таблицы в базе данных. Always Encrypted гарантирует, что зашифрованные данные не отображаются в виде обычного текста в базе данных.

Для настройки этого уровня шифрования требуется запустить мастер в SQL Server Management Studio, чтобы выбрать тип шифрования и место в Key Vault для хранения связанных ключей.

Рис. 9-6. Выбор столбцов в таблице для шифрования с помощью Always Encrypted.

Клиентские приложения, которые считывают информацию из этих зашифрованных столбцов, необходимо учитывать особенности для чтения зашифрованных данных. Строки подключения необходимо обновить с помощью Column Encryption Setting=Enabled, а учетные данные клиента получить из Key Vault. Затем клиент SQL Server должен быть настроен с помощью ключей шифрования столбцов. После этого остальные действия используют стандартные интерфейсы для клиента SQL. То есть средства, такие как Dapper и Entity Framework, созданные на основе клиента SQL, будут продолжать работать без изменений. Always Encrypted пока недоступен для каждого драйвера SQL Server на каждом языке.

Сочетание TDE и Always Encrypted, оба из которых могут использоваться с ключами, зависящими от клиента, гарантирует, что поддерживаются даже самые точные требования к шифрованию.

База данных Cosmos DB

Cosmos DB — это новая база данных, предоставляемая Корпорацией Майкрософт в Azure. Он был построен с нуля с учетом безопасности и шифрования. Шифрование AES-256bit является стандартным для всех баз данных Cosmos DB и не может быть отключено. В сочетании с требованием TLS 1.2 для обмена данными шифруется все решение хранилища.

Рис. 9-7. Поток шифрования данных в Cosmos DB.

В то время как Cosmos DB не предоставляет ключи шифрования клиентов, команда провела значительную работу, чтобы гарантировать, что она остается PCI-DSS совместимой без этого. Cosmos DB также пока не поддерживает шифрование отдельного столбца, аналогичное Azure SQL Always Encrypted.

Сохранение безопасности

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

НазадДалее