>
>
公開日
最終更新日
オンプレミスのWindows Server環境で広く利用されているActive Directory（AD）。クラウドサービスの利用拡大に伴い、社内のIDをMicrosoft 365や業務SaaSへ安全に連携させる仕組みが必要になっています。その選択肢の一つが、Active Directory フェデレーション サービス、通称ADFSです。
ADFSは既存のAD資産を活用できる一方で、公開サーバー、証明書、Windows Serverの保守を継続的に管理する設計です。本記事は、すでにAD FSを運用している、または認証基盤の更新を検討している情報システム部門（情シス）の担当者を対象に、仕組みだけでなく構築・移行時に判断すべき条件まで整理します。
ADFSとは？
ADFSは、オンプレミスADを活用してクラウドサービスへシングルサインオンを提供する認証連携基盤です。
本記事のポイント
AD FSはAD DSのユーザー情報を直接クラウドへ渡さず、署名付きトークンを発行して認証を仲介します。
高可用性を考慮した構成では、社内のADFSサーバー2台とDMZのWAPサーバー2台にロードバランサーを組み合わせます。
新規構築はクラウドID基盤を優先して比較し、特殊なクレームルールや既存資産がある場合にADFS継続を検討します。
証明書更新と脆弱性対応を運用台帳に組み込めない環境では、認証停止のリスクが残ります。
ADFSは、MicrosoftがWindows Serverの役割として提供するフェデレーション機能です。正式名称はActive Directory Federation Servicesであり、製品資料や管理画面では「AD FS」と表記されることもあります。本記事では原則としてADFSと表記します。
フェデレーションとは、組織内の認証基盤と、外部のサービス提供者の間に信頼関係を設定する仕組みです。ユーザーはクラウドサービスごとに別のパスワードを登録するのではなく、社内ADで本人確認を受けます。ADFSはその結果をセキュリティトークンとして外部サービスへ伝えます。
たとえば、社内ADで管理している従業員がMicrosoft 365、Salesforce、Boxなどへアクセスする場面で利用されます。社内ネットワーク上で統合Windows認証が利用でき、ブラウザと対象サービス側の設定が整っている場合は、Windowsへのサインイン状態を利用したシームレスなSSOも可能です。ただし、端末の参加状態、ブラウザ設定、接続元ネットワーク、サービス側の信頼設定によって動作条件が変わるため、「Windowsログインだけで必ず全SaaSに入れる」仕組みではありません。
Office 365の導入が進んだ2014年から2016年には、ローカルADとOffice 365を連携する方式としてADFSが広く使われました。一方、インプレスの市場調査記事は、2024年度の国内IDaaS売上が前年度比23.9％増の303億5,000万円だったと紹介しています。認証基盤の選択は、サーバーを保有するか、クラウドサービスとして利用するかを含めて見直す段階に入っています。
Microsoftは現在、運用コストとセキュリティの観点から、ADFS環境からクラウドネイティブなID管理基盤であるMicrosoft Entra ID（旧Azure AD）への移行を案内しています。ただし、既存アプリケーションの認証方式まで確認せずに切り替えると業務システムのログインに影響します。ADFSを理解する目的は、構築可否だけでなく、残す認証と移す認証を切り分けることにあります。
ADFS認証の仕組みとSAML連携
ADFSはSAMLやOAuthなどの標準プロトコルを用いてトークンを発行し、ADとクラウドサービスの認証を仲介します。
認証の中心となる役割は、IdPとSPです。IdPはIdentity Providerの略で、ユーザーを認証して属性情報を提供する側を指します。ADFSがIdPとして動作します。SPはService Providerの略で、認証結果を受け取りアプリケーションを提供する側であり、Microsoft 365や各種SaaSが該当します。
SAML認証フロー
SAML連携では、ADFSが発行した署名付きSAMLアサーションをSPが検証してアクセスを許可します。
サービスへのアクセス: ユーザーがブラウザでSPへアクセスします。
認証要求の転送: SPは未認証であることを検知し、SAML認証要求を生成してブラウザをADFSへ転送します。
AD DSでの本人確認: ADFSはAD DSを参照します。社内接続で統合Windows認証の条件を満たす場合はKerberosを利用し、社外接続ではフォーム認証や多要素認証を組み合わせる構成があります。
アサーションの発行: 認証に成功すると、ADFSはユーザーID、メールアドレス、所属グループなどをクレームとして格納したSAMLアサーションを発行します。
署名検証と利用開始: ブラウザがアサーションをSPへ送信し、SPが信頼済み証明書で署名、有効期限、発行者、対象者を検証します。検証が成功した場合だけセッションが開始されます。
この流れでは、ユーザーのADパスワードそのものをSPへ送信しません。代わりに、ADFSが署名した認証結果を渡します。そのため、SP側では「誰が認証したトークンか」「改ざんされていないか」「対象サービス向けに発行されたものか」を検証する設計になります。
最も一般的なSAML認証はWebブラウザを利用したSSOで多く使われます。OAuth 2.0とOpenID Connectは、Web APIやモバイルアプリケーションでアクセストークンやIDトークンを扱う場面に適しています。ADFSでどの方式を使うかは、接続先アプリケーションが要求するプロトコルと、必要なクレーム設計から決めます。
クレームルールとトークン設計
ADFSの認可設計は、AD属性をどのクレームとして外部サービスへ渡すかで決まります。
クレームルールでは、たとえばADのmail属性をName IDへ変換し、グループ情報をロールとして渡すといった設定を行います。ここで同じメールアドレスを複数ユーザーが共有している、UPNとSaaS側ログインIDが一致しない、不要なグループ情報まで送信する、といった状態があるとログインエラーや過剰権限につながります。
ADFS認証を設計する際は、接続先ごとに「識別子に使う属性」「渡す権限情報」「トークンの有効期間」「証明書の更新方法」を記録します。設定画面だけを引き継ぐ方法ではなく、SPごとの信頼関係とクレームルールを台帳化することで、障害時に切り分ける範囲を限定できます。
▶ 関連記事: SAML認証について
▲ SAMLプロトコルによるADFS認証の手順とデータの流れ
ADFSとAD DSの違い
AD DSは社内の身分証明書管理を担い、ADFSは社外サービス利用時の査証発行を担います。
AD DSとADFSは名称が似ているため同一視されることがありますが、両者は代替関係ではありません。AD DSはユーザー、コンピューター、グループ、ポリシーを管理するディレクトリサービスです。ADFSはAD DSの情報を利用し、外部サービスが理解できるフェデレーション用トークンへ変換する認証サービスです。
比較項目 | AD DS | ADFS |
|---|---|---|
主な役割 | 社内のユーザー、端末、グループ、権限の管理 | 社内IDと外部サービス間の認証連携 |
主な対象 | Windowsサインイン、ファイルサーバー、社内ネットワーク | SaaS、Webアプリケーション、組織間連携 |
主なプロトコル | Kerberos、LDAP、NTLM | SAML、WS-Federation、OAuth 2.0、OpenID Connect |
認証結果 | ドメイン内のログオンやアクセス制御 | 署名付きトークンとクレームの発行 |
障害時の主な影響 | 社内リソースやドメイン認証への影響 | 連携先クラウドサービスへのログイン影響 |
AD DSは、社員証の発行元に相当します。ADFSは、その社員証を確認して外部サービス向けの利用許可証を発行する窓口に相当します。ADFS単体ではユーザーアカウントを管理せず、通常はAD DSなどの属性ストアを参照して認証します。
この違いを理解すると、障害時の確認順序も明確になります。社内PCへのサインインやLDAP検索も失敗している場合は、まずAD DSやネットワークを調査します。社内ログオンは正常でSaaSだけが失敗する場合は、ADFS、WAP、ロードバランサー、証明書、SP側のメタデータを順に確認します。Active Directoryの基礎的な役割を押さえたうえで、認証経路ごとに責任範囲を分けることが運用の出発点です。
ADFSの構成要素と構築要件
インターネットから利用するADFSは、内部のフェデレーションサーバーとDMZ上のADFS ProxyであるWAPを分離して構成します。
ADFS構築では、認証機能だけでなく、外部公開、可用性、証明書、名前解決、監視の設計が必要です。小規模な検証環境と、本番の認証基盤を同じ基準で扱うと、障害発生時の影響範囲を見誤ります。
フェデレーションサーバーの役割
フェデレーションサーバーはAD DSを参照し、認証結果に基づいてセキュリティトークンを発行します。
フェデレーションサーバーは社内ネットワークに配置し、AD DSと通信します。Microsoft Learnは、新しいAD FSファームで負荷分散を行う場合、少なくとも2台のフェデレーションサーバーを必要と案内しています。単体構成は検証用途では成立しても、計画停止、OS更新、ハードウェア障害の際に認証を継続できません。
データベースとしてWindows Internal Databaseを使う場合、Microsoft Learnは、フェデレーションサーバー30台以下かつ証明書利用者の信頼が100以下の環境に適した選択肢として説明しています。100を超える場合は外部SQL Serverが必要となります。実際の採用時は、連携先数、可用性、バックアップ・復旧要件を確認し、WIDと外部SQL Serverのどちらが運用設計に合うかを決めます。
ADFS ProxyとWAPの役割
ADFS Proxyとして機能するWAPは、外部からの認証要求をDMZで受け、内部のADFSへ中継します。
WAPはWeb Application Proxyの略です。インターネットからADFSにアクセスさせる場合、ADFSサーバーを直接公開せず、DMZにWAPを配置してHTTPS通信を中継する構成が一般的です。
DMZは、インターネットと社内ネットワークの間に置く隔離ネットワークです。WAPを置く目的は、外部からの接続を一度受け止め、AD DSを含む内部ネットワークを直接公開しないことにあります。DMZの基本的な考え方に沿って、WAPからADFS、ADFSからAD DSへ必要最小限の通信だけを許可します。
高可用性と基本スペック
本番で認証停止を避けるなら、ADFSサーバー2台とWAP2台の計4台を基本単位として可用性を設計します。
高可用性を確保する代表的な構成は、社内ネットワークにADFSサーバー2台、DMZにWAPサーバー2台を置き、それぞれをロードバランサー配下に置く形です。この4台にロードバランサーを加える構成は、高可用性を確保する代表例として広く参照されています。これはすべての環境で一律に必須となる台数ではなく、認証停止を許容できない場合の設計判断です。また、ロードバランサー自体が単一障害点にならないよう冗長化の方式（アクティブ－スタンバイ、アクティブ－アクティブなど）をあわせて検討します。外部公開のリバースプロキシとしてはWAPのほかに既存のリバースプロキシ製品を使う構成もありますが、ADFSとの互換性や前段認証の動作を事前に確認します。
Microsoft Learnは、ADFSまたはWAPをインストールするOSとしてWindows Server 2012 R2以降を示し、最小要件をCPUデュアルコア1.6GHz以上、メモリ2GB以上、Azure VMではA2構成以上と案内しています。これはあくまで最小要件です。本番では同時ログイン数、MFA、監査ログ、将来の連携先追加を見込んで性能試験を実施します。
構築前の確認項目
構築前に通信経路、証明書、名前空間、連携先のメタデータを確定すれば、切替時の認証障害を減らせます。
外部公開用のフェデレーションサービス名とDNS設定
クライアントが信頼するSSL/TLS証明書と更新責任者
インターネットからWAPへのHTTPS、WAPからADFSへのHTTPS、ADFSからAD DSへの必要通信
SPごとの識別子、ACS URL、署名証明書、クレームルール
ロードバランサーのヘルスチェック条件と障害時の切替手順
監視対象となる証明書期限、サービス稼働、イベントログ、外部疎通
外部ユーザーや社外端末から認証を受ける構成では、一般にクライアントから信頼される証明書が必要になります。一方、証明書の発行元や配布方法は利用形態によって異なります。利用端末に社内CA証明書を確実に配布できるならその方式を検討でき、BYODや社外利用を含むならパブリックCA証明書を前提に設計する、と判断を分けます。
▶ 関連記事: DMZ（非武装地帯）とは？仕組みやFW構成を情シス向けに解説
▲ 高可用性を考慮したADFSとWAPの冗長化ネットワーク構成
ADFSを選ぶメリットと適用条件
ADFSの利点は既存ADの認証方式やクレームルールを細かく活用できる点であり、サーバー運用を許容できる条件で価値が出ます。
ADFSはWindows Serverの役割として提供されるため、既存のWindows ServerライセンスとCALの条件下では、ADFS機能そのものにユーザー単位の追加SaaS料金は発生しません。ただし、これは総保有コストがゼロという意味ではありません。サーバー、OS保守、ロードバランサー、証明書、監視、障害対応の費用と人員を合算して判断します。
既存AD資産との親和性
複雑なAD属性や既存の認証ルールを維持する必要がある場合、ADFSは移行までの認証連携手段になります。
オンプレミスADにユーザー属性、組織情報、グループ権限が集約されている環境では、ADFSのクレームルールで連携先ごとの属性変換を行えます。特定部署だけにアプリケーションを許可する、UPNと外部サービスのログインIDを変換する、取引先向けに別の認証規則を設けるといった要件に対応できます。
また、AD認証を必要とする既存資産が残る場合は、いきなりオンプレミスを廃止するのではなく、ADとMicrosoft Entra IDを同期・連携するハイブリッド構成が現実的です。ソフトクリエイトのS-FIT社導入事例でも、AD認証を必要とする既存資産を背景に、オンプレミスのActive DirectoryとMicrosoft Entra IDを連携するハイブリッド構成が選択されています。
クラウドID基盤との比較軸
ADFSとクラウドID基盤は、機能の優劣ではなく認証要件と運用責任の置き場所で比較します。
比較軸 | ADFS | Microsoft Entra IDなどのクラウドID基盤 |
|---|---|---|
認証基盤の配置 | 自社のオンプレミスまたはIaaSで運用 | クラウドサービスとして利用 |
インフラ保守 | OS、WAP、負荷分散、証明書を自社で管理 | 基盤運用はサービス事業者側が担当 |
既存クレームルール | 細かな既存ルールを継続しやすい | 対応可否をアプリケーション単位で確認 |
条件付きアクセス | 独自設計と周辺製品の組み合わせが中心 | 端末状態、場所、リスクなどを統合しやすい |
費用の見え方 | 機能利用料よりインフラ・人件費の比重が大きい | ユーザー単位ライセンスとプラン条件を確認 |
料金や含まれる機能は契約プラン、既存のMicrosoft 365ライセンス、地域、契約時期で変わります。公開情報だけでは自社テナントで利用可能なライセンス機能を確定できないため、契約情報と管理画面で対象を照合します。条件付きアクセスやMFAの要件を満たせるライセンスが確認できればクラウドID基盤の限定検証へ進み、確認できなければ必要な追加契約とADFS継続コストを同じ期間で比較します。
IDaaSの導入・検討は広がっています。調査会社の発表をPR TIMESが紹介した調査では、IDaaSを「導入している」と答えた企業は83.7％、「導入を検討中」は6.7％で、合計90.4％でした。また、リプレイスを実施済みまたは検討中の回答者では、「運用・管理が複雑で負荷が大きい」が39.4％で最多の理由でした。ADFSの採否は、初期構築費だけでなく、こうした継続運用の負荷を数年単位で見積もる必要があります。
▶ 関連記事: IDaaSとは？機能や導入メリットをわかりやすく解説
ADFS認証のリスクと失敗パターン
ADFS認証の最大の課題は、認証基盤の停止が複数のクラウドサービスのログイン停止へ連鎖する点です。
ADFSは認証の入口に集約されるため、障害時の影響範囲が広くなります。特に外部公開するWAP、フェデレーションサービス名の名前解決、ロードバランサー、SSL/TLS証明書、トークン署名証明書のどれか一つに問題が起きると、ユーザーからは「Microsoft 365に入れない」「SaaSにログインできない」という同じ症状に見えます。
証明書更新漏れ
証明書の期限切れは、正しいIDとパスワードでも全社的なログイン失敗を起こす失敗パターンです。
ADFSでは、通信を保護するSSL/TLS証明書のほか、トークン署名証明書、トークン暗号化証明書を扱います。証明書を更新しても、SP側が新しい署名証明書やメタデータを取り込めなければ、アサーションの署名検証に失敗します。証明書を自動更新する設定があっても、連携先が自動反映に対応していない場合は手作業が残ります。
Microsoft Learnは、New-AdfsAzureMfaTenantCertificateコマンドレットで作成したMicrosoft Entra多要素認証用の証明書が、既定で2年間有効であると案内しています。少なくとも有効期限の90日前、30日前、7日前に通知する監視を設定し、更新後に代表的なSPでログイン試験を行う運用にすると、更新作業を担当者個人の記憶に依存させずに済みます。
脆弱性と公開面の管理
インターネット公開面を持つADFSでは、OS更新とセキュリティ情報の確認を認証運用の定常業務に組み込みます。
IPAは2026年7月の注意喚起「Microsoft製品の脆弱性対策について（2026年7月）」（IPA公式ページ）で、Active Directoryフェデレーションサービスにおける特権昇格の脆弱性を取り上げ、Microsoftが実際の悪用を確認したと公表しています。なお、CVE番号や対象バージョン、適用すべき更新プログラムの詳細は同ページおよびMicrosoftのセキュリティ更新プログラムガイドで確認してください。適用対象バージョンに合致しない場合は緊急度の評価が変わります。脆弱性の影響有無は利用しているWindows Server、更新プログラム、ADFS構成に左右されますが、公開サーバーだから後回しにする判断はできません。脆弱性情報を受け取ったら、対象バージョンの照合、更新可否の評価、検証環境での適用、本番反映、ログ確認までを一連の変更管理として扱います。
さらに、トークン署名証明書の秘密鍵を侵害されると、攻撃者が正規ユーザーを装うトークンを作成する危険があります。Solorigateで注目されたような認証基盤への攻撃では、パスワード変更だけでは根本対応にならない場合があります。秘密鍵へのアクセス権を限定し、管理者アカウントには多要素認証を適用し、異常なトークン発行や設定変更を監査ログで追跡できる状態にします。
やってはいけない運用
ADFSの構成情報と証明書の責任者を台帳化せず、単一担当者に依存する運用は避けます。
よくある失敗は、「証明書は自動更新されるため管理不要」と判断することです。SP側の証明書登録、WAPへの証明書配布、ロードバランサーの設定、緊急時の連絡先は自動化の対象外になることがあります。認証先一覧、証明書の用途・期限、更新手順、ロールバック方法、担当・代替担当を1つの台帳に集約します。
また、パッチ適用を認証停止が怖いという理由で先送りすると、脆弱性が残ります。冗長化された2台構成であれば、片系ずつの更新とヘルスチェック、認証試験を実施することで、停止リスクと未更新リスクを分けて管理できます。
Microsoft Entra IDへの移行判断と段階的な切替
新規の認証連携はクラウドID基盤を優先して検討し、ADFS固有の要件が残るアプリケーションだけを段階的に切り替えます。
ADFSからMicrosoft Entra IDへ移行する際は、認証方式を変えるだけでは不十分です。ユーザーのUPN、パスワード同期、MFA、条件付きアクセス、端末管理、アプリケーションごとのSAML設定、グループ・ロール連携を確認します。ADFSを停止してから問題を探す進め方ではなく、依存関係を可視化して対象を分けます。
維持を検討する例外条件
オンプレミス連携が必須の既存資産や特殊なクレームルールがある場合は、ADFSを一時的に維持する選択肢があります。
具体的には、ADFS独自の複雑なクレーム変換を前提にした業務アプリケーション、移行先で代替できない認証方式、オンプレミスの認証連携に強く依存する既存資産、変更時に長期の業務影響が出る第三者アプリケーションなどです。こうした条件がある場合でも、すべてを恒久的に残すのではなく、対象アプリケーション、代替手段、改修予定、ADFS依存を解消する期限を整理します。
一方、SAMLまたはOpenID Connectに対応し、必要なユーザー属性と権限をクラウドID基盤で表現でき、MFA・端末条件・監査ログの要件を満たせるアプリケーションは移行候補です。デジタル庁の本人確認ガイドライン改定資料でも、既存のフェデレーションプロトコルにおいて、OpenID ConnectやSAML Web SSOプロファイルを用いた実装例が示されています。
移行判断のタイムライン
移行は棚卸し、限定切替、全体切替、ADFS縮退の順に進めると、認証障害の原因を切り分けやすくなります。
フェーズ | 実施内容 | 判断結果 |
|---|---|---|
1. 棚卸し | SP一覧、プロトコル、クレーム、証明書、利用者、管理者を記録 | 依存関係が不明なサービスはADFS継続対象に仮置き |
2. 互換性評価 | 移行先で属性、MFA、権限、ログ要件を満たせるか検証 | 要件を満たすサービスから限定切替へ進行 |
3. 限定切替 | 対象グループを限定し、ログイン、権限、監査ログを試験 | 失敗時は対象グループをADFS認証へ戻して原因分析 |
4. 全体切替 | 利用部門ごとに展開し、ヘルプデスクと障害連絡を準備 | 残存アプリだけをADFS依存として管理 |
5. 縮退・廃止 | 信頼関係、公開DNS、WAP、証明書を順に廃止 | 認証ログと業務影響を確認後に停止 |
Microsoft Learnは、フェデレーションドメインをマネージドドメインへ切り替える完全なカットオーバーに最大4時間かかる場合があると案内しています（参照：ADFSからMicrosoft Entra IDへの移行に関するFAQ）。切替時間中に影響が出る前提で、業務時間外の実施、問い合わせ窓口、ロールバック条件を計画します。なお、移行は「アプリケーション単位のSAML設定をEntra ID側へ移す作業」と「Microsoft 365ドメインのフェデレーション解除（マネージド化）」を分けて進めることができます。個別アプリのSAML移行は他のアプリに影響せず実施でき、ドメインのフェデレーション解除は対象ドメイン全ユーザーへの影響があるため最後に行います。切替後に認証ログと代表ユーザーのアクセスを確認できれば次のグループへ進み、確認できなければ新規グループへの展開を止めてフェデレーション設定を復旧します。
マネージドサービスを利用する選択肢もあります。ソフトクリエイトのSCCloud 365 Enterpriseは、Microsoft Entra ID、Microsoft Intune、Microsoft Defenderなどを活用し、24時間365日の監視を一体的に支援すると発表しています。自社で夜間監視や証明書運用を担えない場合は、どこまでを自社で管理し、どこからを外部サービスへ委託するかを契約条件と責任分界で決めます。
▶ 関連記事: プロビジョニングとは？デプロイとの違いや種類を解説
▲ ADFSの継続利用かMicrosoft Entra IDへの移行かを判断するフロー
ADFSに関するよくある質問
ADFSの採否は、既存アプリケーションの認証要件と、認証基盤を継続運用できる体制の両方で判断します。
ADFSとMicrosoft Entra IDの選定
新規導入では、オンプレミス固有の要件がなければMicrosoft Entra IDを中心に設計します。
サーバー、WAP、証明書、OSパッチの運用を自社で持たずに済むためです。ただし、特殊なクレームルールや既存アプリの認証方式が移行先で再現できない場合は、そのアプリケーションだけをADFSに残して段階的に移行します。
ADFSの段階的な廃止
ADFSはユーザーやアプリケーションを分けて段階的に廃止できます。
Microsoftはフェデレーションからマネージド認証へ移行する方法を案内しています。切替対象のグループを限定し、ログイン、権限、MFA、監査ログが正常であることを確認できた場合だけ対象を拡大します。ADFSからMicrosoft Entra IDへの移行に関するMicrosoft LearnのFAQも、移行設計時の確認材料になります。
トークン署名証明書の更新
トークン署名証明書はADFSだけでなく、連携先SPの証明書登録状況まで含めて更新します。
AutoCertificateRolloverで新しい証明書を生成できる構成でも、SPがメタデータを自動取得しない場合は手動反映が必要です。期限前に新旧証明書での検証を行い、反映できないSPがあれば切替日前に保守窓口と作業日を確定します。
ADFS ProxyとWAPの必要性
社外からADFSを利用させる場合は、内部のADFSを直接公開せず、DMZ上のWAPで中継します。
WAPは外部からの認証要求を受けて内部のフェデレーションサーバーへ転送します。社内ネットワークからだけ利用する閉域構成と、インターネット公開する構成では必要なネットワーク設計が異なるため、利用者の接続元を基準に構成を決めます。
まとめ
ADFSの適切な運用とクラウド移行へ向けた第一歩は、認証の依存関係を可視化することです。
ADFSは、既存のAD DSを活用してSaaSやWebアプリケーションへのSSOを実現できる認証基盤です。一方で、WAPを含む公開構成、複数サーバーの可用性、証明書更新、脆弱性対応を継続して管理する必要があります。新規構築ではクラウドID基盤を優先して比較し、オンプレミス連携や特殊なクレームルールが残るサービスだけを例外として扱います。
最初に行う棚卸し
明日からは、ADFSに依存するサービスと証明書の一覧を作成します。
ADFS連携中のSP、利用者、認証プロトコル、クレームルールを一覧化します。
SSL/TLS証明書、トークン署名証明書、MFA証明書の用途と有効期限を記録します。
ADFSサーバー、WAP、ロードバランサー、DNSの監視担当と障害連絡先を明確にします。
各アプリケーションについて、Microsoft Entra IDで認証・権限・監査要件を満たせるか評価します。
移行可能なサービスは限定ユーザーで試験し、移行できないサービスは残存理由と解消予定日を管理します。
本記事の内容に誤り等がございましたら、こちらからご連絡ください。
監修
橋爪兼続
ライトハウスコンサルタント代表。2013年海上保安大学校本科第Ⅲ群（情報通信課程）卒業。巡視船主任通信士を歴任し、退職後、大手私鉄の鉄道運行の基幹システムの保守に従事。一般社団法人情報処理安全確保支援士会の前身団体である情報処理安全確保支援士会の発起人。情報処理安全確保支援士(第000049号)。
