文章目录
-
- 一、开篇写在前面
- 二、项目背景及介绍
- 三、Azure PCI DSS 项目架构及组件
- 四、身份验证、访问控制
-
- 4.1 三层防御控制
- 4.2 三层部署结构
- 五、跳板机
- 六、与 PCI DSS 要求的关系
- 七、该篇总结（重要）
- 写在文末
一、开篇写在前面
各位博客阅读者们以及对云计算感兴趣的小伙伴们，微软 Azure 云的基础部分更新已经接近了尾声，从上周末到这周三，我一直没有更文，最近主要 focus 在后续如何更新以及博客内容梳理上，接下来的一小段时间我会将 Azure 基础的后续零散更新完毕，这主要包括剩余的两个部分：
- 用于管理和部署 Azure 资源的功能和工具
- Azure 中的监视工具
接下来的这几周我会准备好上面的剩余两个部分文章稿件的同时，从这周开始会更新企业内应用 Azure 云的真实案例进行讲解。
前几天和朋友聊，我说现在更新博文时间很紧张，但是依然保持一周至少更新一篇的节奏，后来有不止一次听说关于有些博主直接照搬别人的资料或者文章出来，比如从某某某复制到某某某等等，或者买本书籍，直接把书的内容弄到 CSDN博客上来。讲实话我有点小难过，难过的是类似一直肝原创，并且非常努力的一些博主的辛苦有可能被淹没在这卷卷的大浪中，另一方面是别人的成果得不到尊重，就比如我写的 Azure 系列的文章，绝大部分，我可以说 99% 的图都是我自己一点点画出来的，但是有的站外的人可能一个爬虫不到1分钟就给爬走了。
此处省略一百万字用来你懂的。
二、项目背景及介绍
该项目是关于支付卡行业 (PCI) 数据安全标准 (DSS)的一个 Azure 云项目，之所以拿这个举例，是因为一方面微软 Azure 云的安全标准通过了该标准的审计，另一个方面是以该标准为例子的项目在微软官方也有提到过。
这里简单提一下什么是 PCI DSS
PCI DSS是Payment Card Industry Data Security Standard（付款卡行业数据安全标准）的缩写，通常简称为PCI DSS。
PCI DSS是一组由支付卡产业安全标准理事会（Payment Card Industry Security Standards Council，PCI SSC）制定的安全标准，旨在保护持有者信息（Cardholder Data）和支付卡数据的安全性。该标准适用于所有处理、存储或传输持有者信息的组织，包括商户、支付处理服务提供商、银行和其他涉及支付卡交易的机构。
想必一些做国企或者银行项目的同学对这个协议应该并不陌生。
本文是 #云计算解决方案与架构 专栏中的一部分。我们以 PCI DSS 要求为例，详细介绍每个要求及其在 Azure 中的实现。
本文将介绍在 PCI DSS 项目中，如何构建符合 Azure 云平台要求的 PCI DSS 兼容架构。
三、Azure PCI DSS 项目架构及组件
该系统的配置如下。事实上我们构建的实际站点具有更复杂的配置，包括与公司网络的 ExpressRoute 连接，但基本思想是相同的。
首先，整个系统部署在虚拟网络中。从左前方看，公共端点受到应用网关 + WAF 的保护，并通过内部LB连接到应用服务环境（ASE）。
该应用程序部署在 ASE 上并将数据存储在后端 SQL 数据库中。与数据库的通信通过虚拟网络服务端点进行加密和保护。它通过 Express Route 连接到公司网络，并允许与特定系统（系统联动伙伴）进行通信以进行系统联动。另外，还安装了堡垒（跳板机）服务器（Bastion）进行运营管理，通过 Express Route 限制特定终端对堡垒服务器的访问。日志和指标聚合在 Azure Monitor 中。
该系统按组件部署在虚拟网络内的网络安全组 (NSG) 保护的子网内。该架构还包括应用程序网关、Azure DNS 和负载均衡器。
NSG 仅允许组件之间进行必要的通信。这种分离政策比 PCI DSS 的要求更严格，但我们积极使用它，因为它很容易通过 Azure 以较低的额外成本实施。
在解决方案中使用了 Azure 存储帐户，客户可以配置使用存储服务加密来保持数据在静态状态下的机密性。Azure 会在客户选择的数据中心中存储三份数据以增强韧性。地理冗余存储确保数据会被复制到距离数百英里之外的辅助数据中心，并在该数据中心内再次存储三份数据，以防止客户主要数据中心发生不良事件导致数据丢失。
此外，Application Insights 通过 Azure 监视日志提供实时的应用程序性能管理和分析。
此架构解决方案使用以下的 Azure 服务：
- 应用服务环境 v2
- 应用程序网关
- Web 应用程序防火墙
- 防火墙模式：防护
- 规则集：OWASP 3.0
- 侦听器端口：443
- Application Insights
- Azure Active Directory
- Azure 自动化
- Azure DNS
- Azure Key Vault
- Azure 负载均衡器
- Azure Monitor
- Azure 资源管理器
- Azure 安全中心
- Azure SQL 数据库
- Azure 存储
- Azure 虚拟网络
- 16 网络
- 24 网络
- 网络安全组
- Azure Web 应用
四、身份验证、访问控制
Azure 与传统本地安全模型不同的最重要一点是，基本安全是零信任、基于身份的安全验证，关于零信任模型，可以参考我以前的文章《构建安全架构的 Azure 云：深入了解零信任体系结构》。
4.1 三层防御控制
在这个系统中，Azure本身就是 Id Based Security，整个应用架构都受到 Id Based Security 的保护。另外，基本思想是一切都不能信任（零信任）。这个想法甚至不信任内部网络，而是进行身份验证并仅允许预定义的访问。
该系统不仅对外方向而且对企业网络侧都采用相同的策略，并通过认证和访问控制来保护对系统的所有访问。
Azure 资源如何受到保护？当服务部署在Azure上时，将如下图所示进行配置。最底层是 Azure 基础层，中间层是 Azure 资源层，最上面是用户创建的应用程序。
通常所说的基础设施部分是最底层的两层，最上面的一层是应用程序。
4.2 三层部署结构
在 Azure 中，经过 Azure AD 身份验证的操作员通过 Azure 资源管理器执行对资源的操作。这些操作由基于 RBAC（Role-Based Access Control）的权限判断来控制，同时操作历史记录会被记录在 Activity Log 中。RBAC 允许你定义资源操作权限以控制对资源的访问。此外，你还可以通过 API 来执行这些操作，并编写脚本来自动化这些过程。
这里重要的是，网络设置和服务器设置等基础设施工作是基于身份验证和访问控制来执行的。操作历史可以保存为审核日志，并且可以通过自动化（编码）来实现。这些功能有助于满足 PCI DSS 的要求。
五、跳板机
我们在系统中引入了跳板机服务器来管理对公司网络的操作访问。所有运营操作都必须通过跳板机服务器进行认证和访问控制，以确保运营管理员的安全访问。如果需要，可以通过堡垒服务器连接到数据库，但即使在这种情况下，我们也会限制操作员的权限，以防止他们访问不应引用的表和列。这些权限限制是根据操作要求确定的。另外，我们结合了 SQL 数据库审计，以实现对操作的广泛审计。这些措施有助于满足 PCI DSS 的要求。
对于什么是跳板机，这里做个简短说明（已经了解的同学这个解释可以跳过）：
跳板机是一种用于安全访问和管理其他计算设备的中间服务器。它是在网络架构中作为安全防护措施的一部分，用于提供受限访问权限，从而增强网络安全。
跳板机通常位于内部网络和外部网络之间，也可以在内部网络的子网中。它是一台独立的服务器，经过高度保护和配置，仅允许经过授权的用户访问。用户需要先连接到跳板机，通过身份验证后，才能进一步连接到其他受保护的服务器或网络设备。
跳板机在 Azure 中，英文是：
Bastion，你也可能在其他的云厂商或者文档中看见Jump Box字样，也同样代表跳板机。
六、与 PCI DSS 要求的关系
PCI DSS 中相当于身份验证和访问控制的是要求 7 和 8。它需要最低限度的必要访问权限、无共享帐户、始终分配个人帐户以及正确管理 ID 密码。
该系统使用 Azure AD 作为企业帐户。通过向每个人发放个人账户并使用 RBAC 限制对基本要素的访问来满足要求。
要求 9 与物理访问控制有关。Azure 中不允许物理访问，资源操作是通过 Azure REST API 进行的。API 受到身份验证和访问控制。这是一个共同责任的例子，身份管理是客户的责任，API 访问控制是云提供商的责任。
通过在 Log Analytics 中的企业帐户中存储审核所需期间的活动日志和操作历史记录，可以满足要求 10 中与持卡人数据审核日志管理相关的要求。
(图片为 PCI DSS 数据安全标准)
七、该篇总结（重要）
注意：此处的文末总结不同于我其他的文章，以前的文章大部分是总结或者说是一种回顾文章，此处的总结是针对 架构以及一些最佳实践总结而出，建议对云架构有兴趣的同学要知晓此处要点。
在身份验证、访问控制等合规性上，要遵循：
- 资源配置和设置在 AAD 认证下完成
- 访问控制 (RBAC) 与 AAD 身份验证结合使用
- 资源操作可以在代码中完成
- 操作存储在 Log Analytics 中
通过采用这样的机制，PCI DSS 要求的以下项目的操作难度将显着降低。
- 审核未经授权的配置更改
- 成分标准的澄清
- 定期配置检查的实际执行
此外，Azure 资源没有固定的默认密码，并且不受 PCI DSS 要求 2 禁止使用默认密码的约束。这可以说是基于业界最新安全理念的服务设计，可以轻松构建符合 PCI DSS 的环境。
(图片为 PCI DSS 数据安全标准)
写在文末
该篇是 【Azure上云项目实战】PCI DSS 项目的第一篇，主要讲解了其项目架构，特别针对身份验证与访问控制这块，对于如何符合 PCI DSS 的要求进行了总结，试想如果你做了 PCI DSS 类似的项目，一定会有相关的法规，在你设计云架构的时候，或者给客户讲解的时候，如何能保证其符合要求，本文做了详细的解答和讲解，希望对这方面的阅读者们有所帮助。
[ 本文作者 ] bluetata
[ 原文链接 ] https://bluetata.blog.csdn.net/article/details/132068024
[ 最后更新 ] 08/02/2023 22:41
[ 版权声明 ] 如果您在非 CSDN 网站内看到这一行，
说明网络爬虫可能在本人还没有完整发布的时候就抓走了我的文章，
可能导致内容不完整，请去上述的原文链接查看原文。
