跳到正文Seminar Week 10 Summary · Jimmy Huang's BlogSeminar Week 10 Summary
本页目录· 77 条
ChatGPT 说›Learning Outcomes
本周 Seminar 围绕云安全（Cloud Security）展开，核心目标可以整理为：
理解安全（Security）在云计算中的含义：安全不是“绝对安全 / 不安全”的二元状态，而是与上下文、风险、资源和威胁模型相关的连续谱。
认识云安全为什么重要：它影响云服务提供商（Cloud Service Provider, CSP）与企业的信任、合规、成本和法律义务，也直接关系到 DevSecOps 方向的工程能力。
掌握常见安全威胁类别及其缓解方式，例如身份伪造、数据篡改、信息泄露、拒绝服务、权限提升、恶意软件、勒索软件和社会工程攻击。
理解云计算中的身份认证（Authentication）、授权（Authorization）、访问控制（Access Control）和审计（Audit）的关系。
理解共享安全责任模型（Shared Security Responsibility Model），并区分 IaaS、PaaS、SaaS 以及私有云中用户与云厂商的责任边界。
掌握威胁建模（Threat Modeling）与风险评估（Risk Assessment）的基本思路。
理解云基础设施、网络、主机、虚拟机、数据、日志、合规和灾难恢复中的主要安全问题。
能够把安全最佳实践应用到身份管理、网络防护、数据保护、检测、事件响应和组织安全管理中。
本周在课程中的位置
本周是 FIT5225 中关于 Cloud Security 的开端。前几周课程主要围绕云平台、VPC、子网、路由、NAT、Cognito、Serverless 和多云应用架构展开；本周开始把这些云组件放到“安全”的视角下重新理解。
可以这样理解：
课堂中老师特别强调，Cloud Security 的内容本来可以单独开一门课，本课程只能在两周内压缩讲解。因此复习时不应只记住术语，而要理解每个概念如何服务于真实云系统的安全设计。
1. 什么是安全（Security）
1.1 安全不是一个简单定义
安全（Security）和安全的（Secure）本身是非常宽泛、抽象的概念。它们的含义取决于应用场景、系统边界、用户角色和具体威胁。
对 IT 管理员来说，安全可能意味着服务器、网络、身份认证和访问权限没有漏洞；
对会计部门员工来说，安全可能意味着办公软件不会被木马感染，财务数据不会泄露；
对公司管理层来说，安全可能更关注客户数据、商业声誉和法律责任；
对云平台来说，安全还包括基础设施、数据中心、虚拟化、网络隔离、日志审计和合规。
因此，安全不是单一技术问题，而是一个跨技术、流程、人员、管理和法律的系统性问题。
1.2 安全不是二元状态
课件强调：安全不是 binary，不是“安全 / 不安全”的简单开关，而是一个灰色地带。
一个系统可能能抵挡普通个人攻击者，但无法抵挡有组织的大规模攻击；
一个系统现在看起来安全，但下一秒可能出现新的 0-day 漏洞；
一个组件本身安全，不代表整个系统安全；
安全水平通常取决于当前威胁、预算、架构设计、人员能力和运维成熟度。
在什么威胁模型下是安全的；
能抵御哪些攻击；
不能抵御哪些攻击；
发生事故后能否检测、响应和恢复。
1.3 安全技术不等于安全系统
你使用了加密数据库，但管理员密码非常弱，系统仍然不安全；
你部署了 HTTPS，但后端 API 没有权限校验，系统仍然可能被滥用；
你使用了云厂商的安全服务，但日志没有监控、漏洞没有修补，仍然会有风险；
一个 Web 应用、数据库、机器学习模型、存储桶、身份系统和网络配置组合在一起后，最弱的环节会决定整体安全水平。
因此，安全系统需要集体知识（Collective Knowledge）：
云基础设施知识；
网络安全知识；
应用开发安全知识；
数据库安全知识；
机器学习模型安全知识；
法律合规知识；
运维与监控经验。
2. 安全为什么在云时代更重要
2.1 对 CSP 和企业的重要性
对于云服务提供商（Cloud Service Provider, CSP）和企业来说，安全直接关系到：
Trust（信任）：客户是否愿意把数据和核心业务交给平台；
Compliance（合规）：是否满足隐私法、行业规范、合同义务和监管要求；
Cost（成本）：安全事故可能带来赔偿、修复、诉讼、罚款和客户流失；
Obligation（义务）：企业有责任保护用户数据和业务连续性。
云环境下，数据、应用和网络边界不再只存在于企业自己的机房里，而是分布在云厂商的数据中心、不同区域、不同服务和不同租户之间。因此，安全范围变得更大，也更难管理。
2.2 对学生和开发者的重要性
课堂中老师补充说，现在的开发者越来越像“super developer”：不仅要会开发、部署、运维，还要理解安全，未来还可能需要理解如何正确使用 AI 辅助开发并识别 AI 生成代码中的问题。
因此，在 FIT5225 里学习 Cloud Security 不只是为了考试，也是为了具备现代云工程岗位需要的基本能力。
2.3 澳大利亚近期安全事件示例
课件用澳大利亚近年的安全事件说明数据泄露的现实影响：
数据泄露的损失不仅是技术修复成本；
还包括用户信任下降、品牌声誉受损、法律风险、监管罚款和长期客户流失；
对终端用户来说，最基本的自我保护包括使用不同密码、密码管理器、暗网泄露监控和多因素认证（Multi-Factor Authentication, MFA）。
3. 安全设计的 3W2H 思维框架
3.1 Who：我们要防谁
防普通用户误操作，需要权限隔离和 UX 设计；
防外部攻击者，需要网络隔离、防火墙、WAF、认证和检测；
防内部管理员滥权，需要最小权限、审计日志和职责分离；
防非技术员工被钓鱼，需要培训、MFA 和安全流程。
3.2 What：我们要保护什么
物理资产：服务器、硬盘、数据中心、网络设备；
软件资产：源代码、应用逻辑、配置文件、部署脚本；
数据资产：客户信息、交易记录、日志、备份、模型数据；
知识产权：算法、架构设计、专利、商业流程；
人力资源：关键工程师、架构师、掌握内部知识的员工；
业务连续性：服务可用性、灾难恢复能力、客户访问体验。
课堂中老师补充，很多学生容易忽略“人”也是重要资产。例如大型芯片公司中的核心架构师、系统设计负责人或掌握关键业务逻辑的员工，本身就是组织需要保护的重要资源。
3.3 When：安全从什么时候开始，到什么时候结束
安全不是系统上线后才补上的功能，而应该覆盖系统生命周期（Lifecycle）：
可以这样理解：安全的终点不是“系统上线”，而是“系统和数据被安全退役”。
3.4 How：如何衡量、监控和报告
安全必须能被衡量和监控，否则只是口号。常见做法包括：
定义安全指标（Security Metrics）和关键绩效指标（KPI）；
收集服务器日志、应用日志、访问日志、网络日志；
对异常事件设置告警，例如异常登录、权限提升、大量失败请求、DDoS 流量；
为常见事故准备处置手册（Playbook）；
明确发生事故后谁负责、如何隔离、如何通知、如何恢复。
例如，如果 Web 服务器被攻破，不应临时慌乱地“想办法”，而应该提前在 Playbook 中定义：
如何隔离该服务器；
是否切断其外网访问；
如何保存证据；
如何检查横向移动；
如何通知相关负责人；
如何恢复服务。
3.5 How to comply：如何满足合规
合规（Compliance）要求取决于国家、地区、行业和数据类型。例如：
适用哪些法律和行业标准；
数据是否允许跨区域存储或传输；
发生数据泄露后多长时间内必须报告；
用户是否有权导出、修改或删除自己的数据；
备份和复制数据如何满足删除请求。
4. 云安全的技术范围：4A / AAA
有些资料也会使用 AAA 的说法，把 Access 和 Audit 合并到 Accounting 中。无论是 4A 还是 AAA，核心逻辑都是：
4.1 身份认证（Authentication）
身份认证是建立和传播用户身份的过程。它回答的问题是：这个用户到底是谁？
用户名 + 密码；
多因素认证（MFA）；
公钥基础设施（Public Key Infrastructure, PKI）；
单点登录（Single Sign-On, SSO）；
生物特征信息，例如指纹和人脸识别。
4.2 授权（Authorization）
授权决定认证后的用户能访问哪些资源，以及能执行哪些操作。常见权限包括：
read；
write；
execute；
delete；
administer。
课堂中老师补充，真实系统里经常组合使用 RBAC 和 ABAC。例如：
4.3 与 AWS Cognito 的关系
课堂中老师把 4A 和 AWS Cognito 联系起来解释：
Cognito User Pool 主要用于认证，即保存用户身份、处理注册、登录、密码重置和身份验证；
Cognito Identity Pool 主要用于授权，即把登录后的 token 交换成临时 AWS credentials，并控制用户能访问哪些 AWS 服务；
之后用户用临时 credentials 访问 S3、DynamoDB、Lambda 等服务；
CloudWatch 等日志服务可以用于审计用户访问行为。
5. 常见安全威胁类别
5.1 数据泄露与数据篡改
数据泄露（Data Leakage）和数据篡改（Data Tampering）是最常见也最严重的安全问题之一。
可以这样理解：攻击者不一定需要“打爆系统”，只要能在传输、认证、会话、权限或存储中的某个环节获得数据，就可能造成泄露。
5.2 破坏型攻击：DoS / DDoS
破坏行为（Vandalism）通常不一定以窃取数据为目标，也可能是为了让系统不可用。
拒绝服务攻击（Denial of Service, DoS）；
分布式拒绝服务攻击（Distributed Denial of Service, DDoS）；
Botnet 攻击；
ICMP Smurf；
TCP SYN Flood。
DDoS 的核心目标是让正常用户无法访问服务。即使数据没有被窃取，如果系统不可用，也仍然属于安全问题，因为可用性（Availability）是安全的重要组成部分。
5.3 恶意软件与勒索软件
Malware（恶意软件）；
Spyware（间谍软件）；
Ransomware（勒索软件）。
课堂中老师用作业文件被勒索软件加密作为例子：如果没有备份，攻击者加密了你的代码或数据，你可能被迫支付赎金。因此，备份策略本身也是安全的一部分。
5.4 社会工程攻击
社会工程攻击（Social Engineering Attack）利用的是人的认知错误，而不是单纯的软件漏洞。
例如，把 commonwealth 伪造成 commonwea1th，用户不仔细看就可能把密码输到假网站。
6. 威胁类型与缓解技术
注意：这些缓解方式不是互斥的。真实系统通常需要组合多种控制，例如认证、授权、加密、日志、限流、监控和自动化响应共同工作。
7. 隐私（Privacy）与云隐私问题
7.1 隐私的定义因地区和文化而异
隐私（Privacy）不是一个全球完全统一的概念。不同国家、文化、行业和司法辖区对“什么是个人信息”可能有不同定义。
课件引用了 GAPP（Generally Accepted Privacy Principles）的定义：
课堂中老师举例说明：在某些文化中询问工资可能很常见，但在西方文化中通常被视为私人问题。因此，如果开发全球应用，必须理解目标市场对隐私的要求，而不能只按自己熟悉的文化理解隐私。
7.2 云环境中的隐私关注点
7.3 云隐私中的一个关键难点：删除不等于立刻消失
因此，“删除按钮”只是表面动作，真正的安全删除需要数据生命周期管理和清理策略。
8. 共享安全责任模型
8.1 核心思想
共享安全责任模型（Shared Security Responsibility Model）说明：在云计算中，安全责任由云厂商和客户共同承担，但责任边界会随服务模型变化。
8.2 不同服务模型下的责任边界
私有数据中心：你几乎负责全部安全；
IaaS：云厂商负责物理设施和虚拟化，你负责操作系统、应用和数据；
PaaS：云厂商负责运行时和平台，你负责应用逻辑、数据和配置；
SaaS：云厂商负责大部分技术栈，你仍需负责用户、访问、数据治理和合规使用。
9. 私有云与主机级安全威胁
9.1 私有数据中心 / 私有云安全
在私有数据中心或私有云中，组织需要承担完整责任，包括：
9.2 SaaS、PaaS、IaaS 中的主机级威胁
9.3 面向虚拟服务器的典型威胁
私有 SSH key 被盗或误用；
FTP、SSH、HTTP 等标准端口上的服务未打补丁、配置错误或存在漏洞；
账号劫持，例如弱密码、默认密码、安全 bug；
系统没有防火墙保护；
Guest OS 镜像中嵌入木马或 rootkit；
VM hopping，即攻击者从一个虚拟机跳到另一个虚拟机；
VM-based rootkits and malware；
攻击者利用云资源托管 botnet 或传播恶意软件。
使用主机型入侵检测系统（Host-based IDS），例如 OSSEC 或 Samhain；
只开放必要端口；
启用系统审计和事件日志；
使用强密码并定期更换；
妥善保护 SSH 私钥；
加固 VM 镜像，并检查镜像 checksum，确保没有被篡改；
sudo 操作要求密码，或使用基于角色的访问控制，例如 SELinux。
10. 云安全挑战与用户侧风险
10.1 关键挑战
10.2 典型云安全问题与缓解思路
10.3 云服务用户面临的风险
责任模糊（Responsibility Ambiguity）；
治理丧失（Loss of Governance）；
信任缺失（Loss of Trust）；
服务商锁定（Service Provider Lock-in）；
云服务用户访问不安全（Non-secure Cloud Service User Access）；
资产管理缺失（Lack of Asset Management）；
数据丢失和泄露（Data Loss and Leakage）。
这些风险说明，云安全不仅是“云厂商是否安全”，还包括客户是否清楚自己的资产、权限、合同、数据位置和责任边界。
11. 威胁建模与风险评估
11.1 威胁建模的目标
威胁建模（Threat Modeling）是系统性识别安全问题和潜在威胁的过程。它的目标是帮助团队形成：
安全需求；
测试计划；
测试工具；
风险优先级；
缓解策略。
谁可能恶意攻击系统？
他们是内部攻击者还是外部攻击者？
哪些资产可能被攻击？
攻击影响范围有多大？
哪些威胁最关键？
应该用哪些工具和策略缓解？
11.2 Method, Opportunity and Motive
Method（方法）：攻击者如何攻击，例如钓鱼、漏洞利用、DDoS、权限提升；
Opportunity（机会）：系统是否暴露了攻击机会，例如开放端口、弱密码、未打补丁；
Motive（动机）：攻击者为什么攻击，例如盗取数据、勒索、破坏、商业竞争。
只有同时理解攻击者的方法、机会和动机，才能合理评估风险。
11.3 三种常见威胁建模方法
威胁模型可以用 UML 图、攻击树（Attack Tree）或其他格式表示。重点不是图本身有多漂亮，而是能否帮助团队识别风险并制定可执行的缓解措施。
11.4 TOGAF 图示的含义
课件中的 TOGAF Security Guide 图示表达的是：企业安全架构不是孤立存在的，而是和企业架构、业务目标、风险管理、身份与访问管理、事件管理、合规管理和安全监控联系在一起。
所以安全不是单独装一个工具，而是企业治理和架构的一部分。
12. 云安全管理与基础设施安全
12.1 云安全管理范围
云安全管理（Security Management in Cloud）要求理解服务的信任边界（Trust Boundary），例如：
网络服务；
应用服务；
存储服务；
Web 服务；
身份服务。
可用性管理；
配置管理；
补丁管理；
访问管理；
漏洞管理；
事件响应。
12.2 图示中的安全管理层次
基础设施安全（Infrastructure Security）Network-level；
Host-level；
Application-level。
数据安全（Information Security – Data）Encryption；
Data masking；
Redaction；
Protection。
安全管理和监控服务（Security Management and Monitoring Services）
这个图的重点是：安全管理必须同时覆盖底层基础设施、数据保护和上层监控管理。
12.3 云基础设施安全
云基础设施安全（Cloud Infrastructure Security）关注网络、访问、隔离和互联网暴露资源的安全。
使用网络分区和分层，例如安全组（Security Groups）、VPC、独立主机和安全域；
区分 test、production、dev、staging 等隔离环境；
配置防火墙；
部署入侵检测 / 防御系统（Intrusion Detection/Prevention System, IDS/IPS）；
使用 SSL、IPSec 等加密传输数据。
13. 云安全最佳实践
13.1 NIST SP 800-144 的三类活动
课件引用 NIST SP 800-144，把外包到云服务提供商时的最佳实践分成三类：
可以这样理解：云安全不是签约后才开始，而是从选择供应商前就开始，到合同结束和数据清除后才算真正结束。
13.2 安全设计原则
课件采用 AWS Well-Architected Framework 中的安全设计思想，整理为：
建立强身份基础（Implement a strong identity foundation）；
最小权限原则（Least Privilege）；
启用可追踪性（Enable Traceability）；
在所有层应用安全（Apply security at all layers）；
自动化安全最佳实践（Automate security best practices）；
保护传输中和静态数据（Protect data in transit and at rest）；
让人远离数据（Keep people away from data）；
为安全事件做好准备（Prepare for security events）。
其中“Keep people away from data”可以这样理解：
13.3 通用云安全最佳实践
可以这样理解：安全控制不应只靠人工检查，而应该尽可能进入 CI/CD、部署脚本、IaC、自动化扫描和监控系统。
14. IAM 最佳实践
身份与访问管理（Identity and Access Management, IAM）是云安全的核心。
使用集中身份提供者（Centralized Identity Provider）；
利用用户组和属性；
遵守最小权限原则；
使用强登录机制，例如 MFA；
使用临时凭证（Temporary Credentials），减少长期密钥泄露风险；
定期审计和轮换凭证；
安全存储和使用 secrets，不要共享 secrets。
课堂中老师强调集中身份管理的重要性：如果一个组织有几十个系统，每个系统都有独立用户库，员工离职时可能遗漏某些账户，留下长期安全风险。因此，集中身份管理有助于统一授权、撤销权限和审计访问。
15. 基础设施与网络保护
基础设施与网络保护（Infrastructure & Network Protection）主要包括：
创建网络层次；
在所有层控制流量，例如 VPC、Security Group、NACL；
实施检查与保护，例如流量检查、IDS/IPS、WAF；
自动化网络和计算资源保护；
执行漏洞管理；
减少攻击面（Attack Surface）；
尽量使用托管服务（Managed Services）；
验证软件完整性。
网络层不应是“全部互通”；
每个子网、服务和端口都应该有明确用途；
只开放必要端口；
使用分层控制避免单点配置错误导致全局暴露。
16. 数据保护
16.1 数据保护的基本任务
16.2 数据安全的几个方面
16.3 保护静态数据
保护静态数据（Data at Rest）的主要方法包括：
使用端到端加密，确保数据从源头开始被加密，并在目标端安全存储；
使用对称加密技术，例如 AES、Triple DES；
使用足够强的密钥，例如 256-bit 或更高；
使用非对称加密技术；
使用公钥基础设施（PKI）；
使用数据完整性校验，例如 hash-based checksum、CRC、MAC 或人工验证。
课件提到同态加密（Homomorphic Encryption）：它允许在不解密数据的情况下处理加密数据，但需要极高计算能力，因此现实中仍有很高成本。
16.4 数据残留与清理
数据残留（Data Remanence）指数据被删除后仍以某种残余形式存在。
删除操作失败；
存储介质物理特性导致残留；
备份、副本或缓存中仍有数据；
多副本云存储的异步删除机制。
数据清理与净化（Data Clearing and Sanitization）强调在介质复用前彻底清除数据。课件提到 DoD 5220.22-M 标准作为示例。
17. 检测、事件响应与组织安全建设
17.1 检测最佳实践
检测（Detection）不是等事故发生后才做，而是提前建立可见性。
配置服务和应用日志；
集中分析日志、发现和指标；
建立可执行的安全事件 Playbook；
自动化事件响应。
17.2 事件响应
事件响应（Incident Response）关注安全事件发生后的处理能力。
建立响应目标；
文档化响应计划；
明确自己拥有什么资源、还需要什么资源；
使用重新部署机制恢复系统；
尽可能自动化；
从事件中学习并改进流程；
教育、准备、模拟和迭代。
可以这样理解：事件响应能力不是在事故发生当天临时建立的，而是通过平时演练、文档、自动化和复盘持续积累的。
17.3 组织安全建设步骤
18. 配置、连续性、备份和灾难恢复
18.1 AWS 中的配置与连续性管理
变更在推出前应经过审查、测试和批准；
使用不同可用区（Availability Zones）隔离故障；
根据监管合规或可靠性要求选择不同区域（Regions）；
需要 24×7 事件响应团队；
存储数据应进行备份；
物理设备应使用 DoD 或 NIST 介质清理技术擦除。
18.2 灾难恢复和系统备份
灾难恢复（Disaster Recovery, DR）用于应对自然灾害或人为灾害。
19. 合规风险与服务交付模型监控
19.1 常见合规风险
19.2 IaaS、PaaS、SaaS 中的安全监控责任
课件用两个表格说明不同服务模型中的监控责任差异。核心规律是：
20. 课堂补充：VPC、Cognito、Assignment 2 与 Oracle Optional Task
本部分来自 transcript 中的课堂补充，不属于 Cloud Security PDF 的主体内容，但与本周 Seminar 实际讲解有关。
20.1 VPC 网络费用与 NAT Gateway / NAT Instance
老师在开头回顾了 VPC 相关内容，重点是网络流量费用：
同一 AWS Region 内，VPC 到部分 AWS 服务之间通常没有数据传输费用；
私有子网中的实例如果通过 NAT Gateway 出网，NAT Gateway 会收取按小时费用和按 GB 的数据处理费用；
NAT Gateway 是 AWS 托管服务，运维简单但成本更高；
NAT Instance 是自己管理的 EC2 实例，AWS 已不再推荐作为首选，但课堂中可能为了节省成本使用；
跨 Region 数据传输通常按 GB 收费；
通过互联网转发的流量通常比同一区域 / 同一可用区内部私网通信更贵；
VPC Peering、跨 AZ、走公网还是走私网，都会影响费用。
可以这样理解：云网络设计不仅影响安全和连通性，也直接影响成本。
20.2 Cognito 的课堂回顾
课堂中把 Cognito 解释为 AWS 提供的用户身份和数据同步服务，适合中小型业务管理用户库。
User Pool：用户数据库，用于认证；
Identity Pool：用于授权，把登录后的 token 换成临时 AWS credentials；
用户可以通过用户名、邮箱、密码、MFA 或第三方身份提供商登录；
不同用户组可以获得不同 AWS 服务权限；
在 Assignment 2 中，Cognito 被要求用于用户认证和授权。
20.3 Assignment 2 课堂说明
目标是开发一个多云在线存储系统；
背景是澳大利亚野生动物观察和媒体文件管理；
系统需要支持图片和视频上传；
需要至少两个主要云提供商，AWS 加另一个云；
应用应尽量使用 serverless 思路，低流量时可以 scale down to zero；
需要使用预训练机器学习模型自动识别动物标签；
需要支持手动添加、删除标签；
需要支持 deduplication，避免重复文件浪费存储；
需要生成缩略图，便于网页展示；
视频可以通过抽帧方式进行识别；
用户可以按物种、缩略图 URL、标签等查询媒体文件；
需要 tag-based notification，例如用户订阅 koala 后，出现相关上传时收到邮件通知；
Cognito 是认证和授权部分的强制要求；
小组默认 3–4 人，2 人组需要特殊批准，超过 4 人不允许；
Group assignment 的 due date 是 firm，普通 2 天 short extension 不适用于整个小组；
Demo 将通过 Zoom 进行，预计在 Week 14 和 Week 15；
如果组员没有积极贡献，可能通过 confidential report 被扣除最高 50% group mark；
GenAI 工具不被禁止，但 demo 时必须理解并能修改自己提交的代码。
20.4 Oracle Optional Case Study
课堂中还介绍了 Oracle optional case study / design task：
这是额外 optional task，最高可获得 5 分 bonus；
需要提交一页完整架构图，以及简洁的 plan / discussion；
主题是为一个全球电商公司设计现代化技术运营架构；
要求使用 Oracle Cloud 作为 mandatory cloud，同时结合另一个云和私有数据中心；
不提供反馈，只给分数；
分数加到总评中，但最终总分不会超过 100；
截止时间是 Week 11 Friday，即 22 May；
Week 12 会从满分学生中随机抽取 2 人参加 15 分钟 Oracle senior staff mock interview；
面试中学生扮演 CIO，向不太懂技术的 CEO 解释架构如何解决业务挑战，而不是深入讲技术细节。
Summary
本周 Cloud Security 的核心思想可以总结为：安全不是某个单独工具，也不是系统上线后临时补上的功能，而是贯穿云系统生命周期的整体设计问题。
安全是上下文相关的，不是绝对二元状态；
单个安全技术不等于整个系统安全，最弱环节会影响整体安全；
云安全需要先问 3W2H：防谁、保护什么、何时保护、如何监控、如何合规；
4A 是技术核心：Authentication、Authorization、Access、Audit；
隐私保护在云环境中会受到数据位置、跨境传输、备份、副本、删除和合规要求影响；
共享安全责任模型决定了 IaaS、PaaS、SaaS 中用户和云厂商各自负责什么；
威胁建模和风险评估帮助团队系统性识别攻击者、资产、影响和缓解措施；
云基础设施安全需要网络分层、访问控制、防火墙、IDS/IPS、加密和隔离环境；
数据安全覆盖传输、静态存储、处理、可用性、血缘、来源和残留；
检测、事件响应、备份、灾难恢复和合规不是附加项，而是安全架构的重要组成部分。
一句话概括：Cloud Security 的目标不是让系统“看起来安全”，而是让系统在真实威胁、真实用户、真实合规要求和真实故障场景下，能够被保护、被监控、被审计、被恢复。
secure technology != secure system
Dev -> DevOps -> DevSecOps
先证明身份 -> 再获得权限 -> 再访问资源 -> 最后留下可审计记录
User Pool = 证明你是谁
Identity Pool = 决定你能访问什么
Temporary Credentials = 让你实际访问 AWS 资源的短期凭证
Audit Logs = 记录你访问后做了什么
3 copies：至少 3 份数据副本
2 different media：至少 2 种不同存储介质
1 offsite：至少 1 份异地备份