次の方法で共有


フェーズ 2:アプリを分類し、パイロットを計画する

アプリの移行を分類することは、重要な演習です。 すべてのアプリを同時に移行して切り替える必要はありません。 各アプリに関する情報を収集したら、最初に移行する必要があるアプリと、時間がかかる可能性があるものを合理化します。

対象となるアプリを分類する

このアスペクトについて考える 1 つの方法は、ビジネス上の重要度、使用状況、および有効期間の軸に沿うことです。これらはそれぞれ、複数の要因に依存しています。

ビジネス上の重要度

ビジネス上の重要度には、ビジネスごとに異なるディメンションが使用されますが、考慮する必要がある 2 つの基準は、特徴と機能およびユーザー プロファイルです。 機能が重複しているか古いアプリよりも高いポイント値を、固有機能を持つアプリに割り当てます。

特徴と機能およびユーザー プロファイルの適用範囲を示す図。

使用法

使用率の高いアプリケーションが、使用率の低いアプリよりも高い値を受け取る必要があります。 外部、経営幹部、またはセキュリティ チーム ユーザーが存在するアプリにはより高い値を割り当てます。 移行ポートフォリオ内の各アプリについて、これらの評価を完了します。

ユーザーのボリュームとユーザーの幅のスペクトラムを示す図。

ビジネス上の重要度と使用状況の値を決定したら、アプリケーションの有効期間を決定し、優先順位のマトリックスを作成できます。 この図はマトリックスを示しています。

使用状況、予想される有効期間、ビジネス上の重要度の関係を示す三角形の図。

Note

このビデオでは、移行プロセスのフェーズ 1 とフェーズ 2 の両方を取り上げています。

移行するアプリに優先度を付ける

組織のニーズに基づいて、優先度の最も低いアプリまたは優先度の最も高いアプリのいずれかを使用して、アプリの移行を開始することを選択できます。

Microsoft Entra ID と ID サービスの使用経験がないと思われるシナリオでは、まず優先度の最も低いアプリを Microsoft Entra に移行することを検討してください。 このオプションにより、ビジネスへの影響を最小限に抑え、徐々に進めていくことができます。 これらのアプリを正常に移動し、利害関係者の信頼を得たら、他のアプリの移行を続けることができます。

明確な優先度がない場合は、Microsoft Entra ギャラリーにあり、複数の ID プロバイダーをサポートするアプリからまず移行することを検討してください。これらは統合が容易であるためです。 これらのアプリは、組織内で優先度の最も高いアプリである可能性があります。 SaaS アプリケーションを Microsoft Entra ID と統合するのに役立つように、構成を段階的に説明するチュートリアルのコレクションがあります。

アプリの移行期限がある場合、これらの優先度の最も高いアプリのバケットに重点を置いて作業します。 期限を遅らせてもコストは変わらないため、最終的には優先度の低いアプリを選択できます。

この分類に加え、移行の緊急度に応じて、アプリ所有者がそれぞれのアプリを移行するために取り組む必要がある移行スケジュールを公開する必要があります。 このプロセスの最後には、移行のために優先度が付けられたバケットのすべてのアプリケーションの一覧が用意できているはずです。

アプリをドキュメント化する

まず、アプリケーションについての重要情報を収集します。 アプリケーション検出ワークシートを使用すると、移行に関する決定を迅速に行い、ビジネス グループに対してすぐに推奨事項を伝えることができます。

移行を決定するうえで重要な情報には、次のものがあります。

  • アプリ名 – ビジネスにおいて、このアプリは何と呼ばれていますか?
  • アプリの種類 – サードパーティの SaaS アプリですか? カスタムの基幹 Web アプリですか? API ですか?
  • ビジネス上の重要度 – その重要度は高いですか? 低いですか? それともその中間ですか?
  • ユーザー アクセス ボリューム – このアプリにはすべてのユーザーまたはごく少数のユーザーがアクセスしますか?
  • ユーザー アクセスの種類: アプリケーションにアクセスする必要があるのはどのユーザーですか? 従業員、ビジネス パートナー、顧客、またはすべてですか?
  • 計画された有効期間 – 利用可能時間はどのくらいですか? 6 か月未満ですか? 2 年を超えますか?
  • 現在の ID プロバイダー - このアプリの主要な IdP は何ですか? AD FS、Active Directory、または Ping Federate ですか?
  • セキュリティ要件 - アプリケーションにアクセスするには、アプリケーションに MFA が必要ですか、またはユーザーが企業ネットワーク上にある必要がありますか?
  • 認証方法 – アプリはオープン標準を使用して認証されますか?
  • アプリ コードの更新を計画しているかどうか - アプリは計画されている、またはアクティブな開発中ですか?
  • アプリをオンプレミスに保持する予定があるかどうか - アプリをデータセンターに長期間保持しますか?
  • アプリが他のアプリまたは API に依存しているかどうか – 現在、アプリから他のアプリまたは API を呼び出していますか?
  • アプリが Microsoft Entra ギャラリーにあるかどうか - 現在、アプリは既に Microsoft Entra ギャラリーに統合されていますか?

次のようなその他のデータは、移行に関する決定を行ううえで現時点では不要ですが、後で役に立ちます。

  • アプリの URL – ユーザーはアプリにアクセスするためにどこに移動しますか?
  • アプリケーション ロゴ: Microsoft Entra アプリ ギャラリーにないアプリケーションを Microsoft Entra ID に移行する場合は、わかりやすいロゴを指定することをお勧めします
  • アプリの説明 – アプリの機能についての簡単な説明は何ですか?
  • アプリの所有者 – 社内のアプリの主要な POC は誰ですか?
  • 一般的なコメントまたは注意事項 – アプリまたはビジネスの所有権に関するその他の一般的な情報

アプリケーションを分類し、詳細を文書化したら、必ず、計画された移行戦略に対するビジネス所有者の同意を得てください。

アプリケーション ユーザー

Microsoft Entra ID がサポートしているアプリとリソースのユーザーには、次の 2 つの主なカテゴリがあります。

  • 内部: ID プロバイダー内にアカウントを持つ従業員、請負業者、およびベンダー。 このカテゴリには、マネージャーまたはリーダーと他の従業員では規則が異なるピボットがさらに必要になる可能性があります。

  • 外部:Microsoft Entra B2B コラボレーションを使って通常の業務で組織とやりとりするベンダー、供給元、販売代理店、またはその他のビジネス パートナー。

これらのユーザーのグループを定義し、さまざまな方法でこれらのグループを設定することができます。 管理者が手動でメンバーをグループに追加しなければならないようにすることも、セルフサービス動的メンバーシップ グループを有効にすることもできます。 動的メンバーシップ グループを使用して、指定された基準に基づきメンバーをグループに自動的に追加するルールを確立できます。

外部ユーザーが顧客を参照する場合もあります。 Azure AD B2C という別の製品でカスタマー認証がサポートされています。 しかし、本書ではこれについて説明しません。

パイロットを計画する

パイロット用に選択したアプリでは、組織の主要な ID とセキュリティ要件を表す必要があります。また、アプリケーションの所有者からの明確な同意が必要です。 パイロットは通常、別個のテスト環境で実行されます。

外部のパートナーを忘れないでください。 彼らが移行スケジュールとテストに参加していることをご確認ください。 最後に、問題が発生した場合に、ヘルプ デスクにアクセスする方法があることを確認します。

制限事項について計画する

一部のアプリの移行は簡単ですが、サーバーまたはインスタンスが複数あることが原因で、時間がかかる可能性があるものもあります。 たとえば、カスタム サインイン ページが原因で SharePoint の移行には時間がかかることがあります。

多くの SaaS アプリ ベンダーは、アプリケーションを再構成するためのセルフサービスの手段を提供せず、SSO 接続の変更料を請求します。 彼らに確認し、制限について計画してください。

アプリ所有者の承認

ビジネス クリティカルで一般的に使用されるアプリケーションでは、パイロット段階でアプリをテストするためにパイロット ユーザーのグループが必要になる場合があります。 運用前の環境またはパイロット環境でアプリをテストしたら、そのアプリを移行する前にアプリ ビジネスの所有者がパフォーマンスについて承認をしていることを確認してください。 また、すべてのユーザーが認証に Microsoft Entra ID を運用環境で使用するように移行することも確認する必要があります。

セキュリティ体制を計画する

移行プロセスを開始する前に、企業の ID システム用に開発するセキュリティ体制を十分に検討してください。 このアスペクトは、重要な情報であるデータにアクセスしている ID、デバイス、場所を収集することに基づいています。

ID とデータ

ほとんどの組織には、業界や組織内の職務によって異なる ID とデータ保護に関する特定の要件があります。 推奨事項については、「ID とデバイスのアクセス構成」を参照してください。 推奨事項には、条件付きアクセス ポリシーと関連する機能の所定のセットが含まれます。

この情報を使って、Microsoft Entra ID に統合されているすべてのサービスへのアクセスを保護できます。 これらの推奨事項は、Microsoft セキュア スコアと Microsoft Entra ID の ID スコアに準拠しています。 このスコアは、次のために役立ちます。

  • ID セキュリティ体制を客観的に測定する
  • ID セキュリティの強化を計画する
  • 強化の成功を確認する

Microsoft セキュア スコアは、ID インフラストラクチャをセキュリティで保護するための 5 つのステップを実装するのにも役立ちます。 組織の出発点としてガイダンスを使用し、組織固有の要件を満たすようにポリシーを調整します。

データへのアクセスに使用されるデバイスまたは場所

ユーザーがアプリへのアクセスに使用するデバイスと場所も重要です。 企業ネットワークに物理的に接続されているデバイスのほうが安全です。 ネットワークの外部からの VPN 経由の接続には、調査が必要になる場合があります。

ユーザーの場所とデータ アクセスの関係を示す図。

リソース、ユーザー、デバイスのこれらの側面を考慮して、Microsoft Entra 条件付きアクセス機能を使うことを選択できます。 条件付きアクセスがユーザーのアクセス許可を超えています。 次のような要因の組み合わせによって異なります。

  • ユーザーまたはグループの ID
  • ユーザーが接続されているネットワーク
  • ユーザーが使用しているデバイスとアプリケーション
  • ユーザーがアクセスしようとしているデータの種類。

ユーザーに付与されたアクセス権は、このより広範な条件セットに適応します。

終了基準

次のような場合、このフェーズは成功です。

  • 移行する予定のアプリを完全に文書化した

  • ビジネス上の重要度、使用量、および有効期間に基づいて、アプリに優先度を付けた

  • パイロットの要件を表すアプリを選択した

  • 優先度付けと戦略について、ビジネス所有者の同意を得ている

  • セキュリティ体制のニーズとその実装方法を理解している

次のステップ