參考鏈接： 微服務介紹

在整體式架構中，由于運行應用程序的運行時環境相對隔離，所以治理和安全保護很簡單。微服務架構具有典型的革新特征，給活動的治理和應用程序的安全威脅保護帶來了更多挑戰。? 微服務架構中的安全性?

微服務架構通過定義分布式特征來獲得靈活性，系統中的服務能夠以分散方式獨立開發和部署。從安全角度講，這種開放架構的一個缺陷是，系統現在更脆弱，因為攻擊面增加了。開放的端口更多，API 是公開的，而且安全保護變得更復雜，因為需要在多個位置執行安全保護。本節將簡要介紹在設計受微服務啟發的系統時要考慮的一些安全方面。? 身份驗證和授權?

身份驗證和授權是兩個核心流程，在嘗試與 IT 系統交互時通常涉及這兩個流程。這些核心流程可以確保系統面對攻擊時的安全性：?

身份驗證是確認系統項目干系人具有他們聲明的身份的過程。在人類世界，項目干系人通常通過提供用戶名和密碼對來進行身份驗證。有一些先進、復雜的機制可用來執行身份驗證；這些機制可能包括生物特征身份驗證、多因素身份驗證等。被驗證的對象（人或特定的子系統）通常被稱為主體。

授權機制用于確定允許一個主體在系統上執行哪些操作，或者主體可訪問哪些資源。授權流程通常在身份驗證流程后觸發。通常，當主體通過身份驗證后，會提供主體的信息來幫助確定該主體能夠和不能執行哪些操作。

?

在整體式應用程序中，身份驗證和授權簡單而又普通，因為它們由應用程序實際處理；不需要擁有高級機制來提供更安全的用戶體驗。但是，在具有典型的分布式特征的微服務架構中，必須采用更高級的模式來避免提供憑證的服務調用之間的反復攔截。您希望一次可以驗證主體的一個身份。這個身份簡化了身份驗證和授權流程，利用了自動化功能，并提高了可擴展性。?

避免冗余地提供用戶名和密碼的一個著名解決方案是使用單點登錄 (SSO) 方法。一些流行的 SSO 實現提供了這項功能。示例包括 OpenID Connect、SAML、OAuth2 等。每種實現適合一種特定的業務用例。表 1 對比了這些方法。? 表 1 對比 SAML、OpenID Connect 和 OAuth?

考慮因素SAMLOpenID ConnectOAuth2身份驗證 是 是 偽身份驗證授權 是 否 是傳輸 HTTP Redirect (GET)綁定、SAML SOAP 綁定、HTTP POST 綁定等 HTTP Get, Post HTTP令牌格式 XML JSON JSON 或 SAML2安全隱患XML Signature Wrapping to impersonate any user網絡釣魚。 OAuth 2.0 不支持簽名，加密，渠道綁定或客戶端驗證。 相反，它完全依賴于TLS保密。網絡釣魚。 OAuth 2.0 不支持簽名，加密，渠道綁定或客戶端驗證。 相反，它完全依賴于TLS保密。最佳用途企業 SSO 難以采用移動平臺SSO 為公眾消費者應用API 授權?

在微服務架構中應用 SSO 時，需要考慮的一種技術是創建一個 SSO 網關，并將它放在服務與身份提供者之間。然后，該網關可代為處理從系統傳到外部和從外部傳到系統的身份驗證和授權流量。此技術可幫助避免每個微服務都需要與同一個身份提供者單獨握手的情形，從而消除了冗余的流量。此技術的一個缺點是，與網關建立了額外的關聯，這違背了微服務架構的演化原則。? 服務間身份驗證和授權?

在為微服務架構建立安全策略時，可以考慮以下服務間身份驗證和授權實踐：?

信任邊界

?

一種選擇可能是隱式地信任在一個已知、隔離的邊界內的服務之間發出的所有調用。此技術初看起來像是不安全，因為存在受到典型中間人攻擊的風險。但實際上，隨著專為微服務設計的成熟工具和技術的出現，此技術變得更加合理。?

您可以使用容器化技術（比如 Docker）來降低風險。Docker 提供的許多功能使開發人員能在不同層面靈活地、最大限度地提高微服務和整個應用程序的安全性。在構建服務代碼時，開發人員可以自由使用滲透測試工具，對構建周期的任何部分執行壓力測試。因為構建 Docker 鏡像的源代碼已在 Docker 分布組件（Docker 和 Docker Compose 文件）中明確地以聲明形式進行了描述，所以開發人員可以輕松地處理鏡像供應鏈，并在需要時執行安全策略。此外，能夠通過將服務放入 Docker 容器中來輕松加固服務，使它們不可變，從而給服務增添強大的安全保障。?

通過采用軟件定義基礎架構，可以使用腳本語言快速創建和配置私有網絡，而且可以在網絡級別上執行強大的安全策略。來自 HashiCorp 的 Terraform? 是腳本語言的一個良好示例，該語言可幫助您從虛擬機、網絡等不同層級快速創建整個基礎架構。?

利用 SSO

?

如果您已經使用 SSO 模式作為 IT 系統的身份驗證和授權模式，那么此過程會很簡單。可將 SSO 用于微服務架構中的服務之間的內部交互。此方法可使用現有的基礎架構，也可簡化對服務的訪問控制，將所有訪問控制操作都集中在一個企業訪問目錄服務器中。?

基于 HTTP 的哈希運算消息驗證碼 (HMAC)

?

一種常用的服務間身份驗證模式是基于 HTTP 的基本身份驗證。它之所以得到普遍使用，是因為它非常簡單、是輕量的且成本很低。但是，它的一個缺點是，如果將它與簡單的 HTTP 結合使用，則存在著憑證被輕松”嗅探”的風險。通過在服務間的每次交互中使用 HTTPS，可以減輕這些風險。但是，僅使用 HTTPS 的方法會增添大量的流量和證書管理開銷。HMAC 可能是用來取代基本身份驗證的候選方案。?

在 HMAC 中，請求內容與一個私鑰一起執行哈希運算，將得到的哈希值與請求一起發送。然后，通信的另一端使用它的私鑰副本和收到的請求內容來重新創建哈希值。如果哈希值匹配，則允許請求通過。如果請求已被篡改，則哈希值不匹配，另一端就會知道并做出適當的反應。?

使用特殊用途服務管理密鑰

?

要消除微服務架構等分布式模型中的憑證管理開銷，并從所構建系統的高安全性中獲益，一種選擇是使用一個綜合性密鑰管理工具。此工具允許存儲、動態地租用、更新和撤銷密鑰（例如密碼、API 密鑰和證書）。由于微服務中規定的自動化原則，這些操作在微服務中非常重要。市場中已有一些項目擁有這個領域的功能；Vault（來自 HashiCorp）或 Keywhiz（來自 Square）是兩個例子。?

混淆代理問題

?

當一個服務（客戶端）嘗試調用另一個服務（服務器）時，在完成身份驗證后，客戶端開始在請求后從服務器收到信息。但是，為了滿足來自客戶端的請求，服務器通常需要與其他下游服務建立其他連接，以獲取服務器沒有的其他信息。在這種情況下，服務器會代表客戶端嘗試訪問下游服務的信息。如果下游服務允許訪問不允許客戶端擁有的信息，這就稱為混淆代理問題。?

您需要了解這種情況，并擁有克服混淆代理問題的對策。一個解決方案可能是安全地分發一個綜合令牌，該令牌可以幫助識別客戶端，又可以用它來進一步了解客戶端有權訪問哪些資源，并接受流量開銷。? 數據安全?

數據被視為 IT 系統中最重要的資產，尤其是敏感數據。各種各樣的機制可用于保護安全信息。?

但是，無論選擇哪種方法，一定要考慮以下一般性的數據安全準則：?

使用著名的數據加密機制

?

盡管從理論上講，不存在無法攻破的數據加密方法，但仍然存在一些成熟的、經過檢驗的、常用的機制（比如 AES-128 或 AES-256 等）。在進行安全考慮時使用這些機制，而不是在內部創建自己的方法。另外，及時更新和修補用于實現這些機制的庫。?

使用一個綜合性工具來管理密鑰

?

如果您的密鑰未得到妥善管理，您為數據加密投入的所有努力都會白費。首要做法是不將密鑰和數據存儲在同一個位置。另外，不要讓密鑰管理復雜性違背微服務架構的靈活性原則。嘗試使用具有微服務設計思路的綜合性工具，這種工具不會破壞您的連續集成和連續交付管道。來自 HashiCorp 的 Vault 或 Amazon Key Management Service 是”微服務友好的”密鑰管理工具的例子。?

針對業務需求來調整安全策略

?

安全性是有代價的。不要加密所有數據，僅將精力放在最寶貴或最敏感的數據上。根據業務需求來制定安全策略，并不斷調整策略，因為戰略目標可能不斷改變，解決方案中包含的技術也是如此。? 深度防御?

因為沒有哪種解決方案能同時解決所有安全問題，所以提高微服務架構安全性的最佳方法是結合使用所有成熟的技術。更重要的是，將它們應用于架構的不同層級。?

除了身份驗證、授權和數據安全之外，還可以考慮以下技術來提供進一步保護：?

設置防火墻

?

防火墻常用于對外監視，阻止對系統的不良意圖的嘗試。如果使用得當，防火墻可過濾掉大量惡意攻擊，最大限度減少要在系統內的下游層級上完成的工作。防火墻還可以放在不同層級上。一種常用的模式是在系統邊緣設置一個防火墻，然后在每個主機本地設置一個防火墻。考慮到每個主機一個服務的模型的快速普及，這可能成為微服務的運行時環境。您可以進一步定義一些 IP 表規則，以便僅允許已知 IP 范圍的用戶訪問主機。借助防火墻，您可以執行一些安全措施，比如訪問控制、速率限制、HTTPS 終止等。?

網絡隔離

?

微服務架構的分布式特性帶來了一些安全挑戰。但是，每個服務的細粒度和高度針對性的特征意味著，您可以輕松地將微服務放在網絡中的不同隔離網段中，從而控制它們之間的交互。通過采用云技術和軟件定義基礎架構，網絡隔離想法更容易實現，因為可以輕松地腳本化和自動化該過程。OpenStack 技術擁有一個名為 Neutron 的綜合性網絡技術棧。此技術棧允許您快速配置虛擬私有網絡，將虛擬服務器放在不同的子網中，可配置這些子網，以您想要的方式讓它們進行交互。您可以在分開的私有網絡上實施安全策略，使用新興的工具（比如 Terraform）通過腳本來加強服務安全性。?

容器化服務

?

一種在微服務構建過程中被廣泛采用的領先實踐是：采用不可變基礎架構。要實現此目的，可利用 Docker 等技術來容器化您的服務。每個微服務都可以部署到一個單獨的 Docker 容器中，從而在每個服務中詳細地執行安全策略。這使得整個容器不可變，就像創建了一個加固的只讀部署單元一樣。可以將特定服務部署的每個基本映像放入掃描過程中，以便在較低的級別上保證服務的運行時環境的安全。? 微服務架構中的治理?

一般而言，治理活動指的是規定微服務架構中的服務如何協同實現構建系統的戰略目標，并付諸于行動。基于微服務的系統中缺乏對服務的嚴謹治理，這使得微服務計劃很快偏離了正確方向。軟件開發中的兩種常用治理方法是：?

設計時治理：根據一組通用的策略和標準來定義和控制軟件組件的創建，包括組件的 設計和實現

運行時治理：在運行時的執行過程中實施組件策略

?

在微服務架構中，服務是獨立構建和部署的。它們是高度解耦的服務，可能是使用各種不同的技術和平臺構建的。因此，從理論上講，不必為服務設計和開發定義一種通用標準，因為每個服務能夠以不同方式構建，只要它能履行自己的專門職責。微服務架構意味著只能使用去中心化的運行時治理功能。服務必須與它們負責的業務能力明確一致；服務不得嘗試執行其上下文邊界外的操作。否則，會讓服務位于一個緊密耦合的架構中，導致交付熵值 (delivery entropy) 混亂和內聚混亂 (cohesion chaos)。?

微服務架構的運行時治理中的一些常用概念可能是監視、服務發現、通用安全要求等。? 案例分析?

第 6部分小節”實際示例：創建新微服務”中已創建新的 Search Catalog 和演化后的 Accounts 微服務。現在，您可以執行其他更改，以便在一個安全環境中將整體式 Orders 系統與新微服務集成。?

在整體式應用程序示例中，身份驗證流程是使用基本身份驗證方法來完成的，也就是說，將憑證與關系數據庫中存儲的用戶名和密碼進行比較驗證。執行身份驗證后，用戶能看到應用程序的所有選項。?

我們來回顧一下，以下是該系統的 3 個主要部分，它們分別被描述為所擁有的數據類型、允許（不允許）誰查看該數據，以及如何保護該數據：?

Catalog Search 微服務

?

Catalog Search 微服務擁有產品的所有信息。此信息可供任何人查看，所以 API 不需要身份驗證。用戶無需登錄即可查看該目錄；該目錄也是在 HTTP 中公開的，以便允許緩存信息來加快交互速度。因此，對于這個微服務，沒必要執行更改。在未來，您可能會使用 API 管理解決方案，根據一種受控且安全的策略來向其他公司公開 Catalog API。?

Accounts 微服務

?

這個微服務擁有客戶的所有信息，此信息是每個客戶私有的。對于此微服務，必須保護信息，以保證只有經過驗證的用戶能看到和更新他們自己的信息。?

Orders 整體式系統

?

Orders 整體式系統必須與其他微服務集成。您必須確保只有經過驗證的用戶才能創建和查看他們的訂單，而且不允許創建或查看其他用戶的訂單。?

基于這個回顧，可以看到您必須保護兩個組件。為此，創建一個 SSO 網關，使用整體式應用程序中使用的身份驗證方法來驗證用戶；配置 Accounts 和 Orders 微服務，以便只允許使用來自此單點登錄帳戶的調用。首先，在可以使用此 SSO 網關安全地連接的云環境中內，將整體式應用程序的 Orders 方法公開為 API。為此，使用創建的同一個 Secure Gateway 來連接整體式系統的 DB2 和 IBM Bluemix 中的 API Connect 服務。? 集成和保護整體式系統?

要集成整體式應用程序的服務，需要建立一條從 Bluemix 到企業內部數據中心的安全連接，然后創建一個 API 網關，在 Bluemix 內安全地提供服務。? 連接到整體式應用程序的服務?

在”企業內部數據庫連接”中，您在 Bluemix 中創建了一個 Secure Gateway 服務，并配置了一個與 DB2 數據庫具有安全連接的目標。現在，可以執行以下步驟，配置另一個目標來連接到整體式 Orders 應用程序所公開的 REST 服務：?

使用您的 IBM id 登錄到 IBM Bluemix。

創建一個新目標：

?

A.在 Bluemix 控制臺中，單擊您的 Secure Gateway 服務轉到儀表板。

?

B.在 Secure Gateway 儀表板中，單擊創建來連接企業內部數據中心的網關（參見"企業內部數據庫連接"）。

?

C.單擊 Add Destination。

?

D.Add Destination Wizard 中，選擇 On-Premises 并單擊 Next。

?

E.輸入您想連接的資源的主機名（或 IP 地址）和端口，在本例中為整體式應用程序部署到的應用服務器的本地 IP 地址或主機名。

?

F.選擇 HTTPS 或 HTTP 作為連接服務的協議。單擊 Next。

?

G.選擇 Mutual Auth 作為身份驗證方法，并為證書選擇 Auto-generate 選項。單擊 Next。

?

此選項可確保在連接的客戶端與 Secure Gateway 客戶端之間執行安全身份驗證。借助此選項，您可以控制哪些客戶端可連接后端服務，方法是向它們提s供使用傳輸層安全 (TLS) 相互身份驗證所生成的證書。

?

H.將 IP 表規則留空。單擊 Next。

?

在此選項中，還可以創建規則來僅允許來自已知 IP 地址的連接，例如來自開發和質量保證團隊的 IP 地址。在這種情況下，還必須配置第 g 步中生成的證書。

?

I.輸入您想為目標使用的名稱，在本例中為 Orders Monolith，然后單擊 Finish。

?

圖 1 中顯示了該整體式應用程序的網關窗口。Orders Monolith 目標顯示了一個較小的紅色手形圖標（位于磁貼右上角），表明訪問被訪問控制表阻止。

?

圖 1.包含數據庫和服務目標的 Secure Gateway 儀表板

?

?

J. Orders Monolith 目標窗口（如圖 2 所示）顯示了用于連接企業內部的 REST 服務的云主機和端口。單擊 Download Authentication Files（證書）并將它們保存到本地文件夾中。?

圖 2. 后端服務目標信息? ?

K.在網關客戶端控制臺中輸入以下命令來配置訪問控制表 (ACL)，以便允許流量進入企業內部數據庫：

1

?

acl allow <services ip address or hostname>:<port>

?

對于此示例，使用的命令為：

1

?

acl allow orders.xxxx.net:80

創建一個密鑰庫和信任庫來使用生成的證書：

?

A. 打開一個 SSH 或 Telnet 客戶端。

?

B. 要為客戶端創建密鑰庫，可在所下載證書的解壓目錄中輸入以下命令：

?

?openssl pkcs12 -export -out "sg_key.p12" -in JDR26UI0ab1_iIh_destCert.pem

? ? -inkey JDR26UI0ab1_iIh_destKey.pem -password pass:"<a password>" -name

? ? BmxCliCert -noiter?

現在您已擁有密鑰庫 sg_key.p12，可以使用它執行相互身份驗證。

?

C. 要創建一個包含所有服務器和 CA 證書的信任庫，可在所下載證書的解壓目錄中發出以下命令：

?

? keytool -import -alias PrimaryCA -file DigiCertCA2.pem -storepass password

? ? -keystore sg_trust.jks

? ? (answer 'yes' to trust it)

? ? keytool -import -alias SecondaryCA -file DigiCertTrustedRoot.pem -storepass

? ? password -keystore sg_trust.jks

? ? keytool -import -alias GtwServ -file secureGatewayCert.pem -storepass

? ? password -keystore sg_trust.jks

? ? keytool -importkeystore -srckeystore sg_trust.jks -srcstoretype JKS

? ? -deststoretype PKCS12 -destkeystore key_trust_store.p12

? ? (enter a password for the trustore, repeat the password and leave empty the

? ? source password)?

現在您擁有 sg_trust.jks 和 key_trust_store.p12 文件，可使用它們執行相互身份驗證。

?

在云環境中將整體式服務公開為 API?

在”連接整體式應用程序的服務”中，您在 Bluemix 與企業內部的整體式應用程序的服務之間建立了安全連接。現在可以使用 API Connect Bluemix 服務將后端服務公開為 API，以便在您的 Bluemix 空間內輕松使用它。?

使用您的 IBM id 登錄到 IBM Bluemix。

創建 API Connect 服務：

?

a. 轉到 Bluemix 目錄。

?

b. 在 APIs 類別中選擇 API Connect service。

?

c. 單擊 Create。

配置一個 TLS 配置文件，以便向 Secure Gateway 客戶端執行身份驗證：

?

a. 在 API Connect 儀表板中，單擊左上角的 Navigation to 圖標，然后單擊 Admin（圖 3）。

?

圖 3. API Connect 上的 Navigation To 圖標?

?

b. 單擊頂部菜單中的 TLS Profiles，然后單擊 Add。?

c. 輸入您的 TLS 配置文件的名稱和描述。?

d. 單擊儀表板右上角的 Save 選項保存該配置文件。?

e. 單擊 Present Certificate 選項旁邊的加號 (+)。?

f. 單擊 Select File 并搜索第 b 步中生成的 sg_key.p12 文件。?

g. 輸入您在創建 sg_key.p12 文件時配置的密碼（第 b 步）。?

h. 單擊 Upload。?

i. 通過將 Request and validate the certificate against the supplied CAs in the truststore 滑塊滑動到 On 位置，驗證該證書。?

j.單擊 Save。?

k.單擊 Trust Store 選項旁邊的加號 (+)。?

l.單擊 Select File 并搜索第 c 步中生成的 key_trust_store.p12 文件。?

m. 輸入您在創建 key_trust_store.p12 文件時提供的密碼。?

n. 單擊 Upload。?

您的 TLS 配置文件現在類似于圖 4 中的配置文件。?

圖 4. API Connect 的 TLS 配置文件配置?

?

使用啟用了相互身份驗證的 Secure Gateway 云主機創建整體式服務 API：

?

a. 轉到 API Connect 儀表板。

?

b. 在 API Connect 儀表板中，單擊左上角的 Navigation to 圖標，然后單擊 Drafts。

?

c. 單擊 APIs。

?

d. 單擊 Add →?New API。

?

e. 輸入 API 標題，選擇 Add to a new product，輸入新產品標題，然后單擊 Add。

?

f. 在 Design API 選項中，輸入聯系人、條款和許可，以及外部文檔等一般信息。

?

g. 在 Schemes 字段中，選擇 HTTP。

?

h. 在 Host 字段中，輸入 Secure Gateway 所提供的云主機:端口。

?

i. 輸入整體式服務的基礎路徑。在此示例中，該路徑為：/CustomerOrderServicesWeb/jaxrs/

?

j.選擇服務返回的數據類型，在本例中為 application/json。

?

k.在 Security Definitions 選項中，保持 clientID (API Key) 選項不變。

?

l.在 Security 中，選擇選項 1 clientID (API Key)。

?

m. 在 Paths 選項中，輸入服務路徑（在本例中為 /customer/openorder），然后單擊 add 操作并選擇 POST。

?

n. 對于 Parameters 選項，選擇您想發送到您的服務的信息，在本例中為以下信息：

ID? 要創建的訂單的 ID

Date? ? 訂單日期

Line Item? ?包含要加入訂單的產品的 JSON 對象

Total? ?產品價格

?

o. 返回到 API 儀表板并選擇 Drafts and the products。

?

p. 選擇第 e 步中創建的產品。

?

q.選擇您想要對此 API 使用的選項，在本例中為以下信息：

Visibility? Authenticated users

Subscribable by Authenticated users

?

r.單擊窗口右上角的 Stage，然后選擇您希望將 API 發布到的目錄。

?

s. 在 Products 選項卡上，單擊臨時存儲產品右側的 3 個點，然后單擊 Publish。在 Edit visibility 中，為兩個選項都選擇 Authenticated Users，然后單擊 Publish。

?

t. 在 API Connect 儀表板上，選擇臨時存儲 API 的目錄，單擊 Developers 選項卡，然后單擊 Add Bluemix Organization。

?

u. 輸入使用此目錄中公開的 API 的用戶的電子郵箱。

?

v. 單擊 API Connect 發送的電子郵件中的鏈接，以接受使用該 API 的邀請。

?

w. 選擇您想在哪個組織中使用該 API。

?

現在，您可通過這個私有 API 來使用您的整體式應用程序創建訂單。? 創建 SSO 網關?

現在您已與該整體式應用程序建立安全連接，并將它的 API 公開為 Bluemix Organization 內的私有服務。您可以創建 SSO 服務來驗證用戶，然后代表用戶調用 Orders API 和 Account 微服務。?

最終架構?

圖 5 給出了最終的應用程序架構。? 圖 5 安全的架構