Cassandra преко VPN-а: одвојен приступ за клијенте и чворове

Cassandra имплементација нема једну универзалну мрежу базе података. Апликације разговарају са клијентским сервисом, чланови кластера разговарају међусобно, а оператери користе административне интерфејсе, и те три публике не би требало да наслеђују доступност једна од друге. Приватни пут као што је VPN је добра почетна тачка, али није кориснички идентитет базе података нити њена политика шифровања. Третирајте одлуку о повезаности и одлуку о ауторизацији као два одвојена прегледа.

Свака од три публике добија сопствени одговор, а одељци испод их обрађују редом по изложености.

Три публике, три одлуке

Идентификујте шта свака група заиста треба пре него што дирнете правило. Клијентима треба клијентски слушалац и довољно информација да дохвате сваки чвор који им може бити додељен, партнерским чворовима треба један други на internode порту, а оператерима треба интерфејс за управљање за оно што runbook заиста захтева. Три листе, три публике, три нивоа поверења.

Уобичајена грешка је изградити један раван приватни сегмент и претпоставити да VPN граница ради остало. Унутар њега, апликација која дохвата клијентски порт обично дохвата и internode порт, а оператерови административни алати често стоје на истом jump host-у као апликација. Спљоштавање тога заједно значи да компромитовани идентитет апликације већ има већи домашај од сопствених упита. Нацртајте три публике као три реда у пројектном документу, сваки са правилом које га дозвољава, и празнине постају видљиве пре него што их ико изгради.

Шта клијентима треба, и ништа више

Дозволите предвиђеним изворима апликације приступ клијентским крајњим тачкама за распоређену верзију, и држите неповезане кластер и управљачке сервисе изван тог домашаја. Затим проверите како драјвер открива чворове. Доступна почетна контакт тачка не доказује да је свака адреса чвора коју драјвер касније изабере доступна из тог клијентског контекста, јер драјвер пита кластер за партнере и затим се повезује на адресе које кластер оглашава.

Зато једно несагласје приватних адреса даје познат образац: успешна прва веза праћена истеклим временима. Конфигуришите оглашене адресе и клијентско рутирање намерно; објављивање целог кластера на интернету да бисте поправили једно несагласје мења грешку рутирања за изложеност коју не можете повући.

Задржите и аутентификацију базе података и дозволе улога апликације. Заједничка преведена VPN адреса може представљати многе кориснике или сервисе, па никада не замењује засебне идентитете базе података.

Шифрујте одвојено клијент-чвор и internode

Apache безбедносна документација третира шифровање клијент-чвор и internode као одвојене конфигурације, а укључивање једне не укључује другу. Та разлика и даље важи унутар VPN-а, јер тунел штити сопствени сегмент и не простире се аутоматски од процеса апликације до процеса базе података нити између сваког пара чланова кластера.

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

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

На серверским конфигурацијама које дозвољавају опционо клијентско шифровање, прихватање TLS-а може коегзистирати са прихватањем нешифрованих веза, па читајте ефективну политику, а не намеру. Планирајте имена сертификата, дистрибуцију поверења и обнављање за крајње тачке које сваки клијент заиста контактира; замена имена хоста IP адресом мења проверу идентитета клијента, не само његову руту.

Држите администрацију на сопственом путу

Internode саобраћај треба дозвољени скуп партнера и сопствену политику заштите. Административни приступ, укључујући JMX где се користи, треба одвојену публику и сопствену аутентификацију. Апликацији дозвољеној да шаље обичне упите није тиме потребна свака управљачка могућност, а обрнуто је горе: административни пут изложен апликативном сегменту најкраћа је рута од грешке до поновне изградње. Запишите те две публике одвојено и наведите њихове власнике, јер су то обично различити тимови чија су правила случајно спојена.

Држите усклађена ефективна cloud правила, правила хоста и конфигурацију слушаоца. Приватни слушалац и даље може бити изложен кроз ненамерно превођење или прокси, а широко јавно правило може тихо стајати поред уског VPN правила док неко не провери оба одједном.

Тамо где оператерима заиста треба управљачки пут, дајте му именованог власника и краћи животни век акредитива од апликацијиног. То одржава делегирање видљивим када следећа особа наследи кластер.

Шта дизајн обећава

Валидирајте сва три обећања стварним улогама, а не само тестовима повезаности. Одобрена апликација треба да заврши дозвољени посао и ништа више, искључени извор треба да не успе на клијентском улазу, а идентитет апликације треба да буде одбијен на резервисаним административним путевима. Додајте поновно повезивање клијента и избор чворова у исти тест увођења, јер се ту појављују грешке откривања.

Завршите са три реченице у пројектном документу: који клијенти могу да упитују, који чворови могу да комуницирају и који оператери могу да администрирају. Бити иза VPN-а је корисна информација о топологији, али није одговор на ниједно од тих три питања.