海外に学ぶSMBのクラウドセキュリティ基礎（CSP編）Microsoft(2)

コメントをどうぞ

海外に学ぶSMBのクラウドセキュリティ基礎（CSP編）Microsoft(1)に引き続き、今回は、アクセス制御の視点から、シンガポールサイバーセキュリティ庁のサイバーエッセンシャルズおよびサイバートラストマークに基づいて開発されたMicrosoft固有のガイドを紹介していく。

アイデンティティ／アクセス管理はクラウドユーザーの責任

Microsoft版ガイドでは、「サイバーエッセンシャルズマーク: クラウドセキュリティコンパニオンガイド」に従い、以下のような管理策について触れている。

[資産]
A1. 人々 – 従業員に、防衛の最前線となるノウハウを装備させる
A2. ハードウェアとソフトウェア – 組織が何のハードウェアとソフトウェアを所有しているかを知り、それらを保護する
A3. データ– 組織が何のデータを持っているのか、どこにあるのか、データをセキュア化しているのかについて知る
[セキュア化／保護]
A4. ウイルスとマルウェアの保護– ウイルスやマルウェアのような悪意のあるソフトウェアから保護する
A5. アクセス制御 – 組織のデータやサービスへのアクセスを制御する
A6. セキュアな構成 – 組織のハードウェアやソフトウェアのために、セキュアな設定を使用する
[アップデート]
A7. ソフトウェアのアップデート – デバイスやシステム上のソフトウェアをアップデートする
[バックアップ]
A8. 不可欠なデータのバックアップ– サイバーセキュリティインシデントを検知し、対応して、復旧の準備をする
[対応]
A9. インシデント対応 – サイバーセキュリティインシデントを検知し、対応して、復旧の準備をする

このうち「A5. アクセス制御 – 組織のデータやサービスへのアクセスを制御する」の中で、アクセス制御に関する要求事項や管理策を提示している。

「サイバーエッセンシャルズ」や「サイバーエッセンシャルズ向けクラウドセキュリティコンパニオンガイド」では、「A5. アクセス制御」のうちA.5.4 (a)のアカウント管理に関して、以下の通りクラウドプロバイダー共通の管理策を提示している。

【サイバーエッセンシャルズ】
A.5.4 (a) <要求事項>
アカウント管理を確立し、アカウントのインベントリを維持し、管理する必要がある。組織は、スプレッドシートを使用する、またはソフトウェアディレクトリサービスからリストをエクスポートするなど、さまざまな方法でこれを実現することができる。

【サイバーエッセンシャルズ向けクラウドセキュリティコンパニオンガイド】
[エンドユーザー組織(SaaSカスタマー)の責任]

  • エンドユーザー組織（SaaSカスタマー）が責任を負う。

<なぜこれが重要なのか>

  • アイデンティティ、資格情報、アクセス管理、および特権アカウントが不十分であることは、主要なクラウドセキュリティの懸念の一部である。
  • 組織が管理するSaaSサブスクリプションの数が増加する可能性がある。
  • さまざまな事業部門の業務ユーザーが、それぞれのSaaSアプリケーションにアクセスし管理する場合がある。
  • 各SaaSサブスクリプションにはそれぞれ固有のアイデンティティが存在する可能性がある。
  • その結果、組織は多数のアイデンティティを管理する必要があるかもしれない。
  • 各SaaSサブスクリプションは、アイデンティティを定義、表示、および保護する方法が異なる場合がある。

<組織は何をすべきか>

  • SaaSサブスクリプションへのアカウントのインベントリを追跡および監視する仕組みを実装する。
  • 多数のSaaSサブスクリプションおよびアイデンティティを管理する必要がある組織は、個々のSaaSサブスクリプションのパスワードを個別に管理するのではなく、アイデンティティプロバイダーを活用してシングルサインオン（SSO）ソリューションを通じてユーザーを認証することで、アイデンティティ管理をスケールすることができる。
  • SaaSサブスクリプションへのユーザーアクセスを制限することを検討する。例：ビジネスセキュリティポリシーに従う承認されたデバイスからのみユーザーがアクセスできるようにする。
  • 組織が「Bring Your Own Device（BYOD）」の方針を採用している場合は、リスクベースのアプローチを検討する。例：管理されていないBYODデバイスからのSaaSサブスクリプションへのアクセスを制限する。

-[クラウドプロバイダーの責任]
-[SaaSプロバイダーの責任]
(該当なし)
-[クラウドインフラストラクチャプロバイダー]
(該当なし)

これらを受けて、Microsoft版ガイドでは、以下のように管理策を提示している。

[エンドユーザー組織(SaaSカスタマー)の責任(例. Microsoft 365カスタマー)]

  • CSAサイバーエッセンシャルマーク：クラウドセキュリティコンパニオンガイドを参照

[クラウドプロバイダーの責任]
-[SaaSプロバイダー(例. Microsoft 365)]

-[クラウドインフラストラクチャプロバイダー(例. Microsoft Azure)]

アカウント管理は、エンドユーザー組織（SaaSカスタマー）の責任範囲であるが、Microsoftの場合、Azure Active DirectoryやPowerShellスクリプトなど、固有のツールを利用した管理サポート策を提供している。これらのツールは、既存のオンプレミス環境と新たなクラウド環境を連携させる場合に重要な役割を果たすが、ユーザー組織の規模が拡大すると、アイデンティティ／アクセス管理が複雑になる。このような状況を支援するために、サードパーティプロバイダーによるIDaaS（Identity as a Service）などがある。IDaaSを利用する場合でも、最終的な責任は、ユーザー組織にあることを忘れてはならない。

参考までに、Google Workspaceでは、A.5.4 (a)に関して、以下のような管理策を提示している。

[Google Workspaceユーザーの責任]

  •  カスタマーは、自身のシステムアカウントユーザーを管理および追跡する責任を負う。この責任には、Google Workspaceユーザーアカウントを管理するために利用可能なツールを使用することが含まれる。

[Googleの責任]

  •  Google Workspaceは、カスタマーがユーザーやそのデバイスを簡単に追加し、管理できる集中型ダッシュボードを提供する。

オンプレミスとクラウドの連携環境で複雑化する物理的なアクセス制御

次に、A.5.4 (i)の物理的なアクセス制御については、以下の通りクラウドプロバイダー共通の管理策を提示している。

【サイバーエッセンシャルズ】
A.5.4 (i) <要求事項>
物理的なアクセス制御を実施し、認可された従業員や契約者のみが組織のIT資産および／または環境にアクセスできるようにする必要がある。たとえば、作業用端末を固定するためのケーブルロックの使用や、認証および承認された入室を行うためのカードアクセス式ドアロックの利用が挙げられる。
【サイバーエッセンシャルズ向けクラウドセキュリティコンパニオンガイド】
[エンドユーザー組織(SaaSカスタマー)の責任]
• エンドユーザー組織（SaaSカスタマー）は、物理的なアクセス制御について責任を負わない。
[クラウドプロバイダーの責任]
-[SaaSプロバイダー]
（該当なし）
-[クラウドインフラストラクチャプロバイダー]
• クラウドインフラストラクチャプロバイダーは、基盤となるクラウドインフラストラクチャの物理的なセキュリティに責任を負う。
• 主要クラウドインフラストラクチャプロバイダーは、物理的なセキュリティ対策に関するベストプラクティスを公開していることが一般的である。

これらを受けて、Microsoft版ガイドでは、以下のように管理策を提示している。

[エンドユーザー組織(SaaSカスタマー)の責任(例. Microsoft 365カスタマー)]
（該当なし）
[クラウドプロバイダーの責任]
-[SaaSプロバイダー(例. Microsoft 365)]

  •  Microsoft Azureに関する情報を確認する。

-[クラウドインフラストラクチャプロバイダー(例. Microsoft Azure)]

物理的なアクセス制御は、エンドユーザー組織（SaaSカスタマー）の責任範囲外であるが、Microsoftの場合、クラウドプロバイダー（例. Microsoft 365、Microsoft Azure）としての管理状況をユーザー組織が確認できる仕組みになっている。

ただし、オンプレミス環境における物理的なアクセス制御について、クラウドプロバイダーは言及していない。参考までにGoogle Cloudの場合、「カスタマーは、自身のローカル環境における物理的なスペースおよび資産のセキュリティを確保する責任を負う。」と明記してある。ハイブリッド環境上のSaaSでは、ユーザーがオンプレミス環境とクラウド環境の間をシームレスに行き来しながら利用するのが普通だが、物理的なアクセス制御に関する責任分担は異なるので、注意が必要だ。

非アクティブなアカウントの維持管理は要注意

さらに、A.5.4 (k)の非アクティブなアカウントに関して、以下の通りクラウドプロバイダー共通の管理策を推奨している。

【サイバーエッセンシャルズ】
A.5.4 (k) <推奨事項>
長期間（例：60日間）非アクティブまたは休眠状態となっているアカウントは、削除または無効化されるべきである。
[クラウドプロバイダーの責任]
-[SaaSプロバイダー]
（該当なし）
-[クラウドインフラストラクチャプロバイダー]
（該当なし）

これらを受けて、Microsoft版ガイドでは、以下のように管理策を提示している。

[エンドユーザー組織(SaaSカスタマー)の責任(例. Microsoft 365カスタマー)]
（該当なし）
[クラウドプロバイダーの責任]
-[SaaSプロバイダー(例. Microsoft 365)]

-[クラウドインフラストラクチャプロバイダー(例. Microsoft Azure)]

未使用のユーザーアカウントの場合、一定期間が経過すると、データの削除やサービスの無効化が行われる規定になっていることがあるので、クラウドユーザーは、定期的に未使用のユーザーアカウントを確認し、必要な措置を講じておく必要がある。

参考までにGoogle Cloudの場合、「カスタマーは、Google Workspaceアカウントを含むすべての非アクティブなユーザーアカウントを削除または無効化する責任を負う。」と明記している。

プロバイダーや政府機関が推奨する多要素認証（MFA）

A.5.4 (l)のパスワード管理に関して、以下の通りクラウドプロバイダー共通の管理策を提示している。

【サイバーエッセンシャルズ】
A.5.4 (l) <要求事項>
組織は、すべてのデフォルトのパスワードを変更し、強力なパスフレーズに置き換える必要がある。たとえば、12文字以上で、大文字、小文字、および／または特殊文字を含むべきである。
【サイバーエッセンシャルズ向けクラウドセキュリティコンパニオンガイド】
[エンドユーザー組織(SaaSカスタマー)の責任]

  •  SaaSサブスクリプションごとに別々のパスワードを維持・管理するのではなく、アイデンティティプロバイダーとSSOの使用に関するA.5.4(a)のガイダンスを参照のこと。
  • もし別々のパスワードを維持・管理する必要がある場合：
    • 安全なパスフレーズの使用を導入する。
    • パスフレーズが複数のSaaSサブスクリプション間で再利用されないようにする。
    • パスフレーズが複数のアカウント間で共有されないようにする。

[クラウドプロバイダーの責任]
-[SaaSプロバイダー]
（該当なし）
-[クラウドインフラストラクチャプロバイダー]
（該当なし）

これらを受けて、Microsoft版ガイドでは、以下のように管理策を提示している。

[エンドユーザー組織(SaaSカスタマー)の責任(例. Microsoft 365カスタマー)]
（該当なし）
[クラウドプロバイダーの責任]
-[SaaSプロバイダー(例. Microsoft 365)]

パスワード管理についてはSaaSユーザーが責任を持っている。これに対してMicrosoftは、一貫してMFAの導入を推奨しており、シンガポールサイバーセキュリティ庁も、MFAの重要性を訴えている（https://www.csa.gov.sg/alerts-and-advisories/advisories/ad-2023-006）。

さらに、A.5.4 (o)の2要素／他要素認証に関しては、以下の通りクラウドプロバイダー共通の推奨事項として提示している。

【サイバーエッセンシャルズ】
A.5.4 (o) <推奨事項>
可能であれば、重要なシステムへの管理者アクセスには二要素認証（2FA）を使用するべきである。たとえば、機密情報や業務に重要なデータを含むインターネット向けシステムが該当する。組織はこれをさまざまな方法で実施することができる。例として、モバイル上の認証アプリケーションやワンタイムパスワード（OTP）トークンの使用が挙げられる。
[エンドユーザー組織(SaaSカスタマー)の責任]

  • SaaSサブスクリプションは公共のインターネット経由でアクセスされる可能性があるため、二要素認証（2FA）を導入して、SaaSサブスクリプションにアクセスするユーザーが本人であることを確認する必要がある。

[クラウドプロバイダーの責任]
-[SaaSプロバイダー]
（該当なし）
-[クラウドインフラストラクチャプロバイダー]
（該当なし）

これらを受けて、Microsoft版ガイドでは、以下のように管理策を提示している。

[エンドユーザー組織(SaaSカスタマー)の責任(例. Microsoft 365カスタマー)]
（該当なし）
[クラウドプロバイダーの責任]
-[SaaSプロバイダー(例. Microsoft 365)]
• A.5.4 (l)を参照
-[クラウドインフラストラクチャプロバイダー]
• A.5.4 (l)を参照

ただし、昨今、シンガポールでは、中間者攻撃（MITM：Man-in-the-Middle Attack）、MFA疲労攻撃、セッションハイジャック／cookie盗難、認証コード／トークン窃盗などの手法を使ってMFAをバイパスする攻撃による被害が増加しており、シンガポールサイバーセキュリティ庁が注意喚起を行っている（https://www.csa.gov.sg/alerts-and-advisories/advisories/ad-2024-020/）。MFAを導入したからといって、セキュリティリスクを100%低減できるわけではない点に注意する必要がある。

今回は、アクセス制御に焦点を当てたが、たとえば取引先の環境に合わせて、Microsoft 365とGoogle Workspaceを併用しなければならないケースが多く見受けられる。そのような場合には、Google Cloud版ガイドとMicrosoft版ガイドを組み合わせて管理策を検討する必要があろう。

CSAジャパン関西支部メンバー
健康医療情報管理ユーザーワーキンググループリーダー
笹原英司

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

CAPTCHA

*