在 SharePoint Server 中使用微調權限的最佳作法
適用於：
2013 Subscription Edition 
SharePoint in Microsoft 365
微調權限可以影響 SharePoint 伺服器陣列的安全性。 當您使用微調權限時，可能會發生潛在效能問題。 當環境遭遇微調權限使用或範圍錯誤所引起的問題時，下列資訊可協助您處理問題。
您可以執行下列動作來避開微調權限：
儘可能不要中斷權限繼承。
根據資料夾成員資格使用群組來指派權限。
由於 SharePoint Server 搜尋連續編目功能有所變更，現在包含安全性資訊，所以我們不再建議您避免使用 SharePoint 群組來管理動態使用者和群組成員資格。 在 SharePoint Server 之前，在 SharePoint 群組中使用動態成員資格可能會導致在成員資格變更後發生完整編目以前，無法對所有成員正確顯示搜尋結果。 現在透過包含安全性資訊的連續編目功能，將可更快挑選出動態成員資格或其他安全性變更 (預設值為 15 分鐘) 並由搜尋查詢結果修剪所使用。
在可能最高的層級指派權限。 依據此策略，考慮採用下列技巧：
將需要微調權限的文件放入可支援每個權限群組的文件庫中。將文件庫放在個別的網站集合或網站中。
使用不同的文件發行層級來控制存取。 發行文件之前，可以對僅能核准文件庫中項目的使用者設定進階權限和版本設定。
對於非文件庫 (清單)，使用 ReadSecurity 和 WriteSecurity 權限層級。 在建立清單後，擁有者即可將項目層級權限設為「讀取」存取權或「建立及編輯」存取權。
開始之前
在開始進行此作業之前，請先檢閱下列先決條件的相關資訊：
用於避免微調權限常見限制問題的最佳作法
如果您的業務需求必須使用微調權限，請考慮下列建議的最佳作法：
請確定文檔庫中的相同階層層級沒有太多專案，因為處理檢視中專案所需的時間會增加。
使用事件處理常式來控制編輯權限。 您可以讓事件處理常式使用 SPEventReceiverType.ItemUpdating 與 SPEventReceiverType.ItemUpdated 方法來註冊事件，然後使用代碼來控制是否允許更新。 這種作法非常有效，因為您可以根據清單或項目的任何中繼資料來進行安全性決策，但不會影響檢視呈現的效能。
使用 AddToCurrentScopeOnly 方法來指派 SharePoint 群組中的「限制存取」成員資格。 此原則中的關鍵元素是重新設計架構，讓範圍成員資格不會造成訪問控制清單 (ACL) 在上層文檔庫和 Web 重新計算。 如需範圍變更的其他資訊，請參閱「問題 3：依範圍結構變更使用微調權限 (僅限 2010)。
使用更細緻的許可權時，很容易無意中遇到無法解析許可權的限制。 本節說明其中一些限制，以及如何設定限制而讓權限得以正確解析的最佳作法。
清單中有太多範圍
每個清單或文檔庫有50,000個範圍的內建限制。 達到 50,000 個範圍之後，禁止在指定的清單或文件庫中增加新範圍。
最佳作法：
僅在父物件上設定專屬範圍，例如資料夾。
請勿在具有許多範圍的物件下方建立具有許多唯一許可權對象的系統。
如果您的業務要求一份清單或一個文件庫中有 50,000 個以上的專屬權限項目，則必須將某些項目移到不同的清單或文件庫。
變更內建範圍限制
使用 Microsoft PowerShell 指令碼來變更內建範圍限制。
使用 Windows PowerShell 來變更內建範圍限制
- 確認您具備下列成員身分：
SQL Server 執行個體上的 securityadmin 固定伺服器角色。
所有要更新之資料庫上的 db_owner 固定資料庫角色。
您執行 PowerShell Cmdlet 之伺服器上的系統管理員群組。
請以高於上述基本要求新增必要的成員資格。
系統管理員可以使用 Add-SPShellAdmin Cmdlet 授與使用 SharePoint Server 2016 Cmdlet 的權限。
注意事項
[!附註] 如果您不具備上述權限，請連絡安裝程式系統管理員或 SQL Server 系統管理員要求權限。 如需 PowerShell 許可權的詳細資訊，請參閱 Add-SPShellAdmin。
啟動 SharePoint Management Shell
在 PowerShell 命令提示字元中，輸入下列命令：
$webapp = Get-SPWebApplication http://<serverName> $webapp.MaxUniquePermScopesPerList $webapp.MaxUniquePermScopesPerList = <Number of scope limit>其中：
其中 <serverName> 是 SharePoint 伺服器陣列中應用程式伺服器的名稱。
其中 <範圍數目限制> 是您想要允許每個 SharePoint 清單的唯一許可權範圍數目上限。 如果相同階層式層級存在許多範圍，有效限制往往比 50,000 小很多。 這是因為必須針對該階層式層級上的所有範圍檢查該階層式層級下的項目顯示檢查。 此限制可能會導致特定查詢中允許的有效範圍數目減少到 1,000 至 2,000。
注意事項
[!附註] 建議您在執行命令列管理工作時使用 Windows PowerShell。 Stsadm 命令列工具已過時，但為與舊版產品相容，仍會隨附提供。
權限範圍中有太多成員
如先前所述，當相關權限範圍的成員資格變更時會計算二進位 ACL。 這包含增加新的限制存取成員時。 隨著範圍成員數目增加，重新計算二進位 ACL 所需的時間會隨之增加。
此問題可能會變得更糟，因為在子物件的專屬範圍新增使用者，將會導致其父範圍隨著新的「限制存取」成員更新，即使最終父範圍成員資格沒有變更。 發生這種情形時，還必須重新計算父範圍的二進位 ACL，以致處理時間更長，即使最終會導致相同的 ACL 亦然。
最佳作法：
依賴權限範圍中的群組成員資格，而非個別使用者成員資格。 例如，若可以使用單一群組，而非 1,000 個個別使用者，則權限範圍與其任何父範圍的範圍將會是小於 999 個成員資格項目。 此外，將會更新具有「限制存取」權的單一群組，而非更新具有「限制存取」權的每個使用者。 這也有助於加快在父範圍物件上發送「限制存取」權和重新計算 ACL 的速度。
重要事項
[!重要事項] 使用 SharePoint 群組將會導致索引的完整編目。 可能的話，請使用網域群組。
非常多層的範圍階層
如先前所指出，權限範圍的階層深度會影響將「限制存取」使用者新增至父範圍所需執行的工作。 一個項目中以上的專屬範圍數目愈大 (包含專屬權限 Web)，必須發生的新增數目就愈大。 如果範圍階層有非常多層，則範圍成員資格變更可能需要很長的時間才會發生，因為最深層範圍項目中的每個成員資格變更將必須針對具有「限制存取」權之明確新增的使用者或群組，隨著成員資格新增反覆更新父範圍。 此外，這會增加必須重新計算的二進位 ACL 數目，並產生相應的效能要求。
最佳作法：
減少專屬權限父物件的數目。 這麼做會減少當任何子物件的範圍變更時，必須隨著「限制存取」成員更新的範圍數目。