Вопрос или проблема
Я использую HAProxy для выполнения завершения взаимной TLS для моего API.
У HAProxy включен взаимный TLS с требованием проверки и файлом cert-auth, чтобы ограничить доступ к службе Apache, которая проксирует мой API.
Я хочу разрешить доступ только двум конкретным клиентам через HAProxy. Оба этих клиента использовали общие корневые/промежуточные ЦП для подписания своих сертификатов.
Я знаю, что HAProxy не позволяет применять строгую проверку глубины (3), поэтому я не могу просто добавить полную цепочку каждого клиента в мой файл cert-auth, так как HAProxy все равно будет проверять любой сертификат, подписанный одним из ЦП.
Я считаю, что у меня есть три (основных) варианта:
- Использовать файл cert-auth, который содержит только два конкретных leaf-сертификата, и полагаться на HAProxy, чтобы он отклонил все остальные. Это означает, что мой доверенный корень — это сам leaf, и я игнорирую реальные промежуточные/корневые органы.
или
- Использовать какую-либо форму ACL в HAProxy для проверки, совпадает ли имя или серийный номер представленного сертификата с именем/серийным номером любого из двух сертификатов, которым я доверяю, в сочетании с корневыми/промежуточными сертификатами в файле cert-auth.
или
- Удалить серийный номер/cn/sha1 представленного сертификата и добавить его как заголовок при пересылке в Apache, а затем провести аналогичную проверку, как в варианте 2, в upstream-сервисе Apache.
Я хотел бы использовать вариант 1, хотя не уверен, что он так же безопасен, как два других. Я понимаю, что, пока я доверяю клиентам предоставлять мне их правильные leaf-сертификаты, использование только этих leaf-сертификатов (sic) напрямую в моем файле cert-auth HAProxy не должно быть менее безопасным, чем доверие корневому ЦП и проверка CN сертификата либо в ACL, либо в Apache. Первоначальная TLS-ручка докажет, что представленный сертификат принадлежит клиенту, поэтому не должно быть риска, что третья сторона предоставит правильный сертификат, добираясь до этапа проверки HAProxy.
Основная причина, по которой я запутался, в том, что я видел похожие вопросы, заданные в других местах, и ответ всегда склонен быть какой-то разновидностью “используйте ACL” или “передайте CN как заголовок и проверьте его в приложении”.
Кратко: Вношу ли я какой-либо риск безопасности, добавляя в файл CA HAProxy определенные сертификаты вместо самих подписывающих ЦП?
Причина, по которой я предпочел бы использовать файл CA вместо правила ACL, заключается в том, что это упрощает долгосрочную поддержку (необходимо просто заменить файл cert-auth вместо обновления конфигурации haproxy каждый год).
Вместо того чтобы реализовать доверие к самому узлу leaf, я решил использовать частичное решение, предоставленное Sartsj в своем аналогичном вопросе о проверке клиентов в HAProxy.
Ответ или решение
Как настроить HAProxy для доверия только к конкретным клиентским сертификатам при взаимной аутентификации
Если вы используете HAProxy для выполнения взаимной TLS-терминации, важно правильно настроить доверие к клиентским сертификатам, чтобы обеспечить безопасность вашего API. В этой статье мы рассмотрим, как можно настроить HAProxy так, чтобы он принимал только два конкретных клиентских сертификата, подписанных общими корневыми или промежуточными центрами сертификации (ЦС).
Текущая ситуация
Вы уже задали базовую конфигурацию с использованием файла cert-auth, который определяет доверенные сертификаты. При этом вы используете параметр verify required, что означает, что HAProxy будет требовать наличия клиентского сертификата. Однако, учитывая, что HAProxy не может непосредственно ограничивать глубину проверки сертификатов, важно найти подходящий способ ограничить доступ.
Опции настройки
Вы предложили три основных варианта настройки, каждый из которых имеет свои плюсы и минусы. Рассмотрим их подробнее:
-
Использование файла cert-auth только с конкретными клиентскими сертификатами:
В этом подходе вы включаете в файлcert-authтолько два конкретных сертификата клиентов, которые хотите разрешить. Это возможно, но требует от вас строгости в управлении их сертификатами. Если клиентская сторона изменит свой сертификат, вам придется обновить HAProxy с новым сертификатом. Хотя технически это работает, существуют некоторые риски:- Если злоумышленник получит доступ к сертификату, он сможет подключиться.
- На уровне безопасности это может добавить риск, если вам когда-либо придется доверять новым клиентам с теми же ЦС.
-
Использование ACL для проверки имени или серийного номера сертификата:
Этот вариант предполагает использование ACL (Access Control Lists) для проверки не только наличия сертификата, но и его уникальности (серийный номер или CN). Подход достаточно безопасен, так как он позволяет добавить дополнительный уровень проверки. Однако он требует большего объема административной работы, так как вам придется обновлять конфигурацию HAProxy при изменении сертификатов. -
Передача информации о сертификате в заголовках к Apache:
Этот вариант подразумевает, что вы передаете информацию о сертификате (например, CN, номер серийного номера или SHA1) в качестве заголовка в запросах, которые проксируются к вашему серверу Apache. Этот подход также потребует дополнительной настройки и проверки на стороне Apache, что увеличивает сложность всей системы.
Оценка рисков
С точки зрения безопасности, использование файла cert-auth, который включает лишь доверенные клиентские сертификаты, может быть приемлемым, но необходимо учитывать следующие моменты:
- Управление сертификатами: Долгосрочное управление сертификатами может стать вызовом. Вы будете вынуждены поддерживать актуальность этих сертификатов в
cert-authфайле без использования инструментов автоматизации. - Широкий доступ через ЦС: Используя только определенные клиента, вы не сможете доверять другим сертификатам, которые могут быть выданы этим центром сертификации, даже если они будут действительными.
Рекомендации
Если вы уверены в идентификации и управлении клиентами, то использование файла cert-auth с конкретными сертификатами может быть лучшим для вас вариантом с точки зрения простоты. Тем не менее, если вам необходима более высокая степень защиты и вы хотите сохранить гибкость для новых клиентов, рассмотрите возможность реализации второго варианта с использованием ACL.
В любом случае, вне зависимости от выбранного подхода, обязательно следите за актуальностью ваших сертификатов и регулярно проводите аудит систем безопасности.
Заключение
Выбор способа настройки HAProxy для доверия только к двум конкретным клиентским сертификатам зависит от ваших потребностей в безопасности и удобстве управления. Оцените предложенные варианты, учтите свои риски и выберите наиболее подходящий для вашей среды. Надеюсь, это поможет вам более уверенно настроить ваше решение на HAProxy для безопасного доступа к вашему API.