2015-07-20 3 views
0

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

Я считал, что шифрование ключевой пары, но похоже, что это не принесло бы пользы, поскольку ключ шифрования должен был бы храниться в клиентском коде, который отображается в Javascript. Я не могу придумать другого способа защитить keypair от тех, кто просто может использовать инструменты Chrome dev.

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

спасибо.

+0

Можете ли вы объяснить сценарий? что вы имеете в виду частного KeyPair комбо/подписанную URL-адреса? - обеспечить простой сценарий и то, что вы после –

+1

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

+0

@RoyiNamir: пара открытого и закрытого ключей - это файлы PEM. Основной предпосылкой подписанных URL-адресов Cloudfront является то, что вы создаете строку подписи, которая описывает вашу политику доступа, хеширует ее с помощью закрытого ключа RSA и проверяет ее с помощью открытого ключа. Эта подпись затем добавляется к URL и проверена в CloudFront. – aeskreis

ответ

0

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

Вам нужно будет подписать свои URL-адреса на сервере, а не в браузере.

Самый безопасный способ защитить ваш секретный ключ - это аппаратный модуль безопасности, но они не дешевые.

Следующим лучшим способом является защита его с помощью элементов управления доступом на вашем сервере.

+0

Простите меня, если это глупый вопрос, но не мог пользователь просто посмотреть на запросы, сделанные на вкладке «Сеть» инструментов Chrome dev, посмотреть, как мы получаем подписанные URL-адреса с сервера и просто реплицируем процесс? Например, если я делаю конечную точку, которая принимает URI и возвращает подписанный URL-адрес, как я могу запретить кому-либо удалять этот API для получения подписанного URL-адреса? Простите мое невежество, считает меня послушником безопасности. – aeskreis

+0

Я играл со своими подписанными URL-адресами раньше. Походившего недолговечно, IP-адрес конкретный был путем. Как не знак (ваш ключ, реальный URL + IP-адрес клиента + действует до времени). Таким образом, URL-адрес действителен только с этого IP-адреса в течение нескольких минут. –

+0

Правильно, проблема в том, что мое приложение является общедоступным, поэтому URL-адреса, специфичные для IP-адресов, не будут работать. Поэтому серверное решение не является более безопасным. Он будет защищать мой закрытый ключ, но он не будет препятствовать тому, чтобы пользователь мог создавать подписанные URL без нашего разрешения (на самом деле это упростит, так как им даже не нужно беспокоиться о том, как подписанный URL-адрес вместе взятые, так как это все абстрагируется от сервера). – aeskreis

Смежные вопросы