コラム
サイバー攻撃事例から考える M365によるゼロトラスト実現ステップ
■ JAXA がサイバー攻撃の被害に
先日、JAXA がハッカー集団からサイバー攻撃を受け、有人月探査計画関連や他の機密性の高い資料を含む 1 万ファイル以上が流出したとの報道がありました。
参照：讀賣新聞オンライン
「中国系ハッカー、JAXAから機密情報窃取か…火星衛星探査や有人月探査計画の資料も」
ざっくりいうと、VPN の脆弱性をついてネットワークに侵入し、Microsoft 365 のアカウントを乗っ取り、データを盗み出すという攻撃だったようです。100 年単位で人類に貢献する宇宙開発プロジェクトに遅れが出るなどの影響が出ないことを願う一方で、どの組織でもこれと同じような被害にあう可能性があるということをここでは強調してお伝えしたいと思います。
多くの Microsoft 365 はすでに攻撃対象になっており、経験上、ユーザー数が多いテナントや運用期間が長いテナントほど激しく攻撃されている傾向にあります。このような脅威に対抗するためにすべての組織でもつべき考え方（ゼロトラスト）と、Microsoft 365 を使った実現方法の概要について紹介したいと思います。
■ 社内ネットワークは安全という神話
JAXA と同様に多くの企業では社内ネットワークに安全に接続するために VPN を利用しています。しかし、VPN 機器はたびたび大きな脆弱性が見つかり、これを放置すると攻撃者が社内ネットワークにアクセスするための都合の良い “どこでもドア” として機能してしまいます。このように、セキュリティを強化する目的で導入したセキュリティ ソリューション自体が、組織に脅威を与えるリスクになってしまう例は数多くあります。
これに加え、メールによる標的型攻撃の隆盛もあり、社内ネットワークはもはや安全と見なすことはできなくなっています。
このような状況で「ネットワーク境界型防御からゼロトラストへ移行することが必要」ということは様々なところで言われていますが、どうしても境界型防御の発想を抜け出すことが出来ていない人はまだまだ多い印象です。
もう一度、ゼロトラストとは何かについておさらいしてみましょう。
■ ゼロトラスト
ゼロトラストとは、リソースへのアクセス要求を行うユーザーやデバイスは基本的に「信頼できない」という前提におき、リソースへのアクセス時に正当なリクエストであるかを都度検証するというセキュリティの考え方です。
住宅地の狭い道路で車を運転する際、たとえ車側の信号が青だったとしても「子どもが飛び出してくるかもしれない」と思いながら注意して運転しますよね？ゼロトラストもそれに似ていて、仮に「社内からのリクエストである」「パスワードによる認証が通っている」という “青信号” が灯っていても、だからといって盲目的にアクセルを踏むのではなくて、常に「成り済ましかもしれない」という疑いの目をもって毎回リクエストを検証するというイメージです。
Microsoft 365 のセキュリティを使った場合では、（社内からのアクセスで、かつパスワードによる認証をクリアしていたとしてもそれに加えて）リソースへのアクセス要求がある度に、認証に使用された多要素認証の強度を確認したり、アクセス元のデバイスがいつもと同じかを確認したり、EDR がデバイスの脅威を検出していないかを確認したりして、すべてが問題ない場合だけ Entra ID の認証を許可するといった実装ができます。
■ 侵害前提
また、ゼロトラストの原則の一つに「Assume Breach（侵害前提）」があります。これは、現在の高度化、複雑化したサイバー セキュリティ環境においては攻撃を完全に防ぐことはそもそも難しいということを意味します。
どんなに完璧と思われるセキュリティであっても、そこに人が介在する以上ミスもあり得ますし、想定していなかった攻撃手法や、また当時存在しなかった新しい攻撃手法によって将来的に突破される可能性もあります。
私たちがお客様テナントをアセスメントすると、Entra ID 条件付きアクセス ポリシーやメール ルール（トランスポート ルール）などのポリシーの不備が見つかることが多々あります。
この主な原因は、構築当初に設定したままポリシーの見直しが行われていないことです。セキュリティソリューションを導入したりポリシーを構成しただけで満足するのではなく、「今の構成で本当に問題がないか（破られていないか、不備がないか）」と常に確認し続けることが求められます。
■ ログ監視は重要
ここまでをまとめると、ユーザーやデバイスを「信頼できないかもしれない」という前提でセキュリティを構築し、構築後も「侵害されているかもしれない」という前提で常に監視し、設定を見直していく必要があるということです。
これらを機能的に実現するために「ログ」の存在は欠かせません。ユーザーやデバイスが安全かどうかを確認するための機能がなければそもそもそのログを出力することはできませんし、ログがなければ侵害や不備がないかを確認することもできません。
横道にそれますが、基本的にオンプレミスでシステムを構築しないほうが良い理由はログ関連の機能が弱いからです。
よくある例として、「重要なファイルこそ社内のファイル サーバーに格納すべき」論がありますが、そのファイル サーバーにアクセスするための認証ログや、ファイル サーバーでの操作ログを SIEM に集めて脅威検出ルールを作成して・・といったことまでされている例を見たことがありません。しかし、これらの多くはクラウド サービスでは普通にできていることです。重要なデータこそ監視が行き届かないオンプレミスのファイル サーバーではなくクラウド ストレージに保存すべきです。
話を戻して、前述のようにセキュリティの構築や運用を完璧に行うことはそもそも難しいため、ログ監視によって不正アクセスや意図しないアクセスの有無を可視化し、それらの情報をポリシーの見直しに活用し、セキュリティを強化し続けることが理想です。そしてこれこそが、ネクストリードがセキュリティ サービスによって実現しようとしていることでもあります。
■ NRAS でどんどんセキュアに
ネクストリードのセキュリティ サービス NR Automate Security （以降 NRAS）では、Microsoft 365 のセキュリティ監視を主体にしながら、ネットワークや Active Directory の監視をアドオンでき、組織の IT 環境を網羅的にカバーしたログ収集を行うことができます。
Microsoft Defender XDR や、ログから独自に生成したアラートを調査することで顕在化した脅威に対応します。アラートのほとんどは誤検知に分類されますが、中にはパスワード漏えいやマルウェア感染など、放置することで重大なインシデントに発展する可能性があったアラートも少なからずありますので、生成されたアラートは確実に調査する必要があります。（しかし、アラートを調査できていないという組織は意外と多いんですよね・・）
また、一般的な監視サービスではアラート監視のみを行いますが、NRAS ではセキュリティを強化するために必要な構成変更をお客様に提案することもある点が特徴です。
例えば、ユーザーのメールボックスに脅威メールが配信される場合は、Defender for Office 365 のポリシー見直しを提案することで、そもそもユーザーのメールボックスにメールが届く確率を減らしていくことを目指します（それによってアラートも減らすことができます）。この例の場合はメール中のリンクにユーザーがアクセスしたかを確認することでフィッシングやマルウェア感染の初期イベントが発生していないかについても調査します。最近は QR コード フィッシングという脅威が増えていますが、メール中の QR コードを URL に変換してその URL にアクセスがないかも確認しています。
他にも、個人の Gmail などへのメール転送などを検知した場合は、該当ユーザーに転送ルールの削除を提案するだけでなく、管理者にテナント全体でメール転送を禁止するポリシー変更を提案することでセキュリティ リスクの根本的な軽減を目指します。
デバイスには Intune のポリシーや ASR ルールの適用を提案することもあります。
■ M365 セキュリティ ステップ
これまで述べてきた Microsoft 365 によるゼロトラスト実現ステップをまとめると下記のようになります。
1. 重要データは Microsoft 365 （SharePoint や OneDrive など） においたままで OK
2. Entra ID 条件付きアクセス ポリシーを適切に構成する（それに伴いデバイス管理や MFA 設定も必要です）
3. Microsoft 365 アラート、およびログを監視する
4. アラートやログをもとにセキュリティ構成を改善する
おそらく IT ベンダーに相談すると 2 （構築）だけ提案されたり、3 （監視）だけを提案されたり、または構築と監視を別々のサービスとして紹介されることが多いと思います。
どちらも重要ですが、どちらか一つだけと言われれば最初の一歩は 3（監視）からスタートすることをお勧めします。アラートやログに対応する中で現状を把握し、具体的な課題を踏まえて必要なアーキテクチャや投資を検討することができるからです。また、（すでに脅威がある場合は）監視により不審な動きを早期発見し対応することで攻撃がエスカレーションすることを防ぐことができるため、投資に対するリターンをすぐに得ることができます。
すべてを実現するにはコストも時間もかかりますが、ゼロトラストは小さな取り組みから少しずつ始めることができます。
■ まとめ
JAXA のインシデントの詳細は公開されていませんが、おそらく「社内ネットワークからは Microsoft 365 にアクセスが可能」というポリシーになっていたのではないかと想像しています。また、同じポリシーになっている組織もたくさんあるのではないでしょうか。
ネクストリードでは Microsoft 365 の現在の脅威を可視化するアセスメントや、監視サービスのトライアルを提供しています。これらサービスの提供知見から「私たちなら指摘できたかも？」と少なからず思うと同時に、お客様のためにも「絶対に指摘できた！」と自信を持って言えるよう今後も努力を重ねてまいりたいと思います。
本コラムをきっかけに、境界型防御からゼロトラストに考え方をアップデートし、Microsoft 365 の運用を見直すきっかけとなれば幸いです。その際は、ぜひ最初の一歩をネクストリードにご相談ください！
【関連サービス】
Microsoft 365 脅威可視化アセスメント Light
https://nextread.co.jp/nrassessment/
【関連記事】
クラウド秘密基地™ 導入事例（クラウドセキュリティ関連）
・株式会社エフ・シー・シー様のクラウド秘密基地™
Vol.1 https://nextread.co.jp/column-casestudy/fccv1/
Vol.2 https://nextread.co.jp/column-casestudy/fccv2/
Vol.3 https://nextread.co.jp/column-casestudy/fccv3/
・東京エレクトロン株式会社様のクラウド秘密基地™
Vol.1 https://nextread.co.jp/column-casestudy/telv1/
Vol.2 https://nextread.co.jp/column-casestudy/telv2/
