脆弱性対応に限らず

世界中で祭りになってしまった脆弱性問題

昨今、まさかの総理大臣がアナウンスしてくれる事態まで発展したPHP2SHELLの脆弱性問題。
私自身、これを知ったのは10/21のことで、比較的後から知ったクチです。

経験上、こうした脆弱性対応をする人は情シス部門か、SIerのITインフラ部門・運用･保守部門が対応することが多く。私の場合、ちょうどSIerのITインフラ部門の人間として十数年ほど動いてた時期があるので、その人間として述べることを挙げると、ITインフラのオペレーションで重要なポイントは大体準備段階で押さえちゃうことが多いんですね。

今回の記事の話題の主軸はそこです。

準備段階で何をするかってたとえばこんな感じ。

顧客間との調整、合意取り付け
- 影響範囲の確認、どのシステムに影響するか、間接的に他のシステムに影響が及ぶかどうか
- そもそも脆弱性対応のために最新化することが許容できるか
- 顧客はどこまでリスクを受容できるか、停止時間判断どうするか、顧客情シス側で調整できる範囲は何か？
- 必要に応じて作業前情報の収集なんかも行ったりする
方針策定
- 顧客側体制の確認（顧客側は誰が対面に立つか？連絡先は？
- どんな手順でどんなサーバから手をつけていくかの手順検討
- 失敗時のフォールバックプラン検討（コンティンジェンシープランと呼んだりもする）
  - 切り戻すかどうか（切り戻すなら場合によってはバックアップ手順の追加も必要）
- 脆弱性対応をする際、何をもって対応するか（パッチを適用？それともパッケージ管理経由でアップデート？それとも再コンパイルしてバイナリ作って書き換え？など）
- 脆弱性対応をした結果問題ないかどうかの判断をどうするか
  - 顧客側からアクセスしてもらって動作確認をしてもらう？（確認操作手順は事前に確立されてることが多い）
  - サーバサイドで確認する事項の準備（これも事前に確立されてることが多い）
- 再起動は必要か？起動にかかる時間はどの程度か
  - それはプロセス再起動か？アプリ全再起動か？サーバ単位で再起動か？システム単位で再起動か？
  - それぞれの時間はどの程度予測されるか？（過去情報から引っ張り出して推定することが多い）
  - 人員アサイン方針決め・招集（何人で対応するか？誰が何を対応するか？何時から開始か？など）
    - 該当する対応者が非番の場合、誰が土下座してお願いすることになるか
    - メンバの連絡先へCallして繋がるかどうか、連絡手段の確定等
メンバ内で認識合わせ
- メンバ内でミーティングを実行（対面でもリモートでも）
- 各メンバの役割分担発表、連絡体制認識合わせ
- 手順のすりあわせなど
手順書作成
- メンバ間で決めた役割分担に従い、コマンド実行順序などを作成
  - 想定できる定常外実行手順も実はこの中にある程度盛り込む（確認手順実施の上、そこから外れた場合に、実際には問題ないケースだったり、本当に問題だったりするケース別に対処法・判断基準を記載することが多い）
- メンバ間レビューで誤り等修正、必要確認事項の追加等
- 必要な場合は顧客にも手順を展開して、どのあたりで連絡するか、何を実行してもらうかのすりあわせを実施
- 手順書FIXしたら一旦作業開始時間まで待機

実際に作業する段階になったら

以下のような感じで作業に入ります。

作業実行
- 役割に従って作業実行（出来れば最低でもツーマンセル）
  - 基本オペレータ役はバカになってチェッカーの言う指示に従って操作を実行
  - チェッカーは同時にオペレータの制御役となって、実行結果の確認、手順のガイド
  - ツーマンセルじゃない場合は結構大変（頭の切り替えが）
- マイルストーン到達時はチェッカーが連絡役となって責任者間と連絡実行
- 責任者は進捗の把握、プラン逸脱がないかのチェック、顧客間の連絡調整役となって動く
- 作業手順からの逸脱はNG。想定外事象が発生したら連絡体制に従い報告、顧客調整が必要な場合は顧客指示を仰ぐ
作業完了
- 作業完了したら責任者は内部メンバ・顧客と連絡を取り、作業完了を通知
- 場合によっては、サービス開始時刻あるいはエンドユーザが一定数操作してる間まで待機を命じられる場合がある
- 情報収集の漏れがないかどうかの確認、あれば顧客承認のもとで再採取を実施

実作業と事前作業を比べると

やることの内容は圧倒的に事前準備作業の方が多いのです。
何故そうなるかというと、ぶっつけ本番作業はtypoしたらTHE ENDになる場合があるからです。それと、判断ミスが本当に増える。

想定外事象が起きたとき、とっさの機転で何とかするケースもありますが、それは事前に様々な想定ケースが準備段階である程度ピックアップできていて、操作手順内にその判断パターン、その場合の対処法が記述されてるからです。大体オペレーションそれ自体をしてる場合は、私でも結構淡々と実行するだけの機械みたいな感覚で実機は操作します。（逆にチェッカーがいい加減なことをすると致命傷になることがあります）

「PHPなんてaptでアップデートしたら一発じゃーん」な訳がないのです。PHPそれ自体はアプリケーションプラットフォームというアプリケーションを動かす土台に過ぎず、その土台を差し替えることでアプリケーションが互換性を失い、動作しなくなるリスクがあるケースはわんさかありますし、私たちが手順を考える以前の段階で、アプリケーションベンダーはその問題がないことの確認をしなければならないからです。

場合によっては、ある意味博打で臨まなければならない場合もありますし、その博打が失敗した後のプラン検討も必要になるケースさえあります。