#windows #security #azure #cloud #copy-protection
#Windows #Безопасность #azure #облако #защита от копирования
Вопрос:
Мне нужно перенести огромное приложение на Windows Azure. Приложение зависит от сторонней библиотеки, для которой требуется ключ активации, хранящийся в специальном двоичном файле в файловой системе экземпляра роли.
Очевидно, что этот ключ должен быть либо включен в пакет роли, либо сохранен где-то, где роль может его извлечь. Ключ активации не будет привязан к компьютеру (поскольку я понятия не имею, где именно в облаке будет выполняться роль), поэтому любой может использовать его, чтобы заставить копию этой библиотеки работать.
Поскольку роли Azure выполняются где-то вне нашего контроля, я чувствую себя несколько параноидально из-за того, что ключ был украден и стал широко доступным.
Как мне оценить, насколько вероятно, что двоичный файл, включенный в роль Azure, будет украден? Как мне снизить такие риски?
Комментарии:
1. Вы читали технический документ Microsoft по этому вопросу: blogs.msdn.com/b/windowsazure/archive/2010/08/10 / …
2. @Simon Mourier: Я прочитаю это, спасибо.
3. Кто, как вы беспокоитесь, украдет ваши роли? Например, Microsoft, злоумышленники, ваша оперативная группа и т.д.?
4. @Igor Dvorkin: Ну, конечно, не Microsoft — у них есть полный доступ ко всем файлам. Я беспокоюсь о какой-то третьей стороне.
Ответ №1:
Задавая подобные вопросы, вам нужно различать злоумышленников:
- A2) Мошеннический интернет-хакер
- A3) Разработчик в вашей организации
- A4) Человек в вашей организации, который выполняет развертывания
Двоичные файлы вашей роли недоступны для A2, однако они очень доступны для A3 и A4.
Как упоминалось в другом ответе, вы можете хранить свои секреты в файле конфигурации роли. Тем не менее, эти секреты по-прежнему доступны для A4 (любого, у кого есть доступ к порталу).
Для защиты от A4 вы хотите зашифровать секреты в файле конфигурации роли ключом, которого нет в двоичных файлах роли или конфигурации роли. Затем в двоичных файлах вашей роли вы расшифровываете зашифрованный параметр роли с помощью ключа дешифрования.
Ключом для шифрования секретов является сертификат, который Azure SDK установит для вас. Вы можете найти сообщение о настройке сертификатов для azure здесь.
вкратце, для секретов, которые вам нужно защитить от людей в вашей организации, которые выполняют развертывания / имеют доступ к вашим файлам конфигурации, вы делаете следующее:
Попросите доверенную сторону выполнить следующее:
- Сгенерируйте сертификат / закрытый ключ
- Зашифруйте секреты с помощью сертификата и сохраните зашифрованные параметры в файлах конфигурации
- Загрузите сертификат / закрытый ключ в свою службу.
Затем измените свой сервис на:
- Пусть модель service установит сертификат / PrivateKey
- Запустите свое приложение, загрузите закрытый ключ для расшифровки секретов
- Пусть ваше приложение загрузит зашифрованные параметры из конфигурации роли и расшифрует их с помощью закрытого ключа.
Ответ №2:
Что касается безопасности, если ваша команда не обладает исключительными способностями в этой области, по умолчанию всегда обновляемая Azure OS, вероятно, намного безопаснее любого самостоятельно настроенного хоста. По крайней мере, так мы (она же моя компания, Lokad) оцениваем ситуацию через два года после полной миграции на Windows Azure по сравнению с нашей предыдущей ситуацией с самостоятельным размещением.
Тогда, если у вас есть учетные данные, такие как лицензионные ключи, то наиболее логичным местом для их размещения является файл конфигурации роли, а не двоичные файлы роли. Вы, естественно, можете повторно создать специальный файл в виртуальной машине по мере необходимости, но таким образом вы не распространяете свои учетные данные повсюду при архивировании своих двоичных версий.