读数据安全架构设计与实践01安全架构基础(上)

1. 术语

1.1. 信息安全

• 1.1.1. Information Security

• 1.1.2. 广义的信息安全​，是基于“安全体系以信息为中心”的立场，泛指整个安全体系，侧重于安全管理

• 1.1.3. ISO 27001信息安全管理体系

• 1.1.4. 内容合规，防止有毒有害信息内容（黄赌毒等）的发布、传播

• 1.1.5. DLP（Data leakage Prevention，数据泄露防护）​，防止内部数据泄露等

1.2. 网络安全

• 1.2.1. Network Security

• 1.2.2. 最早的网络安全是基于“安全体系以网络为中心”的立场，主要涉及网络安全域、防火墙、网络访问控制、抗DDoS（分布式拒绝服务攻击）等场景，特别是以防火墙为代表的网络访问控制设备的大量使用，使得网络安全域、边界、隔离、防火墙策略等概念深入人心

1.3. 网络空间安全

• 1.3.1. Cyber Security

• 1.3.2. 网络安全的范围越来越大，向云端、网络、终端等各个环节不断延伸，发展为网络空间安全（Cyberspace Security）​，甚至覆盖到陆、海、空、天领域，但Cyberspace这个词太长，就简化为Cyber Security了

• 1.3.3. 仍基于“安全体系以网络为中心”的立场，泛指整个安全体系，侧重于网络空间安全、网络访问控制、安全通信、防御网络攻击或入侵等

• 1.3.4. 范围最大

1.4. 数据安全

• 1.4.1. Data Security

• 1.4.2. 广义的数据安全是基于“安全体系以数据为中心”的立场，泛指整个安全体系侧重于数据分级及敏感数据全生命周期的保护

• 1.4.3. 以数据的安全收集或生成、安全使用、安全传输、安全存储、安全披露、安全流转与跟踪、安全销毁为目标，涵盖整个安全体系

• 1.4.4. 数据安全，也包括个人数据安全与法律合规，也就是隐私保护方面的内容

• 1.4.5. 狭义的数据安全往往是指保护静态的存储级的数据，以及数据泄露防护（DLP）等

• 1.4.6. Cyber Security并没有完全覆盖数据安全，如数据安全里面的长臂管辖权（治外法权）

• 1.4.7. 数据安全更接近安全的目标，可看成是数据的随身保镖，随着数据流动，数据流到哪里，安全就覆盖到哪里

• 1.4.8. 在使用数据的过程中保护数据，在数据的全生命周期中保护数据，特别是保护涉及个人隐私的数据

• 1.4.9. 数据安全这个词，可以将信息安全、网络安全以及隐私保护的目标统一起来

2. 安全理念

2.1. 主动预防”胜于“事后补救”

2.2. 默认就需要安全，安全贯穿并融入产品的生命周期，尽可能地从源头改善安全

• 2.2.1. 对数据的保护，也不再是保护静态存储的数据，而是全生命周期的数据安全与隐私保护

• 2.2.2. 在安全设计上，不依赖于广大员工的自觉性，而是尽量让大家不犯错误

2.3. 数据安全与隐私保护可以和业务双赢，数据安全与隐私保护不是妨碍业务的绊脚石，也可以成为助力业务腾飞的核心竞争力

• 2.3.1. 只有真正从用户的立场出发，充分重视数据安全，尊重用户隐私，才能赢得市场的尊重

2.4. 基于身份的信任思维：默认不信任企业内部和外部的任何人、设备、系统，需基于身份认证和授权，执行以身份为中心的访问控制和资产保护

2.5. 不纠缠产品或技术的理论细节，只考虑是否属于业界最佳实践，是否可以更好地用于安全建设，做建设性安全

3. 数据安全

3.1. 数据泄露事件层出不穷，就算是安全建设得比较好的企业，也不能保证自己不出问题

• 3.1.1. 在日常安全工作中，还面临着三大困境—资源有限、时间不够、能力不足，使得我们距离数据安全的目标还有不小的差距

3.2. 资源有限

• 3.2.1. 体现在企业在安全方面的投入往往不足，特别是在预防性安全建设、从源头开始安全建设的投入方面，更加缺乏

• 3.2.2. 在有的产品团队，人力几乎全部投在业务方面，没有人对安全负责，产品发布上线后，也缺乏统一的安全增强基础设施，导致产品基本没有安全性可言

3.3. 时间不够

• 3.3.1. 因为业务开发忙得不可开交，完成业务功能的时间都不够，哪里还有时间考虑安全呢

3.4. 能力不足

• 3.4.1. 体现在具备良好安全设计能力和良好开发能力的人员太少

• 3.4.2. 基层开发人员普遍缺乏良好的安全实践和意识，写出来的应用频频出现高危漏洞

• 3.4.3. 事先意识到安全问题，在实现上，安全解决方案也是五花八门，*重复造轮子，且互不通用，往往问题多多，效率低下

• 3.4.4. 发现了安全问题，然而牵一发而动全身，修改了问题还担心业务服务是否正常运转

3.5. 寄希望于企业内安全团队的事后防御

• 3.5.1. 时间不等人，险情就是命令

• 3.5.1.1. 漏洞或事件报告过来的时候，无论是节假日，还是半夜时分，都需要立即启动应急响应，​“三更起四更眠”屡见不鲜

• 3.5.2. 依赖各种安全防御系统，没有从根本上解决问题，属于治标不治本，黑客经常能找到绕过安全防御系统的方法，就如同羸弱的身体失去了铠甲的保护

• 3.5.3. 事后修复很可能会影响业务连续性，即便产品团队已经知道问题出在哪里了，但是由于业务不能停，风险迟迟得不到修复，因此还可能引发更大的问题

3.6. 通过安全架构方法论的引入，探讨如何从源头开始设计产品自身的安全架构，快速提升产品自身的安全能力，让产品（网络服务等）天然就具有免疫力，构建安全能力的第一道防线

3.7. 梳理安全技术体系架构，建立并完善安全领域的基础设施及各种支撑系统，让产品与安全基础设施分工协作，并对协作进行疏导

• 3.7.1. 减少各业务在安全上的重复性建设和资源投入，避免重复造轮子，让业务聚焦到业务上去，节省业务团队在安全方面投入的时间

• 3.7.2. 产品外部的安全能力，构成了第二道防线

3.8. 以数据安全的视角，一览企业数据安全治理的全貌，协助提升大家的架构性思维，站在全局看问题，了解数据安全与隐私保护治理实践