云安全实用指南 - (EPUB全文下载)

文件大小：0.23 mb。
文件格式：epub 格式。
书籍内容：

云安全实用指南
第1章　原则与概念
第2章　数据资产管理与保护
第3章　云资产管理与保护
第4章　身份与访问管理
第5章　漏洞管理
第6章　网络安全
第7章　安全事件的检测、响应与恢复
第1章　原则与概念
本书是一本实用指南，但在我们深入讨论实用细节之前，还需要从一个较高层次来介绍几个与云相关的安全原则。如果你是经验丰富的安全专家，只是刚接触云，那么可以直接从第 6 页“云共享职责模型”开始阅读。
最小权限
最小权限（least privilege）原则说起来很简单：对于承担某项工作的个人或自动化工具，应该只授予他们完成该任务所必需的访问权限，除此之外不再提供其他任何权限。最小权限原则中很容易被忽视的是自动化部分，例如，如果某个访问数据库的组件不需要写权限，那么就不应该让它使用可对数据库写权限的凭证。
如果某个项目中的应用符合最小权限原则，通常就意味着它的访问策略是默认拒绝（deny by default）。也就是说，默认用户不会被授予任何（或只授予非常小的）权限，若要获取所需权限就必须进行申请和审批。
在云环境中，部分管理员需要有云控制台的访问权限。云控制台是一个基于网页的控制台，用户可以通过这个页面创建、修改和删除某些云资产，例如虚拟机。对于云提供商来说，用户能访问云控制台就意味着用户拥有上帝特权，他可以操作该提供商管理的任何资源，不管提供商实际创建的系统在操作系统层面做了什么控制，他都有可能从云环境的任何地方读取、修改和删除数据。出于这个原因，你应该收紧用户对云控制台的访问权限和使用特权，就像在本地部署（on-premises）环境中严格控制对物理数据中心的访问一样；另外，你还需要记录这些用户都做过哪些事情。
纵深防御
本书介绍的一些控制措施如果实施得当，你就无须使用其他控制方式。纵深防御（defense in depth）是指，几乎任何单一的安全控制都会以失败告终，原因可能是攻击者一直在持续不断地攻击，也可能是安全控制的实现方式存在漏洞。在纵深防御中，你需要创建多层安全控制，它们互有重叠，这样当一层被攻破时，下一层还能挡住攻击者。
但这个原则如果把握不当，就很容易走极端，因此去了解你可能要面对哪些风险是非常重要的，我们稍后会介绍这些内容。通常来说，一旦你指着安全控制中的任何一层问自己：“如果这一层失败了会怎样？”如果答案是（系统）彻底失败，就说明防御的层级还不够。
威胁行为体、图和信任边界
评估所面临的风险有多种方式，我个人倾向于一种面向资产（asset-oriented）的方式。这种方式需要你首要明确的是哪些资产需要保护，这也是为什么本书在第2 章就开始深入介绍数据资产（data asset）的原因。
此外，你头脑中要时刻铭记谁可能会给你带来威胁，这会对你很有帮助。用网络安全术语来说，这些（带来问题的人或组织）就是潜在的“威胁行为体（threat actor）”。例如，你可能不需要考虑如何为资金充沛的国家行为体（state actor）做好防御，但需要考虑你自己经营的生意，因为罪犯可能会通过窃取你的数据而获利，或者“黑客行为体（hacktivist）”可能会攻击你的网站并使其瘫痪。在设计各种防御系统时，你需要经常在脑海中考虑以上提到的几种情况。
虽然市面上已经有大量关于威胁行为体、动机和方法的资源和讨论，[1]但本书介绍的四个主要威胁行为体可能是你最需要关心的：
· 有组织犯罪（organized crime）或独立罪犯（independent criminal），主要目的是获利。
· 黑客行为体，主要目的是通过公布窃取的数据，实施破坏行为，扰乱业务来使你信誉受损。
· 内部攻击者（inside attacker），通常目的是损害你的信誉或获利。
· 国家行为体，目的可能是窃取机密或扰乱业务。
我们从用户体验设计（UED）领域借鉴一种设计防御系统的方法：想象应用的所有适用场景，从每种场景中选取一个用户并给该用户取一个名字，然后用简笔画将这些用户都画到一张卡片上；在设计防御系统的过程中，始终保持这些卡片可见。
接下来，你需要找出应用中需要访问哪些部分，最简单的方式就是画一张图，找出其中的脆弱之处可能在哪里。市面上有很多书是专门介绍如何完成这项工作的，[2]其实你无须成为专家就可以画出一些足够有用的图来帮助你做决定。但是如果你处在高风险的环境中，那么就需要用合适的工具创建一些更正式的图，而不是像我们这里用简笔画的方式。
应用架构有很多不同的类型，为了展示方便，我将采用一个简单的三层设计（three-tier design），建议如下：
1.首先画出一个“用户”，然后加入一个“管理员”（图1-1），以此作为我们的起点。以后你可能会遇到多种类型的用户和管理员，或有其他角色的情况，这里暂不考虑。
图1-1　用户和管理员角色
2.画出用户访问的第一个组件（例如Web 服务器），然后将该组件与用户连起来，并在连线上注明用户的访问方式（图1-2）。注意，这里的组件可能是一个 serverless 函数，也可能是一个容器、虚拟机或其他组件。由于这个组件可以被任何人访问，因此从这里开始是比较合适的。另外，我们不希望其他组件过于信任这个组件。
图1-2　第一个组件
3.继续画出第一个组件需要访问的其他组件，再画出它们之间的连线（图1-3）。如果遇到实际存储数据的系统，就在它旁边画一个标记（这里我使用了圆柱体），并简要注明它具体存储了什么数据。重复以上过程，直到应用所需的全部组件都已画在图中。
图1-3　其他组件
4.现在画出管理员（以及你定义的其他角色）如何访问应用。注意管理员可能有多种访问应用的方式，例如，可通过云提供商提供的门户或应用编程接口（API）访问，还可通过操作系统权限访问，或者通过与用户访问应用类似的方式访问（图1-4）。
图1-4　管理员权限
5.用虚线画出信任边界（图1-5）。信任边界（trust boundary）表示的是，边界内的任意组件至少是在一定程度上清楚彼此的动机的，但对于边界外的任何组件必 ............

以上为书籍内容预览，如需阅读全文内容请下载EPUB源文件，祝您阅读愉快。