作者: stevencho

蠕蟲可以主動利用網路服務漏洞或被動使用群發郵件來傳播自身。但是，只有當用戶執行附加到電子郵件的惡意代碼時，它才會變為活動狀態。
. 病毒不會自我複制；它可以被操作系統（例如編譯病毒）或應用程序（例如巨集病毒）加載和執行。
. “惡意移動代碼是具有惡意意圖的軟體，從遠程主機傳輸到本地主機，然後在本地主機上執行，通常沒有用戶的明確指令。惡意移動代碼的流行語言包括 Java、ActiveX、JavaScript 和 VBScript。” (NIST SP 800-83 R1)
惡意移動代碼不涉及移動應用程序，並且在沒有用戶明確指示的情況下穿越移動設備。
. 特洛伊木馬不會自我複制。這是一個自成一體的程式，似乎是良性的，但實際上有一個隱藏的惡意目的。

參考
. NIST SP 800-83 R1

資料來源： Wentz Wu QOTD-20210831

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

以下是 NIST SP 800-204B 的摘錄：
可以通過配置身份驗證和存取控制策略來實施對微服務的細粒度存取控制。這些策略在服務網格的控制平面中定義，映射到低級配置，並推送到構成服務網格數據平面的邊車代理（sidecar proxies）中。
授權策略，就像它們的身份驗證對應物一樣，可以在服務級別和最終用戶級別指定。此外，授權策略是基於存取控制模型的構造來表達的，並且可能會根據應用程序和企業級指令的性質而有所不同。此外，存取控制數據的位置可能因企業中的身份和存取管理基礎設施而異。這些變化導致以下變量：
● 兩個授權級別——服務級別和最終用戶級別
● 用於表達授權策略的存取控制模型
● 存取控制數據在集中或外部授權服務器中的位置或作為頭數據攜帶
服務網格中支持的存取控制使用抽象來分組一個或多個策略組件（在第 4.5.1 節中描述），用於指定服務級別或最終用戶級別的授權策略。由於基於微服務的應用程序被實現為 API（例如，表現層狀態轉換(REST)ful API），使用鍵/值對描述的授權策略組件將具有與 API 相關的屬性，包括相關的網絡協議。授權策略的類型有：
● 服務級授權策略
● 最終用戶級授權策略
● 基於模型的授權策略

參考
. NIST SP 800-204B

資料來源： Wentz Wu QOTD-20210830

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

-VPN 訪問（來源：ActForNet）
VPN 是一種通過隧道連接節點的虛擬網路。L2F、PPTP 和 L2TP 是早期的隧道協議。通過 VPN 隧道傳輸的數據通常由安全協議加密，例如 SSL/TLS、IPsec、SSH、MPPE。
L2F 不提供加密。PPTP 使用 MPPE（Microsoft 點對點加密）加密數據。L2TP 本身建立隧道但不加密數據；它通常通過 IPsec 強制保密。
“Secure Shell (SSH)是一種加密網路協議，用於在不安全的網路上安全地運行網路服務。” （維基百科）它可用於建立 SSH VPN 或與其他隧道協議一起使用。

-SSH隧道

參考
. NIST SP 800-77 R1
. NIST SP 800-113
. 如何使用 SSH 配置端口轉發
. 如何找到SSH隧道

資料來源： Wentz Wu QOTD-20210827

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

-數字身份模型（來源：NIST SP 800 63-3）
“秘密”是用於驗證主體身份的最關鍵元素。一個認證是秘密的載體，例如，密碼，在你的大腦記憶（你知道的），私有密鑰儲存在令牌設備（你有什麼），或生物識別嵌入在你的身體（你是）。
 生物識別（您的身份）不足以構成秘密，因為它可能會暴露給公眾。例如，您的自拍可能會讓您容易受到黑客的攻擊。NIST SP 800-63 系列指南“僅允許在與物理身份驗證器強綁定時使用生物識別技術進行身份驗證。”
 用於基於知識的身份驗證的認知密碼是您知道的一種形式，但它們也不是秘密。顧名思義，它們就是知識。
 基於位置的身份驗證（您所在的某個地方）不是身份驗證因素。
以下是 NIST SP 800-63-3 的摘錄：
身份驗證系統的經典範例將三個因素確定為身份驗證的基石：
• 您知道的東西（例如，密碼）。
• 您擁有的東西（例如，ID 徽章或加密密鑰）。
• 您的身份（例如，指紋或其他生物特徵數據）。

MFA是指使用以上因素中的一種以上。
身份驗證系統的強度在很大程度上取決於系統所包含的因素的數量——採用的因素越多，身份驗證系統就越強大。就這些準則而言，使用兩個因素足以滿足最高的安全要求。
如第 5.1 節所述，RP 或驗證者可以使用其他類型的信息（例如位置數據或設備身份）來評估所聲明身份中的風險，但它們不被視為身份驗證因素。
在數字認證申請人擁有和控制的一個或多個鑑定人已註冊與CSP和用於證明申請人的身份。身份驗證器包含索賠人可以用來證明他或她是有效訂戶的秘密，索賠人通過證明他或她擁有和控制一個或多個身份驗證器來對網路上的系統或應用程序進行身份驗證。
在本卷中，身份驗證器始終包含一個秘密。一些經典的身份驗證因素並不直接適用於數字身份驗證。例如，物理駕駛執照是您擁有的東西，並且在向人類（例如保安人員）進行身份驗證時可能很有用，但它本身並不是數字身份驗證的身份驗證器。
歸類為您所知的身份驗證因素也不一定是秘密。 基於知識的身份驗證，其中提示申請人回答可能只有申請人知道的問題，也不構成數字身份驗證可接受的秘密。一個生物特徵也並不能構成一個秘密。因此，這些指南僅允許在與物理身份驗證器強綁定時使用生物識別技術進行身份驗證。
來源：NIST SP 800-63-3

參考
. NIST SP 800-63-3
. 你的自拍可能會讓你容易受到黑客攻擊
. 化妝和假手指——領先於網絡騙子
. 照片中隱藏的指紋

資料來源： Wentz Wu QOTD-20210825

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

-API 網關和服務網格（來源：Liran Katz）

服務網格（service mesh）是便於一個專用基礎設施層服務對服務的通信通過服務發現，路由和內部負載均衡，流量的結構，加密，認證和授權，指標和監測。
它提供了在由於服務實例脫機和不斷重定位而導致網路拓撲變化的環境中通過策略聲明性地定義網路行為、節點身份和流量流的能力。
它可以被視為一種網路模型，它位於開放系統互連 (OSI) 模型（例如，傳輸控制協議/互聯網協議 (TCP/IP)）的傳輸層之上的抽象層，並處理服務的會話層（OSI 模型的第 5 層）關注。然而，細粒度的授權可能仍然需要在微服務上執行，因為這是唯一完全了解業務邏輯的實體。
服務網格概念上有兩個模塊——數據平面和控制平面。在數據平面承載通過服務特定代理服務實例之間的應用請求的流量。所述控制平面配置數據平面，提供了一種用於遙測點聚集，以及用於通過各種特徵，諸如負載平衡，斷路，或速率限制修改網路的行為提供API。
來源：NIST SP 800-204

參考
. NIST SP 800-204
. 邊車模式(Sidecar pattern)

資料來源： Wentz Wu QOTD-20210824

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

-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:此文章經過作者同意刊登 並且授權可以翻譯成中文