ASPIRE

各厂商安全白皮书收集整理

=Start=

缘由：

遵循最佳实践，向最佳案例学习，是快速提升的不二法门。

正文：

=各厂商云安全白皮书=
顶级梯队：

Google 基础架构安全设计概述
Google架构安全白皮书

AWS 安全最佳实践
https://aws.amazon.com/cn/security/

Google云安全 vs AWS安全
https://kinsta.com/blog/google-cloud-vs-aws/#security

一级梯队：

Azure 安全性白皮书

阿里云安全白皮书
阿里云安全白皮书都有哪些重要内容？

腾讯云安全白皮书

华为云安全白皮书

二级梯队：

京东云安全白皮书
https://www.jdcloud.com/cn/service/trustedCenter

金山云安全白皮书

UCloud 云安全白皮书

=

 

=数据安全白皮书=

大数据安全白皮书

华为云数据安全白皮书

腾讯云数据安全白皮书

阿里云信任中心

IBM数据安全防护白皮书

 

=END=

Docker

,
, ,

《 “各厂商安全白皮书收集整理” 》 有 21 条评论

  2. 鸟哥在Google云访问后的收获整理：
    `
    1、集中化是云安全产品大方向：Google安全产品跟其他产品例如负载均衡集成是趋势，逐步来看Google发布的Backstory
    以及Azure发布的Sentinel都是在往这个技术趋势和方向走，当然也包括AWS Security Hubs；
    2、云上IDaaS目前都已经进行成熟发展期，AWS、Google、Azure都已经完成产品化；
    3、生态解决方案逐步清晰完整，云厂商需要需要布局混合云终端安全、数据安全、网络安全、应用安全综合解决方案：Google今天邀请了几家合作伙伴MSSP（云上Hunting、检测服务、托管SIEM）、数据保护（因为AWS S3、Google Budget都存在一些安全问题，所以推出了混合云数据安全方案）、WAF、合规、漏洞扫描都非常贴近云上客户的真实需求；
    4、生态集成Google生态跟WAF合作模式是Armor进行规则管理，云厂商的自身的产品要跟生态找到最好的匹配模式，Google是提供了规则模型来配合生态合作伙伴的WAF，安全生态要找到平衡点；
    5、针对Cloud Native的攻击会越来越多：针对云平台的攻击逐渐增多例如k8s，目前很多平台收到了攻击，云厂商需要重点关注这个技术攻击趋势；
    6、云基础设施安全需要提炼最关键对客户最重要的点：Google讲基础设施安全就四个点，一个是全球的数据中心所有数据都通过GFE，第二个点是默认存储加密、第三个点是Titan芯片，第四个点是数据中心安全；云厂商要推出最关键的点，这些最关键的点都是保证客户最关心的技术，例如默认加密等策略，而且还是解决关键问题的点；
    7、DDoS、WAF、身份认证是收入主要来源：Google在展台就展出了Cloud Identity和Cloud Armor两款产品最多看来客户需求最多，国外身份认证和DDoS、WAF需求最高；
    `
    可能取代SIEM的PB级遥测数据平台：谷歌发布Backstory
    https://mp.weixin.qq.com/s/ArLDHSRxLk_lF99F5A7O3w
    https://go.chronicle.security/hubfs/Backstory_WP.pdf

    回复

  3. AWS安全笔记|扯淡与权限
    https://mp.weixin.qq.com/s/jtloGx9L8GXzkRHNkkwFqw
    `
    1.1 碎碎念

    这篇文章是我乱七八糟的想法，实践，扯淡，别人那看到的，听来的等等玩意堆积起来的结果。理论的理论说，所有试图大一统的理论最终都变成了分类，而我努力一下让这篇文章看起来不那么像分类，虽然起名叫云安全，不过主要讲的应该还是AWS。

    要论述云这么庞大的产品中的安全体系，首先要谈论的也许是这个产品，或者这个公司，团队的原则，或者说他们的产品假设，或者说他们的公司理念。

    有些人说AWS的产品是基于某些原则做的，或者基于某个竞对，或者出于某个团队的野心和KPI的不饱和。但严格来说，现实世界的产品并不是这么单调具有一致性的事物。每一个产品都对应着所属团队，公司内在的环境，外在的环境，一个集体的世界观的某种形式的糅合，在填上一些随机性的因素。

    另一层面的原则来说，基于某种美好的安全理念在现实中设计出来的产品，能达到40%的状态通常已经可以算作及格分了。

    这个系列文章分为四个。
    《扯淡与权限》
    《数据与加密》
    《检测与响应》
    《服务与体系》

    综上所述，这是一堆草稿。

    1.2 云平台安全产品
    1.3 关于原则
    1.3.1 Serverless
    1.3.2 多路径（赛马机制）
    1.3.3 最佳实践

    关于权限
    2.1 前言

    2.2 权限管理模型
    2.2.1 多账户模型
    2.2.2 多用户模型

    2.3 IAM简介
    2.3.1 IAM 用户，组
    2.3.2 IAM 策略
    2.3.3 角色

    2.4 其他云
    2.4.1 Aliyun
    2.4.2 GPC

    2.5 其他公司（Netflix）
    `

    回复

  4. 云安全相关技术介绍（一）
    https://www.sec-un.org/%E4%BA%91%E5%AE%89%E5%85%A8%E7%9B%B8%E5%85%B3%E6%8A%80%E6%9C%AF%E4%BB%8B%E7%BB%8D%EF%BC%88%E4%B8%80%EF%BC%89/

    云安全相关技术介绍（二）
    https://www.sec-un.org/%E4%BA%91%E5%AE%89%E5%85%A8%E7%9B%B8%E5%85%B3%E6%8A%80%E6%9C%AF%E4%BB%8B%E7%BB%8D%EF%BC%88%E4%BA%8C%EF%BC%89/

    云安全相关技术介绍（三）
    https://www.sec-un.org/%E4%BA%91%E5%AE%89%E5%85%A8%E7%9B%B8%E5%85%B3%E6%8A%80%E6%9C%AF%E4%BB%8B%E7%BB%8D%EF%BC%88%E4%B8%89%EF%BC%89/
    https://paper.tuisec.win/detail/58fa3db265329c8

    回复

  5. 京东云发布《数据安全白皮书》，恪守“不触碰用户数据”承诺
    https://mp.weixin.qq.com/s/J0SgWM6nICpTnTJC_CWbBA
    https://jdcloud-marketing.s3.cn-north-1.jdcloud-oss.com/WhitePaper/JD-Cloud-Data-Security-WhitePaper.pdf
    `
    近日，京东云正式发布《京东云数据安全白皮书》，宣布以“让云端数据更安全”为目标，以及“尊重数据主权不碰用户数据，提供安全保障保护用户数据安全，保护隐私对用户透明可信”的理念。

    # 完善的数据安全防护体系
    京东云以满足合规监管要求和保障用户安全的处理云上数据为出发点，严格贯彻数据安全治理的执行要求，结合积累的云安全实践及安全运营保障经验，对数据全生命周期的数据生产、数据存储、数据传输、数据访问、数据使用、数据销毁各阶段应用不同安全措施，配合京东云全流程数据安全保护体系，提供系统化的安全防护，并通过友好的操作界面和接口，方便用户使用与集成，满足不同行业用户对数据安全的个性化需求。

    # 强力的安全运营管控
    京东云打造集安全监测、安全预警、安全响应、安全运维为一体的云数据安全保障体系，动态协同多种安全防御措施，及时获知最新网络安全动态、安全情报，并在第一时间处理相关安全事件，保证平台的安全稳定，实现保障用户数据安全核心目标。
    `

    回复

  6. 阿里钉钉张作裕：由内而外，以数据安全赋能业务
    https://www.freebuf.com/articles/people/204711.html
    `
    做安全就像是练功，只有死磕到极致，才能求得正果。在张作裕看来，企业安全建设还是需要围绕安全三要素“发现”、“阻断”、“复盘”，深耕体系和规则：丰富发现能力、提升阻断能力、增强复盘能力，这是第一步，风险及威胁的感知是建立在基础能力可以充分依赖的平台上完成的。对于自身产品，在未来的攻击趋势上的变化要有充分的准备，用户与系统的交互应该像人与人对话一样，礼貌地拒绝和不接受妥协也能做出态度强硬的安全产品。

    很多系统建设的初级阶段，用户对产品的数据需求是较为一致的，基本围绕在系统主要或核心功能周围，数据能够产生的风险也在基本的传输和存储上。但随着用户角色的增加，产品上出现了管理者，且管理者也是用户的情况下，不难想象针对管理者的数据安全需求也可能成为他所在组织的安全需求，部分需求甚至有可能矛盾。在此基础上，如果再出现新的业务角色如开发者，对于使用用户权限、使用管理者权限、使用平台权限等需求时，就会产生非常多的交叉风险。而往往这些风险是最容易出现数据透出的地方，不同的存储环境和不同的传输环境让用户、管理者、开发者的数据安全没有得到基本保障。

    针对钉钉的安全痛点，张作裕透露他们的做法是通过将数据的存储和传输进行规范化治理，保证了数据在存储和传输上的基本要求，在开发者业务应用不出问题的前提下，良好的数据存储及传输管控是保障ISV数据安全健康度的基本能力。

    很多时候我们感知到隐私数据疑似被恶意使用，大部分还是源于软件对于隐私使用和授权还不够清晰，没有说明白为什么使用就去调用，这是让用户觉得自己的隐私使用的授权权力被剥夺。除此之外，钉钉在开放平台的探索也在一直进行中，随着钉钉开放平台能力的逐步升级，绝大多数企业希望通过开放平台对接自己的系统，但不少企业系统存在着多多少少的漏洞和设计缺陷，在与客户的合作中，我们深深的发现这类问题不在少数，钉钉除了标准化开放能力外钉钉安全也在帮助企业内部系统尽可能多的修复问题。

    张作裕认为数据安全仍然会是安全行业里占比较大的一个热点，而且随着事件、技术的发展，未来对数据的定义也会更加明确。数据的归属、使用都会在未来发展中逐步标准化。新技术带来的风险主要是在IoT安全上，未来设备数的累积、宽领域的应用，会让IoT能够产生的威胁从量变到质变。

    信息安全未来的路还有很长一段要走，业务形态的变化越来越多，对信息的收集欲望也越来越强烈，从业务角度来讲，越多的专属信息意味着越多的定制和更好的服务。安全上保证数据的使用规范，保证数据的归属权，控制好数据的使用权，是一条难走又必须走的路，安全人的工作已经和数年前的防御者不同，已经走向前台，走进业务，已经在公正独立的思考下帮助企业业务发展了。
    `

    回复

  7. 鸟哥谈云安全系列-AWS安全月度总结（5月）
    https://www.sec-un.org/%E9%B8%9F%E5%93%A5%E8%B0%88%E4%BA%91%E5%AE%89%E5%85%A8%E7%B3%BB%E5%88%97-aws%E5%AE%89%E5%85%A8%E6%9C%88%E5%BA%A6%E6%80%BB%E7%BB%93%EF%BC%885%E6%9C%88%EF%BC%89/
    `
    一、AWS对外PR以及峰会
    Security Best Practices Workshop – AWS Summit Sydney
    AWS之前宣传云安全架构的方法论是分成了五大块，五大块分别是标识（AWS IAM、AWS Organizations等）、检测控制（GuardDuty、、VPC Flows等）、基础设施安全（AWS WAF、AWS VPC等）、数据保护（AWS HSM、AWS KMS、Macie等）、应急响应（AWS Config Rule、Lambda）这套体系，而本次悉尼峰会，AWS再此基础上又进行了一次抽象，分成了Preventative（预防）、Detective（检测）、Corrective（纠正）。AWS的五大块和PDC的关系分别是：标识对应P预防、检测控制对应到D检测、基础设施安全对应PD预防和检测、数据安全对应到PD预防和检测、响应对应到C纠正；可以看出AWS在不停的完善和总结和迭代自身的防御体系思考；

    Finding all the threats: AWS threat detection and remediation – SEC303 – Chicago AWS Summit
    AWS的输入源包括了AWS CloudTrail（用来跟踪用户活动和API的使用）、Flow Logs（在VPC内部的网络接口的进出流量Flows）、Amazon CloudWatch（监控类产品）、DNS（VPC内部使用DNS解析器解析的DNS），这些数据源涵盖了云产品API的用户调用、VPC内的Flow Logs、VPC的DNS日志等，从整体上来看还缺少系统层的数据、VPC流量的数据（Azure支持）；也就是说从目前的角度来看，AWS还是存在着一些检测的盲区，例如针对Hadoop、Redis、Mongodb等的入侵分析检测模块。

    下面这张图比较完整的针对AWS GuardDuty的检测能力进行了详细的分析，GuardDuty检测的模式包括RDP暴力破解（网络检测模型、恶意IP地址）、RAT安装（连接黑名单站点、异常基线端口）、数据提取（DNS通道）、使用凭证访问云平台（临时凭证关闭实例等异常、调用方检测）、尝试获取账号（挖矿、新建实例）；做好云上的威胁检测，一定要对云上的资产绘制资产地图，从资产地图来反推威胁，根据威胁来做对应的检测规则的模式，让云上安全要更贴近云上用户的真实场景；

    Delivering applications securely with AWS – SVC303 – Chicago AWS Summit
    AWS在推广Private Links方案，目前接入的产品有22+（EC2、API Gateway、SNS、ELB API）等；通过PrivateLink方案可以很好的把API的访问收敛到VPC内部，这样的话快速收敛攻击面，目前竞品涵盖的包括Google VPC Service Control，VPC访问控制也是Google首先推出来的；

    Deep dive on security in Amazon S3 – STG304 – Chicago AWS Summit
    一张图讲清楚了S3提供给客户的安全Features,让客户快速能理解和选择适合自己的防护控制，S3主要是数据存储类服务，S3的安全Features罗列的逻辑主要是从CIA角度，机密性、完整性、可用性角度再加上身份认证维度来讲的，通过一个产品的安全Features罗列出来所有背后跟这个产品相关的能力，让客户从全局视角能看到云产品的价值。

    S3的最佳安全事件包括账号层面（锁定默认Public访问）、默认加密策略（默认开启SSM-KMS）、Bucket策略开启TLS链路加密、网络层面（开启VPC Endpoint访问）、合规需求（Object防止删除策略）；

    Using automation to drive continuous-compliance best practices – SVC309 – Chicago AWS Summit
    AWS使用自动化来做合规的最佳实践检查，这个也从侧面证明了AWS内部也会具有这个能力，通过自动化驱动合规检查、不安全的配置项的自动化回滚等，例如有人修改了默认基线就会通知Lambda来进行自动化的回滚操作，保证合规保持在一定比较安全的水位；

    Safeguarding the integrity of your code for fast, secure deployments – SVC301 – Chicago AWS Summit
    AWS使用这张图来讲清楚了IPDRR对应安全域的保护能力，把IPDRR和安全域防御进行了整合，一目了然的清楚安全域属于标识、预防、检测、响应、恢复的哪个阶段；

    二、AWS本月新增产品Features

    三、AWS本月更新
    1、AWS的访问控制力度越来越细；目前AWS正在横向推动IAM+ABAC的访问控制策略，提供更细粒度的控制；

    2、AWS在数据库层面开始逐步放开数据库的实时活动数据流，之前都是客户下载备份文件进行数据库的合规检查，现在结合自身安全生态快速的满足客户的安全和合规需求，同时也增加了相关的收入；

    3、AWS本月的对外宣传上有更新了IPDRR+PDC的模型，让传统线下用户可以更加了解云上安全防御对应线下的哪些能力，这块是需要增强线下客户的宣导能力，让客户理解云上的安全防护能力和线下有哪些相同的点和不同的点，让客户快速对云环境有个认同感；

    4、包括默认EBS进行加密、默认存储加密等；默认加密成为了各个云逐步发展的重要安全趋势；

    5、从本月观察来看，默认实时的日志输出也成为了AWS的一个重要的推广战略，另外实时输出之后结合CloudWatch+第三方的安全生态厂商进行安全分析；

    6、在合规上，AWS又进行了深入的研究，例如针对数据库类的API进行FIPS 140-2的TLS卸载会话，让合规涵盖到了API这个层面，让更多的HIPAA用户可以放心的上云，说服这些高敏感数据的用户迁移上来，拥有高敏感数据的客户如何让他们上云放心，也是一个重要的安全体系不断持续的灌输客户，是一个安全感的体现；

    7、AWS除了给客户SQL日志的审计之外，也开放了服务器的部分日志审计功能，这个是在增强客户的安全感，让客户可以针对SQL服务器上的日志进行审计，安全感的方法就是让高安全等级客户看见更多，当然对技术能力要求要提出了更高的挑战；

    8、上云过程中的安全也是一个重要考虑的事，而身份认证是上云间比较重要的防护手段；

    9、AWS正在横向推动SOC的合规的云产品；
    `

    回复

  8. `
    IPDRR:
    Identify (Security fundamentally anchors on having sufficient knowledge of your world)
    Protect (The best defense is an offense)
    Detect (However, one must “assume breach” and have a strong defense)
    Response/Recover (Knowing and being able to act swiftly is key in the cloud)

    标识（因为安全从根本上来说基于你对你的世界有多了解而定）
    保护（最好的防御就是进攻）
    检测（然而，你必须“假定一定会被攻破”并有一个强大的防御）
    响应/恢复（了解并能够迅速采取行动是云计算的关键）
    `
    https://www.slideshare.net/AmazonWebServices

    回复

  9. Security Best Practices Workshop – AWS Summit Sydney
    https://www.slideshare.net/AmazonWebServices/security-best-practices-workshop-aws-summit-sydney

    Finding all the threats: AWS threat detection and remediation – SEC303 – Chicago AWS Summit
    https://www.slideshare.net/AmazonWebServices/finding-all-the-threats-aws-threat-detection-and-remediation-sec303-chicago-aws-summit

    Delivering applications securely with AWS – SVC303 – Chicago AWS Summit
    https://www.slideshare.net/AmazonWebServices/delivering-applications-securely-with-aws-svc303-chicago-aws-summit

    Deep dive on security in Amazon S3 – STG304 – Chicago AWS Summit
    https://www.slideshare.net/AmazonWebServices/deep-dive-on-security-in-amazon-s3-stg304-chicago-aws-summit

    Using automation to drive continuous-compliance best practices – SVC309 – Chicago AWS Summit
    https://www.slideshare.net/AmazonWebServices/using-automation-to-drive-continuouscompliance-best-practices-svc309-chicago-aws-summitpdf

    Safeguarding the integrity of your code for fast, secure deployments – SVC301 – Chicago AWS Summit
    https://www.slideshare.net/AmazonWebServices/safeguarding-the-integrity-of-your-code-for-fast-secure-deployments-svc301-chicago-aws-summit

    回复

  10. 运营商大规模数据集群治理的实践指南
    https://mp.weixin.qq.com/s/C0eygTSdPhFKzHD1GcZk1A
    `
    一、集群治理的定位
    Q: 我以前听说过数据治理，你这里说大规模数据集群的治理，有什么具体差异吗？
    A: 好问题！不过要搞清楚这块，得先了解一下我们数据资产管理体系建设的实施路径——主要分三个子工程，同步开展实施推进：

    工程一：搭建核心业务数据治理框架，包括基础平台的建设、治理规范的制定，元数据管理、数据血缘和数据质量工具开发和应用实践，构建上层数据产品体系和数据能力开放平台，让数据多用活用，形成符合公司业务和组织协作特点的治理文化。

    工程二：实现全域数据计算集群的深度治理，完成全域数据治理元数据的自动化采集、存储和分析，构建数据能力开放平台多租户专项治理机制，沉淀数据治理中台能力，基于大数据集群底层核心组件（如YARN、HDFS）的深入洞察，孵化出数据集群治理的应用。

    工程三：完善治理机制体制建设，构建数据资产管理体系，并利用该系统的运营逐步重塑优化业务流程，实现可支撑全业务流程的成本评估机制，让数据价值持续攀升。

    四、集群治理的实施路径
    Q: 军哥，说了半天，你好像还没有告诉我，到底如何开展集群的治理工作呀？
    A: 不急，只要你明白了集群治理的定位、背景、目标，其实搞大规模数据集群的治理工作就没有那么难，按照以下8个步骤做就行：

    第一步：理清大规模数据集群的现状和治理需求点
    第二步：明确治理的组织架构、方法论、技术框架
    第三步：构建针对大数据集群的智能运维技术平台
    第四步：实现YARN作业&HDFS画像、小文件洞察
    第五步：实现NN RPC画像、关键Master服务预警
    第六步：实现冗余计算挖掘，以目录维度评估冗余度
    第七步：重构数据血缘、元数据、数据资产管理应用
    第八步：智能分析集群用户行为画像，检测预测异常
    `

    回复

  11. 阿里云SDDP（敏感数据保护）测试调研
    https://developer.aliyun.com/article/712628
    `
    海量数据的使用正在为企业创造越来越多的价值，与此同时，数据也正成为企业的核心资产；如何在对数据高效使用的同时，确保数据的安全，尤其是敏感数据的安全，是一个重要的安全课题，也是很多企业的核心诉求。本次对阿里云SDDP（敏感数据保护）产品进行了测试调研。

    测试过程中，了解到SDDP实现的功能主要包括：

    1.敏感数据识别：基于敏感数据识别规则，对使用阿里云产品服务中产生的数据进行分析，识别出其中的敏感数据和对应的风险等级。

    2.异常事件告警：从权限开放，数据流转和操作等方面对潜在的异常事件告警。

    3.数据脱敏：敏感数据从高安全级别区域/系统进入低安全级别区域/系统使用前，进行静态脱敏。

    4.其他增强特性：如API等。
    `

    回复

  12. 腾讯安全产品列表
    https://s.tencent.com/product/yunjing/index.html
    `
    # 终端安全
    终端安全管理系统
    零信任无边界访问控制系统
    主机安全
    反病毒引擎

    # 数据安全
    云加密机
    数据安全审计
    敏感数据处理
    数据安全治理中心
    堡垒机
    凭据管理系统
    密钥管理系统

    # 网络安全
    高级威胁检测系统
    样本智能分析平台
    DDoS防护
    云防火墙
    网络入侵防护系统

    # 安全管理
    安全运营中心

    # 业务安全
    借贷反欺诈
    风控平台
    营销风控
    注册保护
    登录保护
    验证码
    活动防刷
    保险反欺诈
    定制建模
    图片内容安全
    文本内容安全
    业务风险情报
    营销号码安全

    # 安全服务
    公共互联网威胁量化评估
    网络资产风险监测系统
    高级威胁追溯系统
    威胁情报云查服务
    代码审计
    网站渗透测试
    脆弱性检测服务
    应急响应
    安全咨询

    # 应用安全
    应用级智能网关
    漏洞扫描服务
    Web应用防火墙
    移动应用安全
    手游安全
    `

    回复

  15. Google Cloud 提供的安全产品
    https://cloud.google.com/security/products?hl=zh-cn
    `
    # 基础架构安全
    我们的基础架构具备安全强化、配置管理、补丁程序/漏洞管理功能，在设计之初便确保了安全性。
    * 云基础架构安全概览
    * 容器安全概览
    * 安全强化型虚拟机
    * Binary Authorization

    # 网络安全
    利用可定义并强制划定边界的产品来帮助保护网络安全，并实现网络分段、远程访问和 DoS 防御。
    * 虚拟私有云
    * Cloud Load Balancing
    * 传输加密
    * 应用层传输安全性
    * Cloud Armor

    # 端点安全
    借助设备安全强化、设备管理、补丁程序/漏洞管理功能，保护端点安全并防范入侵。
    * Chromebooks
    * Chrome 操作系统
    * Chrome 浏览器
    * G Suite 设备管理
    * 安全浏览

    # 数据安全
    利用数据发现机制，采取多种控制措施来避免数据丢失、泄露和渗漏，并实施数据治理计划，提高敏感数据的安全性。
    * 静态加密
    * Cloud KMS
    * Cloud Data Loss Prevention
    * G Suite Data Loss Prevention – Gmail
    * G Suite Data Loss Prevention – 云端硬盘
    * G Suite 信息权限控制
    * Cloud HSM
    * VPC Service Controls
    * G Suite 增强的网上诱骗和恶意软件防护功能
    * G Suite 第三方应用访问权限控制
    * G Suite 安全沙盒

    # 身份和访问权限管理
    管理并保护员工、合作伙伴、客户和其他身份，及其对云端和本地的应用和数据的访问权限。
    * Cloud Identity
    * Identity Platform
    * Cloud IAM
    * Policy Intelligence
    * Cloud Resource Manager
    * Cloud Identity-Aware Proxy
    * 情境感知访问权限
    * Managed Service for Microsoft Active Directory
    * Security Key Enforcement
    * Titan 安全密钥

    # 应用安全
    借助应用测试、扫描和 API 安全功能，保护和管理贵公司的应用。
    * Cloud Security Scanner
    * Apigee

    # 安全监控和运营
    监测是否存在恶意活动，处理安全突发事件，并为预防、检测和应对威胁的运营流程提供支持。
    * Cloud Security Command Center
    * 安全中心 – G Suite
    * 提醒中心 – G Suite
    * 数据区域 – G Suite
    * Access Transparency
    * Access Transparency – G Suite
    * Event Threat Detection
    * Cloud Audit Logs
    * Cloud Asset Inventory
    * 背景故事

    # 用户保护服务
    保证用户上网安全
    * Phishing Protection
    * ReCAPTCHA Enterprise
    * Web Risk API

    # 治理、风险与合规性
    支持管治与合规性流程，包括审核、风险评估、合规报告和认证。
    * 第三方审核与认证
    * Cloud Data Loss Prevention
    * Access Transparency
    * Vault – G Suite
    `

    回复

  16. [译] 云原生时代，是否还需要 VPC 做应用安全？（2020）
    https://arthurchiao.github.io/blog/do-i-really-need-a-vpc-zh/
    https://info.acloud.guru/resources/do-i-really-need-a-vpc
    `
    1. 需求分析：VPC 是可选还是必需？
    很多时候 VPC 只是可选项，而非必需。遗憾的是，很多工程师并没有理解到这一层。

    2. 利弊权衡：额外的责任而非超能力
    从安全的角度来说，VPC 非但不是一种超能力（superpower），反而是额外的责任 （additional responsibility）。
    确实，对于安全配置来说，越多并非永远意味着越好（more is not always better） 。如果你连配置 IAM 角色都还没搞熟，那又如何相信你能做好 VPC 安全？如果你连S3 bucket 的 public 属性都不清楚，那又如何确定你能管好安全组、ACL 以及 VPC 引入的 subnets？

    3. 云原生安全：模型抽象与安全下沉
    云安全太难了！但我显然不是在鼓励大家因此而放弃。相反，正是因为云安全如此困难且重 要（both hard and important），我才建议你不要轻易引入自己的网络控制方案，而 应该尽可能用好平台提供的安全能力。
    越来越多的职责下沉到了云提供商那里。你确实会失去一些控制能力 ，但换来的是 AWS 最佳实践的保驾护航之下，更快的应用构建速度。
    你可能会说，保护云原生应用的安全其实最后就是：“要么裸奔，要么上云”（letting go and letting cloud）。确实，但这种职责模型转变（paradigm shift）是传统的安全团队才需要关心的 ；对于用户来说，只需要用好这种优势，自然就会取得巨大收益。
    `

    回复

  17. 补充微软azure的安全白皮书：https://info.microsoft.com/GC-AzureMig-CNTNT-FY21-08Aug-28-AzureCloudSecurityWhitePaper-SRGCM3775_01Registration-ForminBody.html

    回复

  18. 微软azure的安全白皮书：https://info.microsoft.com/GC-AzureMig-CNTNT-FY21-08Aug-28-AzureCloudSecurityWhitePaper-SRGCM3775_01Registration-ForminBody.html

    回复

  19. 苹果「安全」网站更新，你的 iPhone、Mac、iPad 原来是这样被保护的
    https://www.ifanr.com/1402803

    Apple 平台安全保护
    https://support.apple.com/zh-cn/guide/security/welcome/web
    `
    Apple 平台安全保护介绍

    Apple 平台以安全性为设计核心。Apple 利用在打造优秀移动操作系统方面所积累的丰富经验，创建了可满足移动设备、手表、台式设备以及家居设备独特要求的安全性架构。

    硬件、软件和服务在每台 Apple 设备上紧密联系、共同协作，旨在为用户提供最高的安全性和透明的使用体验，从而实现保护个人信息安全这一终极目标。自定安全性硬件为关键的安全性功能提供了支持。软件保护保障了操作系统和第三方 App 的安全。服务提供了安全和及时的软件更新机制，建立了更安全的 App 生态系统，保障了通信和支付的安全，以及提供了更安全的互联网体验。Apple 设备不仅保护设备及其数据，还保护整个生态系统，包括用户在本地、网络上以及使用互联网核心服务执行的所有操作。

    我们设计的产品在保持简单、直观和强大的同时，也很安全。而基于硬件的设备加密等关键的安全性功能不会因为误操作而被停用。触控 ID 和面容 ID 等其他功能让设备安全性变得更简单直观，从而增强了用户体验。由于很多安全性功能在默认情况下均处于启用状态，因此用户或 IT 部门无需执行大量的配置操作。

    本文详细介绍了安全性技术和功能如何在 Apple 平台中得以实现，同时帮助组织将 Apple 平台安全保护技术和功能与其自身的政策和规程相结合，从而满足组织的特定安全性需求。

    内容主要分为以下几个主题：
    • 硬件安全性和生物识别：构成 Apple 设备安全性根基的硬件包括安全隔区、专用 AES 加密引擎、触控 ID 和面容 ID。
    • 系统安全性：集成的硬件和软件功能，针对 Apple 操作系统的安全启动、更新和持续运行而提供。
    • 加密和数据保护：一种对用户数据进行保护的架构和设计。在设备丢失或被盗，或有未授权人员或进程尝试使用或修改设备时，能够保护设备上的用户数据。
    • App 安全性：软件和服务，提供安全的 App 生态系统并确保 App 安全运行且不破坏平台完整性。
    • 服务安全性：Apple 的服务，用于身份认证、密码管理、支付、通信以及查找丢失设备。
    • 网络安全性：针对传输中的数据提供安全认证和加密的行业标准联网协议。
    • 开发者套件： 安全私密的家庭和健康管理框架，以及 Apple 设备和第三方 App 服务功能的扩展框架。
    • 安全设备管理：允许对 Apple 设备进行管理、防止未经授权的使用以及在设备丢失或被盗时启用远程擦除的方法。
    • 安全和隐私认证：ISO 认证、加密验证、通用标准认证和涉密项目商业解决方案 (CSfC) 计划的信息。
    `

    回复

发表回复

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