変更要約: DP-300 第2章を深掘り（図ja化・比較表/シナリオ/FAQ/ひっかけ/深掘り段落を全節に追加）
2.1認証とアクセス制御
Azure SQL の 認証（Microsoft Entra 認証 と SQL 認証）と、データベース内での認可（ロール・最小権限）を理解します。誰がどのデータにアクセスできるかを安全に制御します。
データベースの保護はまず「誰がアクセスできるか（認証）」と「何ができるか（認可）」から始まります。Azure SQL では Entra 認証が推奨です。
2.1.1認証と認可
オンプレミスやマルチクラウドの SQL Server も Azure Arc-enabled SQL で Azure の管理面に統合でき、インベントリ・パッチ・Microsoft Defender for Cloud・Azure Policy・監査を一元的に適用できます。クラウドと同じ運用を場所を問わず実現します。
- Microsoft Entra 認証：推奨。一元管理でき、MFA や条件付きアクセスと連携できる。
- SQL 認証：ユーザー名/パスワード。Entra が使えない場合などに用いるが、管理は分散しがち。
- ロールによる認可：サーバー/データベースロールで権限をまとめ、ユーザー個別付与を減らす。
- 最小権限：必要最小限の権限のみ付与する（過剰な db_owner 付与を避ける）。
「推奨される認証＝Microsoft Entra 認証（一元管理・MFA 連携）」「権限はロールでまとめる」「最小権限の付与」 は DP-300 で頻出です。Entra 認証は SQL 認証より集中管理・多要素対応の点で優れます。
コンテインドユーザー（contained user）やマネージド ID を使うと、サーバーログインに依存せずデータベース単位でアクセスを管理しやすくなります。
Azure SQL の認証は階層で理解します。ログイン（サーバー/インスタンスレベル）と ユーザー（データベースレベル）があり、SQL Database では コンテインドユーザー（master のログインに依存せず DB に直接作成）が推奨です。Microsoft Entra 認証 では Entra 管理者 をサーバーに設定し、個人ユーザー・グループ・アプリ（サービスプリンシパル）・マネージド ID を DB ユーザーにマップできます（アプリは Entra トークンで接続＝パスワードレス）。認可は固定 データベースロール（db_datareader/db_datawriter/db_owner 等）とカスタムロール、GRANT/DENY/REVOKE による細粒度権限で構成し、最小権限を徹底します（DENY 優先）。さらに 行レベルセキュリティ（RLS） で行単位、列レベル権限 で列単位に絞れます。ネットワーク面は サーバー/データベースファイアウォール（許可 IP）・プライベートエンドポイント・VNet サービスエンドポイント・公開アクセス無効化で多層化。Entra＋条件付きアクセス＋MFA を組み合わせ、共有 SQL ログインの濫用を避けるのが定石です。
| 観点 | Microsoft Entra 認証 | SQL 認証 |
|---|---|---|
| 資格情報 | Entra ID（トークン）・パスワードレス可 | ユーザー名/パスワード |
| MFA/条件付きアクセス | 対応 | 非対応 |
| 管理 | 一元管理（推奨） | DB 個別・分散しがち |
| アプリ接続 | マネージド ID で安全 | 接続文字列に資格情報 |
シナリオ： アプリから Azure SQL へ接続文字列にパスワードを置かずに接続し、読み取り/書き込みだけ許可したい。→ アプリにマネージド ID を付け、Entra 管理者経由で DB にユーザーとして作成、db_datareader＋db_datawriter を付与（db_owner は付けない）。接続は Entra トークンで行い、ファイアウォール/プライベートエンドポイントで経路も絞ります。
FAQ： Q. ログインとユーザーの違いは？ → A. ログインはサーバー/インスタンス、ユーザーはデータベースの主体。SQL Database では master 依存を避けるコンテインドユーザーが推奨です。Q. 特定の行だけ見せたい時は？ → A. 行レベルセキュリティ（RLS）でユーザーに応じて行をフィルタします。
ひっかけ： 「SQL 認証でも MFA や条件付きアクセスが使える」は誤りです。MFA/条件付きアクセスは Microsoft Entra 認証 の利点。また「アクセス管理を簡単にするため全員に db_owner を付ける」も誤り（最小権限に反し、GRANT より DENY が優先される点も踏まえ必要な権限だけ付与）。
2.1.2この節のまとめ
- 認証＝Entra 認証（推奨）／SQL 認証
- 認可＝ロール＋最小権限
進捗の記録にはログインが必要です。
理解度チェック
（軽い確認用）Q1. Azure SQL で推奨される、一元管理でき MFA や条件付きアクセスと連携できる認証方式はどれですか？
Q2. 多数のユーザーへの権限付与を効率化し、個別付与を減らす方法はどれですか？
Q3. アクセス制御の原則として正しいものはどれですか？