跳到正文 Cloud Security Guest Lecture + Mock Interview · Jimmy Huang's Blog
← Week 12 Industry Talk and Unit Revision 学习 › C6001 › 2026 S1 › FIT5225 Cloud computing and security › Week 12 Industry Talk and Unit Revision Cloud Security Guest Lecture + Mock Interview Cloud Security Guest Lecture + Mock Interview 本页目录· 82 条 1. 本次 Lecture 总体结构 这次是 FIT5225 Cloud Computing 的 Week 12，也就是本学期最后一次 lecture。整体内容分成四部分：
课程与作业面试说明
Oracle Guest Lecture：Cloud Security in Enterprise
Q&A：AI、Solution Architect、Oracle Cloud、企业安全现实
Assignment 2 Mock Interview 与面试反馈
本次 lecture 的核心不是单纯讲某一个云服务，而是从企业真实环境角度解释：
云计算系统不只是“能跑起来”，还必须能被安全地运行、维护、扩展和解释。 2. 课程与作业面试说明 2.1 Assignment Interview 很重要 老师强调，FIT5225 的 assessment 允许使用 GenAI，但学生必须能够证明自己理解自己提交的内容。
因此，Assignment 的 interview 不只是形式流程，而是评分的重要依据。
重点包括：
你必须能解释自己做了什么；
你必须能说明为什么这样设计；
本页目录 如果作业看起来很完整，但 interview 中无法解释，可能会被扣分，严重时某部分可能给 0。
2.2 如果对分数有疑问，应该按层级沟通 老师说明，如果学生对 marks 或 feedback 有疑问，不应该直接群发给所有 teaching team。
先联系 marking tutor；
如果仍然不满意，再 escalate 给 Jay / Head Tutor / UC；
如果问题仍然存在，最后才到 lecturer。
2.3 Mock Interview Extra Mark 之前提交 solution architect scenario 的学生会获得额外加分。老师提到有超过一半学生提交了设计，教学团队已经进行 marking，并会按之前公告加入 quiz 或 assignment 分数。
3. Guest Lecture：Cloud Security in Enterprise 本次 guest speaker 是 Oracle 的 Rakesh Singh，他的角色类似 Chief Customer Architect / Chief Solution Architect。
他的工作不是只卖某个产品，而是帮助企业客户把 business strategy 和 technology strategy 对齐，也就是：
企业想去哪里，技术如何帮助它安全、可扩展、可维护地到达那里。
4. 为什么 Cloud Security 是核心问题
4.1 安全不是附加功能，而是系统能否被信任的前提 No matter how good the solution is, if it is not secure, no one is going to use it. 也就是说，系统功能做得再好，如果 security 不可靠，企业、政府、银行、医疗机构都不会真正信任它。
4.2 安全也必须变得更简单 传统做法要求用户记住复杂密码，但现实中用户可能会：
写在纸上；
重复使用同一个密码；
选择很弱的密码；
绕过复杂流程。
如果安全流程太复杂，人会找 shortcut；如果安全流程简单，人更可能遵守。
5. 企业面临的主要安全风险 Guest lecture 中提到企业常见 security concerns 包括：
5.1 Ransomware 勒索软件攻击会直接影响企业声誉和业务连续性。攻击一旦发生，可能迅速变成 public knowledge，影响客户信任。
5.2 Human Error 使用简单密码；
没有及时更换默认密码；
没有正确配置权限；
没有及时 patch；
错误暴露 public endpoint。
5.3 Enterprise Complexity 大型企业往往不是一个系统，而是大量系统组成的复杂生态：
只要其中一个系统、API、第三方连接或旧服务存在 weak link，就可能影响整个环境。
5.4 Unpatched Legacy Systems Guest speaker 提到，有些企业知道风险存在，但因为升级成本、测试成本、预算周期等原因，会选择“先继续用，希望没事”。
很多组织不是不知道风险，而是知道风险但仍然拖延修复。
5.5 Third-party Risk 有时候企业自己的主系统是安全的，但第三方系统、API link 或 integration 没有被充分审计，最终成为攻击入口。
5.6 Hybrid Work Risk 疫情后 hybrid work 成为常态，员工可能在家处理敏感数据。企业必须考虑：
家庭环境是否安全；
call centre 员工是否会泄露信息；
远程访问是否经过强认证；
数据是否能被未授权人员看到或听到。
5.7 Geopolitical Risk 随着国际冲突增加，国家、组织、黑客团体之间的网络攻击风险也上升。Cloud security 需要考虑更大的 geopolitical threat landscape。
6. Oracle Guest Lecture 中的安全框架 Guest speaker 用 Oracle 作为例子，但也说明这些思路可以作为 cloud security 的通用 template。
他把企业 cloud security 分成四个方向：
Guard
Accelerate
Simplify
Deliver
7. Guard：防止攻击、数据泄露和横向扩散
7.1 Core-to-Edge Security Oracle 的视角是从 core 到 edge 保护系统。
Core：数据存储、database、object storage；
Compute：VM、bare metal、OS；
Network：subnet、firewall、public/private access；
Identity：IAM、RBAC、MFA；
Monitoring：Cloud Guard、Threat Intelligence、Audit。
这说明 security 不是只在一个地方做，而是每一层都要有 control。
7.2 Data Safe Data Safe 的作用是根据数据敏感度定义和检查安全策略。
哪些数据是 PII？
哪些数据需要 masking？
谁可以访问这些数据？
是否有 public endpoint 暴露？
是否违反了 security policy？
它的核心价值是自动化检查，而不是只给管理员一堆手动功能。
7.3 Transparent Data Encryption Transparent Data Encryption 用于加密存储层数据。
不只是 online system 要安全，backup 也要安全。 很多企业保护了运行中的系统，却忽略 backup。如果 backup 没有加密，被偷走后仍然可能造成数据泄露。
7.4 Audit Vault / Data Vault Audit Vault / Data Vault 用于保护审计信息，防止攻击者修改或删除 audit trail。
原因是攻击者入侵后，常常会尝试清除痕迹。如果 audit log 可以被随意篡改，就很难追踪事故。
7.5 Key / Certificate / Secrets Management encryption keys；
certificates；
secrets；
passwords；
tokens；
API credentials。
这些内容如果散落在代码、配置文件或个人电脑里，会带来严重风险。
7.6 Autonomous Database / Autonomous Linux Oracle 提到 Autonomous Database 和 Autonomous Linux 的思想：
自动发现需要的 patch；
自动应用 patch；
自动调优；
自动监控运行状态；
降低人为维护遗漏。
很多安全事故来自没有及时 patch，所以让系统自动 patch 可以降低风险。
7.7 Bare Metal Compute 对于敏感 workload，企业有时不想运行在 shared virtualised environment 中。
Bare metal compute 提供类似“整台物理服务器”的云上资源，减少虚拟化层带来的隔离顾虑，适合某些高安全性或高性能场景。
7.8 Hardened Images and Hardware Root of Trust 安全的 compute environment 还包括：
7.9 Network Security Cloud architecture 中必须明确设计：
public subnet；
private subnet；
firewall rules；
security groups；
open ports；
route tables；
API access；
east-west traffic；
north-south traffic。
Deny all by default, then allow only what is needed.
7.10 Off-box Virtualization Oracle 提到 OCI 的一个设计：把 networking control plane 从 compute server 上移走，放到独立硬件中。
7.11 Cloud Guard and Threat Intelligence Cloud Guard 用于持续监控资源配置和异常行为。
Threat Intelligence 可以结合外部安全情报，例如来自 CrowdStrike 等来源的攻击 IP 信息，帮助企业动态更新防火墙或安全策略。
8. Accelerate：安全地 Onboard Workloads
8.1 企业应用迁移到云时，第一步是 Landing Zone 当企业把 workload 搬到 cloud 时，不应该一上来就随意创建资源，而应该先设计 landing zone。
在 OCI 中，类似概念是 compartment；在 AWS、Azure、GCP 中也有对应的 account/project/subscription/resource hierarchy 设计。
8.2 Production 和 Non-production 应该隔离
8.3 Logging and Monitoring 要统一 企业中系统很多，如果每个系统各自监控，安全团队很难看清整体状态。
centralized logging；
centralized monitoring；
single pane of glass；
alerting；
incident response；
audit trail。
8.4 IAM Federation and SSO 多云和多 SaaS 环境下，用户身份分散是重大风险。
8.5 Terraform / IaC 可以标准化 Landing Zone Guest speaker 提到 landing zone 可以用 Terraform scripts 部署，让企业快速获得标准化、可重复的基础架构。
这也和 FIT5225 中 IaC、cloud deployment、multi-cloud assignment 的实践有关。
9. Simplify：让安全在 Multi-cloud 和 Enterprise 环境中更简单
9.1 Multi-cloud 是企业常态
9.2 统一 IAM 是简化的关键 为了降低复杂度，企业应建立统一身份和访问管理层，让所有应用都通过统一入口管理 access。
重复账号；
重复密码；
不一致权限；
难以审计的访问路径；
员工离职后仍然保留 access 的问题。
9.3 WAF 用于保护 Public Endpoints Web Application Firewall 可以保护 public-facing applications 和 APIs。
9.4 Distributed Cloud / Dedicated Region 有些客户希望获得 cloud 的弹性和服务体验，但又不想把数据放进 public cloud。
因此 Oracle 提供不同 cloud deployment models，例如：
Cloud 不一定只等于 public cloud。企业可以根据安全和合规需求选择不同部署形态。
10. Deliver：满足 Compliance 和 Regulatory Requirements
10.1 Compliance 是企业安全架构的一部分 企业不只是要“技术上安全”，还要满足监管要求，例如：
10.2 Cloud 的优势是标准化合规环境 Cloud provider 的服务通常已经通过大量合规认证。企业使用这些服务时，可以减少从零开始证明基础设施合规的负担。
Cloud 像一个已经通过基础安全检查的环境，客户可以在这个基础上构建自己的系统。
10.3 GDPR 的启示 GDPR 不只影响欧盟本地企业。如果企业拥有 EU customers，也可能需要满足 GDPR。
谁能访问 customer data；
数据如何被存储；
数据是否被 masking；
数据是否可审计；
数据是否可以按政策删除或处理。
11. Q&A 重点总结
11.1 企业真的理解安全风险吗？ Defence 等领域非常重视安全，愿意投入成本；
银行也理解安全，但可能受成本和 legacy system 限制；
一些政府或企业系统长期不升级，因为“以前没出事”；
很多风险不是完全不知道，而是知道但拖延修复。
企业安全不只是技术问题，也是预算、管理、legacy、risk appetite 的问题。
11.2 什么是 Solution Architect / Enterprise Solution Architect？
Solution Architect 关注某一个具体 solution 或某个业务流程，例如：
Enterprise Solution Architect / Chief Customer Architect 关注范围更大，是 end-to-end enterprise scope：
理解公司 business strategy；
将 corporate strategy 转换为 technology direction；
连接 business stakeholders 和 technical specialists；
设计跨系统、跨部门、跨云的整体方案；
不是每个技术都亲自深入，而是协调专家共同完成 enterprise-level solution。
Solution Architect 看一个具体系统；Enterprise Architect 看整个企业技术版图。
11.3 AI 如何影响架构师工作？ Guest speaker 说，现在工作中 AI 使用非常重要，甚至会被衡量使用多少 AI。
快速查内部知识库；
做 research；
生成 slide deck；
设计 demo；
brainstorm solution；
分析客户问题；
构思 agentic workflow；
自动化一些重复性任务。
不要放弃 coding。Coding knowledge 仍然是 foundation。 如果 AI 生成代码，但你看不懂、不会部署、不会 debug，那仍然没有用。
会用 AI；
但不能只依赖 AI；
要理解代码；
要理解 architecture；
要理解 deployment；
要有学习能力。
11.4 Hiring 中什么更重要？ Guest speaker 认为 coding skill 重要，但 aptitude 更重要。
11.5 Oracle Cloud 相比 AWS / GCP / Azure 有什么特点？ Guest speaker 从 Oracle 视角解释了 OCI 的一些特点：
1. 面向 enterprise workload 重新设计 早期 cloud 更像是把大服务器切成很多 compute 资源卖给用户，但这对 enterprise database workload 不一定理想。
OCI 更强调 enterprise database、cluster、storage、low-latency networking 等场景。
2. Network latency OCI 使用更适合低延迟通信的网络设计，使节点之间通信延迟更低。
这对 GPU cluster、database cluster、high-performance workload 很重要。
3. NVMe storage OCI 强调高吞吐存储，在某些场景中可以提供更好的 storage performance。
4. Off-box virtualization 把 networking layer 从 compute server 中分离，提高隔离性和安全性。
5. GPU workload 对于 AI training，GPU 之间和 GPU 与 storage 之间的 east-west traffic 很重要。如果数据不能及时送到 GPU，整个训练集群都会等待。
因此 low-latency networking 在 AI infrastructure 中非常重要。
6. Cost / performance Guest speaker 认为 Oracle compute 在某些场景下比 AWS / Azure 更便宜，同时性能较好。不过这属于 Oracle 视角，实际 assignment 或企业选型仍应根据 workload、region、service maturity、team familiarity、pricing、support 等综合判断。
11.6 AI 会不会带来更强攻击？
12. Mock Interview 重点总结 Guest lecture 后，老师安排了 mock interview。Rakesh 扮演 CEO，学生扮演 CIO / Solution Architect，模拟真实 assignment interview 或企业沟通场景。
13. Mock Interview 中暴露的问题
13.1 不要只列步骤 identify problems；
standardise；
scale；
do penetration testing；
create paths；
fix teams one by one；
这种结构本身没错，但对 CEO 来说太像 checklist。
13.2 面对 CEO，要用 high-level language 如果对方是 CEO，通常不需要一开始讲太多底层技术细节。
先给 vision；
再解释 business value；
再讲 key phases；
最后才补 technical detail。
Our goal is to reduce security risk, standardise deployment, improve visibility, and create a scalable foundation for future systems. secure the foundation；
standardise platform；
centralise logging and monitoring；
implement CI/CD governance；
improve IAM and access control；
introduce container image scanning；
roll out gradually by priority。
13.3 CEO 关心的是 outcome，不是 implementation detail 风险是否降低；
系统是否更稳定；
是否能满足 compliance；
是否会影响业务；
需要多少资源；
第一阶段做什么；
哪些团队需要配合；
如何衡量成功。
13.4 Interview 中常见追问方向 Mock interview 中出现或暗示的追问方向包括：
你会从哪里开始？
你需要 CEO 什么支持？
如何做 observability？
如何监控 CI/CD pipeline？
如何确认线上代码是正确版本？
如何保护 containers？
如何避免 image tampering？
如何设计 monitoring？
如果用 AWS，可以用什么服务举例？
如果系统有多个团队，如何标准化流程？
如何解释你的 roadmap？
14. Assignment Interview 的备考重点 根据本次 lecture 和 mock interview，Assignment 2 interview 应该重点准备以下内容。
14.1 你必须能解释自己的架构 为什么选择两个 cloud providers；
每个 provider 承担什么角色；
system components 如何通信；
哪些组件在 public subnet；
哪些组件在 private subnet；
数据如何存储；
request flow 是什么；
failure handling 怎么做；
如何 scale；
如何 monitor；
如何 secure。
14.2 你必须能解释你的技术选择 不要只说“我用了 AWS / GCP / OCI / Azure”。
14.3 你必须能解释基础操作
14.4 回答要区分 audience 如果是 CEO / business stakeholder：
用 high-level；
强调 value；
强调 risk reduction；
强调 roadmap；
避免一开始堆技术名词。
如果是 technical interviewer：
14.5 推荐回答框架
15. 本次 Lecture 和 FIT5225 整体关系 老师最后总结说，FIT5225 这门课希望学生获得真实 cloud 平台经验，而不是只停留在概念层面。
老师强调，这些经验对未来很有用，不只是 cloud engineer 需要，software engineer、ML engineer 也越来越需要了解：
Docker；
cloud dashboard；
distributed systems；
multiple VMs / GPUs；
deployment；
security；
cloud services。
16. 最重要的 Takeaways
Takeaway 1 Cloud security 不是单点功能，而是从 data、compute、network、identity、monitoring 到 compliance 的整体设计。
Takeaway 2 企业最大的问题往往不是“不知道安全重要”，而是 legacy systems、patch delay、budget pressure 和系统复杂度让安全难以执行。
Takeaway 3 好的 security design 要自动化、标准化、简单化。否则人会犯错或绕过规则。
Takeaway 4 AI 会改变工作方式，但不会替代基础能力。学生仍然需要真正理解 coding、cloud、architecture 和 deployment。
Takeaway 5 Assignment interview 的关键不是背诵服务名，而是证明你理解自己的系统，并能根据不同 audience 清楚解释。
Takeaway 6 面对 CEO，要先讲 vision 和 business value；面对 technical interviewer，再深入技术细节。
Takeaway 7 Multi-cloud 和 enterprise security 的核心挑战是复杂性。解决复杂性的方式是统一身份、统一监控、标准化 landing zone、自动化治理和清晰的安全边界。
17. 可用于考试 / Interview 的一句话总结 This lecture explained that enterprise cloud security requires a layered, automated and simplified approach across data, compute, network, identity, monitoring and compliance. It also highlighted that students must be able to explain their own cloud architecture clearly in interviews, especially by starting with high-level business value before going into technical implementation details.
这次 lecture 的核心是：企业云安全不是单独配置几个安全服务，而是要从数据、计算、网络、身份、监控、合规等多个层次进行整体设计，并尽量通过自动化和标准化降低人为错误。同时，Assignment interview 中必须能证明自己真正理解架构设计，回答时要根据对象调整表达层次，先讲 high-level value，再讲技术细节。
1. Vision
我们的目标是建立一个安全、可扩展、可监控、可维护的 multi-cloud platform。
2. Current Problems
当前主要问题是 security gaps、manual deployment、limited observability、inconsistent access control、scalability risk。
3. Proposed Solution
我会从 secure foundation 开始，然后标准化 deployment，再增加 monitoring 和 governance，最后逐步 scale。
4. Key Controls
包括 IAM least privilege、private networking、encrypted storage、CI/CD validation、container image scanning、centralised logging、alerting、backup strategy。
5. Business Value
这样可以降低 breach risk，减少 manual errors，提高 release reliability，并为未来扩展提供基础。
6. First Step
第一阶段我会先做 security baseline 和 deployment standardisation，因为如果基础不稳定，后续 scaling 会放大问题。