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 е корисна тополошка информација, но не е одговор на ниту едно од овие три прашања.