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設定の一般的な手順は以下のとおりです。

エンタープライズアプリケーションの追加：Microsoft Entra管理センターで「エンタープライズアプリケーション」→「新しいアプリケーション」からアプリを追加
SSO方式の選択：「シングルサインオン」メニューで「SAML」を選択
基本的なSAML構成：
- 識別子（Entity ID）：SaaS側から提供される一意のID
- 応答URL（ACS URL）：認証レスポンスの送信先URL
- サインオンURL：SaaS側のログインURL
属性とクレーム：SaaS側が要求するユーザー属性（メールアドレス、名前など）のマッピングを設定
SAML署名証明書：Entra IDが生成した証明書をダウンロードし、SaaS側にアップロード
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を導入すると、ユーザーからの問い合わせが集中する可能性があります。以下のような段階的なアプローチを推奨します。

Phase 1：管理者アカウントにMFAを強制（条件付きアクセスポリシー）
Phase 2：IT部門とパイロットユーザーにMFAを展開
Phase 3：全社員にMFAを展開（事前にAuthenticatorアプリの登録手順を周知）
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の構築ガイドでネットワークセキュリティについても学ぶことをお勧めします。