変更要約: Associate Google Workspace Administrator 第4章を新規作成（ドメイン4「セキュリティ/アクセス」: 認証の強化＝2SV 強制/セキュリティキー・パスキー/SAML SSO/パスワードポリシー/復旧、アクセス制御と対応＝コンテキストアウェアアクセス/セキュリティダッシュボード/アラートセンター/安全性の低いアプリのブロック/侵害時の停止・再設定・セッション失効）。
4.2アクセス制御とセキュリティ対応
コンテキストアウェアアクセスによるデバイス/場所/IP などの条件に応じたアクセス制御、セキュリティダッシュボードとアラートセンターによる脅威の把握と対応、OAuth ベース認証の徹底（Google は 2024 年に「安全性の低いアプリ（LSA）」のサポートを全廃済み）、そして侵害時のアカウント保護の運用を理解します。
認証を強くしても、状況に応じた制御と異常の検知・対応が欠かせません。条件ベースのアクセス制御と、脅威の可視化・対応の仕組みを押さえます。
4.2.1コンテキストアウェアアクセス
コンテキストアウェアアクセス は、ユーザーが満たすべき 条件（デバイスの状態、場所/国、IP 範囲、企業デバイスかどうかなど）に応じてアクセスを許可/制限します（ゼロトラスト的な考え方）。例：管理対象デバイスからのみ Drive にアクセス可、特定の国からはブロック。「条件に応じてアクセスを制御＝コンテキストアウェアアクセス」と結びます。
4.2.2脅威の把握と対応
セキュリティダッシュボード で組織のセキュリティ状況（共有・スパム・認証など）を俯瞰し、アラートセンター で不審なログインやフィッシングなどの アラート を受けて対応します（調査ツールと連携）。古い認証方式の 安全性の低いアプリ はブロックし、侵害が疑われるアカウントは 停止/パスワード再設定/セッション失効 で保護します。「脅威の俯瞰＝セキュリティダッシュボード」「アラートを受けて対応＝アラートセンター」「古い危険な接続を遮断＝安全性の低いアプリのブロック」を押さえます。
「要件 → 手段」が頻出。例：「管理対象デバイスからのみアクセス許可」＝コンテキストアウェアアクセス、「組織のセキュリティ状況を俯瞰」＝セキュリティダッシュボード、「不審ログインの通知を受けて対応」＝アラートセンター、「古い安全でない接続を止める」＝安全性の低いアプリのブロック、「侵害アカウントの即時保護」＝停止/再設定/セッション失効。
混同に注意：
①コンテキストアウェアアクセスは条件ベースの制御で、認証強化（2SV/SSO）とは別レイヤー（組み合わせる）。
②ダッシュボードは俯瞰、アラートセンターは個別の通知対応で役割が違う。
③一部の高度なセキュリティ機能はエディションに依存する。
4.2.3この節のまとめ
- コンテキストアウェアアクセス＝デバイス/場所/IP 等の条件でアクセスを許可・制限
- セキュリティダッシュボードで俯瞰、アラートセンターで通知を受けて対応
- 安全性の低いアプリはブロック、侵害時は停止/再設定/セッション失効で保護
進捗の記録にはログインが必要です。
理解度チェック
（軽い確認用）Q1. 管理対象（企業）デバイスからのみ Drive へアクセスを許可し、それ以外を制限したい。使うのはどれですか？
Q2. 組織全体のセキュリティ状況（共有・スパム・認証など）を一目で俯瞰したい。使うのはどれですか？
Q3. 不審なログインやフィッシングの通知を受けて対応・調査したい。使うのはどれですか？
Q4. 古い認証方式を使う「安全性の低いアプリ」への対処として適切なのはどれですか？
Q5. アカウントの侵害が疑われるとき、即時の保護として最も適切な操作はどれですか？
Q6. コンテキストアウェアアクセスと 2 段階認証プロセスの関係として正しいものはどれですか？