Вопрос или проблема
Если у меня есть кластер, в котором все узлы используют один сертификат и закрытый ключ, считается ли это взаимным TLS? Технически обе стороны в связи имеют сертификат и представляют его друг другу.
Взаимный TLS требует, чтобы обе системы представляли сертификаты и проверяли сертификат партнера в рамках одного соединения.
Если ServerA устанавливает обычное соединение TLS с ServerB, а затем ServerB устанавливает последующее обычное соединение TLS с ServerA, это не будет считаться взаимным TLS; потому что в обоих этих отдельных соединениях клиент не представляет сертификат.
Не имеет смысла делиться сертификатом между узлами, которые взаимодействуют друг с другом. Сертификат не передает никакой полезной информации в этом случае, потому что каждый узел уже знает открытый ключ каждого другого узла – это всегда его собственный ключ.
Существуют два варианта.
Рекомендуемое решение – сгенерировать пару ключей на каждом узле, получить сертификаты, специфичные для узлов, и затем установить классический mTLS. Использование различных ключей резко снижает как риск, так и последствия компрометации ключа, потому что злоумышленнику необходимо атаковать каждый узел индивидуально, и даже если они успешно это сделают, они смогут выдать себя лишь за один узел.
Если вы настаиваете на использовании общего ключа, то используйте TLS-PSK. Сертификаты в этом случае не нужны, потому что пиры могут просто аутентифицироваться с помощью общего ключа. Обратите внимание, что TLS-PSK может и должен по-прежнему комбинироваться с обменом ключами (EC)DHE, чтобы обеспечить передачу секретности.
Ответ или решение
Установка взаимно защищенного TLS (Mutual TLS, mTLS) с использованием общей сертификата — это сложный вопрос, требующий понимания принципов работы TLS и его механизмов аутентификации.
Понимание Mutual TLS
Взаимный TLS подразумевает, что обе стороны в соединении представляют свои сертификаты и проверяют сертификат друг друга в рамках одного соединения. Это означает, что клиент и сервер должны подтверждать друг друга, обеспечивая высокий уровень доверия и безопасности. Если, например, СерверA устанавливает обычное TLS-соединение с СерверомB, и затем СерверB инициирует отдельное TLS-соединение к СерверуA, это не будет считаться взаимным TLS, поскольку в каждом из этих соединений клиент не предоставляет сертификат.
Проблема с общей сертификатом
Использование единого сертификата и закрытого ключа для всех узлов в кластере не подходит для настройки mTLS. Причина в том, что сертификат не несет полезной информации, если каждый узел уже знает открытый ключ каждого другого узла — все узлы фактически используют свой собственный ключ, а не уникальный для них.
Рекомендуемое решение
Наилучший подход заключается в том, чтобы сгенерировать уникальную пару ключей для каждого узла, получить сертификаты, соответствующие этим ключам, и затем настроить классическое mTLS. Использование различных ключей значительно снижает как риск, так и последствия компрометации ключа. В случае, если злоумышленнику удастся взломать один узел, он сможет выдать себя только за этот конкретный узел, а не за весь кластер.
Альтернативный вариант
Если вы настаиваете на использовании общего ключа, то можете рассмотреть использование TLS-PSK (Pre-Shared Key). В этом случае сертификаты не требуются, так как стороны могут аутентифицироваться с помощью общего ключа. Однако важно отметить, что TLS-PSK следует комбинировать с обменом ключами (EC)DHE для обеспечения передачи секретной информации и увеличения безопасности.
Заключение
Таким образом, чтобы реализовать взаимный TLS с надежным уровнем безопасности, вам следует создать уникальные сертификаты для каждого узла. Это значительно укрепит вашу инфраструктуру безопасности. В противном случае, использование общего ключа через TLS-PSK — это вариант, хотя он и не предоставляет всех преимуществ, которые дает mTLS с индивидуальными сертификатами.