AzureのIDとアクセス管理 — Microsoft Entra ID・MFA・RBACの基礎
この章の目次開く
クラウド時代のセキュリティの主役は、ファイアウォールではなく ID(アイデンティティ) です。社外からもアクセスできるクラウドでは、「正しい人が、正しい権限で、正しくサインインしているか」がセキュリティの境界線になります。
この章では、Azureの認証・認可の中核である Microsoft Entra ID と、MFA・条件付きアクセス・RBACといったアクセス管理の仕組みを整理します。AZ-900の「アーキテクチャとサービス」分野の中でも出題が多いテーマです。
学習者Microsoft Entra IDって最近よく聞くけど、前に勉強したときは「Azure AD」って名前だった気がする…別物なの？
先生同じものです。Azure Active Directory (Azure AD) が2023年にMicrosoft Entra IDに名称変更 されました。古い教材や記事ではAzure AD表記が残っているので、「Entra ID = 旧Azure AD」とまず覚えてしまいましょう。試験は新名称で出題されます。
Microsoft Entra IDとは
Microsoft Entra IDは、クラウドベースのID・アクセス管理サービス です。ユーザーのアカウント情報を一元管理し、AzureやMicrosoft 365、その他のクラウドアプリへのサインインを引き受けます。
役割をひとことで言えば 「クラウドの受付係」 です。
- 社員が誰なのかの台帳(ユーザー、グループ)を持つ
- サインイン(認証)を処理する
- どのアプリに入れるか(アクセス)を制御する
オンプレミスのActive Directoryとの違い
社内ネットワークの世界には、以前から Active Directory Domain Services (AD DS) という仕組みがありました。名前が似ていますが、両者は別物です。
| AD DS (オンプレミス) | Microsoft Entra ID (クラウド) | |
|---|---|---|
| 置き場所 | 社内のドメインコントローラー | Microsoftのクラウド |
| 守る対象 | 社内ネットワークのPC・サーバー | クラウドアプリ・SaaS |
| プロトコル | Kerberos、LDAPなど | OAuth 2.0、SAMLなどWeb標準 |
| 管理単位 | ドメイン・フォレスト | テナント |
外部IDの管理
Entra IDは社員だけでなく、組織の外のユーザー も扱えます。
- B2Bコラボレーション — 取引先のユーザーを自社のテナントにゲストとして招待し、自社アプリを使ってもらう
- 顧客向けID (External ID) — 一般消費者向けアプリのサインアップ・サインイン基盤として使う
認証を強くする — SSO・MFA・パスワードレス
認証(Authentication) とは「あなたが本人であることの確認」です。Entra IDは、パスワードだけに頼らない複数の認証方式をサポートします。
シングルサインオン (SSO)
1回のサインインで複数のアプリにアクセスできる仕組み です。アプリごとにパスワードを覚える必要がなくなります。
利便性のためだけの機能に見えますが、実はセキュリティ対策でもあります。パスワードの使い回しが減り、管理者は「1つのID」を守ることに集中できるからです。
多要素認証 (MFA)
サインイン時に、性質の異なる2つ以上の要素 を要求する仕組みです。
| 要素 | 例 |
|---|---|
| 知っているもの | パスワード、PIN |
| 持っているもの | スマホ(Authenticatorアプリ)、セキュリティキー |
| 自分自身であるもの | 指紋、顔 |
パスワードが漏れても、攻撃者は2つ目の要素(スマホなど)を持っていないためサインインできません。パスワード漏洩に対する最も費用対効果の高い防御 とされています。
パスワードレス認証
さらに進んで、パスワードそのものをなくす 方式です。
- Windows Hello for Business — 顔や指紋+デバイスで認証
- Microsoft Authenticatorアプリ — スマホの通知を承認して認証
- FIDO2セキュリティキー — USBキーなどの物理デバイスで認証
「知っているもの(漏れるもの)」を使わないため、フィッシングに強いのが特長です。
学習者MFAとパスワードレスって何が違うの？どっちも「パスワード以外を使う」って話に聞こえるけど…
先生MFAは「パスワード に加えて もう1要素」、パスワードレスは「パスワードを 使わずに 別の強い要素で」です。パスワードレスも複数要素(デバイス+生体など)を組み合わせるので、実質的にMFAの発展形と捉えるとスッキリしますよ。
条件付きアクセス — 状況に応じてサインインを制御する
条件付きアクセス(Conditional Access) は、サインインの状況(シグナル)をもとに、アクセスを許可・拒否・追加確認する仕組みです。「if-thenルール」と考えるとわかりやすいです。
具体例で見るとこうなります。
- 社内ネットワークからのサインイン → そのまま許可
- 自宅など社外からのサインイン → MFAを要求してから 許可
- 普段と違う国からの不審なサインイン → ブロック
「全員に常にMFA」ではなく、リスクが高いときだけ追加の確認を求める ことで、安全性と利便性を両立します。
RBAC — 「誰が・何に・何をできるか」を管理する
認証を通過した後の問題は 認可(Authorization)、つまり「サインインした人に何をさせてよいか」です。Azureではこれを ロールベースのアクセス制御 (RBAC: Role-Based Access Control) で管理します。
RBACは3つの要素の組み合わせです。
ロールの割り当て = 誰に(プリンシパル) × 何の権限を(ロール) × どの範囲で(スコープ)
| 要素 | 内容 | 例 |
|---|---|---|
| プリンシパル | 権限を受け取る対象 | ユーザー、グループ、アプリ |
| ロール | できる操作のセット | 所有者、共同作成者、閲覧者 |
| スコープ | 権限が効く範囲 | 管理グループ / サブスクリプション / リソースグループ / リソース |
スコープと継承
スコープは第5章で学んだAzureの階層構造に対応しており、上位で割り当てた権限は下位に継承されます。
たとえばサブスクリプションに「閲覧者」ロールを割り当てると、その中のすべてのリソースグループとリソースが閲覧できるようになります。
よく出る組み込みロール
| ロール | できること |
|---|---|
| 所有者 (Owner) | すべての操作+他人への権限付与 |
| 共同作成者 (Contributor) | リソースの作成・変更・削除(権限付与は不可) |
| 閲覧者 (Reader) | 閲覧のみ |
ポータルで試してみよう — Entra IDとRBACの画面を歩く
IDまわりの画面は 見るだけなら無料 です。この章の用語がどこにあるかを確認しましょう。
- ポータル上部の検索ボックスに「Microsoft Entra ID」と入力して選択する
- 「概要」 で自分の テナント(組織の単位)の名前とIDを確認する
- 左メニューの 「ユーザー」 を開くと、自分のアカウントがディレクトリに登録されているのがわかる
- 次にRBACを見る。第5章で作ったリソースグループを開き、左メニューの 「アクセス制御 (IAM)」 をクリック
- 「ロールの割り当て」 タブに「誰に・どのロールが・この範囲で」付いているかの一覧が表示される。「+ 追加」→「ロールの割り当ての追加」 を押すと、所有者・共同作成者・閲覧者などのロール一覧も見られる(割り当てずに閉じてOK)
「RBAC = プリンシパル × ロール × スコープ」という抽象的な式が、「IAM」画面の実物を見ると一気に具体化します。
まとめ
- Microsoft Entra ID(旧Azure AD) はクラウドのID・アクセス管理サービスで、認証と認可の中核
- オンプレミスの AD DS とは別物(Web標準プロトコル・テナント単位で管理)
- 認証強化の3点セットは SSO(1回のサインイン)・MFA(複数要素)・パスワードレス(パスワード廃止)
- 条件付きアクセス はシグナルに応じて「許可 / MFA要求 / ブロック」を判定するif-thenルール
- RBAC は「プリンシパル × ロール × スコープ」で権限を管理し、上位スコープの権限は下位に継承される
次の章では、ID以外のセキュリティの考え方——ゼロトラスト・多層防御・Microsoft Defender for Cloud を見ていきます。