Cassandra via un VPN : un accès distinct pour les clients et les nœuds

Un déploiement Cassandra n’a pas un réseau de base de données unique et universel. Les applications parlent au service client, les membres du cluster se parlent entre eux et les opérateurs utilisent des interfaces d’administration, et ces trois publics ne devraient pas hériter de l’accessibilité les uns des autres. Un chemin privé comme un VPN est un bon point de départ, mais il n’est pas l’identité utilisateur de la base de données et il n’est pas sa politique de chiffrement. Traitez la décision de connectivité et la décision d’autorisation comme deux revues distinctes.

Chacun des trois publics reçoit sa propre réponse, et les sections ci-dessous les abordent par ordre d’exposition.

Trois publics, trois décisions

Identifiez ce dont chaque groupe a réellement besoin avant de toucher à une règle. Les clients ont besoin de l’écouteur client et de suffisamment d’informations pour joindre chaque nœud qui peut leur être attribué, les nœuds pairs ont besoin les uns des autres sur le port internodal, et les opérateurs ont besoin de l’interface de gestion pour ce que le runbook demande réellement. Trois listes, trois publics, trois niveaux de confiance.

L’erreur courante est de construire un segment privé plat unique et de supposer que la frontière du VPN fait le reste. À l’intérieur, une application qui atteint le port client atteint généralement aussi le port internodal, et les outils d’administration d’un opérateur se trouvent souvent sur le même hôte de saut que l’application. Aplatir tout cela ensemble signifie qu’une identité d’application compromise dispose déjà de plus de portée que ses propres requêtes. Dessinez les trois publics comme trois lignes dans le document de conception, chacune avec la règle qui l’autorise, et les lacunes deviennent visibles avant que quiconque les construise.

Ce dont les clients ont besoin, et rien de plus

Autorisez les sources d’application prévues à atteindre les points de terminaison client pour la version déployée, et gardez les services de cluster et de gestion sans rapport hors de cette portée. Vérifiez ensuite comment le pilote découvre les nœuds. Un point de contact initial joignable ne prouve pas que chaque adresse de nœud que le pilote sélectionne ensuite est joignable depuis ce contexte client, parce que le pilote demande les pairs au cluster puis se connecte aux adresses que le cluster annonce.

C’est pourquoi une seule inadéquation d’adresse privée produit le schéma familier : une première connexion réussie suivie de délais d’attente. Configurez délibérément les adresses annoncées et le routage client ; publier tout le cluster sur internet pour réparer une inadéquation échange un bogue de routage contre une exposition que vous ne pouvez pas reprendre.

Conservez aussi l’authentification de base de données de l’application et les permissions de rôle. Une adresse VPN partagée et traduite peut représenter de nombreux utilisateurs ou services, aussi ne remplace-t-elle jamais des identités de base de données distinctes.

Chiffrez séparément client-vers-nœud et internodal

La documentation de sécurité d’Apache traite le chiffrement client-vers-nœud et internodal comme des configurations distinctes, et activer l’un n’active pas l’autre. Cette distinction s’applique encore à l’intérieur d’un VPN, car le tunnel protège son propre segment et ne s’étend pas automatiquement du processus applicatif au processus de base de données ni entre chaque paire de membres du cluster.

Une configuration qui active explicitement les deux, plutôt que d’hériter d’une valeur par défaut de modèle, ressemble à peu près à ceci :

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

Dans les configurations serveur qui autorisent un chiffrement client facultatif, l’acceptation de TLS peut coexister avec l’acceptation de connexions non chiffrées, alors lisez la politique effective plutôt que l’intention. Planifiez les noms de certificats, la distribution de confiance et le renouvellement pour les points de terminaison que chaque client contacte réellement ; remplacer un nom d’hôte par une adresse IP change le contrôle d’identité du client, pas seulement sa route.

Gardez l’administration sur son propre chemin

Le trafic internodal a besoin de l’ensemble de pairs autorisé et de sa propre politique de protection. L’accès administratif, y compris JMX là où il est utilisé, a besoin d’un public distinct et de sa propre authentification. Une application autorisée à émettre des requêtes ordinaires n’a pas pour autant besoin de toutes les capacités de gestion, et l’inverse est pire : un chemin administratif exposé au segment applicatif est la route la plus courte d’un bogue à une reconstruction. Écrivez ces deux publics séparément et nommez leurs responsables, car ce sont généralement des équipes différentes dont les règles ont été fusionnées par accident.

Gardez alignés les règles de cloud effectives, les règles d’hôte et la configuration de l’écouteur. Un écouteur privé peut encore être exposé par une traduction ou un proxy involontaire, et une règle publique large peut se tenir tranquillement à côté d’une règle VPN étroite jusqu’à ce que quelqu’un audite les deux à la fois.

Là où les opérateurs ont réellement besoin d’un chemin de gestion, donnez-lui un responsable nommé et une durée de vie des identifiants plus courte que celle de l’application. Cela garde la délégation visible lorsque la personne suivante hérite du cluster.

Ce que la conception promet

Validez les trois promesses avec de vrais rôles plutôt qu’avec des tests de connectivité seuls. Une application approuvée devrait accomplir son travail autorisé et rien de plus, une source exclue devrait échouer à l’entrée client, et une identité d’application devrait être refusée sur les chemins d’administration réservés. Ajoutez la reconnexion du client et la sélection de nœud au même test de déploiement, car c’est là que les erreurs de découverte apparaissent.

Terminez par trois phrases dans le document de conception : quels clients peuvent interroger, quels nœuds peuvent communiquer et quels opérateurs peuvent administrer. Être derrière un VPN est une information de topologie utile, mais ce n’est la réponse à aucune de ces trois questions.