-VPN 和 EAP
VPN 服務器可以在沒有 RADIUS 服務器支持的情況下作為身份驗證服務器運行，RADIUS 服務器與 RADIUS 客戶端（VPN 服務器）而不是 VPN 客戶端進行通信。VPN 客戶端可以通過 PEAP 對 VPN 服務器進行身份驗證，“PEAP 是一種將 可擴展身份驗證協議 (EAP) 封裝在加密和經過身份驗證的 傳輸層安全 (TLS) 隧道中的協議”。（維基百科）
802.1X 也稱為 EAP over Lan (EAPoL)，用於局域網訪問控制，特別是有線乙太網路或 WI-FI 網路。802.1X 不是為遠程訪問身份驗證或 VPN 設計的。
“可擴展身份驗證協議 ( EAP ) 是一種經常用於網路和 Internet 連接的身份驗證框架。” （維基百科）EAP 不是用於認證主體的認證協議，而是一種擴展認證協議的協議。
參考
. 誤用案例
. 集成測試
. 系統測試

資料來源： Wentz Wu QOTD-20211025

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

API 是什麼?

API，全名 Application Programming Interface (應用程式介面)，簡單來說，是品牌開發出的一種接口，讓第三方可以額外開發、應用在自身的產品上的系統溝通介面。

來看個短短的、清楚直白的敘述影片：API 就是你的餐廳服務生💁

https://cdn.embedly.com/widgets/media.html?src=https%3A%2F%2Fwww.youtube.com%2Fembed%2FzvKadd9Cflc%3Ffeature%3Doembed&url=http%3A%2F%2Fwww.youtube.com%2Fwatch%3Fv%3DzvKadd9Cflc&image=https%3A%2F%2Fi.ytimg.com%2Fvi%2FzvKadd9Cflc%2Fhqdefault.jpg&key=a19fcc184b9711e1b4764040d3dc5c07&type=text%2Fhtml&schema=youtube

以實際應用的範例而言，Google Map API 就很好理解了，常常可以在各式不同的網站看見 Google Map 應用，很多都是接 Google Map API 的範例，營運考量上，有可能 API 會限制一定使用流量以內免費，超過即收費，Google map 也是如此。

點我查看 Google Maps API 收費標準

在 RESTful API 之前，要再理解一下 HTTP，HTTP 是一種協定，全名 Hypertext Transfer Protocol（超文本傳輸協定），網路世界其實就分為客戶端、伺服器端，舉例說，客戶端就是我，伺服器端就是 Yahoo，我要看 Yahoo 的首頁，我就是向 Yahoo 的伺服器端傳送了這個要求，Yahoo 再回應資源給我。為了讓要求和回應統一規範，就有了 HTTP。

舉例，假設我要吃滷味：

• 在瀏覽器輸入 Yahoo 網址，按下 enter，送出 request (跟老闆說我要切兩塊百頁豆腐)
• 伺服器收到 request 檢查該網址是否存在(老闆轉身看百頁豆腐還有沒有)
• 伺服器發 response 回來(百頁豆腐切好了)

跟老闆點餐的方式，有一定的規範跟方式，像是我一定要用講的，不可以用比的，我要說中文，不可以說英文，這就是 HTTP 協定。

如果伺服器發現網址不存在(老闆發現百頁豆腐賣完了)，就會回傳 HTTP status code 狀態碼 404：

狀態碼又會再分為下幾種：

2xx = Success（成功）
3xx = Redirect（重定向）
4xx = User error（客戶端錯誤）
5xx = Server error（伺服器端錯誤）

在 HTTP 中，會有很多種 method 做為請求的方法，常用的幾個動作分別為：GET / POST / PUT / DELETE，正好會對應到資料庫基本操作 CRUD 增刪查改。

CRUD 為 Create(新增)、Read(讀取)、Update(更新)與Delete(刪除)的縮寫

那 RESTful API 又是什麼?

先來看是誰發明的↓

REST，全名 Representational State Transfer( 表現層狀態轉移)，他是一種設計風格，RESTful 只是轉為形容詞，像是 peace 和平這名詞，轉成形容詞是 peaceful，RESTful 則形容以此規範設計的 API，稱為 RESTful API。

先用白話來說，以剛剛 API 影片中的餐廳服務生為例，如果使用一般的 API 點菜，我要加點、查看已點菜色、修改已點菜色、取消已點菜色，都需要不同的服務生替我服務，可能加點的服務生是 John、查看已點菜色是 Annie….等，RESTful API，就是讓這些動作，都可以由同一位服務生完成。

RESTful API 主要由三種元件組成：

1. Nouns 名詞：定義資源位置的 URL，每個資源在網路上都會有唯一的位置，就如每戶人家都有唯一的地址一樣。
2. Verbs 動詞：對資源要做的動作。
3. Content Types 資源呈現方式：API 資源可以以多種方式表現，最常用的是 JSON，較輕，也較好處理。

一般的 API，可能會是這樣：

獲得資料GET    /getData
新增資料POST   /createData
刪除資料DELETE /deleteData/1

不同公司，不一樣的工程師，設計的名稱都會不一樣，沒有統一的命名方式，造成在引用各家 API 時，都需要詳讀 API 文件，理解所有設計命名規則後，才可使用。

若以 RESTful API 風格開發的話：

獲得資料GET     /data
新增資料POST    /data
刪除資料DELETE  /data/1

就是用一個唯一的 URL 定位資源，將動作藏在 HTTP 的 method 裡面。

所以使用 RESTful 風格設計的 API，就有了以下幾種優點及限制：

1. 有唯一的URL表示資源位置，統一的 API 接口。(Uniform Interface)

2. 無狀態。(Stateless)

RESTful 的狀態，意即 HTTP 的請求狀態，一般 Web 服務中，Server 端和 Client 端交互的資訊，會存在 Server 端的 Session (例如：已登入狀態)，在 Client 端再次發送請求的時候，Server 端透過保存在 Server 端的 Session，去執行 request。無狀態的意思，即 Client 端自行保存狀態，在請求 Server 的時候，一併附上給 Server 端，Server 端無保存 Client 端的狀態資訊。

舉例來說，可能在用戶登錄系統時，Server 產生 token 紀錄 user 已登錄系統，然後把 token 還給 Client，在 Client 再次發送請求的時候，把 token 一起發給 Server，這樣 Server 就知道這一個 Client 是已經處於登錄的狀態。

意即所有的資源都可以 URI 定位，而且這個定位與其他資源無關，也不會因為其他資源的變化而變化，資源相互的依賴性降低。

舉一個白話一點的例子：查詢員工工資：
第一步：登錄系統。
第二步：進入查詢工資的頁面。
第三步：搜索該員工。
第四步：點擊姓名查看工資。

這樣的操作流程就是有狀態的，查詢工資的每一個步驟都依賴於前一個步驟，只要前置操作不成功，後續操作就無法執行。如果輸入一個URL就可以直接得到指定員工的工資，這種情況就是無狀態的，因為獲取工資不依賴於其他資源或狀態，這種情況下，員工工資是一個資源，由一個 URL 與之對應可以通過 HTTP 中的 GET 方法得到資源，這就是典型的 RESTful 風格。

3. 可更高效利用快取來提高回應速度 (Cachable)

在 server-side，GET 過的資源，如果沒有被變更過，可以利用 cache 機制減少 request。
在 client-side，透過 client 端 cache 紀錄 cache 版本，若向 server 要求資源時發現 server 最新版與 cache 相同，則 client 端直接取用本地資源即可，不需要再做一次查詢

4. 分層系統架構 (Layered System)

5. 客戶端服務器分離 (Client-Server)

6. 充份利用 HTTP protocal(GET/POST/PUT/DELETE) (Manipulation of resources through representations)

7. 可執行程式碼的設計，像是 JavaScript（非必要實作項目） Code-On-Demand (optional)

參考文章：
https://zh.wikipedia.org/wiki/%E8%A1%A8%E7%8E%B0%E5%B1%82%E7%8A%B6%E6%80%81%E8%BD%AC%E6%8D%A2
https://tw.alphacamp.co/blog/2016-10-25-coding-basics-for-marketers-1
https://ithelp.ithome.com.tw/articles/10157431
https://www.itread01.com/content/1544242329.html
https://progressbar.tw/posts/53
https://blog.csdn.net/hjc1984117/article/details/77334616
https://www.zhihu.com/question/28557115
https://blog.csdn.net/hjc1984117/article/details/77334616
http://www.ruanyifeng.com/blog/2011/09/restful.html
https://blog.toright.com/posts/5523/restful-api-%E8%A8%AD%E8%A8%88%E6%BA%96%E5%89%87%E8%88%87%E5%AF%A6%E5%8B%99%E7%B6%93%E9%A9%97.html
https://blog.csdn.net/Jmilk/article/details/50461577
https://blog.csdn.net/matthew_zhang/article/details/63410421

資料來源：https://medium.com/itsems-frontend/api-%E6%98%AF%E4%BB%80%E9%BA%BC-restful-api-%E5%8F%88%E6%98%AF%E4%BB%80%E9%BA%BC-a001a85ab638

VPN就是透過tunneling技術, 把公眾/共用網路當作(模擬成)網路線來連接公司的電腦及網路. 由於使用公眾/共用網路, 因此必須搭配安全服務(如身份驗證, 金鑰交換, 加密, 完整性控制)才能安全地在tunnel上傳輸資料.
VPN = 建立私有通道(tunneling) + 提供安全服務(security services)
https://wentzwu.com/2022/05/18/vpn-tunneling-and-security-services/

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

-代碼倉庫：git
顧名思義，整合測試結合了代碼單元、模組或子系統並對其進行測試。在託管代碼儲存庫的服務器上進行整合測試是很常見的，例如 git 服務器。
在持續整合設置中，當滿足構建標準（夜間構建或新代碼簽入）時，服務器開始構建代碼並運行簽入代碼存儲庫的所有單元測試。如果構建或任何測試失敗，則會向相關方發送通知以解決問題，直到一切正常；這種迭代過程稱為回歸測試。

模組或子系統通常通過所謂的 API（應用程序編程接口）相互通信。API 測試沒有用戶界面，依賴於測試工具來提供數據作為輸入並接收結果作為輸出。Fuzzer 是Fuzz 測試中使用的工具，可幫助生成隨機測試數據以饋入接口測試。

系統測試在整合測試完成後開始，例如壓力測試、性能測試、安全測試等。大部分系統測試任務都可以自動化。一旦自動化任務完成，測試人員就會參與進來。他們根據包含一個或多個場景或用例的測試用例來測試系統。誤用案例基本上是採取攻擊者觀點的用例。

參考
. 誤用案例
. 整合測試
. 系統測試

資料來源： Wentz Wu QOTD-20211024

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

-XP 實踐（來源：https ://twitter.com/CharlotteBRF ）
結對編程是眾所周知的極限編程 (XP) 實踐之一。這也是一種實時代碼審查的實踐；同行開發人員在其他開發人員編寫代碼時即時監控和審查。
命名約定（Naming convention）、SQL 注入（SQL injection）和邏輯炸彈（logic bomb）在源代碼級別很容易被發現。然而，像死鎖這樣的競爭條件通常會不時發生在運行時（動態測試），並且很難在設計時識別（靜態測試）。競爭條件是由多線程、並行編程或多用戶環境導致的並發問題。
參考
. 代碼審查清單——執行有效的代碼審查
. 任何開發人員都應該知道的 4 種代碼審查類型
. 五種審查

資料來源： Wentz Wu QOTD-20211023

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

CMMI、CMMC、BSIMM 和 SAMM 是評估軟體開發能力的好模型。但是BSIMM 是衡量一個組織在安全性方面相對於其他組織執行情況的最佳方法。
成熟度模型中的安全構建 (BSIMM) 是對當前軟件安全計劃或程序的研究。它量化了跨行業、規模和地域的不同組織的應用程式安全 (appsec) 實踐，同時確定了使每個組織獨一無二的變化。

BSIMM 包括：
對組織當前的appsec 計劃 提供客觀、數據驅動的評估的評估
成為提供協作、最佳實踐和獨家內容的安全同行社區的成員
全球會議 ，包括來自安全領導者的主題演講、交流機會以及交流技術和實踐的論壇
一份年度報告 （目前為 BSIMM12），提供對現實世界軟件安全計劃、實踐和活動的數據驅動分析
資料來源：BSIMM

參考
. OWASP SAMM
. 網絡安全成熟度模型認證
. 負責採辦和維持的國防部副部長辦公室 (OUSD(A&S))
. 關於 BSIMM
. 能力成熟度模型集成 (CMMI)

資料來源： Wentz Wu QOTD-20211022

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

網路功能虛擬化 (NFV) 通常使用專有服務器來運行網路服務以提高性能。
根據Wikipedia的說法，“NFV 部署通常使用商品服務器來運行以前基於硬體的網路服務軟體版本。”

-SDN架構

-SDP架構

-核心零信任邏輯組件（來源：NIST SP 800-207）

參考
. 軟體定義網路
. 軟體定義的邊界：SDP 的架構視圖
. SDP 和零信任
. 軟體定義邊界 (SDP)：創建新的網路邊界
. SDP（軟體定義定義）讓SDN更安全，你的對面不能是一條狗！

資料來源： Wentz Wu QOTD-20211018

-示例 XACML 實現
XACML主要用於授權而不是身份驗證。可以實施 PKI 以支持相互身份驗證。802.1X，又名 EAP over LAN，是一種基於 EAP 的網路存取控制標準。HTTP Basic Authentication 是一種純文本的身份驗證方案；但是，它可以受到 TLS/SSL 的保護。

XACML 代表“可擴展存取控制標記語言”。該標准定義了一種聲明性的細粒度、基於屬性的存取控制策略語言、一種體系結構和一個處理模型，描述瞭如何根據策略中定義的規則來評估存取請求。
作為已發布的標準規範，XACML 的目標之一是促進多個供應商的存取控制實現之間的通用術語和互操作性。XACML 主要是基於屬性的存取控制系統 (ABAC)，也稱為基於策略的存取控制 (PBAC) 系統，其中與用戶或操作或資源相關聯的屬性（數據位）被輸入到決定是否給定用戶可以以特定方式存取給定資源。基於角色的存取控制 (RBAC) 也可以在 XACML 中實現，作為 ABAC 的專門化。
XACML 模型支持並鼓勵將執行 (PEP) 與決策 (PDP) 與授權的管理/定義 (PAP) 分離。當訪問決策在應用程序中硬編碼（或基於本地機器用戶 ID 和存取控制列表 (ACL)）時，當管理策略發生變化時很難更新決策標準，並且很難實現對應用程序的可見性或審計授權到位。當客戶端與存取決策分離時，授權策略可以即時更新並立即影響所有客戶端。
資料來源：維基百科

資料來源： Wentz Wu QOTD-20211010

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

PKI 證書編碼(PKI Certificate Encoding)
X.509 標準中未定義的一個值得注意的元素是證書內容應如何編碼以存儲在文件中。但是，通常有兩種編碼模式用於將數字證書存儲在文件中：
可分辨編碼規則 (Distinguished Encoding Rules:DER) – 最常見，因為架構處理大多數數據對象。DER 編碼的證書是二進製文件，不能被文本編輯器讀取，但可以被 Web 瀏覽器和許多客戶端應用程序處理。
隱私增強郵件 (Privacy Enhanced Mail:PEM) – 一種加密的電子郵件編碼模式，可用於將 DER 編碼的證書轉換為文本文件。
資料來源：Sectigo

參考
. 什麼是 X.509 證書及其工作原理？
. SSL 證書文件擴展名說明：PEM、PKCS7、DER 和 PKCS#12
. 數字證書

資料來源：Wentz Wu QOTD-20211009

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