一、责任共担模型和基础架构安全
云提供商始终负责底层网络和基础架构，并且客户始终负责其访问政策和数据。
Google 基础架构安全层详细参考：https://mp.weixin.qq.com/s/RJn5O5Gh-PJyt-1K2ivM8A (从位于底层的硬件基础架构安全性开始，到位于顶层的运营安全性。)
二、安全的底层基础架构
1. 安全启动栈和机器身份标识
服务器利用以下技术确保启动正确的软件栈，启动链的硬件信任根如下：
• The Titan hardware chip
• A lockable firmware chip
• A microcontroller running our own security code
通过自动化任务维护服务安全基线：
• 确保服务器运行其软件栈的最新版本（包括安全补丁）。
• 检测和诊断硬件和软件问题。
• 使用启动时验证和隐式证明确保机器和外围设备的完整性。
• 确保只有运行指定软件和固件的机器才能访问使其可在生产网络中进行通信的凭据。
• 当不再需要机器时，在服务中移除或重新分配机器。
三、安全的服务部署
集群编排服务（Borg）控制直接在基础架构上运行的服务。
“零信任安全模型”：基础架构假定基础架构上运行的服务之间不存在任何信任。无论是位于网络内部还是外部，默认情况下不信任任何设备或用户。
BeyondCorp 认为“用户信任应该取决于设备的上下文感知状态等特征，而不是连接到公司网络的权限”；BeyondProd 认为“服务信任应该取决于代码出处和服务身份等特征，而不是生产网络中的位置（例如 IP 地址或主机名身份）”。
下图对比了传统基础架构安全性方面与云原生架构中的安全性方面。更多细节参考：https://cloud.google.com/docs/security/beyondprod?hl=zh-cn
在开发云原生架构时的安全原则：
• 在边缘保护网络，以便将工作负载与来自互联网的网络攻击和未经授权的流量隔离开来。虽然基于防火墙的方法不是云原生架构的新概念，但仍然是安全性的最佳做法。在云原生世界中，边界方法用于保护尽可能多的基础架构，使其避开来自互联网的未经授权的流量和潜在的攻击，例如基于卷的拒绝服务攻击。
• 服务之间没有固有的相互信任，只有已知的、受信任的、明确授权的调用者才能使用服务。这样可以阻止攻击者使用不可信代码访问服务。如果某个服务受到破解，这一原则可阻止攻击者执行扩大其攻击范围的操作。这种“互不信任”的机制有助于限制危害的范围。
• 运行具有已知出处的代码的受信任机器，以便服务身份只能使用经过授权的代码和配置，并且只能在经过验证的授权环境中运行。
• 用于跨服务强制执行一致政策的关卡。例如，一个用于验证访问用户数据的请求的关卡，以确保服务的访问来自于获得授权的最终用户发出且经过验证的请求，并且管理员的访问需要提供正当的理由。
• 简单、自动化、标准化的更改发布，以便相关人员轻松审核基础架构更改对安全性的影响，并且可以在几乎不影响生产环境的情况下发布安全补丁程序。
• 在共享操作系统的工作负载之间进行隔离，使得某项服务在被破解的情况下也不会影响同一主机上运行的其他工作负载的安全性。这样可以限制潜在的破解“影响范围”。
基础架构设计为多租户。
1. 服务身份标识、完整性与隔离
为了实现服务间通信，应用使用加密的身份验证和授权。身份验证和授权以管理员和服务可以理解的抽象级别和粒度提供强大的访问权限控制。
服务不依赖内部网络分段或防火墙作为主要安全机制。
在基础架构上运行的每个服务都具有关联的服务帐号身份标识。安全政策可确保客户端与预期服务器通信，并且服务器限制特定客户端可以访问的方法和数据。
使用各种隔离和沙盒技术来保护服务免受同一机器上运行的其他服务的影响。这些技术包括 Linux 用户分离、基于语言（如 Sandboxed API）和基于内核的沙盒、容器应用内核（如 gVisor）和硬件虚拟化。为风险较高的工作负载使用更多的隔离层。
为了提高安全性，敏感服务（例如集群编排服务和某些密钥管理服务）只在专用机器上运行。
2. 服务间访问管理
服务的所有者可以利用基础架构提供的访问管理功能来精确指定其服务可以与其他哪些服务进行通信。
可以将服务配置为根据身份标识允许或拒绝访问。所有这些身份标识（机器、服务和员工）都位于基础架构维护的全局命名空间中。
为管理这些身份标识，基础架构提供了一个工作流系统，其中包括批准链、日志记录和通知。
基础架构还为服务提供用户、群组和成员资格管理的规范化服务，可以在必要时实现精细的自定义访问权限控制。
3. 服务间通信的加密
基础架构可确保网络上的 RPC 数据的机密性和完整性。
所有 Google Cloud 虚拟网络流量均经过加密。基础架构服务之间的所有通信都经过身份验证，大多数服务间通信均已加密，这增加了一层额外的安全保护，即使网络被窃听或网络设备遭到破解，也能保护通信。
基础架构可自动、高效地（借助硬件分流）为数据中心之间通过网络传输的基础架构 RPC 流量提供端到端加密。
4. Google Workspace 中的最终用户数据访问管理
基础架构提供了一项中央用户身份识别服务，该服务可以颁发上述最终用户权限票证。
身份识别服务验证最终用户登录，然后向用户的设备颁发用户凭据，例如 Cookie 或 OAuth 令牌。从该设备发送到的基础架构的每个后续请求都必须提供该最终用户凭据。
当某个服务收到最终用户凭据时，会将该凭据传递给身份识别服务进行验证。如果最终用户凭据通过验证，身份识别服务会返回一个短期有效的最终用户权限票证，该票证可用于与该用户的请求相关的 RPC。
基础架构可提供服务身份、自动身份互验、服务间通信加密，并可执行服务所有者定义的访问政策。每项服务都有一个由服务所有者创建的服务配置。对于加密的服务间通信，自动双向身份验证使用调用方和被调用方身份标识。只有在访问规则配置允许的情况下才能进行通信。
四、安全的数据使用/存储
Google 安全策略的核心是身份验证、完整性和加密，对于静态数据和传输中的数据均适用。
Google 采用多种安全措施来确保传输过程中数据的真实性、完整性和私密性。
• 身份验证：会验证数据源、人员或过程以及目标位置。
• 完整性：确保您发送的数据会原封不动地到达目的地。
• 加密：使数据在传输过程中无法识别，以保持其私密性。
加密可用于保护三种状态的数据：
• 静态加密通过加密存储的数据，防止数据受到系统入侵或数据渗漏的危害。
• 传输加密：当数据在网站与云服务商之间或在两个服务之间移动时，如果通信遭到拦截，则可保护数据。
• 使用中加密：通过加密处理中的数据（例如机密计算），保护内存中的数据免遭入侵或数据渗漏。
1. 静态加密
Google 的基础架构提供各种存储服务和分布式文件系统（例如 Spanner 和 Colossus）以及一个中央密钥管理服务。
Google 的应用使用存储基础架构访问物理存储。默认情况下，存储基础架构会在用户数据写入物理存储空间之前加密所有用户数据。使用高级加密标准 (AES) 算法对静态存储的数据进行加密。
基础架构在应用层或存储基础架构层执行加密。加密可使基础架构将其自身与底层存储上的潜在威胁（例如恶意磁盘固件）隔离开来。
Cloud Storage 加密机制的具体运作方式：
• 会将数据分割为多个子文件块进行存储；每个块的大小可以达到数个 GB。每个块使用单独的加密密钥在存储层级进行加密，两个块不会共用同一个加密密钥。
• 如果数据块发生更新，系统会使用新密钥对其进行加密，而不是重复使用现有密钥。
• 每个数据块都有一个唯一标识符。访问控制列表 (ACL) 确保每个块只能由已获授权的角色使用 Google 服务进行解密，并且授权角色仅会在解密那一刻获得访问权限。
• 每个块都分布在 Google 的存储系统中，并以加密形式进行复制，以便于备份和灾难恢复。
除了存储系统级加密外，大多数情况下数据还会在存储设备级加密。
Google 的备份系统可确保数据在整个备份过程中保持加密状态。备份系统还使用专属的 DEK 对每个备份文件进行独立加密。
用于对块中的数据进行加密的密钥称为 DEK（数据加密密钥）。由于 Google 的密钥很多，且需要提供低延迟、高可用性的服务，因此这些密钥都存储在用其加密的数据附近。DEK 本身又使用 KEK（密钥加密密钥）进行加密（也称为“封装”）。每项 Google Cloud 服务都有一个或多个 KEK。这些 KEK 集中存储在 Google 的 KMS 中，这是一个专为存储密钥而构建的存储区。只需少量 KEK（少于 DEK 的数量）并使用集中式密钥管理服务，就能轻松管理整个 Google 中的数据存储和加密，同时还可以集中跟踪和控制对数据的访问。系统会将每位 Google Cloud 客户的所有非共享资源拆分为多个数据块，并使用客户专属的密钥进行加密。即使是同一位客户所拥有的同一部分数据，保护其各块的 DEK 也各不相同。 更多细节：https://cloud.google.com/docs/security/encryption/default-encryption?hl=zh-cn#key_management
Google 的 KMS 受到名为“KMS 主密钥”的根密钥保护，该密钥会封装 KMS 中的所有 KEK。它本身存储在另一个名为“Root KMS”的 KMS 中。Root KMS 也有自己的根密钥，称为“根 KMS 主密钥”。
• 对数据进行分块并使用 DEK 进行加密。
• DEK 使用 KEK 进行加密。
• KEK 存储在 KMS 中。
• KMS 在全球数据中心的多台机器上运行。
• KMS 密钥使用 KMS 主密钥进行封装，而 KMS 主密钥存储在 Root KMS 中。
• Root KMS 中的密钥数量远少于 KMS 中的数量，并且仅在每个数据中心内的专用机器上运行。
• Root KMS 密钥使用根 KMS 主密钥进行封装，后者存储在根 KMS 主密钥分发服务器中。
• 根 KMS 主密钥分发服务器是一个点对点基础架构，在全球各地专用机器的 RAM 中并发运行；每个分发服务器实例都会从其他正在运行的实例获取其密钥材料。
• 如果所有分发服务器实例都关闭（全球性关闭），有存储在（不同的）安全硬件中的主密钥，这些安全硬件存放在有限的几个 Google 地点的（实体）保险箱中。
除了基础架构进行的加密以外，Google Cloud 和 Google Workspace 还提供密钥管理服务。
高可用性、低延迟、密钥全球访问在每个层级都至关重要；只有具备这些特性，才能在整个 Google 范围内使用 KMS。
2.数据删除
客户发出删除请求时，客户数据删除操作就会开始。通常，删除请求会指向特定资源、Google Cloud 项目或客户的 Google 帐号。删除请求的处理方式可能会有所不同，具体取决于客户请求的范围。
数据删除流程通常是从将具体数据标记为“已安排删除”开始，而不是真正的删除数据。借助此方法，可以恢复无意间删除的数据，例如由客户发起的删除、bug 导致的删除或内部流程错误导致的删除。数据标记为“已安排删除”后，系统会根据特定于服务的政策来删除数据。
当最终用户删除其帐号时，基础架构会通知处理最终用户数据的服务该帐号已被删除。然后，这些服务便会安排删除与被删除的最终用户帐号相关联的数据。此功能使最终用户能够控制自己的数据。
删除流程细节参考：https://cloud.google.com/docs/security/deletion?hl=zh-cn#deletion_timeline
3.保护使用中的数据/传输加密
机密计算通过在加密隔离中执行计算来保护正在使用的数据，并在多租户云环境中维护工作负载的机密性。
这种类型的加密隔离环境有助于防止在使用应用或数据时对应用和数据进行未经授权的访问或修改。
可信执行环境还可增强管理敏感数据和受监管数据的组织的安全保障。
Google 使用各种加密方法（包括默认方法和用户可配置的方法）加密传输中的数据。使用的加密类型取决于 OSI 层、服务类型和基础架构的物理组件。
实现细节参考：https://cloud.google.com/docs/security/encryption-in-transit?hl=zh-cn#how_google_helps_the_internet_encrypt_data_in_transit
下图展示了 Google Cloud 为第 3、4 和 7 层配置的可选和默认保护措施，以及第 3 层和第 4 层的默认保护措施和各种选项。
4.Cloud KMS
通过 Cloud KMS，Google 可专注于提供可扩缩、可靠且高性能的解决方案，在使用方便的平台上提供最广泛的可控制选项。
Cloud KMS 的设计有五大重点：
• 客户控制。借助 Cloud KMS，可以管理软件和硬件加密密钥，也可以提供自己的密钥。
• 访问权限控制和监控。借助 Cloud KMS，可以分别管理各个密钥的权限，并监控这些密钥的使用方式。
• 区域性。Cloud KMS 提供开箱即用的区域化功能。该服务配置为仅在所选的 Google Cloud 区域中创建、存储和处理软件密钥。
• 耐用性。Cloud KMS 符合 Google Cloud 的最高耐用性标准。为了帮助防止数据损坏并验证数据能否成功解密，Cloud KMS 会定期扫描并备份所有密钥材料和元数据。
• 安全性。Cloud KMS 提供强大的保护功能，以防密钥遭到未经授权的访问，并且已与 Identity and Access Management (IAM) 和 Cloud Audit Logs 控件完全集成。
Cloud KMS白皮书和实现细节参考：https://cloud.google.com/docs/security/key-management-deep-dive?hl=zh-cn
4. 对上传到 Cloud Storage 的文档进行自动恶意软件扫描
流水线中的步骤：
• 将文件上传到 Cloud Storage。
• 上传事件会自动触发恶意软件扫描服务。
• 恶意软件扫描工具服务会扫描上传的文档是否包含恶意软件。
• 如果文档受感染，则服务会将其移到隔离的存储分区；否则，该文档会被移到另一个存储分区以存放未受感染的已扫描文档。
5.数据丢失导致的泄漏
享受公有云基础架构带来的灵活性、成本节约和功能时还需要提高警惕，并采用新方法保护数据免遭外泄。
细节参考：https://cloud.google.com/docs/security/data-loss-prevention/preventing-data-exfiltration?hl=zh-cn
• 通过数据分区最小化数据外泄事件的“爆炸半径”。
• 在系统管理员工作流程中创建冗余和批准以加强问责制。
• 使用精细配置的权限并仅将敏感数据的访问权限授予有相应工作职能需要的员工。
• 使用日志记录提高组织中数据访问和移动的透明度。
• 使用联网规则、identity and access management (IAM) 以及堡垒主机限制和监控组织中的机器的入站和出站。
• 创建数据流的正常基准（例如可访问或传输的数据量）和用于比较异常行为的访问的地理位置。
五、安全的互联网通信
服务间通信的安全性不依赖于网络安全。但是，将基础架构从互联网隔离到专用 IP 地址空间。只将部分机器直接暴露给外部互联网流量，从而可以实现额外的保护，例如防御拒绝服务 (DoS) 攻击。
1. Google Front End 服务
当某个服务需要在互联网上可用时，它可向名为 Google Front End (GFE) 的基础架构服务注册。
2. DoS防护
当光纤骨干网向其中一个数据中心传送外部连接时，该连接会经过多层硬件和软件负载均衡器。这些负载均衡器会将有关入站流量的信息报告给在基础架构上运行的中央 DoS 服务。当中央 DoS 服务检测到 DoS 攻击时，该服务可以配置负载均衡器，以降低或限制与攻击相关的流量。
3. 用户身份验证
在 DoS 防护之后，安全通信的下一层防御来自中央身份识别服务。
用户登录时，他们可以使用第二重身份验证，例如动态密码或防钓鱼安全密钥（例如 Titan 安全密钥）。
相关技术细节参考：
https://cloud.google.com/docs/authentication?hl=zh-cn
https://cloud.google.com/docs/authentication/use-cases?hl=zh-cn
六、安全运营
1.安全的软件开发
源代码控制保护机制和双方审核流程
安全库和安全框架
自动化安全扫描工具
人工安全审核
漏洞奖励计划
安全问题研究(P0)
2.源代码保护
源代码存储在具有内置源完整性和治理的代码库中，可以在其中审核服务的当前版本和过去版本。
基础架构要求服务的二进制文件基于经过审核、登记和测试的特定源代码构建。
Binary Authorization for Borg (BAB) 是部署服务时进行的内部强制执行检查。供应链完整性可确保处理数据的服务的底层代码和二进制文件得到验证，并且通过证明测试。
• 确保 Google 上部署的生产软件和配置经过审核和授权，尤其是在代码可以访问用户数据时。
• 确保代码和配置部署满足特定的最低标准。
• 防止内部人员或攻击者恶意修改源代码，并实现从服务回溯到其源代码的取证跟踪。
实现细节参看：https://cloud.google.com/docs/security/binary-authorization-for-borg?hl=zh-cn
如果怀疑任何凭据已遭到泄露，必须立即采取措施来限制其 Google Cloud 帐号的影响。确保用户的SOC 拥有快速响应可疑凭据泄露事件所需的策略方案、工具和访问权限。
将您的凭据与源代码分开管理和存储。不小心将凭据和源代码都推送到 GitHub 等源代码管理站点这种情况极其常见，这会使您的凭据容易遭到攻击。使用 Secret Manager 和 Hashicorp Vault 等密文管理解决方案来存储密文，定期进行轮替，并应用最小权限。
3.确保员工设备及凭据的安全
实施保护措施，使员工的设备和凭据免遭破解。强制使用与 U2F 兼容的安全密钥来取代动态密码双重身份验证。
监控员工用于运行基础架构的客户端设备。
使用零信任安全性来保护员工对资源的访问。
4. 降低来自内部人员的风险
限制并主动监控拥有基础架构管理员权限的员工的活动。
Google 员工对最终用户信息的访问情况可通过底层基础架构钩子进行记录。安全团队会监控访问模式并调查异常事件。
5.威胁监控
Google 的威胁分析小组会监控威胁发起者及其策略和技术的演变。
6.入侵检测
使用复杂的数据处理流水线来集成各个设备上基于主机的信号、来自基础架构中各个监控点的基于网络的信号，以及来自基础架构服务的信号。构建于这些流水线之上的规则和机器智能会向运营安全工程师发出潜在突发事件警告。
7.应急响应
每个数据突发事件都具有特异性，数据突发事件响应流程的目标是保护客户的数据，尽快恢复正常服务，并满足监管和合同合规要求。 Google 的突发事件响应计划的流程如下：
七、支持合规性要求
Google Cloud 会定期接受安全性、隐私权和合规控制措施方面的独立验证，并接收认证、证明和审核报告以证明合规。
