クラウドからバックエンドへのアクセス契約に書き込むべき六つの決定

顧客の社内システムから承認済みの要約を受け取る必要がある、クラウドアカウント上のレポートサービスを例に考えてみる。VPN や認証済みのアプリケーション接続は経路を守るだけで、それ以外の何も決めない。レポート用のワークロードが無関係なレコードを読んでよいのか、バックエンドを変更してよいのか、取得したデータを保持してよいのかは決めない。コネクタを選ぶ前に、操作とデータの観点でアクセス契約を書くべきである。コネクタは後から変更するのが最も安く、最初に間違えやすい部分だからだ。

コネクタより先に操作を決める

最初の決定は、ワークロードが何をしてよいかであり、ネットワーク範囲ではなく操作として名付ける。レポートの例なら、狭いレポート用 API でニーズを満たせ、クラウドのワークロードにデータベース管理を渡さずに済む。

レポートに必要なデータと、たまたま到達できるデータを分ける。許可する操作は、エンドポイントと動詞として、アイデンティティの決定と同じ文書に書く。この区別が、監査を通過する統合と、毎年説明し直さなければならない統合の差であり、後日の議論を会議なしで決着させる。

ワークロードのアイデンティティを決め、所有者を決める

無人で動くジョブはプロンプトに答えられない。だからチームは個人の広い権限のアカウントに手を伸ばし、やがて忘れる。バックエンドが実際に受け入れるサービスアカウントかマシン資格情報を使い、誰が所有し、どこに保管し、どう回転させるかを記録する。

三つの条件がそろえば、専用のアイデンティティへ判断を傾けるべきだ。人がいなくてもジョブが動くこと、資格情報が単一のデプロイより長く生きること、一人より多くの人がその存在を知る必要があることだ。三つすべてが当てはまるなら、共有の人間アカウントは近道ではなく、誰もきれいに失効させられない恒久的な例外である。

設定に貼り付けた静的シークレットではなく、プラットフォームがワークロード向けに発行・回転できる資格情報を優先する。たとえばバックエンドが検証するワークロードアイデンティティトークンだ。アプリケーション設定の静的シークレットこそ、回転が障害になる原因である。

ネットワーク範囲を決める。それは権限ではないと知ったうえで

どちらの側が接続を開始するか、対応するトランスポート、関係するエンドポイントを明記する。ピアのアイデンティティ検証は有効にしたまま、無関係なバックエンドの宛先は単に告知しないのではなく到達不能にしておく。

狭いトンネル経路は有用な範囲だが、操作レベルの認可を置き換えられない。バックエンドは自身の制御で契約を強制しなければならない。ネットワークは到達可能なポートに届いた要求を喜んで運ぶからだ。ルートテーブルではなく、バックエンド自身のロールと付与を確認する。サーバーに届く経路でも判断はサーバー側に残り、そこで契約が強制されるか無視されるかが決まる。

逆もまた真である。有効なサービス資格情報は、あらゆる送信元にリスナーを公開する理由にはならない。両方の制御が必要で、どちらも他方を代替しない。

データの扱いと責任の分担を決める

顧客環境から何が出ていくのか、アプリケーションがどこで処理するのか、実際の保存・バックアップ・アクセス・保持の取り決めを記録する。保持は後になって発覚する部分で、たいていは、誰も文書化していないバケットに前四半期のコピーがまだ残っているのかと誰かが尋ねたときに明らかになる。

当事者は分けておく。アプリケーションの運用者、ソフトウェアの供給者、インフラのホストは異なる責任を負い得て、どれがどれかはサービスモデルが決める。三者のアクセスが同一だと決めつけたり、まったく無いと決めつけたりせず、実際の契約を読む。

障害、撤去、そして受け入れ方を決める

障害時の責任を、起きる前に割り当てる。コネクタが壊れたときやアイデンティティの侵害が疑われるとき、対応は場当たり的な無制限のネットワーク例外であってはならない。それがインシデントより長く生き残るからだ。

撤去は構築と同じ精度に値する。認可がどう取り消されるか、製品が対応する挙動のもとで有効なアクセスがどう終わるか、関係が終わったときに保持されたコピーがどうなるかを定義する。

代表的な許可操作と、契約が求める拒否をそろえて統合を受け入れる。すべて意図したワークロードのアイデンティティのもとで行う。要求の経路と実際に届いたデータを確認し、資格情報の交換と撤去を実際に試す。接続されたトンネルは経路の存在を証明する。契約はその経路に限界を与えるものだ。