資訊保護的安全性最佳做法
重要
2020 年 3 月之前發行的 Microsoft Rights Management Service SDK 版本已被取代;使用舊版的應用程式必須更新為使用 2020 年 3 月版本。 如需完整詳細資料，請參閱 淘汰通知。
Microsoft Rights Management Service SDK 沒有進一步的增強功能。 我們強烈建議採用Microsoft 資訊保護 SDK來分類、標記和保護服務。
資訊保護軟體開發套件 (SDK) 提供一個健全的系統，可用來發佈和取用所有類型的受保護資訊。 若要盡可能強化系統，必須使用最佳做法來建置啟用資訊保護的應用程式。 應用程式可分擔協助維護此生態系統安全性的責任。 識別安全性風險並針對在開發應用程式時引發的風險提供緩和措施，可將較不安全軟體實作的可能性降到最低。
這項資訊是用來補充法律合約，必須簽署此法律合約才能使用 SDK 取得應用程式的數位憑證。
未涵蓋的主題
雖然下列主題是建立開發環境和保護應用程式的重要考量，但不在本文討論範圍內：
- 軟體開發程序管理 - 設定管理、保護原始程式碼、將對已偵錯之程式碼的存取權降到最低，以及為 Bug 指派優先順序。 對某些客戶而言，擁有一個較安全的軟體開發程序極其重要。 有些客戶甚至還會規定開發程序。
- 常見的編碼錯誤 - 避免緩衝區溢位的資訊。 建議您參閱 Michael Howard 與 David LeBlanc (Microsoft Press 2002 年) 所撰寫的最新版 Writing Secure Code (撰寫安全的程式碼)，以檢閱這些一般威脅和緩和措施。
- 社交工程 - 包括有關程序性和結構性保護的資訊，這些保護可協助防止程式碼遭到製造商組織內的開發人員或其他人非法利用。
- 實體安全性 — 包括有關鎖住對程式碼基底的存取及簽署憑證的資訊。
- 發行前版本軟體的部署或散佈 — 包括有關散佈 Beta 版軟體的資訊。
- 網路管理 — 包括有關您實體網路上之入侵偵測系統的資訊。
威脅模式與緩和措施
數位資訊擁有者必須要能夠評估將解密其資產的環境。 最低安全性標準聲明提供資訊擁有者一個架構，用以了解和評估應用程式的安全性層級。
有些產業 (例如政府和衛生保健) 具有可能適用於您產品的認證及鑑定程序與標準。 達成這些最低安全性建議，並不代表可以取代客戶獨特的鑑定需求。 不過，安全性標準是要協助您為目前和未來的客戶需求做好準備，而您在開發週期初期所做的任何投資都將對您的應用程式有所助益。 這些指導方針是建議，不是正式的 Microsoft 認證計劃。
版權管理服務系統中有數個主要的漏洞類別，包括︰
- 外洩 — 資訊出現在未經授權的位置。
- 損毀 — 軟體或資料在未經授權的情況下被修改。
- 拒絕 - 計算資源無法供使用。
這些主題主要著重於外洩問題。 API 系統完整性取決於它是否能夠隨著時間的進展，透過只允許存取指定實體的方式來保護資訊。 這些主題也會談到損毀問題。 拒絕問題則不屬於涵蓋範圍。
Microsoft 不會測試或檢閱與符合最低標準相關的測試結果。 合作夥伴需負責確保符合最低標準。 Microsoft 提供兩個額外層級的建議來協助降低常見威脅的風險。 一般而言，這些建議是附加的。 例如，符合慣用建議是假設您已符合適用的最低標準，除非另有指定。
| 標準層級 | Description |
|---|---|
| 最低標準 | 處理受保護資訊的應用程式必須符合最低標準，才能以 Microsoft 所收到的生產環境憑證進行簽署。 合作夥伴通常會在軟體的確定發行版本階段使用生產環境階層憑證。 使用了合作夥伴自己的內部測試來驗證應用程式是否符合此最低標準。 符合最低標準並不可 (也不應該) 解釋為是 Microsoft 所做出的安全性保證。 Microsoft 不會測試或檢閱與符合最低標準相關的測試結果。 合作夥伴需負責確保符合最低標準。 |
| 建議的標準 | 建議的指導方針不僅詳細地計劃提升應用程式安全性的途徑，也指出 SDK 如何隨著更多安全性準則的實作來演進。 廠商可能會將其應用程式建置成符合這個較高層級的安全性指導方針，來突顯其應用程式的優勢。 |
| 慣用標準 | 此標準是目前已定義的最高安全性類別。 廠商如果開發標榜高安全性的應用程式，就應該以此標準為目標。 符合此標準的應用程式可能最不易於受到攻擊。 |
惡意軟體
Microsoft 已定義所需的最低標準，您的應用程式必須符合這些標準，才能保護內容不受惡意軟體侵害。
使用位址表格來匯入惡意軟體
資訊保護 SDK 不支援在執行階段修改程式碼，或是修改匯入位址表格 (IAT)。 針對您處理程序空間中載入的每個 DLL，都會建立一個匯入位址表格。 它指定了您應用程式所匯入之所有函式的位址。 其中一個常見的攻擊就是修改應用程式內的 IAT 項目，例如，修改成指向惡意軟體。 SDK 會在偵測到此類型的攻擊時停止應用程式。
最低標準
- 您無法在執行期間修改應用程式處理程序中的匯入位址表格。 您的應用程式會透過使用位址表格，指定許多在執行階段呼叫的函式。 這些表格無法在執行階段期間或之後更改。 除此之外，此限制也意謂著您無法在以生產環境憑證簽署的應用程式上執行程式碼分析。
- 您無法從資訊清單中指定的任何 DLL 內呼叫 DebugBreak 函式。
- 您無法在設定 DONT_RESOLVE_DLL_REFERENCES 旗標的情況下呼叫 LoadLibrary。 此旗標會告訴載入器略過與所匯入模組進行繫結的步驟，因而可修改匯入位址表格。
- 您無法透過對 /DELAYLOAD 連結器參數進行執行階段變更或後續變更，來更改延遲的載入。
- 您無法透過提供自己的 Delayimp.lib 協助程式函式版本，來更改延遲的載入。
- 當資訊保護 SDK 環境存在時，您無法卸載由已驗證模組所延遲載入的模組。
- 您無法使用
/DELAY:UNLOAD連結器參數來啟用延遲模組的卸載。
不正確地解譯授權權限
如果應用程式未正確地解譯及強制執行 SDK 發行授權所表示的權限，可能會導致應用程式以資訊擁有者未預期的方式提供資訊。 例如，當發行授權僅賦予檢視資訊的權限時，應用程式卻允許使用者將未加密的資訊儲存到新媒體。
Azure 資訊保護 (AIP)
資訊保護系統會組織一些群組的許可權。 如需詳細資訊，請參閱設定 Azure 資訊保護的許可權。
AIP 可允許或不允許使用者將資訊解密。 資訊並沒有任何固有的保護。 如果使用者具備解密的權限，API 就會允許解密。 應用程式會在資訊解密後負責管理或保護該資訊。 應用程式需負責管理其環境和介面，以防止資訊遭到未經授權的使用。 例如，如果授權僅授與「檢視」權限，便停用 [列印] 和 [複製] 按鈕。 您的測試套件應確認應用程式會依據它所認可的所有授權類型正確運作。
最低標準
- XrML v.1.2 許可權的客戶實作應該與這些許可權的定義一致，如 XrML 規格中所述，可在 XrML 網站 (http://www.xrml.org) 取得。 如果有任何您應用程式特定的權限，則針對對您應用程式感興趣的所有實體，都必須定義這些權限。
- 您的測試套件和測試程序應確認應用程式會依據其支援的權限正確執行。 也應確認「不會」依據不支援的權限運作。
- 如果您要建置一個發佈應用程式，您就必須提供資訊來說明所使用的內建權限。 這包括發佈應用程式所支援和不支援的，以及應該如何解譯這些許可權。 此外，使用者介面應該向使用者清楚傳達被授與或拒絕一段個別資訊的每個權限有何含意。
- 任何權限只要是透過包含在應用程式所實作的新權限中來提取，就必須對應至新的術語。 例如，稱為 MANAGER 的新權限可能包含提取的權限，例如 PRINT、COPY 及 EDIT 權限。
建議的標準
目前未提供。
慣用標準
目前未提供。
後續步驟
使用 AIP SDK 來實作應用程式的最佳做法包括下列文章：