Ключ безопасности между двумя серверами - PullRequest
1 голос
/ 30 марта 2011

Я пишу приложение с двумя слоями, сидя на двух отдельных серверах:

Уровень представления (где пользователь загружает / выбирает изображения)

Уровень приложения (где обрабатываются изображения)

Может быть несколько разных серверов презентаций, которые обращаются к серверу приложений.

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

Рекомендуется ли создавать ключ между двумя серверами, поэтому, когда я выполняю запрос GET / POST на уровне приложенийиз уровня Presentation он знает, что это правильный запрос от этого сервера, а не из внешнего мира?

Я думаю, я мог бы сделать что-то грубое, как

/request/?key=xyz123

и проверить, что key == xyz123на другом сервере, но это не кажется мне слишком безопасным.

Если бы оба сервера имели хеш-код шифрования, я мог бы сделать что-то вроде

encrypt(time()); на уровне представления, а затем decrypt(time()); на другом сервере и проверить, что это было в течение 20 секунд послепросьба или что-то в этом роде.

Просто интересно, каковы лучшие практики для этого?

Спасибо!

Ответы [ 4 ]

2 голосов
/ 30 марта 2011

Настройте HTTPS на своих серверах и попросите их аутентифицироваться друг с другом, используя SSL-сертификаты, которые вы создали для этой конкретной цели. Есть причина, по которой все так поступают.

1 голос
/ 30 марта 2011

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

0 голосов
/ 30 марта 2011

(SSL вызывает у меня головную боль: p, вот простой метод, я думаю)

Простой способ - установить пароль, который вы выбираете, например: «myLongPasswordWitheWeirdChracters», затем зашифровать его на основе этого пароля и отправить его с данными «Post» или «Get» (с другими вещами), затем в другой сервер, первое, что вы делаете, это расшифровываете его с помощью того же длинного пароля, поскольку только два ваших сервера знают этот пароль, они единственные, кто может расшифровать сообщения, зашифрованные с помощью этого пароля или ключа.

Хорошо, позвольте мне дать вам реальные вещи, теория скучна: p)

Используйте этот класс для шифрования: http://www.phpclasses.org/browse/file/17234.html Как это:

// Создать ключ, очень длинный

$myKey = "a big key with weird charcters àçèàçè'("; 

// Отдаем его классу

$crypter = new(2, $myKey);

// Теперь с $ crypter вы можете зашифровать все

$cryptedData = $crypter->encrypt($aDataInDB);

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

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

Надеюсь, это поможет:)

0 голосов
/ 30 марта 2011

шифровать (время ());на уровне представления, а затем расшифровать (время ());на другом сервере и проверьте, что это было в течение 20 секунд после запроса или чего-то в этом роде.

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

Используя только время запроса, вам придется использовать обратимое шифрование, а не просто хэши, и вы только уменьшите окно для атак - вы не обращались к MITM или подделкам запросов.

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