TLS、ネットワーク入口、SQL権限はそれぞれ別の問いに答える

顧客にPostgreSQLのログインを渡せば経費申請が端から端まで暗号化されて流れる、という提案がある。データベース管理者は本物のSQLセッションを必要としており、別の誰かは代わりにWebフォームを提案する。どちらの提案も、顧客が実際に行う操作から始まっていないため、間違った問題を解いている。三つの決定を順にたどれば、TLSがVPNの代わりになるかという問いは自ずと答えが出る。

顧客が必要とする操作から始める

顧客が何を達成すべきかを書き出す。申請の提出、レポートの一行の読み取り、その場の問い合わせの実行は、リスクの性質が異なる三つの別の操作である。

次に、誰が要求しているかを書き出す。顧客、サポート担当者、管理者は、同じテーブルに触れるとしても互換ではない。その違いが、顧客が問い合わせ言語をどこまで見るべきかを決める。

二つの答えの組がインターフェースを決める。その後のすべては実装であり、暗号化をめぐる議論のほとんどは、実際にはどのインターフェースを選んだかの議論である。

三つの制御、三つの決定

認証されたTLSは接続を保護し、どのTLS識別子を受け入れるかを決める。ネットワーク入口は、どの送信元が待ち受けに到達できるかを決める。データベースの認可は、ロールがどのオブジェクトと操作を使えるかを決める。

三つはどれも他を代替せず、表がそれを明示している。

頼りにしている行を外す前に、その行を読む。こうした設計の多くは、制御を設定せず前提にしたために失敗する。

直接SQLではデータベースのポリシーが主導する

承認された直接接続では、サービスの識別子の検証と意図したアクセスポリシーの両方を維持する。TLSを有効にすると暗号化された接続が利用可能になるだけで、アクセス設定がhostsslの項目で求めていない限り、暗号化されていない接続を拒否しない。

その区別は、テンプレートではなく稼働中の設定で確認する価値がある。TLSを提供し平文も受け入れるサーバーは、多くの人が導入したと思っている設計ではない。アクセス規則を読み、どの項目が実際にそれを要求しているかを見る。その一つの確認が、暗号化できるサーバーと暗号化のみのサーバーを分ける。

仕事に必要な権限だけを持つロールを使い、所有権、継承されたメンバーシップ、広く付与された許可を見直す。PostgreSQLの権限モデルが、データベースオブジェクトの権限の境界である。

VPNは、データベース認証の前にどの端末がサービスに到達できるかを制限でき、アクセスゲートウェイも同様のことができる。どちらも、公開された構成要素の保守、資格情報の管理、資源使用の制限という必要性をなくさない。

クライアント証明書は資格情報であり、ACLではない

クライアント証明書は接続時に要件を追加できる。clientcert設定は、信頼された証明書を要求でき、より厳格なモードでは証明書名とデータベース利用者の関係を要求できる。

それはより強い資格情報である。認可の一覧ではなく、接続を受け入れる構成要素が今もネットワーク通信とハンドシェイクを処理しているため、サーバーを不可視にもしない。証明書をアクセス一覧として扱っても、実際の許可は変わらない。また証明書の配布を広げがちで、それが次の問題を生む。

過剰な権限のロールに結び付いた強い証明書は、よく認証された管理者を生む。証明書を祝う前にロールを確認する。

合うなら狭いインターフェースを選ぶ

経費申請では、申請を受け取り、業務ルールを適用し、その利用者に許された結果を返すアプリケーションの端点のほうが、汎用のSQLアカウントよりもうまく操作を表す。

アプリケーションは自前の制限されたデータベース識別子を使い、顧客が問い合わせ言語を機能として受け取ることはない。より小さな面であり、誤り方も少ない。

これは設計上の選択であり、アプリケーションコードが自動的に安全だという主張ではない。そのコードは呼び出し元を認証し、各操作を認可し、入力を検証する必要があり、それ自身のデータベース許可も依然として重要である。

直接SQLは、承認された仕事がそれを必要とする人と道具にとって正しいままだ。その設計はロール、ネットワーク範囲、運用上の制限で条件づけ、他の顧客には狭いインターフェースを保たせる。二つの集団を一つのロールに混ぜることが、議論の始まるところである。