Cassandra VPN-en át: külön hozzáférés az ügyfeleknek és a csomópontoknak

A Cassandra-telepítésnek nincs egyetlen egyetemes adatbázis-hálózata. Az alkalmazások az ügyfélszolgálattal beszélnek, a fürt tagjai egymással beszélnek, az üzemeltetők pedig adminisztratív felületeket használnak, és ennek a három közönségnek nem kellene egymás elérhetőségét örökölnie. A VPN-hez hasonló privát útvonal jó kiindulópont, de nem az adatbázis felhasználói identitása, és nem a titkosítási szabályzata. Kezelje a kapcsolódási döntést és az engedélyezési döntést két külön felülvizsgálatként.

A három közönség mindegyike saját választ kap, és az alábbi szakaszok a kitettség sorrendjében tárgyalják őket.

Három közönség, három döntés

Határozza meg, mire van valójában szüksége az egyes csoportoknak, mielőtt bármelyik szabályhoz nyúlna. Az ügyfeleknek az ügyfél-figyelőre és arra elegendő információra van szükségük, hogy elérjék minden csomópontot, amelyet kaphatnak, a társcsomópontoknak egymásra van szükségük a csomópontok közötti porton, az üzemeltetőknek pedig a felügyeleti felületre ahhoz, amit a runbook valóban előír. Három lista, három közönség, három bizalmi szint.

A gyakori hiba egyetlen lapos privát szegmenst építeni, és feltételezni, hogy a VPN határa elvégzi a többit. Ezen belül az ügyfélporthoz elérő alkalmazás általában a csomópontok közötti portot is eléri, és az üzemeltető adminisztratív eszközei gyakran ugyanazon az ugró gazdagépen ülnek, mint az alkalmazás. Ezek összelapítása azt jelenti, hogy egy feltört alkalmazás-identitásnak már nagyobb a hatóköre, mint a saját lekérdezéseinek. Rajzolja fel a három közönséget három sorként a tervezési dokumentumban, mindegyiket azzal a szabállyal, amely engedi, és a rések láthatóvá válnak, mielőtt bárki megépíti őket.

Amire az ügyfeleknek szükségük van, és semmi több

Engedje, hogy a szándékolt alkalmazásforrások elérjék az ügyfélvégpontokat a telepített verzióhoz, és tartsa a nem kapcsolódó fürt- és felügyeleti szolgáltatásokat e hatókörön kívül. Ezután ellenőrizze, hogyan fedezi fel az illesztőprogram a csomópontokat. Egy elérhető kezdeti kapcsolódási pont nem bizonyítja, hogy minden csomópont-cím, amelyet az illesztőprogram később kiválaszt, elérhető abból az ügyfélkörnyezetből, mert az illesztőprogram társakat kér a fürttől, majd azokhoz a címekhez kapcsolódik, amelyeket a fürt hirdet.

Ezért egyetlen privát cím-eltérés hozza létre az ismerős mintát: sikeres első kapcsolat, majd időtúllépések. A hirdetett címeket és az ügyfél-útválasztást szándékosan állítsa be; a teljes fürt internetre publikálása egyetlen eltérés javításáért útválasztási hibát cserél olyan kitettségre, amelyet nem lehet visszavonni.

Tartsa meg az alkalmazás adatbázis-hitelesítését és szerepkör-engedélyeit is. Egy megosztott, lefordított VPN-cím sok felhasználót vagy szolgáltatást képviselhet, ezért soha nem helyettesíti a különálló adatbázis-identitásokat.

Titkosítsa külön az ügyfél-csomópont és a csomópontok közötti kapcsolatot

Az Apache biztonsági dokumentációja külön konfigurációként kezeli az ügyfél-csomópont és a csomópontok közötti titkosítást, és az egyik engedélyezése nem engedélyezi a másikat. Ez a megkülönböztetés VPN-en belül is érvényes, mert az alagút a saját szegmensét védi, és nem terjed ki automatikusan az alkalmazásfolyamattól az adatbázis-folyamatig, sem a fürt tagjainak minden párja között.

Egy konfiguráció, amely mindkettőt kifejezetten bekapcsolja, ahelyett hogy sablon-alapértelmezést örökölne, nagyjából így néz ki:

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

Azokon a kiszolgálókonfigurációkon, amelyek opcionális ügyfél-titkosítást engednek, a TLS elfogadása együtt létezhet a titkosítatlan kapcsolatok elfogadásával, ezért a tényleges szabályzatot olvassa, ne a szándékot. Tervezze meg a tanúsítványneveket, a bizalomelosztást és a megújítást azokhoz a végpontokhoz, amelyeket az egyes ügyfelek valóban elérnek; a gazdagépnév IP-címre cserélése az ügyfél identitásellenőrzését változtatja meg, nem csak az útvonalát.

Tartsa a felügyeletet a saját útvonalán

A csomópontok közötti forgalomnak az engedélyezett társak halmazára és saját védelmi szabályzatra van szüksége. Az adminisztratív hozzáférésnek, beleértve a JMX-et ahol használják, külön közönségre és saját hitelesítésre van szüksége. Egy alkalmazás, amelynek engedélyezett rendes lekérdezéseket kiadni, ezáltal nem igényel minden felügyeleti képességet, és a fordított eset rosszabb: az alkalmazásszegmensnek kitett adminisztratív útvonal a legrövidebb út a hibától az újraépítésig. Írja le ezt a két közönséget külön, és nevezze meg a tulajdonosaikat, mert általában különböző csapatok, amelyek szabályai véletlenül összeolvadtak.

Tartsa összehangban a tényleges felhőszabályokat, a gazdagépszabályokat és a figyelő konfigurációját. Egy privát figyelő továbbra is nyitva lehet egy nem szándékos fordítás vagy proxy miatt, és egy széles nyilvános szabály csendesen ott ülhet egy szűk VPN-szabály mellett, amíg valaki egyszerre nem auditálja mindkettőt.

Ahol az üzemeltetőknek valóban szükségük van felügyeleti útvonalra, adjon neki nevesített tulajdonost és rövidebb hitelesítőadat-élettartamot, mint az alkalmazásnak. Ez láthatóan tartja a delegálást, amikor a következő ember örökli a fürtöt.

Mit ígér a tervezés

Érvényesítse mindhárom ígéretet valódi szerepkörökkel, ne csak kapcsolódási tesztekkel. Egy jóváhagyott alkalmazásnak be kell fejeznie az engedélyezett munkáját és semmi többet, egy kizárt forrásnak el kell buknia az ügyfél-belépésnél, és egy alkalmazás-identitást el kell utasítani a fenntartott adminisztratív útvonalakon. Adja hozzá az ügyfél újracsatlakozását és a csomópontválasztást ugyanahhoz a bevezetési teszthez, mert ott kerülnek felszínre a felderítési hibák.

Fejezze be három mondattal a tervezési dokumentumban: mely ügyfelek kérdezhetnek, mely csomópontok kommunikálhatnak és mely üzemeltetők felügyelhetnek. A VPN mögött lenni hasznos topológiai információ, de nem válasz egyikre sem e három kérdés közül.