wiki ingest: batch 2 (+2 docs, Claude Skills & NotebookLM)

knowledgebase/DevOps & SRE/01_AWS-Landing-Zone/ctp-topic-10-aws-landing-zone-lz-data-collection-tagging-related-security.md

@@ -12,7 +12,7 @@ tags:
 date-added: 2026-04-14
 video-source: "nas:///volume2/work/Public Cloud Learning Sessions/CTP _ Topic 10_ AWS  Landing Zone (LZ) Data Collection, Tagging _ Related Security.mp4"
 audio-source: ""
-status: raw
+status: summarized
 ---
 
 # CTP Topic 10 AWS Landing Zone (LZ) Data Collection, Tagging Related Security
@@ -27,21 +27,35 @@ status: raw
 
 ## 摘要
 
-> 待转录后由 LLM 生成
+> 本次视频是云转型计划（Cloud Transformation Program）的每周技术分享，重点探讨了 **AWS Landing Zones** 的部署流程、数据收集策略，以及如何利用标签（Tagging）和安全策略构建现代化的云安全架构。会议由 Steve Jarman 和 Pradeep 主讲，旨在帮助团队理解从传统网络安全向基于身份和元数据的云原生安全转型的过程。
+>
+> 核心内容分为三个部分：首先，Steve 介绍了 Landing Zone 的规划与自动化。他强调在部署前，必须深入了解业务部门（BU）的资产清单、IP 地址空间及数据敏感性，以便制定合适的安全姿态。目前，DNS、Transit Gateway 等基础服务的创建已通过 SRE 团队实现了高度自动化。
+>
+> 其次，视频详细讲解了**基于标签的安全控制机制**。与传统基于 IP 的防火墙规则不同，该方案利用 AWS 标签作为安全凭证。为了防止用户通过篡改标签绕过安全审计，架构中引入了 **OU（组织单元）** 和 **SCP（服务控制策略）**。通过 SCP 的“显式拒绝”逻辑，系统能够强制执行标签规范，确保资源在创建时即具备正确的归属（如 BU、产品、环境等）。
+>
+> 最后，Pradeep 演示了 **Checkpoint 防火墙** 中的“有序层（Ordered Layer）”逻辑。防火墙根据标签对流量进行分层过滤，包括地理屏蔽、BU 隔离、产品隔离及环境隔离（如开发环境与生产环境隔离）。这种设计确保了流量在跨 VPC、访问本地（On-prem）或互联网时，能够受到精细化的策略约束，同时支持 PSDC 等共享服务的合法访问。
 
 ---
 
 ## 关键概念
 
--
+- **AWS Landing Zones**: 一种能够按照最佳实践快速设置、安全且多账号的 AWS 环境的基础架构框架。
+- **Tagging Methodology**: 标签方法论，通过为资源定义标准化的元数据（如 Owner, BU, Product, Environment），作为自动化管理和安全策略执行的基础。
+- **SCP (Service Control Policies)**: 服务控制策略，一种组织策略，用于管理组织中的权限，本视频中用于强制执行标签合规性，防止未经授权的标签更改。
+- **OU (Organizational Unit)**: 组织单元，AWS Organizations 中账号的分组容器，用于分层应用安全策略（SCP）。
+- **Checkpoint Firewall**: 部署在云环境中的虚拟防火墙，通过集成 AWS 标签实现动态的对象识别和流量过滤。
+- **Transit Gateway**: 传输网关，作为网络中心枢纽，连接 VPC 与本地网络，是跨环境流量经过防火墙检查的关键节点。
+- **Ordered Layer**: 有序层，防火墙策略的一种组织方式，按顺序执行地理屏蔽、BU 隔离、环境隔离等逻辑。
+- **SRE (Site Reliability Engineering)**: 站点可靠性工程，负责 Landing Zone 部署中的自动化脚本编写与基础架构维护。
 
 ---
 
-## 行动项
+## 相关视频
 
--
-
----
+> [!info]+ 交叉引用
+> [[AWS_Organizations_and_SCP_Deep_Dive]] — 深入探讨如何编写和应用 SCP 策略以增强账号安全性。
+> [[SRE_Automation_Services_Overview]] — 关联 SRE 团队在 Landing Zone 中实现的 DNS 与网络自动化工具。
+> [[Hybrid_Cloud_Connectivity_Guide]] — 详细说明 Transit Gateway 如何连接 AWS 环境与本地数据中心。
 
 ## 相关视频
 

knowledgebase/DevOps & SRE/01_AWS-Landing-Zone/ctp-topic-17-active-directory-services-in-gruntwork-aws-lzs.md

@@ -12,7 +12,7 @@ tags:
 date-added: 2026-04-14
 video-source: "nas:///volume2/work/Public Cloud Learning Sessions/CTP _ Topic 17_ Active Directory Services in Gruntwork AWS LZs.mp4"
 audio-source: ""
-status: raw
+status: summarized
 ---
 
 # CTP Topic 17 Active Directory Services in Gruntwork AWS LZs
@@ -27,21 +27,31 @@ status: raw
 
 ## 摘要
 
-> 待转录后由 LLM 生成
+> 本次视频是 DevOps 云学习系列课程之一，重点介绍了在 Gruntwork AWS Landing Zones 架构中集成与管理 Active Directory (AD) 服务的核心实践。演讲者 Paul 详细阐述了两种主要环境的域名配置：研发实验室（R&D Labs）统一使用 `swinford.net` 域名，而生产与分阶段 SAS 环境则采用 `intsas.local`。视频明确指出，旧有的 `infra` 和 `AST` 域名在新的 Gruntwork 落地页中已被废弃，并为用户提供了相应的迁移路径和所有权归属建议。
+> 
+> 在技术实现层面，视频重点讲解了如何利用 SRE 团队提供的预制 AMI（Amazon Machine Images）实现自动化的域加入（Domain Join）。通过在 Terraform 的 `user_data` 中调用内置脚本，Windows 实例可以实现自动命名、管理员权限分配及旧对象清理；Linux 实例则支持安全动态更新以自动注册 DNS A 记录。此外，视频还介绍了针对不同环境的自助服务工具（如 MIM）和支持渠道（如 SMACKS 工单系统），旨在帮助开发者在遵循安全合规的前提下，提升系统接入域的效率与自动化水平。
 
 ---
 
 ## 关键概念
 
--
+- **Gruntwork Landing Zones**: 预配置的、基于最佳实践的 AWS 基础架构框架，分为 R&D Labs 和 SAS 两种环境类型。
+- **swinford.net**: 专门用于研发实验室（R&D Labs）环境的 Active Directory 域名，支持自助服务管理。
+- **intsas.local**: 用于生产和分阶段 SAS 环境的内部 Active Directory 域名，强调资源的所有权和审计。
+- **SRE-provided AMIs**: 由 SRE 团队预先构建的机器镜像，内置了用于自动加入域的 PowerShell 和 Shell 脚本。
+- **User Data**: 在 AWS 实例启动时执行的脚本数据，本视频中用于触发自动化的域加入流程。
+- **MIM (Microsoft Identity Manager)**: 用于 R&D 环境中安全组管理和权限申请的自助服务解决方案。
+- **SMACKS Ticket**: 内部服务管理工单系统，用于申请新账号、重置密码或处理复杂的生产环境变更。
+- **Secure Dynamic Updates**: 一种安全机制，允许 Linux 系统在加入域时向 Windows DNS 服务器安全地注册其 A 记录。
 
 ---
 
-## 行动项
+## 相关视频
 
--
-
----
+> [!info]+ 交叉引用
+> [[Gruntwork AWS Landing Zones Overview]] — 了解 AD 服务运行的基础架构背景
+> [[SRE Standard AMIs and Image Building]] — 了解内置域加入脚本的 AMI 制作标准
+> [[Terraform Single Server Module Deep Dive]] — 深入理解视频中用于部署实例的 Terraform 模块用法
 
 ## 相关视频
 

knowledgebase/DevOps & SRE/01_AWS-Landing-Zone/ctp-topic-26-standard-ami-build-publish-share-processes.md

@@ -11,7 +11,7 @@ tags:
 date-added: 2026-04-14
 video-source: "nas:///volume2/work/Public Cloud Learning Sessions/CTP _ Topic 26_ Standard AMI – build, publish, share processes.mp4"
 audio-source: ""
-status: raw
+status: summarized
 ---
 
 # CTP Topic 26 Standard AMI – build, publish, share processes
@@ -26,21 +26,34 @@ status: raw
 
 ## 摘要
 
-> 待转录后由 LLM 生成
+> 本次会议是每周转型计划（Weekly Transformation Program）的一部分，重点讨论了 **Foundation AMI（基础亚马逊机器镜像）** 的构建、加固与分发流程。会议由 Srihari、Alan 和 Praveen 三位专家主讲，旨在向产品团队介绍如何利用标准化的镜像来提升安全性和运维效率。
+>
+> 核心内容涵盖了 Foundation AMI 的全生命周期管理。首先，Foundation AMI 是基于市场主流操作系统（如 CentOS, Ubuntu, Windows 等）进行深度加固的镜像，集成了 CIS 安全基准、防病毒软件（McAfee EPO）、日志管理（Syslog-ng）以及单点登录（AD 集成）。其主要优势在于“即插即用”，确保所有实例从启动之日起就符合 Micro Focus 的安全合规标准，并预装了 SSM Agent 和 SiteScope 监控预选件。
+>
+> 在技术实现上，团队采用了 **HashiCorp Packer** 和 **Jenkins** 构建流水线，实现了镜像创建的完全自动化。为了优化成本和分发速度，镜像存储在中央存储库中，并通过跨账号共享（Sharing）而非物理复制（Copying）的方式分发到全球多个区域（如俄勒冈、法兰克福、悉尼等）。此外，镜像每两个月更新一次，遵循 N-2 的版本保留策略。
+>
+> 最后，会议强调了责任共担模型：CCOE 负责提供安全的基础镜像，而产品团队则被鼓励在 Foundation AMI 之上构建自定义的“产品特定 AMI”，以满足各自应用的特殊需求，并负责其后续的生命周期管理。
 
 ---
 
 ## 关键概念
 
--
+- **Foundation AMI**: 基础机器镜像，是经过安全加固、集成标准组件并预配置好的操作系统模板。
+- **OS Hardening**: 操作系统加固，通过关闭不必要服务、优化内核参数和应用安全补丁来减少系统攻击面。
+- **CIS Benchmarks**: 由互联网安全中心制定的安全配置基准，用于衡量镜像是否符合行业最佳安全实践。
+- **HashiCorp Packer**: 一种开源工具，用于从单一源配置为多个云平台自动创建一致的机器镜像。
+- **SSM Agent**: AWS 系统管理器代理，用于实现实例的远程管理、自动化补丁更新和配置同步。
+- **AMI Sharing**: 镜像共享机制，通过授权其他账号访问中央镜像，避免了跨账号复制带来的额外存储成本。
+- **Central Repository**: 中央仓库，用于统一存放和管理经过验证的官方镜像，确保分发源的唯一性。
 
 ---
 
-## 行动项
+## 相关视频
 
--
-
----
+> [!info]+ 交叉引用
+> [[Cloud Transformation Program Overview]] — 了解转型计划的背景与整体框架
+> [[Guardrail Rules and Compliance]] — 关联 Foundation AMI 在合规性检查中的角色
+> [[CCOE Portal User Guide]] — 如何在门户网站订阅 AMI 更新通知
 
 ## 相关视频
 

knowledgebase/DevOps & SRE/01_AWS-Landing-Zone/ctp-topic-28-aws-tag-validation-tool.md

@@ -12,7 +12,7 @@ tags:
 date-added: 2026-04-14
 video-source: "nas:///volume2/work/Public Cloud Learning Sessions/CTP _ Topic 28_ AWS Tag Validation Tool.mp4"
 audio-source: ""
-status: raw
+status: summarized
 ---
 
 # CTP Topic 28 AWS Tag Validation Tool
@@ -27,21 +27,31 @@ status: raw
 
 ## 摘要
 
-> 待转录后由 LLM 生成
+> 本次视频由 Lewis Brown 主讲，重点介绍了由 SRE 团队开发的一款 **AWS 标签验证工具（AWS Tag Validation Tool）**。在 AWS 架构中，标签（Tags）不仅是简单的元数据（键值对），还直接影响网络安全。该组织使用的 Checkpoint 防火墙会读取 EC2 实例、安全组和负载均衡器的标签值来配置网络访问权限；如果标签无效或缺失，防火墙将拦截相关网络流量。
+> 
+> 虽然目前已通过服务控制策略（SCPs）在组织层面拦截了不合规资源的创建（目前主要应用于 SAS 账户），但对于大量已经存在的存量资源，仍需有效的审计手段。为此，Lewis 展示了这款基于 Python 和 Boto3 开发的工具。该工具通过读取包含各账户预定义合法标签值的 YAML 配置文件，自动扫描指定账户内的 EC2、安全组、负载均衡器及 Lambda 函数，并将扫描结果与预期值进行比对。
+> 
+> 工具最终会生成一份详尽的 CSV 报告，列出所有缺失或标签值错误的资源 ID 及其具体问题，极大提高了审计效率。在演示环节，Lewis 展示了如何通过 Poetry 管理 Python 环境并运行该脚本。此外，视频还讨论了标签在未来成本核算（Costing）中的潜在用途，即通过标签区分同一账户下不同产品的资源消耗。
 
 ---
 
 ## 关键概念
 
--
+- **AWS Tags**: 附加在 AWS 资源上的元数据，以键值对（Key-Value pairs）形式存在，用于识别和管理资源。
+- **Checkpoint Firewall**: 一种网络安全解决方案，在本案例中通过读取资源标签来动态配置和执行网络访问策略。
+- **Service Control Policies (SCPs)**: AWS Organizations 的一种策略，用于集中管理组织中所有账户的最大可用权限，此处用于强制执行标签规范。
+- **Boto3**: 适用于 Python 的 AWS SDK，允许开发者通过编写 Python 代码来调用 AWS 服务接口。
+- **Poetry**: 一个 Python 依赖管理和打包工具，用于确保开发环境的一致性并简化工具的安装与运行。
+- **variables.yaml**: 该工具的核心配置文件，定义了特定 AWS 账户所期望的合法标签键及其对应的允许值列表。
+- **SRE Tools Repository**: 存放该验证工具及其他 SRE 自动化脚本的内部代码仓库。
 
 ---
 
-## 行动项
+## 相关视频
 
--
-
----
+> [!info]+ 交叉引用
+> [[CTP Topic 10 - AWS Tagging Deep Dive]] — 演讲者提到的相关视频，详细介绍了标签的技术细节与标准。
+> [[AWS Landing Zone Governance]] — 关联原因：讨论了新旧登陆区（Landing Zone）中通过标签进行治理的背景。
 
 ## 相关视频