Cassandra через VPN: раздельный доступ для клиентов и узлов

Развёртывание Cassandra не имеет одной универсальной сети базы данных. Приложения обращаются к клиентской службе, участники кластера общаются между собой, а операторы используют административные интерфейсы, и эти три аудитории не должны наследовать доступность друг друга. Частный путь, такой как VPN, — хорошая отправная точка, но он не является идентичностью пользователя базы данных и не является её политикой шифрования. Рассматривайте решение о связности и решение об авторизации как два отдельных обзора.

Каждая из трёх аудиторий получает собственный ответ, и разделы ниже рассматривают их в порядке уязвимости.

Три аудитории, три решения

Определите, что каждой группе действительно нужно, прежде чем трогать правило. Клиентам нужен клиентский слушатель и достаточно информации, чтобы добраться до каждого узла, который им могут выдать, узлам-партнёрам нужно видеть друг друга на порту internode, а операторам нужен интерфейс управления для того, что действительно требует runbook. Три списка, три аудитории, три уровня доверия.

Обычная ошибка — построить один плоский приватный сегмент и предположить, что граница VPN сделает остальное. Внутри него приложение, которое достаёт клиентский порт, обычно достаёт и порт internode, а административные инструменты оператора часто стоят на том же хосте перехода, что и приложение. Сведение их вместе означает, что скомпрометированная идентичность приложения уже имеет больше доступа, чем её собственные запросы. Нарисуйте три аудитории как три строки в проектном документе, каждую с разрешающим её правилом, и пробелы станут видны до того, как кто-то их построит.

Что нужно клиентам, и ничего больше

Разрешите предполагаемым источникам приложения доступ к клиентским конечным точкам развёрнутой версии и держите несвязанные службы кластера и управления вне этой зоны. Затем проверьте, как драйвер обнаруживает узлы. Доступная начальная точка контакта не доказывает, что каждый адрес узла, который драйвер выберет потом, доступен из этого клиентского контекста, потому что драйвер спрашивает кластер о партнёрах и затем подключается к адресам, которые кластер объявляет.

Поэтому одно несовпадение приватных адресов даёт знакомую картину: успешное первое подключение, за которым следуют тайм-ауты. Настраивайте объявляемые адреса и клиентскую маршрутизацию осознанно; публикация всего кластера в интернете ради исправления одного несовпадения обменивает ошибку маршрутизации на раскрытие, которое нельзя отменить.

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

Шифруйте отдельно клиент-узел и internode

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

Конфигурация, которая включает оба явно, а не наследует значение шаблона по умолчанию, выглядит примерно так:

client_encryption_options:
  enabled: true
  optional: false
server_encryption_options:
  internode_encryption: all

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

Держите администрирование на отдельном пути

Трафику internode нужен разрешённый набор партнёров и собственная политика защиты. Административный доступ, включая JMX там, где он используется, требует отдельной аудитории и собственной аутентификации. Приложение, которому разрешено отправлять обычные запросы, не нуждается из-за этого в каждой возможности управления, а обратное хуже: административный путь, открытый для сегмента приложений, — это кратчайший путь от ошибки до пересборки. Запишите эти две аудитории отдельно и назовите их владельцев, потому что обычно это разные команды, чьи правила случайно объединили.

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

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

Что обещает проект

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

Завершите тремя предложениями в проектном документе: какие клиенты могут выполнять запросы, какие узлы могут обмениваться данными и какие операторы могут администрировать. Нахождение за VPN — полезная информация о топологии, но это не ответ ни на один из этих трёх вопросов.