《云原生安全》读后感.docx

《云原生安全》读后感

在数字化进程中，越来越多的组织机构开始拥抱多云和混合云，利用以容器为代表的云原生技术逐步将业务系统迁移或新建在云计算环境中。通过阅读《云原生安全：攻防实践和体系构建》一书，了解到了云原生应用有了哪些改变，以及随之引入了哪些安全威胁以及我们如何应对这些威胁所带来的风险。

1．云原生应用对软件架构和开发模式带来改变

业务系统上云可将组织的精力从基础设施资源管理转移到应用设计与开发上面。为了获取更高的性能、提高软件质量以及增强业务系统可移植性，这些都是组织拥抱云原生应用的重要驱动力。当开发云原生应用的时候，很多组织已经从瀑布式开发转向敏捷型开发，从单体式软件架构转向微服务架构。

在新业务系统架构和开发方法的推动下，DevOps理念已经被很多机构所采用。DevOps通过CI/CD（持续集成与持续交付）自动化工具，将应用开发、集成、测试和交付进行合并，同时加强了组织内各部门和开发团队之间的沟通与协作，使得业务系统可以更快地在云端交付。

2．云原生传统应用安全

由于云原生应用也是应用，因而云原生应用风险也包含传统应用风险。传统应用风险以Web应用风险为主，主要包含注入、敏感数据泄漏、跨站脚本、使用含有已知漏洞的组件，不足的日志记录和监控等风险。

此外，还包含现有的API风险，主要包括安全性错误配置和注入、资产管理不当、资产缺失和速率限制等风险。

3．云原生应用引入新型安全威胁

组织上云和用云时，边界逐渐模糊，传统安全能力无法满足业务需求：目前已有大量工作负载横跨本地环境和云环境，传统防护模型无法处理如此动态化的环境，需要统一管理的资源可见性以及基于上下文去理解业务中各工作负载之间复杂的关联。随着更多容器化工作负载的部署，应用和服务呈现更加分布化的趋势，同时以容器为载体的云原生应用实例极大地缩短了应用和服务的生命周期。对于传统安全防护方法提供的有限可见性以及基于边界的网络防护模式，显然无法满足云原生应用的安全需求。

传统安全认知在DevOps环境下受到挑战：传统安全策略是基于静态数据的，而DevOps强调让业务系统开发更具流动性，这使得DevOps理念与传统安全有着较为强烈的文化冲突。产品开发团队会犹豫是否将安全团队纳入到他们的开发计划中，因为这可能会减缓工作进度造成开发瓶颈。缺乏安全控制作为DevOps理念固有的风险，如果没有得到妥当处理将会导致安全问题，为此我们需要将安全防护以合适的方法与DevOps流程紧密集成形成DevSecOps。

4．关于云原生应用安全最佳实践理解

1)安全建设融入业务开发流程

将安全流程与访问控制合并到DevOps工作里面，这是一个不断迭代和扩展的过程。初期可以尝试工作负载的微隔离、API检查，以及配置核查和漏洞评估；然后开展应用部署前的恶意代码检测、安全事件的响应和溯源等工作；最后，执行异常活动的自动化监测和容器运行时的预防性控制等措施。

2)实施覆盖威胁检测的安全控制

部署CWPP能力执行自动化安全防护：基于CWPP（云工作负载保护平台）的安全能力主要为容器化负载提供行为监控、恶意文件扫描、应用控制、日志管理等功能；CWPP安全产品通常可以与DevOps编排工具相结合实现自动化部署，并在多云或混合云等异构环境中保持功能与策略的一致性；CWPP可以很好地适配容器化环境并为组织提供更多容器化资源的可见性和集中防护能力。

通过CSPM能力确保资源配置一致性：很多云上的安全问题都是由于不合理配置导致的。基于CSPM（云安全态势管理）的安全工具可以对标Benchmarks对组织云上资源执行安全风险评估；另外，CSPM可以自动化评估组织资源所在的云内环境，识别并梳理组织资源（包括影子IT）并可以基于安全策略和合规标准对无法满足需求的配置进行检测与发现。

通过微隔离限制安全威胁横移：对云内资源进行微隔离可以有效地减小威胁平面，虽然CWPP可以提供一部分工作负载微隔离能力，但相比之下，专注于微隔离的独立安全产品具备更强的针对性。基于主机或容器的终端安全产品可以在混合云的环境下确保能力一致性，同时可以根据安全策略的建议开展细粒度的微隔离工作。

确保实现所有API的可见性和数据防护：WebAPI在云环境下无处不在，传统应用防护产品在保护WebAPI这方面存在明显短板。另外，微服务架构应用其内部各服务之间的交互严重依赖API，这也导致了对于API的可见性和漏洞扫描达到了前所未有的重要性。应用部署前的代码测试以及融入DevSecOps流程下不间断的审计可以有效帮助组织对数据渗透进行防护，缓解身份欺诈以及恶意活动的发生的风险。

3）持续性地开展安全运营

云上的资源和环境是动态的，所以威胁也是持续变化的。由于安全能力总有短板，这时就轮到安全运营派上用场的时候了。有效地将安全事件监控与威胁情报集成到安全事件响应