共用方式為


安全性網域:數據處理安全性和隱私權

此安全性網域的設計目的是要確保從 Microsoft 365 取用的任何數據在傳輸中和待用時都會受到充分保護。 此網域也可確保ISV符合消費者 (數據主體) 隱私權考慮,符合GDPR (一般數據保護規定) 和 HIPAA (1996) 健康保險可移植性和責任法案。

傳輸中的數據

Microsoft 365 開發的應用程式/載入巨集的連線需求需要透過公用網路進行通訊,特別是因特網。 因此,傳輸中的數據必須適當地受到保護。 本節涵蓋透過因特網的數據通訊保護。

控制節點 1

請提供下列所有項目的辨識項:

  • 驗證您的 TLS 組態為 TLS1.2 或更高版本。

  • 系統會保留並維護受信任密鑰和憑證的清查。

意圖:TLS

此子點的目的是要確保貴組織所取用Microsoft 365 個數據安全地傳輸。 TLS 配置檔組態可用來定義 TLS 特定需求,以協助確保流量安全地抵禦攔截式攻擊。

指導方針:TLS

最簡單的方式就是針對所有 Web 接聽程式執行 Qualys SSL Server 測試 工具,包括在非標準埠上執行的任何。

請記得勾選 [不要在面板上顯示結果] 選項,這會阻止 URL 新增至網站。

提供個別檢查的辨識項,即可示範 TLS 配置檔組態需求。 若要提供特定設定的辨識項,例如停用 TLS 壓縮、組態設定、腳本和軟體工具。

範例辨識項:TLS

下列螢幕快照顯示 Qualys 針對 webappfrontdoor- byendbagh6a0fcav.z01.azurefd.net 進行 SSL 掃描的結果。

使用 A+ 評等憑證 #1 的 Qualys 報告進行 SSL 掃描。

[通訊協定] 區段顯示 TLS1.2 是唯一支援/啟用的通訊協定。

Qualys 的 SSL 掃描報告 TLS 組態表。

注意:認證分析師會檢閱掃描的完整輸出,以確認符合TLS配置檔設定需求的所有需求。 預期會針對公開的所有端點提供掃描, (IP 位址和 URL) 至範圍內的後端環境。 根據所提供的辨識項,分析師可能會執行自己的 Qualys 掃描。

範例辨識項:TLS

下列螢幕快照顯示 Azure 應用程式服務中 TLS 的組態設定,後面接著透過 PowerShell 的 TLS 列舉。

已醒目提示最低 TLS 版本的 Azure Web 應用程式組態設定

適用於 PaaS-FrontDoor-WebApp 的 Azure Web 應用程式 Powershell 程式代碼行。

意圖:金鑰和憑證

此子點的目的是要確保維護受信任密鑰和憑證的完整清查,包括識別相依於這些密碼編譯元素的各種系統、服務和應用程式。

指導方針:金鑰和憑證

辨識項必須證明信任密鑰和憑證的清查存在且受到維護。 此外,可以提供用來儲存實際密鑰和憑證之工具的適用辨識項,例如 Azure 金鑰保存庫、HashiCorp 保存庫秘密、Confluence Cloud 等。

範例辨識項:金鑰和憑證

下列螢幕快照顯示在 Confluence Cloud 中維護密鑰和憑證清查。

具有核准金鑰的 Confluence 憑證檢查清單清查。

下列螢幕快照顯示已核准的信任金鑰和憑證清單。 其中包含憑證、金鑰、密碼及其安裝所在的系統等詳細數據。

Confluence 憑證金鑰清查清單和檢查清單。

下列螢幕快照來自 HashiCorp Vault。 清查清單中概述和記錄的憑證會儲存在此在線保存庫中。 HashiCorp Vault 是一種開放原始碼工具,用於秘密管理、加密即服務,以及特殊許可權存取管理。

Hashicorp Vault 概觀儀錶板。

下列螢幕快照是實際憑證和儲存在在線保存庫內之密鑰的擷取。

Hashicorp Vaults 儀錶板秘密報告概觀。 Hashicorp Vault 儀錶板秘密報告第 2 頁。

注意:預期金鑰的儲存位置會有適當的訪問控制。 如果私鑰遭到入侵,則有人可能會利用合法的憑證詐騙伺服器。

範例辨識項:金鑰和憑證

受信任密鑰和憑證的清查也可以使用 Microsoft 365 Defender 來維護,其提供清查功能,如下一個螢幕快照所示。

Microsoft Defender 清查頁面。

下一個螢幕快照顯示憑證的詳細數據。

Microsoft Defender Microsoft跟證書頒發機構單位 2010 的清查頁面快顯。

請注意:這些範例不是全螢幕螢幕快照,您必須提交具有任何 URL、登入使用者以及時間和日期戳記的全螢幕螢幕快照,以供辨識項檢閱。 如果您是Linux使用者,可以透過命令提示字元來完成此動作。

控制節點 2

請提供下列所有項目的辨識項:

  • 顯示所有處理 Web 要求的公開服務都已停用 TLS 壓縮,以防止在發生壓縮比例資訊外泄時發生 (造成) 。

  • 驗證 TLS HSTS 已啟用並設定為跨所有網站 180 天。

意圖:TLS

  • 在壓縮安全套接字層 (SSL) /傳輸層安全性 (TLS) 通訊協定時,對 (壓縮比例資訊洩漏使 CVE-2012-4929) ) 攻擊變得容易 (。 因此,業界建議停用SSL壓縮。

  • HTTP Strict Transport Security (HSTS) 是一種安全性機制,其設計目的是透過名為 “Strict-Transport-Security” 的 HTTPS 回應標頭欄位強制執行 TLS 連線,以保護網站免於攔截式攻擊。

指導方針:TLS

這可透過 Qualys SSL Labs 工具辨識。 範例辨識項:TLS

下列螢幕快照顯示已停用 SSL/TLS 壓縮。

Qualys SSL 實驗室工具報告已停用 SSL/TLS 壓縮。

下一個螢幕快照顯示已啟用 HSTS。

Qualys SSL labs 工具會報告已啟用 HSTS 的輸出。

注意:認證分析師會檢閱完整輸出,確認符合 TLS 配置檔設定需求的所有需求 (請提供完整掃描輸出) 的螢幕快照。 根據所提供的辨識項,分析師可能會執行自己的 Qualys 掃描。

其他可用來檢查是否已啟用 HSTS 的工具為 『HTTP Header Spy』,以及

securityheaders.com 如下列範例所示。 其他辨識項

螢幕快照,例如安全性標頭的組態設定,特別是 HSTS,可提供進一步示範公用使用量的安全性狀態。

下一個螢幕快照顯示 Azure Front Door 設定,以及針對重寫標頭所實作的規則集。

Azure Front Door 組態設定規則集概觀頁面。

Azure Front Door 組態設定規則集組態表

下一個螢幕快照顯示已執行的安全性標頭掃描,並實作所有安全性標頭,而不只是 HSTS。

顯示 A+ 分數的安全性報告摘要標頭掃描。

注意:如果使用 Qualys SSL 掃描器或安全性標頭,預期會提供完整報告供檢閱。

待用資料

當ISV儲存從 Microsoft 365 平台取用的數據時,必須適當地保護數據。 本節涵蓋儲存在資料庫和檔案存放區中之數據的保護需求。

控制節點 3

提供可辨識的辨識項,證明待用數據會根據加密配置檔需求進行加密,並使用 AES、大滑鼠、TDES 等加密演算法,以及 128 位和 256 位的加密密鑰大小。

意圖

某些較舊的加密演算法已知包含一些密碼編譯弱點,這會增加威脅執行者在不知道密鑰的情況下能夠解密數據的機會。 基於這個理由,此控件的目的是要確保只會使用業界接受的加密演算法來保護儲存的 M365 數據。

指導方針

您可以透過螢幕快照提供辨識項,其中顯示用來保護資料庫和其他儲存位置內 M365 數據的加密。 證據應該會示範加密組態符合 Microsoft 365 認證的 加密配置檔 設定需求。

範例辨識項

下一個螢幕快照顯示已在 Contoso 資料庫上啟用 TDE (透明數據加密) 。 第二個螢幕快照顯示Microsoft文件頁面[SQL Database、SQL 受管理執行個體 和 Azure Synapse 分析的透明數據加密],其中顯示 AES 256 加密用於 Azure TDE。

SQL 透明數據加密設定

請注意:在先前的範例中,未使用全螢幕快照,不過所有ISV提交的辨識項螢幕快照必須是顯示URL的全螢幕快照,任何已登入的使用者和系統時間和日期。

Microsoft了解服務管理的透明數據加密檔。

範例辨識項

下列螢幕快照顯示已設定 Blob 和檔案加密的 Azure 記憶體。 下一個螢幕快照顯示待用數據的Microsoft文件頁面 Azure 儲存 體加密,顯示 Azure 記憶體使用 AES-256 進行加密。

Azure 存放區帳戶加密設定

Microsoft瞭解待用數據的 Azure 記憶體加密檔。

數據保留、備份和處置

當ISV取用和儲存Microsoft 365數據時,如果威脅執行者危害ISV環境,就會有數據洩露的風險。 若要將此風險降到最低,組織應該只保留提供服務所需的數據,而不是未來可能使用的數據。 此外,只有在需要提供擷取數據的服務時,才應該保留數據。 應該定義數據保留期,並與用戶通訊。 一旦數據超過定義的保留期間,就必須安全地刪除此專案,才能重新建構或復原數據。

控制節點 4

請提供已正式建立並記載已核准數據保留期限的證明。

意圖

記載並遵循的保留原則不僅對於符合某些法律義務很重要,例如數據隱私權法規,例如,但不限於歐盟GDPR) 一般數據保護規定 (和數據保護法 (英國 DPA 2018) ,也是為了限制組織風險。 藉由瞭解組織的數據需求,以及企業執行其功能所需的數據長度,組織可以確保數據在使用性到期時會正確處置。 藉由減少儲存的數據量,組織會減少在發生數據洩露時所公開的數據量。 這會限制整體影響。

組織通常會儲存數據,因為只在案例中擁有數據是不錯的。 不過,如果組織不需要數據來執行其服務或商務功能,則不應儲存數據,因為這會不必要地增加組織的風險。

此控件的目標是要確認組織已正式建立並記載所有相關數據類型的核准數據保留期間。 這不只牽涉到指定要儲存不同數據類型的持續時間,也會概述數據刪除或封存到期后的程式。

指導方針

提供完整數據保留原則,其中清楚詳述數據 (必須涵蓋所有數據類型的時間長度,) 應保留這些數據類型,讓企業可以執行其商務功能。

範例辨識項

下一個螢幕快照顯示 Contoso 的數據保留原則。

具有版本歷程記錄的數據保留原則計劃檔,由和核准者準備。

數據保留原則數據表,包括類別和保留期間詳細數據。

注意:這些螢幕快照顯示原則/程序檔的快照集。 預期ISV會共用實際的支持原則/程序檔,而不只是提供螢幕快照。

控制節點 5

示範數據只保留在定義的保留期間,如控件 4 中所述。

意圖

此控制項的目的是要只驗證是否符合定義的數據保留期間。 如先前所述,組織可能具有符合此條件的法律義務,但也會保留必要的數據,而且只要必要,有助於降低發生數據外泄時對組織的風險。 這可確保數據不會保留過長的持續時間,也不會提前刪除,這兩者都可能會造成各種性質的風險—法律、作或安全性相關。

指導方針

提供螢幕快照辨識項 (或透過螢幕共用) 顯示所有資料位置中儲存的數據 (,包括資料庫、檔案共用、封存和備份) 未超過定義的數據保留原則。 可接受的螢幕快照範例包括:

  • 具有日期欄位、以最舊記錄順序搜尋的資料庫記錄,以及/或
  • 檔案儲存位置,顯示保留期間內的時間戳。 注意:任何個人或敏感性客戶數據都應該在螢幕快照中進行修訂。
  • 備份記錄顯示備份數據會保留在定義的保留期間內,並在這段期間之後正確刪除。

範例辨識項

下列辨識項顯示 SQL 查詢,其中顯示在 [DATE_TRANSACTION] 字段上以遞增順序排序的資料庫數據表內容,以顯示資料庫內最舊的記錄。 這會顯示數據小於兩個月,且不會超過所定義的保留期間。

SQL 查詢編輯器會執行結果。

注意:這是測試資料庫,因此其中沒有很多歷程記錄數據。

注意:在先前的範例中,未使用全螢幕快照,不過所有ISV提交的辨識項螢幕快照必須是顯示URL的全螢幕快照,任何已登入的使用者和系統時間和日期。

控制節點 6

示範在數據保留期間之後安全地刪除數據的程式。

意圖

此控制項的目的是要確保用來刪除超過保留期間之數據的機制會安全地執行此動作。 刪除的數據有時可以復原;因此,刪除程式必須夠強固,以確保數據在刪除後無法復原。

指導方針

如果刪除程式是以程序設計方式完成,請提供用來執行此作業之腳本的螢幕快照。 如果是依排程執行,請提供顯示排程的螢幕快照。 例如,刪除檔案共享內檔案的腳本可能會設定為CRON作業,螢幕快照顯示排程的CRON作業和執行的腳本;並提供顯示所使用命令的腳本。

範例辨識項

這是一個簡單的腳本,可用來刪除根據日期 -WHERE DateAdd 為 -30 天而保留的所有數據記錄,這將會清除超過所選數據保留日期 30 天的所有保留記錄。 請注意,我們需要腳本;正在執行之作業和結果的辨識項。

顯示成功執行結果的腳本行。

請注意:在先前的範例中,未使用全螢幕快照,不過所有ISV提交的辨識項螢幕快照必須是顯示URL的全螢幕快照,任何已登入的使用者和系統時間和日期。

範例辨識項

下列螢幕快照取自控件 4) 的 Contoso 數據保留原則 (– 這會顯示用於數據解構的程式。

確保數據正確終結原則檔的程式。

注意:此螢幕快照顯示原則/程序檔的快照集。 預期ISV會共用實際的支持原則/程序檔,而不只是提供螢幕快照。

範例辨識項

在此範例中,已在 Azure 中建立 Runbook 和對應的排程,以安全地刪除在數據記錄保留原則到期後的 30 天內建立結束日期的記錄。 此作業設定為在每個月的最後一天執行一次。

Azure Runbook 概觀頁面。

下一個螢幕快照顯示 Runbook 已編輯為尋找記錄,且具有不在檢視中的刪除命令,例如腳本。

Azure 數據保留設定會編輯 PowerShell Runbook。

注意:這些螢幕快照的完整 URL 和使用者名稱必須位於檢視中,且 ISV 必須先顯示的螢幕快照,才能刪除記錄計數,以及刪除記錄計數之後的螢幕快照。

Azure 排程概觀數據保留設定。

這些螢幕快照純粹是不同方法的範例。

Azure 排程 Runbook365 數據保留設定。

控制節點 7

請提供證明,示範:

  • 自動化備份系統已就緒,並已設定為在排程的時間執行備份。

  • 備份資訊會依照備份排程程式進行測試,並定期還原,以確認數據的可靠性和完整性。

  • 適當的訪問控制和保護機制 (也就是實作不可變的備份) ,以確保備份/系統快照集會受到保護,防止未經授權的存取,並確保備份數據的機密性、完整性和可用性。

意圖

此控件的目標是要確認組織已備妥自動化備份系統,其設定為在預先決定的時間執行備份。

指導方針

請提供備份解決方案中組態設定的螢幕快照,其中顯示備份是在排定的期間/時間間隔執行。 如果解決方案會自動完成備份排程,則可提供廠商文件來支援。

範例辨識項

下列螢幕快照適用於受控實例 適用於 MySQL 的 Azure 資料庫。 這表示已完成第一個自動備份。

適用於 MySQL 的 Azure 備份和還原設定。

下一個螢幕快照是在經過一段時間之後擷取,顯示已進行進一步的完整備份。 彈性伺服器上的備份是以快照集為基礎,其中第一個快照集備份會在建立伺服器之後立即排程,而且每天會進行一次進一步的快照集備份。

Azure 備份和還原設定概觀。

下一個螢幕快照顯示在線檔的快照,其中概述備份頻率和自動備份功能。

learn.microsoft.com 自動備份檔。

意圖

此控件的目的是要證明備份信息不僅會依排程產生,也很可靠,而且會隨著時間維持其完整性。 為了符合此目標,將會對備份數據執行定期測試。

指導方針

符合此控件的辨識項將取決於組織測試備份數據的程序和程式。 可以提供辨識項,其中顯示已成功測試的備份,以及歷程測試完成的記錄。

範例辨識項

下列螢幕快照顯示備份排程和還原程式存在且已維護,而且已針對所有適用的系統定義備份組態,包括在 Confluence 平臺中執行備份的頻率。

Confluence 備份排程和還原程式與數據備份計劃。

下一個螢幕快照顯示每個適用系統的備份測試歷程記錄頁面。 請注意,每個測試都會參考數據表右側的 JIRA 票證。

Confluence 備份設定測試頻率。

接下來的四個螢幕快照顯示從快照還原 適用於 MySQL 的 Azure 資料庫 的端對端程式。 使用 [快速還原] 選項,我們可以起始 SQL 資料庫的還原程式。

使用中伺服器的 Azure 備份和還原設定概觀頁面。

下列螢幕快照顯示我們可以在其中自定義還原的組態頁面。

建立適用於 MySQL 彈性伺服器的 Azure 資料庫的 Azure 備份和還原設定。

一旦選取要從中還原資料庫的目標位置、網路和快照集,我們就可以起始部署。 請注意,我們的資料庫實例現在稱為 『test』。

Azure 部署概觀:您的部署正在進行中。

在總共五分鐘之後,SQL 資料庫已成功從備份快照集完整還原,如下所示。

Azure 部署概觀:您的部署已完成。

測試完成後,請與建立 JIRA 票證的程式一起建立,以記錄備份測試和所執行還原的詳細數據。 這可確保歷程記錄數據可用於合規性用途,以及完整的記錄存在,以供在事件或災害的最終狀況中檢閱,以允許組織執行根本原因分析。

適用於 Azure 資料庫 mySQL 的 Jira 備份票證。

具有持續時間、結果和活動追蹤器的 Jira 備份票證。

意圖

從上一個控件開始,應該實作訪問控制,以限制只有負責備份數據的個別使用者才能存取。 藉由限制存取權,您可以限制未經授權的變更執行的風險,因而導致不安全的變更。 應採用最低許可權的方法來保護備份。

若要正確保護數據,組織必須知道其環境/系統正在取用哪些數據,以及數據的儲存位置。 一旦完全瞭解並記載此信息之後。

然後,組織不僅能夠實作適當的數據保護,也能夠合併數據所在的位置,以更有效率地實作保護。 此外,當數據儘可能合併到最少的位置時,實作適當的 RBAC (角色型訪問控制) ,以視需要限制對少數員工的存取會更為容易。

指導方針

您應該從示範備份和備份解決方案訪問許可權的系統/技術提供辨識項,並提供核准存取清單的支援檔。

範例辨識項

我們可以在下列螢幕快照中看到,在資料庫實例上實作訪問控制,以根據作業角色限制僅授權人員的存取權。

Azure 訪問控制儀錶板。

範例辨識項

Azure SQL 資料庫和 Azure SQL 受控實例的自動化備份是由 Azure 管理,且其完整性是 Azure 平臺的責任;沒有任何使用者可以存取這些備份,而且會在待用時加密,而且不會遭受勒索軟體攻擊。 它們也會復寫到其他區域以進行保護。

learn.microsoft.com 受控實例原則檔 Azure SQL 自動備份。

數據存取管理

數據存取需要視需要限制為最少的人員,以降低數據遭到惡意或意外入侵的機會。 數據和加密密鑰的存取權應限於具有合法商務存取權的使用者,才能履行其工作角色。 應實作妥善記載且妥善建立的要求存取程式。 存取數據和加密金鑰應遵循最低許可權原則。

控制節點 8

提供辨識項,以證明具有資料和/或加密金鑰存取權的個人清單:

  • 會維護 ,包括每個人的業務理由。

  • 已根據其作業函式所需的訪問許可權正式核准。

  • 使用核准中概述的許可權來設定。

意圖

組織應該將數據和加密金鑰的存取限制為盡可能少的員工。 此控件的目的是要確保員工對數據和/或加密密鑰的存取權僅限於對上述存取有明確商務需求的員工。

指導方針

內部系統的檔或螢幕快照,其中記錄具有數據和/或加密密鑰存取權的所有員工,以及為何應提供這些人員存取權的商業理由。 認證分析師會使用這份清單來取樣下一個控件的使用者。

範例辨識項

下列文件顯示具有數據存取權和業務理由的已記載用戶清單。

Cotoso 核准的使用者存取檔。

注意:此螢幕快照顯示原則/程式檔,預期ISV會共用實際的支持原則/程序檔。

意圖

授與數據和/或加密密鑰存取權的程式必須包含核准,以確保其作業功能需要個人的存取權。 這可確保沒有實際存取理由的員工不會取得不必要的存取權。

指導方針

一般而言,為上一個控件提供的辨識項有助於支援此控件。 如果提供的文件沒有正式核准,則辨識項可能包含針對 Azure DevOps 或 Jira 等工具內的存取提出和核准的變更要求。

範例辨識項

這組影像顯示為 i) 的控制 (建立並核准 Jira 票證,以授與或拒絕敏感數據和/或加密密鑰的存取權。 此影像示範已在 Jira 中建立要求,以取得系統後端環境中加密密鑰的 Sam Daily 核准。 這是在取得書面授權的下一個步驟中完成。

加密金鑰票證的 Jira 核准要求。

醒目提示核准的 Jira 核准票證。

這會顯示提供 Sam Daily 存取權的要求,已由 Jon Smith 從管理人員核准。 (請注意,核准必須來自具有足夠授權才能允許變更要求的人員,不能是另一個開發人員) 。

具有狀態的進程流程圖。

上一個顯示此程式在 Jira 中的工作流程。 請注意,除非已通過自動化且因此無法略過的核准程式,否則沒有任何專案可以新增為完成。

醒目提示核准階層的 Jira AAA 短期衝刺面板。

Project 面板現在顯示已核准 Sam Daily 的加密金鑰存取權。 下列待辦項目顯示 Sam Daily 的要求核准,以及指派要執行工作的人員。

具有指派的 Jira 待辦項目面板。

若要符合此控件的需求,您必須顯示所有這些螢幕快照或類似/對等的辨識項,並提供說明以證明您已符合控件需求。

請注意:在先前的範例中,未使用全螢幕快照,不過所有ISV提交的辨識項螢幕快照必須是顯示URL的全螢幕快照,任何已登入的使用者和系統時間和日期。

範例辨識項

在下一個範例中,已要求使用者存取生產資料庫的系統管理員存取權和完全控制許可權。 要求已傳送以供核准,如影像右側所示,且已核准,如左側所示。

Jira 核准面板描述, 核准者, 資料, 醒目提示。

下一個影像表示存取已核准,並已在完成時註銷。

Jira 核准面板描述、核准者、日期和註銷,以醒目提示方式實作。

請注意:在先前的範例中,未使用全螢幕快照,不過所有ISV提交的辨識項螢幕快照必須是顯示URL的全螢幕快照,任何已登入的使用者和系統時間和日期。

Intent

此子點的目的是要確認數據和/或加密金鑰存取已根據記載進行設定。

指導方針

您可以透過螢幕快照提供辨識項,其中顯示授與取樣人員的數據和/或加密密鑰存取許可權。 辨識項必須涵蓋所有資料位置。

範例辨識項

此螢幕快照顯示授與使用者 「John Smith」 的許可權,這些許可權會交叉

根據前一個控件的辨識項,針對這個相同使用者的核准要求參考。

請注意:下列範例不是全螢幕螢幕快照,您必須提交具有任何 URL、登入使用者以及時間和日期戳記的全螢幕螢幕快照,以供辨識項檢閱。 如果您是Linux使用者,可以透過命令提示字元來完成此動作。

具有查詢結果的Linux查詢編輯器。

控件 No. 9

提供辨識項:

  • 維護與數據共用之所有第三方的清單。

  • 數據共享協定已與所有使用數據的第三方一起使用。

意圖

當第三方用於儲存或處理Microsoft 365 數據時,這些實體可能會造成重大風險。 組織應該開發良好的第三方盡職調查和管理程式,以確保這些第三方安全地儲存/處理數據,並確保他們遵守可能擁有的任何法律義務,例如 GDPR 下的數據處理者。

組織應該維護與其共享數據的所有第三方清單,以及下列部分或全部:

  • 所提供的服務 () ()

  • 共用的數據

  • 共用數據的原因

  • 密鑰連絡資訊 (例如主要聯繫人、外洩通知聯繫人、DPO 等 )

  • 合約續約/到期

  • 法律/合規性義務 (例如 GDPR、HIPAA、PCI DSS、FedRAMP 等 )

指導方針

提供文件,詳細說明共用Microsoft 365 數據的所有第三方。

注意:如果第三方未使用,則必須以撰寫 (電子郵件) 由資深領導小組成員確認。

範例辨識項

Contoso 資料共享協定。

數據處理特性頁面。

請注意:在先前的範例中,未使用全螢幕快照,不過所有ISV提交的辨識項螢幕快照必須是顯示URL的全螢幕快照,任何已登入的使用者和系統時間和日期。

範例辨識項

下列螢幕快照顯示資深領導小組成員的電子郵件範例,確認沒有任何第三方用來處理Microsoft 365 數據。

Email CEO re:敏感數據共用。

請注意:在這些範例中,未使用全螢幕快照,不過所有ISV提交的辨識項螢幕快照必須是顯示URL的全螢幕快照,任何已登入的使用者和系統時間和日期。

意圖

當 M365 數據與第三方共用時,請務必適當且安全地處理數據。 數據共享協議必須已就緒,以確保第三方只會視需要處理數據,並瞭解其安全性義務。 組織安全性只會與最弱的連結一樣強大。 此控件的目的是要確保第三方不會成為組織的弱式連結。

指導方針

提供與第三方簽訂的數據共享協定。

範例辨識項

下一個螢幕快照顯示數據共享合約的簡單範例。

具有概觀和定義的數據共享合約第 1 頁。

具有責任、機密性和簽章的數據共享合約第 2 頁。

注意:應共用完整合約,而不是螢幕快照。

隱私權

隱私權合規性和資訊管理對於保護個人權利並確保負責的數據處理至關重要。 若要讓組織建立有效的隱私權資訊系統,他們必須留意其保存的個人資料,以及處理和儲存這類數據的目的。 組織應該對應資訊流程和處理方式,並辨識可能會發生數種不同類型的處理。

控制節點 10 – 個人資料

提供貴組織的證據:

) 維護收集、處理及儲存之所有個人資料的最新清查,包括每個數據元素的用途。 

B) 設計數據收集表單,只包含商務用途所需的欄位,並適當地實作必要和選擇性欄位。 

C) 開發並強制執行原則,以指定可收集的個人資料類型,以及可使用這些數據的目的。 

D) 可讓使用者選擇不處理或廣泛顯示其個人、非商務基本數據。 

意圖

此控件的目的是要確保您遵守與數據收集有關的數據隱私權,確保擷取的數據有其理由,並清楚瞭解收集數據的內容和原因。 使用者 (數據主體) 能夠退出處理也很重要。  

指導方針

此控件的辨識方式如下:

) 提供目前版本的處理活動記錄 (RoPA) , (請參閱 GDPR 文章 30) 或詳細數據元素的類似檔,以及處理 () 目的 (請參閱 GDPR 文章 5.1.b) 。 

在大部分情況下,這會是 Excel 電子表格 (,可從 OneTrust) 等工具中擷取。 

如果檔案太大或包含敏感數據,可以提供摘錄,顯示指定數據範例的所有數據欄位,只要辨識項可以保證 RoPA 已就緒,就可以進行部分修訂。 

不符合規範:記錄不存在、非常舊/過期,或遺漏索引鍵字段。 

B) 如需「數據最小化」的目的 (請參閱 GDPR文章5.1.c) ,提供用來取得數據的所有表單,不論是在在線、使用tablet或類似的裝置, (例如會議) 或檔。 這些可能是空白/範本。 

不符合規範:表單具有必要的欄位,不需要用於預定的處理目的。 例如,要求電話號碼、年齡或性別,以透過電子郵件或郵件位址傳送手冊。  

C) 如需「合法性、公平性和透明度」的目的 (請參閱 GDPR文章5.1.a) 適用於員工) 的隱私策略 (,必須備妥適用於使用者/客戶) 的隱私權通知 (。 一般而言,隱私權注意事項應該會在組織的網站上公開提供。  

不符合規範:原則不存在或遺漏主要元素。 

主要元素:

隱私策略/注意:資訊收集和使用方式、已處理的數據元素、處理的目的 () 、處理的合法性、傳輸至其他國家/地區的數據、數據主體許可權、數據儲存和保留。  

D) 如需退出機制 (請參閱 GDPR 文章 4.11GDPR 第 6 條GDPR 第 7 條) ,通常是在網頁上。 檢查使用者需要遵循的流覽,才能到達該頁面 (例如,是否容易找到?) 。 

不符合規範:沒有明確的退出功能或「泛型」退出,且沒有粒度。 

範例辨識項

為)

電子表格專案,包括數據保護人員和處理活動的記錄。

針對 B)

手冊順序表單。左側的窗體會要求電子郵件,右邊的窗體會要求電話號碼,並以圓形表示 X'd out。

針對 C)

Iapp25 常見問題清單,包括我們如何收集和使用您的個人資訊和數據主體許可權。

針對 D)

選擇加入行銷接收電子報、促銷和免費範例。

控制節點 11 – 使用者感知

提供使用者知道的辨識項:

可存取其數據的)

B) 可存取其工作空間的人員

C) 可透過共用或數據流存取其數據的人員,讓他們能夠做出明智的決策。

意圖

此控件的目的是要示範數據保護「透明度」原則 (請參閱 GDPR文章5.1.a) 。

指導方針

為了證明這已就緒,最好是某種形式的用戶認可 (例如,必須先閱讀隱私策略) 應該就地記錄下來。

實際上,只要為員工 (隱私策略) ,使用者和客戶的隱私權通知 () ,請提供下列各項的足夠詳細數據:

- 與 (處理者、子處理者、第三方、約聘人員等共用個人資料 ) 。

不符合規範:沒有通知存在,或隱私策略/隱私權通知不存在。

範例辨識項

我在此表示已閱讀並瞭解我們的隱私策略。

OR

Iapp25 常見問題清單,包括我們如何收集和使用您的個人資訊和數據主體許可權。

控制節點 12 – 數據處理協定 (DPA)

提供數據處理合約的辨識項,其中應包含所有已核准的第三方/子處理者的清單。

意圖

為了確保您對數據主體保持透明,確保他們收到通知,告知哪些第三方/子處理者可以存取其數據、他們在處理 (數據控制者、數據處理者) 、其各自的責任和安全性機制中所扮演的角色。

此外,當數據共用涉及將數據傳輸至歐盟以外地區 (在GDPR) 下,確保傳輸是合法的機制詳細數據。 (參閱 GDPR 第 5 條GDPR 文章 44-50)

針對GDPR,要處理的區域必須符合下列其中一個條件:

- 成為歐盟成員國家。

- 由歐洲委員會視為提供「適當的保護措施」。 目前清單可以在這裡找到: 非歐盟國家/地區的數據保護是否充分

自 2025 6 月 13 日起:

歐洲委員會清單,可辨識GDPR和LED架構下的衝突。

- 成為數據隱私權架構 (DPF) 的一部分,並列於此處: 數據隱私權架構

- 已備妥系結公司規則 () BCR。

- Standard (SCC 的合約條款) 備妥。

指導方針

辨識項可能是透過取樣數個數據處理合約的方式, (DPA) 現有的子處理器。 在某些情況下,組織可能沒有 DPA,但會有合約的附錄或「隱私權條款」。

不符合規範:

- 缺少第 3 方 / 子處理器的清單。

- 未提供收件者國家/地區的詳細數據。

- 國家/地區未列為「適當的國家/地區」,而且沒有BCR 或 SCC。

範例辨識項

此範例顯示來自IAPP的範例 DPA,或辨識項可能是相關文件,其中列出與數據共享的物件。

來自數據處理合約的 Exceprt。

此外,請檢查歐盟外部的數據傳輸機制。

數據傳輸之數據處理合約的 Exceprt。

控制節點 13 – 數據保護影響評估 (DPIA)

提供您的組織執行數據保護影響評估 (DPIA)

     OR

提供與此隱私權檢閱所連線之數據隱私權和保護相關的評量名稱。

意圖

此控件的目的是要確保您對個人權利和自由的潛在風險執行評估,特別是與引進新技術或新式使用現有技術有關。 (參閱 GDPR 文章 35)

指導方針

檢閱最近的 DPIA 或相關評定檔,即可評估此控件。

不符合規範:

DPIA 應該具有下列元素:

- 識別 DPIA 的需求。

- 已修改處理的描述,包括範圍、內容和目的 () 。

- 必要性和比例評估。

- 風險的識別和評估。

- 識別可降低風險的量值。

- 記錄的結果。

如果遺漏上述任何一項,或只是在發音層級執行,此控件可以標示為不符合規範。

範例辨識項

範例 DPIA 範本。

步驟 1:識別 DPIA 的需求。

您可以在 ICO 的網站上找到 DPIA 的完整樣本 ,dpia-template.docx

控制節點 14 – 生物特徵辨識數據

應用程式是否與生物特徵辨識數據互動? 如果是,

提供證明生物特徵辨識數據已通過法律檢閱、受到保護,並通知使用者,並提供選擇加入/退出生物特徵辨識數據收集的選項。

意圖

此控件有興趣確保生物特徵辨識數據的適當保護, GDPR 第 9 條 將此數據分類為特殊的數據類別。  生物特徵辨識數據的使用經過了一項合法性分析。

指導方針

生物特徵辨識數據的使用必須經過法律檢閱,因此必須在辨識項集合中提供。 如果沒有存在,請要求 (用來檢查其整備) 的範本。

不符合規範:

生物特徵辨識數據處理的法律檢閱應包含下列各項:

- 下列一或多個) (處理的法律基礎:

同意 合約的效能 其他法律義務
同意 合約的效能 其他法律義務
重要興趣 公開興趣 合法的權益

- 列出處理生物特徵辨識數據的有效條件 (下列一或多個) :

用戶的明確同意 雇用或社會安全
用戶的明確同意 雇用或社會安全
保護重要興趣 合法活動
數據主體以指令清單方式公開個人資料 建立、執行或防禦法律宣告
重大的公共利益 預防性或醫學
公用健康情況領域的公開興趣 為了公開、科學或歷史研究而進行封存

- 考慮使用替代專案,而不是生物特徵辨識數據。

如果遺漏上述任何一項,或只是在發音層級執行,此控件可以標示為不符合規範。

範例辨識項

來源:

- GDPR 文章 9 – 特殊資料類別的處理: 藝術.9 GDPR – 處理特殊類別的個人資料 - 一般數據保護規定 (GDPR)

- ICO「我們如何以任意方式處理生物特徵辨識數據?」: 如何以實際方式處理生物特徵辨識數據? |ICO

 

控制節點 15 – Data Insights

提供辨識項,指出計量只會顯示匯總和匿名的數據,而沒有個別可識別的數據。 租用戶應該能夠設定其慣用的匯總層級下限,產品允許的絕對最小值為 5。

意圖

此控件的目的是要確保您已實作,並在整個數據生命週期中維持匿名和假名化數據的狀態。 (參閱

指導方針

為了協助示範此控件已就緒,應該提供透過 GUI 或 CLI 的辨識項來示範:

- 匯總層級最低限制的用戶層級設定。

- 計量的範例。

評估使用者是否可以設定其慣用匯總層級的閾值,最小值為 5。 辨識項應該會示範計量範例中只有匿名。

不符合規範:

- 用戶無法將其匯總層級自定義為最少 5,或是一般使用者無法預期需要的技術技能。

- 個人資料存在於計量範例中;例如:姓名、姓氏、標識碼、客戶號碼、電話號碼、電子郵件地址、郵件地址、銀行詳細數據、近親等等。

範例辨識項

組態設定的螢幕擷取,其中顯示特定詳細數據。

收集的計量範例。 或許要詢問達成匿名的程式。

GDPR

大部分組織都會處理可能是歐洲公民 (數據主體的數據,) 數據。 處理 ANY 數據主體的數據時,組織必須符合一般數據保護規定 (GDPR) 。 這適用於您直接擷取上述資料) 或數據處理器 (您代表數據控制器) 處理此資料 (兩個數據控制器。 雖然本節並未涵蓋整個法規,但會解決GDPR的一些重要要素,以協助取得組織正在重視GDPR的一些保證。

控制節點 16

藉由顯示下列專案,提供辨識項,示範如何遵守數據主體的許可權:

) 主體存取要求 (SAR) 促進:

可確認數據主體有權存取其個人資料,並可將主體存取要求 (SAR) 提交給貴組織的檔。

 

B) 資料探索和 SAR 履行:

證明貴組織能夠找出並擷取與所有系統和存放庫中個別數據主體相關的所有個人資料,以回應 SAR。

意圖

此控件的目的是要確保有足夠的機制讓數據主體對組織所持有的個人資料提出要求,而且合法要求的履行是徹底的。 (參閱 GDPR 文章 15) 。

指導方針

) 隱私權注意事項應包含如何建立 SAR 的詳細數據,其可能使用下列方法:

- 使用組織提供的 Web 表單

- 使用組織提供的電子郵件位址

- 使用組織提供的電話號碼/網路聊天

- 使用監督機關 (例如英國ICO)

就地要求方法的辨識項;螢幕擷取應該已足夠。

B) RoPA 或類似的檔可用來識別與數據主體相關的個人資料所在位置,不論是數位還是在文件系統中 (實體) 。

或者,電子探索練習可以達到相同的結果。

要求用來履行 SAR 之進程/工作流程的辨識項,以及如何判斷程式是徹底的,且不會遺漏與數據主體相關的任何個人資料的說明。

不符合規範:

) [隱私權注意事項]) 中通常不會提供組織網站 (的資訊。

B) 辨識項指出收集個人資料的程式並不徹底,或可能缺少技術詳細數據 (例如沒有針對資料庫指定的名稱/位置) 。

範例辨識項

) 下列範例說明可以提供哪些辨識項來涵蓋點 A) 。

– Web 窗體:

主體存取要求表單。

來源: 主體存取要求 - 英國警訊服務

- Email 位址/電話號碼:

要求 SAR 且不共用清單的動作清單和聯繫人資訊。

來源: 哪一個?隱私策略 - 哪個?

- Webchat:

透過電話或 Webchat 套用,並提供連結來提出主體存取要求。

來源: 向 HMRC 提出主體存取要求 - GOV.UK

- 透過監督機關 (例如 ICO) :

在線 ICO 主體存取要求表單。

來源: 提出您的主體存取要求 |ICO

B) 提供的辨識項精工詳細說明具有足夠技術詳細數據的工作流程或程式描述,可合理地用來履行特別行政區。

控制節點 17

提供隱私權注意事項,其中應包含所有必要的元素,如下所示:

) 如果適用,則為組織的身分識別和聯繫人詳細數據,以及數據保護長 (DPO) 。

B) 貴組織處理 (姓名、姓氏、客戶號碼、電子郵件地址、電話號碼等的個人資料類型 ) 。 此外,個人資料源 (例如個人資料來自) ,以防組織未直接從數據主體取得。

C) 處理個人資料的目的 () 。

D) 處理個人資料的合法基礎 (包括相關) 的合法) 。

E) 貴組織共用個人資料的物件。

F) 個人資料保留時間長度的詳細數據。

G) 數據主體權利的詳細數據:

  • 收到通知的許可權

  • 存取權

  • 修正許可權

  • 清除許可權

  • 處理許可權

  • 數據可移植性

  • 對象的許可權

  • 與自動化決策相關的許可權,包括分析

H) 關於將個人資料傳輸到第三個國家/地區以及採取保護措施的詳細數據。

我) 向監管機關提出抱怨的權利,提供監管機關 (例如英國ICO) 的聯繫人詳細數據。

意圖

其目的是要確保已發佈的隱私權聲明包含足夠的詳細數據,方法是包含上述元素和原則,並依 GDPR 第 3 章所述。

指導方針

根據控件 10.c,您必須發佈隱私權注意事項,其中涵蓋Microsoft 365 認證中包含的服務。 此隱私權注意事項必須包含上述醒目提示的項目和原則。

不符合規範:

請參閱控件 10.c。

範例辨識項

請參閱控件 10.c。

HIPAA (健康保險可移植性和責任法案)

1996 (HIPAA) 的健全保險可移植性和責任法案是適用於美國公民和醫療保健組織的聯邦法規。 請務必注意,這項法規也涵蓋美國以外的任何組織,以處理美國公民的醫療保健數據。 引進法規時,會要求美國健康與人力資源部門 (HHS) 制定法規,以保護特定健康資訊的隱私權和安全性。 某些組織可能會 (ePHI) 處理可能受保護健康情況信息的數據,這表示可由電子媒體個別識別的健康情況資訊、在電子媒體中維護,或以任何其他形式或媒體傳輸或維護。 在處理 ANY 數據主體的健康情況數據時,組織必須符合 HIPAA。

HIPAA 有兩項需要考慮的法規:「隱私權規則」或「個別識別健康資訊的隱私權標準」,其中概述保護特定健康情況資訊的國家標準,以及「保護受電子保護的健康狀態資訊的安全性標準」也稱為「安全性規則」。 後者會建立一組國家安全性標準,以保護以電子格式保留或傳輸的特定健康情況資訊。

從高階概觀中,「安全性規則」是「隱私權規則」所提供保護的實際實作。 其中概述「涵蓋的實體」必須實作的技術和非技術性措施,以確保個人「受電子保護的健康情況資訊」 (電子 PHI) 的安全性。 雖然本節並未涵蓋整個法規,但它可解決 HIPAA 的一些重要元素,以協助確保組織符合需求,且組織正在保護其處理的健康情況資訊。

控制節點 18

請提供可辨識的辨識項::

  • 貴組織內針對員工、承包商等的 HIPAA 和 HIPAA 處理有一項原則。

  • ISV 正在確保其所建立、接收、維護或傳輸之 ePHI 的機密性、完整性和可用性。

  • 防範任何合理預期的威脅,並危害 ePHI 的安全性或完整性。

意圖

此子點的目的是要確保組織已建立通訊協定,作為管理健康情況資訊、處理混亂和服務中斷,以及員工存取健康資訊和訓練的標準程式。 此外,組織應該維護並概述這些系統管理保護措施,作為其 HIPAA 安全性計劃的一部分。 這是遵守 HIPAA 法規的重要層面。

指導方針

提供組織建立的檔概述 HIPAA 原則和程式,即可證明這一點。 認證分析師會檢閱此項,以確保控件內提供的所有資訊都已解決。

範例辨識項

螢幕快照顯示 HIPAA 原則的快照集。 請注意:預期ISV會共用實際的支持原則/程序檔,而不只是提供螢幕快照。

具有定義、版本歷程記錄和用途的 HIPAA 原則檔。

HIPAA 原則檔,定義 ePHI 的機密性、完整性和可用性,以及防範威脅。

注意:預期ISV會共用實際的完整支持原則/程序檔,而不只是提供螢幕快照。

意圖

若要瞭解此子點的意圖,並確保符合安全性規則,「涵蓋的實體」必須先知道機密性、完整性和可用性的條款在 § 164.304 底下定義的方式:

  • 機密性:「數據或資訊無法提供給未經授權的人員或進程使用或揭露的屬性。」

  • 完整性:「數據或資訊未以未經授權的方式改變或終結的屬性。」

  • 可用性:「數據或資訊可在授權人員要求時存取及使用的屬性。」

這項需求的目的是組織會在IT基礎結構內實作存取、稽核、完整性和傳輸控制等技術保護措施/措施,以確保 ePHI 機密性,同時維護其完整性和授權使用者的可用性。

指導方針

辨識項可透過保護機制的組態設定來提供,這些機制可用來確保 ePHI 資料受到保護,符合控件需求。 這類機制可以包括訪問控制、緊急存取程式、RBAC、加密等。

範例辨識項:存取和完整性控件

下一個螢幕快照顯示有權處理 ePHI 儲存位置的個人授權存取清單存在,且會在 HIPAA 原則檔中維護。 此外,在核准清查清單之後的螢幕快照中,可以觀察到整個叢集的寫入存取權有限,只有系統管理員和資料庫維護分析師能夠在叢集上讀取和寫入。

HIPAA 原則檔,其中包含 ePHI 數據存取控制資料表,其中列出使用者、角色、部門、需要存取權、業務理由,以及核准日期檢查。

下一個從 Atlas Mongo 中的其中一個 ePHI 記憶體資料庫擷取的螢幕快照,示範只有已授權的使用者具有記載的存取權,而且所有帳戶都有唯一的使用者標識符,以確保責任。

第一個螢幕快照顯示 ePHI 的主要儲存位置/資料庫叢集。

列出 EPHI 數據叢集的 MongoDB 雲端叢集頁面,列在 Project 0 之下。

第二個螢幕快照示範核准的使用者只有已記載的角色和存取權。

列出 4 個測試使用者的 MongoDB 雲端資料庫存取使用者頁面。

接下來的兩個螢幕快照會顯示每個已指派角色以及所有相關聯許可權的更細微檢視,這些許可權與上述存取核准一樣。

列出自定義角色和範圍的 MongoDB 雲端資料庫存取頁面。

每個自定義角色都有一組許可權和存取範圍。

列出自定義角色和範圍的 MongoDB 雲端數據服務頁面。

最後,下一個螢幕快照會從網路觀點示範,只允許安全公司網路的授權IP範圍存取叢集。

MongoDB 雲端網路存取頁面。

範例辨識項:稽核控件

這些螢幕快照顯示已針對資料庫叢集實作記錄和警示。 第一個螢幕快照顯示警示已啟用。 請注意,預期提供的辨識項也會顯示根據組織的需求/實作所設定的警示規則。 第二個螢幕快照顯示正在啟用資料庫稽核。

MongoDB 雲端叢集頁面顯示 Contoso Project 0 測試專案的 1 個叢集。

顯示已選取資料庫稽核的 MongoDB 雲端數據服務頁面。

下一個螢幕快照顯示所記錄資料庫叢集的存取歷程記錄。 預期是根據稽核記錄設定警示,且任何未經授權的存取不符合預先定義的條件都會觸發警示。

具有 ePHI 資料叢集使用量圖表的 MongoDB 雲端資料庫部署頁面。

具有 ePHI 資料庫存取歷程記錄的 MongoDB 雲端數據服務頁面。

最後兩個螢幕快照顯示會為資料庫叢集產生稽核記錄,而且可以導出記錄以進行分析。

MongoDB 雲端記錄下載頁面,其中已選取具有下載選項的 ephi 數據叢集。

MongoDB 雲端記錄下載原始 MS 記事本頁面。

請注意,預期有一個程式可供分析所產生的稽核記錄,也必須提供檢閱程式的辨識項。 如果以程式設計方式達成此目的,則必須提供記錄擷取至所使用平臺/記錄解決方案之組態設定的螢幕快照,以及規則的螢幕快照以供檢閱。

範例辨識項:加密和傳輸控件

下一個螢幕快照示範記憶體位置預設會加密待用數據。 請注意,如果預設使用的平臺未執行加密,且您自己的加密密鑰正在使用中,則預期會適當地保護這些密鑰,並提供辨識項來證明這一點。

具有過去 6 小時區域和使用量統計數據之 ePHI 數據叢集概觀儀錶板的 MongoDB 雲端數據服務頁面。

MongoDB 雲端資源頁面組態加密概觀。

接下來的兩個螢幕快照示範記憶體位置預設會加密傳輸中的數據。 第一個螢幕快照示範已啟用具有「讀取和寫入」許可權的數據 API。

已啟用數據 API 和 ePHI 資料叢集數據源的 MongoDB 雲端數據服務頁面。

端點的 SSL 掃描會示範傳輸中的數據是透過 TLS 1.2 加密。

顯示整體 A 評等的 Qualys SSl 報告。

範例辨識項:可用性和復原控件

下一個螢幕快照示範資料庫叢集會復寫到三個區域,以確保可用性。 Mongo Atlas 預設會完成此作業。 此外,備份已啟用且為作用中。

具有 ePHI 數據叢集概觀的 MongoDB 雲端數據服務頁面,其中顯示區域、標籤和備份列為 [作用中]。

下列螢幕快照顯示叢集的備份儀錶板,也示範已建立快照集。

具有檢視篩選條件之 ePHI 資料叢集備份儀錶板的 MongoDB 雲端數據服務頁面。

接下來的兩個螢幕快照示範備份原則已就緒,可在 PIT) (不同時間點執行排程備份。

具有 ePHI 數據叢集備份原則時間、頻率和保留設定的 MongoDB 雲端數據服務頁面。

以下指出,快照集和時間點還原 (PIT) 都有保留原則。

具有快照集時間、備份原則頻率和保留、時間點還原設定的 MongoDB 雲端備份數據服務頁面。

意圖

此子點的意圖與為了確保彈性和延展性而開發的安全性規則一致,因此「涵蓋的實體」可以實作符合實體大小、組織結構及其特定風險,以及其風險偏好的原則、程式和技術解決方案。 從實際的觀點來看,這表示所實作的適當安全性措施將取決於「涵蓋實體」業務的性質,以及其大小和資源。

每個組織都必須進行全面的風險分析,以找出電子 PHI 的機密性、完整性和可用性的潛在風險和弱點。 透過這項風險分析,組織接著可以實作適當的安全性控制措施,以降低這些已識別的風險。

指導方針

可透過風險分析輸出來提供辨識項。 透過在線平臺執行和維護風險分析時,應提供整個輸出的螢幕快照。

範例辨識項

下一個螢幕快照顯示風險評估程式的快照集,後面接著風險分析,其執行目的是為了判斷控件正確實作和運作的程度,以保護 ePHI。 第二個螢幕快照顯示風險評估中所識別風險的風險分析,以及為了降低風險層級而實作的補償控制和風險降低。

範例 1 – HIPAA 原則內的風險評估程式快照集,以及執行的風險分析

具有個別考慮數據表的 HIPAA 安全性規則風險分析。

HIPAA 定義和風險計算數據表檔。

HIPAA 原則檔列出安全性考慮,包括成熟度、風險層級、可能性、影響、後續步驟。

注意:此螢幕快照顯示風險分析檔的快照集,這隻是範例,且預期ISV會共用實際檔,而不只是提供螢幕快照。

範例 2 – HIPAA 原則內的風險評估程序螢幕快照,以及 (Confluence Cloud Platform 中維護的風險分析)

具有安全性風險分析的 Confluence HIPAA 原則頁面。

具有定義的 Confluence HIPAA 原則頁面。

第二個螢幕快照顯示風險評估中所識別風險的風險分析,以及為了降低風險層級而實作的補償控制和風險降低。 我們可以在 Confluence 雲端平臺中看到此專案存在並加以維護。

Confluence 風險分析報告第 1 頁。

Confluence 風險分析報告第 2 頁。

控件 No. 19

請提供您 (ISV) 的辨識項:

  • 防止合理預期的使用或洩漏隱私權規則不允許的這類資訊;和

  • 確保其員工符合安全性規則。

  • 164..308 下的數據備份和災害復原計劃 () (7) (ii) (A) ,以及 164.308 () (7) (ii) (B) 。

Intent

隱私權規則會定義法律所涵蓋的受保護健康情況資訊 (PHI) 的哪些部分,並禁止不當使用和揭露 PHI。 此子點的目的是組織必須將電子 PHI 的存取和使用限制為僅限需要它以達到授權目的的人員,而且必須遵守最低必要規則,因此必須使用或只揭露達成其預定目的所需的最低電子 PHI 數量。

必須結合技術和系統管理保護措施,以限制 ePHI 的使用,並確保 ePHI 洩漏的風險降低。

指導方針

提供的辨識項需要顯示技術保護措施,例如用來保護電子 PHI的技術和機制,以及組織控制如何檢查這類數據的存取和移動。

範例辨識項

下一個螢幕快照顯示 Microsoft Purview 資料外洩防護 (DLP) ,這是一個整合式平臺,可讓組織從單一集中位置管理其 DLP 原則。

您可以觀察到下方已啟用「美國 HIPAA 增強」原則,這可防止使用者將敏感數據貼到特定網站,包括個人電子郵件、產生 AI 提示、社交媒體網站,以及透過支援的網頁瀏覽器存取時的更多功能。

Microsoft包含 GDPR 和 HIPAA 明細專案的 Purview 原則頁面。已選取 HIPAA,且側邊快顯具有狀態、描述、位置和原則設定詳細數據

下一個螢幕快照提供原則的更完整概觀,包括套用範圍。 此原則會設定為 SharePoint、裝置、OneDrive 等位置中的所有帳戶。

Microsoft包含 GDPR 和 HIPAA 明細專案的 Purview 原則頁面。

選取 [編輯原則] 選項時,會顯示特定組態的更細微檢視。

Microsoft Purview 自定義進階 DLP 規則頁面,並已核取 [內容符合 US HIPAA] 增強的方塊。

接下來的兩個螢幕快照顯示必須符合才能套用原則的內容定義和條件。

Microsoft Purview 編輯規則中,條件包含組名和選取的敏感性信息類型。

此原則涵蓋各種敏感數據類型,以及一組分類器。

Microsoft Purview 編輯規則,敏感數據類型。

下一節顯示符合先前螢幕快照中顯示的條件時,所設定要採取的動作。

Microsoft Purview 編輯規則設定,將動作套用至特定活動。

下列螢幕快照顯示 DLP 原則已設定為防止其使用者在支援的瀏覽器上複製和貼上敏感性資訊,例如從組織內部資料庫 (PII) 的個人標識資訊、聊天機器人和社交媒體網站。

Microsoft Purview DLP 原則設定。

最後,使用者通知會設定為在處理 ePHI 數據時通知使用者,並提供指引給使用者。

Microsoft Purview 通知設定規則編輯。

下列螢幕快照顯示在事件發生時產生警示的設定面板。

Microsoft開啟 Purview 警示設定。

意圖

此子點的目的是組織必須訓練其員工如何安全且適當地處理電子 PHI,而且必須強制執行原則和程式,以確保符合安全性規則。

指導方針

提供的辨識項必須示範 HIPAA 定型是針對如何處理 ePHI 以及出席和訓練完成的記錄存在而執行。 在適用的情況下,原則檔和所使用的訓練教材可以支援此功能。

範例辨識項

下列範例顯示可能提交的辨識項,以示範適當的 HIPAA 訓練符合原則。

下一個螢幕快照顯示 HIPAA 原則的快照,其中包含概述定型需求的特定區段。 請注意,這隻是範例,而不是完整的檔/實作,預期ISV會有適用於其組織的已建立程式。

範例 1 – 透過系統管理程式進行 HIPAA 用戶訓練

用於處理 ePHI 的安全性意識訓練檔。

在下一個螢幕快照中,課程概觀投影片會顯示課程目標的摘要。 如果訓練是內部建置的,則必須提供訓練教材以供檢閱,請注意,必須提交完整的材料,而不只是摘要的螢幕快照。

HIPAA 訓練課程目標概觀。

下列螢幕快照顯示參與訓練之員工的出席記錄。 此記錄也會顯示通過分數以及下一個定型排程日期。

安全性意識員工訓練記錄。

第二個範例示範如何使用 Microsoft 365 Defender 來設定和啟動訓練活動。

範例 2 – 透過 Microsoft 365 Defender 攻擊模擬平台訓練 HIPAA 使用者 (所有使用者)

Microsoft 365 Defender 訓練頁面。

上一個螢幕快照顯示 HIPAA 安全性訓練活動、總持續時間以分鐘為單位,以及完成狀態。 下一個螢幕快照提供已指派訓練的使用者概觀,以及示範成功完成的訓練狀態。

Defender 攻擊模擬訓練頁面。

範例 3 – 透過 Microsoft 365 Defender 攻擊模擬平臺進行 HIPAA 使用者訓練 (個別使用者)

Microsoft Outlook 電子郵件通知,讓使用者知道安全性小組已指派訓練。

雖然上一個範例著重於示範所有使用者都已完成年度訓練活動,但最後一個範例會顯示示範一位員工完成的目標辨識項。

Microsoft Outlook 電子郵件通知共用連結到訓練、所需訓練名稱、持續時間和到期日。

您可以在先前的兩個螢幕快照中觀察到,一旦訓練活動啟動,每位員工都會收到一封電子郵件,確認訓練指派和到期日,以及指派的模組、持續時間等。

使用電子郵件通知中可用的連結,下列螢幕快照顯示使用者的 [訓練指派] 頁面,以及現在已完成的兩個模組。

Defender 訓練指派頁面。

意圖

在 HIPAA 安全性規則下,數據備份計劃和災害復原計劃是處理 ePHI) (電子保護健康情況資訊的任何「涵蓋實體」的必要專案。 這類計劃是應變策略的一部分,旨在確保在發生緊急或其他情況時,ePHI 的可用性和安全性會損害包含 ePHI 的系統。

數據備份計劃的目的是要建立及維護可擷取的相同 ePHI 複本,這也應該包含定期測試備份,以確保數據可以復原。 災害復原計劃的目的是要在發生災害時還原任何可能遺失的數據,這應該指定還原數據存取權時必須採取的步驟,包括應如何從備份還原檔案。

指導方針

請提供災害復原計劃/程式的完整版本,其中應涵蓋備份計劃和復原計劃。 如果是在數位版本中,請提供實際的 PDF/Word 檔;或者,如果透過在線平臺維護程式提供 PDF 導出,或因為平臺的限制而無法匯出,請提供涵蓋整個原則的螢幕快照。

範例辨識項

下一個螢幕快照顯示 HIPAA 安全策略的快照集,其中包含一般和高階備份程式和災害復原計劃的概觀。

數據備份和災害復原檔第 1 頁。

數據備份和災害復原檔第 2 頁。

注意:此螢幕快照顯示原則/程序檔的快照集,這隻是範例,且預期ISV會共用實際的完整支持原則/程序檔,而不只是提供螢幕快照。

書籍

2018 (2018 年) Blue Team 手冊:事件回應版本:網路安全性事件回應回應程式的壓縮字段指南。 第二版,發行者:CreateSpace Independent Publishing Platform。

參考

從檔Microsoft取的影像/文字

深入了解