4.2ID・アクセスとセキュリティ

クラウドを安全に使う土台が ID（アイデンティティ） です。境界（社内ネットワーク）で守る時代から、「ID こそが新しい境界」という考え方へ移りました。この節では、ID 管理（認証・認可・Entra ID・RBAC）と、それを取り巻くセキュリティの考え方（ゼロトラスト・多層防御・Defender for Cloud）をまとめて押さえます。

4.2.1認証と認可

「あなたが誰か」を確かめる 認証（AuthN）と、「何にアクセスできるか」を決める 認可（AuthZ）は別の概念です。順序は必ず 認証 → 認可：まず本人と確認し、その後に「このリソースを操作してよいか」を判断します。試験ではこの2語を入れ替えた選択肢が頻出です。

機密情報の保護には Azure Key Vault を使います。API キー・接続文字列・証明書・暗号化キーを安全に一元管理し、アプリやサービスはコードに秘密を直書きせずマネージド ID 経由で取得します。アクセスは Microsoft Entra ID と RBAC で制御します。

4.2.2Microsoft Entra ID と認証の強化

• Microsoft Entra ID（旧 Azure AD）：クラウドのID／アクセス管理サービス。ユーザー・グループ・アプリのサインインを管理。
• 多要素認証（MFA）：パスワードに加え第二の要素（スマホ承認・コードなど）で本人確認を強化。
• パスワードレス：パスキー・Windows Hello・Authenticator アプリなどで、パスワード自体を使わずより安全にサインイン。
• シングルサインオン（SSO）：一度のサインインで複数のサービスを使えるようにする。
• 条件付きアクセス（Conditional Access）：場所・デバイス・リスクなどの条件に応じてアクセスを許可／追加要求（例：社外なら MFA 必須）。
• 外部 ID（B2B/B2C）：取引先（B2B）や顧客（B2C）などの社外ユーザーを扱う仕組み。

4.2.3認可の仕組み：RBAC

認可を実際に担うのが RBAC（ロールベースのアクセス制御） です。「誰に（ユーザー/グループ）・どの役割を（閲覧者/共同作成者/所有者など）・どの範囲で（前章のスコープ：管理グループ〜リソース）」割り当てて権限を与えます。原則は 最小権限——必要な人に、必要な範囲で、必要なだけ。割り当てはスコープの下位へ継承されるため、広い権限は上位に当てると効きすぎる点に注意します。

4.2.4Entra ID とオンプレミスの AD DS

Microsoft Entra ID はクラウドの ID サービスで、Web/SaaS アプリやデバイス向けに最新のプロトコル（OAuth/OpenID Connect/SAML）で動きます。一方、Active Directory Domain Services（AD DS）はオンプレミスのドメイン（社内の PC やサーバーを Kerberos/LDAP で管理）です。両者は別物で、Entra ID はドメイン参加やグループポリシーの仕組みではありません。ハイブリッド構成では Entra Connect で同期して連携できます。

4.2.5セキュリティの考え方

ゼロトラスト は「決して信頼せず、常に検証する（never trust, always verify）」という現代の指針です。社内ネットワークの内側だからと無条件に信頼せず、アクセスのたびに ID・デバイス・状況を検証します（条件付きアクセスや MFA はその実装手段）。これと対になるのが 多層防御（defense in depth）——防御を何層にも重ね、1つ破られても次の層で守る考え方です。

これらの状態をまとめて可視化・強化するのが Microsoft Defender for Cloud です。リソースのセキュリティ状態を採点（セキュアスコア）し、設定の不備や脅威を検出して改善を促します。責任共有モデルで自分が担う範囲（設定・ID・データなど）を継続的に評価し、優先度付きの是正策を提示する役割です。

4.2.6この節のまとめ

• 認証（誰か）→ 認可（何ができるか） の順。認可の実装が RBAC（最小権限・スコープ継承）
• Entra ID＝クラウドのID。MFA/SSO/パスワードレス/条件付きアクセス/外部ID。≠ AD DS（オンプレ）
• ゼロトラスト＝常に検証／多層防御＝重ねて守る／Defender for Cloud＝状態を採点・強化