Полевое устройство, TLS и VPN: какая граница что защищает

Полевое устройство открывает соединение со службой, и вопрос проектирования приходит как выбор между VPN и TLS. Эта рамка неверна, потому что оба выполняют разную работу. TLS аутентифицирует конечную точку приложения и защищает разговор; а VPN управляет доступностью и защищает пакеты между узлами. Пройдите соединение от устройства наружу, и у каждого уровня есть свой ответ.

Если вы не можете сказать, где завершается TLS, вы не можете сказать, чему приложение действительно доверяет.

Найдите, где TLS на самом деле завершается

Начните с приложения устройства и пройдите соединение до процесса, который завершает рукопожатие. Если прокси завершает TLS перед мейнфреймом, защищённый путь заканчивается на прокси. Оставшемуся переходу нужна собственная документированная защита.

Назвать это сквозным по предположению — именно так обзор проекта утверждает пробел. Нарисуйте точку завершения и якорь доверия на одной схеме.

TLS передаёт запросы и ответы в обе стороны, поэтому двунаправленному приложению по своей природе не нужен VPN вместо TLS. Верно и обратное: развёртыванию может по-прежнему требоваться VPN для других протоколов на том же устройстве.

Решите, что устройство должно аутентифицировать

Настройте проверку идентичности сервера и предполагаемые корни доверия. Если каждое устройство должно доказать собственную идентичность, выберите поддерживаемую модель аутентификации клиента и зарегистрируйте отдельные учётные данные для каждого устройства. Общие учётные данные превращают одно украденное устройство в проблему всего парка.

Спланируйте защиту ключей, продление, отзыв и восстановление до отправки. Устройство в поле, которое нельзя зарегистрировать заново после неудачного продления, превращается в выезд на место, и эта стоимость формирует проект сильнее, чем рукопожатие.

Используйте поддерживаемую библиотеку и актуальные рекомендации. Современные рекомендации по развёртыванию TLS запрещают согласование TLS 1.0 и 1.1, а упоминание TLSv1 в старой заметке о проектировании не является требованием.

Закрывайтесь при неудачном рукопожатии

Неудачное рукопожатие или проверка идентичности не должны молча возвращаться к исходному протоколу открытого текста. Этот откат — уязвимость, которую работа с TLS должна была закрыть. Сделайте сбой видимым для оператора устройства и для службы и требуйте защищённый канал для чувствительных операций. Затем пусть авторизация приложения решает, что может делать аутентифицированное устройство.

Определите время жизни соединения, кадрирование, тайм-ауты и поведение при повторе как часть контракта. Шифрование не делает повторную команду безопасной, а повтор после неопределённой предыдущей операции требует ответа на уровне приложения.

Запишите правило отката. «Он переподключается без TLS, если рукопожатие не удалось» — это проектное решение, и оно должно быть явным.

Дайте VPN только ту работу, которую он может выполнить

VPN может ограничить доступность и защитить пакеты до своего узла. TLS защищает отношение приложения к выбранной конечной точке. Их точки завершения могут различаться, и ни одна из них не защищает хранимые данные конечной точки или административный доступ.

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