Windows Azure. Общие сведения об управлении учетными записями безопасности в Windows Azure

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

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

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

Владение учетной записью

На портале для клиентов интерактивных служб Майкрософт (MOCP) осуществляется все управление учетными записями и биллинг Windows Azure. На портале MOCP можно подписаться на службы Windows Azure, а также дополнительные службы, такие как SQL Azure, и создать новые экземпляры существующих служб (называются подписками).

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

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

Настоятельно рекомендуется создавать отдельные учетные записи для этих ролей. Эти учетные записи независимы от отдельных учетных записей. Другими словами, в параметрах отделов или организации не следует использовать персональную учетную запись Windows Live ID в качестве учетной записи владельца или администратора учетной записи. Вместо этого необходимо создать уникальные учетные записи (например, используя схему именования AO[уникальный идентификатор]@live.com для владельца учетной записи и AA[уникальный идентификатор]@live.com для администраторов учетной записи) с паролями, которыми можно управлять и восстанавливать при необходимости, на централизованном уровне.

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

Рис. 1. Создание размещенной службы в Windows Azure

При создании новой размещенной службы появится запрос на указание имени службы. Также необходимо указать префикс URL и параметры развертывания. Также можно выбрать уже существующий пакет (.cspkg) и файл конфигурации (.cscfg) в среде развертывания, например в Visual Studio (если уже имеются упакованные приложения).

На вкладке «Hosted Services» (Размещенные службы) в левой части портала выберите «User Management» (Управление пользователями). Здесь можно добавить дополнительных администраторов для подписки (см. рис. 2). Это обеспечивает дополнительную гибкость предоставления доступа к администрированию размещенного приложения.

Рис. 2. Добавление к подписке новых администраторов

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

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

Сертификаты служб — это традиционные сертификаты SSL, используемые для защиты связи конечных точек. Если вы когда-либо настраивали функцию безопасности SSL, например для веб-сайта, размещенного на IIS, вам знаком этот тип сертификата. Сертификаты служб используются для рабочих развертываний сред, выпускаемых доверенным корневым центром сертификации (CA). Поэтому они отдельно приобретаются у стороннего поставщика, например VeriSign или DigiCert.

Список доверенных корневых центров сертификации доступен здесь (для Microsoft Windows) и здесь (для Microsoft Windows Phone 7). Имя сертификата SSL должно соответствовать имени домена веб-сайта. Поэтому требуется запись DNS CNAME для сопоставления yourapp.cloudapp.net (имя домена для приложения, предоставленное Windows Azure) с www.yourcompany.com. Для целей обеспечения безопасности нельзя приобрести сопоставление сертификатов с yourapp.cloudapp.net. Только корпорация Майкрософт может выпускать сертификаты для cloudapp.net, хотя для целей разработки можно создавать собственные самоподписывающиеся сертификаты.

Самоподписывающиеся сертификаты должны использоваться только для целей тестирования, поскольку им не будут доверять веб-обозреватели конечных пользователей. Во время тестирования вы заметите, что ваш обозреватель укажет на недоверенный сертификат или на сбой вызовов API, осуществленных с помощью Windows Communications Foundation (WCF). Это не означает, что данный сертификат не работает; ему не доверяет корневой центр сертификации. В обозревателе это является допустимым неудобством при тестировании, но с этим не должны сталкиваться конечные пользователи.

Для тестирования вызовов API необходимо добавить код для обхода проверки сертификата или корневой сертификат ЦС самоподписывающегося сертификата службы к хранилищу сертификатов доверенных корневых центров сертификации, используя MMC управления сертификатами, пакетные команды или код. Дэвид Хардин (David Hardin) из корпорации Майкрософт подробно описал эту проблему в данной записи блога.

Необходимо указать сертификаты служб Windows Azure в формате PFX (Personal Information Exchange). Для создания собственного самозаверяющегося сертификата службы с паролем по умолчанию «password» (его можно изменить в последней команде в соответствие с собственными предпочтениями) откройте командую строку Visual Studio и выполните следующие команды:

makecert -r -pe -n "CN=yourapp.cloudapp.net" -b 01/01/2000 -e 01/01/2036 -eku 1.3.6.1.5.5.7.3.1 -ss my -sky exchange
-sp "Microsoft RSA SChannel Cryptographic Provider" -sy 12 -sv SSLDevCert.pvk SSLDevCert.cer

del SSLDevCert.pfx

pvk2pfx -pvk SSLDevCert.pvk -spc SSLDevCert.cer -pfx SSLDevCert.pfx -po password

Сертификаты служб SSL можно загрузить на вкладке «Hosted Services» (Размещенные службы) портала управления Windows Azure, выбрав «Add Certificate» (Добавить сертификат) и указав пароль (см. рис. 3).

Рис. 3. Добавление сертификата службы в Windows Azure

Сертификаты управления — другой тип сертификатов, использующихся Windows Azure. Средства Windows Azure для Microsoft Visual Studio используют сертификаты управления для проверки подлинности разработчиков для развертывания Windows Azure. Средство командной строки CSUpload также использует сертификаты управления для развертывания ролей образов виртуальных машин, выполняющих запросы Windows Azure Service Management REST API.

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

Сертификаты управления Windows Azure должны быть указаны в формате X.509 (.cer). Для создания собственных самоподписывающихся сертификатов управления откройте командную строку Visual Studio и выполните следующую команду:

makecert -r -pe -a sha1 -n "CN=Windows Azure Authentication Certificate" -ss my -len 2048 -sp "Microsoft Enhanced RSA and AES Cryptographic Provider" -sy 24 ManagementApiCert.cer

Загрузите сертификаты управления, используя платформу управления Windows Azure, выбрав «Management Certificates» (Сертификаты управления) на левой панели, а затем «Add Certificate» (Добавить сертификат) (см. рис. 4). Подробные сведения о создании собственных сертификатов для Windows Azure приведены в статье библиотеки MSDN «Создание сертификата для роли».

Рис. 4. Добавление сертификата управления в Windows Azure

Переходы сотрудников

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

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

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

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

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

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

Материалы по теме

• Разгоняя туман вокруг облачных вычислений
• Microsoft, NSF открывает Azure для исследователей
• Можем ли мы защитить облачные вычисления? Позволительно ли отсутствие защиты?