安全乐观主义点评：由cnbird鸟哥分享的一份介绍Google BeyondProd实现的ppt，笔者遗憾没有现场听到具体的内容，ppt下面的“安全乐观主义点评”字样为小编的发散思考，并不代表鸟哥大佬原始观点。
安全乐观主义点评：ppt分为四个章节，介绍了云原生环境下的安全风险、Google的基础信任机制、BeyondProd实践以及实现技术细节。
安全乐观主义点评：咦！攻守之势异也。攻防两端，当具备完成基础的技术能力之后，将由传统被动挨打转移到主动防御建设阶段。从防御的层层积累，到检测、溯源、审计手段的多样化。将分布在各个角落的数据、安全态势、应急措施统一整合起来（安全切面乱入）。将原来的基于漏洞管理转换为应急的全面复盘，每次修复行动都增强了企业安全现状的全貌。由人工跟进漏洞到全自动化编排处理，自动化的前置条件是资产完全、流程完全、自动化手段完成。从红黑对抗的起点从找到漏洞，到规范化模拟ttps阶段，增强效果。从一味对标最佳实践，贪大求全的安全建设到以攻防演练为核心，从安全效果反推建设进度和成本。在不具备完全剔除攻击者的情况下，采取合理有效监控和观察手段，及时止损。从依据黑客行为特征到完全依赖白名单到基于行为的动态智能检测。依据云原生的架构治理内部服务，由以往的ip、主机重新定义身份信息，并给予认证鉴权。以往的devsecops等依赖于兴师动众的手段，迁移到基础设置提供安全标准能力，不仅仅是默认安全，更是基础架构安全，不给研发人员犯错的机会。
安全乐观主义点评：防止替换boot固件的攻击手段，谷歌从全球采购服务器，Titan 安全密钥采用一块硬件芯片，其中含有 Google 设计的固件，可验证密钥的完整性。这有助于确保密钥未曾遭受物理篡改。
安全乐观主义点评：要面对如何艰苦的形势，才需要具备这样的安全性？
安全乐观主义点评：热迁移、热补丁是技术的要点，带来的收益很高。为了最大化的安全防护，谷歌还对KVM的核心代码进行了如Fuzzing、静态分析、手工核查等一系列安全测试。
安全乐观主义点评：发布系统经常出现的问题是调度和隔离风险。由于谷歌在全球不同的region使用同一个主干仓库，brogmaster要验证每一次的发布方才可以访问指定的代码仓库、传输链路也要加密。CI、CD的制品分发时，也要加密和具备身份验证。多租户间执行任务，要实现各pipeline隔离策略，线上线下环境网络和数据隔离。
安全乐观主义点评：首先有统一的身份审批流程，说明具备了集中的策略扫描、资源角色定义、身份认证机制。具体在物理层面为主机创建身份还不够，为进程创建证书，进程的颗粒度表示具备BAB的能力，只有经过brog发布的服务，才能被访问和运行，结合实际，就是不再担心如下场景：内部员工（或攻击者）通过到具体的某个合法服务，自己部署一个拖库脚本任意访问线上数据库。通过brog发布的代码，一定是经过仓库负责人codereview，然后经过自动化的单测和白盒扫描服务。第二。主机证书是上面服务验证的核心，丢失怎么办？采取轮转的方式缩短暴露的间隔。workload，可以理解为不同的微服务负载，下面将会详细讲到。另外的亮点是实现了人的验证。如果一个合法员工需要进行线上数据的调试、安全调查怎么办呢？不能直接启动ide调试，和beyondcorp联动，在访问数据的grpc凭据附带个人的service account，只有在验证权限列表才能访问最终服务，20分钟失效。
安全乐观主义点评：传统的防护是防止外来攻击，而云原生的零信任是动态的，对服务间的数据传输进行身份标识和验证（不默认开启加密），避免在内网攻击者可以扩散开来。不再基于网络边界进行防护，而是每次都验证身份。传统的基于ip身份验证，但是云环境下，ip动态更新，缩扩容频繁，甚至一个ip背后有多个服务，一个ip，只能表示一层身份，不能表示数据链路调用关系。ip要求服务必须具备运行在主机或者硬件上，但是抽离真正需要防护的服务，就给了serverless应用、大数据作业、分布式应用也提供认证的可能性。传统的安全要求对每个应用进行加固，符合owasptop10、数据安全隐私之类种种制度，而且互相之间没有通过资源策略进行联系。构建和审核，有个Jenkins+sonar已经够用，但是云要求责任统一，有集中性的安全审核和视角。不仅仅要求自己可信，更要求服务调用间证明自己可信。云+互联网的方式服务发布频率快速，有了更快的响应、诊断、恢复、隔离的可能性。传统的攻击，是获取主机权限，然后提权为root。但是在负载之间的隔离，假设入侵了Google的系统，后面会面临着什么，从之前Google Borg生产环境安全来看容器最上层是跑的Google的各种业务，包括Gmail、Adworks、AdSense等，一旦Google的Portal、产品等存在高危漏洞直接进入Google Borg管理的容器中，首先要面对的第一层gVisor（详见Google生产环境安全）沙箱的安全保护，突破这层需要的知识包括，第二层是各种Namespace，包括Network Namespace、Pid Namespace等，要突破这层需要的知识包括内核提权、Google Borg容器逃逸漏洞；第三层是CGroups主要是资源的控制；第四层是Capablitiy的权限控制，需要详细了解各种Capablity的特性，对Linux内核极其了解，第四层就是文件系统层，有账号的安全保护，需要寻找Linux内核的漏洞来进行权限提升；另外Google在RPC调用上也使用了类似强制访问控制的机制，对IP进行限制、调用方的权限进行严格限制、对RPC通信协议进行加密、进行微服务级的安全控制，想渗透整套系统的难度可想而知，需要大量的对抗经验，储备各种安全漏洞，对整个Google的系统非常熟悉，才可以进行艰难的横向移动和权限提升。如果尾随google员工进入办公网，会被检测客户端设备是否可信，看该设备不是公司发行的笔记本网络，或者它的证书已经过期，设备会被分配一个非常有限的访问控制权限的网络，同时后台被校验容许访问的api，权限是24小时。
安全乐观主义点评：Beyondprod的最佳参考对象是istio，全链路鉴权这里提到的euc tickets就是全程票据。建设的核心是alts，验证的身份由证书实现，证书通过titan提供，对应用是透明的，不存在窃取证书的风险。在后端服务的每次请求前，都会匹配service access policy是否符合权限模板。具体的逻辑为：实施多方授权（MPA）为敏感数据的请求作出访问决策；速度限制、与开源第三方目标系统的兼容性。隔离的逻辑是三个策略：统一物理和逻辑隔离架构，将物理安全和网络安全对应，在Google的生产环境中，类似于BeyondCorp的设计，生产服务之间的身份验证植根于基于每台计算机凭据的机器对机器信任中。Google的生产环境不会信任未经授权的设备上的恶意植入；隔离了加密密钥，之前的提到的titan，是容许在本地密钥上使用ACL，以防止远程攻击者解密数据。即使攻击者可以访问加密数据（通过内部破坏或渗透），也可以防止解密；时间隔离：尽快的替换密钥，即使它们没有被泄露。
安全乐观主义点评：GFE，可以参考google next 2020大会介绍的armor、anthos。注意核心的内部服务只鉴权，不加密，可能是基于性能考虑。自研的ssl实现，可以参考下Amazon的s2n。
安全乐观主义点评：alts ，可以看到笔者的上一个文章介绍从gRPC安全设计理解双向证书方案，这里谈到了很多架构设计的原则。BeyondProd的基础就是由alts是实现的，付出的代价是，谷歌必须维护一套复杂的，符合各个国家数据加密要求的，灵活调度全球idc服务的证书系统，如果证书有问题，也要具备降级能力。这个证书的体系是从主机硬件芯片到应用层各个协议都支持的能力。开发者不需要关系如何适配身份体系，如何加白，都是由数据权限（使用AWS或GCP Identity＆认证和授权决策的策略框架 访问管理类IAM产品）自动判断。
安全乐观主义点评：据说alts开始时，还没有tls1.3，所有更灵活，但是只能适用于谷歌内部。mTLS单独指双向 TLS 身份验证：即使用 mTLS 时，客户端和服务器（或另一个客户端）在 TLS 握手期间提供证书，互相证明身份。alts是具体的技术的实现。认证和鉴权方面，通过tls中的namespace认证身份。加密方面，证书天然的加密机制不再说。握手消息，不用隐藏对端通信服务的来源（虽然你有nmap扫描到了服务，但是不能建立通信）。密钥泄露伪装攻击是指获取了证书就可以冒充身份了吗？理论上是可以的，猜测谷歌还有别的访问模型进行安全管控。
安全乐观主义点评：运行公共信任的CA使用商业机构提供的HSM，采用nsjail隔离第三方代码，fuzz安全漏洞报告厂商。签发和认证时使用了多个独立的日志记录系统，通过逐个比较两个系统来确保一致性。
安全乐观主义点评：brogmaster是核心，攻击获取了master的私钥，就可以伪造发布的应用，所以定时更换。用k8s举个的例子：在一个应用发布时，master使用机器主私钥对一个docker进行签名，容许发布应用，master对一个应用镜像仓库创建主证书和私钥，获取签名。master验证docker是否有权限运行这个特定的应用镜像。发起rpc请求时，使用应用镜像的证书标识对外身份。这个例子中，master指代brogmaster，docker指代运行应用的客户端，应用镜像仓库指代workload。实现的效果是:只有经过brogmaster发布的可信的工作负载，才能运行在可信的客户端上。否则，这个客户端不仅仅运行不起来，而且对外通信会失败。
安全乐观主义点评：一、A和B两个微服务之间交互，a有accout为A_servie,B的account为B_service，二、双向认证策略mtls，只容许a访问B，不容许A访问C。三、同时mlts基于alts实现加密。四、每一步带上用户的票据，实现全程票据方案
安全乐观主义点评：传统的内部微服务之间，内网之间无防火墙acl，api网关方案也不可行。由grpc支持各个语言，无开发接入工作量。
安全乐观主义点评：业务团队职责：从个人、服务、资源维度合理审批、及时二次通知、审核、fido。安全团队职责：审计申请记录，观察异常服务调用，3FA
安全乐观主义点评：这里没有提如何进行完整性校验，传统的ak、sk通过摘要的方式验证一致性，证书可以通过公钥加密消息体，私钥+协商算法解析，从通信链路层实现rpc协议的整体加密
安全乐观主义点评：票据在mtls的rpc报文之间传递cuis是票据服务的核心，eut具备原始的认证授权信息，每个入方向的服务，用这个票去cuis验票，不需要鉴权则透传票据。contact服务解密eut，查看是否有地址簿数据权限，调用地址簿服务放回用户数据。解决的问题是：防止遍历：不能直接伪造大量的用户票据；防越权，每个下游服务都去票据服务中心获取授权；缩小攻击范围:B服务沦陷了，但是由于没有A阶段的票据，不能访问C的服务。不能解决的问题：重放攻击，因为票据是有有效的，除非有销毁机制；性能问题，验票环境是瓶颈；需要稳定性：ABC服务都需要支持票据能力，一旦一个环境丢票，用户请求就中断。极大的复杂性：ABC服务都有改造支持在rpc或者http协议中和票据中心有验票逻辑，cuis会有复杂的权限模板，模板要写清ABC各个环节需要的详细权限。
安全乐观主义点评：不要有这个BeyondProd的锤子就到处寻找钉子，不同的安全需求决定了组织所处的安全现状，对应不同的建设手段。
安全乐观主义点评：小编将持续跟踪，分享BeyondProd相关材料。
