移轉應用程式驗證至 Azure Active Directory

關於本白皮書

本白皮書將詳細說明將應用程式驗證遷移至 Azure AD 的規劃和優點。 這是專為 Azure 管理員和身分識別專業人員所設計。

該程序分成四個階段,每個階段都有詳細的規劃和允出準則,其設計目的是協助您規劃移轉策略,並了解 Azure AD 驗證如何支援您的組織目標。

簡介

現今,您的組織需要許多應用程式 (app) 來讓使用者完成工作。 每天都有可能繼續新增、開發或淘汰應用程式。 使用者從各式各樣的公司裝置、個人裝置及不同位置存取這些應用程式。 他們以許多方式開啟應用程式,包括:

  • 透過公司首頁或入口網站

  • 藉由在瀏覽器上加上書籤

  • 透過軟體即服務 (SaaS) 應用程式的廠商 URL

  • 透過行動裝置/應用程式管理 (MDM/MAM) 解決方案直接推送到使用者桌上型電腦或行動裝置的連結

您的應用程式可能會使用下列驗證類型:

  • 內部部署同盟解決方案 (例如 Active Directory 同盟服務 (ADFS) 和 Ping)

  • Active Directory (例如 Kerberos 驗證和 Windows 整合式驗證)

  • 其他雲端式身分識別和存取管理 (IAM) 解決方案 (例如 Okta 或 Oracle)

  • 內部部署 Web 基礎結構 (例如 IIS 和 Apache)

  • 雲端託管的基礎結構 (例如 Azure 和 AWS)

為了確保使用者可以輕鬆且安全地存取應用程式,您的目標是有一組可跨內部部署和雲端環境使用的存取控制和原則。

Azure Active Directory (Azure AD) 提供通用身分識別平台,可讓您的員工、合作夥伴和客戶取得單一身分識別來存取他們所需的應用程式,並且可以從任何平台和裝置共同作業。

A diagram of Azure Active Directory connectivity

Azure AD 有一套完整的身分識別管理功能。 在 Azure AD 中將您的應用程式驗證和授權標準化,可讓您享有這些功能所提供的優點。

您可以在這裡找到更多的移轉資源:https://aka.ms/migrateapps

將應用程式驗證遷移至 Azure AD 的優點

將應用程式驗證移至 Azure AD 可協助您管理風險和成本、提高生產力,以及滿足合規性和治理需求。

管理風險

若要保護應用程式,您必須擁有所有風險因子的完整觀點。 將您的應用程式遷移至 Azure AD 會整合您的安全性解決方案。 這麼做之後,您就可以:

管理成本

您的組織可能會有多個身分識別存取管理 (IAM) 解決方案。 遷移至一個 Azure AD 基礎結構,可讓您降低對 IAM 授權 (內部部署或雲端) 的依賴性和基礎結構成本。 如果您已透過 Microsoft 365 授權支付 Azure AD 的費用,就沒有理由支付另一個 IAM 解決方案的額外成本。

有了 Azure AD,您可以透過下列方式降低基礎結構成本:

提高生產力

經濟效益和安全性優點可促使組織採用 Azure AD,但如果使用者也受益,則更有可能達到完全採用和一致性。 透過 Azure AD,您可以:

滿足合規性與治理要求

使用整合式稽核工具和 API 強制執行公司存取原則,以及監視使用者對應用程式和相關資料的存取,來確保符合法規要求。 在 Azure AD 中,您可以透過能運用安全性事件與事件監視 (SIEM) 工具的報告,來監視應用程式登入。 您可以從入口網站或 API 存取報表,並以程式設計方式稽核誰可以存取您的應用程式,以及透過存取權檢閱來移除非使用中使用者的存取權。

規劃您的移轉階段和專案策略

技術專案如果失敗,通常是因為預期結果不相符、正確的專案關係人未參與,或是缺乏溝通。 規劃專案本身才能確保獲得成功。

移轉階段

在開始使用工具之前,您應該先了解如何思考移轉程序。 經過數個「直接面對客戶」研討會之後,我們建議您規劃下列四個階段:

A diagram of the phases of migration

召集專案小組

應用程式移轉是小組工作,您必須確保所有重要位置都已填滿。 資深業務領導人的支援非常重要。 請確保您有一組適當的執行贊助者、企業決策者和主題專家 (SME)。

在移轉專案進行期間,一個人可能有多個角色,或每個角色有多個人員,這取決於您組織的大小和結構。 您可能也會相依於在您安全性環境中扮演重要角色的其他小組。

下表包含重要角色和其貢獻:

角色 參與
專案經理 負責指導專案的專案導師,包括:
- 取得執行支援
- 帶入專案關係人
- 管理排程、文件和溝通
身分識別架構師/Azure AD 應用程式管理員 他們的負責項目如下:
- 與專案關係人合作設計解決方案
- 記錄解決方案設計和作業程序以交付給營運團隊
- 管理實際執行之前和實際執行時的環境
內部部署 AD 作業小組 管理不同內部部署身分識別來源 (例如 AD 樹系、LDAP 目錄、HR 系統等) 的組織。
- 在同步之前,執行任何所需的補救工作
- 提供同步所需的服務帳戶
- 提供將同盟設定為 Azure AD 的存取權
IT 支援管理員 IT 支援組織所推派的代表人員,可從技術服務人員的觀點就是否能支援這項變更來提出看法。
安全性負責人 安全性團隊所推派的代表人員,可確保計畫符合組織的安全性需求。
應用程式技術負責人 包含應用程式和服務 (將與 Azure AD 整合) 的技術負責人。 他們會提供應包含在同步程序中的應用程式身分識別屬性。 他們通常與 CSV 代表有關聯性。
應用程式業務負責人 業務代表同事,可提供使用者體驗的輸入資訊,並從使用者的觀點來提供這項變更的實用資訊,負責應用程式的整體業務層面,其中可能包括管理存取權。
試驗使用者群組 將在日常工作中進行測試的使用者 (試用體驗),並提供意見反應來指引其餘的部署。

規劃溝通

有效的業務參與和溝通是成功的關鍵。 請務必為專案關係人和終端使用者提供取得資訊的途徑,並讓他們持續收到排程的更新通知。 教育所有人了解移轉的價值、預期的時程表為何,以及如何規劃任何暫時性的業務中斷。 使用多個途徑,例如簡報研討會、電子郵件、一對一會議、橫幅及全員大會。

根據您為應用程式選擇的溝通策略,您可以提醒使用者有暫時的停機時間。 同時,您應該確認最近沒有必須延遲部署的任何變更或業務影響。

下表是讓您的專案關係人掌握最新資訊的最基本建議溝通:

規劃階段和專案策略

溝通 適用對象
專案的認知和商務/技術價值 終端使用者以外的所有人
試驗應用程式的徵集 - 應用程式業務負責人
- 應用程式技術負責人
- 架構師和身分識別小組

第 1 階段 - 探索和範圍

溝通 適用對象
- 應用程式資訊的徵集
- 範圍界定執行的結果
- 應用程式技術負責人
- 應用程式業務負責人

第 2 階段 - 將應用程式分類和規劃試驗

溝通 適用對象
- 分類結果及對移轉排程的意義
- 初步移轉排程
- 應用程式技術負責人
- 應用程式業務負責人

第 3 階段 – 規劃移轉和測試

溝通 適用對象
- 應用程式移轉測試的結果 - 應用程式技術負責人
- 應用程式業務負責人
- 即將進行移轉的通知,以及終端使用者體驗結果的說明。
- 即將停機和完成溝通,包括他們現在應該做什麼、意見反應,以及如何取得協助
- 終端使用者 (及其他所有人)

第 4 階段 - 管理和取得深入解析

溝通 適用對象
可用的分析及如何存取 - 應用程式技術負責人
- 應用程式業務負責人

移轉狀態溝通儀表板

傳達移轉專案的整體狀態是很重要的,因為狀態會顯示進度,並可協助其應用程式即將開始移轉的應用程式擁有者做好遷移準備。 您可以使用 Power BI 或其他報告工具來彙集簡單的儀表板,以在移轉期間提供應用程式狀態的可見性。

您可以考慮使用的移轉狀態如下:

移轉狀態 動作計劃
初始要求 尋找應用程式並與擁有者聯繫以取得詳細資訊
評量完成 應用程式擁有者會評估應用程式需求,並傳回應用程式問卷
設定進行中 形成管理 Azure AD 驗證所需的變更
測試設定成功 評估變更並針對測試環境中的測試 Azure AD 租用戶驗證應用程式
實際執行設定成功 變更設定以針對實際執行的 AD 租用戶運作,並評估測試環境中的應用程式驗證
完成/認可 將應用程式的變更部署至實際執行環境,並對實際執行的 Azure AD 租用戶執行

這可確保應用程式擁有者在應用程式即將移轉時,知道應用程式移轉的內容和測試排程,以及從其他已遷移的應用程式中知道結果。 您也可以考慮提供 Bug 追蹤器資料庫的連結,讓擁有者能夠針對正在遷移的應用程式提出問題及檢視問題。

最佳作法

以下是我們的客戶和合作夥伴的成功案例,以及建議的最佳做法:

第 1 階段:探索應用程式並界定範圍

應用程式探索和分析是提供您良好起點的基本演練。 您無法事事皆知,因此必須做好接受未知應用程式的準備。

尋找您的應用程式

應用程式移轉中的第一個決策點是要遷移哪些應用程式 (如果有的話),以及要淘汰哪些應用程式。 您永遠有機會淘汰組織中不使用的應用程式。 您可以透過數種方式來尋找組織中的應用程式。 探索應用程式時,務必將開發中和已規劃的應用程式包含在內。 在所有未來的應用程式中使用 Azure AD 進行驗證。

使用 Active Directory 同盟服務 (AD FS) 收集正確的應用程式詳細目錄:

  • 使用 Azure AD Connect Health。 如果您有 Azure AD Premium 的授權,建議您部署 Azure AD Connect Health,以分析內部部署環境中的應用程式使用情況。 您可以使用 ADFS 應用程式報表 (預覽) 來探索可遷移的 ADFS 應用程式,並評估要遷移的應用程式是否就緒。 完成您的移轉之後,請部署 Cloud Discovery,讓您可以在雲端中持續監視組織內的影子 IT。

  • AD FS 記錄剖析。 如果您沒有 Azure AD Premium 授權,建議您使用以 PowerShell 為基礎的 ADFS 到 Azure AD 應用程式移轉工具。 請參閱解決方案指南

從 Active Directory 同盟服務 (AD FS) 將應用程式遷移到 Azure AD。

使用其他識別提供者 (IdP)

針對其他識別提供者 (例如 Okta 或 Ping),您可以使用其工具來匯出應用程式詳細目錄。 您可以考慮查看 Active Directory 上註冊的服務主體,這些服務主體與您組織中的 Web 應用程式相對應。

使用 Cloud Discovery 工具

在雲端環境中,您需要豐富的可見度、控制資料移動,以及精密的分析,才能在所有雲端服務中找出並對抗網路威脅。 您可以使用下列工具來收集您的雲端應用程式詳細目錄:

  • 雲端存取安全性代理程式 (CASB) – CASB 通常會與您的防火牆一起運作,以提供員工雲端應用程式使用情況的可見度,並協助您保護公司資料免於網路安全性的威脅。 CASB 報告可協助您判斷組織中最常使用的應用程式,以及遷移至 Azure AD 的早期目標。

  • Cloud Discovery - 藉由設定 Cloud Discovery,您可以看到雲端應用程式的使用情況,並且可以探索待批准或影子 IT 應用程式。

  • API - 針對連線到雲端基礎結構的應用程式,您可以使用這些系統上的 API 和工具來開始清查託管的應用程式。 在 Azure 環境中:

    • 使用 Get-AzureWebsite Cmdlet 來取得 Azure 網站的相關資訊。

    • 使用 Get-AzureRMWebApp Cmdlet 取得 Azure Web Apps 的相關資訊。 D

    • 您可以使用 AppCmd.exe,從 Windows 命令列尋找在 Microsoft IIS 上執行的所有應用程式。

    • 使用應用程式服務主體在 Azure AD 中取得目錄中的應用程式和應用程式執行個體相關資訊。

使用手動程序

在您採用上述的自動化方法之後,您就能夠更好地掌控應用程式。 不過,您可能會考慮進行下列動作,以確保包含所有使用者存取區域:

  • 請與組織中的各個業務負責人聯繫,以找出組織中正在使用的應用程式。

  • 在您的 Proxy 伺服器上執行 HTTP 檢查工具,或分析 Proxy 記錄,以查看流量通常路由的位置。

  • 從熱門公司入口網站檢閱網路日誌,查看使用者最常存取的連結。

  • 與主管或其他重要業務成員接洽,確保您已涵蓋商務關鍵應用程式。

要遷移的應用程式類型

找到您的應用程式之後,您將會在組織中識別這些類型的應用程式:

  • 已使用新式驗證通訊協定的應用程式

  • 使用您選擇將其傳統驗證通訊協定現代化的應用程式

  • 使用您選擇不將其傳統驗證通訊協定現代化的應用程式

  • 新的企業營運 (LoB) 應用程式

已使用新式驗證的應用程式

已現代化的應用程式最有可能移至 Azure AD。 這些應用程式已使用新式驗證通訊協定 (例如 SAML 或 OpenID Connect),且可以重新設定為使用 Azure AD 進行驗證。

除了 Azure AD 應用程式庫中的選擇,這些可能是已存在於您組織中的應用程式,或是來自非 Azure AD 資源庫廠商的任何第三方應用程式 (非資源庫應用程式)。

您選擇將其現代化的舊版應用程式

針對您想要現代化的舊版應用程式,請移至 Azure AD 進行核心驗證和授權,即可解鎖 Microsoft GraphIntelligent Security Graph 必須提供的所有功能和資料豐富性。

建議您更新這些應用程式的驗證堆疊程式碼,以從舊版通訊協定 (例如 Windows 整合式驗證、Kerberos 限制委派、HTTP 標頭式驗證) 更新到新式通訊協定 (如 SAML 或 OpenID Connect)。

您選擇不要將其現代化的舊版應用程式

有時候因為一些商業原因,對於某些使用舊版驗證通訊協定的應用程式而言,現代化其驗證並不是正確做法。 其中包括下列類型的應用程式:

  • 基於合規性或控制原因而保留在內部部署環境中的應用程式。

  • 連線至內部部署身分識別的應用程式,或是您不想要變更的同盟提供者。

  • 使用您不打算移動的內部部署驗證標準所開發的應用程式

Azure AD 可以為這些舊版應用程式帶來絕佳的優點,因為您可以對這些應用程式啟用新式 Azure AD 安全性和治理功能,例如多重要素驗證條件式存取身分識別保護委派的應用程式存取存取權檢閱,而且完全無須觸及應用程式!

首先,使用簡單的驗證方法 (例如密碼保存庫),透過 Azure AD 應用程式 Proxy這些應用程式延伸至雲端,來讓您的使用者快速遷移,或透過我們的合作夥伴整合,以及您可能已部署的應用程式傳遞控制器。

新的企業營運 (LoB) 應用程式

您通常會開發在組織內部使用的 LoB 應用程式。 如果您的管線中有新的應用程式,我們建議使用 Microsoft 身分識別平台來實作 OpenID Connect。

要淘汰的應用程式

沒有明確擁有者和明確維護和監視方式的應用程式,會讓您的組織存在安全性風險。 如有以下情況,請考慮淘汰應用程式:

  • 功能性與其他系統高度重複 • 沒有任何業務負責人

  • 顯然已不再使用

建議您不要淘汰影響度高的業務關鍵性應用程式。 在這些情況下,請與業務負責人合作,以判斷正確的策略。

允出準則

若要成功完成此階段,您必須具備下列條件:

  • 充分了解您移轉範圍內的系統 (您可以在移至 Azure AD 之後淘汰的系統)

  • 包含下列各項的應用程式清單:

    • 這些應用程式所連線的系統
    • 使用者從何處及在哪些裝置上存取這些應用程式
    • 是否要將其遷移、淘汰或與 Azure AD Connect 連線。

注意

您可以下載應用程式探索工作表,以記錄您要遷移至 Azure AD 驗證的應用程式,以及您想要保留但使用 Azure AD Connect 進行管理的應用程式。

第 2 階段:將應用程式分類和規劃試驗

將應用程式移轉分類是很重要的練習。 並非每個應用程式都需要同時移轉和轉換。 收集每個應用程式的相關資訊之後,您就可以合理知道應先遷移哪些應用程式,而哪些應用程式可能會花費較長的時間。

分類範圍內的應用程式

您可以根據業務關鍵性、使用量和存留期的軸線來思考此做法,這每一個項目都取決於多個因素。

業務關鍵性

業務關鍵性會針對每個業務採用不同的維度,但您應該考量的兩個量值是特性和功能使用者設定檔。 對具有獨特功能的應用程式指派較高的點值,其值應比重複或過時功能的值高。

A diagram of the spectrums of Features & Functionality and User Profiles

使用方式

使用量較高的應用程式應比使用量低的應用程式獲得更高的值。 對具有外部、主管或安全性小組使用者的應用程式指派較高的值。 針對您移轉組合中的每個應用程式,完成這些評量。

A diagram of the spectrums of User Volume and User Breadth

決定業務關鍵性和使用量的值之後,您就可以決定 應用程式存留期,並建立優先順序的矩陣。 請參閱下方的此類矩陣:

A triangle diagram showing the relationships between Usage, Expected Lifespan, and Business Criticality

排定應用程式移轉的優先順序

您可以根據組織的需求,選擇以優先順序最低的應用程式或優先順序最高的應用程式來開始遷移應用程式。

如果您沒有使用過 Azure AD 和識別服務的經驗,請考慮先將優先順序最低的應用程式移至 Azure AD。 這會將您的業務衝擊降到最低,並且可以藉此產生動力。 成功移動這些應用程式並獲得專案關係人的信賴之後,您就可以繼續遷移其他應用程式。

如果沒有明確的優先順序,您應考慮先移動位在 Azure AD 資源庫中且支援多個識別提供者 (ADFS 或 Okta) 的應用程式,因為這些應用程式比較容易整合。 這些應用程式很可能是您組織中優先順序最高的應用程式。 為了協助您整合 SaaS 應用程式與 Azure AD,我們開發了一系列教學課程,可逐步引導您進行設定。

如果您必須在期限前遷移應用程式,這些優先順序最高的應用程式貯體將會是主要的工作負載。 您可以最後再選取優先順序較低的應用程式,因為即使您已變更期限,這些應用程式也不會改變成本。 即使您必須更新授權,這也只是很小的部分。

除了此分類和取決於移轉的急迫性外,您也可以考慮使用移轉排程,讓應用程式擁有者必須加入該排程,才能遷移其應用程式。 此程序結束時,在排定優先順序以用於移轉的貯體中,應該會有所有應用程式的清單。

記錄您的應用程式

首先,請先收集您應用程式的重要詳細資料。 應用程式探索工作表將協助您快速制定您的移轉決策,並立即對業務小組提出建議。

制定移轉決策的重要資訊包括:

  • 應用程式名稱 – 公司如何稱呼此應用程式?

  • 應用程式類型 – 是否第三方 SaaS 應用程式? 自訂的企業營運 Web 應用程式? API?

  • 業務關鍵性 – 其關鍵性高嗎? 還是偏低? 或介於兩者之間?

  • 使用者存取量 – 每個人都會存取此應用程式,還是僅限一些人?

  • 規劃的存留期 – 此應用程式會存在多久? 少於六個月? 超過兩年?

  • 目前的識別提供者 – 此應用程式的主要 IdP 為何? 或是其依賴本機儲存體?

  • 驗證方法 – 應用程式是否使用開放式標準進行驗證?

  • 您是否打算更新應用程式程式碼 – 應用程式處於已規劃或開發中狀態?

  • 您是否計劃將應用程式保留在內部部署環境 – 您是否想要將應用程式'長期保留在資料中心內?

  • 應用程式是否相依於其他應用程式或 API –應用程式目前是否會呼叫其他應用程式或 API?

  • 應用程式是否位於 Azure AD 資源庫 – 應用程式目前是否已與 Azure AD 資源庫整合?

之後對您有幫助,但您不需要立即制定移轉決策的其他資料包括:

  • 應用程式 URL使用者前往哪裡存取應用程式?

  • 應用程式描述 – 應用程式用途的簡短描述為何?

  • 應用程式擁有者 – 在公司中,應用程式的主要 POC 是誰?

  • 一般註解或附註 – 任何其他關於應用程式或業務擁有權的一般資訊

當您將應用程式分類並記錄詳細資料之後,請務必讓業務負責人接受您規劃的移轉策略。

規劃試驗

您為試驗選取的應用程式應代表您組織的重要身分識別和安全性需求,而且您必須讓應用程式擁有者明確地接受。 試驗通常會在個別的測試環境中執行。 請參閱 [部署計劃] 頁面上的試驗最佳做法

別忘了您的外部合作夥伴。 務必讓他們參與移轉排程和測試。 最後,確定他們在遇到重大問題時,請有方法可以連絡技術服務人員。

規劃限制

有些應用程式很容易遷移,而有些應用程式可能會因為有多個伺服器或執行個體而需要較長的時間。 例如,SharePoint 因為是自訂登入頁面的關係,移轉可能需要較長的時間。

許多 SaaS 應用程式廠商會收取變更 SSO 連線的費用。 請洽詢這些廠商並進行規劃。

Azure AD 也有您應該注意的服務限制

應用程式擁有者認可

業務關鍵性和普遍使用的應用程式可能需要一組試驗使用者,以在試驗階段中測試應用程式。 在實際執行之前或試驗環境中測試過應用程式之後,請先確定應用程式業務負責人認可該效能,再將應用程式和所有使用者遷移至實際使用 Azure AD 進行驗證的環境。

規劃安全性狀態

在您起始移轉程序之前,請花一些時間徹底考慮您想要為公司身分識別系統開發的安全性狀態。 為此,您需要收集以下重要資訊集:存取您資料的身分識別、裝置和位置。

身分識別與資料

大部分的組織都有特定的身分識別和資料保護需求,這些需求會因產業區塊和組織內的作業功能而有所不同。 請參閱身分識別和裝置存取設定來取得我們的建議,其中包括一組指定的條件式存取原則和相關功能。

針對與 Azure AD 整合的所有服務,您可以使用此資訊來保護其存取權。 這些建議與 Microsoft 安全分數及 Azure AD 中的身分識別分數一致。 此分數可協助您:

  • 客觀地測量身分識別安全性狀態

  • 規劃如何改善身分識別安全性

  • 檢閱改善是否成功

這也可協助您實作保護身分識別基礎結構的五個步驟。 請使用該指引作為您組織的起點,並調整原則以符合您組織的特定需求。

誰正在存取您的資料?

Azure AD 支援的應用程式和資源使用者有兩個主要類別:

  • 內部:在您的識別提供者中具有帳戶的員工、約聘人員和廠商。 對於管理者或領導階層,這可能需要以不同的規則進行進一步調整 (相對於其他員工)。

  • 外部:透過 Azure AD B2B 共同作業與您組織有一般商務互動的廠商、供應商、經銷商或其他商業合作夥伴。

您可以定義這些使用者的群組,並以不同方式將人員加入這些群組。 您可以選擇管理員必須手動將成員新增到群組中,或者您可以啟用 selfservice 群組成員資格。 也可以使用動態群組建立規則,以自動根據指定的準則將成員新增至群組。

外部使用者也可能是客戶。 Azure AD B2C是個別的產品,可支援客戶驗證。 不過,這不在本文的討論範圍內。

用來存取資料的裝置/位置

使用者用來存取應用程式的裝置和位置也很重要。 實際連線到公司網路的裝置比較安全。 從網路外部透過 VPN 建立的連線可能需要仔細檢查。

A diagram showing the relationship between User Location and Data Access

考慮到資源、使用者和裝置這些層面,您可以選擇使用 Azure AD 條件式存取功能。 條件式存取超出使用者權限:其以各種因素的組合為基礎,例如使用者或群組的身分識別、使用者所連線的網路、所使用的裝置和應用程式,以及他們嘗試存取的資料類型。 授與使用者的存取權需根據這一組更廣泛的條件來進行調整。

允出準則

若要成功完成此階段,您必須具備下列條件:

  • 了解您的應用程式

    • 已完整記錄您想要遷移的應用程式
    • 已根據業務關鍵性、使用量和存留期來設定應用程式的優先順序
  • 已選取代表您需求的應用程式來進行試驗

  • 業務負責人接受您的優先順序和策略

  • 了解您的安全性狀態需求以及如何加以實行

第 3 階段:規劃移轉和測試

一旦您獲得業務認可之後,下一個步驟就是開始將這些應用程式遷移至 Azure AD 驗證。

移轉工具與指引

您可以使用以下的工具和指引,遵循將應用程式遷移至 Azure AD 所需的精確步驟:

在移轉之後,您可以選擇傳送通知,告知使用者部署成功,並提醒他們必須採取的任何新步驟。

規劃測試

在移轉的過程中,您的應用程式可能已有在一般部署期間使用的測試環境。 您可以繼續使用此環境進行移轉測試。 如果目前無法使用測試環境,您可以根據應用程式的架構,使用 Azure App Service 或 Azure 虛擬機器設定一個。 您可以選擇設定個別的測試 Azure AD 租用戶,以在開發應用程式組態時使用。 此租用戶會以乾淨的狀態啟動,且不會設定為與任何系統同步。

您可以以測試使用者的身分登入來測試每個應用程式,並確定所有功能與移轉之前相同。 如果您在測試期間判斷使用者需要更新其 MFASSPR 設定,或您在移轉期間新增了此功能,請務必將其新增至您的終端使用者溝通計畫中。 請參閱 MFASSPR 終端使用者溝通範本。

當您遷移應用程式之後,請移至 Azure 入口網站 來測試移轉是否成功。 請遵循下列指示:

  • 選取 [企業應用程式] > [所有應用程式],並從清單中尋找您的應用程式。

  • 選取 [管理] > [使用者和群組],將至少一個使用者或群組指派給應用程式。

  • 選取 [管理] > [條件式存取]。 檢查您的原則清單,並確保您未使用條件式存取原則來封鎖應用程式的存取。

根據您設定應用程式的方式,確認 SSO 是否正常運作。

驗證類型 測試
OAuth / OpenID Connect 選取 [企業應用程式] > [權限],並確定您已在應用程式的使用者設定中,同意在您的組織中使用該應用程式。
以 SAML 為基礎的 SSO 使用 [單一登入] 下的 [測試 SAML 設定] 按鈕。
密碼式 SSO 下載並安裝 MyApps 安全登入延伸模組。 此延伸模組可協助您啟動組織中要求使用 SSO 程序的任何雲端應用程式。

| 應用程式 Proxy | 確定您的連接器正在執行,並已指派給您的應用程式。 請造訪應用程式 Proxy 疑難排解指南,以取得進一步的協助。 |

疑難排解

如果您遇到問題,請參閱我們的應用程式疑難排解指南來取得協助。 您也可以查看我們的疑難排解文章,請參閱登入已設定 SAML 型單一登入的應用程式時遇到問題

規劃復原

如果您的移轉失敗,最佳策略是復原並測試。 您可以採取下列步驟來因應移轉問題:

  • 取得您應用程式現有設定的螢幕擷取畫面。 如果您必須重新設定應用程式,即可回頭查看。

  • 如果雲端驗證發生問題,您也可以考慮提供舊版驗證的連結

  • 在您完成移轉之前,請勿變更先前識別提供者的現有設定

  • 請先遷移支援多個 idP 的應用程式。 如果發生錯誤,您隨時都可以變更為慣用的 IdP 設定。

  • 確定您的應用程式體驗有意見反應按鈕,或指向技術服務人員的指標。

允出準則

若要成功完成此階段,您必須具備下列條件:

  • 已決定每個應用程式的移轉方式

  • 已檢閱移轉工具

  • 已規劃您的測試,包括測試環境和群組

  • 已規劃復原

第 4 階段:規劃管理和深入解析

遷移應用程式之後,您必須確定:

  • 使用者可以安全地存取和管理

  • 您可以取得使用量和應用程式健康情況的正確深入解析

如果可行,建議您對組織採取下列動作。

管理使用者的應用程式存取權

當您遷移應用程式之後,您可以透過許多方式來豐富使用者的體驗

讓應用程式可供探索

將您的使用者指向 MyApps 入口網站體驗。 在這裡,他們可以存取所有雲端式應用程式、使用 Azure AD Connect 提供的應用程式,以及使用應用程式 Proxy 的應用程式,但前提是他們有權存取這些應用程式。

您可以引導使用者如何探索其應用程式:

讓應用程式可供存取

讓使用者從其行動裝置存取應用程式。 使用者可以在其 iOS 7.0 (或更新版本) 或 Android 裝置上,使用 Intune Managed Browser 來存取 MyApps 入口網站。

使用者可以下載 Intune Managed Browser

讓使用者從瀏覽器延伸模組開啟其應用程式。

使用者可以在 ChromeMicrosoft Edge下載 MyApps 安全登入延伸模組,並且可以直接從其瀏覽器列啟動應用程式,以執行下列動作:

讓使用者從 Office.com 開啟其應用程式。

使用者可以移至 Office.com搜尋其應用程式,並讓他們最常使用的應用程式在其工作的位置中顯示

安全的應用程式存取

Azure AD 提供集中式存取位置來管理您已遷移的應用程式。 移至 Azure 入口網站 並啟用下列功能:

  • 保護使用者對應用程式的存取。 啟用條件式存取原則身分識別保護,以根據裝置狀態、位置等來保護使用者對應用程式的存取。

  • 自動佈建。 對使用者需要存取的各種第三方 SaaS 應用程式設定使用者自動佈建。 除了建立使用者身分識別以外,其功能還包括隨著狀態或角色變更,維護和移除使用者身分識別。

  • 委派使用者存取管理。 如果適當,讓自助應用程式能夠存取您的應用程式,並指派業務核准者來核准這些應用程式的存取。 針對指派給應用程式集合的群組,可使用自助群組管理

  • 委派管理員存取權。 使用目錄角色將管理員角色 (例如應用程式系統管理員、雲端應用程式系統管理員或應用程式開發人員) 指派給您的使用者。

稽核您的應用程式並取得深入解析

您也可以使用 Azure 入口網站,從中心位置稽核您所有的應用程式。

  • 使用 [企業應用程式]、[稽核] 來稽核您的應用程式,或從 Azure AD 報告 API 存取相同的資訊,以整合到您最愛的工具。

  • 針對使用 OAuth/OpenID Connect 的應用程式,使用 [企業應用程式]、[權限]來檢視應用程式的權限

  • 使用 [企業應用程式]、[登入] 來取得登入深入解析。從 Azure AD 報告 API 存取相同的資訊。

  • Azure AD Power BI 內容套件中,將應用程式的使用情況視覺化

允出準則

若要成功完成此階段,您必須具備下列條件:

  • 為您的使用者提供安全的應用程式存取

  • 進行管理以稽核已遷移的應用程式並取得深入解析

使用部署計劃執行更多作業

部署計劃會逐步引導您了解 Azure AD 解決方案的商業價值、規劃、實作步驟及管理,並包括應用程式移轉案例。 這些計劃會將您需要的一切整合在一起,以開始部署和取得 Azure AD 功能的價值。 部署指南包含 Microsoft 建議的最佳做法、終端使用者溝通、規劃指南、實作步驟、測試案例等內容。

有許多部署計劃可供您使用,而且我們仍在持續開發更多計劃!

請連絡支援人員

請造訪下列支援連結,以建立或追蹤支援票證和監視健康情況。

身分識別部署問題 (根據您與 Microsoft 建立的 Enterprise 合約)。

  • FastTrack:如果您已購買 Enterprise Mobility and Security (EMS) 或 Azure AD Premium 授權,您就有資格得到 FastTrack 計畫的部署協助。

  • 與產品工程團隊合作:如果您正在進行數百萬名使用者的主要客戶部署,您將有權獲得 Microsoft 客戶團隊或您的雲端解決方案架構師的支援。 根據專案的部署複雜性,您可以直接與 Azure 身分識別產品工程團隊合作。

  • Azure AD 身分識別部落格:訂閱 Azure AD 身分識別部落格,以隨時掌握身分識別工程團隊所提供的所有最新產品公告、深度探討和藍圖資訊。