Cassandra през VPN: отделен достъп за клиенти и възли

Едно внедряване на Cassandra не разполага с една универсална мрежа за базата данни. Приложенията говорят с клиентската услуга, членовете на клъстера говорят помежду си, а операторите използват административни интерфейси, и тези три аудитории не бива да наследяват достъпността една от друга. Частен път като VPN е добра отправна точка, но той не е идентичността на потребителя на базата данни и не е нейната политика за криптиране. Разглеждайте решението за свързаност и решението за оторизация като два отделни прегледа.

Всяка от трите аудитории получава свой отговор, а разделите по-долу ги разглеждат по реда на излагането.

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

Определете какво всъщност е нужно на всяка група, преди да пипате правило. На клиентите им трябва клиентският слушател и достатъчно информация, за да достигнат до всеки възел, който може да им бъде даден, на партньорските възли им трябва връзка помежду им на междувъзловия порт, а на операторите им трябва интерфейсът за управление за това, което действително изисква runbook. Три списъка, три аудитории, три нива на доверие.

Честата грешка е да се изгради един плосък частен сегмент и да се предположи, че границата на VPN прави останалото. Вътре в него приложение, което достига клиентския порт, обикновено достига и междувъзловия порт, а административните инструменти на оператора често стоят на същия междинен хост като приложението. Спускането им заедно означава, че компрометирана идентичност на приложение вече има по-голям обхват от собствените си заявки. Начертайте трите аудитории като три реда в проектния документ, всеки с правилото, което го разрешава, и пропуските стават видими, преди някой да ги изгради.

Какво им трябва на клиентите и нищо повече

Разрешете на предназначените източници на приложения достъп до клиентските крайни точки за внедрената версия и дръжте несвързаните клъстерни и управленски услуги извън този обхват. След това проверете как драйверът открива възлите. Достъпна начална точка за контакт не доказва, че всеки адрес на възел, който драйверът избере след това, е достъпен от този клиентски контекст, защото драйверът пита клъстера за партньори и след това се свързва с каквито адреси клъстерът обяви.

Затова едно несъответствие на частен адрес произвежда познатия модел: успешна първа връзка, последвана от изтичания. Конфигурирайте обявените адреси и клиентското маршрутизиране съзнателно; публикуването на целия клъстер в интернет, за да поправите едно несъответствие, разменя грешка в маршрутизирането срещу излагане, което не можете да върнете назад.

Запазете също удостоверяването за базата данни на приложението и разрешенията на ролите. Споделен преведен адрес на VPN може да представлява много потребители или услуги, затова той никога не заменя отделните идентичности в базата данни.

Криптирайте отделно клиент-към-възел и междувъзловото

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

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

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

При сървърни конфигурации, които позволяват незадължително клиентско криптиране, приемането на TLS може да съществува заедно с приемането на нешифровани връзки, затова четете действащата политика, а не намерението. Планирайте имената на сертификатите, разпространението на доверие и подновяването за крайните точки, с които всеки клиент действително се свързва; замяната на име на хост с IP адрес променя проверката на идентичността на клиента, а не само маршрута му.

Дръжте администрирането на собствен път

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

Дръжте действащите правила в облака, правилата на хостовете и конфигурацията на слушателя съгласувани. Частният слушател все още може да бъде изложен чрез неволно преобразуване или прокси, а широко публично правило може да стои тихо до тясно правило за VPN, докато някой не одитира двете наведнъж.

Където операторите наистина се нуждаят от път за управление, дайте му именуван собственик и по-кратък срок на живот на идентификационните данни от този на приложението. Това запазва делегирането видимо, когато следващият човек наследи клъстера.

Какво обещава дизайнът

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

Завършете с три изречения в проектния документ: кои клиенти могат да правят заявки, кои възли могат да комуникират и кои оператори могат да администрират. Да си зад VPN е полезна информация за топологията, но не е отговор на нито един от тези три въпроса.