Microsoft Entra ID（旧Azure AD）入門｜認証・認可・SSO設定の実践ガイド

「社員のアカウント管理がバラバラで、SaaSごとにIDとパスワードが異なる」「退職者のアカウントが残っていないか不安」――こうした課題は、Microsoft Entra ID（旧Azure Active Directory）で解決できます。

Microsoft Entra IDは、Microsoftが提供するクラウドベースのID管理・アクセス管理サービスです。ユーザーの認証（本人確認）と認可（アクセス権限の制御）を一元的に管理し、Microsoft 365やAzureだけでなく、数千種類のSaaSアプリケーションとのシングルサインオン（SSO）を実現します。

この記事では、Microsoft Entra IDの基本概念から、テナントの構成、ユーザー・グループ管理、SSO設定、条件付きアクセスポリシー、多要素認証（MFA）の導入まで、IT担当者・エンジニアが実務で必要とする知識を体系的に解説します。

Microsoft Entra IDとは？オンプレミスADとの違い

Microsoft Entra IDは、2023年にAzure Active Directory（Azure AD）からリブランドされたサービスです。機能面に変更はなく、名称のみが変わりました。

オンプレミスActive Directoryとの比較

従来のオンプレミスActive Directory（AD DS）とMicrosoft Entra IDは、根本的に異なるアーキテクチャを採用しています。

• プロトコル：オンプレミスADはKerberos / LDAP、Entra IDはOAuth 2.0 / OpenID Connect / SAML
• ネットワーク：オンプレミスADは社内ネットワーク中心、Entra IDはインターネット経由のクラウドサービスに対応
• デバイス管理：オンプレミスADはグループポリシー（GPO）、Entra IDはMicrosoft Intune / 条件付きアクセス
• 構成管理：オンプレミスADはOU（組織単位）の階層構造、Entra IDはフラットなグループベースの管理

多くの企業では、オンプレミスADとEntra IDをMicrosoft Entra Connectで同期させるハイブリッド構成を採用しています。これにより、既存の社内アカウントでクラウドサービスにアクセスできるようになります。

ライセンスプラン

Microsoft Entra IDには、以下のプランがあります。

• Free：基本的なユーザー管理とSSO。Microsoft 365やAzureサブスクリプションに含まれる
• P1：条件付きアクセス、動的グループ、セルフサービスパスワードリセット。月額約750円/ユーザー
• P2：P1の機能に加え、ID保護（リスクベースの条件付きアクセス）、Privileged Identity Management（PIM）。月額約1,130円/ユーザー

本番環境で条件付きアクセスポリシーやMFAの詳細な設定を行うには、P1以上のライセンスが必要です。

テナントの構成とユーザー管理

Microsoft Entra IDの管理単位は「テナント」です。テナントは組織（会社）に対して1つ作成されるのが一般的です。

ユーザーの作成と管理

Azure CLIまたはMicrosoft Graph APIを使って、ユーザーをプログラム的に管理できます。

# Azure CLIでユーザーを作成
az ad user create \
  --display-name "田中太郎" \
  --user-principal-name tanaka@example.onmicrosoft.com \
  --password "InitialPassword123!" \
  --force-change-password-next-sign-in true

# ユーザー一覧の取得
az ad user list --output table

# ユーザーの無効化（退職者対応など）
az ad user update \
  --id tanaka@example.onmicrosoft.com \
  --account-enabled false

退職者のアカウントは削除ではなく、まず無効化することを推奨します。無効化したアカウントは30日以内であれば復元可能です。データの引き継ぎやコンプライアンス要件への対応が完了した後に、完全に削除しましょう。

グループの活用

Microsoft Entra IDのグループは、アクセス権限の管理を効率化するための重要な機能です。

• セキュリティグループ：アプリケーションやリソースへのアクセス権限を付与する目的で使用
• Microsoft 365グループ：Teams、SharePoint、Outlookなどの共有リソースへのアクセスを管理

# セキュリティグループの作成
az ad group create \
  --display-name "SalesTeam" \
  --mail-nickname "salesteam" \
  --description "営業部門のセキュリティグループ"

# グループにメンバーを追加
az ad group member add \
  --group "SalesTeam" \
  --member-id "ユーザーのオブジェクトID"

P1ライセンスでは、動的グループが利用できます。ユーザーの属性（部署、役職、国など）に基づいて、グループメンバーシップが自動的に更新されます。

// 動的グループのルール例：営業部門の全メンバーを自動追加
(user.department -eq "営業部")

シングルサインオン（SSO）の設定

SSOを設定すると、ユーザーはMicrosoft Entra IDに一度サインインするだけで、連携されたすべてのアプリケーションにアクセスできます。

SSOの方式

Microsoft Entra IDは、以下のSSOプロトコルをサポートしています。

• SAML 2.0：エンタープライズ向けSaaSアプリ（Salesforce、ServiceNowなど）で広く採用されている
• OpenID Connect / OAuth 2.0：モダンなWebアプリやAPIで使用される。自社開発アプリとの連携に適している
• パスワードベースSSO：SSOプロトコルをサポートしていないレガシーアプリに対応。ブラウザ拡張機能がパスワードを自動入力する

SAMLベースSSOの設定手順

SaaSアプリケーションとのSAML SSO設定の一般的な手順は以下のとおりです。

1. エンタープライズアプリケーションの追加：Microsoft Entra管理センターで「エンタープライズアプリケーション」→「新しいアプリケーション」からアプリを追加
2. SSO方式の選択：「シングルサインオン」メニューで「SAML」を選択
3. 基本的なSAML構成：
   • 識別子（Entity ID）：SaaS側から提供される一意のID
   • 応答URL（ACS URL）：認証レスポンスの送信先URL
   • サインオンURL：SaaS側のログインURL
4. 属性とクレーム：SaaS側が要求するユーザー属性（メールアドレス、名前など）のマッピングを設定
5. SAML署名証明書：Entra IDが生成した証明書をダウンロードし、SaaS側にアップロード
6. SaaS側の設定：Entra IDのメタデータ（ログインURL、識別子、証明書）をSaaS側の管理画面に入力

自社アプリへのOAuth 2.0 / OIDC統合

自社開発のWebアプリケーションにMicrosoft Entra IDの認証を組み込む場合、MSAL（Microsoft Authentication Library）を使用します。

// Node.js + MSAL.jsの例
const msal = require("@azure/msal-node");

const config = {
  auth: {
    clientId: "アプリケーションのクライアントID",
    authority: "https://login.microsoftonline.com/テナントID",
    clientSecret: "クライアントシークレット"
  }
};

const cca = new msal.ConfidentialClientApplication(config);

// 認証URL の生成
async function getAuthUrl() {
  return await cca.getAuthCodeUrl({
    scopes: ["user.read"],
    redirectUri: "https://myapp.example.com/auth/callback"
  });
}

// トークンの取得
async function acquireToken(authCode) {
  return await cca.acquireTokenByCode({
    code: authCode,
    scopes: ["user.read"],
    redirectUri: "https://myapp.example.com/auth/callback"
  });
}

Azure App ServiceのEasy Auth機能を使えば、コードを変更せずにEntra ID認証を追加することも可能です。

条件付きアクセスポリシーの設計と実装

条件付きアクセスは、「誰が」「どこから」「何のデバイスで」「何にアクセスするか」に基づいて、アクセスの許可・拒否・追加認証を動的に制御する機能です。P1ライセンス以上で利用可能です。

ポリシーの構成要素

条件付きアクセスポリシーは、「条件」と「制御」の組み合わせで定義します。

条件（シグナル）

• ユーザーまたはグループ
• クラウドアプリケーション
• 場所（IPアドレス範囲、国）
• デバイスのプラットフォーム（Windows、iOS、Androidなど）
• デバイスの状態（準拠、Entra ID参加済みなど）
• サインインのリスクレベル（P2ライセンスで利用可能）

アクセス制御

• アクセスをブロック
• アクセスを許可（追加条件付き）
• 多要素認証（MFA）を要求
• 準拠デバイスを要求
• Entra ID参加済みデバイスを要求
• 承認済みクライアントアプリを要求

推奨ポリシーの設定例

以下は、企業環境で推奨される代表的なポリシーです。

ポリシー1：すべてのユーザーにMFAを要求

• 対象：すべてのユーザー（緊急アクセスアカウントを除外）
• 対象アプリ：すべてのクラウドアプリ
• 制御：多要素認証を要求

ポリシー2：社外からの管理者アクセスをブロック

• 対象：グローバル管理者、特権ロール管理者
• 対象アプリ：すべてのクラウドアプリ
• 条件：信頼済みの場所以外からのアクセス
• 制御：アクセスをブロック

ポリシー3：レガシー認証のブロック

• 対象：すべてのユーザー
• 対象アプリ：すべてのクラウドアプリ
• 条件：クライアントアプリがレガシー認証クライアント
• 制御：アクセスをブロック

条件付きアクセスポリシーは、必ず「レポート専用」モードでテストしてから有効にしましょう。意図しないロックアウトを防ぐため、少なくとも1つの緊急アクセスアカウント（Break Glass Account）をすべてのポリシーから除外しておく必要があります。

多要素認証（MFA）の導入

パスワード漏洩によるアカウント侵害を防ぐために、MFAの導入は最も効果的な対策の一つです。Microsoftの調査によると、MFAによりアカウント侵害の99.9%を防げるとされています。

MFAの認証方法

Microsoft Entra IDでは、以下のMFA方法が利用できます。

• Microsoft Authenticatorアプリ（推奨）：プッシュ通知による承認。フィッシングに強い番号マッチング機能あり
• FIDO2セキュリティキー：物理キーによる認証。最もフィッシング耐性が高い
• Windows Hello for Business：生体認証またはPINによるパスワードレス認証
• SMS / 音声通話：電話番号への確認コード送信。セキュリティ面では非推奨だが、導入の容易さから過渡的に利用されることが多い

MFA導入のロードマップ

全社一斉にMFAを導入すると、ユーザーからの問い合わせが集中する可能性があります。以下のような段階的なアプローチを推奨します。

1. Phase 1：管理者アカウントにMFAを強制（条件付きアクセスポリシー）
2. Phase 2：IT部門とパイロットユーザーにMFAを展開
3. Phase 3：全社員にMFAを展開（事前にAuthenticatorアプリの登録手順を周知）
4. Phase 4：レガシー認証のブロック、パスワードレス認証の推進

アプリケーションの登録とAPI権限の管理

自社開発のアプリケーションやサードパーティのサービスがMicrosoft Entra IDの認証を利用するには、アプリケーション登録が必要です。

アプリケーション登録の手順

# アプリケーションの登録
az ad app create \
  --display-name "MyWebApp" \
  --web-redirect-uris "https://myapp.example.com/auth/callback" \
  --sign-in-audience AzureADMyOrg

# サービスプリンシパルの作成
az ad sp create --id "アプリケーションのクライアントID"

# クライアントシークレットの追加
az ad app credential reset \
  --id "アプリケーションのクライアントID" \
  --append \
  --display-name "Production Secret" \
  --years 1

クライアントシークレットの有効期限は最大2年ですが、セキュリティの観点から1年以内に設定し、定期的にローテーションすることを推奨します。可能であれば、証明書ベースの認証やマネージドIDの使用を検討しましょう。

API権限の最小化

アプリケーションに付与するAPI権限は、必要最小限に留めることが重要です。

• 委任されたアクセス許可：サインインしているユーザーの権限でAPIを呼び出す。ユーザーがアクセスできる範囲に限定される
• アプリケーションのアクセス許可：ユーザーのサインインなしでAPIを呼び出す。バックグラウンドジョブやデーモンサービスで使用。管理者の同意が必要

「アプリケーションのアクセス許可」は強力な権限のため、本当に必要な場合のみ使用し、管理者の承認プロセスを設けましょう。

監視とトラブルシューティング

Microsoft Entra IDの運用では、サインインログと監査ログを定期的に確認することが重要です。

サインインログの分析

Microsoft Entra管理センターの「サインインログ」では、以下の情報を確認できます。

• サインインの成功・失敗とその理由
• 条件付きアクセスポリシーの適用結果
• MFAの要求と結果
• アクセス元のIPアドレスと場所
• 使用されたクライアントアプリとデバイス

よくあるトラブルと対処法は以下のとおりです。

• エラーコード 50126：パスワードが間違っている。セルフサービスパスワードリセットの利用を案内する
• エラーコード 53003：条件付きアクセスポリシーでブロックされた。該当するポリシーを確認し、必要に応じて例外を追加する
• エラーコード 50076：MFAが要求されたが完了していない。Authenticatorアプリの設定を確認する

サインインログをより詳細に分析したい場合は、Azure Monitorと連携してLog Analyticsワークスペースにログを転送し、KQLクエリで分析することも可能です。

まとめ：Microsoft Entra IDで実現するゼロトラストセキュリティ

Microsoft Entra IDは、クラウド時代のID管理とアクセス制御の中核を担うサービスです。この記事で解説した内容を振り返ります。

• ID管理：ユーザー・グループの一元管理と動的グループによる自動化
• SSO：SAML / OpenID ConnectによるSaaSアプリとの統合で、ユーザー体験とセキュリティの両方を向上
• 条件付きアクセス：場所、デバイス、リスクレベルに基づいた動的なアクセス制御
• MFA：Authenticatorアプリやセキュリティキーを活用した多要素認証で、アカウント侵害の99.9%を防止
• アプリ登録：最小権限の原則に基づいたAPI権限管理

Entra IDの認証基盤は、Azure App ServiceのEasy AuthやAzure SQL Databaseの認証と連携することで、Azureリソース全体のセキュリティを統一的に管理できます。サーバーレスアプリケーションでの活用については、Azure Functionsの実践ガイドも参照してください。

ゼロトラストセキュリティの考え方をより深く理解したい方は、Azure Virtual Networkの構築ガイドでネットワークセキュリティについても学ぶことをお勧めします。