一、開篇寫在前面

各位博客閱讀者們以及對(duì)云計(jì)算感興趣的小伙伴們，微軟 Azure 云的基礎(chǔ)部分更新已經(jīng)接近了尾聲，從上周末到這周三，我一直沒有更文，最近主要 focus 在后續(xù)如何更新以及博客內(nèi)容梳理上，接下來的一小段時(shí)間我會(huì)將 Azure 基礎(chǔ)的后續(xù)零散更新完畢，這主要包括剩余的兩個(gè)部分：

• 用于管理和部署 Azure 資源的功能和工具
• Azure 中的監(jiān)視工具

接下來的這幾周我會(huì)準(zhǔn)備好上面的剩余兩個(gè)部分文章稿件的同時(shí)，從這周開始會(huì)更新企業(yè)內(nèi)應(yīng)用 Azure 云的真實(shí)案例進(jìn)行講解。

前幾天和朋友聊，我說現(xiàn)在更新博文時(shí)間很緊張，但是依然保持一周至少更新一篇的節(jié)奏，后來有不止一次聽說關(guān)于有些博主直接照搬別人的資料或者文章出來，比如從某某某復(fù)制到某某某等等，或者買本書籍，直接把書的內(nèi)容弄到 CSDN博客上來。講實(shí)話我有點(diǎn)小難過，難過的是類似一直肝原創(chuàng)，并且非常努力的一些博主的辛苦有可能被淹沒在這卷卷的大浪中，另一方面是別人的成果得不到尊重，就比如我寫的 Azure 系列的文章，絕大部分，我可以說 99% 的圖都是我自己一點(diǎn)點(diǎn)畫出來的，但是有的站外的人可能一個(gè)爬蟲不到1分鐘就給爬走了。

此處省略一百萬字用來你懂的。

二、項(xiàng)目背景及介紹

該項(xiàng)目是關(guān)于支付卡行業(yè) (PCI) 數(shù)據(jù)安全標(biāo)準(zhǔn) (DSS)的一個(gè) Azure 云項(xiàng)目，之所以拿這個(gè)舉例，是因?yàn)橐环矫嫖④?Azure 云的安全標(biāo)準(zhǔn)通過了該標(biāo)準(zhǔn)的審計(jì)，另一個(gè)方面是以該標(biāo)準(zhǔn)為例子的項(xiàng)目在微軟官方也有提到過。

這里簡單提一下什么是 PCI DSS

PCI DSS是Payment Card Industry Data Security Standard（付款卡行業(yè)數(shù)據(jù)安全標(biāo)準(zhǔn)）的縮寫，通常簡稱為PCI DSS。

PCI DSS是一組由支付卡產(chǎn)業(yè)安全標(biāo)準(zhǔn)理事會(huì)（Payment Card Industry Security Standards Council，PCI SSC）制定的安全標(biāo)準(zhǔn)，旨在保護(hù)持有者信息（Cardholder Data）和支付卡數(shù)據(jù)的安全性。該標(biāo)準(zhǔn)適用于所有處理、存儲(chǔ)或傳輸持有者信息的組織，包括商戶、支付處理服務(wù)提供商、銀行和其他涉及支付卡交易的機(jī)構(gòu)。

想必一些做國企或者銀行項(xiàng)目的同學(xué)對(duì)這個(gè)協(xié)議應(yīng)該并不陌生。

本文是 #云計(jì)算解決方案與架構(gòu) 專欄中的一部分。我們以 PCI DSS 要求為例，詳細(xì)介紹每個(gè)要求及其在 Azure 中的實(shí)現(xiàn)。

本文將介紹在 PCI DSS 項(xiàng)目中，如何構(gòu)建符合 Azure 云平臺(tái)要求的 PCI DSS 兼容架構(gòu)。

三、Azure PCI DSS 項(xiàng)目架構(gòu)及組件

該系統(tǒng)的配置如下。事實(shí)上我們構(gòu)建的實(shí)際站點(diǎn)具有更復(fù)雜的配置，包括與公司網(wǎng)絡(luò)的 ExpressRoute 連接，但基本思想是相同的。

首先，整個(gè)系統(tǒng)部署在虛擬網(wǎng)絡(luò)中。從左前方看，公共端點(diǎn)受到應(yīng)用網(wǎng)關(guān) + WAF 的保護(hù)，并通過內(nèi)部LB連接到應(yīng)用服務(wù)環(huán)境（ASE）。

該應(yīng)用程序部署在 ASE 上并將數(shù)據(jù)存儲(chǔ)在后端 SQL 數(shù)據(jù)庫中。與數(shù)據(jù)庫的通信通過虛擬網(wǎng)絡(luò)服務(wù)端點(diǎn)進(jìn)行加密和保護(hù)。它通過 Express Route 連接到公司網(wǎng)絡(luò)，并允許與特定系統(tǒng)（系統(tǒng)聯(lián)動(dòng)伙伴）進(jìn)行通信以進(jìn)行系統(tǒng)聯(lián)動(dòng)。另外，還安裝了堡壘（跳板機(jī)）服務(wù)器（Bastion）進(jìn)行運(yùn)營管理，通過 Express Route 限制特定終端對(duì)堡壘服務(wù)器的訪問。日志和指標(biāo)聚合在 Azure Monitor 中。

該系統(tǒng)按組件部署在虛擬網(wǎng)絡(luò)內(nèi)的網(wǎng)絡(luò)安全組 (NSG) 保護(hù)的子網(wǎng)內(nèi)。該架構(gòu)還包括應(yīng)用程序網(wǎng)關(guān)、Azure DNS 和負(fù)載均衡器。

NSG 僅允許組件之間進(jìn)行必要的通信。這種分離政策比 PCI DSS 的要求更嚴(yán)格，但我們積極使用它，因?yàn)樗苋菀淄ㄟ^ Azure 以較低的額外成本實(shí)施。

在解決方案中使用了 Azure 存儲(chǔ)帳戶，客戶可以配置使用存儲(chǔ)服務(wù)加密來保持?jǐn)?shù)據(jù)在靜態(tài)狀態(tài)下的機(jī)密性。Azure 會(huì)在客戶選擇的數(shù)據(jù)中心中存儲(chǔ)三份數(shù)據(jù)以增強(qiáng)韌性。地理冗余存儲(chǔ)確保數(shù)據(jù)會(huì)被復(fù)制到距離數(shù)百英里之外的輔助數(shù)據(jù)中心，并在該數(shù)據(jù)中心內(nèi)再次存儲(chǔ)三份數(shù)據(jù)，以防止客戶主要數(shù)據(jù)中心發(fā)生不良事件導(dǎo)致數(shù)據(jù)丟失。

此外，Application Insights 通過 Azure 監(jiān)視日志提供實(shí)時(shí)的應(yīng)用程序性能管理和分析。

此架構(gòu)解決方案使用以下的 Azure 服務(wù)：

• 應(yīng)用服務(wù)環(huán)境 v2
• 應(yīng)用程序網(wǎng)關(guān)
  • Web 應(yīng)用程序防火墻
  • 防火墻模式：防護(hù)
  • 規(guī)則集：OWASP 3.0
  • 偵聽器端口：443
• Application Insights
• Azure Active Directory
• Azure 自動(dòng)化
• Azure DNS
• Azure Key Vault
• Azure 負(fù)載均衡器
• Azure Monitor
• Azure 資源管理器
• Azure 安全中心
• Azure SQL 數(shù)據(jù)庫
• Azure 存儲(chǔ)
• Azure 虛擬網(wǎng)絡(luò)
  • 16 網(wǎng)絡(luò)
  • 24 網(wǎng)絡(luò)
  • 網(wǎng)絡(luò)安全組
• Azure Web 應(yīng)用

四、身份驗(yàn)證、訪問控制

Azure 與傳統(tǒng)本地安全模型不同的最重要一點(diǎn)是，基本安全是零信任、基于身份的安全驗(yàn)證，關(guān)于零信任模型，可以參考我以前的文章《構(gòu)建安全架構(gòu)的 Azure 云：深入了解零信任體系結(jié)構(gòu)》。

4.1 三層防御控制

在這個(gè)系統(tǒng)中，Azure本身就是 Id Based Security，整個(gè)應(yīng)用架構(gòu)都受到 Id Based Security 的保護(hù)。另外，基本思想是一切都不能信任（零信任）。這個(gè)想法甚至不信任內(nèi)部網(wǎng)絡(luò)，而是進(jìn)行身份驗(yàn)證并僅允許預(yù)定義的訪問。

該系統(tǒng)不僅對(duì)外方向而且對(duì)企業(yè)網(wǎng)絡(luò)側(cè)都采用相同的策略，并通過認(rèn)證和訪問控制來保護(hù)對(duì)系統(tǒng)的所有訪問。

Azure 資源如何受到保護(hù)？當(dāng)服務(wù)部署在Azure上時(shí)，將如下圖所示進(jìn)行配置。最底層是 Azure 基礎(chǔ)層，中間層是 Azure 資源層，最上面是用戶創(chuàng)建的應(yīng)用程序。

通常所說的基礎(chǔ)設(shè)施部分是最底層的兩層，最上面的一層是應(yīng)用程序。

4.2 三層部署結(jié)構(gòu)

在 Azure 中，經(jīng)過 Azure AD 身份驗(yàn)證的操作員通過 Azure 資源管理器執(zhí)行對(duì)資源的操作。這些操作由基于 RBAC（Role-Based Access Control）的權(quán)限判斷來控制，同時(shí)操作歷史記錄會(huì)被記錄在 Activity Log 中。RBAC 允許你定義資源操作權(quán)限以控制對(duì)資源的訪問。此外，你還可以通過 API 來執(zhí)行這些操作，并編寫腳本來自動(dòng)化這些過程。

這里重要的是，網(wǎng)絡(luò)設(shè)置和服務(wù)器設(shè)置等基礎(chǔ)設(shè)施工作是基于身份驗(yàn)證和訪問控制來執(zhí)行的。操作歷史可以保存為審核日志，并且可以通過自動(dòng)化（編碼）來實(shí)現(xiàn)。這些功能有助于滿足 PCI DSS 的要求。

五、跳板機(jī)

我們?cè)谙到y(tǒng)中引入了跳板機(jī)服務(wù)器來管理對(duì)公司網(wǎng)絡(luò)的操作訪問。所有運(yùn)營操作都必須通過跳板機(jī)服務(wù)器進(jìn)行認(rèn)證和訪問控制，以確保運(yùn)營管理員的安全訪問。如果需要，可以通過堡壘服務(wù)器連接到數(shù)據(jù)庫，但即使在這種情況下，我們也會(huì)限制操作員的權(quán)限，以防止他們?cè)L問不應(yīng)引用的表和列。這些權(quán)限限制是根據(jù)操作要求確定的。另外，我們結(jié)合了 SQL 數(shù)據(jù)庫審計(jì)，以實(shí)現(xiàn)對(duì)操作的廣泛審計(jì)。這些措施有助于滿足 PCI DSS 的要求。

對(duì)于什么是跳板機(jī)，這里做個(gè)簡短說明（已經(jīng)了解的同學(xué)這個(gè)解釋可以跳過）：

跳板機(jī)是一種用于安全訪問和管理其他計(jì)算設(shè)備的中間服務(wù)器。它是在網(wǎng)絡(luò)架構(gòu)中作為安全防護(hù)措施的一部分，用于提供受限訪問權(quán)限，從而增強(qiáng)網(wǎng)絡(luò)安全。

跳板機(jī)通常位于內(nèi)部網(wǎng)絡(luò)和外部網(wǎng)絡(luò)之間，也可以在內(nèi)部網(wǎng)絡(luò)的子網(wǎng)中。它是一臺(tái)獨(dú)立的服務(wù)器，經(jīng)過高度保護(hù)和配置，僅允許經(jīng)過授權(quán)的用戶訪問。用戶需要先連接到跳板機(jī)，通過身份驗(yàn)證后，才能進(jìn)一步連接到其他受保護(hù)的服務(wù)器或網(wǎng)絡(luò)設(shè)備。

跳板機(jī)在 Azure 中，英文是：Bastion，你也可能在其他的云廠商或者文檔中看見Jump Box字樣，也同樣代表跳板機(jī)。

六、與 PCI DSS 要求的關(guān)系

PCI DSS 中相當(dāng)于身份驗(yàn)證和訪問控制的是要求 7 和 8。它需要最低限度的必要訪問權(quán)限、無共享帳戶、始終分配個(gè)人帳戶以及正確管理 ID 密碼。

該系統(tǒng)使用 Azure AD 作為企業(yè)帳戶。通過向每個(gè)人發(fā)放個(gè)人賬戶并使用 RBAC 限制對(duì)基本要素的訪問來滿足要求。

要求 9 與物理訪問控制有關(guān)。Azure 中不允許物理訪問，資源操作是通過 Azure REST API 進(jìn)行的。API 受到身份驗(yàn)證和訪問控制。這是一個(gè)共同責(zé)任的例子，身份管理是客戶的責(zé)任，API 訪問控制是云提供商的責(zé)任。

通過在 Log Analytics 中的企業(yè)帳戶中存儲(chǔ)審核所需期間的活動(dòng)日志和操作歷史記錄，可以滿足要求 10 中與持卡人數(shù)據(jù)審核日志管理相關(guān)的要求。

七、該篇總結(jié)（重要）

注意：此處的文末總結(jié)不同于我其他的文章，以前的文章大部分是總結(jié)或者說是一種回顧文章，此處的總結(jié)是針對(duì) 架構(gòu)以及一些最佳實(shí)踐總結(jié)而出，建議對(duì)云架構(gòu)有興趣的同學(xué)要知曉此處要點(diǎn)。

在身份驗(yàn)證、訪問控制等合規(guī)性上，要遵循：

• 資源配置和設(shè)置在 AAD 認(rèn)證下完成
• 訪問控制 (RBAC) 與 AAD 身份驗(yàn)證結(jié)合使用
• 資源操作可以在代碼中完成
• 操作存儲(chǔ)在 Log Analytics 中

通過采用這樣的機(jī)制，PCI DSS 要求的以下項(xiàng)目的操作難度將顯著降低。

• 審核未經(jīng)授權(quán)的配置更改
• 成分標(biāo)準(zhǔn)的澄清
• 定期配置檢查的實(shí)際執(zhí)行

此外，Azure 資源沒有固定的默認(rèn)密碼，并且不受 PCI DSS 要求 2 禁止使用默認(rèn)密碼的約束。這可以說是基于業(yè)界最新安全理念的服務(wù)設(shè)計(jì)，可以輕松構(gòu)建符合 PCI DSS 的環(huán)境。

寫在文末

該篇是 【Azure上云項(xiàng)目實(shí)戰(zhàn)】PCI DSS 項(xiàng)目的第一篇，主要講解了其項(xiàng)目架構(gòu)，特別針對(duì)身份驗(yàn)證與訪問控制這塊，對(duì)于如何符合 PCI DSS 的要求進(jìn)行了總結(jié)，試想如果你做了 PCI DSS 類似的項(xiàng)目，一定會(huì)有相關(guān)的法規(guī)，在你設(shè)計(jì)云架構(gòu)的時(shí)候，或者給客戶講解的時(shí)候，如何能保證其符合要求，本文做了詳細(xì)的解答和講解，希望對(duì)這方面的閱讀者們有所幫助。文章來源地址http://www.zghlxwxcb.cn/news/detail-624390.html

[ 本文作者 ]   bluetata
[ 原文鏈接 ]   https://bluetata.blog.csdn.net/article/details/132068024
[ 最后更新 ]   08/02/2023 22:41
[ 版權(quán)聲明 ]   如果您在非 CSDN 網(wǎng)站內(nèi)看到這一行，
說明網(wǎng)絡(luò)爬蟲可能在本人還沒有完整發(fā)布的時(shí)候就抓走了我的文章，
可能導(dǎo)致內(nèi)容不完整，請(qǐng)去上述的原文鏈接查看原文。

到了這里，關(guān)于【Azure上云項(xiàng)目實(shí)戰(zhàn)】 合規(guī)性的身份驗(yàn)證與訪問控制：在 Azure 中實(shí)現(xiàn)符合 PCI DSS 要求的架構(gòu)設(shè)計(jì)的文章就介紹完了。如果您還想了解更多內(nèi)容，請(qǐng)?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！