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 — корисна інформація про топологію, але це не відповідь на жодне з тих трьох питань.