コロナ禍で変化したIT環境

サイバーセキュリティへの関心は年々、高まっている。2000年以降の国会会議録で「サイバー」を含む文言が用いられた数を図示すると、その増加傾向は明らかだ（図1）。2000年7月には沖縄でサミット（主要国首脳会議）が開催されたが、その際、サミットの歴史の中で初めて「サイバー」という言葉が使われた。こうした出現数が急伸したのは2013年のことだ。国家安全保障戦略の中にサイバーセキュリティが言及され、技術面だけでなく、安全保障の観点から注目を集めた。その後、日本年金機構が2015年にサイバー攻撃を受けた事案などを背景に、日本のセキュリティ業界が進展していった。

図1：サイバーセキュリティの動向

新型コロナウイルス感染症の拡大を受けてリモートワークが推奨され、今や多くの企業でWeb会議システムを活用したオンライン会議が当然のことのように行われている。こうした状況を受けて、企業のIT環境やセキュリティ事情は大きな影響を受けた。従来のIT環境では、原則すべてのパソコンやデータなどの資源はオフィス内にあり、出社して使用するのが前提だった。一方、現在では、コロナ禍に対応するために自宅などのリモートからでも業務可能な環境が整備されるに至った。一部のIT資産はオフィス内に残るものの、クラウド側にデータやアプリケーションが移行されている。

図2：現在のIT環境

コロナ禍を契機にわずか1年程度でIT環境が大きく変化したため、社内のルールやセキュリティの仕組みが、そうした状況に対応できていないという現状がある。ここでは、「リモート接続端末のインシデント」「クラウド環境のインシデント」「インターネットに接続するアプライアンス」の3つに焦点を当てて、見直すべきポイントについて解説する。

リモート接続端末のインシデント

まず、運用委託事業者がユーザー企業の業務システムを管理していた際に発生した事件を例に、リモート接続端末の問題点について議論したい（図3）。これまで、保守作業を行う際には、運用委託事業者の担当者が企業のネットワークに接続して作業を実施していた。保守用の端末を持って現地に赴き、アップデートファイルを導入したり、システムをアップデートしたりする流れだ。

ここで、コロナ禍によるリモートワーク対応で問題が発生した。運用委託事業者は社員を守るため、出社しなくても作業ができるよう、保守用端末にリモートから接続したいと考えたのだ。その結果、外部からアクセスできるようグローバルIPアドレスを割り振り、脆弱なパスワードを設定した。その後、管理者パスワードが破られ、不正アクセスによる情報流出につながってしまった。

図3：運用委託事業者の作業ミスによる事件

発注者の視点で考えると、基本的なセキュリティ対策を怠っていた運用委託事業者に不満を抱くかもしれない。業務システムのセキュリティをいくら高めても、運用委託事業者の担当者に十分な教育がされていなければ意味がないからだ。しかし、運用委託事業者の視点からは別の見方もできる。運用の作業内容は変わらないにも関わらず、毎年、運用委託費が引き下げられてしまう現状では、経験のあるエンジニアを常時配置させることは困難だ。また、社員を保護するためにリモートワークを推進したくても、ユーザー企業が現地作業にこだわり、あれこれと書類を要求する場合もある。

運用委託事業者としては、利益を確保することが難しい契約を継続しようとは思わないだろう。そのときに困るのは発注者側だろう。ユーザー企業が自社のシステムを守り、運用委託事業者に基本的なセキュリティ対策を講じてもらうためには、現実的な業務の進め方や契約内容を再考する必要がある。

ほかにも、次のようなリモート接続端末に関連したセキュリティ事故が発生している。

1）社内用に設定されたパーソナル・ファイアウォール（FW）のオープンポート

社内で使用していた端末をリモートワーク用に自宅で使用する場合、ファイアウォールの設定をそのままにして使ってしまうケースがある。インターネットに接続する場合は閉じておくべきポートが開いているために、セキュリティリスクが生じる。

2）システム部門から配布されたパソコンの脆弱な設定

社内での使用を前提にしていたため、セキュリティの設定が不十分で脆弱性がある。

3）ハードウェア故障で急遽交換した保守切れの端末

社員が使用していた端末に故障があったため、減価償却を終えた古い端末を配付してしまうケースがある。保守が切れた端末は適切にメンテナンスされておらず、セキュリティ事故のリスクを高める。

4）通信環境が脆弱でアップデートが適用されていない

リモートワーク環境で通信状態が十分ではなく、Windowsアップデートや、そのほかのアプリケーションのアップデートが適用されていない。あるいは、後回しにされてしまい脆弱な状態になっている。

リモートワークを推進する企業では、端末のアップデート状況やリモート接続の設定に加えて、ファイアウォールの設定などを改めて確認しておいてほしい。

クラウド環境のインシデント

Web会議システムに代表されるように、クラウドサービス、およびSaaS（ソフトウェア・アズ・ア・サービス）を利用するようになった企業は少なくないが、セキュリティインシデントにつながってしまった事例がある。それは、情報共有のために使っていたクラウドサービスやタスク管理のシステムで、アクセス制御の設定が適切ではなく、意図せず情報を公開してしまう、といったものだ。無料でも使えるようなクラウドサービスを業務で使い始めた人は、それらのセキュリティリスクに関して一定の理解があるかもしれないが、企業内での利用を拡げていくうちに、セキュリティの知識・意識が十分でない人によって機密情報が公開された状態になってしまうというケースもよく見受けられる。

このようなインシデントを見聞きして、クラウドの利用を禁止するべきだと考える人もいるかもしれない。しかし、クラウドを使わずに業務要件を満たすことができるのか考慮しなければならない。従業員がクラウドサービスを使ったのは、既存の社内システムではできない機能や、スピーディーな導入が可能である利点があったからだ。むやみにクラウドサービスを禁止しても業務が非効率となり、残業時間の増加や隠れてクラウドサービスを使うシャドーITが横行してしまう恐れもあるのだ。クラウドサービスは一律に禁止するのではなく、安全に使える方法を社内で検討して推進するのが望ましい。

ここで、クラウド環境から個人情報が盗まれた事例を紹介したい（図4）。ある企業では、クラウド上でWebサーバーを運用し、個人情報をデータベースに保存するという一般的な構成をとっていた。攻撃者は、まず、クラウド環境を操作するために必要なAPIキーを窃取し、クラウド環境へ仮想マシンを立ち上げた。同じネットワーク上にある仮想マシンからデータベースにもアクセスできることから、保存されていた個人情報が盗まれてしまったのだ。そして、個人情報を転送した後に仮想マシンを削除したため、痕跡も残さなかった。

図4：盗まれた個人情報

このインシデントで重要なのは、クラウド環境にアクセスするAPIキーがどこから漏えいしたかという点だ。実際は、Webサーバーのディレクトリ内がインターネットから閲覧可能な状態にあったのが原因だった（図5）。ソースコードの管理システムとしてGitを使用している企業は少なくないが、そのソースコードの中にAPIキーやデータベースの接続情報を含めてしまう場合がある。このインシデントでは、公開されたGitのディレクトリからAPIキーが盗まれたのだ。

図5：.gitディレクトリが閲覧可能

Webサーバーの担当者も、ディレクトリが公開されている状態にあるのは認識しながら、リスクは高くないと判断していたのかもしれない。しかし、APIキーのように公開されるはずのない情報が漏えいし、悪用されるというインシデントは多数発生しており、対策を講じておく必要がある。例えば、サーバーや個人の端末で、テキストファイルにパスワードが記載されている場合がある。システム管理用のスクリプトや、ベンダーが納品した設定ファイルに認証情報が残っているケースも考えられる。攻撃者から見ると、パスワードを容易に取得でき、複数のシステムへ攻撃を仕掛けられる条件が整っているということなのだ。

クラウドサービスの利用が今後も増えていくことを想定すると、シャドーITの管理や認証の手続きについて考慮しておく必要がある。多要素認証（MFA）は当然、導入するべきものであるが、個人所有のモバイル端末を使用している場合に認証アプリの導入を強制するべきか、といった点については議論の余地があるだろう。また、複数のクラウドサービスで同じパスワードを使い回してしまう人が多いという現状を考えると、シングルサインオンやID連携の導入も検討したい。

また、クラウドサービスに関するユーザー教育も欠かせない。少なくとも、社外の人が自由にアクセスできるURLで社内の情報を共有しないよう、すべての従業員に周知・徹底してほしい。より複雑な設定については、システム部門やセキュリティの専門家へ相談するようにしたい。

インターネットに接続するアプライアンス

近年、インターネットに接続するアプライアンス製品、特にVPN（Virtual Private Network）が標的とされるセキュリティインシデントが目立つ。リモートワークの普及に伴い、自宅から社内のネットワークへVPNを介して接続する従業員が増えたため、VPN製品のサービス停止時間を設定しにくいという背景がある。つまり、VPNをアップデートする運用が定められておらず、アップデートができていない状況が考えられる。

インターネットに接続するアプライアンスから侵入されると、マルウェアなどが内部に展開されやすいため、被害が拡大するリスクがある。すでに内部へ侵入してからアプライアンスをアップデートしても、攻撃者は再度侵入できる仕掛けを設けているため、攻撃を防御することはできない。アカウントが不正に作成されていないか、アプライアンスの再起動は必要か、といった点も検証するべきだ。

あるセキュリティ専門家は、ランサムウェア攻撃者が狙いやすい製品を一覧化している。マイクロソフト社などの大手の製品が挙げられているが、攻撃者が多額の身代金を要求できる組織を標的にしているからであろう。また、カプコン社のように、ランサムウェアによる被害を公表している企業もある。

図6：ランサムウェア攻撃者が狙う脆弱性

VPNを介して不正侵入を許してしまうと、ID管理サーバーのように重要なIT資産が被害を受ける場合が多い。Active Directoryのアップデートが適用されていなかったり、内部通信が監視されていなかったりと、防御や検知の対策が十分に施されていないのだ。「不審なメールを開かない」といった外部からの攻撃に備えていても、すでに内部に侵入した攻撃に対する備えが不十分だと、企業は多大な損害を被る。

脆弱性情報が発表される前や、パッチが適用される前に、インターネットに接続するアプライアンスが攻撃を受けるケースもある。そのため、攻撃を防ぐだけではなく、攻撃を速やかに検知するアプローチも必要になってくるだろう。アプライアンスのセキュリティ機能はベンダーが提供する機能に頼らざるを得ず、ユーザーがログの設定を変更するような対策は容易ではないが、疑わしい活動を検知するようログを分析する仕組みについてはユーザー側で検討しておきたい。また、予算次第ではあるが、IPS（Intrusion Prevention System）やWAF（Web Application Firewall）を導入する方法もある。

インターネットに接続するアプライアンスを利用する企業では、「防御」「検知」「対応」といった観点から対策を講じたい（図7）。まず、「防御」の観点では、VPNに接続するIPアドレスやユーザーを制限できないか検討することが推奨される。リモートワークに対応するためにIPアドレスの制限は難しいかもしれないが、普段使用していないユーザーに制限をかけるといった見直しは可能だ。また、システム部門はVPNのアップデート情報を監視する体制を整える必要がある。運用委託事業者の契約に入っていない場合など、被害が拡大するまで、アップデート情報に気づかないかもしれない。

図7：見直すべきポイント

次に、「検知」の観点では、ログの出力設定や監視体制を確立しておきたい。例えば、VPNのログを別のサーバーに送信・保存しておけば、仮にシステムが侵入されても別のサーバーのログまで消去するのは容易ではないため、ログの検証が可能となる。ログの送信が停止した時点でVPN製品の問題が検知できる場合もあるだろう。ログを監視する人員や、アウトソーシングする予算が確保できない企業の場合、ログ解析を自動化できないかを検討してみてほしい。

最後に、「対応」の観点では、サイバー攻撃の被害を受けた際に、VPNサーバーを緊急停止する手順が準備されているか確認しておきたい。

ケアされていない領域をどのように守っていくか

セキュリティ業界では、ゼロトラストのように注目を集める概念や優れた技術は多々あるが、1つの施策ですべてを解決するようなソリューションは存在しないのが現実だ。システムを構成する要素のうち、十分に対策を講じられていないものから問題が引き起こされる。セキュリティ製品を導入していても、例えば、サポート切れのOSやアップデートされていない端末が放置されていれば、セキュリティインシデントにつながってしまうケースも少なくない。

図8：システムを取り巻く現実

企業のシステムでは、いわゆる「儲かっていないサービス」でセキュリティリスクが散見される。「儲かっているサービス」では、積極的なセキュリティ投資で対策が講じられており、「赤字のサービス」では早々に撤退することになるためシステムは停止される。しかし、わずかに黒字化しているが今後大きく伸びる見込みのないサービスにおいては、セキュリティが後回しにされる傾向にある。
会社の収益に寄与している以上、IT部門やユーザー部門がシステムを変更するという判断を行うのは非常に難しい。そして、セキュリティ対策が遅れている間に攻撃を受け、全社のシステムやサービスに甚大な悪影響を及ぼしてしまう可能性がある。企業全体を俯瞰する経営者は、利益は高くないものの安定して稼働しているシステムほど、セキュリティ対策が十分に行われているかを検証してほしい。

海外のシステムや管理されていないデバイスを起点として、サイバー攻撃を受けるケースも多い。利用するアプリケーションが最新のセキュリティ機器によって保護されていても、ほかのシステムから侵害されてしまっては意味がない。ゼロトラストの考えに従って新しいビジネス環境を守ることはできても、既存のシステムまで適用範囲を広げるのは難しいものだ。「儲かっていないサービス」に対して、防御の仕組みを強化できなくても、ログを監視する検知の仕組みだけは導入する、といったアプローチも検討してほしい。

おわりに

多くの企業では入念に計画を立て、稟議を上げて対策を講じるというプロセスが一般的であろう。コロナ禍を受けてIT環境や外的環境の変化は加速しており、業務に必要な要件や事業構造も大きく変化した。そのため、立てた計画を進めながらも、変化に対して柔軟に対応できる余地を残しておくことが重要だ。

また、システム部門だけではサイバーセキュリティの対策は実行できないため、部門間の連携と協働が不可欠となる。当然ながら、部門ごとに役割分担すること自体が目的ではなく、業務の効率性を高めながら、最終的に企業が提供しているサービスやシステムを守る意識が重要となる。経営者のリーダーシップのもと、システム部門が中心となりながらも、これからの時代に合ったセキュリティ対策を推し進めてほしい。