您的組織中的敏感數據是否安全？ PII 和 PHI 合規性測試

如果您的組織定期處理敏感數據，您必須實施數據安全合規性策略，以保護數據所屬的個人以及您的組織免於違反任何联邦法律（例如 HIPPA、GDPR 等）。 這會影響醫療保健、銀行、政府、法律等行業的組織……實際上是任何處理敏感數據的組織。

我們正在談論 PII（個人身份信息）和 PHI（受保護的健康信息）. PII 示例 -

• 社會安全號碼
• 銀行賬戶
• 全名
• 護照號碼等

PHI 示例 -

• 健康記錄
• 實驗結果
• 醫療賬單等，包括個人標識符

保護敏感數據的方法

一些客戶將他們的方法描述為您可能會在看過的電影中想像的場景……想像一群持有所需安全許可的人擠在一個沒有窗戶的上鎖房間裡，手動檢查報告打印輸出以確保敏感信息不包括在內。 雖然這會產生戲劇性的電影場景，但它並不是測試敏感信息報告的最萬無一失的方法，也不是最有效的方法。 並且由於需要遠程 Covid-19 勞動力，這在目前根本不可行。

我們已經幫助我們的幾個客戶實現了自動化測試的強大功能，以動態測試他們的 Cognos 報告輸出。 這種測試策略會儘早捕獲報告，一旦它們不合規，並且在它們最終投入生產並落入壞人之手之前。 知道離您最近的社會保障辦公室在哪裡總是一個好主意，例如 內華達州社會保障辦公室，如果最壞的情況發生，因為您當地辦事處的團隊知道如何處理這種情況。

在開發週期早期進行測試的價值

在開發階段的早期檢測數據安全漏洞可以幫助避免未來政府施加的任何罰款和製裁。 根據 健康和人類服務部迄今為止，民權辦公室 (OCR) “已在 75 起案件中解決或處以民事罰款，總金額為 116,303,582.00 美元。” 每箱超過 1.5 萬美元！ 並且根據 HIPAA期刊 “未能執行組織範圍的風險分析是導致經濟處罰的最常見的 HIPAA 違規行為之一。”

除了避免政府施加的處罰外，在開發週期的早期發現錯誤通常很重要，因為這是解決問題更容易、更便宜的階段。 因此，本練習的主要目標是使用 MotioCI回歸測試的強大功能可以輕鬆識別此類錯誤，從而在開發週期的早期防止它們發生。

讓我們來看看如何設置測試。 我們將從設置 Cognos 環境開始，然後解釋如何為我們的示例設置 PHI 和 PII 數據的自動化測試。 我們還將在生產環境中使用這些相同的測試用例，以提高合規性和安全性檢查水平。

PHI 和 PII Cognos 環境設置

我們的示例 Cognos 環境（圖 1）由幾個報告組成，每個報告都包含 PII 和 PHI 敏感數據（例如診斷代碼、處方、社會安全號碼、患者姓氏等）和最低限度的敏感數據（例如患者名、訪問日期等）。

有兩個 Cognos 角色， 允許PII 和 允許PHI，確定在執行報告時是否呈現任何敏感數據。 （表格1）

表 1：控制敏感數據再現的 Cognos 角色。

例如，一個用戶沒有我們的 Cognos 角色，他們的“Patient Daily Intake”報告應該是這樣的（圖 2）：

如您所見，所有 PHI 和 PII 數據都被完全混淆，因為用戶缺乏“AllowPHI/PII”角色的成員資格。

現在，讓我們使用屬於“AllowPII”角色的用戶運行報告，這意味著我們希望該用戶只能查看 PII 數據（圖 3）：

您可以在此處看到社會安全號碼和姓氏列都正確顯示，沒有進行任何編輯。

到目前為止，我們已經瞥見了我們神話般的診所的 Cognos 環境，到目前為止我們所看到的只是 Cognos 基於角色的數據安全性，你們中的許多人可能已經在自己的​​ Cognos 環境中實施了該安全性。 這將把我們帶到敏感數據希望的承載者永遠不必面對的主要問題：

如果經過一些繁重的開發工作，一些敏感數據漏掉並開始顯示給不應該看到的用戶怎麼辦？

錯誤當然在所難免，所以稍後在博客中我們將使用 MotioCI回歸測試的強大功能可以密切關注我們的報告，以確保私人數據永遠不會暴露給非預期的受眾。

了解 Cognos 的合規性測試

如上一節所述，報告創作或建模中的簡單錯誤可能會導致 Cognos 環境中報告輸出中出現不需要的行為。 如果這些變化未被發現，它們就有可能潛入您的生產環境。 更糟糕的是，如果這些不需要的更改包括將私人數據暴露給非預期的受眾。

例如，一個用戶不是其中任何一個的成員 允許PII or 允許PHI Cognos 角色不應在我們的示例 Cognos 環境中看到 PII 或 PHI 私有數據。 但是，正如您在下面看到的（圖 4），FM 模型中的一個簡單更改已導致診斷描述和患者 SSN 號碼暴露給此類用戶，這嚴重違反了聯邦 HIPAA 安全規則。

在搬東西之前 MotioCI，我們將首先在我們的 Cognos 環境中創建三個測試用戶，並按以下方式將他們分配給我們的兩個角色（表 2）：

表 2：使用分配的角色測試 Cognos 用戶帳戶。

這些測試用戶帳戶稍後將用於 MotioCI 用於對包含敏感 PII 和 PHI 數據的報告進行回歸測試。 我們的測試結果將取決於每個用戶根據其角色成員身份對敏感數據的可見性。

現在我們已經設置了我們的測試用戶，我們準備好配置我們的回歸測試 MotioCI.

MotioCI 環境設置

我們的示例環境由開發、UAT 和生產 Cognos 實例組成。 雖然 MotioCI 允許我們同時登錄所有三個，我們將在三個不同的階段開始在開發環境中設置回歸測試。

關於回歸測試 MotioCI，安 斷言 是測試用例對您的對象執行的單獨檢查或“測試” MotioCI 實例，例如報表、文件夾或包。 將執行測試敏感數據報告輸出工作的斷言稱為 敏感數據合規性測試 （圖 7）。 這是我們為本練習組合在一起的自定義斷言。 下面你可以看到 斷言類型 它基本上充當了在整個我們的測試用例中復製到測試用例的主要模板 MotioCI 環境。 稍後會詳細介紹。

一些斷言提供了一些用戶可調整的功能 提示窗口. 在這裡，您可以更改您希望給定斷言測試任何給定 Cognos 報告的方式。 下面的圖 8 顯示了 提示窗口 我們將用於測試包含敏感數據的 Cognos 報告的斷言。

圖 8 中頂部突出顯示的部分顯示了 PII 和 PHI 敏感數據的測試選項。 這允許您進行斷言測試報告是否必須顯示或隱藏其 PII 或 PHI 數據。 當我們開始為三個測試用戶中的每一個創建測試用例時，我們將對這兩個選項進行更改。

圖 8 中間突出顯示的部分顯示了我們報告中包含 PHI 敏感數據的列的名稱。 儘管我們的示例環境由名稱為 ICD10 診斷代碼、診斷描述、過程和 Rx 的列組成，但您當然可以修改此列表以滿足您的需要。

最後，圖 8 中底部突出顯示的部分顯示了電子郵件選項。 在失敗的情況下，此斷言將向此部分中配置的收件人發送詳細的電子郵件消息。

階段 I：僅顯示 PII 的報告

讓我們在下面創建一個項目 產業發展  實例在 MotioCI 並稱之為 僅允許 PII. 我們可以通過首先右鍵單擊 產業發展  實例節點 MotioCI 導航樹並選擇 新增專案 選項（圖 9）。

 添加項目嚮導 將帶您通過一些步驟來選擇項目所需的路徑。 在我們的示例中，所有包含 PII 和 PHI 敏感數據的報告都存在於 患者數據 文件夾。 檢查此父文件夾將自動包括所有基礎報告（圖 10 和 11）。

由於該項目中的所有報告都應允許顯示所有 PII 數據並混淆所有 PHI，因此在添加任何測試用例之前，我們需要使用正確的設置配置斷言類型（圖 12）。 這意味著在同一個斷言上設置兩個測試選項 提示窗口 我們之前在圖 8 中看到的。

現在我們準備將我們的測試用例添加到我們的報告中。 為此，請右鍵單擊項目節點（即 僅允許 PII 項目）在 MotioCI 並選擇 生成測試用例 選項（圖 13）。 這將啟動生成測試用例嚮導，這將允許我們為項目中的所有報告創建大量測試用例。

 生成測試用例 嚮導還允許我們為要執行測試的測試用例選擇輸出格式。 對於我們的示例環境，我選擇了 CSV 輸出。 該嚮導還將讓我們選擇每個測試用例將用於實際測試工作的斷言。 對我們來說，這將是 敏感數據合規性測試 斷言。 您可以看到下面突出顯示的這兩個選項（圖 14）。

單擊“確定”後，您將返回到 MotioCI 主屏幕，您將能夠在其中看到我們的所有報告，每個報告都包含一個測試用例，每個報告都包含我們的單個斷言（圖 15）。

最後，我們需要配置所有測試用例以使用正確的 Cognos 用戶（例如，我們在 Cognos 中配置之前在 Cognos 中配置的三個測試用戶之一）來執行它們的父報告 MotioCI）。 因為對於這個項目，我們正在測試以確保 PHI 內容是 任何監管機構都不批准 顯示給只允許查看 PII 數據的用戶，我們需要設置所有測試用例來運行 測試用戶A （見表 2）。

起初這聽起來像是一項乏味的任務，但幸運的是我們可以將用戶設置在項目級別，然後該項目中的所有底層測試用例都會繼承該用戶。 為此，在左側導航樹中，我們將單擊項目節點 ( 僅允許 PII 項目），然後選擇 項目設定 在屏幕中間。 然後，根據 測試 部分，我們將看到更改憑據的選項（圖 16）：

點擊之後 編輯 按鈕位於前面 證書 選項，我們將看到 編輯憑據 窗戶。 我們將繼續輸入憑據 測試用戶A （圖17）。

我們現在看到新用戶反映在 測試 條的規定， 項目設定 選項卡（圖 18）。

現在我們已準備就緒，可以執行所有測試用例。

為此，我們將單擊 僅允許 PII 項目，在中間我們將看到 測試用例 選項卡，顯示位於項目中的所有測試用例。 由於我們還沒有執行任何操作，我們將看到 Status 顯示為 無結果. 要執行所有測試用例，我們將單擊 跑 按鈕，然後選擇 全部運行 選項（圖 19）。

MotioCI 現在將執行所有測試用例，並在完成後向我們展示結果（圖 20）。

如您所見，我們所有的測試用例都成功了，除了 住院病人 報告。 那麼，讓我們來看看結果。 為此，我們將點擊位於下方的藍色時間戳 結果 列並查看圖 21 中的詳細信息。

下 斷言結果 我們現在可以看到我們的報告違反了 PHI 合規要求。 我們可以從以下位置下載 CSV 報告輸出 測試用例輸出 單擊 CSV 圖標（圖 21）。

正如您在我們的報告中所見（圖 22），除了 TestUserA 可以訪問的 PII 數據之外，我們還能夠看到 PHI 程序數據，該數據使報告違反了聯邦 HIPAA 安全規則。

如果您還記得斷言設置窗口，我們也應該收到有關此失敗的電子郵件通知。 讓我們看看它是什麼樣子的（圖 23）：

在這一點上，我們完成了測試以確保 PHI 數據對用戶隱藏而不需要 允許PHI Cognos 角色。 現在我們準備將我們的測試擴展到對缺乏所需的用戶隱藏的 PII 數據 允許PII Cognos 的作用。

階段 II：僅顯示 PHI 的報告

在創建新項目之前，首先讓我們編輯主斷言的選項，以確保它現在測試所有要隱藏的 PII 和要顯示的所有 PHI（圖 24）。

現在我們的斷言都配置好了，我們現在準備好創建新項目和我們的測試用例。 為此，我們將按照與“第一階段”相同的步驟創建一個名為 僅允許 PHI. 另外，我們不要忘記添加憑據 測試用戶B 作為項目用戶。

完成所有配置步驟後，我們將執行所有測試用例，就像我們在階段 I 中所做的那樣。在我們的示例環境中，這次我們有一個不同的報告，它似乎違反了 HIPAA（圖 25）。

對測試用例結果的進一步調查 患者每日攝入量 報告顯示，我們的報告向非預期受眾顯示了患者社會安全號碼（圖 26）。

下載並打開 CSV 文件將進一步確認我們的測試結果（圖 27）：

但是，正如您在圖 27 中看到的，我們的報告通過僅顯示首字母來正確屏蔽了患者姓氏列（也是 PII）。

至此，我們的環境應該已經利用 Cognos 基於角色的數據安全性實現了對 PHI 和 PII 敏感數據的全面回歸測試。 我們的測試用例將分別執行其父報告並根據其基礎斷言中的測試配置集分析輸出，並告訴我們是否有任何報告不符合規定。

當然，我們的測試環境與您的環境中可能擁有的環境之間最重要的區別之一是大小。 一個典型的 Cognos 環境很可能有成百上千甚至上千個報告，並且像我們在小樣本環境中所做的那樣同時執行所有這些報告，可能會對 Cognos 的性能造成影響。 和 MotioCI的測試腳本，但是，您可以安排您的測試用例在非工作時間以較小的批次運行，從而確保您的 Cognos 環境在高流量時間獲得最佳性能。

開發過程中的良好測試實踐

但是，在計劃的運行時間之間，您仍然可以根據需要手動運行任意數量的單個測試用例。 一個很好的例子是在開發報告時，您可以運行測試用例以確保您的更改沒有造成任何 HIPAA 違規。

自動化 Cognos 測試用例

返回上一頁 MotioCI，在導航樹上，我們展開我們創建的項目之一以顯示其內容。 這應該會顯示一個名為的節點 測試腳本. 展開它會顯示一組在您第一次創建項目時自動創建的測試腳本（圖 28）。

根據定義，a 測試腳本 是項目的一個組件，它根據指定的標準選擇屬於項目的測試用例。 您可以安排測試腳本或手動運行它們。 當您運行測試腳本時， MotioCI 運行所有符合腳本標準的測試用例。

在我們的例子中，我們希望按計劃設置所有測試用例。 所以為了做到這一點，我們點擊 全部 導航樹中的測試腳本，然後單擊 測試腳本設置 選項卡位於屏幕中間（圖 29）。

接下來，我們選擇 新增時間表 選項。 在這裡，我們現在可以為我們的測試腳本設置時間表。 我將繼續讓我們的測試用例在每週一到週五的凌晨 3:00 運行（圖 30）。

就是這樣！ 我們現在可以每天早上檢查我們的電子郵件收件箱，以了解我們的任何報告是否不合規。 我們還可以通過簡單地單擊 更改或失敗 測試腳本和所有失敗的測試用例將在 測試用例 面板（圖 31）。

結論

不遵守 HIPPA、GDPR 和其他有關敏感信息和隱私的聯邦法規的成本可能非常高，事實上，每個違規案件大約 1.5 萬美元。

通過實施自動化測試策略來處理合規性測試，您將擁有額外的安全層，並在遵守法律的情況下高枕無憂。 除了隱私數據要求之外，自動化測試可以使所有類型的行業和您的組織想要實施的任何類型的測試要求受益。

我們能幫你什麼嗎？

如果您想觀看有關此博客主題的網絡研討會， 在這裡訪問它。 或者， 聯繫我們 (contact us) 進一步討論您的 Cognos 測試問題。