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