Cassandra VPN:n yli: erillinen pääsy asiakkaille ja solmuille

Cassandra-käyttöönotossa ei ole yhtä yleistä tietokantaverkkoa. Sovellukset puhuvat asiakaspalvelun kanssa, klusterin jäsenet puhuvat keskenään ja operaattorit käyttävät hallintaliittymiä, eikä näiden kolmen kohderyhmän pitäisi periä toistensa tavoitettavuutta. Yksityinen polku, kuten VPN, on hyvä lähtökohta, mutta se ei ole tietokannan käyttäjätunniste eikä sen salauskäytäntö. Käsittele yhteyksien päätöstä ja valtuutuksen päätöstä kahtena erillisenä tarkasteluna.

Jokainen kolmesta kohderyhmästä saa oman vastauksensa, ja alla olevat osiot käsittelevät ne altistumisen järjestyksessä.

Kolme kohderyhmää, kolme päätöstä

Selvitä, mitä kukin ryhmä todella tarvitsee, ennen kuin kosket sääntöön. Asiakkaat tarvitsevat asiakaskuuntelijan ja tarpeeksi tietoa päästäkseen jokaiseen solmuun, joka heille voidaan antaa, vertaissolmut tarvitsevat toisensa solmujen välisellä portilla, ja operaattorit tarvitsevat hallintaliittymän siihen, mitä runbook todella vaatii. Kolme listaa, kolme kohderyhmää, kolme luottamustasoa.

Yleinen virhe on rakentaa yksi litteä yksityinen segmentti ja olettaa, että VPN:n raja hoitaa loput. Sen sisällä sovellus, joka pääsee asiakasportille, pääsee yleensä myös solmujen väliselle portille, ja operaattorin hallintatyökalut istuvat usein samalla hyppyisäntäkoneella kuin sovellus. Näiden litteäksi yhdistäminen tarkoittaa, että vaarantuneella sovellustunnisteella on jo suurempi ulottuvuus kuin sen omilla kyselyillä. Piirrä kolme kohderyhmää kolmena rivinä suunnitteluasiakirjaan, kukin sen säännön kanssa, joka sen sallii, ja aukot tulevat näkyviksi ennen kuin kukaan rakentaa ne.

Mitä asiakkaat tarvitsevat, eikä mitään muuta

Salli aiottujen sovelluslähteiden päästä asiakkaan päätepisteisiin käyttöönotetun version osalta ja pidä asiaankuulumattomat klusteri- ja hallintapalvelut tuon ulottuvuuden ulkopuolella. Tarkista sitten, miten ajuri löytää solmut. Tavoitettavissa oleva ensimmäinen yhteyspiste ei todista, että jokainen solmuosoite, jonka ajuri valitsee sen jälkeen, on tavoitettavissa kyseisestä asiakaskontekstista, koska ajuri kysyy klusterilta vertaisia ja yhdistää sitten mihin tahansa osoitteisiin, jotka klusteri ilmoittaa.

Siksi yksi yksityisosoitteen poikkeama tuottaa tutun kuvion: onnistunut ensimmäinen yhteys, jota seuraa aikakatkaisut. Määritä ilmoitetut osoitteet ja asiakkaan reititys tarkoituksella; koko klusterin julkaiseminen internetiin yhden poikkeaman korjaamiseksi vaihtaa reititysvirheen altistumiseen, jota et voi perua.

Pidä myös sovelluksen tietokantatodennus ja roolioikeudet paikallaan. Jaettu käännetty VPN-osoite voi edustaa monia käyttäjiä tai palveluja, joten se ei koskaan korvaa erillisiä tietokantatunnisteita.

Salaa asiakas-solmu ja solmujen välinen liikenne erikseen

Apachen suojausta koskeva dokumentaatio käsittelee asiakas-solmu- ja solmujen välistä salausta erillisinä kokoonpanoina, eikä toisen käyttöönotto ota toista käyttöön. Tämä ero pätee myös VPN:n sisällä, koska tunneli suojaa oman segmenttinsä eikä laajene automaattisesti sovellusprosessista tietokantaprosessiin tai jokaisen klusterin jäsenparin välillä.

Kokoonpano, joka kytkee molemmat nimenomaisesti päälle mallin oletusarvon perimisen sijaan, näyttää suunnilleen tältä:

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

Palvelinkokoonpanoissa, jotka sallivat valinnaisen asiakassalauksen, TLS:n hyväksyminen voi esiintyä salaamattomien yhteyksien hyväksymisen rinnalla, joten lue tosiasiallinen käytäntö, älä aikomus. Suunnittele varmenteiden nimet, luottamuksen jakelu ja uusiminen niille päätepisteille, joihin kukin asiakas todella ottaa yhteyttä; isäntänimen korvaaminen IP-osoitteella muuttaa asiakkaan identiteettitarkistusta, ei vain sen reittiä.

Pidä hallinto omalla polullaan

Solmujen välinen liikenne tarvitsee sallitun vertaisjoukon ja oman suojauskäytäntönsä. Hallinnollinen pääsy, mukaan lukien JMX siellä missä sitä käytetään, tarvitsee erillisen kohderyhmän ja oman todentamisensa. Sovellus, jolla on lupa tehdä tavallisia kyselyitä, ei sen vuoksi tarvitse kaikkia hallintakykyjä, ja päinvastoin on pahempaa: sovellussegmentille altistettu hallintopolku on lyhin reitti virheestä uudelleenrakennukseen. Kirjoita nuo kaksi kohderyhmää erikseen ja nimeä niiden omistajat, koska ne ovat yleensä eri tiimejä, joiden säännöt on yhdistetty vahingossa.

Pidä tosiasialliset pilvisäännöt, isäntäsäännöt ja kuuntelijan kokoonpano yhdenmukaisina. Yksityinen kuuntelija voi silti olla altistunut tahattoman käännöksen tai välityspalvelimen kautta, ja laaja julkinen sääntö voi seisoa hiljaa kapean VPN-säännön vieressä, kunnes joku auditoi molemmat yhtä aikaa.

Kun operaattorit todella tarvitsevat hallintapolun, anna sille nimetty omistaja ja lyhyempi tunnistetietojen elinikä kuin sovelluksella. Tämä pitää delegoinnin näkyvänä, kun seuraava henkilö perii klusterin.

Mitä suunnittelu lupaa

Validoi kaikki kolme lupausta oikeilla rooleilla, älä pelkillä yhteystesteillä. Hyväksytyn sovelluksen pitäisi suorittaa sallittu työnsä eikä mitään muuta, poissuljetun lähteen pitäisi epäonnistua asiakkaan sisäänkäynnissä, ja sovellustunniste pitäisi hylätä varatuilla hallintapoluilla. Lisää asiakkaan uudelleenyhdistäminen ja solmun valinta samaan käyttöönoton testiin, koska juuri siellä löytämisen virheet tulevat esiin.

Lopeta kolmeen lauseeseen suunnitteluasiakirjassa: mitkä asiakkaat voivat kysellä, mitkä solmut voivat viestiä ja mitkä operaattorit voivat hallita. VPN:n takana oleminen on hyödyllistä topologiatietoa, mutta se ei ole vastaus yhteenkään näistä kolmesta kysymyksestä.