=Start=
缘由：
在看云安全、企业安全相关的资料时看到的内容，之前可能看到了，但没怎么注意，今天仔细看了一下之后真的感觉阿里以及阿里云在这块的储备真的是很强，我需要学习、了解的知识还有很多！
正文：
参考解答：
在了解云安全架构之前，“云安全责任共担”，是一个必要的背景知识。
“云安全责任共担”简单来说就是云上的安全是由用户和云计算平台共同承担的。而具体的责任划分，用肖力的说法就是：云平台负责云基础设施层面的安全，用户负责虚拟化层以上的安全。
举个简单的例子，物业出租一套公寓给租户。为了安全，物业要保证门上的锁完全可靠，保证小区的保安尽职尽责；租户要保证自己保管好钥匙，出入注意锁门。
“云安全责任共担模型”已经被行业公认，企业云安全架构，也是建立在这个基础之上的。
下面看图：
下方的云产品安全、虚拟化安全、硬件安全、物理安全，归为云计算厂商的职责范围；上方的业务安全、安全运营、数据安全、网络安全、应用安全、主机安全、身份管理，归为用户的职责范围。
据了解，阿里云企业云安全架构采用“平台-用户”双层安全保障模式，涵盖业务、运营、数据、网络、应用、主机、账号、云产品、虚拟化、硬件、物理安全等11个维度共45个模块，将安全武装到了“牙齿”。企业可以根据这份指南搭建一个更简单、更智能的安全架构，确保生产效率，创造更多的价值。
在平台方面，阿里云打好了安全的地基；在用户层面，用户可选择阿里云全栈安全模块快速提升业务安全能力。
具体来讲,可分为三部分:
- 第一是硬件安全方面。做安全的人都知道，越往底层越安全，如果芯片能够提供安全功能，则可以说是最高顶级的安全保护。而这方面技术门槛非常高，且需要定制化。肖力对雷锋网表示，阿里云接下来会推出像芯片级加密的服务，直接在CPU在芯片里面提供直接加密的服务，做到足够的安全。
- 第二，云产品层面。对像ECS、OSS存储、以及RDS类似的产品，在出厂之前会进行整个安全的设计，包括安全框架以及代码安全，确保用户使用产品时是默认安全的。
- 第三，数据安全。肖力表示，数据安全最核心的一个点，是要做好加密。提出完整全链路的数据加密方案。数据链路的安全上来后，目前ECS支持整个存储盘的加密，对RDS支持整个透明加密，在存储方面，云产品支持全链路的加密。另一方面芯片级的加密，包括引入第三方的硬件加密机给用户提供更多更便捷不同安全等级的加密服务。
虽说上面内容中的“云安全架构”里的要点很简明，但是要把其中的每一项都做好且能做到相互联动，真的是非常非常难！！！
参考链接：
=END=
《 “阿里云-企业云安全架构” 》 有 14 条评论
基于通用技术的企业安全运营架构
https://mp.weixin.qq.com/s/WHhTZSf0JZK5KVH-o6NAoA
`
SANS网络安全活动标尺模型将网络安全建设投入及工作方向划分为五个阶段：架构、被动、主动、情报和震慑。
对于大多数传统企业（区别于安全企业和互联网企业）而言，经过一段时间的努力，都可以完成从无到有（架构）、从“救火”（被动）到正向建设（主动）的过程。处于这一阶段的企业，一般都具有了以下能力：
基本攻防能力：了解常见网络攻防技术，能够开展渗透测试。
威胁防护能力：对于常见网络攻击威胁，能够采用多种手段进行防护和监测，形成纵深架构。收集并运用威胁情报进行溯源分析和失陷检测。
安全运营能力：对安全事件完成闭环处置，形成有效的风险控制机制。
（四） 部署示例
1、 采用LVS/Nginx为集群化部署的工具进行负载均衡。
2、 采用Kubernetes为安全平台提供基础计算环境。
3、 采用ZooKeeper对安全工具策略进行统一管理。
4、 采用FileBeat采集并传输日志。
5、 采用Kafka作为消息队列接收日志。
6、 采用Flink对日志进行实时处理。
7、 采用Hive作为大数据存储。
8、 采用Logstash接收日志实时处理结果。
9、 采用ElasticSearch存储实时处理结果，并提供全文检索。
10、采用Kibana对ElasticSearch中的数据进行展现。
11、采用Redis作为缓存数据库，MySql作为主要存储。
12、采用Jira进行工单管理，对日志分析结果进行后续处置，与ZooKeeper对接，进行策略调整和下发。
13、本文主要对于企业安全技术架构转型进行讨论，故不进行工具层面的具体选型。
我的想法：
此篇文章虽然内容看上去大而全，也挺唬人，但实际在一个大的企业安全部门做过的话就会理解——纸上得来终觉浅，绝知此事要躬行。
`
主机的零信任安全实践
https://mp.weixin.qq.com/s/w70M07OCG70Kdcy7hdCXZg
`
零信任安全（Zero Trust）是以身份为中心进行访问控制的安全概念，其核心观点是不自动信任何访问者或设备,任何访问都应该进行认证、授权或者访问控制，以避免内网渗透等安全风险。零信任代表未来安全架构的发展方向，在本文中，笔者主要从主机领域分析零信任框架的落地与实践。
思考：如果没有零信任，我们将面临怎样的安全威胁？
场景1：东西向移动
解决主机间东西向移动的零信任架构是微隔离技术，微隔离从2016年开始连续三年入选Gartner 10大安全技术，其本质是基于主机agent的分布式防火墙技术，目标是解决进入云计算时代后安全边界模糊导致的防火墙策略丢失，以应对云计算时代的东西向流量防护。
场景2：应用漏洞利用
应对应用漏洞攻击的零信任架构，1，在内核层剥离应用过高权限；2，对在易受攻击应用中注入rasp应用运行时自我防护技术。
结束语：
主机是信息安全的最后一道防线，主机安全也必将成为零信任安全框架落地的重要构成。
`
【流沙】宜信安全数据平台实践
https://mp.weixin.qq.com/s/3TDt4veunLZkVpzRqvnd0A
`
OpenSOC是思科在BroCON大会上亮相了的一个安全大数据分析架构，它是一个针对网络包和流的大数据分析框架，它是大数据分析与安全分析技术的结合, 能够实时的检测网络异常情况并且可以扩展很多节点，它的存储使用开源项目Hadoop，实时索引使用开源项目ElasticSearch，在线流分析使用著名的开源项目Storm。
宜信结合自己的实际情况，同样实现了一套集采集、分析和存储为一体的安全数据平台——流沙平台。本文重点介绍一下流沙平台的架构，相比于OpenSOC做了哪些优化及改进的地方以及流沙平台在落地过程中的经验总结。
数据是安全分析的基础，有了数据以后，威胁情报、态势感知、黑客画像、业务风控、攻击溯源、攻击识别、资产发现都变得并非遥不可及。流沙平台结合宜信实际的场景，从效率、成本、功能三者之间综合考量，对OpenSOC进行了一些改良并落地。通过流沙平台，安全工作人员可以将大部分精力专注于数据分析上，弥补了商业安全产品的不足，更好的帮助安全防护同学全面的了解企业的安全状态。流沙平台不仅仅是一个数据平台，更是宜信现有安全措施的重要补充。
在流沙平台落地的过程中，我们发现了一些问题，并总结出了一套落地的方式方法。我们在这里分享出来，希望可以为各位提供一些思路。流沙平台并不完美，若大家有疑问或想法请联系微信:gaozhi8963，我们会积极改进，不断完善该产品。
`
对话行癫：解密阿里云顶层设计和底层逻辑
https://mp.weixin.qq.com/s/p0M36OV682FlyAT-13ogiQ
美团企业信息安全技术架构
https://mp.weixin.qq.com/s/xFk7spcOkuZYSAawH6hZAg
`
美团点评建立了纵深防御体系，从网络隔离、访问控制、入侵检测、病毒防护、漏洞检测、应用安全等方面抵御外界各种威胁，对产品和数据进行保护；并采用号码保护、数据加密、数据脱敏等多种隐私保护技术为用户的信息安全提供全方位保障。
大数据时代，由于网络活动的随意性、不确定性，用户隐私保护的难度越来越大，为此政府相关部门正在不断完善法律法规，加强监管力度。而作为为用户提供服务的主体，企业也应承担相应监管责任，为保护用户信息安全贡献力量。
`
云安全相关技术介绍（六）
https://paper.tuisec.win/detail/d1e4899eb52e190
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%E5%85%AD%EF%BC%89/
`
相关法规、标准和认证
云等保，GA/T 1390.2-2017
GB/T 31167-2014《信息安全技术云计算服务安全指南》
GB/T 31168-2014《信息安全技术云计算服务安全能力要求》
国家标准《信息安全技术 云计算安全参考架构》（征求意见稿）
国家标准《信息安全技术 云计算服务安全能力评估方法》（征求意见稿）
ISO/IEC 27001信息安全管理体系和认证
ISO/IEC 27000 系列标准
CSA-STAR
C-STAR云安全评估
CS-CMMI云安全能力成熟度模型集成
可信云服务
`
鸟哥谈云安全 – Google云安全趋势解读[简版]
https://www.sec-un.org/%E9%B8%9F%E5%93%A5%E8%B0%88%E4%BA%91%E5%AE%89%E5%85%A8-google%E4%BA%91%E5%AE%89%E5%85%A8%E8%B6%8B%E5%8A%BF%E8%A7%A3%E8%AF%BB%E7%AE%80%E7%89%88/
https://cloud.google.com/files/trusting-your-data-with-google-cloud-platform.pdf
`
Google的展台就展出了Cloud Identity和Cloud Armor从这点可以看得出来国外身份认证、DDoS、WAF需求最多；笔者觉得身份认证将会是下一个爆款产品。
在参加Google的两天线下交流时候，被一张Secure By Design: Google Infrastructure Tour的墙面吸引；
Google讲基础设施安全就四个点：
一个是全球的数据中心所有数据都通过GFE和使用了安全的网线，
第二个点是默认存储加密，所有Google Cloud Platform的产品使用默认存储加密策略，
第三个点是Titan芯片所有物理机上都安装了Titan硬件芯片，作为硬件可信信任根，
第四个点是数据中心安全主要是物理安全，进入数据中心需要生物识别和激光束入侵检测系统；
云平台服务提供商要根据自身的安全特点来对客户讲出最核心的安全能力：
AWS的安全能力是基础设施安全、数据保护、身份标识、检测能力、应急响应；
Azure的安全能力是透明（对客户数据保持透明的策略和承诺保障）、隐私（用户可以很好的控制数据而Azure云平台不会去看敏感的数据）、合规（查看满足合规要求的产品、解决方案、证书）和安全（保证客户的数据安全）四个关键词；
`
大型互联网组织安全产品研发与落地的一些方法与思考
https://www.freebuf.com/articles/neopoints/211400.html
`
二、组织开展项目研发前的准备工作
确定项目产出程度，即投入产出是否简单明了，我一般把项目分为复杂项目和简单项目，以下为个人经验作为界定，可能有误
复杂项目的特征:
1.安全产品需要公司多维度人员参与开发，如风控系统可能需要SDK，逻辑引擎，消息中间件平台，前后端多方面支持，可以拆分成多个微服务。
2.接入面积较广，可能成为不同业务线的接入。尤其大厂可能有不同的业务场景，都需要接入此系统，如比如直播搜索都需要接入此系统。
3.在生产流程上存在高危风险点，如分布式HIDS,WAF等在生产会侵入生产服务器进程或者流量转发流程，需要多维度配合。
4.项目的核心功能会超过20个接口以上的前后端耦合。
相对简单项目的特征:
1.管理流程类项目:项目仅侵入管理流程节点，并不会耦合业务与生产风险。
2.生产无侵入类项目:如日志分析类，蜜罐类相关的项目。
个人经验：简单项目可以采用全栈式开发的模式，即1-2个具有安全背景的研发工程师完成相关的工作即可。一旦出现复杂项目的特征，需要慎重考虑是自研还是购买第三方产品，下文的人员配比会详细的解释原因。
三、复杂安全项目的全流程闭环
3.1 复杂项目的全流程闭环
3.2 自研人员到岗顺序
1、产品与PMO第一到位：负责产品需求的调研，业务线访谈，需求整理收集。
2、架构师或资深研发工程师的到位——他们主要的是针对于产品的需求进行技术选型和性能评估。
3、研发工程师的到位
`
云环境自动化入侵溯源实战
`
徐越(cdxy)，阿里云安全工程师，主要研究方向为安全数据分析与云环境攻防技术。
议题介绍：
随着云计算的大规模普及，公有云的安全趋势已逐渐从”监控已知漏洞”发展为”感知未知威胁”。一方面，客户的自研代码和独特的业务场景带来了个性化的攻击面；另一方面，黑灰产的武器库日趋成熟，其中不乏未披露的漏洞攻击手段(0day)。传统漏洞情报驱动的应急响应已经不能适应云环境复杂的攻击形态，如何在入侵后自动定位攻击源以及入侵原因，已经成为云环境威胁检测技术的重中之重。
本技术正是基于上述背景，结合多种云产品日志，通过大数据分析引擎对数据进行加工、聚合、可视化，形成攻击者的入侵链路图。该方案完全自动化，不依赖漏洞先验知识，具有0day识别能力。便于安全运营人员在最短时间内定位入侵原因、制定应急决策。
在本议题中，我们首先通过数据描述公有云威胁形态，之后将阐述基于统计和实时图计算的自动化入侵溯源方案，并通过真实案例展示其效果。
`
http://vipread.com/library/item/2454
https://github.com/knownsec/KCon/blob/master/2019/25%E6%97%A5/%E4%BA%91%E7%8E%AF%E5%A2%83%E8%87%AA%E5%8A%A8%E5%8C%96%E5%85%A5%E4%BE%B5%E6%BA%AF%E6%BA%90%E5%AE%9E%E6%88%98.pdf
百度工程能力白皮书 – 工程标准 V1.0
https://developer-bos.bj.bcebos.com/百度工程能力白皮书-工程标准V1.0.pdf
云安全的未来
https://mp.weixin.qq.com/s/MfjRfJ04fnRY8gI5s6BA8g
`
# 云安全的主流产品
云安全产品可以从两个方面进行分类，一方面是云计算提供方直接提供的安全产品，另一方面是第三方提供的安全产品。前者也叫云计算服务方原生安全cloud native security，这里指的是云厂商配套云服务提供的安全产品，跟下文提到的cloud-native security还是有区别的，后者指的是适配云原生服务（容器、微服务等）的安全产品，注意区分。
…
# 总结
笔者先从云安全市场的趋势来说明云安全市场发展速度是跟着云计算的发展速度蓬勃发展，然后介绍了一些云安全的主流产品，包括了云计算提供商自身提供的安全产品和生态以及主流的第三方安全产品CWPP、CASB和CSPM。然后，提到了在SD-WAN的推动下基于云的安全产品SASE，最后说到了云原生安全这个全新的话题，云原生也是一种软件开发和交付在云计算环境下的变革，所以相关的安全解决方案也需要提前考虑。本文主要关注了云安全的未来一段时间内的发展方向，这些内容已经在国外有落地，根据国内的发展情况可能会有差别，或者会发展到另外的一种状态也未可知，但是也会有一定的参考价值，毕竟IT技术的发展还是比较一致。
`
Twitter前首席安全官谈云安全
https://www.mgclouds.com/archives/10414
混合云实践中那些让甲方痛点的问题分析以及如何让云更安全？员工移动安全实践探讨等 | 总第153周
https://mp.weixin.qq.com/s/aLstCwIKcUjhPjyjaoWvOw
`
0x1 本周话题TOP2
# 话题1：咨询下，有使用腾讯云混合云并集中做态势感知的么？（把公有云的日志同步到本地集中感知）目前发现腾讯云没有实时告警的接口（如阿里云提供消息队列可以实现实时），只有离线下载模式，就很难受。
上次讨论如何接阿里云，好多大佬从使用者角度给出各种姿势，受益匪浅。售后侧给的回复有3种方式，都有在对接哈，就是尝到甜头了，想看看大家还有没有什么好用的姿势？
A2:我觉得云的最大风险在于配置不当，传统网络和云有着路线上的不同，没有云最佳实践经验就去迁移很容易出错，而且不同云的“默认安全”底线或者说放权程度还不尽相同，但你要追究起责任来，云可没什么责任，是你自己没在几百页文档里找到自己那个需求的加固配置罢了。
Q:赞同。这块安全基线检查，目前不太好做是吧？大家一般怎么处理呢？
A3:是的，在业务的便利性上与安全性上，大部分业务会选择便利性。安全性要投入 又不赚钱，所以很难受。出一版本已知风险加固，然后慢慢踩坑迭代。听说阿里云官方会出一版本安全加固基线。
A4:就是Gartner报告里面云原生安全解决方案之一cspm（其它是cwpp和casb），cspm有开源也有商业化，还有云服务商自带的。
上家公司用过国外知名的2个，最近正好重新调研一下，发现传统的国外开源产品就不错，美中不足就是只支持aws、gcp、azure这些。国内的某开源堡垒机厂商也有号称开源的cspm，支持国内云，不过结果貌似一般，而且好久没人更新。国外的几个知名开源背后都有商业化公司支持，更新和技术能力有保障。不差钱就使用云服务商原生的，或者使用开源支持自定义的，方便多云管理。
A5:我们是统一出个云基线，从严。有的云默认安全了，就查一下，不用配置。但是这个还要时间与攻防演习检验。
这个我个人一直觉得很扯。用你的产品。你也知道怎么配有风险。但是这个风险提示要花钱，不问就发标准文档，问漏洞就发加固文档，不买就由着你配错受损失，赚的黑心钱。
A7:4年前收集安全事件案例的时候，AWS存储桶未授权访问的问题每周都有，都麻了。即使研究出了成功的方法，人们还是做不到成功。
A8:说默认安全，但是貌似也没有做到默认落地就安全，说白了安全还是没有那么的重要。
A9:建议对云上不同模型下的云安全责任共担好好研究下，不是上云了就都是云服务商的安全责任，上云不仅是技术改变，更是观念需要改变。
基本上所有默认都是从方便用户使用角度考虑的，微软的产品就是例子，厂商不会自己为难自己一开始就设置最安全影响用户体验。而且很多情况下云服务商没办法替用户判断，比如你安全组的22端口就是对所有IP都开放，背后可能有合理的业务理由，服务商不能禁止用户这么做。
其实在我看来，cspm是重要但是不一定需要花费太多成本（尤其是钱）的地方，有专门工具定期检查，定期发现有人为操作造成的安全风险及时解决就好。国外细分赛道厂商就做得很极致，实时监控，发现误配置就发slack告警，和咱们国内与企微、钉钉类似。cspm别看被Gartner列为三大云原生安全技术，技术门槛比cwpp低多了，这块大家有足够重视就好，但是云上还有很多安全风险。
A10:我理解是不是需要一些云安全建设的最佳实践，由云厂商整体来提供一些解决方案，这里不仅指的是安全相关，还有整个云建设最佳实践。目前看如果云安全的建设阶段没有规划好，那安全到后面就仅能在现有的架构上进行修修补补，而非从根本上去解决问题。
过去我看到的是，很多企业上云（公共云、混合云、私有云），因为对云本身提供的一些便利和架构不熟悉，所以很多都是边摸索边建设，建设的也是五花八门，更多是依赖过去一些经验还有线下的一些经验来建设，只是用了云，但是没有用好。就拿一个ak/sk来说，对于ak/sk的管理都是一个很复杂的问题。
Q:想问问这个基线检查是基于等保的标准还是？
A12:云资源、账号、身份、权限、访问控制的配置检查。攻防实战标准。分两个视角，攻击者视角和合规视角，基于场景把内容和策略做区分，混在一起完全是灾难。安全最佳实践还是得基于真实风险危害来搞，并且得做风险的验证后再推风险结果，不搞假设。
A13:混在一起确实是灾难， 基于攻防实战标准已经不仅仅是基线了。
A14:比如，网络管带宽，系统申请虚拟机带NAT，安全配了ddoswafhidsips，都合规了，在攻防面前都没用。
Q:现在不是CNAPP概念了吗？
A16:对，现在Gartner的最新报告把cwpp、cspm和casb整合为cnapp了。咱们甲方看清技术本质、把握主要风险，与时俱进就好，也不必执着或迷信于这些术语。
A17:仅代表我个人总结：
甲方：主要盯“动作”，看“方向”，清“本质” ，即某个攻击动作是什么？攻击链路的下一步有哪些或阻断其中关键步骤，清晰某个问题或者技术的本质。
乙方：主要盯“思路”，看“算盘”，清“资产” ，即完整的攻击思路，如何把漏洞与漏洞之间窜连成完整攻击链，或以漏洞的串联加大提升漏洞的危害度，深入了解目标的资产情况，边界情况，供应链情况等。
乙方进阶：清“本质”，避“动作”，看“盘子” ，即深入了解攻击本质，避开连续性动作特征，把控全盘节奏。
甲方进阶：清“思路”，盯“细节”，看“特征”，即清楚攻击或者漏洞利用的思路，盯住关键攻击细节，阻断某个环节或某几个关键，增加攻击成本，增强防守时间，了解其中关键特征。
# 话题2：请教下，给一般员工的移动安全宣传，除了通用的安全意识（比如口令 锁定 备份 安装软件 联网 不要越狱开发模式等等）事项提醒外，会推荐安装 某些安全类软件（如杀毒软件）吗？如果有的话，有哪些？
A1:杀毒软件，桌管软件，备份客户端。
Q:安全软件不是必装么？为啥是推荐安装？
A2:没有纳入统一管理。没法必装，但要做些宣传，可能需要推荐些手机安全软件 （看应用市场也不少 ） 如果担心违反群规 麻烦私发我哈。或者直接用有些手机自带的？
A3:手机装安全软件没有必要吧，现在所谓的安全软件也只有垃圾清理的功能。
A4:我最近刚好在测手机端的安全软件，目前觉得不是很有必要安装。终端edr的功能，手机版。但是感觉没必要，一般手机也遇不到这种攻击。因为员工手机中毒导致的风险，感觉是蛮可控，目前没遇到过。
A5:感觉还是有用的，比如安装提醒，有些下载自动安装软件。
企业版的安全软件也可以批量做一些管控，但目前有些公司入职是要求手机安装管理软件的。
A6:现在好像除了保密部门配的专用手机，一般员工自己的手机不会装那些东西了吧。
毕竟手机和办公电脑不一样。手机是属于员工私人物品，办公电脑是属于公司资产。不能在员工的私人物品上面去强制安装一些东西吧。
这就涉及到隐私的问题了，可以从员工私人手机连入公司网络的wifi和流程层面来把网络给剥离开公司的办公网络。特别是现在00后员工出现了，简直就是来整顿职场的。
A7:我们是私人走一个网络，办公走另一个。
A8:企业大家会觉得会监控隐私，我们这边pc装杀毒软件都有人质疑会监控隐私。更难提手机版了。很多人对装杀软是很抵触的，怕卡、怕破解盗版软件用不了。我前几个月在公司内部推，各种宣传，2个月时间也就安装了55%左右，然后就推不动了。还是要自上而下
A10:本来想通过准入来强推杀软的，结果推了一圈，发现准入不敢开。
A11:安全本身很多要求是反人性的，挨骂或者说有意见是正常的。但是能让大家都乐意接受，那就是水平了。是不是可以对员工群体进行划分，一类用手机办公接触公司数据的对应什么解决方案，一类不接触公司数据的那就没必要装了。
A16:这事其实责任很清楚的。如果移动端要管，参考PC端，公司出钱购买并预装，领用前事先声明，并要求签署文件，这样就行。既要管，又不愿意购买终端和缴费，这事推不动才是正常。
`
加强监控以检测针对Outlook Online的APT活动
Enhanced Monitoring to Detect APT Activity Targeting Outlook Online
https://www.cisa.gov/news-events/cybersecurity-advisories/aa23-193a
`
一般云缓解措施 (GENERAL CLOUD MITIGATIONS)
CISA 和 FBI 建议关键基础设施组织实施以下措施来加固其云环境。尽管这些缓解措施无法阻止此活动或相关活动（行为者利用受损的消费者密钥），但它们将减少针对云环境的不太复杂的恶意活动的影响。注：这些缓解措施与CISA的SCuBA技术参考架构（TRA）一致，该架构描述了安全服务和能力的重要组成部分，以确保云业务应用程序（包括托管应用程序的平台）的安全和加固。
1. 应用CISA推荐的Microsoft Defender基线安全配置(为Office 365、Azure Active Directory、Exchange Online、OneDrive for Business、Power BI、Power Platform、SharePoint Online和Teams等应用)
2. 职责分离，将管理员帐户与用户帐户分开。仅允许指定的管理员帐户用于管理目的。如果单个用户需要其工作站的管理权限，请使用不具有其他主机管理访问权限的单独帐户。
3. 收集和存储安全云访问（SCA）解决方案、端点解决方案、云应用程序/平台和安全服务（如防火墙、数据丢失防护系统和入侵检测系统）的访问和安全日志。
4. 使用遥测托管解决方案（如SIEM解决方案），汇总日志和遥测数据，以促进内部组织的监控、审计、警报和威胁检测活动。
5. 审查与所有云服务提供商（CSP）的合同关系，确保合同包括以下内容
客户认为适当的安全控制。(Security controls the customer deems appropriate.)
对供应商管理的客户系统进行适当的监控和记录。(Appropriate monitoring and logging of provider-managed customer systems.)
对服务提供商的存在、活动以及与客户网络的连接进行适当监控。(Appropriate monitoring of the service provider’s presence, activities, and connections to the customer network.)
通知确认或可疑的活动。(Notification of confirmed or suspected activity.)
`
Secure Cloud Business Applications (SCuBA) Project
https://www.cisa.gov/resources-tools/services/secure-cloud-business-applications-scuba-project
http://www.cisa.gov/sites/default/files/2022-12/SCuBA_TRA_RFC_EG_508c.pdf