最新パッチを当てると認証が無効になる

一言でいうと

認証を受けた構成では、脆弱性への対応が、アップデートではなく緩和措置と文書化で終わることがよくあり、その文書がなければ、次の監査で放置と読まれます。

なぜ必要なのか

商用環境で脆弱性のアドバイザリを受けたとき、私たちがすることは、たいてい1つです。上げます。パイプラインがあり、テストがあり、ロールバックがあるので、上げることがいつも最も安い選択です。

防衛産業・公共の国防環境には、ここに条件がもう1つ付きます。システムの構成が認証を受けて運用されています。どのコンポーネントがどのバージョンで入っているかが認証文書に書かれていて、その一覧どおりに動作することが、運用の根拠です。そのため、バージョンを変えると、その構成は認証を受けたその構成ではなくなります。再認証には数か月かかります。

ここで、初めて入ったエンジニアが最も戸惑う瞬間が来ます。高リスクの脆弱性アドバイザリを受け、パッチのバージョンを確認して、「これはすぐに上げなければなりません」と言ったところ、返ってくる答えが「それは上げられません」という瞬間です。

どう動くのか

上げられないことが、そのまま何もしないことではありません。やることが3つに変わります。

1つ目は、影響判定です。アドバイザリが出たからといって、すべてに影響があるわけではありません。インストールされているバージョンと修正されたバージョンを比べて、実際に該当するかを分けます。ここで最もよくある事故が、バージョンを文字列で比較することです。16.2と16.10を文字列で比べると、16.2のほうが大きく見え、その瞬間に、本当に影響のある項目が、静かに「該当なし」に回されます。逆の方向もあります。インストールされた3.12.3と修正された3.9.20を文字列で比べると、影響があるように見えて、問題のない項目に対応人員を使います。ドットで区切って、数字で比較しなければなりません。

境界値もよく間違えます。修正バージョンが1.24.0で、インストールされているものも1.24.0なら、すでに修正済みです。そして、そもそもインストールされていないコンポーネントについてのアドバイザリは、影響がありません。一覧にないものに対処することはできません。

2つ目は、措置の区分です。影響のある項目を2つに分けます。認証済み構成の外にあるアプリケーションなら、上げられるのでパッチです。認証済み構成に縛られていれば、緩和です。緩和は、脆弱性が成立する条件をなくすことです。脆弱な経路が外部入力でだけ成立するなら、外部入力の経路を遮断し、拡張モジュールのロードでだけ成立するなら、その拡張をインストールせず、インストール権限を取り消します。

3つ目は、文書化です。これが最も抜けやすく、最も大きな問題になります。緩和には、目に見える成果物がありません。バージョン番号がそのままなので、外から見ると、何もしなかったことと区別がつきません。そのため、判断したという事実を残すこと自体が仕事です。何が影響なのか、なぜ上げられないのか(認証番号)、何で成立条件をなくしたのか、いつ再び見るのか。この4つが1行にあってはじめて、次の監査で「放置」ではなく「判断」と読まれます。

現場での姿

構成リスト自体を守らなければなりません。認証を受けた一覧が、静かに変わっているのが最悪です。誰がいつ何をなぜ変えたかがなければ、今動いているものが認証を受けたそれなのか、誰も答えられません。そのため、一覧ファイルのハッシュを別に記録しておきます。一覧が変われば、ハッシュが変わり、ハッシュが変わったことは、すぐに現れます。

再評価の時点がない緩和は、緩和ではありません。「今はこうして塞いでおきます」で終わると、その緩和は永遠に残ります。次の再認証の周期がいつか、そのときにこの項目をどう処理するのかを一緒に書いてはじめて、緩和が終わりを持ちます。

対応の対象でないものを表に入れないでください。影響なしと判定した項目まで対応表に載せておくと、表が長くなって、本当の対象が埋もれます。判定の根拠は別に残し、対応表には対応するものだけを載せます。

続けて読むこと

変えられない構成を守る話がここまでだとすれば、すぐあとに来る記事は、「誰が何をいつ行ったか」を残す設計と、その設計を次の人に引き継ぐことを扱います。監査証跡は、事故のあとに探すものではなく、作業の前に残るようにしておくものであり、引き継ぎ文書は、その設計が受け継がれる通路です。そのあとのラボで、2つの記事の内容を、一度に手で追います。