Cassandra per VPN: accés separat per a clients i nodes

Un desplegament de Cassandra no té una única xarxa universal de base de dades. Les aplicacions parlen amb el servei de client, els membres del clúster parlen entre ells i els operadors utilitzen interfícies administratives, i aquests tres públics no haurien d'heretar l'abast els uns dels altres. Un camí privat com una VPN és un bon punt de partida, però no és la identitat d'usuari de la base de dades ni és la seva política de xifratge. Tracteu la decisió de connectivitat i la decisió d'autorització com dues revisions separades.

Cadascun dels tres públics rep la seva pròpia resposta, i les seccions següents els tracten per ordre d'exposició.

Tres públics, tres decisions

Identifiqueu què necessita realment cada grup abans de tocar cap regla. Els clients necessiten l'oient de client i prou informació per arribar a cada node que se'ls pugui assignar, els nodes parells es necessiten entre ells al port entre nodes, i els operadors necessiten la interfície de gestió per al que el runbook demana realment. Tres llistes, tres públics, tres nivells de confiança.

L'error habitual és construir un sol segment privat pla i donar per fet que la frontera de la VPN fa la resta. A dins, una aplicació que pot arribar al port de client normalment també pot arribar al port entre nodes, i les eines administratives de l'operador sovint seuen al mateix host de salt que l'aplicació. Aplanar-ho tot junt significa que una identitat d'aplicació compromesa ja té més abast que les seves pròpies consultes. Dibuixeu els tres públics com tres files al document de disseny, cadascuna amb la regla que la permet, i els buits es fan visibles abans que ningú els construeixi.

Què necessiten els clients, i res més

Permeteu que les fonts d'aplicació previstes arribin als punts finals de client per a la versió desplegada, i manteniu els serveis de clúster i de gestió no relacionats fora d'aquest abast. Després comproveu com el controlador descobreix els nodes. Un punt de contacte inicial abastable no estableix que cada adreça de node que el controlador triï després sigui abastable des d'aquell context de client, perquè el controlador demana parells al clúster i després es connecta a les adreces que el clúster anuncia.

Per això una discordança d'adreça privada produeix el patró conegut: una primera connexió correcta seguida de temps d'espera. Configureu les adreces anunciades i l'encaminament del client de manera deliberada; publicar tot el clúster a internet per reparar una discordança intercanvia un error d'encaminament per una exposició que no podeu recuperar.

Manteniu també l'autenticació de base de dades de l'aplicació i els permisos de rol. Una adreça VPN compartida i traduïda pot representar molts usuaris o serveis, de manera que mai no substitueix identitats de base de dades diferents.

Xifreu per separat client-a-node i entre nodes

La documentació de seguretat d'Apache tracta el xifratge client-a-node i entre nodes com a configuracions separades, i activar-ne una no activa l'altra. Aquesta distinció encara s'aplica dins d'una VPN, perquè el túnel protegeix el seu propi segment i no s'estén automàticament del procés d'aplicació al procés de base de dades ni entre cada parella de membres del clúster.

Una configuració que activa tots dos explícitament, en lloc d'heretar un valor per defecte de plantilla, s'assembla aproximadament a això:

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

En configuracions de servidor que permeten xifratge de client opcional, acceptar TLS pot coexistir amb acceptar connexions no xifrades, així que llegiu la política efectiva i no la intenció. Planeu els noms de certificat, la distribució de confiança i la renovació per als punts finals amb què cada client contacta realment; substituir un nom d'amfitrió per una adreça IP canvia la comprovació d'identitat del client, no només la seva ruta.

Manteniu l'administració en el seu propi camí

El trànsit entre nodes necessita el conjunt de parells permès i la seva pròpia política de protecció. L'accés administratiu, inclòs JMX allà on s'utilitza, necessita un públic separat i la seva pròpia autenticació. Una aplicació autoritzada a emetre consultes ordinàries no necessita per això totes les capacitats de gestió, i el contrari és pitjor: un camí administratiu exposat al segment d'aplicacions és la ruta més curta d'un error a una reconstrucció. Escriviu aquests dos públics per separat i nomeu-ne els propietaris, perquè normalment són equips diferents les regles dels quals es van fusionar per accident.

Manteniu alineades les regles efectives de núvol, les regles d'amfitrió i la configuració de l'oient. Un oient privat encara es pot exposar mitjançant una traducció o un proxy no previstos, i una regla pública àmplia pot seure en silenci al costat d'una regla VPN estreta fins que algú auditï totes dues alhora.

On els operadors necessitin realment un camí de gestió, doneu-li un propietari nomenat i una vida útil de credencials més curta que la de l'aplicació. Això manté la delegació visible quan la persona següent hereta el clúster.

Què promet el disseny

Valideu les tres promeses amb rols reals i no només amb proves de connectivitat. Una aplicació aprovada hauria de completar la seva feina permesa i res més, una font exclosa hauria de fallar al punt d'entrada de client, i una identitat d'aplicació hauria de ser rebutjada als camins d'administració reservats. Afegiu la reconnexió del client i la selecció de node a la mateixa prova de desplegament, perquè és allà on es manifesten els errors de descoberta.

Acabeu amb tres frases al document de disseny: quins clients poden consultar, quins nodes poden comunicar-se i quins operadors poden administrar. Ser darrere d'una VPN és informació útil de topologia, però no és una resposta a cap d'aquestes tres preguntes.