持ち出し審査 — 消す仕事ではなく選ぶ仕事

一言でいうと

持ち出し用の要約は、原本を消して作るものではなく、空のファイルから始めて、必要な事実だけを書き写して作るものであり、その違いが、事故と無事故を分けます。

なぜ必要なのか

エアギャップ環境の中で原因を見つけても、仕事は終わりません。その結果を本社の開発チームに伝えてはじめて修正版が作られ、修正版があってはじめて次の持ち込みができます。ところが、伝えるには審査を通過しなければならず、審査は「これが出ていってもよいか」を人が判断します。

ここには、2種類の失敗があります。

多く残しすぎた失敗。ログをそのまま出そうとして、差し戻されます。ログには、アカウント、社員番号、内部ホスト名、内部IP、ファイルパスが入っています。1つ1つは些細に見えますが、外で集めると、組織の構成とネットワークの構造になります。差し戻しは、まだましな結果です。通過したのにあとで見つかるのが、最悪です。

多く消しすぎた失敗。心配が先に立って、数字やコードまで潰してしまうと、受け取る側は何の判断もできません。「性能の問題と見られます」だけが書かれた要約は、出ても出なくても同じです。そうなると、結局電話で改めて説明することになり、電話で説明しているうちに、結局、消した値を口頭で伝えることになります。統制は無力になり、記録は残りません。

どう動くのか

この2つを同時に避ける方法は、向きを変えることです。

消さずに、選んでください。原本を開いて機微な部分を消していくと、消し残しが必ず1つ残ります。残った1つは、何度読み直しても見えません。すでに処理したと思っている文書を、人は検査するようには読めないからです。代わりに、空のファイルから始めて、判断に必要な事実だけを書き写せば、書き写さなかったものは、そもそも存在しません。

何が入っているかを先に数えます。選ぶ前に、種類別の一覧を作ります。アカウント8個、社員番号8個、ホスト名3個、内部IP3個、連絡先1個、作業者識別子4個。この一覧が、あとで自己検証の基準になります。一覧なしで始めると、1つの種類をまるごと見落とし、見落とした種類は、探していないので最後まで見えません。そして、審査の対象は、ログファイル1つではありません。構成変更記録に担当者の連絡先が1行入っているように、一緒に見ていた他のファイルに、別の種類が隠れています。

検証は、目ではなく一覧で行います。原本から機械的に抽出した禁止トークンの一覧で要約を突き合わせ、一致件数が0かを見ます。固定文字列で突き合わせなければなりません。正規表現として読まれると、ドットが任意の1文字になって、見当違いの場所が引っかかったり、逆に見逃したりします。

そして、その一覧自体は出ません。禁止トークンの一覧は、機微な値だけを集めたファイルです。持ち出しディレクトリに一緒に入れておくと、肝心の最も危険なファイルが出ていってしまいます。実際にあったことで、そのため、持ち出しディレクトリには審査を受けるものだけを置くというルールができました。

現場での姿

残すものの基準は、「これがなければ、受け取る側が判断できないか」です。エラーコードは残します。ないと、どんな失敗かわかりません。件数は残します。ないと、規模がわかりません。構成変更の識別子は残します。それが原因を指し示した根拠です。一方、どのアカウントがそのリクエストを送ったかは、原因と無関係です。ノード名も同じです。「3台すべてで発生した」という事実があれば判断に十分で、その3台の名前は必要ありません。

完全性も一緒に出ます。審査を受けたファイルと、実際に出ていくファイルが同じであることを確認する手段が必要です。要約のSHA-256を申請書に書き、ハッシュファイルを一緒に置きます。要約を1文字でも直したら、ハッシュも計算し直さなければなりません。この1行を忘れて、審査を2回受けたことがあります。

申請書も、一緒に出る文書です。要約はきれいなのに、申請書に担当者の連絡先を書いてしまう場合が、驚くほどよくあります。突き合わせは、出ていくすべてのファイルにかけます。

次のラボですること

前の調査で得た事実を、持ち出し可能な形にします。種類別に数え、空のファイルから始めて要約を書き、原本から抽出した禁止トークン27個で突き合わせて一致0件を確認し、目的・含めるもの・除くもの・検証・完全性・承認の6つの節を備えた持ち出し申請書を書きます。最後に、持ち出しディレクトリの中に、審査対象ではないファイルが1つもないことまで確認します。