3.2 系统化建设阶段
经过第一阶段救火式的快速治理后，企业中存在的大部分隐患基本被解除，所以第二阶段可以系统地完善企业安全架构，将1.3节中所提到的“将安全融于体系，建立自动化监控与响应系统”的理念落地。这一阶段的工作可以归结为如下3个层面。
3.2.1 依据ISMS建立安全管理体系
俗话说“三分技术，七分管理”。近年来，伴随着ISMS国际标准的修订，ISMS迅速被全球接受和认可，成为世界各国、各种类型、各种规模的组织解决信息安全问题的一个有效方法。ISMS是建立和维持信息安全管理体系的标准，该标准要求组织通过确定信息安全管理体系范围、制定信息安全方针、明确管理职责、以风险评估为基础选择控制目标与控制方式等活动建立信息安全管理体系。ISMS具体是由ISO27000～ISO27013系列标准组成的，其中尤以ISO27001最为业界所熟知。ISO27001主要规定了信息安全管理体系的要求，主要是对一些概念的介绍和概述，一般用于认证。ISO27002为信息安全控制提供实践指导，是对应ISO27001的详细实践，该标准涉及14个领域，包含113个控制措施，最新版本为2013版。
ISMS具体依据PDCA循环原则建立。P即Plan（计划），制定与风险管理和信息安全改进相关的政策、ISMS目标、流程和程序，以提供符合组织全球政策和目标的结果。D即Do（实施），实施和利用ISMS政策对流程和程序进行控制。C即Check（检查），在检查过程中对流程进行相应的评估，并在适当的情况下根据政策、目标和实践经验衡量流程的绩效，之后将结果报告给管理层进行审核。A即Act（行动），根据ISMS内部审核和管理评审的结果或其他相关信息，采取纠正和预防措施，不断改进上述系统。PDCA循环原则的示意图如下图所示。
ISMS提供了一个大而全的指导性要求框架，其可以为互联网企业安全负责人带来的帮助有：①提供一个全面的安全视图，避免安全覆盖面不足带来的死角；②可以给CEO等高管一个可交代的信息安全实施依据，方便安全策略的推行；③获取ISO27001认证后，可以提高公司的知名度与信任度，使生意伙伴和客户对企业充满信心。
不能为企业安全负责人带来的帮助有：①只提供了管理要求，没有提供技术措施，需要负责人自行补充对应的技术方案；②没有具体的组织架构、流程制度和规范细则方面的说明，需要安全负责人按照公司组织架构自行制定。
ISMS包含的14个控制领域如下图所示。
很多互联网企业初期都缺乏安全管理体系，ISMS刚好给企业安全负责人提供了一个检查表格，对照着这个表格完成相应的模块并打钩，等勾选得差不多了，安全管理体系自然也就建好了。
3.2.2 基于BSIMM构建安全工程的能力
互联网企业业务的基石建立在软件上，而软件开发是一个系统工程，如何构建软件安全工程是每个互联网企业都必须考虑的课题。20世纪90年代中后期，随着互联网的发展，软件系统的互联与开放性逐渐增强，由软件漏洞导致的安全事件以及造成的资产和服务功能的损失急剧增加，于是各种软件安全开发理论、实践和标准相继推出，包括Cigital BSI、Microsoft SDL、ISO/IEC 27034、Cisco NIST 800-64、CLASP、SQUARE等。同时也形成了多个侧重于评估组织安全开发能力和保障能力的理论和标准，比如Cigital的软件安全构建成熟度模型BSIMM（参见参考资料[15]、OWASP的软件保证成熟度模型OpenSAMM（参见参考资料[16]）、ISSEA的系统安全工程能力成熟度模型SSE-CMM（参见参考资料[17]）等。
很多安全负责人不知道如何系统实现DevSecOps，这里推荐使用BSIMM工程体系。相比OpenSAMM和SSE-CMM，BSIMM社区更加活跃，影响力也比较大，基本每年发布一版BSIMM，截至本书截稿时已发展到BSIMM9，该版本根据120家企业（有Cisco、NVIDIA、Paypal、Qualcomm、Synopsys等知名公司）的实践数据构建，是对现实世界中软件安全计划进行多年研究的结果。有167家公司通过BSIMM标准来实施自身安全开发建设。BSIMM是衡量软件是否安全的标尺，通过BSIMM可以很方便地将“Building Security In”即“安全融于体系”的理念落地。BSIMM具体由如下3大部分组成。
·软件安全框架（SSF）：支撑BSIMM的基础结构由划分为4个领域的12项实践模块组成。
·软件安全小组（SSG）：负责实施和推动软件安全工作的内部工作小组。
·软件安全计划（SSI）：一项涵盖整个组织机构的项目，用于以协调一致的方式来灌输、评估、管理并演进软件安全活动。
软件安全框架4个领域的12项实践模块如下图所示。
下面对上图所示的软件安全框架的4个领域做具体说明。
·治理：用于协助组织、管理和评估软件安全计划的实践。人员培养也属于治理领域的核心实践。
·情报：用于在企业中汇集企业知识以开展软件安全活动的实践。前瞻性的安全指导和威胁建模都属于该领域。
· SSDL触点：分析和保障与特定软件开发工件（artifact）及流程相关的实践。
·部署：与传统的网络安全及软件维护组织机构打交道的实践。软件配置、维护和其他环境问题对软件安全有直接影响。
BSIMM软件安全框架的每项实践模块又可以被分为3级，由软件安全小组和外围小组（由对软件安全感兴趣且积极参与的开发人员、架构师、软件管理人员、测试人员以及类似角色的人员所组成的小组）来具体实施。总的来说，BSIMM之于软件安全和ISO27001之于信息安全管理系统所起的作用类似，BSIMM主要由各种要求组成，用来指导企业安全实践。通过对12大类的116项具体实践活动打分，可以很好地评估企业软件安全成熟度。由于BSIMM每类实践活动的表格中也有其他公司的平均分值，因此从打分后形成的雷达图中可以看出企业自身与业界公司在软件安全工程能力方面的差距。由于雷达图对于特定垂直行业的企业群很有用，因此BSIMM的数据有很多都来自非常有代表性的垂直行业：金融服务行业（50）、独立软件供应商（42）、医疗保健行业（19）、云计算行业（17）、物联网行业（16）、保险行业（10）和零售行业（10），其中括号中的数字表示有多少家企业参与了BSIMM并为其提供了数据来源。BSIMM9在其说明中对116项实践活动提供了详细描述，并阐述了如何保障BSIMM有效落地。其中有不少好的实践，比如“创建安全性门户网站”“聘请外部渗透测试者来寻找问题”。BSIMM9中与安全性功能和设计相关的7项实践活动如下图所示。
BSIMM和ISO27001一样，都是只提供了一个大而全的普适性框架，而具体实施则需要安全负责人根据企业实际情况、结合具体技术来进行，并将其引入DevSecOps中。互联网公司用到的典型的安全技术图谱如下图所示。
越早关注软件在安全方面的问题，企业付出的成本越低，反之成本越高。IBM的研究人员曾公开过统计数据，在产品发布以后修复安全问题的成本是在设计阶段修复的4～5倍，而在运维阶段修复安全问题的成本将是在设计阶段修复的100倍甚至更多。很多公司在系统建设后期往往需要伤筋动骨才能解决安全隐患。安全工程能力建设（DevSecOps）需要研发、运维、安全方面的团队相互配合才能落地，所以一定要得到公司高层的支持才行，如BSIMM文档中所提到的“最好是CEO或CTO能鼎力支持”，然后建立包含研发人员、运维人员、安全人员的软件安全小组。为了确保成功交付DevSecOps，下面给出一些建议。
·安全功能与现有CI\CD体系对接
问题：业务上线时间紧、压力大，安全漏洞测试占用时间过多而影响业务上线进度。
为了避免安全工作（例如：测试与评估、安全策略的部署等）成为开发瓶颈，安全测试技术应尽量和现有系统相结合。比如，在IDE上直接集成SpotBugs插件，开发人员在编译时就能被提示要修改漏洞代码；在管理第三方组件漏洞时将BlackDuck与Maven仓库相结合，业务人员不需要介入就可以解决Java库的安全问题；在提交代码到GitLab时，加入Gitrob自动扫描密钥、密码等敏感信息泄露问题；将Facebook Infer集成在CI平台（如Jenkins）上，形成扫描集群以自动检测代码漏洞，并编写Python脚本将漏洞信息发到JIRA上提醒研发人员修复，跟踪漏洞修复进度；使用IAST技术，如Seeker或类似PHP Taint的解决方案，可以自动对软件进行漏洞测试。
·成立专门的安全测试专家小组
问题：安全漏洞方面的误报太多，开发人员最初可能还会不厌其烦地进行问题排查和解决，但久而久之便会对漏洞结果产生质疑，最终认为都是误报，不再配合修复漏洞。
任何自动化安全测试系统在刚上线时都可能存在误报问题，针对这类问题可以设计误报反馈功能，成立专职安全专家小组提供安全技术支持，并使其参与到不断优化检测规则的工作中来，经过几轮迭代之后基本都可以解决误报问题。另外，安全专家可以组织各种安全培训并建立安全知识库，使得开发人员对各种漏洞有更清晰的认识并加深对安全工作的理解，还可以按照BSIMM9中所提到的那样建立安全的外围小组，共同推动DevSecOps建设。
·建立对应的流程制度
问题：公司对员工工作无量化指标，部分研发团队成员的责任心不够，对于漏洞修复持无所谓态度，从而留下大量安全隐患。
建立漏洞修复相关的流程制度，将代码质量与KPI挂钩，对因违反流程制度而造成安全隐患的员工按出现的漏洞等级进行处罚。结合质量保障（QA）团队定期发送项目质量报告，最终将安全漏洞数据汇总到SonarQube代码质量管理平台。将漏洞修复放入KPI指标，以促进开发人员修复安全漏洞的积极性。
3.2.3 参考Google云平台设计安全技术体系
Google被业内公认为安全技术方面的领先企业，且其安全理念是“以技术驱动安全”，所以这里以Google为研究蓝本来讲解安全技术体系建设。Google拥有超过850名安全专业人士，他们分布于安全监控、安全设计和安全研究团队，发布了超过300篇与安全与隐私保护相关的论文（详见参考资料[18]），同时开发了大量改进软件安全的工具（详见参考资料[19]），创新性地提出了BeyondCorp零信任远程安全访问模型（详见参考资料[20]）。由Google Project Zero团队提交的安全漏洞数量常年高居于各漏洞公布平台榜首。
Google云平台的基础安全设计采用了从硬件基础到服务、用户身份、存储、通信和运营的分层纵深防御架构，每层都有严格的访问和权限控制，覆盖了从安全物理数据中心到硬件可信、安全启动、安全内部服务通信、数据安全、服务的互联网访问保护等方面。Google建立了高效和持续进化的安全方法论，通过安全运营中的人员参与和技术手段不断增强各个安全层。Google云平台基础安全设计的层次结构如下图所示。
下面对上图所示的重点层次结构做具体说明。
·硬件基础安全
① 物理场所的安全性：数据中心仅限少数专业员工访问，采用多种物理安全层面的措施（包括生物识别、金属检测、摄像头、车辆路障和基于激光的入侵检测系统等技术）来确保安全。
② 硬件的设计和来源：每个数据中心都有数千台服务器与本地网络相连，服务器主板和网络设备均由Google专门设计，Google会对合作的组件供应商进行审核并谨慎选择组件，同时还会与供应商一起对组件提供的安全属性进行审核和验证。芯片也由Google专门设计，包括目前部署到服务器和外围设备上的硬件安全芯片，保证在硬件级别上安全地对设备进行识别和身份验证。
③ 安全的启动栈和机器身份标识：利用各种技术来确保服务器进行可信启动，比如对BIOS（基本输入输出系统）、引导加载程序、内核和基本操作系统映像等底层组件使用加密签名，在每次启动或更新期间对这些签名进行验证。每台服务器都有唯一的身份标识与硬件信任根以及启动机器所用的软件相关联。此外，Google还开发了自动化系统来确保服务器运行最新版本的软件（包括安全补丁程序），以便检测和诊断硬件和软件问题，并在必要时将机器从云服务中移除。
·服务部署安全
① 服务身份标识、完整性和隔离：所有服务都通过Borg集群进行编排服务控制。运行的每项服务都具有关联的服务身份标识，且具有加密凭据，以便在向其他服务发送或接收远程过程调用（RPC）时证明自己的身份。客户端利用这些身份标识来确保其与正确的目标服务器通信，而服务器则利用这些身份标识将方法与数据的访问权限限定给特定的客户端。Google将源代码存储在中央代码库中，代码当前版本及过去版本的服务均可被审核。此外，基础架构可配置为要求服务的二进制文件由经过具体审核、登记和测试的源代码构建而成。此类代码审核需要开发者以外的至少一位工程师进行检查和批准，而对任何系统执行代码修改都必须得到该系统所有者的批准。这些要求可以防止内部人员或攻击者恶意修改源代码，还可以实现从服务回溯到其源代码的取证跟踪。Google采取各种隔离和沙盒技术来保护服务免受同一台机器上运行的其他服务的影响，这些技术包括普通的Linux用户分离、基于语言和内核的沙盒以及硬件虚拟化。风险较高的工作负载（例如，当基于用户提供的数据运行复杂的文件格式转换器时，或者在Google App Engine或Google Compute Engine等产品上运行用户提供的代码时）需要使用更多的隔离层。作为额外的安全防线，极其敏感的服务（例如集群编排服务和部分密钥管理服务）只会运行在专用机器上。
② 服务间访问管理：Google的内部服务运行在不需要虚拟机（VM）的容器中，除了能够提高性能，还方便管理和审计。通过使用Kubernetes，可以使以前需要几天才能完成的日志审计工作在几分钟内完成。服务的所有者可以利用基础架构提供的访问管理功能来精确指定其服务可以与其他哪些服务进行通信。所有身份标识（机器、服务和员工）都位于基础架构维护的全局命名空间中。Google针对这些内部身份标识提供了丰富的身份管理工作流程体系，包括审批链、日志记录和通知。例如，可以通过双方控制体系（其中，一名工程师可以提议对某个组进行更改，但这种提议必须得到另外一名工程师兼该组管理员的批准）将这些身份标识分配到访问控制组。这一体系可以让安全访问管理流程扩展到在基础架构上运行的数千项服务上。除了API层面的自动访问控制机制，基础架构还允许服务从中央ACL和存放访问控制组信息的数据库中读取数据，以便在必要时执行精细的定制化访问控制。
③ 服务间通信的加密：通过在RPC通信框架中引入加密处理实现了应用层隔离，这样一来，即使网络被窃听或网络设备被破解，经加密的服务间通信也可以保证安全。服务可以为每个RPC配置所需级别的加密保护。对于私有广域网链路，基础架构会自动加密流经广域网数据中心的所有基础架构RPC流量，而无须对服务进行任何具体配置。对数据中心内部所有基础架构的RPC流量进行加密，则需要通过部署硬件加密加速器实现默认加密。
④ 最终用户数据访问管理：基础架构提供了一项中央用户身份识别服务，该服务可以签发“最终用户权限工单”。中央用户身份识别服务会对最终用户的登录信息进行验证，然后向该用户的客户端设备签发用户凭据，例如Cookie或OAuth令牌。从该客户端设备向Google发出的任何后续请求都需要提交此用户凭据。
·数据存储安全
① 静态加密：Google的基础架构提供各种存储服务（例如Bigtable和Spanner）以及中央密钥管理服务。使用中央密钥管理服务中的密钥对数据进行加密，然后再将数据写入物理存储。此密钥管理服务支持自动密钥轮替，提供大量审核日志，并与前面提到的最终用户权限工单集成，从而将密钥与特定的最终用户进行关联。在应用层执行加密可以使基础架构将其自身与底层存储上的潜在威胁（例如恶意磁盘固件）隔离开来。Google在硬盘和SSD中启用了硬件加密支持，并会在每个硬盘的整个生命周期内跟踪这些硬盘的使用情况。对于退役的加密存储设备先通过多步骤流程（包括两次独立验证）清空其内容，然后才会将其撤离管控范围。对于未经过此类擦除程序处理的设备，现场会进行物理销毁（例如粉碎）。
② 数据删除：Google的数据删除流程通常是从将具体数据标记为“已安排删除”（scheduled for deletion）开始，而不是真的彻底删除。这样便可以恢复无意间删除的数据（无论是由客户发起的删除操作，还是因内部漏洞或流程错误而造成的删除）。在将数据标记为“已安排删除”后，Google会根据服务专用政策来删除数据。当最终用户删除其整个账号时，基础架构会通知处理最终用户数据的服务该账号已经被删除。然后，这些服务便会安排删除与被删除的最终账号相关联的数据。此功能可使服务开发者轻松实现最终用户控制。
·互联网通信安全
① Google前端服务：当一项服务希望其在互联网上可用时，便可在名为Google前端（Google Front End，GFE）的基础架构服务上进行注册。通过使用正确的证书及最佳做法（例如支持完全正向加密），GFE可确保终止全部TLS（安全传输层协议）连接。此外，GFE会应用保护措施来防御拒绝服务（DoS）攻击。然后，GFE会利用前面讨论的RPC安全协议转发对该服务的请求。GFE作为智能反向代理前端可以通过公开的IP地址托管公开的DNS名称来防御DoS攻击，以及终止TLS连接。请注意，GFE与其他任何服务一样都是在基础架构上运行的，因此能够对入站请求量进行调节，以防止造成DoS攻击。
② 防御拒绝服务（DoS）攻击：规模庞大的Google基础架构可以轻而易举地抵御许多DoS攻击。骨干网向其中一个数据中心提供外部连接之后，该连接会经过多层硬件和软件负载均衡器。这些负载均衡器会将有关入站流量的信息报告给在基础架构上运行的中央DoS服务。当中央DoS服务检测到DoS攻击时，便会配置负载均衡器，以降低或限制与攻击相关的流量。在下一层，GFE实例还会将与它们正在接收的请求有关的信息报告给中央DoS服务，包括负载均衡器没有的应用层信息。然后，中央DoS服务还会配置GFE实例，以降低或限制攻击流量。
③ 用户身份验证：在DoS防御之后，下一层防御来自中央身份识别服务。此服务通常作为Google登录页面显示给最终用户。除了要求提供简单的用户名和密码，该服务还会根据风险因素智能地要求用户提供其他信息，例如询问他们过去是否从同一设备或类似位置登录过。在对用户进行身份验证之后，身份识别服务会签发Cookie和OAuth令牌等凭据，供后续调用时使用。用户还可以选择在登录时使用第二因素身份验证，例如动态密码或防止网上诱骗的安全密钥。为确保除Google以外的其他第三方也能享受这些优势，Google通过FIDO Alliance与多家设备供应商合作，以便开发通用第二因素（U2F）开放标准。
·安全运营
① 安全的软件开发：除了前面介绍的中央源代码控制和双方审核功能，Google还开发了可阻止开发者引入带有某些安全错误的库，例如，可以让网页应用避免引入带有XSS漏洞的库和框架，以及可自动检测安全错误的自动化工具（包括模糊测试工具、静态分析工具和网络安全扫描工具）。Google会对软件开发中所写的代码进行人工安全审核，并将其作为最终检查，比如，对较低风险的功能进行快速分类，对最高风险的功能在设计和实施上进行深入审核。执行这些审核的团队由网络安全、加密和操作系统安全领域的专家组成。此类审核还可能催生出新的安全库功能和新的模糊测试工具，以用于未来的其他产品。此外，为了进一步保障软件开发的安全，鼓励大家积极有效地发现漏洞，Google实施了漏洞奖励计划（Vulnerability Rewards Program），对于在基础架构或应用中发现错误并告知的人员予以奖励，自该计划实施以来，Google已经发放了数百万美元的奖励。Google还投入了大量精力查找使用的所有开源软件中的零日漏洞及其他安全问题，并上报这些问题。例如，Google发现了OpenSSL Heartbleed错误，并且是为Linux KVM管理程序提交CVE（Common Vulnerabilities&Exposures，公共漏洞和暴露）和安全问题修复解决方案最多的一家公司。
② 员工设备及凭据安全：投入大量成本来保护员工的设备和凭据免遭破解，并监控相关活动以便发现潜在的破解行为或内部人员非法行为，这是为确保基础架构安全运行所进行的关键投资。员工始终面临着高级网上诱骗威胁，为了防范这种威胁，Google强制为员工账号使用了兼容U2F的安全密钥，取代了可能会受到网上诱骗攻击的动态密码第二因素身份验证。Google还投入大量成本来监控员工用来运行基础架构的客户端设备，确保这些客户端设备的操作系统映像具有最新的安全补丁程序，并确认应用是否可以安装。此外，Google配备了相关系统来扫描员工安装的应用、下载内容、浏览器扩展程序和网络浏览内容，以确保其适合企业客户端。员工是否在企业局域网上办公不是用来判断是否授予访问权限的主要条件。Google使用应用级访问管理控制机制，以便仅向来自安装有Google安全客户端认证的设备以及来自预期网络和地理位置的特定用户公开内部应用，这也是Google的BeyondCorp架构的一部分。
③ 降低内部人员风险：积极限制并主动监控拥有基础架构管理员权限的员工的活动，并且不断地努力以期不再针对特殊任务而授予特别访问权限，而可以以安全可控的方式自动完成同样的任务。限制措施包括，要求某些操作获得双方批准方可执行，以及引入有限的API（对这些有限的API进行调试不会暴露敏感信息）等。Google员工对最终用户信息的访问情况可通过底层基础架构钩子进行记录。Google的安全团队会主动监控访问模式并调查异常事件。
④ 入侵检测：Google拥有先进的数据处理管道，这些管道汇聚了各个设备上基于主机的数据、来自基础架构中各个监控点的基于网络的数据，以及来自基础架构服务的数据。构建于这些管道之上的规则和机器智能会向运营安全工程师发出潜在事件警告。调查和事件响应团队会每年365天、24小时全天候地对这些潜在事件进行分类、调查和响应。此外，Google也效仿Red Team的做法来衡量和改善检测与响应机制的有效性。
结合Google云平台的安全分层架构和国内一般互联网公司的实际情况，我设计了一个更具普适性且易于实践的互联网安全技术架构，如下图所示。
纵观Google云平台的安全技术体系，我们可以看到Google云平台的安全设计是基于纵深防御架构和安全融于体系的理念的。
· Google在物理层安全方面提供了生物识别、激光入侵检测等技术加强重要场地的安全。国内公司的机房一般都是通过登记进行管理，并配有摄像监控。
· Google在硬件层提供了可信执行环境（TEE）芯片Titan来保障硬件可信和系统启动可信，并提供加密身份认证（CA认证）功能。据称，Google将在未来开源Titan芯片的设计，有关Titan的详细介绍可见参考资料[21]。同时微软云平台Azure也提供了类似的安全解决方案，详见参考资料[22]。国内的互联网公司在服务器定制和芯片开发方面还有待进步，未来可能需要先依靠几个大的云服务厂商来做，而小公司使用Intel的SGX来实现部分功能更切实际。
·在网络层，Google使用了多层防御，首先结合全球负载均衡（GLB）在网络边缘提供的Cloud Armor产品来解决L3～L7层的网络安全问题，包括分布式拒绝服务攻击（DDoS）、IP访问控制和类似WAF的功能，详见参考资料[23]。其次，Google提供了GFE（Google Front End）服务，GFE是一个类似Nginx的反向代理产品，用来控制不可信的TLS访问和进一步细粒度地解决DDoS攻击，有关GFE的资料比较少，可以参考Google SRE的相关文章，文章地址可见参考资料[24]。同时在网络传输安全方面，Google自己实现了一套被称为ALTS的通信协议，与Borg服务结合紧密。ALTS相比TLS更加轻量化，并抛弃了过时的加密算法，ATLS使用Protocol Buffer来序列化证书和协议消息，是Google分布式RPC通信框架的基础，有关ATLS的详细设计见参考资料[25]，Google云的传输加密架构见参考资料[26]。在网络层安全的建设方面，国内公司与国外公司的发展差距不大，而且也有不少不错的开源产品，比如，在NTA网络流量分析方面有AOL开源的Moloch（详见参考资料[27]）和redborder（详见参考资料[28]）等，在欺骗防御方面有Thinkst的OpenCanary和Canarytokens，详见参考资料[29]。
·在主机层，Google应用了Shielded VM技术，结合Titan芯片实现可信启动和加密认证功能，使用UEFI替代BIOS实现安全启动，并提供了热补丁和热更新技术，详见参考资料[30]。而Google自己的服务则运行于Container-Optimized OS上，它是基于Chromium OS定制的一个加固容器，具备IMA、KPTI、LSM、LoadPin、AppArmor等多种安全功能属性，详见参考资料[31]，同时Google还在打造一个隔离性更强的容器gVisor，不过该产品目前还在开发中，性能和功能还未达到生产要求，项目地址详见参考资料[32]。在主机层的安全建设方面，国内公司多依赖于HIDS，老牌的开源产品有OSSEC，不过该产品的自我保护能力不足，安全检测能力一般，比如在后门检测（Rootkit）、反弹shell等方面较弱。新的开源产品有Facebook的Osquery，详见参考资料[33]。
·在应用层，Google提供了Cloud Security Scanner自动化漏洞扫描服务，主要检测Web相关的安全漏洞，详见参考资料[34]。对于应用层API安全，Google提供了Apigee Sense安全功能，该功能类似于Istio微服务治理框架，实现身份验证、授权、速率限制和检测机器人恶意调用攻击等功能，详见参考资料[35]。在应用层安全建设方面，国内公司的发展相对比较成熟，有完善的WAF、RASP、DBF产品线。其中不少开源产品也不错，比如百度的OpenRASP，详见参考资料[36]。
·在业务层，Google所做的安全工作比较少，仅在内容安全方面提供了Cloud Vision和Cloud Video Intelligence服务，属于机器学习方面的应用，可以用来检测视频和图片内容，比如成人或暴力等方面的内容，详见参考资料[37]和参考资料[38]。在业务安全方面，国外的关注点主要集中在anti-fraud反欺诈方向上，国内的公司，特别是互联网电商公司，反而做得更加成熟，做了很多账号风控、交易风控、支付风控以及内容安全方面的工作，主要构筑于Spark、Storm、Flink和机器学习等基础上，比如阿里巴巴有MTEE第三代智能风控引擎、NTU实时计算引擎、实人认证人脸识别等。
·在身份和访问权限管理方面，Google提供了CloudIAM做身份与访问管理，详见参考资料[39]；同时提供了Cloud Identity-Aware Proxy（Cloud IAP）来做访问权限控制和安全审计，类似云访问安全代理（CASB）的功能，该组件是BeyondCorp的组件之一，详见参考资料[40]；另外提供了Cloud Resource Manager来做资产管理，类似配置管理数据库（CMDB）的功能，详见参考资料[41]；最后还提供了基于FIDO协议的Titan Security Key做双因素认证来拦截网上诱骗的攻击（又称为钓鱼攻击），详见参考资料[42]。国内不少公司在这方面做得相对没那么好，不少企业内部缺乏统一的身份和访问权限管理系统，缺乏双因素认证、资产管理等方面的设施。比较好的开源IAM产品有gluu，详见参考资料[43]。
·在数据安全与隐私方面，Google提供了Cloud KMS密钥管理系统，详见参考资料[44]；同时提供了Cloud HSM硬件安全模块，用来处理加密操作并提供加密密钥的安全存储，详见参考资料[45]；另外还提供了数据泄露防护（Data Leakage Prevention，DLP）相关功能，用于数据的分类分级、数据脱敏等，详见参考资料[46]。随着公民隐私意识增强和法律制度的完善，数据安全与隐私对企业来说变得越来越重要。而国内公司在该方向上多起步较晚，与国外公司差距较大。随着大数据的兴起，很多企业内部团队（如BI团队）会接触到大量敏感数据。如果没有对这些数据做管控并采取相应的技术措施，那么就很容易产生数据泄露和隐私保护风险。大数据产品（如Hadoop）由于缺乏安全功能，也会带来不少安全隐患。在维护数据安全与隐私方面也有不少开源产品，比如，Apache Ranger可以做细粒度权限管理，详见参考资料[47]；eBay开源的Apache Eagle可以做大数据安全与性能分析，详见参考资料[48]。在开源KMS（Key Management System，密钥管理系统）产品中比较好的有HashiCorp的Vault，详见参考资料[49]。
·在安全运营方面，Google提供了Stackdriver Logging服务，用于实时日志管理和分析，类似于ELK的功能，详见参考资料[50]；同时提供了Cloud Security Command Center安全与数据风险平台，用于态势感知和综合数据分析（如异常检测），并可实现安全编排和自动化响应功能，类似于SIEM和SOAR，详见参考资料[51]。针对Cloud SCC，Google还开源了Forseti，这是一款由社区驱动并与Google云平台结合紧密的资产清查和安全基线检查产品，详见参考资料[52]。另外，Google对内还使用了BeyondCorp架构来做访问控制和安全审计，详见参考资料[53]。国内公司在这方面也有一定的积累，比如，阿里巴巴的态势感知系统，腾讯针对内网终端办公安全所做的iOA、Itlogin和TSOC等。要管理几千甚至几万人规模公司的安全，就必须具备对应的大数据安全分析和自动化安全响应能力。同时，国内公司大部分都建立了SRC安全响应中心用以收集白帽提交的安全漏洞、组织安全渗透，并召开安全会议活动。但针对内网终端办公安全，不少公司做得还不到位，这也成为黑客入侵和数据泄露的重灾区。这里也有不少不错的相关开源产品，例如Mozilla开源的SIEM平台MozDef，详见参考资料[54]。