SCS★3の準備を始めて気付いた――「バックアップがある」と「戻せる」は同じではなかった
SCS★3の準備を始め、クラウドにバックアップがあっても昨日の状態へ戻れるとは限らないと気付きました。世代管理と物理バックアップを加え、戻し方を一つにしないまでの思考の記録です。
以前、この技術ノートで、「要求される前に、SCS★3を目指してみようと思う」と書きました。
そのときは、まだ「これから要求事項と自社の状態を照らし合わせてみる」という段階でした。
今回は実際に、2026年9月時点で公表されているSCS★3の要求事項・評価基準を見ながら、自社で何ができていて、何が足りないのかを一つずつ確認し始めました。
始める前は、少し構えていました。
当社には、二段階認証、端末のセキュリティ対策、UTM、社内NAS、クラウドへのバックアップなど、必要に応じて入れてきた仕組みがあります。SECURITY ACTION二つ星や、事業継続力強化計画にも取り組んできました。
それでもSCS★3を目指すなら、さらに高価なセキュリティ製品をいくつも追加しなければならないのではないか。そんなイメージを持っていました。
ところが、実際に確認を始めてみると、今のところ大きく不足しているのは機器ではありませんでした。
すでにやっていることを、会社のルールとして整理できていない。
こちらの方が大きいように感じました。
「分かっている」と「管理できている」は違う
例えば、社内で使っているPCやNAS、ネットワーク機器、クラウドサービスについては、日常業務の中で把握しています。
少人数の会社なので、「誰がどの端末を使っているか」「どんなサービスを契約しているか」「どこに問い合わせればよいか」と聞かれても、普段はそれほど困りません。
ただ、それをIT資産台帳として一覧にしているかというと、そうではありませんでした。
ここで最初に気付いたのが、頭の中で分かっていることと、会社として管理できる状態になっていることは違うということです。
大げさな資産管理システムを入れるつもりはありません。それでも、使用している端末や社内機器、クラウドサービス、利用者、管理者、契約先、保守状況くらいは一覧にしておいた方がよさそうです。
これはSCS★3のためだけではありません。PCの更新や契約管理、障害時の確認、担当者が不在のときの引き継ぎ、BCPにもそのまま使えます。
認定のために新しい仕事を増やすというより、今まで人の頭の中にあったものを、会社の情報へ移していく。
まずは、そんな作業なのだと思いました。
バックアップなら、クラウドで十分だと思っていた
もう一つ、考え方が大きく変わったのがバックアップでした。
当社では以前から、業務データを社内NASに保存し、さらにクラウドにもバックアップしています。会社のDXやBCPを考えるときも、基本的には「NAS＋クラウド」という構成を前提にしてきました。
クラウド側には保存容量にも余裕があります。
事務所内の機器に障害が起きても、別の場所にデータが残る。火災や盗難などでNASそのものを失ったとしても、クラウド側にデータがある。
そう考えると、私はかなりクラウド寄りでした。
バックアップの保存先なら、もうクラウドでよいのではないか。
正直なところ、そう思っていました。
今でも、別の場所にデータを残すという考えが間違っていたとは思いません。クラウドがあるから助かる場面は、実際にあるはずです。
ただ、SCS★3の準備を進める中で、「バックアップがあるか」ではなく、実際にどう戻すのかまで考え始めました。
そこで、少し引っかかりました。
当社のクラウドバックアップは、比較的新しい状態のデータを別の場所にも残しておくためのものです。完全な自動同期にはせず、誤った操作まで即座に反映されないよう、タイミングを見ながらバックアップしてきました。
自分では、かなりバックアップを意識しているつもりでした。
では、昨日の状態に戻せるのか。数日前の状態に戻せるのか。
そう考えると、話は別でした。
誤って上書きした状態をバックアップ先にも反映してしまえば、以前の状態が残っているとは限りません。削除についても、運用方法によってはバックアップ側へ反映されます。
今のバックアップでは、昨日に戻れないかもしれない。
バックアップがあることと、過去の状態へ戻れることは同じではありませんでした。
「バックアップを取っているか」ではなく、「どの時点まで戻れるか」。問い方が変わるだけで、今までできていると思っていたことが、急に途中までに見えてきました。
ここで初めて、「世代管理」を自社の問題として具体的に考えることになりました。
クラウドで世代管理するより、NASに追加した方が簡単ではないか
SCS★3の準備で確認したIPAの「中小企業の情報セキュリティ対策ガイドライン」第4.0版には、バックアップの対象や取得間隔だけでなく、保管場所、世代管理、保管期間、復旧計画、正しく復旧できることの確認まで出てきます。
世代管理が必要なら、最初はクラウド側でやればよいと思いました。
クラウドには十分な容量があります。複数の時点のデータを残す仕組みも、技術的には作れます。わざわざ物理的なバックアップ機器を増やす必要はないように見えました。
ただ、今の運用へ本格的な世代管理まで加えようとすると、保存先の分け方や履歴の管理、戻すときの手順が少し複雑になります。
そこで思ったのが、
NASにバックアップ用のHDDをつないだ方が、簡単なのではないか。
ということでした。
既存NASの機能を使えば、社内に複数世代のバックアップを残せます。何かあったときも、インターネット経由ですべてを戻すより、社内にデータがあった方が早く戻せる可能性があります。回線の状態にも左右されにくくなります。
特に、現在進行中の仕事を早く再開したい場面では、その差は小さくないと思います。
そこで今回は、既存NASの機能を使い、物理的なバックアップ機器を一つ追加することにしました。
クラウドに十分な容量があるのに、それでも物理バックアップを追加する。
一見するとクラウドから逆戻りしたようにも見えます。でも、クラウドをやめるわけではありません。
クラウドとは別に、昨日や数日前へ戻れる場所を社内にも作る。今回は、こちらの方が当社には分かりやすく、運用しやすいと判断しました。
速く戻すだけでなく、戻し方を一つにしない
物理的な世代バックアップを追加する意味は、戻す速さだけではありませんでした。
ファイルを誤って上書きしただけなら、社内の世代バックアップから戻す。**NAS本体に問題が起きても、バックアップ用HDD側のデータが無事なら、そこから復旧する選択肢が残る。**火災や盗難で事務所内の機器そのものが使えなくなれば、クラウドから戻す。
インターネット回線に問題があるときは、社内のバックアップを使えるかもしれません。逆に、社内の機器をまとめて失っても、クラウド側にはデータが残ります。
つまり、何か起きたときに、戻す方法を選べるようにしておくということです。
この見方をすると、NASのRAIDについても整理できました。
RAIDは、NAS内部のディスクが故障したときに、すぐ業務が止まるリスクを下げるためのものです。しかし、ファイルを誤って削除したり上書きしたりすれば、その操作はNAS上のデータに反映されます。NAS本体の故障や、事務所全体の事故にも、RAIDだけでは対応できません。
RAIDはディスク故障。
世代バックアップは誤削除や上書き。
クラウドは事務所側の機器を失ったとき。
こうして見ると、同じデータを守る仕組みでも役割が違いました。
さらに調べていく中で、CISAが紹介する「3-2-1ルール」も知りました。元データを含めて三つのコピーを持ち、二種類の異なる媒体を使い、そのうち一つを別の場所に置くという考え方です。
先に3-2-1へ合わせようとしたわけではありません。昨日へ戻れるようにしたい、早く戻したい、戻し方を一つにしたくないと考えていった結果、今回の構成がその考え方に近づいていました。
自分たちで困りそうな場面を順番に考え、その後で調べてみたら、すでに名前の付いた考え方があった。今回は、その順番でした。
単にコピーの数を増やせばよいのではなく、同じ事故ですべてを失わないこと。そして必要なときに、本当に戻せることが大切なのだと思います。
全部を同じ速さで戻す必要もなかった
戻し方を考えていくと、もう一つ気付いたことがあります。
当社には、現在進行中の業務データだけでなく、これまで蓄積してきた資料や参考データもあります。どれも大切ですが、災害や障害の直後に、すべてを同時に戻さなければ仕事ができないわけではありません。
まず必要なのは、今動いている仕事です。
現在進行中の業務データを最初に戻す。次に直近の業務資料や共通資料。その後で過去の蓄積資料を戻す。
そう考えれば、長年の資料すべてを数時間以内に戻せる仕組みを作る必要はありません。最初に仕事を再開できる状態を作り、その後で順番に戻せばよい。
「何を守るか」だけでなく、「何から先に戻すか」も決めておく。これは、以前取り組んだBCPともそのままつながる話でした。
ただし、順番を決めただけでは十分ではありません。
少し前に、会社の通常PCと社内LANを使わず、別のPCとスマートフォンのテザリングだけで、クラウド上の業務データへ接続する訓練を行いました。そのとき確認できたのは、データへ到達できるところまでです。
今後は、世代バックアップから実際にファイルを戻すことも試さなければなりません。誰が作業するのか、担当者が不在でも手順が分かるのかも確認する必要があります。
設定画面で「正常」と表示されていることと、必要なファイルを仕事へ戻せることも、同じではありません。
バックアップ機器を追加した。世代管理を設定した。クラウドにもデータがある。
それだけで終わらせず、本当に戻せるところまで一度試してみる。
バックアップがあることと、復旧手順を実行できることの間にも、まだ一段あります。
最後に残ったのが「管理の型」だった
もちろん、SCS★3の準備はまだ途中です。
IT資産の一覧化もこれからです。インシデントが起きた場合の対応手順、情報の分類、アカウント管理、訓練や記録など、整理しなければならないことも残っています。SCS★3を取得できるかどうかは、まだ先の話です。
それでも、ここまで進めてみて感じているのは、少なくとも当社の場合、最初に想像したほど「新しい機器を買い足す話」ではなかったということです。
すでに行っている対策は、思っていたよりありました。
ただ、それが人の頭の中にあり、会社のルールや手順になっていなかった。バックアップも、保存するところまでは考えていても、いつの状態へ、どこから、どの順番で戻すのかまでは決めていませんでした。
足りなかったのは、機器よりも、そうしたことを会社の仕組みにするための**「管理の型」**だったのだと思います。
少人数の会社なので、複雑な仕組みにはしたくありません。
今あるものをできるだけ使う。人の手間を増やさない。必要なところだけ補う。そして、実際に何か起きたときに使える状態にする。
今回も、新しい機器を導入すること自体が目的ではありません。
クラウドに十分な容量があるのに、それでも物理バックアップを追加する。考えていたのは容量ではなく、実際に戻れるかどうかでした。
ディスクが壊れても止まりにくいこと。
過去へ戻れること。
早く戻れること。
そして、戻し方を選べること。
認定を取ることそのものよりも、認定を目指した結果、実際に少し強い会社になる。
今回も、その方向で進めていこうと思います。