同类推荐
-
-
用数据说话:WPS表格数据处理与分析一本通
-
¥89.00
-
-
AI助力Python编程做与学
-
¥99.00
-
-
嵌入式系统电子设计与应用
-
¥68.00
-
-
Web渗透测试从新手到高手:微课超值版
-
¥79.80
-
-
C++树莓派机器人开发实战指南
-
¥198.00
-
-
大语言模型:基础与前沿
-
¥118.00
-
-
Python3编程从零基础到实战
-
¥99.00
-
-
生成式AI绘画:Stable Diffusion从基础…
-
¥89.00
-
-
剪映视频后期剪辑零基础入门到精通
-
¥89.00
-
-
开发者关系实践指南
-
¥79.80
|
|
图书信息
|
|
|
Google系统架构解密:构建安全可靠的系统
|
ISBN: | 9787115569257 |
定价: | ¥129.80 |
作者: | (美)希瑟·阿德金斯[等]著 |
出版社: | 人民邮电出版社 |
出版时间: | 2021年09月 |
开本: | 24cm |
页数: | 34,355页 |
装祯: | 平装 |
中图法: | TP316 |
相关供货商
供货商名称
|
库存量
|
库区
|
更新日期
|
北京人天书店有限公司
|
15
|
库区7/样本7-1
|
2024-04-19
|
其它供货商库存合计
|
405
|
|
2024-04-19
|
图书简介 | 本书分为五大部分, 共21章, 内容涉及安全性和可靠性的关系, 系统的设计原则、实现原则、维护原则, 还辅以丰富的案例分析。 |
目录 | 序一 xviir对本书的赞誉 xxir 序一 xxiiir 序二 xxvr 前言 xxviir 第 一部分 入门资料r 第 1章 与可靠的交集 3r 1.1 从密码和电钻谈起 3r 1.2 可靠与:设计注意事项 4r 1.3 机密、完整、可用 5r 1.3.1 机密 5r 1.3.2 完整 5r 1.3.3 可用 6r 1.4 可靠与:共 6r 1.4.1 隐形 6r 1.4.2 评估 7r 1.4.3 简洁 7r 1.4.4 演变 7r 1.4.5 弹 8r 1.4.6 从设计到生产 9r 1.4.7 调查系统和日志 9r 1.4.8 危机响应 9r 1.4.9 恢复 10r 1.5 小结 10r 第 2章 了解攻击者 11r 2.1 攻击者动机 12r 2.2 攻击者画像 13r 2.2.1 业余爱好者 13r 2.2.2 漏洞研究人员 13r 2.2.3 黑客活动家 14r 2.2.4 犯罪分子 14r 2.2.5 自动化和人工智能 15r 2.2.6 内部人员 15r 2.3 攻击者方法论 19r 2.3.1 威胁情报 19r 2.3.2 网络杀伤链 20r 2.3.3 TTP 20r 2.4 风险评估注意事项 21r 2.5 小结 21r 部分 设计系统r 第3章 示例分析:代理 25r 3.1 生产环境中的代理 25r 3.2 Google工具代理 27r 3.3 小结29r 第4章 设计中的权衡 30r 4.1 设计目标和要求 31r 4.1.1 特需求 31r 4.1.2 能需求 31r 4.1.3能与涌现特 32r 4.1.4 案例:Google的设计文档 33r 4.2 需衡 34r 4.3 处理紧张局势和统一目标 37r 4.3.1 案例:微服务和Google Web应用程序框架 37r 4.3.2 统一涌现特的需求 39r 4.4 初始速度和持续速度 39r 4.5 小结 41r 第5章 小特权设计 42r 5.1 概念和术语 43r 5.1.1 小特权 43r 5.1.2 零信任网络 43r 5.1.3 零接触 43r 5.2 基于风险的访问分类 43r 5.3 佳实践 44r 5.3.1 AP能小化 45r 5.3.2 Breakglass机制 47r 5.3.3 审计 47r 5.3.4 测试和小特权 49r 5.3.5 诊断被拒绝的访问 50r 5.3.6 优雅失败和Breakglass机制 51r 5.4 工作案例:配置分发 51r 5.4.1 基于OpenSSH实现的POSIX API 52r 5.4.2 软件更新API 52r 5.4.3 自定义OpenSSH ForceCommand 53r 5.4.4 自定义接收器(边车) 53r 5.4.5 自定义接收器(内置) 53r 5.4.6 权衡取舍 53r 5.5 一种用于认证和授权决策的策略框架 54r 5.5.1 使用授权控件 55r 5.5.2 投入广泛使用的授权框架 55r 5.5.3 避免潜在的陷阱 56r 5.6 控制 56r 5.6.1 MPA 56r 5.6.2 3FA 57r 5.6.3 业务依据 58r 5.6.4 临时访问 59r 5.6.5 代理 59r 5.7 权衡和冲突 59r 5.7.1 增加了复杂 60r 5.7.2 对合作商及公司文化的影响 60r 5.7.3 影响的质量数据和系统 60r 5.7.4 对用户工作效率的影响 60r 5.7.5 对开发复杂的影响 60r 5.8 小结 61r 第6章 面向易理解的设计 62r 6.1 为什么易理解很重要 62r 6.1.1 系统不变量 63r 6.1.2 分析不变量 64r 6.1.3 心智模型 65r 6.2 设计易理解的系统 65r 6.2.1 复杂与易理解 65r 6.2.2 分解复杂 66r 6.2.3 集中负责和可靠需求 67r 6.3 系统架构 67r 6.3.1 易于理解的接口规范 68r 6.3.2 易于理解的身份、认证和访问控制 69r 6.3.3 边界 74r 6.4 软件设计 78r 6.4.1 使用应用程序框架满足服务需求 78r 6.4.2 理解复杂的数据流 79r 6.4.3 考虑API的可用 81r 6.5 小结 83r 第7章 适应变化的设计 84r 7.1 变更的类型 85r 7.2 变更中的设计 85r 7.3 让发布更容易的架构决策 86r 7.3.1 让依赖项保持新并频繁重建86r 7.3.2 用自动化测试让发布更频繁86r 7.3.3 使用容器 87r 7.3.4 使用微服务 87r 7.4 不同的变更:不同的速度与不同的时间线 89r 7.4.1 短期变更:零日漏洞 90r 7.4.2 中期变更:改善态势 92r 7.4.3 变更:外部需求 94r 7.5 难点:计划调整 96r 7.6 不断扩大的范围:心脏滴血漏洞 97r 7.7 小结 98r 第8章 弹设计 99r 8.1 弹设计原则 100r 8.2 纵深防御 100r 8.2.1 特洛伊木马 100r 8.2.2 Google App Engine分析 102r 8.3 控制降级 104r 8.3.1 区分故障成本 105r 8.3.2 部署响应机制 107r 8.3.3 负责任的自动化 109r 8.4 控制爆炸半径 111r 8.4.1 角色分离 112r 8.4.2 位置分离 113r 8.4.3 时间分离 115r 8.5 故障域和冗余 115r 8.5.1 故障域 116r 8.5.2 组件类型 117r 8.5.3 控制冗余 119r 8.6 持续验证 120r 8.6.1 验证关键区域 121r 8.6.2 验证实践 122r 8.7 实践建议:着手点 124r 8.8 小结 125r 第9章 面向恢复的设计 127r 9.1 要恢复什么 128r 9.1.1 错误 128r 9.1.2 意外错误 128r 9.1.3 软件错误 128r 9.1.4 恶意行为 129r 9.2 恢的设计原则 129r 9.2.1 面向快速恢复的设计(受政策监督) 129r 9.2.2 限制对外部时间观念的依赖 132r 9.2.3 回滚所代表的和可靠间的权衡 133r 9.2.4 使用显式吊销机制 139r 9.2.5 了解到字节的预期状态 142r 9.2.6 面向测试和持续验证的设计 145r 9.3 紧急访问 146r 9.3.1 访问控制 147r 9.3.2 通信 148r 9.3.3 响应人员的148r 9.4 预期外的收益 149r 9.5 小结 149r 第 10章 缓解拒绝服务攻击 150r 10.1 攻守双方的策略 150r 10.1.1 攻方的策略 151r 10.1.2 守方的策略 152r 10.2 面向防御的设计 152r 10.2.1 具有防御能力的架构 152r 10.2.2 使服务具备防护能力 154r 10.3 缓解攻击 154r 10.3.1 监控与告警 154r 10.3.2 优雅降级 155r 10.3.3 DoS防护系统 155r 10.3.4 有策略的响应 156r 10.4 应对源于服务本身的“攻击” 157r 10.4.1 用户行为 157r 10.4.2 客户端重试行为 158r 10.5 小结 159r 第三部分 实现系统r 第 11章 案例分析:设计、实现和维护一个受信任的公共CA 163r 11.1 受信任的公共CA的背景 163r 11.2 为什么需要受信任的公共CA 164r 11.3 自建还是购买CA 165r 11.4 设计、开发和维护过程中的考虑 165r 11.4.1 选择编程语言 166r 11.4.2 复杂与简明 166r 11.4.3 保护第三方和开源组件 167r 11.4.4 测试 167r 11.4.5 CA密钥材料的弹 168r 11.4.6 数据验证 168r 11.5 小结 169r 第 12章 编写代码 170r 12.1 框架级和可靠保证措施 171r 12.1.1 使用框架的好处.172r 12.1.2 案例:用于创建RPC后端的框架 172r 12.2 常见漏洞 176r 12.2.1 SQL注入漏洞:TrustedSqlString 177r 12.2.2 XSS漏洞:SafeHtml 178r 12.3 评估和构建框架的经验 179r 12.3.1 用于常见任务的简单、、可靠的库 180r 12.3.2 部署策略 181r 12.4 简洁有助于提升代码的和可靠 182r 12.4.1 避免多层嵌套 182r 12.4.2 消除YAGNI类代码 183r 12.4.3 偿还技术债务 184r 12.4.4 重构 184r 12.5 默认和可靠 185r 12.5.1 选择合适的工具 185r 12.5.2 使用强类型 186r 12.5.3 检查代码.188r 12.6 小结 189r 第 13章 代码测试 190r 13.1 单元测试 190r 13.1.1 编写有效的单元测试 191r 13.1.2 编写单元测试的时机 191r 13.1.3 单元测试对代码的影响 192r 13.2 集成测试 193r 13.3 动态程序分析 194r 13.4 模糊测试 197r 13.4.1 模糊引擎的工作原理 197r 13.4.2 编写有效的模糊测试驱动程序 200r 13.4.3 示例fuzzer 201r 13.4.4 持续模糊测试 204r 13.5 静态程序分析 205r 13.5.1 自动代码检查工具 205r 13.5.2 如何将静态分析集成开发工作流中 209r 13.5.3 抽象解释 211r 13.5.4 形式化方法 213r 13.6 小结 213r 第 14章 部署代码 214r 14.1 概念和术语 214r 14.2 威胁建模 216r 14.3 佳实践 217r 14.3.1 强制做代码审查 217r 14.3.2 依赖自动化 218r 14.3.3 验证工件,而不仅仅是人 218r 14.3.4 将配置视为代码.219r 14.4 基于威胁建模做加固 220r 14.5 缓解策略 222r 14.5.1 制文件来源 222r 14.5.2 基于来源的部署策略 224r 14.5.3 可验证的构建 225r 14.5.4 部署阻塞点 230r 14.5.5 部署后验证 231r 14.6 实用建议 232r 14.6.1 一步步来 232r 14.6.2 提供可操作的错误消息 233r 14.6.3 确保来源信息明确 233r 14.6.4 创建明确的策略 233r 14.6.5 引入Breakglass机制 234r 14.7 重温基于威胁建模部署措施 234r 14.8 小结 234r 第 15章 调查系统 235r 15.1 从调试到调查 236r 15.1.1 案例:临时文件 236r 15.1.2 调试技巧 237r 15.1.3 当陷入困境时该怎么办 243r 15.1.4 协同调试:一种教学方法 246r 15.1.5 调查与系统调试间的差异 246r 15.2 收集恰当、有用的日志 247r 15.2.1 将日志设计为不可变的 248r 15.2.2 考虑隐私要素 249r 15.2.3 确定要保留哪些相关的日志 249r 15.2.4 日志记录成本 252r 15.3 可靠、的调试访问 253r 15.3.1 可靠 253r 15.3.2 253r 15.4 小结 254r 第四部分 维护系统r 第 16章 防灾规划 257r 16.1 “灾难”的定义 257r 16.2 动态灾难响应策略 258r 16.3 灾难风险分析 259r 16.4 建立事件响应团队 259r 16.4.1 确定团队成员和角色 260r 16.4.2 制订团队章程 261r 16.4.3 建立严重和优先级模型 262r 16.4.4 确定与IR团队合作的运营参数 262r 16.4.5 制订响应计划 263r 16.4.6 创建详细的行动手册 264r 16.4.7 确保访问和更新机制位 264r 16.5 在事件发生前预先安排系统和人员 264r 16.5.1 配置系统 265r 16.5.2 培训 265r 16.5.3 流程和程序 266r 16.6 测试系统和响应计划 266r 16.6.1 审计自动化系统 267r 16.6.2 开展非侵入式桌面演练.267r 16.6.3 在生产环境中测试响应 268r 16.6.4 红队测试 270r 16.6.5 评估响应 270r 16.7 Google的案例 271r 16.7.1 具有全球影响的测试 271r 16.7.2 DiRT演紧急访问 271r 16.7.3 行业级漏洞 271r 16.8 小结 272r 第 17章 危机管理 273r 17.1 是否存在危机 274r 17.1.1 事件分诊 274r 17.1.2 入侵与缺陷 275r 17.2 指挥事件 276r 17.2.1 第 一步:不要惊慌 276r 17.2.2 开展响应 277r 17.2.3 组建自己的事件团队 277r 17.2.4 OpSec 278r 17.2.5 牺牲好的OpSec实践换取更大的利益 280r 17.2.6 调查过程 280r 17.3 控制事件 283r 17.3.1 并行处理事件 283r 17.3.2 移交 284r 17.3.3 士气 286r 17.4 沟通 287r 17.4.1 误解 287r 17.4.2 拐弯抹角 287r 17.4.3 会议 288r 17.4.4 让合适的人了解合适的细节 289r 17.5 整合回顾 290r 17.5.1 分诊 290r 17.5.2 宣布事件 290r 17.5.3 沟通和OpSec 290r 17.5.4 开始处理事件 291r 17.5.5 移交 291r 17.5.6 交还事件调查工作 291r 17.5.7 准备沟通和补救 292r 17.5.8 结束 292r 17.6 小结 293r 第 18章 恢复和善后 294r 18.1 恢复调度 295r 18.2 恢复时间线 296r 18.3 恢复计划 297r 18.3.1 确定恢复范围 297r 18.3.2 恢复过程的考虑因素 298r 18.3.3 恢复检查清单 301r 18.4 启动恢复 302r 18.4.1 隔离资产 302r 18.4.2 系统恢复和软件升级 303r 18.4.3 数据过滤 304r 18.4.4 恢复数据 304r 18.4.5 更换凭据和密钥 305r 18.6 恢复之后 306r 18.7 示例 308r 18.7.1 被入侵的云实例 308r 18.7.2 大规模钓鱼攻击 309r 18.7.3 需要复杂恢复工作的、有针对的攻击 310r 18.8 小结 311r 第五部分 组织与文化r 第 19章 案例研究:Chrome团队 315r 19.1 背景和团队发展史 315r 19.2 是团队的职责 317r 19.3 帮助用户地浏览Web页面 318r 19.4 速度很重要 319r 19.5 设计纵深防御机制 319r 19.6 保持透明,让社区参来 320r 19.7 小结 320r 第 20章 理解角色和责任 321r 20.1 谁为和可靠负责 322r 20.1.1 专家的作用 322r 20.1.2 了解专业知识 324r 20.1.3 资格认证和学术教育 325r 20.2 将整合到组织中 325r 20.2.1 嵌入人员和团队 327r 20.2.2 案例:Google的嵌入式 327r 20.2.3 特殊的团队:蓝队和红队 329r 20.2.4 外部研究者 330r 20.3 小结 332r 第 21章 建立可靠的文化 333r 21.1 定义健康的和可靠文化 334r 21.1.1 默认的和可靠文化 334r 21.1.2 评审文化 335r 21.1.3 意识文化 336r 21.1.4 说“是”的文化 339r 21.1.5 接受必然的文化 340r 21.1.6 可持续发展文化 340r 21.2 通过佳实践改变文化 342r 21.2.1 对齐项目目标和激励参与者 342r 21.2.2 通过风险规避机制减少恐惧 343r 21.2.3 使兜底措施成为常态 344r 21.2.4 提高生产力和可用 344r 21.2.5 多沟通,保持透明 345r 21.2.6 怀抱同理心 346r 21.3 说层 347r 21.3.1 了解决策过程 347r 21.3.2 为变革立案 348r 21.3.3 选择自己的战场 349r 21.3.4 升级和问题解决 349r 21.4 小结 350r 附录 灾难风险评估矩阵 353r 作者介绍 355r 封面介绍 355 |
|