案例 2 解決方案 - 任務關鍵性應用程式
在上一個單元中，您已完成涉及 911 調度系統高可用性的案例。 在本單元中，您將檢閱一個可能的解決方案，以及一些要考慮的其他項目。
在檢閱時，建議將所提供解決方案與上一個單元中開發的解決方案進行比較。 任何問題通常都存在不止一個正確的解決方案，但一律會有取捨。 解決方案中有哪些項目與提議的不同？ 解決方案中是否有任何您可能會重新思考的項目？ 所提供解決方案中是否有任何您認為能夠在解決方案中更徹底地解決的項目？
部署選項和設定
處理案例的第一個選擇通常是識別哪一個 Azure SQL 部署選項可能是最合適選項。 若只考慮服務等級協定 (SLA)，則其需求是達 99.995% 的 SLA，而只有 Azure SQL Database 能夠提供這項功能。 若要取得此 SLA，即必須部署業務關鍵服務層級，並啟用使用可用性區域。
另一組決策與如何啟用異地備援，並在災害中維持高可用性有關。 雖然異地複寫和自動容錯移轉群組都是選項，但自動容錯移轉群組可讓客戶在需要時進行容錯移轉，而無需變更任何連接字串。 由於不需要更新應用程式的連接字串，因此這項設定可能有助於減低停機時間。 您也可以設定監視查詢來檢查狀態。 如此一來，萬一發生問題，您甚至可強制進行容錯移轉。
在此設定中，還必須考慮共置扮演的角色。 為了維持高可用性，應用程式必須盡可能接近資料庫，當然一定會在相同的區域中。 您想要確定應用程式部署在自動容錯移轉群組的兩個區域中，因此存在應用程式 (例如 Web 應用程式) 的備援複本。 如果發生容錯移轉，可使用 Azure 流量管理員來將流量重新路由傳送至次要地區中的應用程式。
DBA 和敏感性資料
911 調度系統協調員在允許 DBA 執行作業的同時，也會對保護敏感性資料 (例如健康史和其他個人資訊) 表示關注。
為了確保 DBA 無法看到儲存在特定資料行中的敏感性資料，並確保所有對包含敏感性資料資料表的存取都受到監視，您可使用幾項 Azure SQL 技術。 使用 SQL 稽核是監視存取的最佳做法，但 DBA 仍然可看到該資料。 使用資料分類來分類敏感性資料將有所幫助，因為敏感性資料會加上標籤，且您可使用 SQL 稽核加以追蹤。 不過，在實作這些功能後，DBA 仍然可看到敏感性資料。 您可使用動態資料遮罩來協助遮罩敏感性資料，但無法僅透過權限來阻止 db_owner 檢視使用者資料。
如果資料庫中有高度敏感性資料，您可使用 Always Encrypted 安全地避免 db_owners 看到該資料。 您可使用角色隔離來管理 Always Encrypted 金鑰，如此一來，安全性系統管理員就不會存取資料庫，DBA 也不會以純文字來存取實體金鑰。 透過將此策略與利用 SQL 稽核的監視結合使用，您即可監視、遮罩敏感性資料並追蹤對該資料的存取，即使是擁有 db_owner 權限的 DBA 也是如此。
DBA 需要對敏感性資料進行遮罩，但其仍然能夠使用 Azure 入口網站和 SQL Server Management Studio 或 Azure Data Studio 來針對效能進行疑難排解。 其也需要能夠建立新自主資料庫使用者，這些使用者必須對應至 Microsoft Entra 主體。
其中一個解決方案是針對每個執行個體上的 DBA 建立稱為 SQL DBA 的 Microsoft Entra 群組。 然後，將群組指派給 SQL Server 參與者的 Azure 角色型存取控制 (RBAC) 角色。 最後，您可以將群組設為邏輯伺服器上的 Microsoft Entra 系統管理員。