2023数据安全架构设计实例.docx

数据安全架构设计与实战1. 第1章架构2. 1.1什么是架构3. 1.2架构关注的问题4. 第2章安全架构5. 2.1什么是安全6. 2.2为什么使用“数据安全”这个术语7. 2.3什么是安全架构8. 2.4安全架构5A方法论9. 2.5安全架构5A与ClA的关系10. 第二部分产品安全架构11. 第3章产品安全架构简介12. 3.1产品安全架构13. 3.2典型的产品架构与框架14. 3.2.1三层架构15. 32,2ES架构16. 323C/S架构17. 324SoA及微服务架构18. 325典型的框架19. 3.3数据访问层的实现20. 3.3.1自定义DAL21. 332蚓QRM22. 3.3.3使用DBProXy23. 334配合统一的数据服务简化DAL24. 第4章身份认证：把好第一道门25. 4.1什么是身份认证26. 46如何对用户进行身份认证27. 421会话机28. 422持续的消息认证机制29. 423不同应用的登录状态与超时管理30. 424SS了的典型误区31. 4.3口令面临的风险及保护32. 431口令的保护Qa4R2口令?吊鹿34：4：4前端慢速加盐散列案例35. 4.5指纹、声纹、虹膜、面部识别的数据保护36. 4.6MD5、SHAl还能用于口令保护吗37. 4.6.1单向散列算法简介38. 462HaSh算法的选用39. 4.6.3存量加盐HASH的安全性40. 4.7后台身份认证41. 471基于用户用Cket的后台身份认证42. 4.7.2基于ADPKey的后台身份认证43. 4.7.3基干非对称加密技术的后台身份认证44. 474基于HMAC的后台身份认证45. 475基于AES-GCM共享密钥的后台身份认证46. 4.8双因子认证47. 4.8.1手机短信验证码48. 4.8.2TOTP49. 4.8.3U2F50. 4.9扫码认证51. 4.10小结与思考52. 第5章授权：执掌大权的司令部53. 5.1授权不严漏洞简介54. 5.2授权的原则与方式55. 521基于属性的授权56. 5.2.2基于角色的授权57. 523基于任务的授权58. 5.2.4基干ACL的授权59. 5.2.5动态授权60. 5.3典型的授权风险61. 5.3.1平行越权62. 5.3.2垂2越权63. 5.3.3诱导授权64. 5.3.4职责未分离65. 5.4授权漏洞的发现与改进66. 5.4.2褊徜改进67. 第6章访问控制：收敛与放行的执行官68. 61典型的访问控制策略69. 6.1.1基于属性的访问控制70. 6.1.2基于角色的访问控制71. 71.3基于任务的访问控制72. 6.1.4基于ACL的访问控制73. 6.1.5基于专家知识的访问控制74. 6.1.6基于基的辅助访问控制75. 6.1.7访问控制与授权的关系76. 66不信任原则与输入参数的访问控制77. 621基干身份的信任原则78. 622执行边界检查防止缓冲区溢出79. 623参数化查询防止SQL注入漏洞80. 624内容转义及CSP防跨站脚本81. 625防跨站请求伪造82. 626防跨目录路径操纵83. 6.2.75SSRF84. 628上传控制85. 629MethOd控制86. 6.3防止遍历查询87. 第7章可审计：事件追溯最后一环88. 81为什么需要可审计89. 7.2操作曰志内容90. 7.3操作日志的保存与清理91. 7.3.2日志的保存期限92. 第8章资产保护：数据或资源的贴身保镖93. 8.1数据安全存储94. 8.1.1什么是存储加密95. 8.1.2数据存储需要加密吗96. 8.1.3加密后如何检索97. 8.1.4如何加密结构化数据98. 8.2数据安全传输99. 821选择什么样的HTTPS证书100. 8.2.2HTTPS的部署101. 823TLS质量与合规102. 8.3数据展示与脱敏103. 831不脱敏的风险在哪里104. 8.3.2脱敏的标准105. 8.3.3脱敏在什么时候进行106. 8.3.4业务需要使用明文信息怎么办107. 8.4数据完整性校验108. 第9章业务安全：让产品自我免疫109. 9.1一分钱漏洞110. 9.2账号安全111.112. 922防弱口令尝试113. 923防账号数据库泄露114. 9.2.4防垃圾账号115. 925防账号找回逻辑缺陷116. 9.3B2B交易安全117. 9.4产品防攻击能力118. 第三部分安全技术体系架构119. 第10章安全技术体系架构简介120. 10。安全技术体系架构的建设性思维121. 10.2安全产品和技术的演化122. 1021安全产品的“老三样”123. 1022网络层延伸124. 10.2.3主机层延伸125. 1024应用层延伸126. 10.2.5安全新技术127. 10.3安全技术体系架构的二维模型128. 10.4风险管理的“三道防线”129. 10.5安全技术体系强化产品安全130. 1051网络部署架构131. 10.5.2主机层安全132. 10.5.3应用层安全133. 10.5.4数据层安全134. 第11章网络和通信层安全架构135. 11.1简介136. 11.2网络安全域137. 1121最简单的网络安全域138. 11.2.2最简单的网络安全域改进139. 1123推荐的网络安全域140. 11.2.4从有边界祠络到无边界网络141. 1125网络安全域小结142. 11.3网络接入身份认证143. 11.4网络接入授权144. 11.5网络层访问控制145. 1152生产网络主动连接外网的访问控制146. 11.5.3网络防火墙的管理147. 1154内部网络值得信任吗148. 11.5.5运维通道的访问控制149. 11.6网络层流量审计150. 11.7网络层资产保护：DDOS缓解151. 11.7.1DDoS简介152. 11.7.2DDOS缓解措施153. 11.7.3专业杭f)DoS方案154. 第12章设备和主机层安全架构155. 12.1简介156. 12.2身份认证与账号安全157. 1221设备/主机身份认证的主要风险158. 1222动态口令159. 12.2.3一次一密认证方案160. 1224私有协议后台认证方案161. 12.3授权与访问控制162. 12.3.2主机服务监听地址163. 12.3.3跳板机与登录来源控制164. 12.3.4盲动化运维165. 12.3.5云端运维166. 12&邑数据传输167. 12.3.7设备的访问控制168. 12.4运维审计与主机资产保护169. 12.4.1打补丁与防病毒软件170. 12.4.2母盘镜像与容器镜像171. 1243开源镜像与软件供应链攻击防范172. 12.4.4基于主机的入侵检测系统173. 第13章应用和数据层安全架构174. 13.1简介175. 13.2三层架构实践176. 1321B/S架构177. 1322C/S架构178. 13.3应用和数据层身份认证179. 13.3.1SSo身份认证系统180. 13.3.2业务系统的身份认证181. 13.3.3存储系统的身份认证182. 13.3.4登录状态管理与超时管理183. 13.4应用和数据层的授权管理184. 13.4.1权限管理系统185. 1342权限管理系统的局限性186. 13.5应用和数据层的访问控制187. 1352数据库实例的安全访问原则188. 13.6统一的日志管理平台189. 13.7应用和数据层的资产保护190. 13.7.1KMS与存储加密191. 13.7.2应用网关与HTTPS192. 13.7.3WAF（Web应用防火墙）193. 13.7.4CC攻击防御194. 13.7.5RASP195. 13.7.6业务风险控制196. 13.8客户端数据安全197. 13.8.1客户端敏感数据保护198. 13.8.2安全传输与防劫持199. 13.8.3客户端发布200. 第14章安全架构案例与实战201. 14.1零信任与无边界网络架构202. 14.L1无边界网络概述203. 14.1.2对人的身份认证（SSo及U2F）204. 14.L3对设备的身份认证205. 14.1.4最小授权原则206. 14.1.5设备准入控制207. 14.1.6应用访问控制208. 14.1.7借鉴与改讲209. 14.2统一HTTPS接入与安全防御210. 1421原理与架构211. 14.2.2应用网关与HTTPS212. 1423WAF与CC防御213. 1424私钥数据保护214. 1425负载均衡215. 1426编码实现216. 14.2.7典型特点217. 14.3存储加密实践218. 14.3.1数据库字段加密219. 豆氾数据库透明加密220. 14.3.3网盘文件加密方案探讨221. 14.3.4配置文件口令加密222. 14.4最佳实践小结223. 14.4.1统一接入224. 14.4.2收缩防火墙的使用225. 1443数据服务226. 1444建立KMS227. 14.4.5全站HTTPS228. 14.4.6通用组件作为基础设施229. 14.4.7自动化运维230. 第四部分数据安全与隐私保护治理231. 第15章数据安全治理232. 15.1治理简介233. 15.1.2治理三要素234. 15.2数据安全治理简介235. 15.2.1数据安全治理的要素236. 1522数据安全治理与数据安全管理的关系237. 15.3安全项目管理238. 15.4安全运营管理239. 15.5合规与风险管理240. 15.6安全开发生命周期管理（SDL）241. 15.6.1SQL注入漏洞案例242. 15.6.2SDL关键检杳点与检查项243. 15.6.3SDL核心工作244. 15.7风险管理245. 15.7.1风险识别或评估246. 1572风险度量或成熟度分析247. 15.7.3风险处置与收敛跟踪248. 1574风险运营工具和技术249. 15.8PDCA方法论与数据安全治理250. 第16章数据安全政策文件体系251. 16.1数据安全文件体系252. 16.1.1四层文件体系架构简介253. 16.1.2数据安全四层文件体系254. 16.1.3标准、规范与管理规定的关系255. 16.1.4外部法规转为内部文件256. 16.2数据安全政策总纲257. 16.2.1数据安全的目标和范围258. 16.2.2数据安全组织与职责259. 1623授权原则260. 1624数据保护原则261. 1625数据安全外部合规要求262. 16.3数据安全管理政策263. 16.3.1数据分级与分类264. 16.3.2风险评估与定级指南265. 16.3.3风险管理要求266. 16.3.4事件管理要求267. 16.3.5人员管理要求268. 1636配置和运维管理269. 16.3.7业务连续性管理270. 16.4数据安全标准271. 16.4.1算法与协议标准272. 16.4.2口令标准273. 16.4.3产品与组件标准274. 1644数据脱敏标准275. 16.4.5漏洞定级标准276. 16.5数据安全技术规范277. 16.5.1安全架构设计规范278. 1652安全开发规范279. 16.5.3安全运维规范280. 1654安全配置规范281. 16.6外部合规认证与测评282. 第17章隐私保护基础283. 173隐私保护简介284. 17.1.2什么是隐私285. 17.1.3隐私保护与数据安全的关系286. 17.L4我需要了解隐私保护吗287. 17.L5隐私保护的技术手段288. 17.L6合规遵从289. 17.2GDPR290. 17.2.1简介291. 1722而新角色292. 1723六项原则及问责制293. 1724处理个人数据的六个法律依据294. 1725处理儿童数据295. 1726特殊的数据类型296. 176.7数据主体的权利297. 17.2.8数据控制者和数据处理者的义务298. 1729违规与处罚299. 17.3个人信息安全规范300. 17.3.1简介301. 17.3.2个人信息安全原则302. 17.3.3个人信息的生命周期管理303. 17.4GAPP框架304. 17.5ISO27018305. 第18章隐私保护增强技术306. 186隐私保护技术初探307. 18.2去标识化308. 18.2.1匿名化309. 1822假名化310. 18.2.3K匿名311. 18.3差分隐私312. 18.3.1差分隐私原理313. 18.3.2差分隐私噪声添加机制314. 18.3.3数值型差分隐私315. 18.3.4数值型差分隐私的局限性316. 18.3.5离散型差分隐私317. 18.3.6差分隐私案例318. 18.3.7差分隐私实战319. 第19章GRC与隐私保护治理320. 19.1风险321. 19.2GRC简介322. 19.2.1GRiN三领域323. 19.2.2GRc空制模型324. 19.3隐私保护治理简介325. 19.4隐私保护治理GRC实践326. 19.4.1计划327. 19.4.2执行328. 19.4.3检查329. 19.4.4显理330：19：5隐私保护能力成熟度331. 第20章数据安全与隐私保护的统一332. 20.1以数据为中心的统一治理333. 20.1.1统一的数据安全治理334. 20.1.2统一数据目录与数据流图335. 20.1.3统一数据服务336. 20.2统一的数据安全生命周期管理337. 2021数据安全生命周期338. 20.2.2全生命周期的数据主体权利保障339. 2023典型案例340. 20.3数据安全治理能力成熟度模型（DSGMM）341. 附录数据安全架构与治理总结342. 参考文献第1章架构我们都听说过“架构”这个词，那么架构是指什么呢？本章力求用最简单的语言，让读者明白“架构”并不是虚无缥缈的概念，而是一种在方案设计、系统实现、产品部署、安全改进等项目活动中所必需的思维模式、通用语言和沟通桥梁。1.1什么是架构没有图纸，我们能够直接建造简易的建筑，如围墙、小棚等。但是，没有图纸，我们能够建造出埃菲尔铁塔吗？如图1-1所示。没有图纸，就没有宏伟的建筑。架构所要提供的正是类似于“图纸”这样一种东西。图Ll没有图纸就无法建造的埃菲尔铁塔架好系统中所有元素以及元素间关系的集合。简言之，架构由元素和关系组成，如图1-2所示。图L2架构的定义通俗地说，架构就是系统中包含了哪些元素，这些元素之间的关系是什么样的。也有人把架构简单地总结成“几个框”加上“几根线”，那么这几个框就是元素，框之间的线就是关系，这样就很好理解了。回到埃菲尔铁塔这个例子，元素就是铁塔有哪几个主要部分，关系就是这些部分之间是如何组合在一起的。元素往往也称为组件或逻辑模块，比如当我们说“组件”的时候，表示这是一个独立存在的元素，是一个基本的功能单元（就像一个零部件），如开源组件：Nginx提供前端Web服务功能。MySQL提供数据库功能。而逻辑模块，表示一个抽象的逻辑单元，往往并不独立存在，而是依附、融入或横跨在多个组件上，如本书即将讲到的安全架构的5个主要的逻辑模块。由抽象到具体，架构包括如下几个常用的概念：,概念架构（COnCePtUalArChiteCtUre）:在产品的早期，或者需要向上汇报的时候，通常会使用概念架构，以尽可能简化、抽象的方式，传达产品的概念或理念；概念架构仅涉及基本的定义（组件和组件之间的关系），不涉及接口细节等内容。逻辑架构：在产品需求逐步明确后，通常会用到逻辑架构，体现出业务逻辑模块及之间的关系。物理架构：在产品发布或部署时，需要用到物理架构，体现具体的组件及部署位置。接下来，我们将主要使用概念架构或逻辑架构，并使用架构图来展示元素（组件或逻辑模块）以及元素之间的关系。例如，常见的三层架构如图1-3所示。用户图L3三层架构示例其中：用户接口层、业务逻辑层、数据访问层构成了三层架构的元素（模块），中间的箭头表示了它们之间的访问顺序关系。有关架构的进一步知识，可参考Tc）GAF：TheOpenGroupArchitectureFramework TOGAF: https:/en.wikipedia.org/wiki/The_Open_Group_Architecture_Framework料（ToGAF是一个被广泛接受的架构框架。除此之外，也存在其他的架构框架可供参考）。这些内容不是本书的关注重点，因此不再展开讲述。1.2架构关注的问题对用户而言，一个好的产品主要体现在如下方面： 是否提供预期的功能。,质量是否过关，且没有副作用（不会给用户带来额外的损失或麻烦）。如果一把菜刀，切几次菜之后刀刃就变形了，那么这把菜刀从质量上讲就是不合格的。架构的出发点也是一样的，需要考虑的主要因素也是功能和质量，如图1-4所示。图14架构关注的问题对于产品功能，需要对功能模块、组件进行分割与组装，且保障模块及组件之间的高内聚低耦合。这个部分主要是软件架构师或系统架构师需要关注的范围。对于产品质量，主要关注以下方面（如图1-5所示）：图1-5产品质量关注的问题性能（在预期的用户量/并发数条件下，产品功能能否满足用户正常使用的需要）。 安全性（防止黑客攻击、入侵，导致服务器不可用、数据被篡改、数据泄露等安全事件，以及确保安全相关的法律合规）。 扩展性（在用户规模大幅增长时，能否通过扩容解决问题）。 可维护性（日常运维是否尽可能自动化，降低运维人员投入，如软件更新、数据更新、日志清理、证书/License到期提醒等）。其中安全性部分，由于专业性强，涉及的领域众多，本书将其单独提取出来，即为产品安全架构。第2章安全架构安全架构是架构在安全性这个方向上的细分领域，也是本书关注的重点。本章主要介绍安全的基本概念与相关术语，并提出安全架构的5A方法论。2.1什么是安全在提到安全架构之前，我们先看看安全的定义：安全是产品的质量属性，安全的目标是保障产品里信息资产的保密性(Confidentiality)s完整性(Integrity)和可用性(Availability),简记为ClA(如图2-1所示)o可用性(Availability)图2-1安全的目标：CIA三要素 保密性：保障信息资产不被未授权的用户访问或泄露。 完整性：保障信息资产不会未经授权而被篡改。可用性：保障已授权用户合法访问信息资产的权利。1.保密性为了理解保密性，先来看几个简单的案例。影响保密性最典型的一个场景就是内容被窃听，远在网络时代之前，保密性就广泛应用。比如1945年苏联送给美国大使馆的一枚精制美国国徽名为“TheThing”（被译为“金唇”）,里面就藏着一个窃听器，被悬挂在大使馆长达8年之久，让苏联获知大量美国情报。“TheThing”窃听器之所以没有被美国特工检测出来，是因为使用了一种当时非常先进的被动式调谐的无线电技术，窃听器本身不需要电源，不发射电磁波，只接受外面定向发射过来的电磁波，并在调谐后反射回去。这就超出当时美国特工的知识范围了，美国的反窃听设备没有检测到任何无线电信号，于是这枚国徽顺利地通过了检测。以IT系统为例，假设某外企实施薪酬保密制度，员工张三在工资系统中查询自己工资的时候，利用系统缺陷（平行越权漏洞，后面会讲到），知道了其他员工的工资，这就属于保密性被破坏。也就是，信息被不该知道的人知道了！其他可能导致保密性被破坏的场景包括： 海底光缆窃听。 使用嗅探工具（sniffer）嗅探网络流量，如图22所示。BSmertSniff-×p9EditywQPeonSUelPt>T1DQ¾cS,IndexProtoc-LocalAddressRcmot-LoolPortRemotePortLMlHostRe.Servi-PMketSDaUSizeTotalSaeDA1TCP192.168.0.107139225543880LAPTOP-AL-die-http76,463Bytes8.015Bytes«1«2TCP192.168.0.1072032015544180IAPTOPAL-p一http3424.344Bytes26.129Bytes203TCP192-1610720320.5M4680LAPTOP-AL-Pe-http118.221Bytes10J38Bytes2三94TCP192.168.0.10720320一5544780IAPTOP-AU.p一http41.2Bytes2.216Bytes8STCP192.168.0.10720320.5545060IAPToPAL-P-http105.061Bytes8,561Bytes2vHTTP/1.1200OKADate:Sat916Har21912:13:1¼CHTContent-Type:te×thtnl;charset-utf-8Transfer-Encoding:chunkedConnection:keep-aliueSerued:38005.38005.Content-Encoding:gzip<!DOCTVPEHTNL><HTMl><head><netanaRe",renderercontent-MwebkitM><netahttp-equiu-aX-UA-CRpatiblecontent-0IE-EMlateIE7tt><netahttp-equiu-*aContent-Typea*content-eate×thtnl;Charset-Utf-Bo><title>_<title><netanae-keywords*COntnt"；<netanane-avdescriptionaacontent-*<neta11Re-aauthoraacontent-9*“>r»1«etrannn<ra1hrF三thM,n/d1rt,rn/、vMHBBBi8TCP/IPC8ver<tm.Selected图22嗅探射频辐射（20世纪90年代，有很多人遇到过家里黑白电视机被邻居家VCD播放机正在播放的节目所覆盖的情况）。黑客攻击导致的数据泄露（SQL注入、拖库）。2 .完整性在上面的例子中，如果张三不经过公司的加薪流程，就可以自行在工资系统中修改自己的工资，这属于完整性被破坏。也就是信息被未经授权的人篡改了！其他导致完整性被破坏的场景包括： 主机感染病毒或木马，比如2017年WannaCry（想哭）木马横扫江湖，感染众多计算机。操作系统内核文件被替换。 网站被入侵后，内容被篡改。 网络劫持篡改（很多HTTP网页中加塞的广告就是这么来的） 应用层越权操作。文件下载被替换。3 .可用性接着前面的例子，如果张三使用脚本持续高频地查询工资系统，并导致其他员工访问不了工资系统，这就属于可用性被破坏，也就是让大家都访问不了。这就好比停车场堆满了石头、餐馆被不吃饭的人占满、高速公路停满了汽车，无法继续提供原来的服务了。典型的破坏可用性的场景包括：DDoS或CC攻击，导致网络拥塞、主机资源耗尽，从而网站无法打开。缓冲区溢出导致服务异常中止。除了ClA三要素，根据组织或实际业务需要，还可以添加更多的安全目标，如可追溯性（或称为可审计性）。在发生影响数据保密性、完整性、可用性的安全事件之后，可基于记录的日志追踪溯源，复盘事件发生的全过程，找到导致事件发生的根本原因，加以改进。但从根本上讲，追溯也不是最终的目的，通过追溯与改进，最终的目的还是保障数据的保密性、完整性、可用性。此外，在实际工作中，我们最常使用的是网络安全、信息安全、数据安全等概念，作为业内人士，也经常赋予它们不同的含义，且有广义和狭义之分，为便于区分，下面简单介绍几个概念的区别。2.2为什么使用“数据安全”这个术语在安全领域的发展历程中，使用了信息安全、网络安全、网络空间安全、数据安全等概念。那么本书为什么选择“数据安全”这个术语呢？让我们先来看看每个术语的含义。1 .信息安全广义的信息安全（InformationSecurity）,是基于“安全体系以信息为中心”的立场，泛指整个安全体系，侧重于安全管理。例如ISO27001信息安全管理体系就使用了广义的信息安全概念。狭义的信息安全，在不同的组织内部，往往有不同的含义，主要有：内容合规，防止有毒有害信息内容（黄赌毒等）的发布、传播。DLP（DataleakagePrevention,数据泄露防护），防止内部数据泄露等，例如在技术手段上，通过综合性的DLP解决方案，防止内部保密资料流出公司；在管理政策上，防止员工有意或无意地泄露信息，如员工收集内部保密资料提供给竞争对手等。2 .网络安全网络安全这个概念也是不断演化的，如图2-3所示，最早的网络安全（NetWorkSeeUrity）是基于“安全体系以网络为中心”的立场，主要涉及网络安全域、防火墙、网络访问控制、抗DDOS（分布式拒绝服务攻击）等场景，特别是以防火墙为代表的网络访问控制设备的大量使用，使得网络安全域、边界、隔离、防火墙策略等概念深入人心。NetworkSecurity（网络安全）CyberSecurity（网络空间安全）图23网络安全概念的演变后来，网络安全的范围越来越大，向云端、网络、终端等各个环节不断延伸，发展为网络空间安全（CyberspaceSecurity）,甚至覆盖到陆、海、空、天领域，但CyberSPaCe这个词太长，就简化为CyberSecurity7。所以，我们现在所说的网络安全，一般是指网络空间安全(CyberSecurity),仍基于“安全体系以网络为中心”的立场，泛指整个安全体系，侧重于网络空间安全、网络访问控制、安全通信、防御网络攻击或入侵等。3 .数据安全广义的数据安全(DataSecurity)是基于“安全体系以数据为中心”的立场，泛指整个安全体系侧重于数据分级及敏感数据全生命周期的保护。它以数据的安全收集或生成、安全使用、安全传输、安全存储、安全披露、安全流转与跟踪、安全销毁为目标，涵盖整个安全体系。数据安全，也包括个人数据安全与法律合规，也就是隐私保护方面的内容。狭义的数据安全往往是指保护静态的存储级的数据，以及数据泄露防护(DLP)等。4 .对比与小结从信息安全到网络安全再到数据安全，体现了人们对安全认知的演变历程，也体现出使用者所在企业安全工作的侧重点(或立足点、视角)如图2-4所示。图24安全概念的演变早期，信息安全的范围最大（有句话是“信息安全是个筐，什么都可以往里面装”），而网络安全（NetworkSecurity）是信息安全的子集，网络安全（NetworkSecurity）可看成是海关（或检查站），需要核对身份、检查物品（品类数量控制/检验检疫），是站在网络边界（以及重要的流量节点）看世界，如图25所示。信息安全图2-5早期的信息安全、网络安全、数据安全范围现在，信息安全这个词仍有使用，不过使用场景不是很多了，且有狭义化的趋势，多数情况下可以被网络空间安全(CyberSecurity)所覆盖，也就是说，CyberSeCUrity范围最大。但CyberSeCUrity并没有完全覆盖数据安全，如数据安全里面的长臂管辖权(治外法权)，如图2-6所示。图26当前的网络空间安全与数据安全数据安全更接近安全的目标，可看成是数据的随身保镖，随着数据流动，数据流到哪里，安全就覆盖到哪里。图26为安全概念由信息安全到数据安全的变迁。大家其实不用纠结究竟应该使用哪个术语，我们完全可以根据企业的需要、侧重点，选择相应的术语。即使你所在企业使用的是其他术语，本书所介绍的相关实践也是可以参考的，因为它们之间存在大量的交集。随着信息时代向数据时代的转变，本书将主要使用广义的数据安全这个概念，它更接近安全保护的目标，更适应业务发展的需要，并且这里的数据不仅包括静态的、存储层面的数据，也包括流动的、使用中的数据。我们需要在使用数据的过程中保护数据，在数据的全生命周期中保护数据，特别是保护涉及个人隐私的数据。也就是说，数据安全这个词，可以将信息安全、网络安全以及隐私保护的目标统一起来。下面小结一下各种安全术语的差异和典型的使用场景，如表2-1所示。表21各种安全术语及适用场景术语狭义广义典型使用场景信息安全防止敏感信息的不当扩散.包括控制有毒有害信息（黄赌毒）、内部人为泄密等安全体系架构”以信息为中心”，泛指整个安全体系强调安全管理体系；强调信息及信息系统的保密性、完整性、可用性；强调内容合规；强调DLP（防止内部人为的信息泄露）；强调对静态信息的保护（比如存储系统、光盘上的信息）网络安全侧重于网络安全域、网络访问控制、防网络攻击等安全体系架构“以网络为中心”，泛指整个安全体系强调网络边界和安全域；强调网络入侵防御；强调网络通信系统或传输安全；强调网络空间主权数据安全以保护数据本身为核心.包括加密、脱敏、防差分隐私分析等安全体系架构”以数据为中心”，泛指整个安全体系强调全生命周期中的数据保护；强调数据作为生产力；强调数据主权或数据主体权利；强调长智管辖权；强调隐私保护通常，如无特定的语境或上下文关联，以上三个术语都使用广义的含义，泛指整个安全体系，但在特定的环境，也可能使用狭义的含义。有统计表明，全球数据量每两年翻一番，也就是说从现在开始，未来两年所产生的数据量将超过过去人类历史上数据量的总和。随着大数据时代的到来，数据无疑成为各企业以及用户个人最重要的数字资产，数据安全与隐私保护将成为安全体系建设中的重中之重。2.3 什么是安全架构安全架构是架构在安全性这个方向上的细分领域，其他的细分领域如运维架构、数据库架构等。在IT产品的安全性上，常见到三类安全架构，组成了三道防线： 产品安全架构：构建产品安全质量属性的主要组成部分以及它们之间的关系。产品安全架构的目标是如何在不依赖外部防御系统的情况下，从源头打造自身安全的产品，构建第一道防线。 安全技术体系架构：构建安全技术体系的主要组成部分以及它们之间的关系。安全技术体系架构的任务是构建通用的安全技术基础设施，包括安全基础设施、安全工具和技术、安全组件与支持系统等，系统性地增强各产品的安全防御能力，构建第二道防线。 审计架构：独立的审计部门或其所能提供的风险发现能力，但审计的范围是包括安全风险在内的所有风险，构建第三道防线。在具备SDL（SecurityDevelopmentLifecycle,安全开发生命周期）流程的企业中，通常会有系统架构师、安全架构师、运维架构师或数据库架构师（当然，在名称上不一定是架构师这种叫法）等人员参与产品的正式方案评审活动，其中安全架构师的职责就是对该产品的安全性进行评估。本书主要介绍前两个方面的架构： 产品安全架构：如何打造一个安全的产品（本书第二部分）。 安全技术体系架构：如何构建并完善通用的安全技术基础设施（本书第三部分）。2.4 安全架构5A方法论无论是进行产品的安全架构设计或评估，还是规划安全技术体系架构的时候，都有几个需要重点关注的逻辑模块，它们可以在逻辑上视为安全架构的核心元素。以应用/产品为例，核心元素包括：,身份认证(AUthentiCatiOn):用户主体是谁？ 授权(Authorization)：授予某些用户主体允许或拒绝访问客体的权限。 访问控制(ACCeSSCOntrOI):控制措施以及是否放行的执行者。 可审计(AUditabIe):形成可供追溯的操作日志。 资产保护(ASSetProteCtiOn):资产的保密性、完整性、可用性保障。本书将这5个核心元素称为安全架构5A(即5个以A开头的单词)或5A方法论。我们将其进一步扩展： 主体的范围不局限于用户，将其扩展到所有人员(用户/员工/合作伙伴/访客等)、设备、系统。 安全架构从应用层扩展到空间立体，覆盖物理和环境层、网络和通信层、设备和主机层、应由和数据层。由此，安全架构5A可用图27来表示。Asset Protection对数据和资源的全生命周期保护Authentication 对人员、设备、 系统的认证Auditable立体可审计Authorization对人员、设备、系统的授权AccessControl立体控制措施及是否放行图27安全架构5A安全架构的5A方法论将贯穿全书，成为安全架构设计（无论是产品的架构设计，还是安全技术体系的架构设计）、风险评估等安全工作的思维方式（或共同语言）。其中，资产包括但不限于（如图28所示）图