月份: 2021 年 10 月

-API 閘道器和服務網格（來源：Liran Katz）
實施 API 閘道器以促進跨境通信；他們控制著南北和東西向的交通。外部或邊緣 API 閘道器將來自客戶端的入站請求路由到適當的服務；內部 API 閘道器促進了各種服務網格範圍之間的通信。服務網格促進特定範圍內的服務到服務通信。
API 閘道器架構可以是整體式的，也可以是分佈式的。
在整體式API 閘道器架構中，通常只有一個 API 閘道器部署在企業網路的邊緣（例如，非軍事區 (DMZ)），並在企業級為 API 提供所有服務。
在分佈式API閘道器架構中，有多個微閘道器實例，部署在更靠近微服務API的地方。微閘道器通常是低的覆蓋區，其可以被用來定義和執行自定義策略，因此適合用於基於微服務的應用程序，必須通過特定的服務的安全策略來保護可腳本API閘道器。
微閘道器通常作為使用 Node.js 等開發平台的獨立容器實現。它不同於服務網格架構的 sidecar 代理，後者是在 API 端點本身實現的。
來源：來源：NIST SP 800-204

服務網格(Service Mesh)
服務網格是一個專用的基礎設施層，它通過服務發現、路由和內部負載平衡、流量配置、加密、身份驗證和授權、指標和監控來促進服務到服務的通信。
服務網格為微服務應用程序中的每個服務創建一個小型代理服務器實例。這種專門的代理汽車有時在服務網格術語中被稱為“ sidecar 代理”。Sidecar 代理形成了數據平面，而執行安全性（訪問控制、通信相關）所需的運行時操作是通過從控制平面向 sidecar 代理注入策略（例如訪問控制策略）來啟用的。這也提供了在不修改微服務代碼的情況下動態更改策略的靈活性。
來源：NIST SP 800-204

API閘道器(API Gateway)
API 閘道器的主要功能是始終將入站請求路由到正確的下游服務，可選擇執行協議轉換 （即 Web 協議之間的轉換，例如 HTTP 和 WebSocket，以及內部使用的 Web 不友好協議，例如作為 AMQP 和 Thrift 二進制 RPC)並且有時組合 requests。在極少數情況下，它們被用作前端后端 (BFF) 的一部分，從而支持具有不同外形因素（例如，瀏覽器、移動設備）的客戶端。
來自客戶端的所有請求首先通過 API 閘道器，然後將請求路由到適當的微服務。API 閘道器通常會通過調用多個微服務並聚合結果來處理請求。
由於API閘道器是微服務的入口點，所以它應該配備必要的基礎服務（除了其主要的請求整形服務），如服務發現、認證和存取控制、負載平衡、緩存、提供自定義API對於每種類型的客戶端，應用感知健康檢查、服務監控、攻擊檢測、攻擊響應、安全日誌記錄和監控以及斷路器。
來源：NIST SP 800-204

參考
. NIST SP 800-204
. 網路層複習
. 服務網格與 API 閘道器：有什麼區別？
. API 閘道器和服務網格的區別
. API 閘道器與服務網格
. API 閘道器和服務網格：打開應用現代化的大門

資料來源： Wentz Wu QOTD-20210823

PS:此文章經過作者同意刊登 並且授權可以翻譯成中文

-微服務架構
微服務是一種分佈式架構風格。它具有多種優點，例如：
. 可以提高可擴展性。
. 開發團隊可以獨立工作並變得更加敏捷。
. 服務的獨立性提高了代碼的可重用性。
. 系統的整體架構可以與組織結構保持一致。
但是，由於分佈式架構的性質，微服務的可用性、可管理性和監控可能需要更多的開銷。可擴展性和可用性的概念經常被混淆。可伸縮性是關於服務可以服務多少客戶端，而可用性是客戶端可以可靠和及時地訪問服務的程度。
服務或系統可以採用不同的可擴展性策略，例如，縱向擴展或橫向擴展。擴展策略可能不會提高可用性。橫向擴展策略在不同程度上有助於提高可用性，例如，沒有心跳檢查的基於 DNS 的循環負載均衡器呈現的可用性程度低於檢查服務健康狀態的基於集群的負載均衡器。
以下是 NIST SP 800-204 的摘錄：

微服務的優勢
. 對於大型應用程序，將應用程序拆分為鬆散耦合的組件可以實現分配給每個組件的開發團隊之間的獨立性。然後，每個團隊都可以通過選擇自己的開發平台、工具、語言、中間件和硬件來優化，基於它們對正在開發的組件的適用性。
. 每個組件都可以獨立縮放。資源的有針對性的分配導致資源的最大利用。
. 如果組件具有 HTTP RESTful 接口，只要接口保持不變，就可以在不中斷應用程序整體功能的情況下更改實現。
. 每個組件中涉及的代碼庫相對較小，使開發團隊能夠更快地生成更新，並為應用程序提供響應業務流程或市場條件變化的敏捷性。
. 組件之間的鬆散耦合能夠抑制微服務的中斷，從而將影響限制在該服務上，而不會對其他組件或應用程序的其他部分產生多米諾骨牌效應。
. 當組件使用異步事件處理機制鏈接在一起時，組件中斷的影響是暫時的，因為所需的功能將在組件再次開始運行時自動執行，從而保持業務流程的整體完整性。
. 通過將服務定義與業務能力對齊（或通過基於業務流程或能力的整體應用程序功能的分解邏輯），基於微服務的系統的整體架構與組織結構保持一致。當與組織單位相關的業務流程發生變化並因此需要修改和部署相關服務時，這促進了敏捷響應。
. 微服務的獨立功能特性促進了跨應用程序的代碼更好的可重用性。
. 必須監控多個組件（微服務）而不是單個應用程序。需要一個中央控制台來獲取每個組件的狀態和應用程序的整體狀態。因此，必須創建具有分佈式監控和集中查看功能的基礎設施。
. 多個組件的存在會造成可用性問題，因為任何組件都可能隨時停止運行。
. 一個組件可能必須為某些客戶端調用另一個組件的最新版本，並為另一組客戶端調用同一組件的先前版本（即版本管理）。
. 運行集成測試更加困難，因為需要一個測試環境，其中所有組件都必須工作並相互通信。
. 當基於微服務的應用程序內的交互設計為 API 調用時，必須實現安全 API 管理所需的所有必要流程。
. 微服務架構可以分解縱深防禦的做法。許多架構都有一個運行在 DMZ 中的 Web 服務器，預計會受到威脅，然後是 Web 服務器與之通信的後端服務，最後是後端服務與之通信的數據庫。後端服務可以充當暴露的 Web 服務器和數據庫中的敏感數據之間更堅固的層。微服務架構往往會破壞這一點，現在 Web 服務器和後端服務被分解為微服務，可能比以前的模型暴露得更多。這會導致調用者和敏感數據之間的保護層更少。因此，安全地設計和實現微服務本身以及服務網格或API 網關部署模型。

參考
. NIST SP 800-204

資料來源： Wentz Wu QOTD-20210822

PS:此文章經過作者同意刊登 並且授權可以翻譯成中文

-面向服務的架構 (SOA)
面向服務的架構 (SOA) 可以通過 Web 服務或微服務來實現。Web 服務方法導致 SOA，而微服務架構是 SOA 的擴展。基於 SOA 的企業應用程序集成 (EAI) 通常為企業應用程序實現共享的企業服務總線 (ESB) 以交換消息。微服務託管在一個或多個容器中，這些容器在 Google Kubernetes (K8S)、Docker Swarm 或 Apache Mesos 的編排下協作。

面向服務的架構 (SOA)
服務是一個自包含的松耦合邏輯。在 SOA 中，傳統的單體應用程序被劃分為協作以實現共同目標的服務。服務提供商向私人或公共服務註冊機構註冊服務；服務消費者根據註冊中心查找或發現感興趣的服務以消費（綁定和調用）這些服務。
-SOA 的查找-綁定-執行範式（來源：Qusay H. Mahmoud）
“幾年前，IBM、微軟和 SAP 曾經託管公共 UDDI 服務器，但現在已經停產了。”

~ user159088 on stackoverflow

-SOA 元模型，The Linthicum Group，2007

微服務
微服務：微服務是一個基本元素，它源於將應用程序的組件架構分解為鬆散耦合的模式，這些模式由自包含的服務組成，這些服務使用標准通信協議和一組定義良好的 API 相互通信，獨立於任何供應商、產品或技術。
微服務是圍繞能力構建的，而不是服務，構建在 SOA 之上，並使用敏捷技術實現。微服務通常部署在應用程序容器內。
資料來源：NIST SP 800-180（草案）

容器編排

-Mesos、Swarm 和 Kubernetes（來源：Nane Kratzke）

-Kubernetes 架構（來源：Dorothy Norris）

參考
. SOA宣言
. 面向服務的架構
. 是否有任何公共 UDDI 註冊中心可用？
. UDDI 註冊中心：可由啟用總線的 Web 服務引用的 Web 服務目錄
. 模式：微服務架構
. 2019年容器編排
. 使用 Kubernetes、Docker Swarm 和 Mesos 進行 Neo4j 容器編排
. Kubernetes vs. Mesos——架構師的視角
. Apache Mesos PNG 4
. SOA 與微服務：有什麼區別？
. 企業服務總線
. 企業應用集成
. 面向服務的架構 (SOA) 和 Web 服務：企業應用程序集成 (EAI) 之路
. 面向服務架構的 Web 服務方法

資料來源： Wentz Wu網站

PS:此文章經過作者同意刊登 並且授權可以翻譯成中文

-NIST 通用風險模型 (NIST SP 800-30 R1)
NIST 通用風險模型描述了威脅源如何發起利用漏洞導致不利影響的威脅事件（例如，TTP、策略、技術和程序）。垃圾郵件發送者、恐怖分子和機器人網絡運營商是威脅來源，而網絡釣魚則是威脅事件。
風險與威脅

-什麼是風險？

資料來源： Wentz Wu QOTD-20210818

PS:此文章經過作者同意刊登 並且授權可以翻譯成中文

-CVSS 指標組（來源：FIRST）
通用漏洞評分系統 (CVSS) 標准定義了三個指標組：基本、時間和環境指標組。基本指標組是強制性的，而時間和環境指標組是可選的。
基本指標組有兩個指標集，可利用性指標和影響指標，用於評估風險。風險包括兩個關鍵因素：不確定性（可能性或可能性）和影響（影響）。針對風險可能性或可能性的漏洞可利用性標準。如果一個風險的可能性很大，但對安全目標（機密性、完整性和可用性）沒有影響，那麼它就無關緊要或不是風險。

-CVSS 度量和方程（來源：FIRST）

參考
. 通用漏洞評分系統 v3.1：規範文檔
. 常見漏洞評分系統計算器

資料來源： Wentz Wu QOTD-20210817

PS:此文章經過作者同意刊登 並且授權可以翻譯成中文

-網路安全挑戰
虛擬可擴展局域網 (Virtual eXtensible Local Area Network :VXLAN)
虛擬可擴展 LAN (VXLAN) 是一種網路虛擬化技術，旨在解決與大型雲計算部署相關的可擴展性問題。VXLAN 規範最初由 VMware、Arista Networks 和 Cisco 創建。（維基百科）
它是一個軟體定義的覆蓋網路，它使用類似 VLAN 的封裝技術將 OSI 第 2 層以太網幀封裝在第 4 層 UDP 數據報中，使用 4789 作為 IANA 分配的默認目標 UDP 端口號。最常見的應用之一是連接docker 容器的覆蓋網路。

-Docker 覆蓋網路（來源：nigelpoulton）

軟體定義網路 (Software Defined Networks：SDN)
軟體定義網路 (SDN) 技術是一種網路管理方法，它支持動態的、以編程方式高效的網路配置，以提高網路性能和監控，使其更像雲計算，而不是傳統的網路管理。SDN 試圖通過將網路數據包的轉發過程（數據平面）與路由過程（控制平面）分離，將網路智能集中在一個網路組件中。控制平面由一個或多個控制器組成，這些控制器被認為是整合了整個智能的 SDN 網路的大腦。
資料來源：維基百科

-SDN架構
軟體定義的邊界 (Software Defined Perimeter：SDP)
軟體定義邊界 (SDP)，也稱為“黑雲”，是一種計算機安全方法，它從 2007 年左右在全球信息網格 (GIG) 黑色核心網路計劃下國防信息系統局 (DISA) 所做的工作演變而來.
軟體定義邊界 (SDP) 框架由雲安全聯盟 (CSA) 開發，用於根據身份控制對資源的訪問。軟體定義邊界中的連接基於需要知道的模型，在該模型中，在授予對應用程序基礎設施的訪問權限之前驗證設備狀態和身份。
軟體定義的邊界通過使應用程序所有者能夠部署邊界來解決這些問題，這些邊界保留了傳統模型對外部不可見和不可訪問的價值，但可以部署在任何地方——在互聯網上、在雲中、在託管中心、在私人公司網路，或跨越部分或所有這些位置。
資料來源：維基百科

-SDP架構

參考
. 微分段
. 什麼是微分段？
. 微分段與網路分段的區別
. 微分段：網路安全的下一次演變
. 2021 年最佳零信任安全解決方案
. 什麼是微分段？（帕洛阿爾托）
. 什麼是微分段？(VMware)
. 什麼是 VMware 虛擬化環境中的工作負載管理
. 軟體定義邊界中的微分段
. SD-WAN、SDP、ZTNA……它們真的有那麼不同嗎？
. 安全智庫：SDN、容器、加密和SDP的安全作用
. 軟體定義的邊界：SDP 的架構視圖
. 利用微分段構建全面的數據中心安全架構
. 使用 NSX-T 3.0 為 VLAN 微分段準備集群

資料來源： Wentz Wu QOTD-20210815

PS:此文章經過作者同意刊登 並且授權可以翻譯成中文

-計算機架構

作為解決方案最重要的工件，架構是一個對象（解決方案）從各種觀點或角度的概念、邏輯和物理表示，它確定了它的構建塊、關係、交互、邊界、接口、環境和上下文以及指導解決方案在其整個生命週期中的演變。
~ 吳文智

定義
. 系統或解決方案的一組相關的物理和邏輯表示（即視圖）。該體系結構在不同抽象級別和不同範圍內傳達有關係統/解決方案元素、互連、關係和行為的信息。（來源：NIST SP 800-160 第 1 卷）
. 與描述對象相關的一組設計人工製品或描述性表示，以便它可以按要求（質量）生產並在其使用壽命（變更）期間保持不變（來源：Zachman：1996，ISO/TR 20514:2005)
. 體現在其組件中的系統的基本組織、它們之間的關係以及與環境的關係，以及指導其設計和演變的原則（來源：ISO/IEC 15288:2008）
. 一套系統的概念和規則，描述了整個系統中實體之間的相互關係，獨立於硬體和軟體環境
注 1：架構是通過一系列可能處於不同級別的通用性的觀點來描述的/ specificity、abstraction/concept、totality/component等等。另請參見下文中的“通信視點”、“功能視點”、“組織視點”和“物理視點”定義。（來源：ISO/TR 26999:2012）
. 系統在其環境中的基本概念或屬性，體現在其元素、關係以及其設計和演變的原則中 (ISO/IEC/IEEE 42010:2011)
. 項目或元素的結構表示，允許識別構建塊、它們的邊界和接口，並包括對這些構建塊的需求分配（來源：ISO 26262-1:2018）
. 系統的概念結構
注 1：一個系統可能由幾個相互作用的子系統組成，每個子系統都有自己的體系結構。（來源：ISO/IEC TR 29108:2013）
. 邏輯結構和與組織和業務環境的相互關係所依據的一組原則
注 1：軟體架構是軟體設計活動的結果。（來源：ISO/TR18307:2001）
. 系統中硬體和軟體元素的特定配置（來源：IEC 61508-4）

資料來源： Wentz Wu網站

PS:此文章經過作者同意刊登 並且授權可以翻譯成中文