Azure 中雲端規模分析的驗證
驗證是驗證使用者或應用程式身分識別的程式。 慣用單一來源識別提供者，可處理身分識別管理和驗證。 此提供者稱為目錄服務。 它提供儲存目錄數據的方法，並讓此數據可供網路使用者和系統管理員使用。
任何 Data Lake 解決方案都應該使用並整合已在使用的目錄服務。 對大多數組織而言，Active Directory 是所有身分識別相關服務的目錄服務。 它是所有服務和用戶帳戶的主要和集中式資料庫。
在雲端中，Microsoft Entra ID 是集中式識別提供者，也是身分識別管理的慣用來源。 將驗證和授權委派給Microsoft Entra ID 可讓條件式存取原則等案例要求用戶位於特定位置。 它支援多重要素驗證，以提高存取安全性層級。 盡可能使用 Microsoft Entra 整合來設定 Data Lake 資料存放區服務。
對於不支援Microsoft Entra ID 的數據服務，請使用存取密鑰或令牌進行驗證。 客戶端應該將存取金鑰儲存在金鑰管理存放區中，例如 Azure 金鑰保存庫。
雲端規模分析的驗證案例如下：
- 使用者驗證
- 應用程式和服務對服務驗證
使用者驗證
連接到數據服務或資源的用戶必須出示認證。 此認證會證明用戶是他們宣告的使用者。 然後他們可以存取服務或資源。 驗證也可讓服務知道使用者的身分識別。 服務會決定使用者在驗證身分識別之後可以看到和執行的動作。
Azure Data Lake Storage Gen2、Azure SQL 資料庫 和 Azure Synapse 支援Microsoft Entra 整合。 互動式用戶驗證模式需要使用者在對話框中提供認證。
重要
請勿將使用者認證硬式編碼至應用程式進行驗證。
應用程式和服務對服務驗證
這些要求不會與特定使用者相關聯，或沒有用戶可輸入認證。
服務對服務驗證
即使服務在沒有人為互動的情況下存取另一個服務，服務也必須出示有效的身分識別。 此身分識別證明服務是真實的。 存取的服務可以使用身分識別來決定服務可以執行的動作。
針對服務對服務驗證，驗證 Azure 服務的慣用方法是受控識別。 Azure 資源的受控識別允許向任何支援Microsoft Entra 驗證的服務進行驗證，而不需要任何明確認證。 如需詳細資訊，請參閱什麼是 Azure 資源受控識別。
受控識別是服務主體，只能與 Azure 資源搭配使用。 例如，您可以直接為 Azure Data Factory 實例建立受控識別。 此受控識別是註冊至 entra 標識碼Microsoft的物件。 它代表這個Data Factory實例。 此身分識別接著可用來向 Data Lake Storage 等任何服務進行驗證，而不需要程式代碼中的任何認證。 Azure 會負責服務實例所使用的認證。 身分識別可以將授權授與 Azure 服務資源，例如 Azure Data Lake Storage 中的資料夾。 當您刪除此 Data Factory 實例時，Azure 會清除 Microsoft Entra 識別碼中的身分識別。
使用受控識別的優點
受控識別應該用來向另一個 Azure 服務或資源驗證 Azure 服務。 它們提供下列優點：
- 受控識別代表其建立的服務。 它不代表互動式使用者。
- 受控識別認證會維護、管理和儲存在 entra 識別符Microsoft。 用戶沒有要保留的密碼。
- 使用受控識別時，客戶端服務不會使用密碼。
- 刪除服務實例時，系統會刪除系統指派的受控識別。
這些優點表示認證受到更好的保護，且安全性危害的可能性較低。
應用程式對服務驗證
另一個存取案例是應用程式，例如行動Web應用程式，存取 Azure 服務。 無論誰存取 Azure 服務，存取子都必須提供其身分識別，而且必須驗證該身分識別。
Azure 服務主體是不支援受控識別向 Azure 資源進行驗證的應用程式和服務替代方案。 Azure 服務主體是一種身分識別，建立目的是為了搭配應用程式、託管服務及自動化工具來存取 Azure 資源。 此存取受限於指派給服務主體的角色。 基於安全性考慮，我們建議使用服務主體搭配自動化工具或應用程式，而不是允許他們以使用者身分識別登入。 如需詳細資訊，請參閱 Microsoft Entra ID 中的應用程式和服務主體物件。
注意
受控識別和服務主體只會在 entra 標識碼Microsoft建立和維護。
受控識別和服務主體之間的差異
| 服務主體 | 受控識別 |
|---|---|
| Microsoft Entra ID 中手動建立的安全性身分識別，以供應用程式、服務和工具來存取特定 Azure 資源。 | 特殊類型的服務主體。 這是建立 Azure 服務時所建立的自動身分識別。 |
| 任何應用程式或服務都可以使用。 它不會繫結至特定的 Azure 服務。 | 表示 Azure 服務實例本身。 它無法用來代表其他 Azure 服務。 |
| 具有獨立的生命週期。 您必須明確刪除它。 | 刪除 Azure 服務實例時，會自動刪除。 |
| 密碼型或憑證型驗證。 | 未提供用於驗證的明確密碼。 |
資料庫驗證和許可權
雲端規模分析可能包含 polyglot 記憶體。 範例包括 PostgreSQL、MySQL、Azure SQL 資料庫、SQL 受管理執行個體 和 Azure Synapse Analytics。
- 使用 Microsoft Entra ID 向 PostgreSQL 進行驗證 (部分機器翻譯)
- 搭配 Azure SQL 資料庫、SQL 受管理執行個體 和 Azure Synapse Analytics 使用 Microsoft Entra 驗證
- 使用 Microsoft Entra 識別碼向 MySQL 進行驗證
建議您使用 Microsoft Entra 群組來保護資料庫物件，而不是個別Microsoft Entra 用戶帳戶。 使用這些Microsoft Entra 群組來驗證用戶並保護資料庫物件。 與 Data Lake 模式類似，您可以使用資料應用程式上線來建立這些群組。
注意
數據應用程式可以將敏感數據產品儲存在 Azure SQL 資料庫、SQL 受管理執行個體 或 Azure Synapse Analytics 集區中。 如需詳細資訊，請參閱 Azure 中雲端規模分析的數據隱私權。
雲端規模分析中的 Azure Data Lake 安全性
若要控制數據湖中的數據存取，建議您在檔案和資料夾層級使用訪問控制清單 （ACL）。 Azure Data Lake 也採用類似 POSIX 的訪問控制清單模型。 POSIX （可攜式作業系統介面）是操作系統的一系列標準。 一個標準會定義簡單但功能強大的許可權結構，以存取檔案和資料夾。 POSIX 已廣泛採用網路檔案共用和 Unix 電腦。
與 Azure RBAC 一般作法類似，下列規則應適用於 ACL：
使用群組管理存取權。 將存取權指派給 Microsoft Entra 群組，並管理群組的成員資格以進行進行中的存取管理。 請參閱 Azure Data Lake Storage 中的訪問控制和數據湖組態。
最低權限。 在大部分情況下，用戶應該只有數據湖中所需的資料夾和檔案的讀取許可權。 受控識別或服務主體，例如 Azure Data Factory 所使用的受控識別或服務主體，具有讀取、寫入和執行許可權。 數據使用者不應該具有記憶體帳戶容器的存取權。
與數據分割配置對齊。 ACL 和數據分割設計必須一致，以確保有效的數據訪問控制。 如需詳細資訊，請參閱 Data Lake 數據分割。