Насколько я должен быть параноиком по поводу кражи двоичных файлов приложения Azure? - PullRequest
8 голосов
/ 02 июня 2011

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

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

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

Как оценить, насколько вероятно украсть двоичный файл, который входит в роль Azure? Как мне снизить такие риски?

Ответы [ 2 ]

2 голосов
/ 04 июня 2011

Когда вы задаете такие вопросы, вам нужно различать атакующих:

  • А2) Разбойный интернет-хакер
  • A3) Разработчик в вашей организации
  • A4) Сотрудник вашей организации, выполняющий развертывание

Двоичные файлы вашей роли недоступны для A2, однако они очень доступны для A3 и A4.

Как уже упоминалось в другом ответе, вы можете хранить свои секреты в файле конфигурации ролей. Тем не менее, эти секреты по-прежнему доступны для A4 (любой, кто имеет доступ к порталу).

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

Ключом для шифрования секретов является сертификат, который Azure SDK установит для вас. Вы можете найти пост о настройке сертификатов для Azure здесь .

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

Попросите доверенную сторону сделать следующее:

  • Генерация сертификата / закрытого ключа
  • Зашифруйте секреты с помощью сертификата и сохраните зашифрованные настройки в ваших файлах конфигурации
  • Загрузите сертификат / закрытый ключ к себе.

Затем измените ваш сервис на:

  • Пусть сервисная модель установит сертификат / PrivateKey
  • Приложите ваше приложение, загрузите закрытый ключ для расшифровки секретов
  • Пусть ваше приложение загрузит зашифрованные параметры из конфигурации ролей и расшифрует их с помощью закрытого ключа.
2 голосов
/ 02 июня 2011

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

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...