「外には出ません」は資料ではない
一言でいうと
ネットワーク分離環境に製品を入れるとき、「外には出ません」という文は受け入れられません。構成ファイルが何を呼び出すようになっているか、記録に何が実際に残ったか、そして確認できなかった範囲がどこまでかを一緒に出した資料だけが、根拠になります。
なぜ必要なのか
納品の終盤にプロジェクト監査チームが尋ねる質問は、いつも似ています。「この製品は外に何を送りますか。」作った人は「何も送りません」と答えたくなります。ところが、最近の製品には、アップデート確認、ライセンスのオンライン検査、リモート診断のアップロード、クラッシュレポート、利用統計、時刻同期が、ほとんどすべて入っています。大半はデフォルトがオンで、大半はインストール文書の表にありません。開発環境にはインターネットがあるので、誰も気づかないまま数年が過ぎます。
問題は、この質問が信頼の問題ではなく手順の問題だという点です。監査チームは、作った人を疑って尋ねているのではありません。口頭での約束は、次の担当者に伝わらず、次のバージョンアップで静かにひっくり返ります。そのため、資料として残せる形を求めます。米国国立標準技術研究所のSP 800-53 Rev.5は、システム・通信保護(SC)ファミリーに境界保護を置き、「許可したものだけを通し、残りは遮断する」を基本姿勢として書いています。防衛産業のサプライチェーンを扱うSP 800-171 Rev.3と、コンテナ環境を扱うSP 800-190も、同じ場所で「通信はデフォルト拒否」を前提にしています。この前提のもとで私たちが出せる資料は、「私たちの製品が何を呼び出すのか」の全体の一覧です。
どう動くのか
3つの層を、それぞれ読んで、時刻でつなぎます。
1つ目は、構成です。製品が何を呼び出すようになっているか。ここで、2つのことが毎回人を欺きます。1つは、コメントで塞いでおいた項目です。消したのではなく隠しただけなので、次のバージョンアップで復活します。そのため、オフとして表に載せ、一覧からは外しません。もう1つは、デフォルトがオンの項目です。設定ファイルにenabledがそもそもなければ、製品がオンとみなすというルールがよくありますが、これを知らないと、一覧からまるごと抜け落ちます。
この2つ目の落とし穴は、ツール側でもまったく同じように起きます。jqの代替演算子//は、左がnullのときだけでなく、falseのときも右を使います。そのため、.enabled // trueは「キーがなければオン」を意味するように見えますが、実際には、"enabled": falseときちんとオフにしてある項目まで、オンにしてしまいます。キーがないことと値がfalseであることは別の事実であり、その2つを区別することが、この仕事の半分です。
2つ目は、記録です。プロキシの接続記録は、実際の試行を数えます。ここで、応答コードをひとまとめにしてはいけません。200はリクエストが実際に出たという意味で、407はプロキシが認証を要求して止まったもので、403はプロキシが遮断したものです。403が10行あるということは、「送信がなかった」のではなく、「10回出ようとして、10回遮断された」ということです。監査に出すべき事実は、後者です。
3つ目は、名前解決です。プロキシを経由しない通信は、プロキシ記録に何も残しません。UDPで動く時刻同期、プロキシ設定を読まないライブラリ、ファイアウォールでそのまま落とされた直接接続が、すべてそうです。そうした機能も、名前は問い合わせます。そのため、問い合わせ記録にだけあって接続記録にはない宛先が別に出てきて、それが、そのコードパスが実際に動いたことの唯一の痕跡です。逆に、構成にアドレスが直接書かれていれば、問い合わせ記録にも残りません。RFC 1918のプライベート帯域のアドレスなら、外に出た可能性は低いですが、許可リストが名前で書かれている限り、そのアドレスがどのサービスなのかは突き合わせられません。こうした項目は、許可でも不許可でもない判断不能として書き、確認できなかったことに残します。
そして、時刻です。3つの記録を1つの表でつなぐと、「いつからこの試行が生じたのか」が出ます。構成変更記録の時刻と、最初の問い合わせの時刻が近接していれば、その変更が原因だと言える根拠になります。この表は、逆にも役に立ちます。変更記録にないのに、記録にだけ現れる宛先は、インストールスクリプトや人の手が残したものであり、構成管理の外で起きたことを明らかにします。
このラボの仮定
実習用のPodには、カーネル権限が一切ありません。tcpdumpもiptablesも動作しないので、パケットを捕まえて見せる道は、そもそもありません。実際の納品現場でも、開発者が顧客のファイアウォールにアクセスすることはほとんどなく、その場所は、ネットワークチームが出すファイアウォールポリシーの写しと機器ログが埋めます。このラボは、その場所を、プロキシの接続記録と名前解決の記録で代わりにします。設定ファイルで「セクションにenabledがなければオンとみなす」という製品のルールも、このラボの仮定であり、実際の製品ごとに異なるので、現場では必ず説明書で確認します。
現場での姿
ある納品の案件で、「テレメトリはオフにします」と議事録に書き、実際にもオフにしましたが、半年後のバージョンアップで、デフォルトの設定ファイルがまるごと入れ替えられて、復活しました。誰も知らなかった理由は単純です。オフにしたという事実が、人の記憶と議事録にだけあり、機械が確認する場所にはなかったからです。一覧と、再収集した記録を資料として残せば、次のバージョンアップで、同じ手順をもう一度回せます。
別の案件では、「不許可0件」を出すために、記録から該当の行を消した例を見ました。これは資料ではなく、資料の反対です。「ない」ことを示す方法は、消すことではなく、オフにする前とオフにしたあとの2組の記録を並べて置くことです。オフにしたあとの記録に、承認された宛先がそのまま残っていてはじめて、その収集が本物だったことも一緒に示されます。
実務で本当に大切なこと
- 確認した範囲と確認できなかったことを、同じ文書に書きます。範囲を明かさない「異常なし」は、次の人を欺きます。
- 判定だけを書かず、数えた値とどのファイルから来たかも一緒に残します。監査担当者が自分で数え直せなければなりません。
- どうしても必要な機能は、オフにする代わりに、承認された内部の宛先に切り替えます。時刻同期をオフにすると、別の場所で事故が起きます。
- 資料は古くなります。バージョンアップのたびに、同じ手順をもう一度回せるように、スクリプトにして引き継ぎます。
次のラボですること
構成ファイル3つから、外を指すアドレスをすべて抜き出して、オン・オフを分け、許可リストと突き合わせて、許可・不許可・判断不能の3つに分けます。プロキシ記録から試行を応答別に数え、問い合わせ記録にだけある宛先を別に探します。3つの記録を時刻でつないで、どの構成変更がその試行を生んだかを指し示したあと、構成を実際にオフにして記録を再収集し、消えたことを示します。最後に、監査提出用の要約を、機械が読むJSONと人が読む表の両方で出します。