高瀬里見今回は「止まらない会社」の仕組みを学んでいこう。
📖 用語まとめ表
頑張って覚えていきましょう!攻撃を受けても倒れない組織のつくりかた、一緒に見ていきます。
| 用語(略語) | 読み方 | 一言説明 | 身近な例え |
|---|---|---|---|
| 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段階」
- 検知 ——問題が起きたと気づく
- 分析 ——何が起きているか調べる
- 封じ込め ——被害が広がらないように止める
- 復旧 ——元の状態に戻す
- 報告 ——関係者や、場合によっては外部に報告する
「救急対応みたいだな。呼びかけて、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で守れるのは、可視化された脅威だけだ。次は、もっと深いところを狙う。ログの中に残る痕跡。証拠を消す技術。次話への布石を、結城は静かに書き記していった。
「ログを制する者が、この戦いを制する」






コメント