続々・DR・BCPの目的は「復旧すること」ではありません

皆様こんにちは。
今年の立秋は8月7日だったそうです。
京都だけかも知れませんが、よく言われるのが「祇園祭が終わり（祇園祭は7月丸々ひと月かけて行われるお祭りです）、土砂降りの雨が降り、蝉が鳴き始めたら夏」と言われます。
今年は本当にそのとおりになりました。そして、立秋あたりから少し暑さがマシになりましたね。
よく出来ているものですね。

さて、じゃあ前回の続きを行きましょうか。
一応このシリーズは今日で最後にしたいと思っています。

ランサムウェアから復旧したが取引先への連絡ができない

サーバーは戻りました。でも顧客連絡先が暗号化されたまま。電話番号も分からない。営業担当は

「誰に連絡すればいいんだ？」

となります。代表電話にかけるのも大仰ですし、業務用の携帯電話番号はわからないかも知れません。自社の業務用携帯電話に登録してあるか、あるいは最低限通話履歴が残っているといいんですけどね。

サーバーに保存されているデータというと、売上や顧客情報ばかりを考えがちです。しかし、取引先の連絡先も立派な業務データです。

なお、携帯電話を狙うランサムウェアというのも存在します。サイバー攻撃者にとっては小さな獲物なのでしょうが、数を打てば当たるなのか細かく稼ぐ作戦なのか、実際に被害報告例も出ています。

小さな会社様だと、従業員の個人用携帯電話を業務に用いている例もあるかも知れません。でも、そもそも論ですがこれはやめた方がいいように思います。個人用の連絡手段を業務に使い回すということをやっていると、社外秘の情報をなにかの間違いで外部に送ってしまうということも起こりえます。それをやって社外には極秘の情報を流してしまったばかりに、首を切られた上に10億単位の損害を会社に与えた、なんていう事例も報告されています。携帯電話に限らず、業務用と個人用の境界線を明確にしないのはあまり好ましいことではありません。まあ、これはあくまでも余談でした。

少し話題が逸れましたが、連絡先データのバックアップも取っておいた方がいいという結論に至ります。これはもう、この文章のテーマでもありますね。昔ながらの、紙で出来た電話帳を用意しておくというのもひとつの手ではあると思います。

POSは復旧したが決済端末が動かない（店舗）

これは主に店舗でしょうか。

支払い方法の多様化により小規模な店舗でも複数の支払い方法に対応するのが当たり前になりました。

というわけですので、レジをまず復旧させたとします。起動が確認できました。レジは動いた。しかし、決済端末が動かない、ということも考えられます。

いまは現金は最小限しか持ち歩かないという人も多くなりました。こうなると「不便な店」ということになってしまい、商品はよくても販売実績に響く可能性があります。

「現在、現金しか使えません」となったときに、客離れが懸念されます。お客様が現金しかお持ちでないという事態も想定しておかなければいけませんし、店側でお釣り用の硬貨などがあるか、ということもひとつの問題になってきます。店側の準備は整えられても、お客様の準備は整っていないかも知れません。

お客様に逃げられても仕方がない、ということにもなりかねません。

なお余談ですが、私は二郎系ラーメン好きですが、二郎系で現金払い以外の支払いが出来る店を私は知りません。あれってひとつのコンセプトなのかな？

工場

生産管理サーバーは復旧しました。
でもPLCとの通信設定が戻っていません。従って、機械は動きません。

「サーバーは正常です」

と言われても、工場は止まったままです。
なおPLCというのは、工場の機械や設備をプログラムに従って制御するための産業用コンピュータです。

一般的なPCを使った生産管理システムとは違い、工場や設備の過酷な環境で安定して動作することを前提とした産業用の制御装置に位置付けられます。

リレー制御、マイコン制御、パソコン制御、DCSなど類似した概念がありますが、過酷な工場の環境に耐える専用の制御用コンピュータだとお考えいただきたいと思います。

この状態で「サーバーは正常です」と言われても、各機械を動かすPLCとうまくつながっていないのなら、製造を中止するしかありません。ここの連携を取り戻してはじめて「復旧した」と言えます。

というわけでいろいろ見てきたわけですが

たとえばこんなことも起こり得ます。

バックアップからサーバーを復旧することには成功しました。
ところが、誰がどの順番で何を起動するのか決まっていませんでした。
Active Directory、DNS、ファイルサーバー、業務システム……。
一つひとつは復旧しているのに、全体として業務が動かない。
「システムは復旧したのに、仕事ができない」という状態です。
だから私は、「復旧手順書」と「復旧テスト」が必要だと考えています。

また
「サーバーは復旧しました」
そう聞けば、多くの人は安心するでしょう。
ところが実際には、社員全員が「ログインできません」と立ち尽くしていることがあります。
原因は、認証サーバーより先に業務システムを起動してしまったことでした。
システムの復旧と、業務の再開は同じではありません。

ですので、トラブルからの復旧は「サーバーの復旧」ではなく「業務の再開」が目的であるという結論に達するわけです。

今日も2000文字に達しました

というわけで今日も2000文字に達しました。
「DR・BCPの目的」シリーズは一応今回で終わりにしようと思います。
今回の「目的」シリーズを具現化する上で必要になってくるのが復旧手順書になるわけですが、この話を次回以降お話ししていきたいと思います。
本日はここで終わりです。

あとは毎度のお知らせですが

フォームのご紹介です。

5分でわかる DR/BCP体制 危険度チェック

バックアップの取得状況や復旧体制などについてご回答いただくことで、
現在のDR/BCP体制を簡単にセルフチェックできます。

「バックアップは取っているけれど、本当に十分なのだろうか。」

そう感じられた方は、ぜひ一度お試しください。

また、より詳しいご相談をご希望の方には、お困りごと相談フォームもご用意しております。

こちらは基本無料、人間による回答となります。
バックアップ運用、リカバリテスト、データ復旧、DR/BCP体制の構築など、お気軽にご相談ください。

このnoteの質問箱からのお問い合わせも歓迎いたします。

LinkedInなんかもぼちぼちやっております。

https://www.linkedin.com/in/tadaomurashima/

時々ご覧いただければ幸いです。

前回、配信をやってみようというお話をしましたが、現状8月20日の20:00から30分程度を予定しております。
17LIIVEというところで、名前は「ゆひろ_0606」です。
もしよろしければご覧下さい。

このnoteも長い間記録を行ってきたことになりますが、目次を貼っておきますので、他の記事もご覧になってください。

では今日はこの辺で。