如果将金融机构IT系统比作一个大城市
那么云就是城市建立卫星城的天然土壤
城市原有的空间和环境资源有限
随着城市化进程的加速
中心城区多半出现房价贵
竞争压力、交通拥堵等现象
规模扩大的同时
需要更多的资源和空间以疏导城市功能
与中心城眉毛胡子一把抓的发展思路不同
云上卫星城
有其独特的功能定位和建设策略
金融机构互金核心系统搬上“专有云”
云上架构优势支撑金融敏态业务平滑开展
软件授权（License+Renew）/订阅模式（Subscription）灵活选择
IT投入成本大幅降低
安全能力服务化，运营效率显著提升
金融科技助力业务发展
一天， 城外爆发大规模瘟疫
为了不影响城市的正常运转
管理者决定在城市入口设置集中隔离区
并将“对外贸易”的窗口统一设置在这里
这一区域被称为DMZ区
金融机构将必须公开业务的Web前置服务器设置在这里
如手机银行、直销银行、数字分行（支付宝小程序、生活号）等
这样做的好处是显而易见的：
外部流量属性复杂
夹杂大量攻击和病毒
隔离区天然具有安全属性
可以有效防止“疫情”蔓延至城内
内部流量通过DMZ区服务器进行对公交互
同样不影响与来自互联网流量的业务往来
DMZ区位于系统中间的缓冲地带
是与公网交互承载复杂“对外贸易”的窗口
同时也是“安保措施”最完备的区域
60%-70%的安全产品部署在这里
对公网流入的复杂流量进行识别、检测、清洗、拦截、阻断和追溯
传统DMZ：碎片化管理的安全孤岛
由于中心城区建设周期长
历史久远，且主要资源集中
管理者早期将隔离区设置在中心城区外
招聘来自不同城市的安保人员
针对性管理各类贸易
运行一段时间后
这种隔离方式的弊端逐渐显现出来：
首先，来自不同地区的安保人员语言不通
管理割裂
信息难以聚合和共享
安全孤岛和碎片化令防护效率大打折扣
其次，线上金融业务具有大流量、高并发、强波动的特点
当与传统业务共享流量入口时
基于中心城区架构设置的隔离区
基础架构原始，管理模式陈旧
难以根据业务需求实现动态弹性伸缩
此外，在新增应用或金融强对抗场景下
涉及多个团队管理的多个网络域配置变更
团队间沟通、申请、审批等流程繁琐
难以实现自动化灵活变更与管理
那么问题来了：
DMZ隔离区该如何设置才能在保证安全的同时不影响正常贸易往来？
安保人员如何分配才能达到最佳防护效果？
防护效率与成本投入之间如何取得动态平衡？
DMZ上云：双轨并行实现平滑过渡
2020年，人民银行发布多个金融行业标准
开启金融安全的云化“元年”
随着银行消金和场景金融持续高速增长
《网上银行系统信息安全通用规范》2020新版发布
互金核心“DMZ区域和内网区域”整体上云成为必选项
监管合规了
迁移的实际困难仍不可忽视
银行IT基础设施历史悠久、结构复杂
流量入口迁移上云
实现业务平稳过渡是关键
对于新建局点
云安全产品与业务一体化管控
对于传统DMZ
在原有安全措施不变的前提下
新DMZ与传统DMZ双轨并行，实现双活
压测稳定后
随业务与安全需求“渐进式迁移”
降低迁移风险和升级成本
更重要的是，流量入口上云后
Web前置与业务应用交互方式不变
不增加运维负担，大幅提升安全效率
把复杂留给阿里云，简单留给用户
相较于传统DMZ区
云上安全不再“各自为战”
云盾平台统一安全管控
云端威胁情报动态感知
单点威胁全网阻断
自动化编排响应
安全事件处置效率提升百倍
数字化开放生态平台
无感应对复杂场景扩容
复杂防护与强对抗场景，凸显云的原生架构优势
架构优势从不单纯局限于管理提效
网络攻防演习中
整体安全水位高于传统DMZ
云原生情报赋能
防护规则更新速率数倍于传统安全产品
安全事件归并
真正需要被关注的告警减少到20%
云盾统一资产管理与漏洞管理
提升漏洞治理水位
协助用户建立安全漏洞管理机制
覆盖信息系统全生命周期
快速发现安全漏洞
依托有效的漏洞管理
逐步降低存量漏洞数量
攻击面收敛API化
链条式管理杜绝资产割裂
所有对外暴露IP登记上云，全面可查
全部IP实现界面查看或API导出，高效管理
依托云的原生一体化安全优势
提升应急响应时效
云上安全组件横向拉通
应急处置能力提升8倍以上
自动化编排赋能事件处置秒级响应
运行在阿里专有云之上的金融核心业务
借助阿里云ASR容灾演练平台
做到运维人员面对数据中心级别故障时
能够敢于下决策进行切换
安全产品跟随业务决策自动联动切换
在不可抗灾难中
有效保障数据不丢失、业务不中断
告别传统DMZ高建设成本和运维投入
云端DMZ全局点建设投入节约近 75%
后期维保成本同比例下降
中台架构理念下数字安全体系赋能业务
控制台+账户+日志“多维统一”
安全智能打破数据孤岛
人员投入大幅缩减
实现便捷、高效安全运维
