Cassandra sobre VPN: acceso separado para clientes y nodos

Un despliegue de Cassandra no tiene una única red universal de base de datos. Las aplicaciones hablan con el servicio de cliente, los miembros del clúster hablan entre sí y los operadores usan interfaces administrativas, y esos tres públicos no deberían heredar el alcance de los demás. Una ruta privada como una VPN es un buen punto de partida, pero no es la identidad de usuario de la base de datos ni es su política de cifrado. Trate la decisión de conectividad y la decisión de autorización como dos revisiones separadas.

Cada uno de los tres públicos recibe su propia respuesta, y las secciones siguientes los tratan por orden de exposición.

Tres públicos, tres decisiones

Identifique qué necesita realmente cada grupo antes de tocar una regla. Los clientes necesitan el receptor de cliente y suficiente información para llegar a cada nodo que se les pueda asignar, los nodos pares se necesitan entre sí en el puerto entre nodos, y los operadores necesitan la interfaz de gestión para lo que el runbook realmente exige. Tres listas, tres públicos, tres niveles de confianza.

El error habitual es construir un único segmento privado plano y suponer que la frontera de la VPN hace el resto. Dentro de él, una aplicación que alcanza el puerto de cliente suele alcanzar también el puerto entre nodos, y las herramientas administrativas del operador a menudo se sientan en el mismo host de salto que la aplicación. Aplanar todo eso junto significa que una identidad de aplicación comprometida ya tiene más alcance que sus propias consultas. Dibuje los tres públicos como tres filas en el documento de diseño, cada una con la regla que la permite, y los huecos se vuelven visibles antes de que nadie los construya.

Qué necesitan los clientes, y nada más

Permita que las fuentes de aplicación previstas lleguen a los puntos finales de cliente para la versión desplegada, y mantenga los servicios de clúster y de gestión no relacionados fuera de ese alcance. Luego compruebe cómo el controlador descubre los nodos. Un punto de contacto inicial accesible no demuestra que cada dirección de nodo que el controlador elija después sea accesible desde ese contexto de cliente, porque el controlador pide pares al clúster y luego se conecta a las direcciones que el clúster anuncia.

Por eso una sola discrepancia de dirección privada produce el patrón conocido: una primera conexión correcta seguida de tiempos de espera. Configure las direcciones anunciadas y el enrutamiento del cliente de forma deliberada; publicar todo el clúster en internet para reparar una discrepancia cambia un error de enrutamiento por una exposición que no puede recuperar.

Mantenga también la autenticación de base de datos de la aplicación y los permisos de rol. Una dirección VPN compartida y traducida puede representar a muchos usuarios o servicios, así que nunca sustituye a identidades de base de datos distintas.

Cifre por separado cliente-a-nodo y entre nodos

La documentación de seguridad de Apache trata el cifrado cliente-a-nodo y entre nodos como configuraciones separadas, y habilitar una no habilita la otra. Esa distinción sigue aplicándose dentro de una VPN, porque el túnel protege su propio segmento y no se extiende automáticamente del proceso de la aplicación al proceso de la base de datos ni entre cada par de miembros del clúster.

Una configuración que activa ambos explícitamente, en lugar de heredar un valor predeterminado de plantilla, se parece aproximadamente a esto:

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

En configuraciones de servidor que permiten cifrado de cliente opcional, aceptar TLS puede coexistir con aceptar conexiones sin cifrar, así que lea la política efectiva y no la intención. Planifique los nombres de certificado, la distribución de confianza y la renovación para los puntos finales con los que cada cliente contacta realmente; sustituir un nombre de host por una dirección IP cambia la comprobación de identidad del cliente, no solo su ruta.

Mantenga la administración en su propia ruta

El tráfico entre nodos necesita el conjunto de pares permitido y su propia política de protección. El acceso administrativo, incluido JMX donde se use, necesita un público separado y su propia autenticación. Una aplicación autorizada a emitir consultas ordinarias no necesita por ello todas las capacidades de gestión, y lo contrario es peor: una ruta administrativa expuesta al segmento de aplicaciones es la ruta más corta de un error a una reconstrucción. Escriba esos dos públicos por separado y nombre a sus propietarios, porque suelen ser equipos distintos cuyas reglas se fusionaron por accidente.

Mantenga alineadas las reglas efectivas de nube, las reglas de host y la configuración del receptor. Un receptor privado todavía puede quedar expuesto mediante una traducción o un proxy no previstos, y una regla pública amplia puede quedarse en silencio junto a una regla VPN estrecha hasta que alguien audite ambas a la vez.

Donde los operadores necesiten de verdad una ruta de gestión, dele un propietario nombrado y una vida útil de credenciales más corta que la de la aplicación. Eso mantiene visible la delegación cuando la siguiente persona hereda el clúster.

Qué promete el diseño

Valide las tres promesas con roles reales y no solo con pruebas de conectividad. Una aplicación aprobada debería completar su trabajo permitido y nada más, una fuente excluida debería fallar en la entrada de cliente, y una identidad de aplicación debería ser rechazada en las rutas de administración reservadas. Añada la reconexión del cliente y la selección de nodo a la misma prueba de despliegue, porque es ahí donde aparecen los errores de descubrimiento.

Termine con tres frases en el documento de diseño: qué clientes pueden consultar, qué nodos pueden comunicarse y qué operadores pueden administrar. Estar detrás de una VPN es información útil de topología, pero no es respuesta a ninguna de esas tres preguntas.