烏魚子

當攻擊者突破單一帳號後， 橫向擴散（Lateral Movement） 往往比初始入侵更具破壞力。Compartmented 隔離分區機制透過雙重鎖定，讓即使持有高等級許可的使用者，也無法任意存取超出職責範圍的資料。 什麼是 Compartmented 雙重鎖定機制？ Compartmented 源自軍事與情報領域的資訊分類架構，核心邏輯是： 安全許可等級（Clearance Level）只是必要條件，不是充分條件。 使用者必須同時通過兩道驗證——「許可等級相符」與「明確的知悉必要性（Need-to-Know）」——才能存取特定分區。這與傳統 RBAC 僅依角色授權不同，Compartmented 要求每次存取都有明確業務理由，大幅縮小爆炸半徑（Blast Radius）。即使攻擊者竊取高權限憑證，也因缺乏分區歸屬而被阻擋在外。 如何阻斷資安事件的橫向擴散？ 在現代零信任架構中，Compartmented 通常以 屬性式存取控制（ABAC） 實作。存取決策引擎會同時評估使用者屬性（許可等級、分區標籤）與資源標籤（分區 ID、資料分類），兩者皆符合才允許存取。以雲端環境為例，AWS IAM 可透過 Condition Key 搭配資源標籤實現分區隔離；Azure 則以 Sensitivity Labels 配合 Conditional Access Policy 達成相同效果。分區邊界一旦建立，單一帳號遭入侵時，損失範圍被嚴格限制在該帳號所屬分區內，無法跨分區移動。 # AWS IAM Policy：僅允許存取標記為相符分區的 S3 物件 "Condition": { "StringEquals": { "s3:ExistingObjectTag/Compartment": "${aws:PrincipalTag/Compartment}", "s3:ExistingObjectTag/Clearance": "${aws:PrincipalTag/Clearance}" } } 💡 重點整理 雙重鎖定 ：許可等級 + Need-to-Know 缺一不可，單一條件不足以授權。...

HTTP 是無狀態協定， Session 管理技術（Common session management techniques） 是維持使用者登入狀態的核心機制。選錯技術或實作不當，將直接導致帳號劫持與資料外洩。 主流 Session 管理方式比較 Cookie 是最普遍的做法，伺服器發送 Session ID 至瀏覽器儲存，後續請求自動帶回。必須搭配 HttpOnly 與 Secure 屬性，防止 XSS 竊取與明文傳輸。 隱藏表單欄位 將 Session ID 嵌入 HTML 表單，每次 POST 才傳遞，不適合跨頁面狀態維護，且易遭中間人攔截。 URL 重寫 把 Session ID 附加於網址（如 ?sessionid=abc123 ），無需 Cookie 支援，但 Session ID 會暴露於瀏覽器歷史、伺服器日誌與 Referer 標頭，安全風險最高，現代應用應避免使用。 框架內建 Session 機制與最佳實踐 主流框架如 Express（Node.js） 、 Django（Python） 、 Spring Session（Java） 均內建 Session 管理，自動處理 ID 生成、儲存與過期。以 Express 為例， express-session 預設使用記憶體儲存，生產環境應改用 Redis 等外部儲存以支援橫向擴展。登入後務必執行 Session 再生（Session Regeneration） ，防止 Session Fixation 攻擊；登出時必須完整銷毀伺服器端 Session，而非只清除 Cookie。 // Express Session 安全設定範例 app.use(session({ secret: process.env.SESSION_SECRET, resave: false, saveUninitialized: false, cookie: { httpOnly: true, secure: true, maxAge: 3600000 } })); // 登入後執行 Session 再生 req.session.regenerate(() => { req.session.userId = user.id; }); 💡 重點整理 Co...

在全球資安合規浪潮下， Common Criteria（ISO/IEC 15408） 已成為 IT 產品安全評估的國際黃金標準，透過統一框架取代各國分散標準，實現跨國互認與採購信任。 什麼是 PP、ST 與 EAL？ Protection Profile（PP） 由使用者社群或政府機構制定，定義某類產品（如防火牆、智慧卡）的通用安全需求，與具體實作無關。 Security Target（ST） 則由廠商針對特定產品撰寫，說明如何滿足 PP 需求並描述實際安全功能。 Evaluation Assurance Level（EAL） 分為 EAL 1 至 EAL 7，數字越高代表評估深度越嚴格：EAL 1 僅做功能測試，EAL 4 為商業產品常見等級（含設計審查與滲透測試），EAL 7 則需形式化數學驗證，通常僅用於軍事或高安全核心系統。三者共同構成 CC 評估的核心骨架。 CCRA 互認機制與實務應用 Common Criteria Recognition Arrangement（CCRA） 目前涵蓋超過 30 個成員國，通過認證的產品可在成員國間直接採信，無需重複評估。實務上，政府採購常要求防火牆、VPN 閘道、HSM 等產品持有 CC 憑證。台灣透過 BSMI 參與相關認證體系，廠商可委託 ITSEF（IT Security Evaluation Facility）進行第三方評估。值得注意的是，CCRA 於 2014 年後僅對 EAL 2+ 以下等級維持完整互認，EAL 5 以上需雙邊協議。了解此限制，有助於廠商在進入不同市場時規劃合理的認證策略。 💡 重點整理 PP 定義產品類別的通用安全需求，與廠商無關。 ST 是廠商對特定產品的安全聲明，評估依據即來自此文件。 EAL 4 是商業市場最常見等級，兼顧保證深度與評估成本。 CCRA 實現跨國互認，但 EAL 5 以上需額外雙邊協議才有效。 Common Criteria 不只是一張認證標章，更是產品安全設計的結構化證明。廠商若能在開發早期導入 PP 需求，將大幅降低評估成本，並在國際市場建立可信賴的競爭優勢。 📚 參考文獻 Common Criteria Portal — 官方認證產...

什麼是 FPT_RCV？ 系統故障後的恢復過程，往往是安全漏洞最易滲入的時機。 Common Criteria 的 FPT_RCV（Trusted Recovery） 正是為此而生，它規範 TOE（Target of Evaluation）在故障或中斷後，必須能安全回到 已知安全狀態 ，且整個恢復過程不得違反既有安全策略。 FPT_RCV 隸屬於 CC Part 2 的 FPT（Protection of the TSF）類別，核心訴求是確保 TSF（TOE Security Functionality） 的完整性在恢復流程中始終被維護，不因系統重啟或錯誤處理而遭破壞。 四個層次的 Trusted Recovery FPT_RCV 依據自動化程度與資料保護強度，由低至高分為四個遞進層次，設計者可依系統風險等級選擇對應層次： FPT_RCV.1（Manual Recovery）： 系統無法自動恢復，需由授權管理員手動介入完成。 FPT_RCV.2（Automated Recovery）： 針對特定故障情境，TSF 可自動恢復至安全狀態，無需人工干預。 FPT_RCV.3（Automated Recovery without Undue Loss）： 自動恢復的同時，保證資料不發生不當遺失，確保資料完整性。 FPT_RCV.4（Function Recovery）： 最高層次，要求每個 TSF 功能具備「原子性」——操作要嘛完整成功，要嘛完全回滾，不留中間狀態。 層次越高，對系統設計的要求越嚴苛。 FPT_RCV.4 的原子性設計 常見於金融交易系統、HSM（硬體安全模組）等高保證環境，確保即使電源突然中斷，系統狀態也絕不處於未定義的危險區間。 💡 重點整理 FPT_RCV 確保恢復過程本身不成為安全弱點。 四層次由手動到自動、由允許資料遺失到原子性保護，逐級強化。 選擇層次時，應依 ST（Security Target）中定義的威脅模型與 EAL 等級決定。 FPT_RCV.4 是最高保證層次，適用於不容許任何中間狀態的關鍵系統。 理解 FPT_RCV 的層次設計，有助於在撰寫 Security Target 時精準選擇符合系統風險情境的恢...

在國際採購與政府標案中， Common Criteria (CC) 是資安產品取得信任的通行證。它以 ISO/IEC 15408 為基礎，透過第三方實驗室對產品安全性進行客觀驗證，讓買賣雙方共同認可評估結果。 CC 三層核心架構：PP、ST 與 EAL CC 評估圍繞三個關鍵元素運作。 Protection Profile (PP) 是由需求方（如政府機關）定義的安全需求範本，描述某類產品「應該做到什麼」，與具體實作無關。 Security Target (ST) 則是廠商針對其特定產品（即 TOE，Target of Evaluation ）所撰寫的安全聲明文件，說明產品實際實作哪些安全功能，並對應 PP 的要求。 EAL（Evaluation Assurance Level） 為 EAL1 至 EAL7 的七級保證等級，數字愈高代表驗證過程愈嚴謹，但並非代表功能愈強，而是對安全聲明的信心程度愈高。政府採購常見要求落在 EAL2 至 EAL4。 評估流程與國際互認機制 廠商委託經認可的 評估實驗室（CCTL） ，依據 ST 對 TOE 進行測試與分析，實驗室將結果提交至各國 認證機構（CB） （如美國 NIAP、德國 BSI、台灣 TWNCAF）審核核發憑證。CC 最重要的價值在於 CCRA（Common Criteria Recognition Arrangement） 互認協議：31 個成員國相互承認彼此頒發的 CC 憑證，產品無需在每個國家重複受評。廠商取得憑證後，產品會刊載於 NIAP 或 CC Portal 的公開清單，採購方可直接查驗，大幅降低供應鏈信任成本。 💡 重點整理 PP 定義「需求類型」， ST 描述「產品實作」，兩者對應是評估核心。 EAL 等級 衡量保證深度，非功能強弱；EAL4 是商業產品最常見上限。 CCRA 互認 讓單一憑證跨 31 國有效，節省重複評估成本。 憑證查驗可直接至 CC Portal（commoncriteriaportal.org） 搜尋產品清單。 Common Criteria 不是萬能的安全保證，而是一套 可重複、可比較的評估語言 。理解 PP、ST 與 EAL 的關係，是企業在國際市場中正確解讀資安憑證的第一步。 ...

在系統安全強化與合規稽核中， 組態錯誤 往往是最常被忽略的攻擊面。CCE（Common Configuration Enumeration）透過統一編號體系，讓組織能精準識別與追蹤不安全的系統設定，是落實安全基準（Security Baseline）的核心工具。 什麼是 CCE？核心定義與定位 CCE 由 NIST 維護，專門為 系統組態問題 提供唯一識別碼（如 CCE-27002-5），其定位不同於描述軟體漏洞的 CVE。CCE 聚焦於「設定層面」的安全缺失，例如：密碼原則未啟用、稽核日誌未開啟、不必要的服務未停用。每筆 CCE 紀錄包含技術說明、對應的系統參數名稱，以及可連結至 NIST SP 800-53、CIS Controls 等合規框架的參照。這使得跨工具、跨平台的組態管理能以同一語言溝通，大幅降低稽核的歧義性。 CCE 如何應用於合規稽核與基準強化 CCE 被整合於 SCAP（Security Content Automation Protocol）框架中，常見工具如 OpenSCAP 、Microsoft SCM（Security Compliance Manager）皆以 CCE 編號作為組態檢查項目的索引。稽核人員可透過 XCCDF（Extensible Configuration Checklist Description Format）格式的政策檔，自動掃描主機組態並對應至 CCE 清單，快速產出合規報告。組織只需維護一份 CCE 對應表，即可同時滿足 PCI-DSS、HIPAA、ISO 27001 等多項法規的技術控制要求，實現 一次設定、多框架對應 的高效稽核流程。 # 使用 OpenSCAP 執行 CCE 對應的基準掃描 oscap xccdf eval \ --profile xccdf_org.ssgproject.content_profile_cis \ --results scan-results.xml \ /usr/share/xml/scap/ssg/content/ssg-rhel9-ds.xml 💡 重點整理 CCE ≠ CVE： CCE 針對組態錯誤，CVE 針對軟體漏洞，兩者互補。 統一語言： CCE 編號讓不同工具與框架以同一識別碼溝通組態問...

為什麼 Code Review 是 SDLC 最划算的安全投資？ 在軟體交付前修復一個安全漏洞的成本，遠低於上線後的緊急修補。 程式碼審查（Code Review） 正是 SDLC 中最具成本效益的安全控制點——在程式碼合併前，系統性攔截安全漏洞與邏輯缺陷。 核心概念：人工審查 vs. 自動化工具的黃金組合 人工審查 擅長發現業務邏輯漏洞、權限設計錯誤與架構層級的安全問題，這類缺陷往往無法被工具偵測。 自動化靜態分析（SAST） 則能高效掃描 SQL Injection、XSS、硬編碼憑證等已知漏洞模式。兩者缺一不可：工具負責覆蓋廣度，人工負責判斷深度。常見 SAST 工具包含 SonarQube、Semgrep 與 Checkmarx，可整合進 CI/CD Pipeline，在每次 Pull Request 時自動觸發掃描，確保問題在合併前即被攔截。 審查重點：安全編碼規範的核心檢查清單 有效的 Code Review 需聚焦於高風險區域。輸入驗證與輸出編碼是首要檢查點，未經處理的使用者輸入是最常見的漏洞根源。其次是 身份驗證與授權邏輯 ，確認每個 API 端點都有適當的存取控制。第三是敏感資料處理，包括密碼、Token 是否明文儲存或出現在日誌中。最後檢查 第三方依賴 的版本與已知 CVE，避免引入含有已知漏洞的套件。 # Semgrep 執行範例：掃描 Python 專案中的安全問題 semgrep --config "p/owasp-top-ten" ./src # 整合至 GitHub Actions（Pull Request 觸發） # on: [pull_request] # run: semgrep --config "p/security-audit" --error 💡 重點整理 左移安全（Shift Left）： 在 PR 階段攔截漏洞，修復成本最低。 人工 + 工具並行： SAST 掃描廣度，人工審查邏輯深度，兩者互補。 聚焦高風險區： 輸入驗證、授權邏輯、敏感資料是優先審查目標。 CI/CD 強制執行： 將安全掃描納入 Pipeline，讓審查流程無法被繞過。 Code Review 不只是品質把關，更是安...

在數位轉型浪潮下， IT 治理 已成為企業不可忽視的核心議題。COBIT 提供一套國際通用的控制框架，協助組織將 IT 管理與業務目標緊密對齊，同時滿足稽核與合規的嚴格要求。 什麼是 COBIT？核心架構解析 COBIT（Control Objectives for Information and Related Technologies） 由 ISACA 制定，目前最新版本為 COBIT 2019。它將 IT 相關活動組織為 40 個治理與管理目標 ，分屬「治理（Governance）」與「管理（Management）」兩大領域。治理層關注董事會層級的方向設定與績效監督；管理層則涵蓋計畫、建置、交付與監控四大範疇（PBRM）。每個目標均定義明確的控制活動與成熟度指標，讓組織能客觀評估自身 IT 能力的落差，並制定改善路徑。 業務目標對齊與稽核合規應用 COBIT 的核心價值在於透過 目標串聯（Goals Cascade） 機制，將企業策略目標逐層轉換為具體的 IT 治理目標與流程指標。稽核人員可依據 COBIT 控制目標，系統性地評估 IT 控制的設計與有效性。此外，COBIT 與 ISO 27001、ITIL、SOX 法規 等主流框架具有良好的對應關係，企業無需重複建置，可直接將現有合規成果映射至 COBIT 控制框架，大幅降低稽核準備成本。對跨國企業而言，COBIT 更是建立統一 IT 治理語言的共通基準。 💡 重點整理 標準化控制目標： 40 個治理與管理目標，提供可量化的 IT 控制基準。 目標串聯機制： 從企業策略到 IT 流程，確保每項投資均能回應業務需求。 跨框架整合： 與 ISO 27001、ITIL、SOX 無縫對應，降低重複合規成本。 稽核共通語言： 提供內外部稽核人員一致的評估標準與成熟度模型。 COBIT 不僅是稽核工具，更是連結 IT 與業務策略的橋樑。導入 COBIT 框架，能協助組織建立持續改善的 IT 治理文化，在合規與創新之間取得平衡。 📚 參考文獻 ISACA 官方 COBIT 資源中心 — COBIT 2019 完整框架文件與工具下載 COBIT 2019 Design Guide — 治理系統設計與目標...

在資安領域， CMS 是一個容易造成混淆的縮寫——它同時代表組態管理系統與內容管理系統，兩者性質迥異，卻都是企業資安防護的關鍵戰場。 ① 組態管理系統（Configuration Management System） 組態管理系統整合 CMDB（組態管理資料庫） ，追蹤企業內所有 IT 資產（CI，Configuration Item）及其相互依賴關係。當漏洞爆發時，CMS 能快速定位受影響的設備與服務，是變更管理與修補程序的決策基礎。 資安風險 在於：若 CMDB 資料過時或不完整，修補盲區將大幅擴大攻擊面。防護重點是維持 CI 資料的即時同步，並對每次變更執行影響分析（Impact Analysis），確保修補範圍不遺漏任何相依項目。 ② 內容管理系統（Content Management System） 以 WordPress 為代表的內容管理系統，因龐大的第三方外掛生態而成為高頻攻擊目標。根據統計，超過 90% 的 WordPress 漏洞 來自外掛與佈景主題，而非核心程式。攻擊手法涵蓋 SQL Injection、XSS 及供應鏈投毒（惡意外掛被植入後門）。防護策略包含：僅安裝活躍維護的外掛、啟用 WAF（Web Application Firewall） 、定期執行外掛完整性掃描，以及限制管理後台的存取 IP 範圍。 💡 雙重 CMS 資安防護要點 CMDB 資料即時性 ：CI 資料落差直接導致修補遺漏，應自動化同步。 外掛供應鏈審查 ：僅使用有明確維護紀錄且來源可信的外掛。 最小權限原則 ：兩類 CMS 均應限制管理存取，採用 MFA 強化驗證。 定期漏洞掃描 ：結合 CVE 資料庫，對 CMS 環境執行自動化弱點評估。 釐清 CMS 的雙重身份，是制定精準防護策略的第一步。無論是組態管理的可視性缺口，還是內容管理的供應鏈風險， 主動式盤點與持續監控 是共同的解方。 📚 參考文獻 ITIL 4 — Configuration Management Practice（官方 ITIL 組態管理指引） Wordfence Threat Intelligence — WordPress 漏洞統計與外掛風險報告 OWASP T...

隨著企業行動化加速， CMPP（行動裝置隱私與保護能力） 成為建立組織行動安全基線的關鍵框架，涵蓋裝置管理、隱私控制與合規生命週期，協助 IT 團隊系統化管理 MDM 與 BYOD 環境。 CMPP 核心架構：安全基線與 MDM 政策 CMPP 框架以 三層防護模型 為核心：裝置層、應用層與資料層。在 MDM 政策面，組織需定義裝置註冊標準、強制加密要求（如 AES-256）及遠端清除能力。 BYOD 環境 需額外區隔企業資料容器與個人空間，防止資料滲漏。安全基線設定包含螢幕鎖定逾時（建議 5 分鐘以內）、禁用不受信任的 App 側載，以及強制啟用 VPN 連線於存取企業資源時。合規驗證需透過定期裝置健康狀態掃描（Device Health Attestation）落實，確保每台受管裝置持續符合政策標準。 隱私保護控制與生命週期管理 CMPP 強調 隱私設計原則（Privacy by Design） 須嵌入裝置生命週期每個階段。從採購階段的硬體安全驗證、部署階段的零觸碰配置（Zero-Touch Enrollment），到退役階段的資料安全抹除（符合 NIST SP 800-88 標準），每個環節均需有可稽核紀錄。 資料保護控制 涵蓋 DLP 政策套用、應用程式權限最小化（僅授予必要感測器與位置存取），以及行為異常偵測。合規管理需整合 SIEM 系統，將裝置事件日誌集中分析，達成持續監控與快速事件回應能力。 # MDM 安全基線政策範例（Microsoft Intune JSON 片段） { "passwordMinLength": 8, "encryptionRequired": true, "screenLockTimeoutSeconds": 300, "remoteWipeEnabled": true, "vpnRequired": "onCorporateAccess" } 💡 CMPP 實踐重點整理 安全基線強制化： 加密、鎖屏、VPN 需透過 MDM 政策自動套用，不依賴使用者自主設定。 BYOD 容器隔離： 企業資料與個人資料須嚴格分區，防止跨容器資料外洩...