第8話「事件後も会社は動く ~BCP・BCMとインシデント対応~」

  • URLをコピーしました!
高瀬里見

今回は「止まらない会社」の仕組みを学んでいこう。

目次

📖 用語まとめ表

頑張って覚えていきましょう!攻撃を受けても倒れない組織のつくりかた、一緒に見ていきます。

用語(略語)読み方一言説明身近な例え
BCPビーシーピーBusiness Continuity Plan。事業継続計画。災害・攻撃時でも業務を続けるための計画書学校の「緊急時は体育館に集合」ルール
BCMビーシーエムBusiness Continuity Management。BCP+訓練+改善。計画を活かし続ける活動全体毎学期やる避難訓練と、その後の見直し作業
RPOアールピーオーRecovery Point Objective。目標復旧時点。どこまで遡ってデータを戻すかの目標値「昨日の授業ノートまでは絶対復元できるようにしておく」
RTOアールティーオーRecovery Time Objective。目標復旧時間。いつまでに復旧させるかの目標値「故障から2時間以内に授業再開」という約束
MTBFエムティービーエフMean Time Between Failures。平均故障間隔。どのくらい壊れずに動き続けるかスマホが「平均して何ヶ月に一度フリーズするか」
MTTRエムティーティーアールMean Time To Repair。平均修復時間。壊れてから直るまでの平均時間「フリーズしたスマホが再起動で直るまでの時間」
フェールオーバーフェールオーバー障害発生時に自動で予備システムへ切り替える仕組み工事中で通れなくなった道路の「迂回路」が自動で案内される感じ
ディザスタリカバリディザスタリカバリDisaster Recovery(DR)。災害時のシステム復旧対策の総称地震に備えた「非常用バックアップ倉庫」
インシデント対応手順インシデントたいおうてじゅん事故発生時の対応フロー(検知→分析→封じ込め→復旧→報告)救急対応マニュアルの「呼びかけ→119番→AED→救急隊員に引き継ぎ」

🔍 結城の偵察

結城美雪

BCPがある…なら、その数字を狙えばいい。

深夜二時。結城のデュアルモニターには、メタ・クローディア(メタC)の公式ブログと、とあるIT系メディアの記事が並んでいた。

「メタCは昨年、BCPを整備した、か」

記事の見出しに目を走らせる。事業継続計画(BCP=Business Continuity Plan・ビーシーピー)——地震やサイバー攻撃が起きても、最低限の業務を続けるための計画書だ。最近はVRプラットフォームでも整備が進んでいると、業界紙に書かれていた。

「BCPがあるだけでは困らない。問題は、その中身だ」

結城がキーボードを叩く。目的はRTO(Recovery Time Objective・アールティーオー)とRPO(Recovery Point Objective・アールピーオー)の推測だ。

RTOは「障害から何時間以内に復旧するか」の目標、RPOは「どの時点まで遡ってデータを戻すか」の目標を意味する。この二つの数値がわかれば、どのくらいの時間だけシステムを止め続ければ壊滅的なダメージを与えられるかが、自然と見えてくる。

公開されているサービス稼働率レポート、過去の障害情報、インフラ構成の断片——結城は散在する情報を静かに繋ぎ合わせていった。

「……RPOは1時間以内、RTOは4時間以内、というところか。なら」

慎也の顔が、一瞬脳裏をよぎる。

「——4時間より長く、深いところを壊す必要がある。まだ急がなくていい。もっと丁寧に調べる」

モニターの光だけが、夜の部屋を照らしていた。

💬 慎也と里見の会話①

山本慎也

BCPって、訓練とかするの?初めて聞いた。

週末の昼下がり、慎也はソファで里見の隣に座りながら、スマホのニュースを眺めていた。

「……ねえ、里見。メタCって『BCP訓練』ってやつ、やるの?」

里見がノートパソコンから顔を上げる。「あー、やるよ。先週も佐藤さんが仕切ってた。なんで?」

「ニュースにあってさ。大きい地震のあと、IT会社がBCPで素早く復旧したって。読んでて、なんのことかよくわからなかった」

「慎也が知らないのも無理ないよ」と里見が笑う。「正直、セキュリティやってないと意外と触れない分野だから」

「でも大事なんだよね?」

「超大事。むしろ攻撃された後どうするかって、BCPがないと全部場当たりになる。ちゃんと教えてあげる」

高瀬里見

じゃあ、まずBCPとBCMの違いから整理しようか。

慎也がメモアプリを開く。里見が少しだけソファに近づいて、慎也の画面を覗き込んだ。

📘 里見の解説「止まらない組織のつくりかた」

高瀬里見

事件後も会社が動き続けるには、準備が全部だよ。

BCP(事業継続計画)

高瀬里見

BCPは「緊急時のシナリオ集」みたいなものだよ。

「BCP——Business Continuity Plan・ビーシーピーっていうのはね」と里見が言った。「地震とか、サイバー攻撃とか、火災とか、なにかヤバいことが起きたときに、最低限の業務を続けるための計画書なの」

「最低限って?」

「例えばメタCなら、ユーザーのデータは絶対守る、ワールドが完全に落ちても決済だけは動かし続ける、みたいな。全部は守れないかもしれないけど、一番大事なものは守る、っていう優先順位を決めておく文書」

「学校で言ったら、火事のときの『体育館に集合』みたいな?」

「そう、それがBCP。緊急時の行動マニュアルを事前に作っておくこと」

BCM(事業継続マネジメント)

山本慎也

BCPを作ったら終わりじゃないの?

「じゃあBCMは?」と慎也が聞いた。

「BCM——Business Continuity Management・ビーシーエム——は、BCPを作るだけじゃなくて、訓練して、振り返って、改善し続ける活動全体のこと」

「作って終わりじゃないってこと?」

「そう。BCPを棚に飾っておくだけじゃ意味ない。年に何回か訓練して、実際に動かしてみて、問題点を直して……って繰り返すのがBCM。さっき私が参加してた訓練も、BCMの一部だよ」

「避難訓練を年2回やって、そのたびに反省会してルートを改善する、みたいな感じ?」

「完璧な例え。BCPが地図で、BCMがそれを使い続ける活動全体」

RPO と RTO

高瀬里見

RPOとRTOは、数字で「どこまで許容するか」を決めること。

「BCPには必ず、二つの重要な数字が入ってるんだ」と里見が続けた。「RPOとRTO」

「RPO——Recovery Point Objective・アールピーオーは、目標復旧時点。システムが止まったとき、どこまで遡ってデータを戻すかの目標値。例えばRPOが1時間なら、最大1時間前の状態まで戻せればOKってこと」

「1時間分のデータは失ってもしょうがない、みたいな?」

「そう。それ以上遡る必要があるなら、バックアップの頻度を上げないといけない。そしてRTO——Recovery Time Objective・アールティーオー——は目標復旧時間。障害が起きてから、いつまでに復旧するかの目標値」

「RTOが4時間なら、4時間以内に直せばいい、と」

「完全に止まってる時間が4時間を超えたら、SLAの違反になったり、ユーザーが離れたりするから、この数字を守るために準備する。RPOとRTOが小さいほど守りが厚い分、コストもかかる」

山本慎也

数字が具体的だと、どこまで備えるべきかわかりやすいな。

「そういうこと。曖昧に『早く直す』って言うより、RTOが4時間って決まってるほうが、何を準備すべきかはっきりする」

MTBF と MTTR

高瀬里見

システムの「健康状態」を数字で表すのがMTBFとMTTR。

「似たような指標で、MTBF と MTTR ってのもある」と里見が言った。

「MTBF——Mean Time Between Failures・エムティービーエフ——は、平均故障間隔。システムが壊れずに動き続ける平均の時間のこと。MTBFが大きいほど、安定して動いてる」

「スマホが平均して半年に一回フリーズする、みたいな?」

「そう。そしてMTTR——Mean Time To Repair・エムティーティーアール——は、平均修復時間。壊れてから直るまでにかかる平均の時間。MTTRが小さいほど、復旧が速い」

「MTBFは壊れにくさ、MTTRは直しやすさ、って感じ?」

「まさに。システムの信頼性はこの二つで語られることが多い。MTBFを上げる努力と、MTTRを下げる準備の両方が必要」

フェールオーバーとディザスタリカバリ

高瀬里見

障害が起きたとき、自動で切り替わる仕組みがフェールオーバー。

「実際にシステムが壊れたとき、どうするかって話をしておこう」

「フェールオーバーっていうのは、メインのシステムに障害が起きたとき、自動で予備のシステムに切り替わる仕組み。工事で道が使えなくなったとき、カーナビが自動で別のルートを案内してくれる感じ。人が気づく前に切り替わってるから、ユーザーはほとんど気づかない」

「ディザスタリカバリ——DR——は、それより大規模な概念。災害や深刻な障害が起きたとき、システム全体をどうやって復旧させるかの対策全般のこと。バックアップサイトを別の地域に用意しておくとか、クラウドに切り替えるとか。BCPの中の、特にIT系の対策をまとめたものがDRだと思えばいい」

山本慎也

フェールオーバーって、サービスが止まってないのに裏で動くんだ。

「そう。メタCでも実際に動いてる。ユーザーが何も知らないまま予備サーバーに切り替わってる、ってことが定期的にある」

インシデント対応手順

高瀬里見

何か起きたとき、誰が何をするか決めておくのが大事。

「最後に、インシデント対応手順。何かセキュリティ事故が起きたとき、どう動くかの手順のこと」

「フローがあるの?」

「あるよ。大きく5段階」

  1. 検知 ——問題が起きたと気づく
  2. 分析 ——何が起きているか調べる
  3. 封じ込め ——被害が広がらないように止める
  4. 復旧 ——元の状態に戻す
  5. 報告 ——関係者や、場合によっては外部に報告する

「救急対応みたいだな。呼びかけて、119番して、AEDして、救急隊員に引き継ぐ、みたいな」

里見がにっこりした。「その例え、すごくいい。正解。慌てずに順番通りやることが、被害を最小化する一番の近道なの」

高瀬里見

手順がなかったら……2週間止まったままになることもある。

里見が少し、声のトーンを落とした。

「実際にね、こういう話がある。ある会社が攻撃を受けて、マイニングソフトを埋め込まれたの。そのまま2週間、サービスを止めることになった」

「2週間……」

「攻撃されることを、まったく想定していなかった会社だった。BCPもなかった。インシデント対応の手順もなかった。だから、何が起きているのか把握するところから始めなきゃいけなくて、誰に連絡すべきかも決まってなくて、気づいたら専門家に丸投げするしかなくなっていた」

慎也は黙った。

「2週間、サービスが止まってる間に、ユーザーは離れていく。信頼は壊れていく。売上は消えていく。それが全部、『手順がなかった』ことの代償なんだよ」

「……怖いな」

「怖い話だよ」と里見が静かに言った。「でも、他人事じゃない。インシデント対応手順を作っていなかったら、メタCだってそうなってたかもしれない。この手順表は、2週間を2日に縮めるために存在してる」

⚡ 攻撃の影

佐藤隆

サーバー負荷が急に上がってる。パターンが気になるな。

その夜。佐藤のモニターに、メタCの監視ダッシュボードが広がっていた。

「……また来てる」

特定のAPIエンドポイントに向けて、断続的な高負荷リクエストが届いていた。攻撃というには規模が小さい。DoSでもない。まるで、システムがどう反応するかを丁寧に確かめているような、静かなノック音だった。

発信元のIPは分散されており、一つを弾いても別のIPが引き継ぐ。ボットを使った自動化ではなく、人間の手で操作されているような、微妙に揺らいだタイミングのズレが感じられた。

「試されてる」

佐藤は静かにつぶやいた。RTOとRPOの境界を探るような攻撃——フェールオーバーが発動するかどうか、確かめようとしている。今すぐ壊すつもりはない。ただ、どこまで押せば切り替わるかを観察している。

そういう動き方を、佐藤は知っていた。

🛡️ チームの対応

佐藤隆

BCPに従って動く。フェールオーバーを手動でも確認しておこう。

佐藤はすぐに里見に連絡を入れた。

「今夜、特定エンドポイントへの断続的な負荷が記録されてる。攻撃というより偵察の動き。フェールオーバーの動作確認をしておきたい」

里見がノートパソコンの前に座り直す。慎也はその横に座って、画面を見守った。メタCのスタッフではないが、さっきまで学んでいた言葉が、目の前でリアルに動いていた。

「フェールオーバー、テスト実行します」

里見がコマンドを走らせると、メインのAPIサーバーが予備系に自動切り替えを開始した。数秒のラグで、ダッシュボードの表示が切り替わる。

「切り替え完了。RTOの目標内に収まってる」

佐藤が確認する。「問題なし。RPOの範囲内でバックアップからのリストア確認も取れてる」

インシデント対応手順に従い、佐藤は検知・分析・封じ込めの記録をCSIRT内部のチケットシステムに入力していった。被害なし。ただし、攻撃者の意図は明確だった。

「誰かが、うちのRTOとRPOを測ろうとしてる」

佐藤が静かに言った。「次は、もっと深いところを狙ってくる可能性がある」

山本慎也

さっき里見から習ったことが、全部実際に動いてた……。

慎也は言葉を失いながらも、メモに「検知→分析→封じ込め→復旧→報告」と書き留めた。

💬 慎也と里見の会話②

高瀬里見

準備ってね、地味だけど一番頼りになるんだよ。

深夜、二人でキッチンでお茶を淹れながら、慎也がぽつりと言った。

「今夜、俺がさっき習ったこと、全部本物だったな」

「そうだよ」と里見が答えた。「BCPもフェールオーバーも、実際に動いて初めて意味がある。作って棚に入れてたら意味ない」

「でも……攻撃する側は、そのBCPの中身を読もうとしてるわけだよね。RTOとかRPOとか」

里見がうなずいた。「攻撃側から見たら、RTOが4時間なら、4時間と1分だけ止めれば目標達成、って計算になる。だから守る側は、数字を公開しないことも大事だし、その数字を実際より早く達成できるように準備する」

「いたちごっこだな」

「永遠にね」と里見が笑った。「でも備えがある側と、ない側では、被害の差が全然違う。BCMって、その地味な積み重ねなんだよね」

慎也がマグカップを両手で包んだ。

「里見が毎週訓練に参加してるの、そういうことだったのか」

「そういうこと。私がBCM訓練に出てる間、慎也には待っててもらってたりしたもんね」

「いや、それは全然。……むしろ、ちゃんと理由わかった上で待てる方がいい」

里見が少し、くすっと笑った。

😤 結城の悔しがり

結城美雪

フェールオーバー……BCPが、本当に動いた。

深夜のモニターの前で、結城は画面のログを見つめていた。

APIへの負荷テストは、静かに弾かれていた。フェールオーバーが発動し、切り替えが完了している。RTOを測ろうとしたら、目標時間内に復旧されてしまった。

「……ちゃんと動いてる」

悔しさより先に、技術者としての率直な感嘆が来た。BCPを作るだけなら誰でもできる。だがBCMとして運用し、フェールオーバーを実際の障害で使えるレベルに保っていることは、相当の準備がなければできない。

おそらく、あの佐藤が仕切っている。

「……慎也は、今夜あの対応を間近で見たはずだ」

それが、結城には一番引っかかった。攻撃が防がれたことより、慎也が里見の隣で、あの現場を目撃しているという事実が。

「でも、これで終わりじゃない」

結城は新しいメモファイルを開いた。BCPで守れるのは、可視化された脅威だけだ。次は、もっと深いところを狙う。ログの中に残る痕跡。証拠を消す技術。次話への布石を、結城は静かに書き記していった。

「ログを制する者が、この戦いを制する」

この記事が気に入ったら
いいねしてね!

よかったらシェアしてね!
  • URLをコピーしました!
  • URLをコピーしました!

コメント

コメントする

目次