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

=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=

声明: 除非注明,ixyzero.com文章均为原创,转载请以链接形式标明本文地址,谢谢!
https://ixyzero.com/blog/archives/4298.html

《各厂商安全白皮书收集整理》上有11条评论

  1. 鸟哥在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

  2. 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)

  3. 京东云发布《数据安全白皮书》,恪守“不触碰用户数据”承诺
    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

    近日,京东云正式发布《京东云数据安全白皮书》,宣布以“让云端数据更安全”为目标,以及“尊重数据主权不碰用户数据,提供安全保障保护用户数据安全,保护隐私对用户透明可信”的理念。

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

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

  4. 阿里钉钉张作裕:由内而外,以数据安全赋能业务
    https://www.freebuf.com/articles/people/204711.html

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

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

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

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

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

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

  5. 鸟哥谈云安全系列-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的合规的云产品;


  6. 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

  7. 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

  8. 运营商大规模数据集群治理的实践指南
    https://mp.weixin.qq.com/s/C0eygTSdPhFKzHD1GcZk1A

    一、集群治理的定位
    Q: 我以前听说过数据治理,你这里说大规模数据集群的治理,有什么具体差异吗?
    A: 好问题!不过要搞清楚这块,得先了解一下我们数据资产管理体系建设的实施路径——主要分三个子工程,同步开展实施推进:

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

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

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

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

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

  9. 阿里云SDDP(敏感数据保护)测试调研
    https://developer.aliyun.com/article/712628

    海量数据的使用正在为企业创造越来越多的价值,与此同时,数据也正成为企业的核心资产;如何在对数据高效使用的同时,确保数据的安全,尤其是敏感数据的安全,是一个重要的安全课题,也是很多企业的核心诉求。本次对阿里云SDDP(敏感数据保护)产品进行了测试调研。

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

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

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

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

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

发表评论

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