Блог

Я хочу реализовать зашифрованную связь между двумя серверами JAVA, оба находятся под моим контролем. Я имею в виду три архитектуры, и я хочу получить ваше мнение о их плюсах и минусах.

Архитектура 1: Всякий раз, когда я вызываю удаленный метод, я передаю параметры не как обычный текст, а как сериализованный объект зашифрованного текста. Я буду использовать ESAPI-library для этого, но фактическая реализация не имеет значения. Важно то, что объект зашифрованного текста содержит произвольные данные, зашифрованные симметричным ключом, включая MAC для аутентификации. Симметричный ключ доступен в виде предварительно разделяемого секрета на обоих серверах.

Архитектура 2: Меня не волнует шифрование на уровне приложения, но делегирую его транспортному уровню. Это может быть VPN-туннель или какой-либо поддерживаемый вид шифрования между серверами. У меня не слишком много информации о том, что доступно на современном сервере приложений на данный момент. Информация по этому вопросу также приветствуется.

Архитектура 3: Использование javax.rmi.ssl для использования RMI поверх SSL.

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

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

Прежде всего, решения для обеспечения безопасности не являются универсальными. Вы должны оценить угрозы (кто был бы заинтересован в snoping / атаке), риски (что вы потеряете, если злоумышленник преуспеет) и стоимость внедрения и использования.

Во-вторых, решения для обеспечения безопасности обычно не являются эксклюзивными. Вы могли бы реализовать все 3 решения одновременно (связь через VPN вызовов RMI-SSL с зашифрованными параметрами). Проблема может заключаться в стоимости реализации и накладных расходах.

Теперь к рассматриваемому вопросу:

1) Мне это не нравится, потому что:

• Это позволяет тому, кто выполняет snopping, знать, какие методы вызываются, даже если он не знает, какие данные передаются.
• Насколько я знаю, MAC-адреса могут быть подделаны
• Вы должны сохранять контроль над своими серверами сейчас и в будущем, чтобы общий секрет не был обнаружен. Возможно, в следующем месяце один из ваших серверов будет перенесен в другое местоположение / филиал / подразделение, и больше людей начнут иметь к нему доступ. Или, может быть, они развертывают ваши серверы в другом бизнесе без изменения секрета.

2 и 3) более или менее эквивалентны. Однако с помощью 2 вы должны убедиться, что ваши серверы принимают соединения, поступающие только через OpenVPN, а не из других NI. Я не очень хорошо знаю RMI через SSL, но если у него нет какой-либо скрытой уязвимости, все выглядит нормально.

ИМХО, я бы выбрал 3 (стандартный, интегрированный в сервер и более гибкий). 2 — тоже хороший вариант, его проще реализовать, но он требует от вас лучшего контроля над сервером. 1 — это изобретение колеса, где уже есть допустимые параметры, я бы отказался от него.

Архитектура 4: стандартный ввод-вывод сокета через SSL.