Share via

Windows Azure. Безопасность. Часть 2

  • Article

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

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

Третий уровень безопасности, за которой отвечает поставщик «облачных» сервисов – это среда выполнения и операционная система.

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

В Windows Azure каждая роль выполняется внутри собственной виртуальной машины. Каждая виртуальная машина имеет 1, 2, 4 или 8 виртуальных процессоров и до 14 Гбайт памяти. В виртуальных машинах работает специальная версия Windows Server 2008 или Windows Server 2008 R2, на которой установлены необходимые программные компоненты - IIS, .NET Framework – их состав зависит от типа роли. В виртуальной машине также находится ограниченный набор драйверов устройств. Подробнее об этом см. «Внутри виртуальной машины Windows Azure».

На уровне отдельных узлов не поддерживается «долгосрочное» хранение данных. Данные, записанные на локальные диски, не сохраняются при установке/удалении виртуальных машин. Данные, которые должны быть сохранены, должны храниться с использованием сервисов Azure Storage.

В Windows Azure используется собственный гипервизор – слой виртуализации, разработанный Microsoft на основе технологий, используемых в Hyper-V. Этот гипервизор взаимодействует непосредственно с аппаратной инфраструктурой и разделяет узлы на определенно число виртуальных машин. Каждый узел имеет «корневую» виртуальную машину, на которой выполняется операционная система, представляющая собой существенно обрезанную версию Windows Server, включающая только компоненты, требуемые для хостинга виртуальных машин, агент Fabric Controller и т.п. Это сделано для того, чтобы улучшить производительность и минимизировать область потенциальных атак.

Критической границей является изоляция корневой виртуальной машины от гостевых виртуальных машин и гостевых машин друг от друга. Эта граница реализуется гипервизором и корневой операционной системой. Инфраструктура Windows Azure регулярно устанавливает обновления операционной системы на образы виртуальных дисков (Virtual Hard Drive, VHD), содержащие гостевую операционную систему. У потребителей имеется возможность указать на необходимость использования определенной версии операционной системы – в этом случае дальнейшие обновления устанавливаться не будут.

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

  • Диск D содержит одну из нескольких версий гостевой операционной системы, выбираемой потребителем. Версия операционной системы поддерживается в актуальном состоянии за счет автоматической установки обновлений
  • Диск E содержит образ приложения, создаваемый Fabric Controller на основе пакета развертывания, предоставляемого потребителем. Более подробно про развертывание приложений см. «Windows Azure. Быстрый старт. Развертывание приложений»
  • Диск C содержит конфигурационную информацию и данные, собираемые в процессе работы приложения

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

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

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

Дизайн и разработка веб-приложений должны учитывать следующие рекомендации:

  • Проверка вводимой информации
    • Необходимо выполнять проверку всех вводимых данных, которые пересекают т.н. «границу доверия» (trust boundary). Правильно реализованная проверка позволяет «отсечь» достаточно высокое число существующих и будущих атак. Такая проверка обычно является достаточно простой и очень эффективной. При выполнении проверки можно использовать две стратегии – «белый список» и «черный список». Проверка на основании «белого списка» задает шаблон для проверки корректного ввода – все данные, соответствующие этому шаблону попадают в систему, остальные – отсекаются. Если такой шаблон задать невозможно, создается «черный список», содержащий описание некорректного ввода – при вводе такие данные отсекаются
  • Аутентификация
    • Необходимо идентифицировать пользователей. Практически все веб-приложения должны знать источники запросов к ним
  • Авторизация
    • Проверяйте полномочия, доступные пользователям и то, что выполняемые операции доступны только пользователям с соответствующими привилегиями
  • Управлениеконфигурациями
    • Защищайте информацию, которая размещается в конфигурационных файлах приложения – например, строки соединения. Управление изменениями приложениями – развертыванием новых версий – это процесс, который требует особого внимания с точки зрения безопасности
  • Управлениесессиями
    • Защищайте состояние приложения – информацию, которая сохраняется в рамках сессии и между сессиями
  • Криптография
    • Используйте надежные криптографические алгоритмы и храните ключи в защищенном месте
  • Защитапараметров
    • Защищайте параметры, передаваемые между различными модулями приложения – например, http-параметры, передаваемые между веб-страницами
  • Управлениеисключениями
    • Следите за обработкой исключений и протоколируйте их. Исключения могут содержать конфиденциальную информацию о приложении, которая может использоваться для организации атаки. Обычно, пользователям приложения не нужна детальная техническая информация о произошедшем сбое
  • Аудит и журналирование
    • Определите нештатные ситуации, сравнивая их с обычным поведением приложения При возникновении проблемы важно отследить причину ее появления – без аудита и журналирования сделать это невозможно. Администраторы должны получать уведомления о возникновении нештатных ситуаций и иметь исчерпывающую информацию о причинах ее возникновения

 

Уровни доверия кода

Один из основных принципов написания безопасного кода является выполнение кода с минимально необходимыми привилегиями. Другими словами, код приложения не должен иметь больше привилегий, чем требуется для его нормального выполнения. В Windows Azure есть два уровня Code Access Security (CAS), под которыми выполняется код роли – полное доверие (full trust) и ограниченное доверие (partial trust)

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

  • Запрещено использование неуправляемого кода (native code)
  • Отсутствует доступ к библиотекам и ресурсам на неуправляемом коде
  • Отсутствует доступ к Windows Azure Diagnostics через библиотеку Windows Azure Managed Library
  • Доступ к файловой системе на чтение разрешен для каталога приложения и ряда локальных хранилищ. Доступ к файловой системе на запись и добавление разрешен только для ряда локальных хранилищ
  • Запрещен доступ к реестру
  • Разрешен доступ только к переменным среды TEMP и TMP
  • Запрещен доступ к журналу событий (Event log)

Уровень полного доверия требуется в следующих сценариях:

  • При использовании FastCGI или PHP
  • При миграции «традиционных» веб-сервисов в «облако»
  • При вызове кода роли или создании дочернего процесса (на неуправляемом или управляемом коде)
  • При вызовах библиотек на неуправляемом коде через P/Invoke

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

Идентификация

Как было отмечено выше, аутентификация и авторизация – это два базовых механизма, которые должны использоваться во всех приложениях. Существует два типа управления идентификацией – на основе ролей (role-based identity) и на основе утверждений (claims-based identity).

При использовании идентификации на основе ролей, пользователь предоставляет идентификационные данные (credentials), которые используются приложением для аутентификации пользователя. После этого, пользователь «отображается» на соответствующую группу и получает права, в соответствии с членством в той или иной группе. Идентификация на основе ролей является традиционным способом для аутентификации и авторизации пользователей. К наиболее популярным технологиям авторизации на основе ролей относятся Windows Identity (Domain Join, Kerberos), провайдеры членства (membership providers) ASP.NET и SQL.

При использовании идентификации на основе утверждений аутентификация выполняется вне «границ» приложения. Приложения устанавливают доверительные отношения с сервисами Security Token Services (STSs). Пользователи аутентифицируют себя, используя эти сервисы и получают маркер (token), содержащий коллекцию утверждений – информацию о пользователе. Такой маркер обычно подписан и зашифрован с помощью публичного ключа приложения. Когда приложение получает маркер, пользователь уже аутентифицирован – все, что требуется, это открыть маркер и обработать содержащуюся в нем информацию. Использование идентификации на основе утверждений позволяет реализовать сценарии федерации и делегации аутентификации.

Доверительный уровень может быть установлен даже между различными STS-сервисами – клиент может аутентифицироваться с помощью локального сервиса и послать маркер сервису, которому «доверяет» приложение. Этот сервис использует полученный маркер для создания нового маркера, который уже будет передан приложению. К наиболее популярным технологиям авторизации на основе утверждений относятся Active Directory Federation Services (ADFS) 2.0, Windows Identity Foundation (WIF) и Azure AppFabric Access Control Service (ACS).

В Windows Azure поддерживается как авторизация на основе ролей, так и авторизация на основе запросов.

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

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

Идентификация на уровне утверждений является более простой в реализации и может быть вынесена «вне» приложения. Обычно, при использовании такой идентификации уменьшается число учетных записей, которыми необходимо управлять, а централизация аутентификации упрощает переход на более защищенные методы аутентификации по мере их появления. В состав Windows Azure AppFabric входит масштабируемый, надежный и простой STS-сервис, который может быть использован как в «облачных», так и в традиционных приложениях.

Безопасность данных

В состав Windows Azure входит инфраструктура хранения данных, доступная в виде следующих сервисов - Windows Azure Storage, SQL Azure и Azure AppFabric Cache. Потребители и пользователи будут хранить данные в «облаке» только в том случае, если они будут уверены, что сервисы хранения безопасны и надежны. Поэтому все технологии хранения данных, реализованные в Windows Azure, содержат механизмы для обеспечения контроля доступа и реализуют GFS-политики защищенности пользовательских данных.

Контроль доступа

Сервис Windows Azure Storage поддерживает простую, но эффективную модель контроля доступа. В рамках каждой подписки на Windows Azure можно создать одну или более учетных записей хранилища (Storage Account). Каждая учетная запись хранилища имеет один «секретный» ключ, используемый для контроля доступа ко всем данным. Информация, хранимая в таблицах и очередях Windows Azure Storage, доступна только при аутентификации с использованием данного ключа.

Бинарные объекты (Blobs), с другой стороны, поддерживают расширенные механизмы доступа к данным. Например, информация, хранимая в бинарных объектах, может предназначаться для общего доступа – это могут графические изображения или видеоматериалы, обращение к которым осуществляется прямо из браузера. Контейнеры бинарных объектов могут быть помечены, как "public", что делает их содержимое доступным без необходимости в использовании «секретного» ключа.

В тех сценариях, где необходимо ограничить доступ к содержимому бинарных объектов, эти объекты могут быть доступны либо ограниченное время, либо требовать для доступа к ним специального набора привилегий, опять же, без необходимости в использовании «секретного» ключа. В этих случаях предоставляется возможность создания Shared Access Signature (SAS) – специального варианта URL для доступа к бинарному объекту, который содержит информацию о способах доступа – времени доступности объекта или требуемых привилегиях. Такие URL подписываются с помощью ключа учетной записи хранилища и распространяются только среди пользователей, которым предназначено содержимое бинарных объектов. В доступ к бинарному объекту через «обычный» URL будет отказано, но с использованием SAS его содержимое будет доступно в течение заданного периода. При необходимости усиления уровня защиты следует создать ссылку из Shared Access Signature (SAS) на политику доступа к контейнеру - Container-Level Access Policy. Эта политика может быть модифицирована или отключена, что позволяет более гибко контролировать выданные разрешения на доступ к бинарным объектам.

Целостность данных, доступность и надежность

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

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

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

Криптография

Шифрование данных, находящихся в хранилище или во время их пересылки может использоваться потребителями Windows Azure для обеспечения дополнительной конфиденциальности и целостности данных.

В настоящий момент на уровне платформы шифрование для Windows Azure Storage или SQL Azure не реализовано. Данные, располагаемые в Windows Azure Storage, хранятся в «открытом» виде и не существует опции для их встроенного шифрования – только путем написания дополнительного кода, выполняющего эту операцию. В состав .NET Framework входит набор программных интерфейсов, позволяющих использовать различные алгоритмы шифрования для данных, хранимых в Windows Azure Storage. В настоящий момент SQL Azure не поддерживает механизм Transparent Data Encryption (TDE), доступный в Microsoft SQL Server.

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

Таким образом, до тех пор, пока сервис использует необходимый уровень защиты транспорта (например., SSL), единственным способом получения доступа к данным для злоумышленников является получение информации об учетной записи Windows Live ID, используемой в рамках подписки или сертификате управления, используемого для администрирования сервисов.

Шифрование ценно в тех сценариях, если вы обращаетесь к данным, расположенным в хранилище Windows Azure, из приложений, работающих вне инфраструктуры Azure. В этом случае может потребоваться использование частных AES-ключей, известных только конкретному пользователю. Такие ключи могут быть сгенерированы на компьютере пользователя или где-то в рамках локальной инфраструктуры. Зашифрованные данные загружаются в хранилище Windows Azure. Расшифровка данных доступна только пользователям, у которых есть необходимый ключ – это ключ можно хранить в пользовательском профиле используя программные интерфейсы DPAPI. Клиентское приложение, обращающееся к хранилищу Windows Azure напрямую, не предоставляя соответствующие ключи, не сможет расшифровать хранящиеся данные.

Заключение

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

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

/АФ