时光如白驹过隙，一转眼2023即将过去，崭新的2024就要到来，笔者好像也挺久没有更新公众号了，感谢各位新老粉丝们一直以来的关注，又到了一年一度的普通网安从业人员的年度总结了。

相较于《一个普通网安从业人员的2022》、《一个普通网安从业人员的2021》和《一个普通网安从业人员的2020》，2023年笔者的公开演讲和公众号文章并不多，主要是对于云安全架构的思考、总结和展望。希望2024年的自己继续保持笔耕不辍，坚持思考、持续实践、及时总结。

第一步，对云服务应用进行威胁建模

第二步，基于P.E.A.C.H.五个方面实施云服务安全加固

• 权限加固（Privilege hardening）：

• 在服务环境中，租户和主机通常具有最小的权限，遵循最小特权原则。

• 特别地，除非经过租户明确批准，否则每个租户不得读取或写入其他租户的数据，每个主机也不能读取或写入其他主机的数据

• 在执行操作之前，需要验证权限。

• 加密加固（Encryption hardening）：

• 属于每个租户的数据（静态数据和传输数据）都使用唯一于该租户的密钥进行加密，而不管架构如何。

• 与每个租户的活动相关的日志由租户和控制平面之间共享的秘密进行加密。

• 认证加固（Authentication hardening）：

• 每个租户与控制平面之间的通信（双向）使用唯一于每个租户的密钥或证书进行身份验证。

• 验证身份、验证密钥，并阻止使用自签名密钥。

• 网络加固（Connectivity hardening）：

• 默认情况下，除非经过租户明确批准（例如便于数据库复制），否则阻止所有主机之间的互联互通；主机不能连接服务环境中的其他主机，除了控制平面使用的主机（即集线器和分支配置）。

• 除非经过租户明确批准，否则主机不接受来自其他主机的传入连接请求，除了控制平面使用的主机（以防攻击者设法克服自己受损主机上的连接限制）。

• 租户不能随意访问任何外部资源（服务环境内部和Internet上的资源），只能与租户预先批准或明确批准的资源进行通信。

• 环境清理（Hygiene）：环境中的不必要的数据或者信息可能为攻击者提供线索或快速收益，特别是那些已经成功攻破一个或多个安全边界的攻击者，这会进一步促进侦察和横向移动。因此，供应商可以在设计阶段消除以下类型的数据，并定期扫描部署环境中遗忘的数据或者信息：

• 机密信息：接口和数据存储（以及虚拟化或容器化情况下的底层主机）不包含任何密钥或凭据，这些凭据将允许对其他租户环境进行身份验证或解密其他租户的后端通信或日志。

• 软件：主机实例和数据存储（以及底层主机）不包含任何内置软件或源代码，这些软件或源代码可能会促进侦察或横向移动。

• 日志：每个租户的日志对其他租户隐藏并不可访问；每个租户可访问的日志不包含与其他租户活动有关的任何信息。

三、新型云服务安全架构设计框架（LSSA）

第一步，将云服务按照关键架构元素进行梳理

第二步，针对每一个关键架构元素进行风险识别和安全加固

• 最小权限（Least Privilege）：确保云服务自身及各组件间的身份认证与鉴权始终保持满足业务需要的最小权限。

• 增强隔离（Improve Separation）：从资源隔离（裸金属、虚拟机、容器）、网络隔离（专线、VPC、安全组）、身份隔离（IAM、MTLS、数字证书、联邦认证、委托授权、零信任鉴权）、架构隔离（专属集群、专属region、专属AZ、物理多租）、数据隔离（传输与存储加密、一租户一密）等方面增强租户间的隔离水平。

• 默认简单（Simplify by default）：云服务接口的功能设计要默认简单，每一个对外接口尽可能只做一件事，正如Unix哲学及其实现“一个程序只做一件事，并做好”。

• 假定失馅（Assume Breach）：在审视每一个关键架构元素的风险时，要思考如果当前的架构元素被攻击者控制后最坏情况下能造成哪些重大影响（也就是爆炸半径），影响当前的云服务架构元素？其他的云服务架构元素？还是其他的云服务？

注：更多详情可点击“原文查看”！

查询和订阅最新安全事件，请关注”安全小飞侠“吧！