參考連結

前言

身為一個想要做資料庫與AP之間安全論文的研究生，如果想要套用零信任架構上去，首先就必須了解各種文件上面談到零信任應該滿足的要求或是符合零信任的架構。同時因為是要找AP與資料庫之間的安全，而零信任卻是更全面地談及不同層面應該滿足的要求，像是針對使用者的身份驗證等。因此需要認清楚自己的目標對象怎麼著中在AP與資料之間的安全，為此我將整理的要求和架構進行分類，哪些是針對User與AP，哪些可以用於AP與AP就需要區分出來。

因此這篇文章的目的是在整理以下三篇文章：

因為這篇主要是我自己整理的內容，所以可能內容還沒有更加的統整，如果想直接看總結，建議查看零信任架構的方法。

NIST 零信任假設

以下內容主要出自於 NIST SP 800-207 大概看看就好。

以下是零信任架構的假設前提，我們應該要：

  1. The entire enterprise private network is not considered an implicit trust zone.
    • 企業內部網路不能被視為隱性信任區
  2. Devices on the network may not be owned or configurable by the enterprise.
    • 裝置可能不是由企業擁有或設置管理的（ex. BYOD）
  3. No resource is inherently trusted.
    • 沒有資源本身是受信任的，在授予資源存取前，每項資產都必須通過 PEP 評估其安全狀況
  4. Not all enterprise resources are on enterprise-owned infrastructure.
    • 不是所有企業資源都位於企業擁有的基礎設施上。
    • 資源包括遠程企業主體以及雲服務。
    • 企業擁有或管理的資產可能需要使用本地（即非企業）網路進行基本連接和網路服務（例如，DNS解析）。
  5. Remote enterprise subjects and assets cannot fully trust their local network connection
    • 遠端存取者應假設本地網路環境是不安全的。
    • 資產應該假設所有流量都被監控並有可能被修改。
    • 所有連線必須是被驗證獲授權的。
  6. Assets and workflows moving between enterprise and non-enterprise infrastructure should have a consistent security policy and posture.
    • 在企業基礎設施和非企業基礎設施之間移動的資產和工作流程應該具有一致的安全策略和姿態。

NIST 零信任原則 ZTA Tenets

以下內容主要出自於 NIST SP 800-207

對於NIST SP 800-207中提出的零信任原則所指的對象通常不限定於使用者、應用或服務，主要提出作為存取者發出對於資源的請求時，所應滿足的原則以符合零信任，而對於應用程式或服務在存取資源時的特定情況並沒有具體的說明。

因此這裡我會多補充一些關於應用程式與資源之間，應如何做到滿足零信任的原則。

Tenet 1. All data sources and computing services are consider resources.
> 原則1: 企業內部的數據資源或是計算服務都需要被視為受保護的資源

感想：

  • 已資料庫來說，資料庫可以視為被保護的資源之ㄧ。
Tenet 2. All communication is secured regardless of network location.
> 原則2: 不能只是根據網路位置就授予信任，內部的存取請求所經歷的安全要求與外部請求必須相同

感想：

  • 不會預設有信任應用程式，所有存取資料庫的應用程式應該都要持續授權與驗證。
Tenet 3. Access to individual enterprise resources is granted on a per-session basis.
> 原則3: 企業內部的資源存取必須是基於每個連線的基礎

內容：

  • 在請求被授權前應該經過衡量並滿足執行任務的最小權限原則
  • 值得注意的是，提到不一定要直接在啟動會話或執行與資源的交易之前才授予權限，相反，企業可以在使用者提出存取請求之前，先評估這個使用者的身份和信任程度，並根據這些評估結果授予相應的權限。這樣做可以在使用者真正需要存取資源時，節省時間並簡化存取流程。

感想：

  • 應用程式與資料庫在建立連線時，應該要能夠根據應用程式的身份進行驗證。
  • 並確保該應用程式執行工作的權限應屬於該應用程式的資料存取範圍，這表示對於每個存取資料庫的應用程式都要有清楚的身份區別，以辨別該應用程式可以存取的資源。
Tenets 4. Access to resources is determined by dynamic policy - including the observable state of client identity、 application/service、 and the requesting asset - and may include other behavior and environmental attributes.
> 原則4: 資源請求應該經由動態政策來決定，這包含觀察客戶端應用和服務的身份、請求狀態、環境屬性、存取行為等

內容：

  • 請求資產狀態：可以包含裝置屬性像是軟體版本, 網路位置, 請求時間日期, 觀察的歷史行為, 安裝的憑證
  • 行為屬性包含但不限於：自動化的存取者分析, 裝置分析, 使用模式偏差。
  • 環境屬性可以包含：請求者網路位置, 時間, 主動攻擊報告。
  • Policy：是基於屬性的存取規則集合，屬性由組織assign給subject, data asset或application。

感想：

  • 應該要設計出一存取控制政策應該要能包含各種不同的屬性，如上述內容所提到的。
Tenets 5. The enterprise monitors and measures the integrity and security posture of all owned and associated assets.
> 原則 5. 不再預設信任任何資產，而是持續監控和評估所有資產的安全狀態

內容：

  • 企業應該建立一個持續性診斷和強化CDM來監控裝置和應用程式的狀態，並根據需要應用補丁/修補程式。
  • 建立健全的監控和報告系統，提供有關企業資源當前狀態的可行數據。

感想：

  • 對於存取資料庫的應用程式來說，應該也要持續性的監控該應用程式所使用的第三方套件版本、補丁等，作為該應用的狀態。
  • 同時也要監控應用程式執行的裝置環境是否正常。
Tenet 6. All resource authentication and authorization are dynamic and strictly enforced before access is allowed.
> 原則 6. 資源驗證和授權是動態的，必須在允許訪問之前嚴格執行

內容：

  • 這是一個不斷循環的過程，包括獲取訪問權限、掃描並評估威脅、適應變化，以及持續重新評估通信中的信任。
  • 這種方法確保在任何時候只有經過授權的用戶才能訪問企業資源。
  • 實施零信任架構的企業預期會擁有身份identity、憑證credential和訪問管理access management（簡稱ICAM）以及asset management system資產管理系統。
  • 在用戶交易過程中，不斷進行監控，可能需要重新驗證和重新授權。
  • 這是根據政策（例如基於時間的重新驗證、新資源請求、資源修改、檢測到異常用戶活動等）來定義和強制執行的。
  • 政策旨在在安全性、可用性、易用性和成本效率之間取得平衡。

感想：

  • 首先任何應用程式在進行資料庫存取時，都必須經過嚴格的驗證與授權，只有經過授權的應用程式才能訪問資料庫。
  • 在存取資料的過程中，都應該持續性地進行監控，可能需要根據存取的資源不同，進行重新驗證與授權。
Tenets 7. The enterprise collects as much information as possible about the current state of assets、 network infrastructure and communications and uses it to improve its security posture.
> 原則 7. 應收集資產的安全狀況、網絡流量和訪問請求等，收集到的資料將用於改進政策制定和執行，以提升資安策略

感想：

  • 資料庫、應用程式的安全狀況、網路流量、請求內容、請求結果應該要做紀錄並收集。
  • 這些收集的資料可以用於改進政策制定和執行，以提升資安策略。

NIST 零信任架構的方法

我個人個觀點，若是要實施零信任架構於應用程式和資料庫之間，則應該採用Using Enhanced Identity Governance的做法作為本研究的架構。

NIST SP 800-207主要題中三種作為零信任架構的方法：

  1. Using Enhanced Identity Governance 使用增強的身份管理
    • 說明：一種以身份為核心，基於身份和屬性制定資源訪問政策。
    • 感想：在放行應用程式的請求至資料庫前，應該要先識別發出請求的應用程式為何？健康狀況？應用程式的第三套件是否有重大資安缺漏？再近一步判斷其擁有得權限，才能放行請求。
  2. Using Micro-Segmentation 使用微分割
    • 說明：將資源放置在受到網關安全元件保護的獨立網絡段，保護資源免受未經授權的訪問。
    • 感想：使用微分割的做法主要透過網路安全元件如防火牆等，透過將網段分區的方式，在每個網段透過這些元進行控制與監控。但因為本研究的目的介於應用程式與資料庫之間，為了能夠更清楚的取得兩者之間的資料流，因此不適合使用此方法。
  3. Using Network Infrastructure and Software Defined Perimeters 使用網絡基礎設施和軟體定義的周界
    • 說明：使用網絡基礎設施實現ZTA，可能包含軟體定義網絡和意圖為基礎的網絡概念，PA充當網絡控制器來設置和重新配置網絡。
    • 感想：主要透過類似SDN軟體定義網路的方法來進行網路流量的控制，主要在OSI模型中的網路層（Network Layer），這一層負責處理網路之間的路由和轉發，以及封包在不同網路之間的傳遞，因此應用層級的細節不可見。由於無法深入了解應用程式與資料庫之間的細節，若連線設定不當或未能滿足應用程式的安全需求，可能會導致資料外洩或遭受攻擊。

NIST 零信任架構部署種類

可以從以下架構看到，NIST SP 800-209 中的零信任架構主要都使以使用者為主體，透過裝置來進行資源存取。

比較項目
Agent/Gateway Enclave Gateway Resource Protal App Sandboxing
有無Agent 有 有 無 無
PEP位置 單一資源前 資源集或私有雲前/入口 資源集或私有雲前/入口 裝在資源上
適用情境 有裝置管理計畫之企業 具有Legacy應用程式或on-premises數據中心之企業 適用於BYOD環境，不需要再客戶端設備安裝軟體元件。 適用無法掃瞄客戶資產(裝置)是否存在漏洞。

Device Agent / Gateway Model

  • 在這個模型中，PEP (Policy Enforcement Point) 被分成兩個部分它們分別位於「資源」上或直接作為「資源前端」的一個組件。
    • 第一部分是"Device Agent": 它被安裝在企業發放的資產上，用於協調連接。這個代理程式負責將一些（或全部）流量導向適當的 PEP 以便進行請求評估。
    • 第二部分是"Gateway": 它被放置在每個資源的前端，使資源只與這個網關進行通訊，本質上充當資源的代理。這個網關負責與政策管理員進行通訊，並僅允許政策管理員配置的批准通訊路徑。
  • 政策管理員PA 和 政策引擎PE 可以是企業本地設備或雲端服務。
  • 適用情境：
    • 適合使用在已建立堅固裝置管理計畫的企業，同時擁有可以與網關進行通訊的專屬資源。這個模型也適合不希望實施BYOD政策的企業。
    • 唯有透過裝置代理（device agent），才能取得存取權限，而裝置代理可以安裝在企業擁有的資產上。

Enclave-Based Deployement

“Enclave” 是一個安全隔離的計算環境，可以保護敏感數據和應用程式免受未經授權的存取或攻擊。

  • 是 Device Agent / Gateway Model 的一種變體，企業的資產（裝置）透過使用Agent設備代理連接到Enclave gateway，連接過程基本與Device Agent / Gateway相同。
  • Gateway 主要保護不只單一資源，而是多個。
  • 缺點是網關保護一組資源，可能無法保護每個資源，這可能使得使用者看到他們無權訪問的資源。
  • 適用環境：
    • 適用於具有 legacy 應用程式或on-premises 數據中心的企業，無法為每個資源設置個別的 gateway。
    • 企業需要建立強大的資產和配置管理，以進行安裝/配置設備代理 Device Agents，這樣才可以允許 subjects 看到有哪些權限可以存取。

Resource Portal-Based Deployment

  • 這個模型相比其他模型的主要優勢在於，不需要在所有客戶端設備上安裝軟體元件。
  • 這個模型也有一些限制：
    • 由於只有當設備連接到PEP閘道時才能掃描和分析資產和設備，因此僅能從請求設備獲得有限的信息。
    • 模型可能無法持續監控這些設備，檢測惡意軟體、未打補丁的漏洞和適當的設定。
    • 此模型中沒有本地代理程式處理請求，因此企業可能無法完全查看或隨意控制資產，只有在它們連接到閘道時才能看到/掃描它們。
  • 適用情境：
    • 這使得該模型更適用於BYOD政策（Bring Your Own Device，即員工使用自己的裝置進行工作）和跨組織協作項目。

Device Application Sandboxing

  • 是 Device Agent / Gateway Model 的一種變體
  • 讓審核過的應用程式 Trusted App 或 Process 在「資產上」運行，進行區隔管理。
  • 區隔可以是虛擬機、容器或其他形式的實現，目的是保護應用程式免受可能被入侵的主機或其他應用程式的影響。
  • PEP可以是企業的本地服務或雲服務，負責管理應用程式的訪問。
  • 這個模型的優點是將個別應用程式與資產的其餘部分隔離，有助於防止感染。
  • 缺點：
    • 企業需維護所有資產的沙箱應用程式，且可能無法完全了解客戶端資產。
    • 還需要確保每個應用程式的安全性，可能相較於其他架構需要花更多努力。
    • 無法瞭解客戶端資產（裝置）。
  • 適用環境：
    • 無法掃瞄資產assets是否存在漏洞，這個模型可以保護AP防止主機上潛在的惡意軟體。

OMB - 5大支柱

美國聯邦政府發布的ZTA政策就是參考CISA的陳熟度模型以7個pillar做區分，分別針對identity, devices, networks, applications, data 給出意見具體闡述滿足零信任架構所應滿足的要求。

而這其中，有些要求適用於應用程式應滿足的要求，例如針對應用安全應該要確保第三方元件的安全並且有足夠的安全城市。但是，並無特別列出政府機構之應用服務在存取資源時應滿足的要求，而資料安全方面也僅僅提出基本的要求，包含對重點資料座標記、自動化分類、自動化安全回應等。

Identity 身份驗證

Identity

良好的身分驗證系統是ZTA的基底，政府機構應該要整合身分驗證系統，並根據需要可以和其他機構聯合訪問(Federation)。並且擴大對MFA來保護使用者避免credential-theft或是釣魚攻擊。要求含以下：

  1. 建立SSO服務驗證
    1. 建立SSO服務給使用者，可以和應用程式和通用平台(雲服務)整合
    2. 確保跨各種平台具有相同級別的強身份驗證。
    3. SSO應該使用公認的標準像是SAML或OpenId連線
  2. 應用層 必須 加強 MFA
    1. For agency staff, contractors, and partners: phishing-resistant MFA is required.
    2. For public users: phishing-resistant MFA must be an option.
    3. 必須使用phishing-resistant method 去存取帳號，像是註冊手機電話for SMS或是voice calls，或是WebAuthn，支援one-time codes
  3. 實施安全密碼政策，並檢查密碼是否能夠抵抗以外洩的資料
Devices 裝置監控

Devices

針對資產的檢測和監控：

  1. 要提供一套服務以改進對資產(裝置那些)的檢測和監控，全面了解有哪些使用者、裝置、或是任何在系統的互動。
  2. Continuous Diagnostics and Mitigation (CDM) 計畫要實施，可以參考Cisco提供的CDM Program
  3. 需要有強大的Endpoint detection and response (EDR) 端點偵測與回應 工具來部屬，
Networks 網路安全

Networks

  • DNS請求加密
  • 使用HTTPS連線
  • 網域開啟 MTA Strict Transport Security (MTA-STS)
    • 使用MTA-STS 針對傳送到您網域的電子郵件要求進行驗證檢查和加密作業，讓Gmail 的安全性更加完善。
    • 寄件伺服器支援 MTA-STS，並且收件伺服器在強制執行模式下設有 MTA-STS 政策，就能讓電子郵件的 SMTP 連線更加安全。
  • 每個應用程式應該都要在獨立的網路環境中，應該準備好在不同應用之間建立不受信任的網路安全連線
Applications 應用程式安全

Applications

  • 應用要做足夠專門嚴格的安全測試
  • 第三方元件要夠安全
  • 應用的漏洞報告，不要隱瞞
Data 資料安全

Data

  • 針對重點資料做標記，並進行資料的一些自動化分類或是安全性的回應
  • 必須要有全面和即時的完整logging紀錄
  • 自動化的安全回應:
    • 機構應努力採用植根於機器學習的數據敏感性分類，和安全自動化的早期候選者，這些候選者不需要立即使用機器學習，可以先用簡單的技術向是腳本或是正規表達式來應用
    • 盡可能地提供異常行為早期預警和檢測流程
  • 審核對雲中敏感數據的訪問
    • 使用加密來保護靜態數據
    • 可以通過雲端管理的加密和解密操作，以及相關日誌來幫助檢測
    • 在成熟的階段，機構應該將審計日誌與其他事件數據來源結合起來，採用更複雜的安全監控方法。
    • 例如，可以比較數據訪問的時間與用戶啟動事件的時間，以識別可能不是由正常應用程序活動引起的數據庫訪問。

DOD - ZTA 假設

這裡主要參考DoD中的chapter 2. Pillars and Principles，裏面提到零信任安全策略原則，如果有人問你…零信任的核心理念是什麼？你可以回答:

  • 本文提到「零信任策略的核心理念是在訪問敏感數據或受保護資源之前，要求持續性的驗證或驗證」。
  • 零信任安全模型中，「我們需要重新思考如何對實施對資源的安全訪問，並且由動態策略來決定」而這裡的動態策略應考慮到以下，超出了僅僅進行憑證驗證的範圍包含:
    • (1) 用戶和端點身份的可觀察狀態: 信心水平是從被驗證主體的多個屬性中建立的（身份，位置，時間，設備安全狀態）
    • (2) 應用程序/服務
    • (3) 請求的資產
    • (4) 其他行為和環境屬性
    • (5) 允許對訪問請求進行更全面的評估。

在DoD中，主要提到零信任有五個主要原則，這些原則代表了基本元素，並影響了零信任中的所有方面。

1. Assume a Hostile Environment 假設環境是危險的
  • 假設在環境內部和外部，都有惡意人士存在。
  • 所有用戶、設備、應用程序、環境和其他非人實體都被視為不受信任。
2. Presume Breach 假設環境內部已遭受入侵
  • 每天都有數十萬次針對DoD環境的嘗試性網絡攻擊。
  • 在進行操作和保護資源時，要有一個假設：敵對方已經進入您的環境。
  • 強化對訪問和授權決策的審查，以改善應對結果。
3. Never Trust / Always Verify. 不要信任，始終驗證
  • 默認情況下拒絕訪問。
  • 使用最小特權、多個屬性和動態網絡安全策略，對每個設備、用戶、應用程序/工作負載和數據流進行身份驗證和明確授權。
4. Scrutinize Explicitly. 明確審查
  • 所有資源都以安全方式一致地訪問，使用多個屬性（動態和靜態）為資源的情境訪問衍生出信心水平。
  • 對資源的訪問是有條件的，且基於行動和信心水平的結果，訪問可以動態變更。
5. Apply Unified Analytics 使用統一分析
  • 對數據、應用程序、資產和服務（DAAS）應用統一分析，包括行為特徵，並log每筆交易。

DOD - ZTA Tenets

上面有點像是基礎元件應包含的部分，以下是 chapter 2.4 Reference Architecture Principles 所描述架構在安全方面應採用的指導原則：

原則 #1: 在網路中不假定任何隱含或明示的受信任區域。
Principle #1: Assume no implicit or explicit trusted zone in networks.

這表示不對網路中的任何區域盲目信任。

原則 #2: 基於身份的認證和授權將嚴格執行，涵蓋對基礎設施、數據和服務的所有連接和訪問。
Principle #2: Identity-based authentication and authorization are strictly enforced for all connections and access to infrastructure

確保只有經過身份驗證和授權的用戶可以訪問相關資源。

原則 #3: 機器對機器（M2M）的認證和授權將嚴格執行，用於伺服器和應用程序之間的通信。
Principle #3: Machine to machine (M2M) authentication and authorization are strictly enforced for communication between servers and the applications.

這保證伺服器和應用程序之間的通信是安全和可信的。

原則 #4: 通過監控和評估用戶和設備行為生成風險簡介，以用於授權用戶和設備訪問資源時。
Principle #4: Risk profiles、 generated in near-real-time from monitoring and assessment of both user and devices behaviors、 are used in authorizing users and devices to resources.

這意味著根據即時生成的風險值來授權使用者和設備訪問特定資源。

原則 #5: 所有敏感數據在傳輸過程中和靜態存儲時都要進行加密。
Principle #5: All sensitive data is encrypted both in transit and at rest.

這確保了數據在傳輸和存儲時的安全性。

原則 #6: 所有事件都需要持續監控、收集、存儲和分析，以評估其是否符合安全政策。
Principle #6: All events are to be continuously monitored

這有助於保持對系統行為的實時監控和評估。

原則 #7: 政策管理和分發是集中化的。 rinciple #7: Policy management and distribution is centralized.

這意味著所有的安全政策都集中管理和分發，確保統一的安全措施。

DOD - 7 大支柱

主要會列出，每個支柱的說明、與AP與DB之間應用的相關程度，以及個人的感想。

User 使用者 ⭐️⭐️⭐️
  • 說明：這個支柱關注保護並限制人員和非人員實體對 (Data, Applications, Assets, Services)DAAS的訪問。包含對身份身份驗證，如MFA, 特權訪問管理 (Privileged Access Management ,PAM)，持續對使用者進行身份驗證、授權和監控活動模式，以管理使用者的訪問和特權，同時保護所有互動。
  • 感想：內容有提到，這個User Pillar 不僅僅是針對使用者，但要提出一方式已持續對AP進行身份驗證，並監控活動模式。
Device 設備 ⭐️⭐️
  • 說明：強調在企業中，對設備進行持續的實時驗證、檢查、評估和修補。如使用 Mobile Device Managers、comply to connect（遵守規定才可以連線）或 可信平台模塊（TPM），這些解決方案可以幫助進行設備的信心評估，即確定設備是否是受信任的。並且符合組織的安全標準。同時，這些數據還可以在進行授權決策時提供依據，確保只有合法的設備能夠訪問資源。
    • 對於每個訪問請求，應進行其他評估（例如，檢查是否受到威脅、軟體版本、保護狀態、加密啟用和正確配置等）。
    • 在零信任方法中，能夠識別、驗證、監察、授權、隔離、保護、糾正和控制所有設備至關重要。
  • 感想：應該驗證執行AP的環境設備是否安全。
Network/Environment 網絡/環境 ⭐️
  • 說明：這個支柱強調對網絡/環境進行分段（邏輯和物理），以精細的訪問和策略限制來進行隔離和控制（無論是在場內還是場外）。隨著邊界變得更加精細，微分段提供了更大的保護和控制能力。這一支柱的關鍵在於控制特權訪問、管理內部和外部數據流，以及防止橫向移動。
  • 感想：感覺著重在進行網路的微分割，確保企業內外網都有經過控制。
Applications and Workload 應用程式和工作負載 ⭐️

說明：這個支柱包含 on-premises 或是雲端環境的應用程式和工作負載。Application Delivery 的相關技術可以實現額外的保護，像是開發的 source code 和 libraries 應通過 DevSecOps 的開發實踐來審核，確保應用程序從一開始就安全。

  • 感想感覺這是AP方面單方面的安全準則。
Data 數據 ⭐️⭐️⭐️⭐️
  • 說明：瞭解組織的數據及其重要性對於成功實施 ZT 架構至關重要。組織需要根據任務重要性對其數據進行分類，並將此信息用於制定全面的數據管理策略，作為其整體 ZT 方法的一部分。
    • 通過對一致有效的數據進行摄取、數據分類、開發架構，以及在靜止和傳輸中加密數據，可以實現這一目標。
    • DRM、DLP、軟體定義環境和細粒度數據標記等解決方案支持對關鍵數據的保護。
  • 感想：這很重要，才能特顯出資料庫方面的保護以實現零信任。
Visibility and Analytics 可見性和分析 ⭐️⭐️
  • 說明：上下文詳細信息提供了對其他 ZT 支柱的性能、行為和活動基線的更深入理解。
    • 這種可見性改善了對異常行為的檢測，並能夠在安全策略和實時訪問決策中進行動態更改。
    • 此外，其他監控系統，如感測器數據以及遙測數據，將有助於填充環境的情況，並有助於觸發用於回應的警報。
    • ZT 企業將捕獲和檢查流量，不僅關注網絡遙測，還會深入分析數據包本身，準確地發現網絡上的流量並觀察當前存在的威脅，更智能地調整防禦。
  • 感想：比較重要的是要紀錄Log，作為異常行為檢測和訪問決策中進行動態更改。
Automation and Orchestration 自動化和協調 ⭐️⭐️⭐️
  • 說明：通過基於策略的自動安全流程，在企業範圍內實現快速且規模化的操作。
    • SOAR(Security Orchestration, Automation, and Response)怎麼幫助企業更有效的回應安全事件以降低了響應時間。
    • 安全協調整合了安全信息和事件管理（SIEM）以及其他自動化安全工具，有助於管理不同的安全系統。
    • 在 ZT 企業中，自動安全響應需要明確的流程以及對所有環境的一致性安全策略執行，以提供主動的命令和控制。
  • 感想：著重在怎麼做到自動化的安全響應，透過響應影響策略，實現動態決策。

聚合能力與支柱

這邊會做一個大表格來整理，這樣才能具體知道如何實現Pillar的目標。
然後標示出：

  • 哪些是我們主要探討的
  • 哪些不是針對應用程式與DATA之間的部分，有需要納入嗎？如果要該如何調整？
  • 那些不做的部分，有哪些是可以透過補足文獻來補充的。

（圖片放置處）

上圖展示了七大支柱中，我們應遵循的能力，而這些能力又該如何透過Pillar來滿足，主要可以區分以下兩者：

  • Aggregate:
    • 如果在UML的說詞上A指向B，表示 A 擁有 B，但為弱擁有，A 與 B 有各自的生命週期。
    • 常見用來描述 A 類別擁有 B 的實體，A 與 B 彼此協作，但又可各自單獨存在。
  • Dependency:
    • 如果在UML的說詞上A指向B，A 使用 B，B 的變化有可能會影響到 A。
    • 常見描述 A 在使用某些方法時，會將 B 作為參數傳入，但並不持有 B。
Aggregate Capabilities 1: Zero Trust Authentication & Authorization

這兩個主要牽涉兩個Pillar的「條件授權能力」Conditional Authorization Capabilities：

  • User
    • 侧重于任何被視為人實體或非人實體的對象。
    • 對系統和資源的授權將不僅受限於標准角色，還包括屬性狀態、對該實體的分析、特定時間的需求以及訪問資源和數據的理由。
  • Device
    • 「條件授權能力」將圍繞系統和執行可接受基準和設備狀態的強制執行。
    • 系統將持續評估inventories存和遙測數據的當前狀態。進一步的信息將通過狀態掃描和日誌記錄獲取。
    • 系統將能夠實時更新，或者在協調或其他糾正方法的請求下進行更新。
    • 訪問數據的系統受到的審查程度和要求將與嘗試訪問的數據的安全級別相關。
Aggregate Capabilities 2: Zero Trust Infrastructure

針對 Infrastructure 的聚合能力主要與 Network and Environments Pillar 有關

  • 建立在這個支柱上的控制與任何ZT啟用基礎設施的能力有關。
  • 這不僅可以包括本地基礎設施，還可以包括雲資源。
  • 可以設計一個宏觀和微觀分割策略，將特定的工作負載分割和隔離，只要這些工作負載被嚴格定義和驗證。這不僅允許所需節點之間的互聯，而且還滿足了軟件定義邊界的連接要求。

針對保護Application and Workload 的聚合能力主要與 Workloads Pillar 有關

  • 這個聚合能力包含圍繞工作負載支柱的所有能力。
  • 這些能力將保護應用程式和為最終用戶提供數據的設備。
  • 這些能力旨在防止橫向移動，驗證良好的軟體實踐，並將應用程序分割成離散的高度安全的區域。
  • 對這個區域的連接受到嚴格的審查，並在內部和外部請求之間進行代理。對應用程序呼叫的標準化將有助於適當的實施政策變更和更新。

針對保護Data 的聚合能力主要與 Data Pillar 有關

  • 這個聚合能力包含圍繞數據支柱的所有能力。
  • 這個能力主要在保護資料，飽含標記資料、識別敏感資料、防止外洩或加密敏感資料。
Aggregate Capabilities 3: Analytics and Orchestration

針對Analytics的聚合能力主要與 Visibility & Analytics Pillar 有關：

  • 在這個支柱下的能力是連續實體監控、感應器、日誌記錄、事件驅動的分析工具和機器學習的結合。
  • ZT 將利用機器學習來建立環境數據和分析的基準。
  • 機器學習演算法提供基準數據集，通過人工智慧在 ZT 協調中實現 ZT 政策執行。

針對 Orchestration(協調)的聚合能力主要與 Automation & Orchestration Pillar 有關：

  • 其焦點將是提供自動化，以部署政策變更，以確保企業並在敏感數據周圍進行控制。
  • 自動化和協調支柱還能夠考慮從軟體定義企業中引入所需目標狀態數據 account for the ingestion of desired target state data from the Software-Defined Enterprise. 。
  • 雖然早期能力將集中在政策部署上，但隨著技術的演變，未來的演進將在核心能力中增加人工智慧和機器人流程自動化的能力。
Dependency Capabilities 4: Zero Trust Enabling

以下是成功應用 ZT 安全策略的關鍵：
數據治理：

  • 數據治理是成功應用 ZT 安全策略的關鍵要素。
  • 數據治理提供了管理從數據創建到處理的流程、工具和框架。

ZT 和風險管理：

  • ZT 提供新的發現內容，供風險管理框架（RMF）使用。
  • ZTA 導致風險管理框架（RMF）內的流程為 ZT 提供新的發現內容，同時適應 DevSecOps 等現代應用開發實踐。
  • 影響主要集中在準備、評估和監控步驟。
  • 準備階段需要大量的發現工作，特別是對數據流的記錄和分割政策的制定。
  • 隨著 DevSecOps 能力修改應用程序，評估將有所改變。
  • ZT 需要大量的監控活動，改進反饋給 RMF 過程和事件響應。

軟體定義企業Software Defined Enterprise：

  • 軟體定義企業是實現 ZT 架構廣度和深度的關鍵因素。
  • 虛擬化和軟體定義的基礎設施允許隔離數據和應用程序。
  • 域協調和控制提供企業控制計劃，以推動與 ZT 控制相符的配置和政策。

Pillars, Resources & Capability Mapping


上圖展示「ZT支柱、資源與能力映射」概念展示如何在架構內實施安全措施的操作視角。

  • NPE(non-person entity)身份和個人身份獨立追蹤，允許在執行點之間分離驗證信心水平的驗證路徑。
  • 認證和授權活動將在企業內的多個專注點上進行，包括使用者和端點、代理、應用程式和數據。
  • 在每個執行點，日誌被送往SIEM，進行分析以開發信心水平。
  • 設備和使用者的信心水平是獨立開發的，然後在適當情況下進行彙總，以供策略執行使用。
  • 如果非人實體或個人實體的信心分數超過閾值，則它們被授權查看所需數據。
  • 數據在途中透過數據防洩（DLP）進行保護，同時也將數據餵養到SIEM，以確保正確使用數據。
Enterprise Identity Service 企業身份服務

企業身份服務包括三個主要組件：

  • 聯合企業身份服務（FEIS）Federated Enterprise Identity Service
    • 聚合身份憑證和授權，並在聯合組織之間共享，以實現跨域訪問服務。
  • 自動帳戶配置（AAP）Automation Account Provisioning
    • 提供身份治理服務，管理用戶權限，執行業務角色，以及基於人員中心活動的帳戶設置和撤銷。
  • 主用戶記錄（MUR）Master User Record
    • 實現整體的知識、審計和數據匯總報告，顯示誰可以訪問哪個系統或應用。
    • 還支援識別內部和外部威脅。
Client and Identity Service: ICAM(Identity/Cridential Access Management) 提供德能力

ICAM 提供的能力：

  • 持續認證：一種認證概念，利用多種兼容的認證策略，在用戶和非人實體試圖訪問資源和數據時，以持續的、幾乎即時的方式驗證其身份。
  • 條件授權：在授權一個資源時，需要基於請求者的持續信任來決定。這種信任可以受到設備衛生狀況、用戶和實體行為以及其他因素的影響。

**Comply-to-Connect（C2C）**服務

  • 在整個網絡基礎設施上運作的一個工具和技術框架，用於發現、識別、描述並報告連接到網絡的所有設備。
  • C2C 能力將協調多個工具，防止不符合規定和未經授權的設備和人員連接到網絡，從而保持網絡的安全配置，按照建立的標準和配置保護信息。
  • 設備衛生：檢查設備的狀態，檢查是否存在惡意軟件或漏洞，以及管理和未受管理資產的安全控制合規性狀態，以確定允許設備訪問資源和數據的風險水平。

ICAM 是 “Identity, Credential, and Access Management”（身份、憑證和訪問管理）的縮寫，它是一個在資訊技術和資訊安全領域中的概念，旨在確保組織內部和外部的用戶和實體（如設備、系統等）可以安全且適當地訪問敏感資源和數據。

Data-Centric Enterprise 企業中心數據

企業中心數據主要決策點有分三個部分，主要做Authorization：
資源授權決策點 Resource Authorization Point & 應用授權決策點 Application Authorization Point

  • 將評估結合的非人實體和用戶，以授權訪問請求。
  • 與前面的決策點一樣，這將利用信心水平和定義的策略來判斷是否有權訪問。

應用授權決策點 Application Authorization Point 的能力：

  • 保護應用工作負載 Securing Application Workload：能夠保護和管理應用層以及計算容器和虛擬機。能夠識別和控制技術堆棧，以實現更細粒度和準確的訪問決策。
  • 保護供應鏈 Securing Supply Chain：能夠防止或應對軟體供應鏈攻擊，這種攻擊發生在網絡威脅行為者滲透軟體供應商的網絡，並使用惡意代碼在供應商將軟件發送給客戶之前損害軟件。

數據授權決策點 Data Authorization Point

  • 數據所有者使用 ZT 措施通過協調或數據損失防護/災害恢復（DLP/DRP）服務器對數據進行標記。
  • 數據標記將用於確保所有數據的適當訪問控制得到滿足。
  • 能力：
    • 保護數據 Securing Data：流程和技術控制，用於識別、分類、安全處理、保留和處理數據。
    • 數據發現和分類 Data Discovery ：能夠發現、分類、標記和報告數據，包括數據庫中的敏感數據和風險數據。
    • 動態數據遮蔽 Dynamic Data Masking：提供列級安全功能，使用遮蔽策略在查詢時選擇性地遮蔽表和列。
      • 列級安全功能（Column-level security）是一種數據安全措施，它允許在數據庫中對單獨的列（也就是數據表的某個特定欄位）進行安全設置和控制。
Automation and Orchestration 自動化和協調

內容提到了自動化和協調方面的重點，以及一些相關的能力和技術：
自動化和協調：

  • 政策引擎和自動化 (SOAR)： 這些術語用於定義處理威脅管理、事件響應、政策執行和安全政策自動化的技術。零信任 (ZT) 架構將需要動態政策執行和自動化。SOAR 將與分析和政策引擎協同工作，以發展信心水平並自動將政策傳遞到執行點。
  • 能力：
    • 軟體定義企業： 能夠在物理基礎架構上創建虛擬化層，並以自動化的方式在中心進行管理，利用基於政策的訪問控制動態創建、配置、提供和解除虛擬化網絡功能、系統功能、安全功能和工作流程。
    • 網絡安全協調： 能夠協調和自動化不同的零信任活動，並將它們與核心系統進行接口和協調。

SOAR代表“Security Orchestration, Automation, and Response”的縮寫，翻譯成中文就是「安全協調、自動化與響應」。它是一種資訊安全技術，旨在將安全運營流程自動化、協調和優化，以更快速、更有效地應對安全事件和威脅。這種技術整合了自動化工具、流程協調和威脅情報，使組織能夠更迅速地識別和應對安全威脅，同時降低人工干預的需要。

Monitoring and Analysis Services 監控與分析服務

這篇論文主要探討「監控與分析服務」，以下是其中重點的解釋：

分析與信心評分：

  • 這個系統通過對事件和事故日誌的系統性分析，使用統計學或其他定義的功能性過濾器或計算方法，來獲取信心分數。
  • 這些分數表示在特定誤差範圍內，對於給定的分析數據集，對統計參數的估計被確定為真實的概率/百分比值。
  • 在特定情況下，例如零信任環境中，這代表用戶或NPE（非人類實體）聲稱自己是誰的概率。
  • 能力：
    • 分析：系統地應用統計和/或邏輯技術來描述、概括和評估數據。

使用安全信息和事件管理的日誌記錄：

  • 活動數據被匯總並存儲在安全信息和事件管理（SIEM）系統中，該系統提供安全信息管理（SIM）和安全事件管理（SEM）功能。
  • 能力：
    • 審計/傳感器和遙測：直接驗證（例如通過檢查、檢驗或計算）活動或設備，以確保符合安全要求。實體包括用戶和NPE、傳感器可靠性、合規計劃和共享服務。

DOD - Learn from Use Case

主要能夠回答以下文題，才給予紀錄並筆記：

  1. 怎麼確保AP與Database之間滿足零信任架構。
  2. 應該怎麼實現動態的Policy存取控制
  3. 在AP與DB之間如何做到持續性的驗證

特色：說明針對 Data Center 應該注重的地方


當今的資料安全方法建立在過時的、孤立的網絡中心策略和方法的基礎上。在這種網絡中心的安全模型中，數據容易受到威脅，因為僅通過基本的安全實踐（如用戶名/密碼、基於用戶/設備的訪問和僅在靜態時加密）以及標準的基於角色的訪問控制（RBAC）來保護數據，而這種控制很少被更新或驗證。威脅行為者可以迴避這些基本的保護措施。因此從上述來看，文中提到以下針對數據中心應該要實現的能力：

  • Encryption: 數據中心的技術，主要在靜態時、字段和記錄內部、傳輸中數據要進行加密。
  • Policy Enforcement 中包含數據標記：
    • 用途1: 以提供數位版權管理（DRM）和數據丟失防護（DLP）解決方案的數據。
    • 用途2: 從而允許創建使用基於屬性的訪問控制（ABAC）的額外動態策略。

特色：說明貼標籤 和 其他存取動作應該做的時機點（圖片透過禁止來表達誰負責阻止工作）


從上圖中可以看到 PEP 中主要闡述以下幾點來保護數據存儲（Data Store）中的數據：

  • 數據標記（Data Tagging）
    • 時機：在創建或導入文檔時進行
    • 工作：
      • 對於組織來說，了解擁有哪些資料，資料的特性，以及滿足適當資料保護標準所需的隱私和安全需求非常重要。
      • 組織可以將數據分類並賦予各種屬性。這些屬性可以用於對數據進行分類，例如個人身份信息（PII）和敏感數據。
  • 數據權限管理（DRM）+ 數據遺失防止（DLP）+ 安全信息和事件管理（SIEM）+ 數據存儲 進行協作
    • 時機：數據標記後
    • 保護措施：以下這四種保護措施，再加上前面提到的加密等密碼技術，為資料中心的零信任架構提供了強大的資料保護。
      • SIEM：收集並分析對任何被訪問的數據的訪問和變更。
      • DRM：可以允許或阻止對數據的訪問、編輯或複製，
      • DLP：可以阻止對數據的訪問和傳輸。
      • DDM：如果用戶/端點被認為是值得信賴的，並且已經獲得對數據的訪問權限，動態數據遮罩（DDM）將在訪問和傳輸數據時對數據進行遮罩和修改。

可能會好奇，DLP跟DRM都有阻止的作用，那他們的差異是？
DLP 主要針對未知來源的請求，而DRM則是針對已知來源的請求。

特色：有提到SIEM跟SOAR的關係等監控機制

  • PEP: PEP 認證後，對加密資料進行解密工作，給請求的 user / device
  • SIEM: 任何請求都會被 SIEM 所紀錄，並且進行分析，一但發現可疑的地方就會觸發事件通知SOAR，由 SOAR (Security Orchestration, Automation, and Response) 處理。
  • SOAR: 遵循事件響應程序，可以部署緩解策略來終止現有會話、重新加密數據並更新 PEP 上的策略以拒絕未來的請求。

特色：主要提到 PDP，並說明PDP主要處理請求(標籤,DRM,DDM,DLP,加密連線相關)，PEP 則是即時保護資料和接收（加密,標籤,DRM 相關）。

  • 架構優勢：強調保護資料本身，而非僅限於資料邊界。
  • 資料請求路由：透過政策決策點（PDP）進行，未滿足政策的請求無法訪問。
  • 政策更新：PDP政策即時通過設備健康、特權訪問管理和分析保持更新。
  • 連接管理：PDP政策變更時，PEP可終止現有連接。
  • 資料保護：多個策略執行點（PEP）持續保護資料，並使用加密、標記、遮罩DDM和防止損失DLP等措施。
  • 政策協調：ZT架構組件間的政策協調實現深度防禦，維護資料完整性、可用性和機密性。

特色：著重在 Analysis + AI/ML 對於 Policy 的應用。

  • ZT 模型中透過 AI 大幅提升環境的可見性、洞察力和自動化能力。
  • 全面收集與分析：從環境的各個方面集中收集數據並進行分析。
  • 透過 SIEM 分析，發現威脅則透過SOAR處理。
  • 未來分析使用：這些信息將被記錄並存儲，以用於未來的機器學習和人工智慧，包括用戶/非特權實體的信心評分、高級威脅檢測、創建和修改基準線，以及與外部情報計劃和其他人工智慧一起進行自動化和編排。

DOD - 零信任架構 Pattern

應該要根據內容的章節7.1與7.2歸納出所有架構的pattern，並且指出研究適用的Pattern與說明原因。

Domain Policy Enforcement for Resource Access

  • 說明：主要架構分三段 Resource Domain：Secured User or Device / Secured Network / Secured Application and Data ，每一段都有他們自己的 domain orchestrator 可以想像是設定 policies 的地方，然後Controller進行控制，而做到統一的方式就是透過 Networ + application and data 的 orchestrator 收集資料，並傳送到 Cybersecurity Domain Orchestrator 近一步分析可疑的地方。一但發現威脅，就會透過 automated 調整 policies，以減少威脅。
  • 優點：可以根據不同的 Domain 精準設定 policies，並且透過 Controller 進行控制。這可能更像我的研究內容，針對AP與DB之間的控制措施。
  • 缺點：透過分成不同的 Domain Policy Enforcement 在資料傳輸的過程中，可能有授權驗證的不一致性。

Software Defined Perimeter

  • 說明：其主要特性有二，一個可用來轉發 end-to-end 之間訊息並進行攔截中斷以執行零信任授權的 gateway。另一個主要是說需要在端點上安裝代理，執行身份驗證、健康狀態檢查、扮演類似PEP的角色。而這邊需要注意的是，會透過Broker來進行端點註冊、授權，作為PDP的角色存在。如果授權驗證通過，就會透過 Gateway 建立 Proxy 進行 Direct Link 連接兩個端點的連線。
  • 優點：容易做到政策控制的統一性，並且能夠確保所有連接的裝置都是受管控的，因為必須裝 Agent 才得以建立連線。
  • 缺點：技術難度感覺較高，需要有完整的註冊流程和建立連線流程，在連線上的考慮更多。

ZT Broker Integration

  • 說明：與Software Defined Perimeter有點類似，所有應用程序都對最終用戶網絡隱藏，並且所有連線都須透過信任代理進行連接。但這可能會與Software Defined Perimeter有一點混淆，他們都有Broker, Agent但是差在哪裡呢？差異大概有以下：
    • Broker 同時作為 PDP 和 PEP ，PEP 和 PDP 可以成對分佈(可以多個)，由單個虛擬服務實現，並且可以進行load balancer實現。
    • Broker 可以分散在 edge, 中間層 mid-tier 或是 data center
    • Service Proxy 是裝在 Broker 裏面，不是 Resource Application
    • 並沒有強調要透過 Gateway 來進行連接(Proxy連線)。
  • 優點：PEP, PDP 可以在多個地方部署、load balancer，甚至是以單個虛擬服務實現，可以更普遍的設置存取控制點在不同的地方。
  • 缺點：但是在多個地方同時有PEP,PDP的情況下，可能會造成授權驗證的不一致性，並且 Resource Application 沒有安裝 Agent，不能保證應用程式是受管控的。

Micro / Macro Segmentation

Micro / Macro Segmenetaion 主要是透過第三層網路架構的方式實現ZTA，與本文章想要探討的主題有點不同，因此不會做太多說明與介紹。

  • 說明：在這個架構中，主要角色是 Next Generation Firewall，在這種架構中，所有的流量在到達其目的地微分區之前都必須通過NGFW。在某些情境，微分區可以繼續分解成更小的組件，定義進程對進程的微分區，並演變為API微分區。當用戶對三層Web應用程序進行請求時，流量會先經過Web服務的PEP > 再由應用程式PEP評估流量 > 請求返回給用戶之間再進行評估一次。總共三層，這種方式確保了在多層應用架構中，每一個階段的流量都經過了嚴格的策略評估，從而增強了安全性。但是問題是，應用程式到資料庫之間，並沒有任何評估，就變像是相信應用程式。

DOD - 成熟度模型

這邊主要說明若要滿足ZTA的成熟度模型，需要做到哪些事情。

Preparae for ZTA

關鍵字：辨識重要資源清單、資料流、網路流量Log

要做的事情主要有兩個部分：

  • Discovery
    • 辨識 DAAS (數據、應用程序、資產和服務)
    • 對照 data flows
    • 建立 使用者 和 裝置清單
    • 辨識特權帳戶
    • 紀錄網路 traffic
  • Assessment
    • 利用現有標準確定合規狀態
    • 確定帳戶有適當的權限
    • 確保網路/環境安全設定滿足最小權限原則

ZTA Baseline

關鍵字：網絡分段、最小權限原則、MFA、資料辨識標籤、加密

要做的事情主要有以下：

  • 確保存取 DAAS 的時候是經由 Cybersecurity policies 所決定的。
  • 網絡採用拒絕全部/例外允許進行分段 （白名單）
  • 裝置IT的安全政策要求並管理
  • 實現最小權限存取
  • 使用 MFA
  • 進行 data 辨識，並標示敏感或關鍵資料
  • 滿足加密要求

ZTA Intermediate

關鍵字：細顆粒度、Micro-Segementation、EFIS、PAM、DLP & DRM、UEBA

要做的事情主要有以下：

  • 加強 cybersecurity 政策，基於細顆粒度(user and device attribute)進行控制
  • 主要網路段使用 Micro-Segementation
  • User 基於 Enterprise Federated Identity Service 進行驗證
  • 透過 Privileged access management (PAM) 增強最小特權
  • 實施 DLP & DRM
  • 資料透過 flow analysis 和簡單的自動化進行標籤與分類
  • 使用者和Entity的行為分析（UEBA, User and Entity Behavior Analytics）建立 baseline policy

ZTA Advanced

關鍵字：動態決策、持續驗證與授權、user + device 滿足 EFIS

要做的事情主要有以下：

  • 可以做到動態的決定是否可以存取 DAAS，強大的實時分析驅動
  • 完全的 micro-segmentation
  • 持續性適應驗證與授權
  • User + Device 基於 Enterprise Federated Identity Service 進行驗證
  • 完全的實施 Just-in-Time 和 Just-Enough 的存取政策
  • 透過 machine learning 進行資料的標示與分類
  • 進階分析技術，使威脅檢測能夠自動化並根據事先設計的策略進行協調