BCP（Business Continuity Planning）とは
BCPとは「事業継続計画」
BCPとは、Business Continuity Planningの略称で、「事業継続計画」と訳されます。何らかの理由で事業活動に使用するインフラなどの資産が使えなくなった場合に、できるだけ早く、できるだけ平常時に近い形で事業を再開する、あるいは事業を止めずに継続するための計画です。
BCPの概念自体は比較的古く、1960年代以降、コンピュータシステムの普及とともに登場したと言われています。企業がコンピュータシステムを利用して事業を展開するようになると、何らかの理由でシステムが故障したり、停止したりしても事業が継続できるように、BCPに力を入れるようになりました。
DR（Disaster Recovery）との違い
似たような意味でDRという言葉が使われていますが、DRとは、Disaster Recoveryの略称で、直訳すると「災害復旧」となります。主に情報システムやデータに焦点を当てた災害復旧対策のための計画のことを指します。
DRが主に「洪水や地震などの自然災害からの復旧（サイバー攻撃やテロも含まれる場合がある）」を目的としているのに対し、BCPは「事業活動の継続」を目的としているため、その意味は「復旧」に限定されず、広く包括的です。
本来のBCPは「事業継続計画」の通り、万が一の災害や緊急事態が発生した時にどの事業/業務を継続させる必要があるか、というところから計画を進め、システムだけでなく人・物・情報等の在り方を検討しますが、今回はそのなかでも、「システムやデータをどう守るか」「早期復旧をどう実現するか」、この2点を中心に解説していきます。
BCPでのバックアップの重要性
情報を洗い出し、保護・復旧対象を定める
緊急時にシステムやデータをできるだけ遅滞なく業務遂行に利用できるようにするため、どのようなシステムやサーバー、どのようなデータを保護・復旧するかによって、BCPの対策は異なっていきます。
BCPの策定において、システムやデータを保護・復旧するための「バックアップ」は重要な要素です。BCPがどのような事態を想定しているのか、保護・復旧するシステムやデータの種類によって、必要なバックアップ方法は変わってきます。例えば、サイバーテロからデータを守り、緊急時に復旧させるためのBCPであれば、元のサーバーとバックアップサーバーの物理的距離は問題にならないかもしれません。しかし、大規模災害への対応を前提としたBCPでは、新宿の本社にあるサーバーを渋谷でバックアップすることはあまり意味がありません。
システムの復旧だけではなく、事業継続の要件を考えるべき
一例を説明します。東京に本社があり、全国でコールセンター事業を展開するA社があります。ある時、東京が大規模災害に見舞われ、東京の拠点が大きな被害を受け、事業の継続が難しくなりました。該社はコールセンターなので、事業を継続するためには、電話の受付対応を東京以外で受けられるようにする必要があります。A社は大阪にも大きなコールセンターがあるので、東京のコールセンター宛ての電話を大阪のコールセンターに転送したり、またコールセンターのオペレーター人員を増強したり、さらには電話受付の管理システムを大阪のコールセンターで一元的に集約するなどの対応が必要になります。
このとき、受付管理システムの復旧を考えた場合、データの完全復旧が必須なのか、お客様からの問い合わせに対して過去の問い合わせデータを参照できればよいのかで、復旧方法が異なります。また、復旧レベルも完全復旧が必要なのか、部分復旧が必要なのかによって、復旧対策やバックアップ対策も異なります。これらを検討する上で、3つの基準が存在します。
復旧における3つの基準
システムやデータのBCPやDR計画を策定する際には、RPO、RTO、RLOをどのように設定するか、どの指標を重視するのかといった基準づくりも重要になります。
RPO（Recovery Point Objective）「いつまで遡るのか」
RPOとは、Recovery Point Objectiveの略称で、日本語では「目標復旧時点」と訳されます。つまり、「どこの時点まで遡って、システムやデータを復旧させるのか」という指標です。1か月前に遡るのか、1日前に遡るのかといった遡及ポイントを表します。
RTO（Recovery Time Objective）「いつまでに復旧するのか」
RTOとは、Recovery Time Objectiveの略称で、日本語では「目標復旧時間」と訳されます。つまり、BCPあるいはDRの発動によって、「どのくらいの時間をかけて、必要な復旧を果たすのか」、という指標です。BCPやDRが発動してから、12時間以内の復旧を目指したり、24時間以内の復旧を目指したりと時間を表します。
RLO（Recovery Level Objective）「どの程度復旧するのか」
RLOとは、Recovery Level Objectiveの略称で、目標復旧レベルと訳されます。レベルとは、元のシステムやデータと比べて、「何%ぐらいのレベルで復旧できているか」という指標になります。80%程度のレベルで良いのか、95%以上の復旧が求められるのか、といったことを設定します。
RPOはできるだけ直近の方がよく、RTOは短時間であればあるほど良く、RLOは100%に近ければ近いほど良いということになります。
たとえば、RPOを6時間程度に設定すれば、6時間に1回はバックアップが必要ということになり、1日に4回はバックアップを実施するということになり、負荷が増える分、コストもアップします。RTOもRLOも同様です。
要件が高ければコストも増大する。バランスをみた設計を
RPO、RTO、RLOをどこに設定するかは、その企業の事業内容によって異なります。例えば、社会インフラに近いビジネスであれば、より高い要件が必要になります。しかし、この復旧要件が高いほど、必要なシステム要件も高くなり、コストも増大します。
ある企業では、有事の際に半日以内にBCP環境に切り替えることを前提とし、RLOも100%に近いレベルを求めましたが、バックアップ側でも本番環境と同レベルの規模・パフォーマンスのシステムを用意する必要があり、投資額もかなり大きいものになりました。
BCP環境への切り替え方や運用方法について
BCPの策定と対応の実施にあたっては、バックアップをどうするかということが重要ですが、それと同時に、通常のシステムから、BCP環境への切り替えをどのように行うか、また、単にシステム的な切り替えだけでなく、業務遂行そのものをどう切り替えていくのかということも、BCPでは計画化されている必要があります。
ランサムウェアへの対応
これまで大規模広域災害などを例としてあげていましたが、忘れてはならないのがランサムウェアなどのサイバー攻撃対策です。サイバー攻撃に対するBCP対策は、広域災害とは別で考える必要があります。
バックアップだけでは安心できない
サイバー攻撃は日々、悪質化・巧妙化しています。例えば、ランサムウェアの感染がいつ発生したかを特定することが困難なケースもあります。バックアップがあったとしても、その時点を特定するだけでも数日かかってしまうこともあります。バックアップが数世代しかないと、最悪の場合、バックアップデータがすべて使えなくなることも考えられます。
そうした事態への対応としては、ネットワークと隔離した媒体（テープやクラウド環境）を使ってバックアップを取るという対策もあります。また、同じディスク内であったとしても、バックアップ先の領域については、完全にシステム改変できないようにしてしまうという対策も有効です。
バックアップがあるということで安心せずに、それ以外の対応策を講じておくことが肝要であり、しっかりとしたランサムウェア対策を構築できているかどうかが、BCPの有効性を左右するといっても過言ではありません。
ランサムウェアを検知する仕組みを導入する
前述の通り、いつランサムウェアに侵入されたのかが不明の状態では、バックアップデータを活用して復旧を試みるにしても、どの時点のバックアップデータが活用可能なのかを特定するまでに、相当の労力と時間を要することになります。そのため、バックアップの世代についても、かなり遡ったものも保管しておく必要がありますし、バックアップをとる頻度も可能な限り高める必要があります。しかし、バックアップの世代を長期間にわたって保管しておくのも、データの容量によっては、かなり負荷となります。
そのような場合には、ランサムウェアを検知する仕組みを導入することで、そうした問題を解消することができます。
現在では、ストレージシステム上で、クライアントからのファイルやデータへのアクセスを監視し、ランサムウェア攻撃に近い動きが感知されると、瞬時に警告を発することができる機能や、AIを活用して定期的に行われるバックアップの情報量の変化を捉えて、ランサムウェア攻撃を検知し、安全なリストアポイントを通知してくれる機能などランサムウェアに向けた機能をもったストレージ製品が数多く存在しています。これらを組み合わせることでより高いサイバー攻撃対策を実現することが可能になります。
最後に、ランサムウェア対策を「検知」「保護」「復旧」「アフターケア」の4つの観点から解説をしている特設ページ（ランサムウェア対策特集）もご用意しておりますので、あわせてお読みください。
