総務省がサイバー対策の義務化を検討。小さな会社も「対岸の火事」では済まない理由
小さな会社でも、管理用VMを残したまま公開RDPを減らし、作業PCごとのアクセス範囲と更新責任を整理できます。さらに、事業所の災害・停電・回線障害や固定IPへの依存を見直すことが、クラウド上の業務を続ける備えになります。
通信事業者への対策義務化は、まだ検討段階
2026年10月16日、総務省が通信事業者のサイバーセキュリティ対策を強化するため、有識者による検討会を設置すると発表したことが報じられました。
システムの脆弱性への迅速な対応や、委託先を含めた管理体制の強化などが議論される見通しです。
10月22日に初会合を開き、2027年夏をめどに報告書を取りまとめる予定で、法改正や新たな対策の義務化も検討対象となっています。
ただし、2026年10月17日時点で、今回検討されている新たな義務化が決定・施行されたわけではありません。
また、今回の検討は通信事業者を対象とするものであり、一般のSOHOや小規模事業者に同じ義務が課されるという話でもありません。
では、通信事業者以外には関係のないニュースなのでしょうか。
例えば、社員3人でAWSやAzure上にWebシステムを構築し、開発から運用まで手掛けている会社。
顧客情報を扱い、ソースコードを管理し、クラウド上でサービスを提供している。
そんな会社にとっても、不正アクセスや情報漏えい、サービス停止は決して他人事ではありません。
今回検討されている新たな義務の対象と決まっていないことと、セキュリティ対策をしなくてよいことは別です。
今回のニュースをきっかけに、小さな会社でも実践できるセキュリティ対策と、事業を止めないための備えについて考えてみます。
参照：読売新聞の報道（2026年10月16日、ライブドアニュース掲載）
セキュリティ対策は、いつまで「コストセンター」なのか
かつて、セキュリティ対策は「MUSTでなければ予算が取れない」と言われることが少なくありませんでした。
セキュリティは売上を生まないコストセンター。
何も起きなければ成果が見えず、対策の必要性を説明することさえ難しい。
対策費用を検討すると、こんな質問が出てくることもありました。
「事故が起きる確率はどれくらいなのか？」
「メールアドレスが1件漏えいしたら、被害額はいくらなのか？」
「対策に何百万円も使うくらいなら、事故が起きてから賠償した方が安いのではないか？」
もちろん、こうした考え方がすべて間違っているわけではありません。
限られた予算を合理的に配分するため、リスクの発生確率と影響額を評価することは、現在でも重要です。
しかし、問題は被害額の捉え方です。
過去には、大規模な個人情報漏えい事件で、対象者に1人あたり500円相当のお詫びの品が配布された例もありました。
ただし、この500円は個人情報1件の価値でも、一律の法的賠償額でもありません。
実際の事故では、原因調査、システム復旧、顧客対応、法的責任、再発防止など、さまざまな費用が発生します。
そして、もっと重要な問題があります。
賠償金を支払えたとしても、止まった事業を再開できるとは限らないことです。
社員3人の会社で、全員が事故対応に追われることになったらどうでしょう。
開発は止まり、顧客対応もできず、サービスの復旧にも時間がかかる。
もはや情報漏えいの被害額だけを計算して済む問題ではありません。
社員3人でも、クラウド上には守るべきシステムがある
例えば、次のような小規模なIT事業者を考えてみます。
社員は3人。AWSやAzure上で顧客向けWebアプリケーションを運用しながら、機能開発や保守も担当しています。
クラウド上には、次のようなシステムがあります。
- 顧客向けのWebアプリケーション
- 顧客情報を保存するデータベース
- 運用担当者向けの管理画面・API
- 開発・テスト用のサーバー
- ソースコードやCI/CDの環境
社員は事業所だけでなく、自宅や出張先からも作業しています。
この構成自体は珍しいものではありません。
しかし、それぞれのシステムについて、インターネットからどこまでアクセスできるのかを把握しているでしょうか。
顧客向けWebサイトは、当然ながら公開する必要があります。
一方で、SSH、RDP、管理用API、開発サーバーなどはどうでしょう。
顧客に公開する必要があるサービスと、開発者・運用担当者しか利用しないサービスでは、求められる公開範囲が違います。
本番環境だけ守れば十分なのか
特に注意したいのが、開発環境です。
開発環境だから重要な情報は存在しない、というわけではありません。
開発サーバーやCI/CDには、APIキー、クラウドの認証情報、デプロイ用の権限、ソースコードなどが存在する場合があります。
仮に開発環境が侵害されたとき、その認証情報が本番環境でも利用できるようになっていたらどうなるでしょうか。
攻撃者が本番環境にアクセスしたり、不正なプログラムをデプロイしたりする可能性があります。
そこで考えたいのが、開発環境と本番環境の分離です。
例えばAWSなら、本番環境と開発環境を別々のVPCに配置します。
AzureならVNetを分ける構成が考えられます。
さらに、環境ごとに認証情報やクラウドの権限を分離し、必要のない通信を許可しないようにします。
ここで重要なのは、ネットワークを分けるだけでは不十分という点です。
両方の環境で同じ管理者認証情報を使っていたり、開発環境に本番環境の強力なアクセス権限を与えていたりすれば、ネットワークを分離しただけでは被害の拡大を防げません。
MFA、最小権限、認証情報の管理なども組み合わせる必要があります。
固定IPと共有踏み台PC。よくある管理環境の構成
クラウド上のシステムを運用する現場では、固定IPアドレスからの接続だけを許可し、ネットワークの境界に踏み台PCを設置する構成が使われることがあります。
運用担当者はRDPで踏み台PCへ接続し、そこから本番サーバーやデータベース、管理画面などを操作します。
クラウド環境では、この踏み台PCもWindowsなどのVMとして構築されることがあります。
開発環境と本番環境のアクセスを分離するため、それぞれに専用の踏み台VMを設置する場合もあります。
この構成には一定の合理性があります。
アクセス元を固定IPに限定でき、管理対象のサーバーをインターネットへ直接公開せずに済むからです。
しかし、それだけで安全な運用が完成するわけではありません。
本番用と開発用に分けても残るリスク
仮に本番環境と開発環境で踏み台VMを別々にしたとしても、それぞれが外部からRDP接続を受け付けていれば、外部から到達可能な管理対象が残ります。
固定IPアドレスによる制限は有効な追加対策ですが、利用者本人の認証ではありません。
例えば、事業所の固定IPアドレスを許可している場合、同じ事業所ネットワーク上の端末が侵害されると、その許可された経路から踏み台VMへの接続を試みられる可能性があります。
また、踏み台VMには通常、管理用のブラウザやSSHクライアント、データベース管理ツールなどがインストールされています。
OSやRDPサービス、管理ツールに脆弱性が残っていれば、それらも攻撃対象になり得ます。
本番と開発を分離することは重要ですが、それぞれの環境に置いた踏み台VMそのものを、誰が継続的に管理するのかという問題は残ります。
セキュリティのために置いた踏み台VMが、更新できなくなる
共有踏み台VMには、特に現実的な問題があります。
それは、セキュリティパッチの適用です。
構築時には最新のOSをインストールし、アクセス元を制限し、本番用と開発用の踏み台VMも分けた。
ところが、半年、1年と経過するうちに、パッチの適用が後回しになってしまう。
単なる管理不足の場合もありますが、それだけでは説明できない事情もあります。
アップデートによって、今まで使えていた業務ツールが動かなくなるリスクです。
踏み台VMには、データベース管理ツール、開発ツール、古い業務システムに接続するための専用ソフトウェアなどがインストールされていることがあります。
OSを更新したことで、特定のツールが起動しなくなったり、接続できなくなったりする可能性があります。
しかも、その踏み台VMは本番システムの障害対応にも使われているかもしれません。
「セキュリティパッチを適用して、もし管理ツールが動かなくなったら？」
そう考えると、正常に動作している環境には手を加えたくない、という判断が生まれます。
しかし、更新しなければ既知の脆弱性が残り続けます。
守るために更新したい。しかし、業務を止めたくないから更新できない。
これは単なるパッチ管理の問題ではありません。
セキュリティ対策と事業継続性が衝突している状態です。
本番用と開発用の踏み台VMを分けていても、この問題は解消されません。
それぞれのVMについて、更新による互換性問題と、更新しないことによるセキュリティリスクを抱えることになります。
そして、誰が責任を持つのか分からなくなる
共有踏み台VMには、もう一つ厄介な問題があります。
管理責任の所在が曖昧になりやすいことです。
インフラ担当者はOSやVMを管理している。
開発担当者は、踏み台VMにインストールされたツールを利用している。
運用担当者は、本番環境の保守作業に使っている。
それぞれに担当者は存在していても、踏み台VM全体の維持管理について、最終的な判断をする人が決まっていないことがあります。
例えば、セキュリティパッチの適用です。
パッチを当てれば、業務ツールが動かなくなるかもしれません。
当てなければ、既知の脆弱性が残ります。
では、誰が更新を承認するのでしょうか。
更新後に問題が発生した場合、誰が復旧するのでしょうか。
更新を見送る場合、そのリスクを誰が評価し、いつまで許容するのでしょうか。
明確な責任者がいなければ、判断は先送りされがちです。
そして、正常に動いている限り、問題は表面化しません。
「動いているから触らない」が、いつの間にか運用方針になってしまう。
本番用と開発用で踏み台VMを分けていたとしても、この問題は残ります。
むしろ、管理対象が増えたことで、更新や障害対応の責任分担が複雑になる場合もあります。
クラウド事業者がVMのOSや導入ツールをすべて更新してくれるわけではありません。たとえばAmazon EC2の責任分担では、ゲストOSや導入ソフトウェアの更新などは利用者側の責任です。運用を委託している場合も、契約範囲を確認します。
セキュリティ対策として設置した設備を、誰が継続的に管理するのか。
それを決めないまま導入すれば、その設備自体が新たなリスクになり得ます。
セキュリティ対策は、導入した時点で完成するものではありません。安全に運用し続けられる体制まで含めて設計する必要があるのです。
今すぐ業務のやり方を変えるのは現実的ではない
ここまで共有踏み台VMの問題を取り上げてきましたが、だからといって、明日から踏み台VMを廃止し、すべての管理ツールを各担当者の端末へ移行するというのは現実的ではありません。
長年使い続けてきた管理ツールや、特定のOS環境でしか動作しない業務ソフトウェアもあります。
作業手順を変更するには、動作検証や手順書の更新、担当者への教育も必要です。
何より、セキュリティ対策のために、今動いている業務を止めてしまっては本末転倒です。
そこで、まずは業務のやり方を変えずに、ネットワークの構成を見直すことから始めてはどうでしょうか。
管理用コンソールは残す。ただし、境界から内側へ
従来は、固定IPアドレスからのRDP接続を許可し、共有踏み台VMを外部からの入口として利用していました。
これを、管理用コンソールはVPC内のプライベートネットワークへ配置し、管理者はVPNを経由してアクセスする構成に変更します。ここでいう管理用コンソールは、管理ツールを動かす自社のVMです。クラウド事業者のWeb管理コンソールとは区別します。
本番環境と開発環境にそれぞれ管理用コンソールを設置しているなら、その分離も維持します。
管理者はVPN経由で内部のコンソールへRDP接続し、これまでと同じ管理ツールを使って作業します。
つまり、主に変えるのは、管理用コンソールまでの通信経路です。
これなら、長年使ってきた管理ツールを直ちに置き換える必要はありません。
一方で、外部から直接RDP接続を受け付ける構成を見直し、インターネットに公開する管理用サービスを減らせます。
既存の接続経路を閉じる前に、新しい経路を検証する
ネットワーク構成の変更自体が、業務停止の原因になることもあります。
そのため、最初から既存のRDP接続を無効にするのではなく、まず新しいVPN経路を用意します。
本番環境と開発環境のそれぞれについて、管理用コンソールへ接続できること、必要な管理ツールが動作することを確認します。
そのうえで、従来の公開RDPを閉じます。
移行期間中に既存の接続経路を残す場合も、公開期間を必要最小限にし、適切な認証とアクセス制限を維持する必要があります。
まずは業務を止めずに、外部公開によるリスクを減らす。
そのうえで、パッチ適用やツールの更新、管理責任の明確化などを段階的に進めていく。
小規模な事業者にとっては、こうした現実的な進め方も重要なセキュリティ対策です。
HomeGrid VPNで、本番・開発環境へのアクセスを整理する
このようなネットワーク構成は、自前のWireGuard、クラウドの管理型VPN、対応するマネージド接続機能などでも検討できます。鍵や経路の管理、運用負担、利用条件を比較します。公開入口を減らす一般的な設計は、SSH・RDP・NASを公開しない構成の記事でも説明しています。
このようなネットワーク構成を実現する方法の一つが、HomeGrid VPNです。
HomeGrid VPNは、端末と拠点側の機器がCloud Hubへ接続するHub & Spoke型のVPNです。
クラウドのVPCを接続する場合も、VPC内の接続用ノードからCloud HubへOutbound通信で接続する構成を取れます。
そのため、管理用コンソールにPublic IPを割り当てたり、インターネットからRDP接続を直接受け付けたりすることを前提にせず、管理経路を構成できます。Cloud HubはVPN通信を中継する構成要素です。この管理接続の宛先はVPC内の管理用VMで、インターネットへの出口を利用する接続ではありません。
では、実際に作業PCからどのようにアクセスするのでしょうか。
本番環境と開発環境を分離する
例えば、AWSに次の2つのVPCを用意したとします。
本番用VPC
顧客向けWebアプリケーションを運用する環境です。
顧客向けのHTTPS通信は公開し、データベース、管理用API、管理用コンソールなどはプライベート側に配置します。
本番用の管理用コンソールには、プライベートIPアドレスを割り当てます。
開発用VPC
開発・テスト用のサーバーを配置する環境です。
開発サーバーと管理用コンソールにも、それぞれプライベートIPアドレスを割り当てます。
本番用VPCと開発用VPCは、ネットワークも認証情報も分離して管理します。
リモートアクセス：作業PCからプライベートIPで接続する
開発担当者は、普段使っているWindowsやMacの作業PCからHomeGrid VPNへ接続します。
VPN接続後は、アクセスが許可されたVPC内のサーバーや管理用コンソールに対して、プライベートIPアドレスを指定してアクセスします。
例えば、開発サーバーへは、そのサーバーのプライベートIPアドレスを指定してSSH接続します。
管理用コンソールへは、そのVMのプライベートIPアドレスを指定してRDP接続します。
管理用コンソールには、従来のデータベース管理ツールや専用ソフトウェアをそのまま残しておけます。
つまり、管理者はVPN経由でコンソールへログインした後、これまでと同じツールを使って作業できます。
この構成では、外部から管理用コンソールのPublic IPに接続する必要はありません。
作業PCから、VPNを経由して、VPC内のプライベートIPアドレスへアクセスする。
これが基本的な利用イメージです。
アクセス制御：LAN ACLで、作業PCがアクセスできるVPCを制限する
ここで重要になるのが、HomeGrid VPNのLAN ACLです。
LAN ACLは、VPNに接続した作業PCが、Gridの先のどの宛先LANへアクセスしてよいかを制御する仕組みです。この例では、各VPC内の接続用ノードをGridとして用意し、開発用と本番用のサブネットを別々の宛先LANとして登録します。
例えば、開発担当者の作業PCについて、次のように設定します。
- 開発用VPCのサブネット：アクセスを許可する
- 本番用VPCのサブネット：アクセスを許可しない
HomeGrid VPNのLAN ACLはデフォルト拒否（Default Deny）なので、明示的に許可していないサブネットにはアクセスできません。
この設定なら、開発担当者はVPNへ接続した後、開発用VPCのサーバーや管理用コンソールへアクセスできます。
一方、本番用VPCの管理用コンソールへのVPN経由のアクセスは許可されません。
つまり、VPNへ接続できることと、すべてのVPCへアクセスできることは別なのです。
本番運用を担当する別の作業PCには、業務上必要な本番用VPCのサブネットへのアクセスを許可する構成も考えられます。
LAN ACLの変更は反映まで最大5分かかることがあります。反映後に、開発用サブネットへ接続できることと、本番用サブネットへ接続できないことを確認します。設定手順はLAN ACLのガイドを参照してください。
さらにクラウド側のSecurity Groupで制御する
LAN ACLで作業PCからアクセス可能なサブネットを制限したうえで、クラウド側でもアクセス制御を行います。
例えば、開発用VPC内で次のように設定します。
開発用Linuxサーバーでは、許可された管理経路からのSSH接続だけを受け付ける。
管理用コンソールでは、許可された管理経路からのRDP接続だけを受け付ける。
データベースでは、必要なアプリケーションや管理用コンソールからの通信だけを許可する。
これらはAWSならSecurity Group、AzureならNetwork Security Groupなどで設定できます。OS側のFirewallも併せて確認します。
HomeGrid VPNのLAN ACLはサブネット単位でアクセス範囲を制御し、クラウド側のSecurity GroupやFirewallは、アクセス先のサーバーやポートを制限します。
さらに、OS認証、MFA、IAMなどによって、実際に操作できる利用者や権限を管理します。クラウド管理アカウントのMFAを有効にしても、RDPログインへ自動的にMFAが適用されるわけではありません。それぞれの認証基盤に合わせて設定します。
役割を整理すると、次の3段階です。
- HomeGrid VPNのLAN ACL：この作業PCから、どのVPCのサブネットへアクセスしてよいか
- クラウド側のSecurity Group / Firewall：許可されたサブネット内で、どのサーバー・ポートへの通信を許可するか
- 認証・権限制御：誰がログインでき、何を操作できるか
このような多層的な制御にすることで、VPNに接続した作業PCが必要以上のシステムへアクセスするリスクを減らします。
ただし、これはそれぞれのアクセス制御の役割を示したものです。実際の通信には、クラウド側のルーティングや戻り経路の設定も必要です。Security Groupなどで許可する送信元は、VPN経路やアドレス変換後に接続先から見えるアドレスを確認して決めます。管理用VMの更新に必要な外向き通信も確保します。
また、LAN ACLで本番用VPCを許可しない設定にしても、クラウド管理コンソールや別のネットワーク経路まで自動的に遮断されるわけではありません。それらのアクセス権限は個別に管理する必要があります。
管理用コンソールを残しながら、外部公開を減らせる
この構成の利点は、従来の管理用コンソールを無理に廃止する必要がないことです。
長年使ってきた管理ツールや専用ソフトウェアは、VPC内のコンソールに残せます。
作業PCからはVPN経由でプライベートIPアドレスを指定して接続し、ログイン後は従来の操作方法を続けられます。
同時に、外部から直接RDP接続を受け付ける構成を見直せます。
ただし、管理用コンソールを内部に移したからといって、未適用パッチや古い管理ツールの脆弱性まで解消されるわけではありません。
更新計画、認証、アクセス制御、監視、管理責任の明確化は引き続き必要です。
管理用コンソールを残すか廃止するかではなく、どこに置き、どの作業PCからアクセスできるようにするか。
まずはそこから見直すことができます。
なお、クラウドVPC接続には、HomeGrid VPNの対応プランやVPC側のネットワーク設定などの条件があります。
セキュリティ対策は、事業継続性を高めることにもつながる
ここまでは、外部からの攻撃経路を減らすことや、侵入後の影響を限定することを考えてきました。
しかし、どれほど対策しても、すべてのサイバー攻撃やシステム障害を防ぐことはできません。
そこで重要になるのがBCP（事業継続計画）です。
特に、小規模な事業者が考えておきたいのは、普段仕事をしている事業所が使えなくなった場合でも、クラウド上の業務を続けられるかという問題です。
事業所が使えなくなっても、クラウド上の業務を続けられるか
例えば、地震や水害によって事業所に出社できなくなった場合を考えてみます。
AWSやAzure上のWebシステムは正常に稼働しています。
しかし、管理用コンソールへのアクセスを事業所の固定IPアドレスだけに制限していたらどうでしょうか。
社員が自宅や避難先から作業しようとしても、接続元のIPアドレスが違うため、管理環境へアクセスできません。
事業所の停電や通信回線の障害によって、その固定IPアドレスからの通信自体ができなくなる場合もあります。
クラウド上のシステムは動いているのに、事業所が使えないために運用できない。
これは小規模な事業者にとって、無視できない事業継続上のリスクです。
そこで、管理用コンソールをVPC内のプライベートネットワークへ配置し、作業PCからVPN経由でアクセスできる構成が役立ちます。
管理者は事業所に出社できなくても、自宅や別の作業場所からHomeGrid VPNへ接続し、VPC内の管理用コンソールへプライベートIPアドレスを指定してアクセスできます。
また、HomeGrid VPNのLAN ACLを利用すれば、作業PCごとにアクセス可能な本番用・開発用VPCのサブネットを制限できます。
事業所の固定IPアドレスに依存せず、必要なアクセス制御を維持しながら運用を続けられる構成です。
もちろん、作業場所の通信環境や電源、管理端末などを確保できることが前提です。
それでも、事業所が使えなくなっただけでクラウドの運用まで停止する構成とは、大きな違いがあります。
事業所の回線を使わず、自宅や代替拠点から接続・認証できるかを平時に試します。MFA端末や復旧手順が事業所内にしかない状態も見直します。事業所側の機器を経由しない経路と、クラウド側のVM・接続用ノードの稼働が前提です。働く環境全体の見直しは、数人のチームから始めるリモートワークとBCPの記事で説明しています。
開発環境がサイバー攻撃を受けた場合
事業継続を脅かすのは、自然災害だけではありません。
例えば、開発担当者の作業PCがマルウェアに感染した場合です。
その作業PCから本番用VPCにも自由にアクセスできる構成なら、攻撃者が利用できる接続経路が広がってしまいます。
しかし、HomeGrid VPNのLAN ACLで開発用VPCのサブネットだけを許可し、本番用VPCへのVPN経由のアクセスを許可していなければ、その経路から本番環境へアクセスされるリスクを限定できます。
もちろん、クラウド管理権限やCI/CDの認証情報など、VPN以外の経路についても別途対策が必要です。
環境ごとのネットワーク、認証情報、アクセス権限を分離することで、問題が発生したときの影響範囲を小さくすることが重要です。
バックアップがあっても、すぐ復旧できるとは限らない
万が一、本番環境が侵害されたり、データが破壊されたりした場合には、復旧作業が必要になります。
しかし、バックアップを取っているだけで安心してはいけません。
安全な復旧環境の構築、認証情報の更新、データの整合性確認、復旧先へのアクセス経路の確保などが必要です。
バックアップが攻撃者に削除・改ざんされないように保護することや、実際に復元できるかを定期的にテストすることも欠かせません。
バックアップがあることと、事業を再開できることは同じではありません。
侵入を防ぐだけでなく、侵入された後も被害を広げず、復旧できるようにする。
ここまで考えることが、事業を継続するためのセキュリティ対策ではないでしょうか。
セキュリティ対策とBCPは、別々の話ではない
セキュリティ対策とBCPは、目的が完全に同じというわけではありません。
しかし、共通する部分は少なくありません。
本番環境と開発環境を分離することは、不正アクセスによる被害の拡大を抑えるだけでなく、一方の環境で問題が発生した際の影響を限定することにもつながります。
管理用コンソールを外部公開しない構成にすることは、攻撃経路を減らす対策です。
同時に、事業所に依存しない管理経路を用意することは、事業所の停電や災害時にも役立ちます。
LAN ACLで作業PCごとのアクセス範囲を制御することは、不要なシステムへのアクセスを抑え、端末が侵害された場合の被害範囲を限定する対策にもなります。
バックアップと復元テストは、データ破壊への備えであると同時に、事業を再開するための備えでもあります。
そして、共有踏み台VMの管理責任を明確にし、更新や障害対応の手順を決めることも、セキュリティと事業継続の両方に関係します。
つまり、セキュリティ対策は単に情報漏えいを防ぐための費用ではありません。
事業を止めないため、そして止まっても再開できるようにするための投資でもあるのです。
小さな会社でも、今できることから始められる
大規模なセキュリティ設備や、専任のセキュリティ担当者を用意することは、社員3人の会社には難しいでしょう。
しかし、何もできないわけではありません。
まずは、次のような点を確認してみてはどうでしょうか。
- 管理用コンソールのRDPをインターネットへ公開する必要が本当にあるのか
- 本番環境と開発環境のネットワークや認証情報を分離しているか
- 作業PCごとに必要な環境へのアクセス範囲を限定しているか
- 共有踏み台VMのパッチ適用と管理責任者が決まっているか
- 対応する管理者アカウントにMFAを設定しているか
- バックアップから実際に復元できるか
- 事業所に出社できない場合や、事業所の固定IPが使えない場合でも、クラウド上の運用を続けられるか
すべてを一度に改善する必要はありません。
今使っている管理用コンソールを残しながら、外部公開を減らすことから始めてもよいのです。
そのうえで、アクセス制御を整理し、更新計画や運用体制を見直していく。
業務のやり方をすべて変えなくても、セキュリティ対策は始められます。
大切なのは、対策を導入することだけでなく、それを無理なく継続できる仕組みにすることです。
もう、セキュリティ対策に無関係ではいられない
今回、総務省が検討を始めるのは、通信事業者のサイバーセキュリティ対策です。
その議論が今後どのような制度になるのかは、まだ分かりません。
一般のSOHOや小規模事業者に、新たな義務が直接課されると決まったわけでもありません。
しかし、だからといって、自分たちは無関係だと考えてよいのでしょうか。
かつては、セキュリティ対策を進めようとするたびに、被害想定額や発生確率、投資対効果を問われる時代がありました。
「義務ではないから」
「利益を生まないから」
「事故が起きてから対応した方が安いから」
そんな考え方が、長く続いてきたように思います。
もちろん、今でも費用対効果を考えることは必要です。
しかし、クラウド上でシステムを開発し、顧客情報を預かり、インターネットを通じてサービスを提供する時代です。
たった数人の会社でも、一度のサイバー攻撃や障害によって事業そのものが止まることがあります。
お金を払えば情報が戻るわけではありません。失われた信用が回復するとも限りません。
だからこそ、セキュリティ対策を、単なる義務やコストとして扱ってきた考え方を見直す必要があるのではないでしょうか。
本番環境だけでなく、開発環境も守る。
管理用コンソールを残すとしても、インターネットとの境界に置く必要があるのか見直す。
作業PCごとに、アクセスが必要な環境を制限する。
そして、事業所が使えなくなっても、クラウド上の業務を継続できるようにする。
今すぐ業務のやり方を大きく変えなくても、自分たちの規模に合った対策はできます。
これまで、セキュリティを後回しにしてきたことへの反省も込めて。
もう、セキュリティ対策に無関係ではいられません。
そろそろ、私たちも本気で対策を始めますよね？