[translate]Google基础设施安全设计概述


=Start=

缘由:

向高手学习新姿势

正文:

参考解答:

CIO级别摘要

  • Google拥有全球规模的技术基础架构,旨在给通过Google的整个信息处理生命周期提供安全性。 此基础架构提供:服务的安全部署,终端用户隐私保护的安全数据存储,服务之间的安全通信,通过互联网与客户的安全和私人通信以及管理员的安全操作。
  • Google使用此基础架构构建其互联网服务,包括搜索,Gmail和照片等消费者服务以及G Suite和Google Cloud Platform等企业服务。
  • 基础设施的安全性从数据中心的物理安全性开始逐步设计,继续到作为基础设施基础的硬件和软件的安全性,最后是支持操作安全性的技术限制和流程。
  • Google投入大量资金保护其基础设施,包括数百名致力于安全和隐私的工程师,分布在所有Google产品和服务中,其中包括许多获得认可的行业权威机构。

介绍

本文档概述了Google的技术基础设施是如何设计以保证安全的。Google拥有全球规模的技术基础架构,旨在给通过Google的整个信息处理生命周期提供安全性。 此基础架构提供:服务的安全部署,终端用户隐私保护的安全数据存储,服务之间的安全通信,通过互联网与客户的安全和私人通信以及管理员的安全操作。

Google使用此基础架构构建其互联网服务,包括搜索,Gmail和照片等消费者服务以及G Suite和Google Cloud Platform等企业服务。

我们将从我们的数据中心的物理安全开始,继续到如何保证基础设施的硬件和软件安全,最后描述技术限制和流程以支持运营安全。

Google基础设施安全层:从底层的硬件基础架构到顶层的操作安全性的各种安全层。 每一层的内容在本文中详细描述。

底层基础设施的安全

在本节中,我们将介绍如何保护基础架构的最低层,从物理场所到数据中心的特定硬件,以及在每台机器上运行的低级软件堆栈。

物理设施的安全

Google设计和构建自己的数据中心,其中包含多层物理安全保护。 对这些数据中心的访问仅限于Google员工中的很小一部分。 我们使用多个物理安全层来保护我们的数据中心地板,并使用生物识别,金属检测,摄像机,车辆障碍和基于激光的入侵检测系统等技术。 Google还在第三方数据中心内部托管了一些服务器,我们确保在数据中心运营商提供的安全层之上有由Google控制的物理安全措施。 例如,在这些地点,我们可以操作独立的生物识别系统,照相机和金属检测器。

硬件设计与原型

Google数据中心由连接到本地网络的数千台服务器计算机组成。 服务器板和网络设备都是由Google定制设计的。 我们审查与我们合作的组件供应商,谨慎选择组件,同时与供应商合作,审计和验证组件提供的安全属性。 我们还设计定制芯片,包括目前部署在服务器和外设上的硬件安全芯片。 这些芯片可让我们在硬件层面安全地识别和验证合法的Google设备。

安全引导堆栈和机器身份

Google服务器机器使用各种技术来确保它们正在引导正确的软件堆栈。 我们在低级组件(如BIOS,引导加载程序,内核和基本操作系统映像)上使用加密签名。 这些签名可以在每次引导或更新期间验证。 这些组件全部由Google控制,构建和强化。随着每一代新硬件的发展,我们努力不断地提高安全性:例如,根据服务器设计的生成,我们将引导链的信任归功于可锁定固件芯片,运行Google编写的安全代码的微控制器,上面提到的Google设计的安全芯片。

数据中心中的每个服务器机器都有自己的特定标识,可以绑定到硬件根信任和计算机引导的软件。 此身份用于验证机器上的低级管理服务的API调用。

Google已经创建了自动化系统,以确保服务器运行其软件堆栈(包括安全补丁)的最新版本,检测和诊断硬件和软件问题,并在必要时从服务中删除计算机。

安全的服务部署

我们将继续描述我们如何从基本的硬件和软件到确保一个服务安全地部署在我们的基础设施上。 “服务”是指开发人员写入并希望在我们的基础架构上运行的应用程序二进制文件,例如Gmail SMTP服务器,BigTable存储服务器,YouTube视频转码器或运行客户应用程序的App Engine沙盒。 可能有数千台机器运行相同服务的副本以处理所需的工作负载规模。 在基础架构上运行的服务由名为Borg的集群编排服务控制。

正如我们将在本节中看到的,基础设施不承担在基础设施上运行的服务之间的任何信任。 换句话说,基础设施从根本上设计为多租户。

服务身份,完整性和隔离

我们在应用层使用加密认证和授权进行服务间通信。 这在管理员和服务可以自然地理解的抽象级别和粒度上提供了强大的访问控制。

我们不依赖内部网络分段或防火墙作为我们的主要安全机制。虽然我们在我们的网络中的各个点使用入口和出口过滤,以防止IP欺骗作为另一个安全层。 这种方法还有助于我们最大限度地提高网络的性能和可用性。

在基础架构上运行的每个服务都具有关联的服务帐户身份。 向服务提供加密凭证,在向其他服务发出或接收远程过程调用(RPC)时,可以使用该凭证来证明其身份。 这些标识由客户端使用以确保它们正在与正确的预期服务器通信,并且由服务器来限制对特定客户端的方法和数据的访问。

Google的源代码存储在中央存储库中,其中服务的当前版本和过去版本都是可审计的。 此外,可以将基础设施配置为要求从特定的审查,检入和测试的源代码构建服务的二进制文件。 此类代码审查需要至少一个除作者以外的工程师的检查和批准,并且系统强制该代码对任何系统的修改必须由该系统的所有者批准。 这些要求限制内部人或对手对源代码进行恶意修改的能力,并且还提供从服务返回其源的取证跟踪。

我们有各种隔离和沙盒技术,用于保护服务不受在同一台机器上运行的其他服务的影响。这些技术包括正常的Linux用户分离,基于语言和基于内核的沙箱以及硬件虚拟化。 一般来说,我们对更危险的工作负载使用更多的隔离层; 例如,当对用户提供的数据运行复杂文件格式转换器时,或者为Google App Engine或Google Compute Engine等产品运行用户提供的代码时。作为一个额外的安全边界,我们使非常敏感的服务,如集群协调服务和一些关键的管理服务,可以专门在专用计算机上运行。

服务间的访问管理

服务的所有者可以使用由基础设施提供的访问管理特征来精确地指定哪些其他服务可以与其通信。 例如,服务可能希望仅将一些API提供给其他服务的特定白名单。 可以使用允许的服务帐户标识的白名单配置该服务,然后该基础设施自动实施此访问限制。

访问服务的Google工程师也会被授予单独的身份,因此可以类似地配置服务以允许或拒绝其访问。 所有这些类型的身份(机器,服务和员工)都位于基础架构维护的全局名称空间中。 如将在本文档稍后解释的,终端用户身份被单独处理。

基础架构为这些内部身份(包括审批链,日志记录和通知)提供了丰富的身份管理工作流系统。 例如,可以通过允许两方控制的系统将这些身份分配给访问控制组,其中一个工程师可以向另一工程师(也是该组的管理员)批准的组建议改变。 该系统允许安全的访问管理过程扩展到在基础设施上运行的数千个服务。

除了自动API级访问控制机制,基础架构还为服务提供从中央ACL和组数据库读取的能力,以便他们可以在必要时实现自己的定制的细粒度访问控制。

加密服务间的通信

除了前面部分讨论的RPC认证和授权功能之外,基础设施还为网络上的RPC数据提供加密隐私和完整性。 为了向其他应用层协议(如HTTP)提供这些安全优势,我们将它们封装在我们的基础设施RPC机制中。 实质上,这提供了应用层隔离并且消除了对网络路径的安全性的任何依赖。 加密的服务间通信可以保持安全,即使网络被窃听或网络设备被攻破。

服务可以为每个基础设施RPC配置他们想要的加密保护级别(例如,仅为数据中心内的低值数据配置完整性级别保护)。 为了防止可能试图窃取我们的专用WAN链路的复杂对手,基础设施自动加密在数据中心之间通过WAN的所有基础设施RPC流量,而不需要从服务进行任何显式配置。 我们已经开始部署硬件加密加速器,这将允许我们将此默认加密扩展到我们数据中心内的所有基础架构RPC流量。

终端用户数据的访问管理

典型的Google服务是为终端用户做某事。 例如,最终用户可以在Gmail上存储他们的电子邮件。 最终用户与诸如Gmail之类的应用程序的交互跨越基础架构内的其他服务。 因此,例如,Gmail服务可以调用由联系人服务提供的API来访问最终用户的地址簿。

我们已经在前面部分中看到,可以配置联系人服务,以便只允许来自Gmail服务(或来自联系人服务要允许的任何其他特定服务)的RPC请求。

然而,这仍然是一个非常广泛的权限集。 在此权限的范围内,Gmail服务可以随时请求任何用户的联系人。

由于Gmail服务代表特定最终用户向联系人服务发出RPC请求,因此基础结构提供了一项功能,可让Gmail服务将“最终用户权限故障单”作为RPC的一部分。 此优惠券证明Gmail服务目前正代表该特定最终用户为请求提供服务。 这使联系人服务能够实现保护措施,其中它仅返回故障单中指定的最终用户的数据。

基础设施提供发出这些“最终用户权限票据”的中央用户身份服务。 最终用户登录由中央身份服务验证,然后中央身份服务向用户的客户端设备发出用户凭证,例如cookie或OAuth令牌。 从客户端设备到Google的每个后续请求都需要提供该用户凭证。

当服务接收到最终用户凭证时,它将凭证传递给中央身份服务以进行验证。 如果最终用户凭证正确验证,中央身份服务返回可用于与请求相关的RPC的短期“最终用户权限故障单”。 在我们的示例中,获取“最终用户权限标签”的服务将是Gmail服务,这会将其传递给联系人服务。 从那时起,对于任何级联呼叫,“最终用户权限票据”可以由呼叫服务作为RPC呼叫的一部分传递给被呼叫者。

服务标识和访问管理:基础结构提供服务标识,自动相互认证,加密的服务间通信和由服务所有者定义的访问策略的实施。

安全的数据存储

到目前为止,在讨论中,我们已经描述了如何安全地部署服务。 我们现在来讨论如何在基础设施上实施安全数据存储。

加密所有的内容

Google的基础架构提供各种存储服务,如BigTable和Spanner,以及中央密钥管理服务。 Google的大多数应用程序通过这些存储服务间接访问物理存储。 存储服务可以配置为使用来自中央密钥管理服务的密钥在将数据写入物理存储之前对数据进行加密。 此密钥管理服务支持自动密钥轮换,提供大量审核日志,并与上述最终用户权限标签集成,以将密钥链接到特定最终用户。

在应用程序层执行加密允许基础设施将自身与较低级别的存储(例如恶意磁盘固件)的潜在威胁隔离。 也就是说,基础设施还实现了额外的保护层。 我们在硬盘驱动器和SSD中启用硬件加密支持,并仔细跟踪每个驱动器的生命周期。 在停用的加密存储设备可以物理地离开我们的保管之前,它使用包括两个独立验证的多步骤过程来清洁。 不通过该擦拭程序的设备在物理上被破坏(例如,粉碎)在内部。

删除数据

在Google上删除数据通常首先将特定数据标记为“计划删除”,而不是完全删除数据。 这允许我们从无意的删除中恢复,无论是客户启动的还是由于内部的错误或进程错误。 在被标记为“计划删除”之后,根据服务特定策略来删除数据。

当最终用户删除其整个帐户时,基础架构通知处理最终用户数据的服务已删除该帐户。 然后,服务可以调度与已删除的最终用户帐户相关联的数据以进行删除。 此功能使服务的开发人员能够轻松实现最终用户控制。

安全的互联网通信

在本文档中的这一点之前,我们已经描述了如何保护我们的基础架构上的服务。 在本节中,我们将讨论如何确保互联网和这些服务之间的通信安全。

如前所述,基础结构包括通过LAN和WAN互连的大量物理机器,并且服务间通信的安全性不依赖于网络的安全性。 然而,我们确实将我们的基础设施与互联网隔离为私有IP空间,以便我们可以更容易地实施额外的保护,例如防御拒绝服务(DoS)攻击,只需将机器的一部分直接暴露给外部互联网流量。

Google前端服务

当服务想要在因特网上可用时,它可以向称为Google前端(GFE)的基础设施服务注册自己。 GFE确保所有TLS连接都使用正确的证书和遵循最佳实践(如支持完全转发保密)。 GFE还应用于拒绝服务攻击的保护(我们将在后面更详细地讨论)。 然后,GFE使用先前讨论的RPC安全协议转发对服务的请求。

实际上,任何选择向外部发布的内部服务都使用GFE作为智能反向代理前端。 此前端提供其公共DNS名称,拒绝服务(DoS)保护和TLS终止的公共IP托管。 请注意,GFE像任何其他服务一样在基础架构上运行,因此具有扩展以匹配传入请求卷的能力。

拒绝服务攻击(DoS)保护

我们的基础架构规模庞大,使Google能够简单地吸收许多DoS攻击。 也就是说,我们有多层,多层DoS保护,进一步降低任何DoS对运行在GFE后面的服务的影响的风险。

在我们的骨干网向我们的一个数据中心提供外部连接之后,它通过几层硬件和软件负载平衡。 这些负载平衡器将有关入站流量的信息报告给在基础架构上运行的中央DoS服务。 当中央DoS服务检测到发生DoS攻击时,它可以配置负载均衡器以丢弃或限制与该攻击相关联的流量。

在下一层,GFE实例还将关于他们正在接收的请求的信息报告给中央DoS服务,包括负载平衡器没有的应用层信息。 然后,中央DoS服务还可以配置GFE实例以丢弃或限制攻击流量。

用户验证

在DoS保护后,下一层防御来自我们的中央身份服务。 此服务通常向最终用户显示为Google登录页面。 除了要求简单的用户名和密码,该服务还智能地挑战用户基于风险因素的其他信息,例如他们是否从同一设备或过去的类似位置登录。 在对用户进行身份验证后,身份服务会发出凭证,例如可用于后续呼叫的Cookie和OAuth令牌。

用户还可以选择在登录时使用第二个因素,例如OTP或防网络钓鱼安全密钥。为了确保这些好处不止在Google能用到,我们在FIDO联盟与多个设备供应商合作开发通用第二因子(U2F )开放标准。 这些设备现已在市场上出售,其他主要的网络服务也跟随我们实施U2F支持。

操作安全

到目前为止,我们已经描述了如何在我们的基础设施中设计安全性,并且还描述了一些用于安全操作的机制,例如RPC上的访问控制。

我们现在转向描述我们如何安全地操作基础设施:我们安全地创建基础设施软件,我们保护我们员工的机器和凭据,我们防御内部人员和外部角色对基础设施的威胁。

安全的软件开发

除了前面介绍的中心源代码控制和双方审查功能之外,我们还提供了防止开发人员引入某些类型的安全漏洞的库。 例如,我们有库和框架,消除Web应用程序中的XSS漏洞。 我们还有自动化工具,用于自动检测安全漏洞,包括模糊器,静态分析工具和Web安全扫描程序。

作为最后检查,我们使用手动安全审查,从快速分类到低风险功能,深入设计和实施审查最危险的功能。 这些审核由包括网络安全,密码学和操作系统安全专家的团队进行。 评论还可以产生新的安全库功能和新的模糊器,然后可以应用于其他未来的产品。

此外,我们运行一个漏洞奖励计划,我们向任何能够发现并通知我们基础架构或应用程序中的错误的人员付款。 我们已经在这个计划中支付了几百万美元的奖励。

Google还投入大量精力在我们使用的所有开放源代码软件中查找0day漏洞利用和其他安全问题,并上传这些问题。 例如,在Google上发现了OpenSSL Heartbleed错误,我们是CVE最大的提交者以及Linux KVM虚拟机管理程序的安全错误修复程序。

保证员工设备和证书安全

我们进行了大量投资,以保护我们员工的设备和凭证免受妥协,并监控活动以发现潜在的妥协或非法内部活动。 这是我们投资的关键部分,以确保我们的基础设施安全运行。

我们的员工一直是复杂网络钓鱼的目标。 为了防范这种威胁,我们已经替换了可疑的OTP第二个因素,强制使用我们员工帐户中与U2F兼容的安全密钥。

我们对监控我们的员工用于操作我们的基础设施的客户端设备进行了大量投资。 我们确保这些客户端设备的操作系统映像是最新的安全补丁,我们控制可以安装的应用程序。 此外,我们还具有用于扫描用户安装的应用程序,下载,浏览器扩展和从Web浏览的内容以便在公司客户端上适用的系统。

在公司LAN上不是我们授予访问权限的主要机制。 我们使用应用程序级访问管理控制,允许我们仅当特定用户来自正确管理的设备和预期的网络和地理位置时才向内部应用程序公开。 (更多细节参见我们关于’BeyondCorp’的附加阅读。)

降低内部风险

我们积极地限制和主动监控已授予对基础设施管理访问权限的员工的活动,并通过提供可以以安全和受控的方式完成相同任务的自动化,继续努力消除对特定任务的特权访问的需要。 这包括需要对某些操作进行双方批准,并引入有限的API,允许在不暴露敏感信息的情况下进行调试。

Google员工对最终用户信息的访问权限可以通过低级基础结构挂钩记录。 Google的安全小组会主动监控访问模式并调查异常事件。

入侵检测

Google拥有先进的数据处理管道,将基于主机的信号集成到单个设备上,基于网络的信号来自基础设施中的各个监控点,以及来自基础设施服务的信号。 在这些管道之上建立的规则和机器智能为操作安全工程师提供可能发生的事故的警告。 我们的调查和事故响应小组每年365天全天24小时对这些潜在事件进行分类,调查和应对。 我们进行红队练习来衡量和提高我们的检测和反应机制的有效性。

保护Google云端平台(GCP)

在本节中,我们强调我们的公共云基础设施,GCP,如何从底层基础设施的安全中受益。 在本节中,我们将使用Google Compute Engine(GCE)作为示例服务,并详细描述我们在基础架构上构建的特定于服务的安全改进。

GCE使客户能够在Google的基础架构上运行自己的虚拟机。 GCE实现包括几个逻辑组件,最显着的是管理控制平面和虚拟机本身。

管理控制平面公开外部API表面并协调虚拟机创建和迁移等任务。 它作为基础设施上的各种服务运行,因此它自动获得基本完整性功能,如安全引导链。 各个服务在不同的内部服务帐户下运行,以便每个服务都可以被授予只有在对控制平面的其余部分进行远程过程调用(RPC)时所需的权限。 如前所述,所有这些服务的代码存储在中央Google源代码存储库中,并且在此代码和最终部署的二进制文件之间存在审计跟踪。

GCE控制平面通过GFE公开其API,因此利用了拒绝服务(DoS)保护和集中管理的SSL / TLS支持等基础设施安全功能。 客户可以通过选择使用基于GFE构建的可选的Google Cloud Load Balancer服务来获得对在其GCE VM上运行的应用程序的类似保护,并可以缓解多种类型的DoS攻击。

对GCE控制平面API的最终用户认证是通过Google的集中身份服务完成的,该服务提供安全功能,例如劫持检测。 授权使用中央云IAM服务完成。

从GFE到其后面的第一服务以及其他控制平面服务之间的控制平面的网络流量由基础设施自动认证并且每当它从一个数据中心传播到另一数据中心时被加密。 此外,基础设施也被配置为加密数据中心内的一些控制平面业务。

每个虚拟机(VM)使用关联的虚拟机管理器(VMM)服务实例运行。 基础设施为这些服务提供两种身份。 一个身份由VMM服务实例用于其自己的呼叫,一个身份用于VMM代表客户的VM进行的呼叫。 这允许我们进一步分割对来自VMM的呼叫的信任。

GCE持久磁盘使用由中央基础设施密钥管理系统保护的密钥在静止时进行加密。 这允许自动旋转和对这些键的访问的中央审计。

今天的客户可以选择是否将来自其VM的流量发送到其他VM或互联网,或者实施他们为此流量选择的任何加密。 我们已开始推出自动加密,用于将客户虚拟机的广域网遍历跳转到虚拟机流量。 如前所述,基础设施内的所有控制平面WAN流量都已加密。 将来,我们计划利用之前讨论的硬件加速网络加密,以加密数据中心内的虚拟机之间的LAN流量。

提供给VM的隔离基于使用开源KVM堆栈的硬件虚拟化。 我们通过将一些控制和硬件仿真栈移动到内核之外的非特权进程,进一步强化了我们的KVM的特定实现。 我们还使用诸如模糊,静态分析和手动代码审查等技术广泛测试了KVM的核心。 如前所述,大多数最近公开披露的漏洞已被上传到KVM,来自Google。

最后,我们的运营安全控制是确保访问数据遵循我们的政策的关键部分。 作为Google Cloud Platform的一部分,GCE对客户数据的使用遵循GCP对客户数据政策的使用,即除非有必要向客户提供服务,否则Google不会访问或使用客户数据。

结论

我们已经描述了Google基础架构是如何设计来在互联网规模上安全地构建,部署和运营服务的。 这包括Gmail等消费者服务和我们的企业服务。 此外,我们的Google云端产品是建立在这个相同的基础架构之上。

我们在确保我们的基础设施方面投入巨资 我们有数百名专门用于安全和隐私的工程师,分布在所有Google产品中,包括许多获得认可的行业权威机构。

正如我们所看到的,基础设施的安全性是从物理组件和数据中心到硬件来源,然后到安全引导,安全服务间通信,安全数据静止,受保护的服务访问互联网以及我们为运营安全而部署的技术和人员流程。

附加阅读

有关具体领域的更多详细信息,请参阅以下文件:

  1. 我们的数据中心的物理安全
    https://goo.gl/WYlKGG
  2. 我们的集群管理和编排的设计
    http://research.google.com/pubs/pub43438.html
  3. 存储加密和我们面向客户的GCP加密功能
    https://cloud.google.com/security/encryption-at-rest/
  4. BigTable存储服务
    http://research.google.com/archive/bigtable.html
  5. 扳手存储服务
    http://research.google.com/archive/spanner.html
  6. 我们网络负载平衡的架构
    http://research.google.com/pubs/pub44824.html
  7. BeyondCorp方法来实现企业安全
    http://research.google.com/pubs/pub43231.html
  8. 打击网络钓鱼与安全密钥和通用第二因素(U2F)标准
    http://research.google.com/pubs/pub45409.html
  9. 有关Google脆弱性奖励计划的详情
    https://bughunter.withgoogle.com/
  10. 有关GCP上的HTTP和其他负载平衡产品的更多信息
    https://cloud.google.com/compute/docs/load-balancing/
  11. 有关GCP的DoS保护最佳做法的更多信息
    https://cloud.google.com/files/GCPDDoSprotection-04122016.pdf
  12. Google Cloud Platform使用客户数据政策
    https://cloud.google.com/terms/
  13. 进一步了解G套件中的应用程式安全性和相容性(Gmail,云端硬碟等)
    https://goo.gl/3J20R2
参考链接:

=END=

,

《“[translate]Google基础设施安全设计概述”》 有 36 条评论

  1. 扒一扒这两天有关阿里云经典网络安全性的争论
    http://www.freebuf.com/articles/others-articles/128113.html
    关于阿里云经典网络的问题
    http://weibo.com/ttarticle/p/show?id=2309404079841686247162
    科普一下公有云的网络
    http://weibo.com/ttarticle/p/show?id=2309404079443999097225

    `千万不要单独评估一个安全漏洞的危害,只要它能干不应该干的事情,就要警惕。`
    http://weibo.com/1819367693/EwZFypkK6

    云服务器ECS安全组实践(一)
    https://yq.aliyun.com/articles/70403
    云舒:租户隔离科普文,阿里云经典网络问题续
    http://mp.weixin.qq.com/s?__biz=MjM5MzM3NjM4MA==&mid=507197650&idx=1&sn=a292f80eb6f34e0ab4df80b5dffbfe0e#rd

  2. 绝对不应错过的五大开源安全工具
    http://www.aqniu.com/tools-tech/23198.html
    `
    一、Commit Watcher:检索代码中的秘密信息
    二、Jak:在Git上加密
    三、Yara:使用格式匹配来发现问题
    四、ProcFilter:使用格式匹配来解决问题
    五、OSquery:查询系统状态的端点
    `
    https://github.com/srcclr/commit-watcher
    https://github.com/dispel/jak
    https://github.com/VirusTotal/yara
    https://github.com/godaddy/procfilter

  3. 安全事件关联规则讨论
    https://xianzhi.aliyun.com/forum/topic/1974
    `
    1. 为什么做日志关联分析
    2. 怎样做日志关联分析
    3. 关于安全事件的日志收集

    收集的日志信息可以形成适合自己组织业务的威胁情报数据,如近3天的入侵源 IP 资源池,近一月的流行流行漏洞和攻击方式,代理 IP 库等等。也适用于组织其他业务的安全防御工作。另外关联分析的结果需要结合告警平台,将产生的告警事件通知到相关人员,告警可以使用短信、邮件、微信等方式,可以自建,也可以结合运维系统(如 zabbix)进行发送。也可以结合 zabbix 的事件处理程序直接对在运维平台上完成整个事件的处置。

    将安全事件相关日志收集今昔收集,再用一些关联规则确定真实的攻击事件,实际就是 SIEM,将规则的提取、使用和禁用的过程做个一个生命周期的管理,结合安全事件的处置形成一套标准化的东西。
    `

  4. AWS IAM vs API vs CloudTrail 权限分配研究
    https://summitroute.com/blog/2018/06/28/aws_iam_vs_api_vs_cloudtrail/

    什么是 IAM?
    https://docs.aws.amazon.com/zh_cn/IAM/latest/UserGuide/introduction.html
    https://en.wikipedia.org/wiki/Identity_management

    为什么 IAM 意味着安全的 3 个理由
    https://www.coresecurity.com/blog/3-reasons-why-iam-means-security
    `
    1. IAM 是第一道防线
    2. 权限最小化 = 保护你的数据安全
    3. IAM 是最后一道防线
    `
    gartner iam filetype:pdf

    • AWS的 iam 最佳实践
      https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html
      https://amazonaws-china.com/cn/iam/
      `
      用户 – 创建单独的用户。

      组 – 利用组来管理权限。

      权限 – 授予最低权限。

      审核 – 打开 AWS CloudTrail。

      密码 – 配置强大的密码策略。

      MFA – 为特权用户启用 MFA。

      角色 – 将 IAM 角色用于 Amazon EC2 实例。

      统一认证(SSO) – 使用 IAM 角色共享访问权限。 [?]

      轮换 – 定期轮换安全凭证。

      访问管理 – 利用条件进一步限制特权访问。

      特权账户 – 减少或删除特权账户的使用。
      `

  5. 可能取代SIEM的PB级遥测数据平台:谷歌发布Backstory
    https://mp.weixin.qq.com/s/ArLDHSRxLk_lF99F5A7O3w
    `
    Alphabet子公司Chronicle脱胎自其X计划,于2016年成立。如今,该公司宣称将推出3款网络安全产品: “Backstory”、“Uppercase” 和 “Virustotal” (谷歌于2012年买入的一款恶意软件跟踪工具)。

    其中,Backstory因其“无限扩展”能力,以及使用了构造谷歌基础设施核心的威胁分析引擎而引人注目。极有可能取代2025年市场规模估值1,770亿美元的安全信息与事件管理(SIEM)工具。

    Backstory基本上就是威胁态势版“谷歌”,能够摄入、保留和处理大量威胁数据以进行即时分析。Chronicle首席执行官 Stephen Gillett 将之描述为“以PB为单位思考时代的首款全球安全遥测平台。”

    Chronicle为谷歌核心基础设施再添一层,可供客户上传安全遥测数据,包括海量数据,如DNS流量、网络流量、终端日志、代理日志等,方便进行索引并应用分析引擎自动分析。很多SIEM也能达成同样功效,其中区别就在于可扩展性。

    威胁情报馈送理应附加更多上下文,但往往噪音冗余太甚,以致造成的麻烦比清除的威胁还多。外包给安全服务提供商(MSSP)也不过是将资本支出转换为运营支出,把问题挪到了其他地方而已。

    Backstory能使公司企业运用索引、管理和分析工具,针对自身数据集和第三方或客户馈送的威胁信号,自行保留、分析和搜索大量安全及网络遥测数据。
    `
    Chronicle白皮书
    https://go.chronicle.security/hubfs/Backstory_WP.pdf

  6. 一图了解Google工具栈
    https://mp.weixin.qq.com/s/8mChNs36m-kxL5CUsIHLcw
    `
    Google 一名前员工在 GitHub 上分享了他在 Google 工作时日常使用的工具列表,并详细列出了这些工具列表的外界对应的替代方案。

    网友廖君结合现有的资料将学习笔记整理成脑图,并在原文基础上进行了一定的补充和翻译。
    `
    https://github.com/jhuangtw-dev/xg2xg
    xmind 文件链接: https://pan.baidu.com/s/1iAEPf6OfC2YkG-k7TSyq8g 提取码: 6n9m

  7. Google 基础架构安全设计概述
    https://cloud.google.com/security/infrastructure/design?hl=zh-cn
    `
    * 面向首席信息官级别领导人的摘要
    * 简介
    * 安全的底层基础架构
    ____* 实体场所的安全性
    ____* 硬件的设计和来源
    ____* 安全的启动堆栈和机器身份标识
    * 安全的服务部署
    ____* 服务身份标识、完整性和隔离
    ____* 服务间访问管理
    ____* 服务间通信的加密
    ____* 最终用户数据访问管理
    * 安全的数据存储
    ____* 静态加密
    ____* 删除数据
    * 安全的互联网通信
    ____* Google 前端服务
    ____* 防御拒绝服务 (DoS) 攻击
    ____* 用户身份验证
    * 运营安全
    ____* 安全的软件开发
    ____* 确保员工设备及凭据的安全性
    ____* 降低来自内部人员的风险
    ____* 入侵检测
    * 确保 Google Cloud Platform (GCP) 的安全
    * 总结
    * 附加阅读材料
    `

  8. 白话可信身份认证—FIDO、IFAA、TUSI
    http://www.mpaypass.com.cn/news/201612/12160934.html
    https://zhuanlan.zhihu.com/p/24336743
    `
    当前业界主流的可信身份认证解决方案,从硬件与安全协议的配合使用上主要可以分为两大类:单纯依靠硬件隔离的安全认证方案、硬件隔离结合可信身份认证协议的技术方案。

    1)靠安全硬件无安全协议

    由于搭建一套可信身份认证协议是需要一定成本的,运用起来也有一定的技术难度,所以在一些安全等级要求不高的场景暂时就仅靠安全硬件隔离来实现安全,未配合可信身份认证协议。相当于只实现了可信身份认证模型的前一段:本地认证。

    TEE结合生物特征识别安全认证方案,比如安卓手机中,华为Mate7、Mate8手机的指纹解锁、指纹支付功能,以及苹果iphone5S以上版本的手机的TouchID技术属于这一类型。此类安全方案只做了端的安全,实现了从用户到手机TEE侧的安全,但是不保证从TEE安全锚点到服务端之间的身份安全,所以其安全等级并不高,所以至多只能作为密码认证方式的一种补充。

    a.安卓指纹支付 (TEE&指纹)

    b.苹果的TouchID技术(TEE&指纹)

    2)硬件隔离结合可信身份认证协议的方案

    此类的方案,是实现了完整的可信身份认证模型,本地认证以及本地安全锚点到远端服务器之间的认证。包括传统的网银U盾系统和近几年业界很火的三大统一身份认证协议都属于这种类型:

    a.UKey(SE&CA证书协议)

    b.TUSI (SE&TUSI协议)

    c.FIDO(TEE&UAF、SE&UAF、SE&U2F)

    d.IFAA (TEE&IFAA标准)

    PKI/CA即Public Key Infrastructure 公钥基础设施,是一种利用公钥加密、公钥证书技术为电子商务的开展提供一套安全基础平台的技术和规范。TEE或SE协同安全认证协议进行身份认证,就像是在两个安全堡垒之间架设起来的封闭安全管道,用户通过安全管道走过去,被野外的生物攻击到的可能性就变得非常低,这就是为什么我们要软硬件结合的身份认证方案。TUSI、FIDO、IFAA三种统一身份认证协议之间的优劣,我们将在后续的文章里做深入的对比分析。

    3)有安全协议无安全硬件:

    另外,还有一些没有建立可信安全锚点,仅依靠安全协议的方案,也在广泛使用。比如https协议、区块链技术就是属于有安全认证协议,但是用户端侧没有可信硬件节点支撑。实际上它建立起来的通道的一端还是在开放的操作系统/软件系统里,也就是为什么它还是存在被攻击的可能性,会话密钥协商出来之后还是在不安全的环境里存储,理论上还是有被病毒木马获取的可能。
    `

  9. 认识 WebAuthn
    http://rui0.cn/archives/1543
    `
    WebAuthn在2019年3月成为了W3C推荐标准,同年的BlackHat大会上也有一篇议题专门介绍了WebAuthn,直到目前我们常见的浏览器大部分都已经支持了WebAuthn的标准,如Chrome,Safari等。可以看到各方力量都在联合推动着无密码认证的实现与发展,那么接下来我们就来一起认识一下什么是WebAuthn,以及它是如何工作的。

    FIDO联盟是一个安全、开放、防钓鱼、无密码认证标准的联盟。FIDO联盟成立于2013年,目前在全球拥有超过250名成员。FIDO有三个协议:UAF, U2F和FIDO2,它们是同一个协议家族。
    WebAuthn是FIDO联盟指导下的FIDO2项目的核心组成部分。WebAuthn的目标就是提供一系列标准化的协议,让用户告别过去繁琐且不安全的账号密码登录方式,以实现安全的无密登录体验为目的。它彻底抛弃了传统的账号密码登录方式,允许用户直接使用设备的指纹识别、面部识别、虹膜识别、声音识别、实体密钥(USB连接、蓝牙连接、NFC连接)等方式来进行登录验证。

    本质上WebAuthn只是一个浏览器JS API,描述用于创建和管理公钥证书的接口。是用来规范浏览器Web API的标准。FIDO2才是整个项目的名字。

    WebAuthn基于挑战-应答模型工作

    * USER(用户):指正准备注册/登录的用户
    * USER AGENT(用户代理):用户使用的浏览器或系统,负责与认证器交互
    * AUTHENTICATOR(认证器):认证器通常指USB Key或是设备内置的指纹扫描器、虹膜扫描器、面部识别装置等,正是它们在使用流程中代替了密码甚至是用户名
    * RELYING PARTY(依赖方):指服务提供方,即网站

    在其中认证通常会分为两种分别是Registration和Authentication,上图中不同实体角色之间的所有通信都由用户代理(USER AGENT)处理。

    # Registration
    Registration使用认证器(AUTHENTICATOR)去创建一组新的公钥-私钥凭据,可以用于对依赖方(RELYING PARTY)生成的challenge进行签名。然后会把公钥以及签名的challenge发送回依赖方进行处理与存储。依赖方以后可以在需要时使用这些凭证来验证用户的身份。

    # Authentication
    Authentication中前一部分和Registration一样都是接收依赖方生成的challenge,接下来认证器使用之前存储的公钥-私钥凭据对challenge进行签名,并将其发送给依赖方。通过这种方式依赖方可以验证用户是否拥有所需的凭证,从而证明其身份。

    # 总结
    首先我们再来回顾一下注册环节,主要是使用了navigator.credentials.create()请求认证器生成公钥凭证,其余流程如下。

    对于登录认证环节,主要是使用了navigator.credentials.get()请求获取公钥凭证,其余流程如下。

    WebAuthn被称为“Web身份认证的未来”,它本身需要依靠浏览器作为媒介和认证器进行交互,其本质上利用了非对称加密的方式来保护用户账号认证的安全性。其实我们可以想到当使用SSH进行连接时通常也有两种方式,一种是密码而另一种就是利用公钥,实际上与WebAuthn原理相同。WebAuthn的目标就是提供一系列标准化的协议,让用户告别过去繁琐且不安全的账号密码登录方式,以实现安全的无密登录体验。本文只简单介绍了其基本概念与流程,更多的细节以及标准建议阅读W3C文档。

    虽然WebAuthn提供了一种更加安全的认证模式,但与此同时必然会引发新的安全研究角度,对此浏览器安全会变得更加重要,依赖方的认证处理标准需要进一步规范统一。当然安全并不是一项单一的技术,相信不久的将来WebAuthn会成为Web身份验证中的重要组成部分之一。
    `
    https://webauthn.cn/
    https://webauthn.io/
    https://webauthn.guide/
    https://fidoalliance.org/fido2/

  10. 新的、不需要密码的网站登录协议 WebAuthn 的综合介绍。
    https://webauthn.wtf/
    `
    WebAuthn
    * What is WebAuthn?
    * History of WebAuthn
    * FIDO Alliance
    How it works
    * WebAuthn Basics
    * Authenticators
    * Relying Party
    * Registration Flow
    * Authentication Flow
    * Browser & Device Support
    Develop with WebAuthn
    * Build it Yourself
    * Use an Auth Provider
    * Demos
    * Debuggers
    Reference
    * WebAuthn Glossary
    * Common Questions
    * Additional Resources
    About
    * How to Contribute
    * Privacy & Attributions
    ==

    概述
    WebAuthn(Web Authentication的缩写)是一种API规范,使应用程序能够使用强大而安全的认证方法进行用户注册和登录。它为终端用户提供了一种使用基于硬件或软件的认证器(如USB安全钥匙或与笔记本电脑或移动设备集成的安全硬件元件)进行自我认证的方法,而不是仅仅依赖密码。

    这些认证器依靠公钥加密技术来提供安全的注册和账户认证。为了实现这一点,用户完成了一个注册仪式,将认证器设备与他们的账户联系起来,这就产生了一个公钥-私钥对。

    私钥被安全地存储在用户的设备上,而公钥则在网络应用服务器上注册。在登录过程中,用户通过完成认证仪式注册设备来验证他们的身份,而服务器则使用先前注册的公钥来验证签名。

    作为一个开发者,你可以使用WebAuthn为你的用户提供一个更安全和用户友好的认证机制。它被大多数现代网络浏览器和平台所支持,开源库和身份平台简化了与你现有认证流程的整合。
    `

回复 a-z 取消回复

您的电子邮箱地址不会被公开。 必填项已用*标注