构建安全可靠、高效运行的应用架构 - 周金龙

个人简介 周 金 龙 资 深 架 构 师 •2011年加入阿里，负责阿里运维平台产品落地。•2016年加入菜鸟，负责菜鸟及环路公司云原生架构。•有着15年运维及研发经验，在IT管理与治理领域有着深厚的理论基础和丰富的落地经验。目前担任阿里云解决方案资深架构师。 企业用云面临新挑战 云卓越架构方案概述 目录 云卓越架构实践案例 云治理成熟度及总结 企业用云面临新挑战 云不再是问题，怎么用好云管好云才是问题 企业用云面临诸多挑战，云治理重要性日益凸显 云服务故障发生的原因主要包括云治理问题、人为操作失误、硬件故障、软件故障以及网络问题等，其中云治理问题往往是最根本的原因 云服务故障事件屡屡发生，引起产业各方的广泛关注 云上身份体系复杂度显著提升 云资源及数据缺乏有效的分类管理 随着业务的增长和变化，云上资源种类不断增加，如何进行分类管理成为难题；缺乏有效的数据分级、分层管理策略易导致成本上升和访问效率下降 云上用户身份体系复杂度显著提升，与企业原有身份体系存在不一致或者未打通等情况；此外，各类身份、权限、密钥管理不善易导致安全问题 云上监控不全面，日志分析不足 云上应用架构混乱，扩展能力不足 随着企业用云深入和业务规模扩大，不同云服务提供商或团队可能采用不同的技术和架构，导致迁移或扩展云服务时面临兼容性问题，架构易发生混乱 各类用户云上操作频次增加，但缺少全面、实时、准确的监控与预警；云上日志数量巨大，如何有效收集、存储和分析日志以挖掘数据价值成为难题 云资源供给缺乏规划与弹性 云成本易超支浪费 云服务即开即用的方式决定了用云成本计费模式与传统IT模式大不相同，企业在制定预算和管理资源时面临困难，易造成云成本的超支和浪费现象 企业云资源管理效率低，未进行合理的云资源分配规划，缺乏灵活的编排、调度，易导致资源分配不足、过剩或响应不及时的问题 G O P S全 球 运 维 大 会 暨 研 运 数 智 化 技 术 峰 会2 0 2 4·上 海 站 越来越多企业打造卓越架构，释放云的技术红利 云卓越架构概述 云卓越架构方案：基于多年服务客户的IT治理最佳实践 安全支柱：企业在云上最主要的安全问题 98% 38% 已经分配的账号权限并没有被使用 数据泄漏事件中凭证被盗占比 被盗凭证在Web应用程序攻击中的占比 2024DataBreach InvestigationsReport by Verizon Sysdig2024Cloud-NativeSecurityandUsageReport 2024DataBreach InvestigationsReport by Verizon 人员凭证与程序凭证 源起：凭证泄露是如何发生的 防止凭证泄露的10个方法 程序凭证管理与最佳实践：降低AK泄露风险 必须要使用AccessKey时 建议不使用AccessKey 8 不将AK明文硬编码在代码中杜绝AccessKey公开暴露。 使用临时凭证STSToken 7 凭证有效期短，且可以自动轮转。 使用AccessKeyIP白名单策略拦截来自非可信网络环境的异常调用。 9 10 及时清理闲置AccessKey降低AccessKey暴露时长，减少泄露的风险规模。 使用临时凭证STSToken 使用临时凭证的原因 应用部署在函数计算<服务角色> 应用部署在容器服务ACK<容器服务RRSA功能> 使用临时凭证的方案 使用临时凭证STSToken：ECS场景 ECS实例角色获取临时凭证访问云资源 优势 ü无需自行在实例中保存AccessKey，也没有人员接触程序AK。ü凭证管理简单，不需要手动轮转。ü为不同的实例绑定不同的角色，分别授予所需权限，实现更精细粒度的权限控制。 最佳实践 场景：在ECS实例上部署的应用程序需要访问其他云资源。 •在ECS实例上绑定实例角色，为实例角色授予该应用需要访问的云资源权限。•由ECS元数据服务扮演实例角色获取STSToken。•在该ECS上的程序可以通过阿里云官方SDK，设置实例角色认证方式，从ECS元数据服务获得临时凭证STS Token，访问云资源。 使用临时凭证STSToken：容器场景 容器服务ACKRRSA获取临时凭证访问云资源 优势 ü无需自行在应用中保存AccessKey，也没有人员接触程序AK。ü凭证管理简单，不需要手动轮转。ü通过Java/Python编码示例，客户能够快速完成应用改造。 最佳实践 场景：在容器服务上部署的应用程序需要访问其他云资源。 •开启容器服务RRSA(RAMRolesforService Account)功能。•提交使用了服务账号令牌卷投影功能的应用Pod。•集群将为该应用Pod创建和挂载相应的服务账户OIDC Token文件。•Pod内的程序使用挂载的OIDCToken文件访问STS服务获取扮演RAM角色的临时凭证。 使用临时凭证STSToken：开发环境场景 开发人员使用临时凭证调试 优势 ü研发人员不接触程序AK，减少泄露风险。ü凭证管理简单，不需要手动轮转。 最佳实践 RD多账号企业使用云SSO管理用户身份和权限 •为研发人员分配云SSO用户身份•选择需要访问的云账号，并授予访问配置关联权限。•研发人员直接通过CLI命令acs-sso登录，获取临时凭证进行调试，或登录云SSO门户，选择获取对应账号的临时访问凭证再进行调试。 固定AK：不将AK明文硬编码在代码中 使用环境变量/配置文件 •使用Credentials工具默认凭据链自动获取凭证 阿里云SDK根据指定顺序，依次查找凭证信息。用同一套代码，通过程序之外的配置来控制不同环境下的凭据获取方式。 •指定使用环境变量/配置文件获取凭证 固定AK：如何及时发现凭证泄露风险 治理检测 主动审计 风险监测 RAM和云治理中心诊断凭证管理的风险点及修复方案 操作审计-AccessKey审计排查异常操作 云安全中心发现泄露风险和安全漏洞告警 •AccessKey最近调用时间•AccessKey调用记录：调用的云产品、API、IP等详细信息 •23个治理项，分高、中风险•提供明细数据•提供详细治理方案 •AccessKey明确泄露风险•异常调用风险：存在被盗可能•安全漏洞：及时修复防止通过漏洞泄露凭证 稳定支柱：常见稳定性风险 架构风险 故障应急 变更风险 •单点问题•容错性差•容量问题，大促场景故障频发•…… •缺少变更管控•变更无灰度，分批控制•变更之后，无法回滚•….. •监控不全面，无法准确识别风险•缺少故障应急响应机制•缺少必要的恢复预案•… 高可用架构体系建设思路 容灾：主流容灾架构对比 简单，对于业务侵入较少；不提供在线服务；应用和数据库均是冷备；支持异地部署；发生故障时难以保证切换可靠性，且备份全站成本非常高。 实现单元化的业务跨省机房的无缝切换；部署层面单元化，多个单元之间无访问；调度层面切换禁写局部化、入口引流统一化；数据层面局部化，基于数据时间戳局部同步；数据修复后项化，禁写后的后向数据修复。 不同容灾方案实施成本与容灾能力 同城双活之-逻辑部署架构 流量层 采用云解析DNS实现全局流量调度，支持DNSFailover故障切换、主备切换，异常隔离。 网关层 NLB+云原生API网关，实现高可靠的网关层。云原生API网关，双可用区容灾部署，可实现跨可用区的多个业务集群间的全局负载均衡和秒级故障转移。 应用层 应用多活，采用托管容器服务，Worker节点分不同可用区对等部署，支持应用层面多可用区容灾。 注册中心 注册中心三可用区容灾部署，可实现秒级故障转移。 云数据库/缓存/MQ 云数据库，Redis、MQ均支持多可用区版本能力，实现多AZ容灾。 同城双活之同Region双AZ网络设计 设计关键点 业务场景 容灾 同城多活：VPC内划分的子网均支持多个可用区，应用可以跨可用区部署，实现业务同城多活。 稳定可靠的私有业务环境 容错 阿里云机房按照GB50174-2008《电子信息系统机房设计规范》不低于B级或者《TIA942》的T3+标准建设 容量 地址规划：IP地址统一规划，与现有内网地址不能冲突且留有冗余，可以满足业务长期发展的需求。 弹性架构：ALB/NLB加弹性伸缩实现弹性服务架构 同城双活：防范可用区级故障，基础产品配置建议 计算 存储 网络 ≈ç镜像和快照：对重要服务器创建镜像，对数据盘创建定期或自动快照，通过备份实现故障可快速恢复。 ≈çOSS：采用同城冗余存储（ZRS）类型，将数据多可用区保存，在单可用区故障时保障访问。 ≈ç负载均衡：创建负载均衡，将流量分发到不同后端服务器来扩展应用系统的吞吐能力，消除单点故障。 NAS：通过云备份进行备份，实现故障恢复 容器服务 ≈ç工作负载：通过配置拓朴分布约束、Pod反亲和、PodDisruptionBudget、Pod健康检测与自愈等来实现应用Pod的高可用。 ≈ç节点池&虚拟节点：通过节点池来纳管节点，基于节点的弹性伸缩、部署集、多AZ，结合K8S调度的拓朴分布约束，确保服务在不同的故障域，减少单点故障的风险。 ≈ç负载均衡：在集群中指定负载均衡实例的主备可用区、启用拓朴感知提示等手段来实现。 ≈ç控制面架构：托管类容器服务，均严格采用多副本、多AZ均衡打散部署策略。建议采用托管类容器服务，而不是自建。 同城双活：基础产品配置巡检 同城双活：基础产品配置巡检-Sample 同城双活：应用同城双活解决方案 接入层（将请求路由至正确的单元） 云原生API网关，双可用区容灾部署，可实现跨可用区的多个业务集群间的全局负载均衡和秒级故障转移。 应用层 应用多活，在多个集群中对等部署。 注册中心 注册中心三可用区容灾部署，可实现秒级故障转移。 云数据库 云数据库，双可用区主备部署，主备之间双向同步数据，提供代理数据源，可实现读写分享和灾难场景下秒级切换。 同城双活演练-Workshop 全栈可观测 效率：企业该如何选择资源维护方式？ 效率：推荐采用Terraform落地生产实践 云卓越架构实践案例 某跨国零售企业：云安全与稳定实践 场景痛点 可观测 •安全痛点：存在长期有效的本地RAM用户，人员变动后身份依然有效；未有效保管应用凭据，以明文形式储存在代码库中。•监控痛点：基础设施告警信噪比低，比较分散，健康状态不直观。存在大量无效告警，不利于运维排查问题。 解决方案 •人机身份无密钥：采用SSO单点登录集成企业内部域控，定期清理闲置人员身份；采用RAM角色无AK方案来解决固定应用程序凭据泄露风险。•统一可观测架构：将账号内资源监控实现统一数据采集、存储、分析与使用，并借助机器学习的能力做告警降噪，实现统一的监控大盘，并对接企业内部的ITSM平台，实现告警统一。 人机身份无密钥 方案价值 •降低安全风险：清理高风险账号（近百个账号），修复硬编码的明文凭据，收敛过度授权，有效降低了凭据泄露风险。•统一可观测：梳理基础设施16款云资源的关键监控指标，配置统一的监控大盘，通过智能阀值有效降低无效告警，提升运维效率。 G O P S全 球 运 维 大 会 暨 研 运 数 智 化 技 术 峰 会2 0 2 4·上 海 站 某日资企业：稳定、安全、成本、效率实践 行业/企业属性日资/泛制造行业 人数/云规模＞300≥10M 稳定|安全|成本|效率 •资源分账：通过资源组将不同供应商，不同系统分配到指定的资源组内。进而实现成本分摊。 •账号权限：清理闲置账号（包括人与程序），高危权限及闲置权限。•密钥管理：部署在ECS/ACK上的应用推荐无AK方案。其他环境推荐KMS。•配置审计：通过做WA治理，建立了一套企业内部安全规范，并将这套规