VPN 経由の Cassandra：クライアントとノードに別々のアクセスを

Cassandra の配備に、単一の万能なデータベース網はありません。アプリケーションはクライアントサービスと話し、クラスターのメンバーは互いに話し、運用者は管理インターフェースを使います。この三つの利用者が互いの到達範囲を継承してはなりません。VPN のような専用経路は良い出発点ですが、それはデータベースの利用者 ID ではなく、その暗号化ポリシーでもありません。接続性の判断と認可の判断は、別々のレビューとして扱ってください。

三つの利用者はそれぞれ別の答えを持ち、以下の各節はその順に論じます。

三つの利用者、三つの判断

ルールに触る前に、各グループが本当に必要とするものを洗い出します。クライアントにはクライアントリストナーと、渡されうるあらゆるノードに届くための十分な情報が要ります。ピアノードにはノード間ポートで互いが必要です。運用者には、ランブックが実際に求めるもののための管理インターフェースが要ります。三つの一覧、三つの利用者、三つの信頼水準です。

よくある誤りは、平坦な専用セグメントを一つ作り、境界の VPN が残りをやってくれると考えることです。その内側では、クライアントポートに届くアプリケーションは通常ノード間ポートにも届き、運用者の管理ツールはアプリケーションと同じ踏み台ホストに載っていることがよくあります。これらを一つに平らにすると、侵害されたアプリケーション ID が自分のクエリ以上の到達範囲をすでに持つことになります。設計文書に三つの利用者を三つの行として描き、それぞれに許可するルールを添えれば、誰かが作る前に隙間が見えるようになります。

クライアントに必要なもの、それ以上は不要

配備したバージョンのクライアントエンドポイントへ、意図したアプリケーションの送信元だけを許可し、無関係なクラスターサービスと管理サービスはその到達範囲の外に置きます。次に、ドライバーがどうノードを見つけるかを確認します。到達できる最初の接続先は、その後にドライバーが選ぶすべてのノードアドレスがそのクライアントの文脈から届くことを保証しません。ドライバーはクラスターにピアを問い合わせ、クラスターが広告するアドレスへ接続するからです。

だからこそ、専用アドレスのわずかな不一致が、最初は接続できてその後タイムアウトするという見慣れた形を生みます。広告するアドレスとクライアントの経路は意図して設定してください。不一致を一つ直すためにクラスター全体をインターネットへ公開するのは、経路の不具合を、取り消せない露出と交換することになります。

アプリケーションのデータベース認証とロール権限もそのまま残します。共有された変換後の VPN アドレスは多数の利用者やサービスを表しうるので、別々のデータベース ID の代わりには決してなりません。

クライアント対ノードとノード間を別々に暗号化する

Apache のセキュリティ文書 は、クライアント対ノードとノード間の暗号化を別々の設定として扱っており、片方を有効にしても他方は有効になりません。この区別は VPN の内側でも当てはまります。トンネルは自分のセグメントを守るだけで、アプリケーションのプロセスからデータベースのプロセスへ、あるいはクラスターのメンバーの各組の間へ自動的に及ぶわけではないからです。

テンプレートの既定値を継承するのではなく、両方を明示的に有効にする設定は、おおよそ次のようになります。

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

クライアント暗号化を任意で許すサーバー設定では、TLS の受け入れが暗号化されていない接続の受け入れと共存しうるので、意図ではなく実際に効いているポリシーを読んでください。証明書の名前、信頼の配布、更新を、各クライアントが実際に接続するエンドポイントについて計画します。ホスト名を IP アドレスに置き換えると、経路だけでなくクライアントの ID 確認も変わります。

管理は専用の経路に保つ

ノード間の通信には、許可されたピアの集合と独自の保護ポリシーが要ります。使われる場合の JMX を含む管理アクセスには、別の利用者と独自の認証が要ります。通常のクエリを出すことを許されたアプリケーションが、それによってあらゆる管理機能を必要とするわけではなく、逆の方がより悪いのです。アプリケーションセグメントに開いた管理経路は、不具合から作り直しへ至る最短の道です。この二つの利用者を別々に書き出し、それぞれの所有者を名指ししてください。たいていは別のチームのルールが事故で統合されたものだからです。

実際に効いているクラウドのルール、ホストのルール、リスナーの設定をそろえておきます。専用リスナーも、意図しない変換やプロキシを通じて公開されたままになり、広い公開ルールが狭い VPN ルールの隣に静かに居座り続けることがあります。誰かが両方を同時に監査するまでは。

運用者が本当に管理経路を必要とする場合には、名前のある所有者と、アプリケーションより短い資格情報の寿命を与えます。そうすれば、次に引き継ぐ人にも委譲がはっきり見えます。

設計が約束するもの

三つの約束は、接続テストだけでなく実際のロールで検証します。承認されたアプリケーションは許された作業だけを完了し、除外された送信元はクライアントの入口で失敗し、アプリケーション ID は予約された管理経路で拒否されるべきです。クライアントの再接続とノード選択も同じ展開テストに加えてください。発見の誤りはまさにそこで表面化します。

設計文書では三つの文で締めくくります。どのクライアントが問い合わせできるのか、どのノードが通信できるのか、どの運用者が管理できるのか。VPN の内側にいることは有用なトポロジーの情報ですが、その三つの問いのどれへの答えでもありません。