记录 · AI Times

github跟git产生了哪些不一致的特性呢？

Wed, 29 Apr 2026 10:59:32 +0800

这是一个很好的问题。GitHub 在 Git 之上确实引入了不少”非标准”或”扩展”特性，有些甚至和 Git 原生的设计哲学产生了微妙的张力。我来系统梳理一下：

1. Pull Request（最核心、最显著的差异）

维度	标准 Git	GitHub
协作模型	直接 push/merge	通过 fork + PR 间接合并
权限假设	所有协作者都有仓库写权限	贡献者通常没有上游仓库写权限
代码审查	无内置机制	PR 内置 Review、Comment、Approve
讨论空间	commit message	PR 页面成为主要讨论场所

本质差异：Git 假设协作双方是平等的（都有写权限），GitHub 则假设贡献者和维护者是不平等的。

2. Fork 与”伪分布式”

Git 的设计是真正分布式的——每个 clone 都是完整的仓库，没有”中心”概念。

但 GitHub 的 Fork 机制实际上在心理上和流程上制造了一个”中心”：

你的 fork 是”副本”，上游是”正本”
PR 只能从一个 fork 指向另一个仓库
虽然技术上任何两个仓库都可以互相 push/pull，但 GitHub 的 UI 和流程都围绕”上游-下游”展开

这导致很多人误以为 Git 是”中心化”的——其实 Git 本身不是，是 GitHub 的 UX 让它看起来像。

3. Issues、Wiki、Projects、Actions——这些都不是 Git

功能	是否属于标准 Git	说明
Issues（议题）	❌ 不是	GitHub 的独立数据库系统
Wiki	❌ 不是	GitHub 自己的 Wiki 引擎
Projects（看板）	❌ 不是	GitHub 的项目管理工具
Actions（CI/CD）	❌ 不是	GitHub 的自动化平台
Releases	❌ 不是	基于 Git tag 的附加功能
Discussions	❌ 不是	论坛功能

这些功能的数据不存储在 Git 仓库里，而是 GitHub 自己的数据库中。如果你把仓库 clone 到本地，这些信息是拿不到的。

4. Merge 策略的”魔法”

GitHub 提供了几种 PR 合并方式，这些在标准 Git 里需要手动操作：

方式	标准 Git 等价操作	GitHub 的便利
Create a merge commit	`git merge --no-ff`	一键完成，自动生成 PR 编号引用
Squash and merge	`git merge --squash` + 手动 commit	自动压缩所有 commit，重写历史
Rebase and merge	`git rebase` + `git merge --ff-only`	自动变基，保持线性历史

GitHub 的 PR 合并还会自动：

在 commit message 中插入 Closes #123 等关键字来关联 Issue
触发 Webhook 通知外部系统
在 PR 页面显示合并后的状态

5. Protected Branches（分支保护）

标准 Git 对分支没有任何权限控制——只要你有仓库访问权，你可以对任何分支做任何事。

GitHub 引入了分支保护规则：

禁止直接 push 到 main
强制要求 PR + Review
强制要求 CI 通过
要求签名 commit

这在 Git 原生中完全不存在，是 GitHub 在服务器端的逻辑层实现的。

6. GitHub Flavored Markdown（GFM）

GitHub 对标准 Markdown 做了大量扩展：

@username 提及用户
#123 引用 Issue/PR
sha 自动链接到 commit
Task lists (- [ ])
Emoji :rocket:
Mermaid 图表、数学公式等

这些在标准 Markdown 或 Git 中都不存在。

7. Git LFS（Large File Storage）

Git 本身不擅长处理大文件（视频、二进制资源等），因为每次改动都会保存完整副本，导致仓库膨胀。

GitHub 推出了 Git LFS：

大文件不直接存到 Git 对象数据库
而是存到 GitHub 的 LFS 服务器
Git 仓库里只存一个指针文件

这算是 GitHub 对 Git 原生缺陷的一个补丁式扩展。

8. GitHub Codespaces / GitHub.dev

直接在浏览器里编辑代码、运行开发环境——这和 Git 的”本地工作流”理念已经相去甚远了。Git 假设你在本地有完整的文件系统和工具链，GitHub 则试图把一切都搬到云端。

总结：GitHub 到底”扩展”了什么？

可以把 Git 和 GitHub 的关系理解为：

Git = 分布式版本控制协议（底层）
GitHub = 基于 Git 的协作平台 + 项目管理工具 + 社交网络（上层）

GitHub 引入的特性大致分为几类：

类别	例子	目的
协作流程	PR、Fork、Review	解决开源/大团队权限和审查问题
项目管理	Issues、Projects、Milestones	把代码和任务管理绑定
自动化	Actions、Webhooks、Apps	构建 CI/CD 生态
社交功能	@提及、Emoji、Reactions	降低沟通门槛
存储扩展	LFS、Packages	弥补 Git 原生不适合的场景

最后说一句：这些”不一致”不一定是坏事。Git 的设计哲学是”简单、灵活、去中心化”，而 GitHub 的设计哲学是”让协作尽可能低门槛”。两者目标不同，所以产生了这些差异。很多开发者其实没用过纯 Git 的工作流，他们的”Git 经验”本质上大部分是”GitHub 经验”——这也算是一种有趣的认知偏移吧 😄

mobile-security-2026

Fri, 24 Apr 2026 14:46:42 +0800

2026年移动端安全技术全景分析：iOS vs Android

从早期”裸奔”到多层纵深防御，移动安全到底进化了多少？

一、早期痛点回顾：那些年我们踩过的坑

痛点	早期状况	严重程度
APK反编译	`apktool + dex2jar + JD-GUI` 三件套，几分钟还原Java源码	🔴 致命
硬编码密钥	API Key、Secret直接写在代码或配置里，反编译后一目了然	🔴 致命
明文存储	SharedPreferences / SQLite明文存储，Root设备直接可读	🟠 严重
二次打包	修改APK重签名，植入广告/恶意代码再分发	🟠 严重
中间人攻击	HTTP明文传输，公共WiFi下流量可被截获	🟠 严重
iOS越狱	越狱后Keychain可被导出，App沙盒形同虚设	🟡 中等

二、Android 安全进化路线

2.1 代码保护：从裸奔到虚拟化

进化路径：ProGuard混淆 → R8优化混淆 → Native SO加固 → DEX加壳 → 代码虚拟化

技术层级	原理	防护强度	性能损耗	现状
R8代码混淆	类名/方法名/变量名替换为a.b.c	⭐⭐	几乎无	2026年已是标配底线，但仅防脚本小子
Native NDK	核心逻辑用C/C++实现，编译为.so	⭐⭐⭐	低	加密/认证等关键逻辑推荐放入Native层
DEX加壳	运行时动态解密DEX加载	⭐⭐⭐	中	主流方案，但已被多种脱壳工具针对
代码虚拟化(VMP)	将字节码转为自定义指令集，在私有VM执行	⭐⭐⭐⭐⭐	较高	2026年最强方案，逆向需理解自定义指令集
编译级加固	在LLVM编译阶段进行代码变换/混淆	⭐⭐⭐⭐	低	性能友好，兼容性好，2026年新趋势

2026年主流加固厂商：梆梆安全、360加固宝、爱加密、几维安全、网易易盾、绿盟、深信服、顶象等。技术路线正从”DEX加壳”向”虚拟化 + 编译级加固”双轨演进。

2.2 密钥保护：从硬编码到硬件级

方案	安全等级	说明
❌ 硬编码在代码/配置	不可接受	反编译即暴露，2026年已无任何借口
⚠️ 资源加密存储	低	运行时AES解密，但密钥本身仍有存储问题
✅ Android Keystore	高	密钥存储在系统Keystore中，应用进程无法直接提取密钥材料
✅ 硬件背书Keystore	极高	密钥存储在TEE/StrongBox安全芯片中，即使Root也无法提取

Android Keystore 关键特性：

密钥不可导出：密钥材料从不离开Keystore，应用只能请求加密/解密操作
用户认证绑定：可设定密钥使用必须经过生物识别/锁屏验证
密钥认证(Key Attestation)：可向后端证明密钥确实由硬件生成，非软件模拟
StrongBox：Pixel等设备配备独立安全芯片(HSM)，密钥存储在物理隔离的硬件中

// 2026年推荐的密钥生成方式 – 硬件绑定 + 生物识别绑定
val keyGenParameterSpec = KeyGenParameterSpec.Builder(
 “my_key_alias”,
 KeyProperties.PURPOSE_ENCRYPT or KeyProperties.PURPOSE_DECRYPT
)
 .setBlockModes(KeyProperties.BLOCK_MODE_GCM)
 .setEncryptionPaddings(KeyProperties.ENCRYPTION_PADDING_NONE)
 .setRandomizedEncryptionRequired(true)
 .setUserAuthenticationRequired(true) // 使用密钥需生物识别
 .setUserAuthenticationValidityDurationSeconds(30)
 .setIsStrongBoxBacked(true) // 强制使用StrongBox安全芯片
 .build()

2.3 数据存储保护

场景	早期方案	2026年方案
KV存储	SharedPreferences明文	EncryptedSharedPreferences（自动AES加密）
数据库	SQLite明文	SQLCipher（AES-256整库加密）+ Keystore管理密钥
文件存储	明文写入	Data Protection API（设备锁定时不可访问）
网络通信	HTTP明文	TLS 1.3 + Certificate Pinning

2.4 AAB格式与Google Play安全

2021年起Google Play强制AAB格式，带来安全变化：

不再分发完整APK：Google根据设备配置按需生成APK（split APKs），攻击者无法从商店获取完整包
Google Play App Signing：签名密钥由Google云端保管，开发者只持上传密钥，降低密钥泄露风险
Play Integrity API（替代SafetyNet）：向后端证明App未被篡改、运行在正版Android设备上

2.5 防篡改与运行时保护

技术	说明
签名校验	运行时比对APK签名哈希，检测是否被重签名
完整性校验	SHA-256校验DEX/SO文件，检测代码注入
Root/模拟器检测	检测运行环境安全性
Play Integrity API	服务端验证设备/App完整性
反调试	检测ptrace附加、调试器标志位
运行时自校验	代码运行时检查自身是否被修改

三、iOS 安全进化路线

3.1 硬件安全架构（iOS天然优势）

iOS从芯片层构建了完整的安全信任链：

Secure ROM (Boot ROM) → iBoot → Kernel → App
 ↓ ↓
Secure Enclave ←→ 内存保护引擎 ←→ 加密引擎

组件	功能	安全等级
Secure Enclave	独立协处理器，物理隔离，运行独立OS	🔐 硬件级
内存保护引擎	对Secure Enclave内存进行实时加密	🔐 硬件级
加密引擎	AES专用硬件，文件加密/解密零性能损耗	🔐 硬件级
Secure ROM	不可修改的引导代码，信任链起点	🔐 硬件级

3.2 密钥与数据保护体系

iOS数据保护层级（2026年）：

保护级别	说明	适用场景
`NSFileProtectionComplete`	设备锁定时完全不可访问	顶级敏感数据（密码、金融）
`NSFileProtectionCompleteUnlessOpen`	已打开的文件可继续读写	后台下载/上传任务
`NSFileProtectionCompleteUntilFirstUserAuthentication`	用户首次解锁后可访问	大部分App数据
`NSFileProtectionNone`	随时可访问	不推荐，仅非敏感缓存

密钥层次结构：

用户密码 → 生成Passcode Key
 ↓
Passcode Key + 硬件UID → 文件级加密密钥
 ↓
文件密钥 → 由Secure Enclave保护
 ↓
元数据 → 由文件系统密钥(DPFK)加密

每一层密钥由上一层加密保护，最终追溯到硬件UID（烧录在芯片中，不可读取）。

3.3 2026年iOS关键安全特性

特性	说明	状态
TLS 1.3强制	ATS最低加密标准升级为TLS 1.3，旧协议App将被审核拒绝	✅ 已强制
App Attest	DCAppAttestService，证明请求来自未修改的真实App	✅ 推荐
隐私清单	所有App必须声明数据收集行为，模糊描述不再接受	✅ 已强制
Keychain强制	敏感凭证必须用Keychain存储，禁止UserDefaults	✅ 强烈推荐
生物识别密钥绑定	密钥使用需经Face ID/Touch ID认证	✅ 可用
抗量子加密	Apple已在iOS中集成抗量子加密算法	🧪 推进中

3.4 App Attest 防护链

App请求 → DCAppAttestService生成加密证明
 ↓
证明包含：App的签名哈希 + 设备硬件标识
 ↓
后端验证：确认来自真实设备上未修改的App
 ↓
拒绝：模拟器/越狱/重签名App的请求

四、跨平台安全技术对比

4.1 核心安全能力对比

安全维度	Android (2026)	iOS (2026)
代码保护	混淆+加壳+虚拟化（多层级可选）	加密+App Attest（系统级保障更强）
密钥硬件保护	StrongBox HSM（部分设备）	Secure Enclave（全系标配）
TEE/安全芯片	TEE可选，StrongBox仅高端设备	Secure Enclave全系标配
密钥认证	Key Attestation	App Attest
数据加密	EncryptedSharedPreferences + SQLCipher	Data Protection + Keychain
通信安全	Network Security Config + Pinning	ATS + Certificate Pinning
完整性验证	Play Integrity API	App Attest + DeviceCheck
隐私合规	权限声明+数据最小化	隐私清单（强制）
抗量子	研究中	已集成部分算法
默认安全基线	⚠️ 依赖开发者主动配置	✅ 系统默认较高

4.2 开发者必须做的事（2026年）

Android开发者清单：

R8混淆是底线，不是终点
密钥必须用Android Keystore，绝不再硬编码
数据库用SQLCipher，KV存储用EncryptedSharedPreferences
网络全量TLS 1.3 + Certificate Pinning
高安全场景接入Play Integrity API
核心逻辑考虑Native层或加固方案
接入密钥认证(Key Attestation)防中间人

iOS开发者清单：

敏感数据用Keychain，不用UserDefaults
正确选择Data Protection级别
接入App Attest防篡改
使用CryptoKit + Secure Enclave保护密钥
提供完整隐私清单
生物识别提供回退方案
ATS严格模式，不轻易配置例外

五、鸿蒙(HarmonyOS)安全体系补充

作为中国第三大移动OS，鸿蒙的安全架构值得了解：

组件	说明
iTrustee TEE	华为自研可信执行环境，基于ARM TrustZone
安全元件(SE)	独立安全芯片，存储支付/生物数据
电子围栏	感知环境风险，主动加强数据保护
应用沙盒强化	更严格的跨应用数据隔离
分布式安全	多设备间安全认证与数据传输

六、结论：从”防不住”到”防得住”

维度	5年前	2026年
反编译难度	几分钟还原源码	虚拟化/VMP下需数周专业逆向
密钥安全	硬编码=裸奔	硬件级Keystore/Secure Enclave，Root也无法提取
数据存储	明文存本地	全链路加密，设备锁定时不可访问
通信安全	HTTP到处飞	TLS 1.3强制，证书锁定标配
完整性	随便改随便签	服务端App Attest/Play Integrity验证
默认安全	开发者全靠自觉	系统强制安全基线（ATS、隐私清单等）

核心结论：2026年的移动安全已经从”开发者自觉”进入了”系统强制+硬件兜底”的时代。早期那些硬编码密钥、明文存储、裸奔APK的问题，在当今的技术体系下已经没有借口再犯。但安全是永恒的军备竞赛——抗量子加密、AI辅助攻击等新挑战正在到来。

分析日期：2026年4月24日 | 基于公开资料整理

持仓票，让AI帮忙分析，存档等验证

Fri, 12 Dec 2025 09:41:57 +0800

穿越周期的铜箔龙头：建滔积层板2025财报透视.pptx

https://s3.ap-east-1.amazonaws.com/my-helpful-ai/public/%E7%A9%BF%E8%B6%8A%E5%91%A8%E6%9C%9F%E7%9A%84%E9%93%9C%E7%AE%94%E9%BE%99%E5%A4%B4%EF%BC%9A%E5%BB%BA%E6%BB%94%E7%A7%AF%E5%B1%82%E6%9D%BF2025%E8%B4%A2%E6%8A%A5%E9%80%8F%E8%A7%86.pptx

泡泡玛特：四季财报透视与2026增长边界.pptx

https://s3.ap-east-1.amazonaws.com/my-helpful-ai/public/%E6%B3%A1%E6%B3%A1%E7%8E%9B%E7%89%B9%EF%BC%9A%E5%9B%9B%E5%AD%A3%E8%B4%A2%E6%8A%A5%E9%80%8F%E8%A7%86%E4%B8%8E2026%E5%A2%9E%E9%95%BF%E8%BE%B9%E7%95%8C.pptx

在内地，下个docker镜像都是难事

Wed, 11 Dec 2024 10:33:59 +0800

仅仅因为个别恶意的内容，就屏蔽了整个dockerhub，然后强制下了国内的各种加速站点，现在运行个img，都是登天难事。弄开发弄个环境都可以劝退80%，呵呵。

试了一些加速站之类的方案，都不容易行得通，目前自己走通的一个路：

1.本机安装docker，跳墙，下镜像（macM4Max 下的平台是arm64,适配linux环境需要指定镜像平台）
docker pull –platform=linux/amd64 garethflowers/svn-server

2.使用save参数进行打包镜像文件到tar，

格式如：docker save -o tar文件名称镜像REPOSITORY:TAG

docker save -o yolov5-v6.2.tar yolov5:v6.2

3.在目标机器使用load进行从tar文件导入镜像

docker load -i yolov5-v6.2.tar

阿里云-新加坡C区重大事故

Sat, 14 Sep 2024 09:39:55 +0800

====更新9.19 今天OSS恢复了，但是状态页面还有13个异常显示===
oss不可用从10号到19号，9天了。好在虽然是本地容灾，数据都还在。

从9.10出事到今天，已经5天了。这里面有阿里云的错，也有我们自己的错：

1.OSS新加坡节点开始图个便宜，用的单可用区容灾没有选多可用区容灾（美国弗吉尼亚根本就不支持多可用区容灾，出问题只能干瞪眼）

2.阿里云新加坡机房虽然等级很高、安全认证很多，但是从事件详情里面看出—因为你在国外，要遵循国外的制度。

10日早上火灾，12日傍晚运维人员才被批准进入机房。这种人祸是无论多少技术实施都无法弥补的。

维护12个月免费期后的AWS资源需要花多少钱

Tue, 04 Jun 2024 12:36:58 +0800

来，321,上照片，扣扣搜搜的需要美金$19刀。

Route53 是因为托管了2个域名的解析，现在已经删了一个，可以节省$0.5

EC2 机器是一个12个月免费的实例t3.micro， 2核1g的配置，月供$10.86。
挂了一个30GB的云盘，月供$3.97

现在IP4也是开始收费了，所以我去掉了之前的负载LBS（也有公网IP），现在就机器自己的一个ip，月供 $3.72.

目前这个资源子托管了mysql，wordpress用起来还算顺利。

GitHub Archive Program

Mon, 20 May 2024 12:19:54 +0800

偶然间闲逛发现一个github的存档项目。理念挺有意思的，为后代保存开源软件
https://archiveprogram.github.com

这里提到了他们通过多副本，存储介质等手段，来设计实现至少保存1000年的长期存档。

给Let’sEncrypt免费证书打个call

Tue, 12 Mar 2024 15:47:02 +0800

之前阿里云可以免费申请到1年的单域名SSL证书，现在改成了3个月免费（1年期60元/年），对手工部署、续期带来了非常大的不便。

后续查找方案看到了 Let’s Encrypt – 免费的SSL/TLS证书 (letsencrypt.org) ，非常方便简洁。

其提供的Certbot ACME 客户端，可以自动在linux/win nginx,apache2 等常见的负载工具进行自动申请证书、自动展期、自动部署。

ps.在windows下更新nginx证书碰到的一个坑：命令行启动的nginx，在关掉命令窗口之后，居然还有后台进程在跑。然后改证书、起新nginx，发现站点居然没有生效新证书。各种地方都进行了一轮排查，直到最后才想起这么一茬，在进程管理清理干净所有nginx之后再启动的就可以了。

强烈推荐APPLE下的WPS

Wed, 26 Jul 2023 09:44:41 +0800

windows电脑的office订阅在mac下无效，非365的mac下甚至只能阅读无法编辑。

抱着试试看买了wps的年费（128元），惊艳了：

1.mac下速度、文件格式远超office，甚至流程图、脑图啥的都可以搞定。

2.送的稻壳商城下载真不错。。。会员可以下载很多资料。还可以搜文档模板，相当于买了个B度文库会员。

操蛋的FB数据安全评估

Tue, 25 Jul 2023 12:03:33 +0800

这公司自己在隐私方面一塌糊涂，对开发者却是极其不友好。这么一套评估下来，还有几个公司可以用？

bing的中文翻译，对日期的支持是真烂

Wed, 10 May 2023 16:12:10 +0800

[Submitted on 20 Dec 2021 (v1), last revised 13 Apr 2022 (this version, v2)]
[提交于 20 年 2021 月 1 日（v13），最后修订于 2022 年 2 月 <> 日（此版本，v<>）]

bing页面翻中文，基本日期翻译都要错。。。

多语言环境下，日期的排列就是个很恶心的事情。我们习惯了 Y/M/D 而欧美甚至hk 会出现 M/D/Y 以及 D/M/Y

另外一个就是简写，比如Dec ，Apr（不过按说都是标准格式）和数字的混合

中特估

Tue, 09 May 2023 00:03:03 +0800

中特估”是**“中国特色估值体系”**的简称。是的，依然是“中国特色”。

“中特估”主要以央企、国企以及一些特殊行业的上市公司为主，涉及通信/计算机、建筑、能源/电力、军工、银行等板块，多为具有强现金流、高分红、低估值特点的价值蓝筹股（约计130只个股），提倡的是一种央国企股票的投资机会

这一概念最早被A股市场关注，是2022年11月21日，证监会主席易会满在金融街论坛年会上提出：“要深入研究成熟市场估值理论的适用场景，把握好不同类型上市公司的估值逻辑，探索建立具有中国特色的估值体系，促进市场资源配置功能更好发挥”。在2023年的政府工作报告中，深化国资国企改革，提高国企核心竞争力也成为未来重点工作内容之一。

从官方角度讲，“中特估”已被提升至一定重要的战略地位，核心点是深化国企改革、提高国企估值、做大做强国企。

至jian不过facebook，安全要求屁事多，平台垃圾

Fri, 05 May 2023 15:22:54 +0800

数据安全要求照此填表都得填一天。能做完的，是神仙

数据安全要求

根据要求，有权访问特定类型 Meta 开放平台数据的应用都必须完成年度数据保护评估 (DPA)。数据保护评估旨在确定开发者在使用、分享和保护开放平台数据方面是否遵守了 Meta 开放平台条款的要求。数据保护评估调查问卷的一部分内容围绕开放平台条款 6 展开，该条款概述了数据安全要求。我们建议您参阅本文档，了解 Meta 开放平台条款在数据安全使用和处理方面规定的期望、要求和相关证据。请注意，本文档末尾整理了一份术语表，其中列有关键术语及其定义。

在本文档中，短语服务器端是对组织用于处理开放平台数据的任何后端环境的简称，无论是在 Amazon Web Services (AWS) 等云托管服务上运行，由开发者在共享或独有的数据中心托管，还是采用混合托管模式（结合使用这些方案）。

客户端要求则涉及在浏览器内、移动设备上、桌面设备和笔记本电脑的应用内以及用户使用的其他类型设备上处理开放平台数据的操作。

回答数据安全问题要做好的准备工作

数据流程

创建（或视需要更新）一张数据流程图或一篇介绍，说明应用或系统是如何处理开放平台数据的。

客户端 — 包括所有客户端软件，例如浏览器、移动设备及其他任何受支持的设备类型。
服务器端 — 包括任何相关的服务器或云环境，并找出：
1. 在开放平台数据经历以下环节时所用到的服务器组件：
  1. 进入或退出服务器环境（例如 web 监听器和 REST API）
  2. 写入永久或持久性存储位置，例如数据库、磁盘或日志文件
2. 托管模式，例如：
3. 自托管：组织在自己拥有或与其他方共有的数据中心运行自己的服务器。
4. 基础设施即服务（Infrastructure as a Service，简称“IaaS”）：例如 AWS EC2、Microsoft Azure IaaS 和 Google Compute Engine。
5. 平台即服务（Platform as a Service，简称“PaaS”）：例如 AWS Elastic Beanstalk、Google App Engine 和 Force.com。
6. 后端即服务（Backend as a Service ，简称“BaaS”）：例如 AWS Amplify、Azure Mobile Apps、Firebase 和 MongoDB Switch。
7. 混合托管：结合使用上述多种托管模式。

最后，务必在数据流程图或介绍中回答以下问题：

在客户端和服务器端软件中（如适用于系统设计），Meta API 访问口令是在哪里生成和传输/存储/更新的？
您如何从 Meta API 提取开放平台数据，尤其当您想要获取个人身份识别信息 (PII) 时，例如用户的姓名、性别、生日、电子邮箱和其他用户数据？
您是如何使用、存储和传输这些数据的？
开放平台数据是否发送给了任何第四方？

准备证据

您可能需要提交证据，以佐证您对自己所执行的数据安全保护措施的相关回答。我们建议您阅读本文档中的“证据提交指南”，查看可接受的证据示例并相应地准备证据。我们接受常见的文件类型以及截图和录屏。请确保文件未设置密码保护。您可以上传多个文件，但每个文件不可超过 2 GB。我们接受的文件格式包括 .xls、.xlsx、.csv、.doc、.docx、.pdf、.txt、.jpeg、.jpg、.png、.ppt、.pptx、.mov、.mp4、.zip 和 .zipx。

在提交证据之前，请确保您已消除（移除）其中的敏感数据。

证据类型

对于需要上传数据安全保护相关证据的应用，Meta 规定必须提供两种不同类型的文档：

政策或程序类证据：解释您采取[此项保护]措施保护数据安全所遵循的政策或程序文档
执行类证据：来自系统或应用程序的证据，例如工具配置信息或截屏，表明您是如何执行某项保护措施的

政策或程序类证据

政策或程序类证据，有时被称为一种管理控制手段，是用来介绍特定数据安全保护措施的书面文档。这类证据存在多种不同的形式，例如一系列内部政策的摘录、内部维基页面的部分或全部内容，或者您在没有任何现成文档的情况下新建的用来介绍相关措施的文档。在任何情况下，您上传的政策或程序类证据都必须解释清楚某数据安全保护措施与 Meta 的要求之间的联系。您只需提供与 Meta 安全审核相关且必要的政策或解释，或者通过对开放式问题的作答，引导我们的审核员查看相应部分的内容。

执行类证据

执行类证据是指，直接通过截图和录屏证明您实际上是如何执行特定政策或程序的。由于开发人员使用的工具配置各不相同，因此我们提供的示例无法涵盖每种情况。即便如此，执行类证据还是应当尽可能地以我们提供的示例为参照标准来展示相关细节。

证据的完整性

我们理解，要准备执行类证据来给某项数据安全保护措施全面举证，这可能会造成过于沉重的负担。考虑到这一点，您应当按照以下指南提交证据，并且在提交证据之前，应小心消除其中的敏感数据：

政策或程序类证据必须清楚表明您符合甚至超出了 Meta 的要求
1. Meta 将审核政策或程序类证据，以判断特定的保护措施是否如声明的那样符合 Meta 的要求。
2. 您应当给文档添加注释，醒目标出需要注意的部分
3. 例如，对于向传输开放平台数据的所有网络连接启用 TLS 1.2 或更高版本加密协议的保护措施，文档中应清楚说明以下事项，方可作为可接受的证据：
4. 来自 Meta 的开放平台数据绝不能以未加密的格式在不可信的网络上传输
5. 所有接收或返回开放平台数据的 web 监听器（例如，面向互联网的负载均衡器）将被配置为启用 TLS 1.2
6. 所有接收或返回开放平台数据的 web 监听器将被配置为禁用以下各项：SSL v2、SSL v3、TLS 1.0 和 TLS 1.1
执行类证据必须就各项政策或程序的执行提供一个或多个示例
1. 您必须上传一个或多个文档、截图或工具配置，以此来证明您是如何执行各项保护措施的
2. Meta 将审核执行类证据，以确保这些证据与相关的政策或程序类证据要求相符
3. 例如，对于向传输开放平台数据的所有网络连接启用 TLS 1.2 或更高版本加密协议的保护措施，证据可接受的前提是，其中应包含根据政策或程序配置的一个网域的 Qualys SSL 测试报告。

证据中应消除的敏感数据

请勿提交以可读（未消除）形式展示以下任意信息的证据。如果您要使用图像编辑器来生成截图，请用黑框遮挡这些信息。如果您使用的是 PDF 编辑器，请不要在保留文本的基础上只做简单的遮挡处理，而是一定要使用能真正移除文本的工具（例如，Apple Preview 应用中的 Redact [文本消除]工具），以确保您已真正消除这些信息。

健康信息
财务信息
IP 地址
密码、登录信息和访问口令
加密密钥
实际地址
可以直接或间接识别自然人（不包括企业或其他企业组织)、员工或其他关联方的个人身份识别信息 (PII)，例如：
- 姓名
- 电子邮箱
- 用户编号
- 生日
- 地址信息
- 健康信息
- 文化、社会、政治身份
- 结合证据中的特定背景可识别到个人的信息
重现漏洞的分步详情（例如，在渗透测试报告中）
开发者知道或理应知道的来自或有关 13 岁以下儿童的数据

通过静止数据加密保护存储在服务器端的开放平台数据

问题：您是否对存储在云端、服务器或数据中心环境中的所有开放平台数据进行静止数据加密？

提问意图说明

静止数据加密会使得数据在无单独的解密密钥的情况下无法解读，以此保护开放平台数据。这为防止未经授权读取数据提供了一层额外保护。

在服务器或云环境中，与应用的所有用户相关的开放平台数据倾向于集中存储，而静止数据加密能降低数据泄露的风险。
例如，静止数据加密可以防范类似于未经授权访问数据库备份的威胁，而生产数据库对此类威胁的防范并非如此严密。

要求一览

如果您在服务器端存储开放平台数据：

您必须通过以下方式来保护数据：
- 通过静止数据加密，或
- 通过可接受的其他保护措施（参见“可接受的其他保护措施”）
针对所使用的加密类型：
- 无论是应用程序层级（例如通过软件对数据库中的特定栏进行加密/解密）还是全磁盘层级的加密均可
- 尽管我们推荐使用行业标准加密技术（例如 AES、BitLocker、Blowfish、TDES、RSA），但对具体的算法或密钥长度并无要求

如果开发者不在服务器端存储开放平台数据，则不适用该要求。

特殊情况

使用 IaaS、自托管或混合托管在服务器端存储数据

如果您使用 IaaS 托管（例如 AWS EC2、Microsoft Azure IaaS 和 Google Compute Engine）、自托管或混合托管方法存储开放平台数据，那么这个问题不适用。

使用 SaaS、PaaS 或 BaaS 产品在服务器端存储数据

不过，有些后端托管模式属于特殊情况：

如果您仅通过以下任何产品（而未使用 IaaS、自托管或混合托管）存储开放平台数据，那么这个问题不适用。您需要做的就是，在数据保护评估 (DPA) 的服务提供商部分描述这种关系。

BaaS — 例如：AWS Amplify、Azure Mobile Apps、Azure Playfab、Google Firebase 和 MongoDB Switch
PaaS — 例如：AWS Elastic Beanstalk、Google App Engine、Force.com
SaaS — 例如：MailChimp 或 Salesforce

使用 Meta API 在服务器端存储数据

如果您仅通过某个 Meta API（例如在小游戏 SDK 中使用 player.setDataAsync()）存储开放平台数据，那么这个问题不适用。

证据提交指南

如果您需要提交有关已落实该保护措施的证据，请按照“准备证据”部分的说明，准备好政策/程序类和执行类证据。

执行类证据示例

AWS RDS

AWS RDS — 可在 AWS RDS 中配置静止数据加密，开发者必须确保将配置选项设为应用这项保护服务。

对于包含开放平台数据的代表性 RDS 实例，使用 AWS CLI 工具获取其 StorageEncrypted 配置。

# List RDS instances in default region
$ aws rds describe-db-instances \
 --query 'DBInstances[*].DBInstanceIdentifier'

[
 "database-1",
 "database-2"
]

# For each instance returned, retrieve the storage encrypted config
$ aws rds describe-db-instances \
 --db-instance-identifier database-1 \
 --query 'DBInstances[*].StorageEncrypted'
[
 true
]

$ aws rds describe-db-instances \
 --db-instance-identifier database-2 \
 --query 'DBInstances[*].StorageEncrypted'
[
 true
]

AWS DynamoDB

AWS DynamoDB 默认进行静止数据加密。您可以为使用这些命令的表格获取静止数据加密配置。

$ aws dynamodb list-tables --output table

--------------
| ListTables |
+------------+
||TableNames||
|+----------+|
|| Users ||
|+----------+|

$ aws dynamodb describe-table \
 --table-name Users \
 --query "Table.SSEDescription.Status"

"ENABLED"

AWS DocumentDB

AWS DocumentDB 必须经过配置才能应用静止数据加密。对于包含开放平台数据的代表性集群，使用这些命令获取 StorageEncrypted 配置。

$ aws docdb describe-db-clusters --query 'DBClusters[*].DBClusterIdentifier'

[
 "docdb-users"
]

$ aws docdb describe-db-clusters \
 --db-cluster-identifier 'docdb-users' \
 --query 'DBClusters[*].StorageEncrypted'
[
 true
]

AWS S3

可配置 AWS S3 存储桶，以便对在存储桶内创建的所有对象应用静止数据加密。使用这些命令来列出存储桶并获取默认存储桶加密配置。

$ aws s3api list-buckets --output table --query "Buckets[*].Name"

---------------------------------------------
| ListBuckets |
+-------------------------------------------+
| platform.storage |
+-------------------------------------------+

$ aws s3api get-bucket-encryption \
 --bucket platform.storage \
 --query "ServerSideEncryptionConfiguration.Rules[*].ApplyServerSideEncryptionByDefault" \
 --output table
---------------------
|GetBucketEncryption|
+-------------------+
| SSEAlgorithm |
+-------------------+
| AES256 |
+-------------------+

Microsoft Azure

请查阅与组织的服务使用相关的 Microsoft Azure 静止数据加密文档。

Google Cloud Platform

请查阅 Google Cloud Platform 上的 Google 静止数据加密文档。

可接受的其他保护措施

如果您不在服务器端环境中采用静止数据加密，您可以使用可接受的其他方法来保护开放平台数据。在此情况下，您应描述以下方面：

开放平台数据的敏感性 — 对特定开放平台数据的存储存在较低或较高风险。您将需要研究在服务器端存储了开放平台数据的哪个具体用户属性。
为降低产生特定伤害的可能性而应用的控制工具
1. 防止包含开放平台数据的网络被入侵的控制工具
2. 防止可以访问开放平台数据的应用/系统被入侵的控制工具
3. 防止包含开放平台数据的物理存储介质（如已停用的网络存储设备）丢失的控制工具
4. 防止包含开放平台数据的物理存储介质（如已停用的网络存储设备）丢失的控制工具
5. 防止未经授权访问包含开放平台数据备份的备份件的控制工具
证据强度 — 务必指出这些保护措施是否已由独立的审核员进行评估，例如作为 SOC2 审核的一部分进行的评估。

防止存储在组织设备和可移动媒体上的开放平台数据丢失

问题：具体对于存储在组织设备和个人设备上的数据：针对存储在这些设备上的所有开放平台数据，您是否采用了静止数据加密，或者制定了降低数据丢失风险的政策和规则？

提问意图说明

如果开发者允许将开放平台数据存储在员工笔记本电脑或可移动存储设备（例如 U 盘）等设备上，那么在设备丢失或被盗的情况下，数据将面临无授权访问的高风险。开发者应采取措施降低这种风险。

要求一览

为了降低开放平台数据被无授权访问的风险，开发者必须针对组织设备（例如笔记本电脑）和可移动媒体上的开放平台数据采取技术控制措施（首选）或管理控制措施（非首选，但可接受）。
- 技术控制措施 — 技术控制措施包括：1) 仅允许受管设备连接到公司网络，2) 在受管设备上执行全磁盘加密（例如使用 BitLocker），3) 阻止可移动媒体（例如 U 盘）连接到受管设备，4) 在受管设备上使用数据丢失防护 (DLP) 技术。
- 管理控制措施 — 管理控制措施包括关于在组织设备和个人设备上处理开放平台数据的可接受方式的书面政策文档和年度培训。

无论是否在服务器端处理开放平台数据，此要求都适用。

证据提交指南

如果您需要提交有关已落实该保护措施的证据，请按照“准备证据”部分的说明，准备好政策/程序类和执行类证据。

您可能正在使用以下其中一种或同时使用两种方法：a) 技术控制措施（例如，磁盘加密），或 b) 规则/政策，以降低存储在笔记本电脑和手机等组织设备上的开放平台数据的丢失风险。

技术控制措施可能包括：

阻止非受管设备连接到敏感服务，例如生产网络
在受管设备上执行磁盘加密（例如，通过 Windows 上的 BitLocker 或 Mac 上的 FileVault）
阻止在受管设备上使用可移动媒体（例如 U 盘）
在受管设备上使用 DLP 软件来阻止对开放平台数据的不当处理（例如，通过电子邮件附件发送数据）

规则/政策可能包括：

描述一般情况下处理数据（特别是开放平台数据）的可接受方法和不可接受方法的文档。
督促组织成员学习数据保护指南的机制（例如，在劳动合同中添加的相关规定、数据安全培训、通过电子邮件发送的定期提醒）。

证据示例

一个组织根据其数据分类标准将来自 Meta 的开放平台数据归类为“私密数据”。该组织制定了数据处理指南，并要求所有人员理解并遵守这些政策。

借助传输加密，保护通过网络传输的开放平台数据

问题：您是否为传递、连接或跨公共网络传输开放平台数据的所有网络连接启用了安全协议 TLS 1.2 或更高版本？此外，您是否会确保绝不以未加密的形式在公共网络上传输（例如，通过 HTTP 或 FTP）开放平台数据，并确保绝不使用安全协议 SSL v2 和 SSL v3？

提问意图说明

在网络中传输的开放平台数据允许可查看此网络流量的所有人访问。因此必须进行加密保护，防止无授权方读取数据。

传输加密可使数据仅对传输发起和目标设备可读，从而保护开放平台数据在不可信的网络（如互联网）传输过程中的安全
换言之，在数据传输过程中，各方即使能看到网络流量（这种在传输中段读取数据的行为称为“中间人攻击”），也无法识别开放平台数据
TLS 是最常用的传输加密形式，因为浏览器会使用这种技术来保护向网站（如银行网站）传输的通信数据的安全

要求一览

无论您是否在服务器端处理开放平台数据：

开放平台数据绝不能以未加密的格式在不可信的网络上传输
对于所有接收或返回开放平台数据的 web 监听器（例如，面向互联网的负载均衡器），您必须：
- 启用 TLS 1.2 或更高版本
- 禁用 SSL v2 和 SSL v3
只有在客户设备不可运行 TLS 1.2 或更高版本的情况下，才能使用 TLS 1.0 和 TLS 1.1 版本来兼容设备
对于完全在私密网络（例如虚拟私有云 [VPC]）中传输开放平台数据，Meta 推荐采用传输加密，但不作强制要求。

下表总结了面向不同传输类型的传输加密政策。

传输类型	传输加密政策
往返于终端用户设备（手机、桌面电脑、平板电脑等）与服务器或云基础架构之间。	必须对兼容设备使用 TLS 1.2 或更高版本可使用 TLS 1.0 和 1.1 版本以兼容旧设备
往返于服务器或云基础架构与远程服务器、云基础架构或第四方服务之间。	必须使用 TLS 1.2 或更高版本
往返于私有数据中心、服务器或云基础架构中的不同部分之间	对于完全在私有云网络中传输的开放平台数据，TLS 加密为推荐而非强制要求
往返于 Meta 与任何设备、服务器或云基础架构之间	不在数据保护评估范畴内：Meta 控制这些数据传输的 TLS 策略

证据提交指南

如果您需要提交有关已落实该保护措施的证据，请按照“准备证据”部分的说明，准备好政策/程序类和执行类证据。在准备执行类证据以证明某个 web 监听器的配置状态时，一种简单直观的方法是使用 Qualys SSL 服务器测试工具。

选定一个或多个配置相同的 web 监听器（包括在非标准端口运行的监听器），运行 Qualys SSL 服务器测试工具。
勾选“不要在面板上显示结果”(Do not show the results on the boards) 选项，此操作可避免将结果添加到 Qualys 网站。将所有测试结果页面保存为 PDF 格式。根据 TLS 配置的不同，对往返传输开放平台数据的所有 web 监听器重复上述步骤。

执行类证据示例

这是 Qualys SSL 服务器测试工具的输出结果示例。留意“配置”(Configuration) 部分的红色注释，该部分汇总了受支持的 SSL/TLS 版本。注：本示例仅包括前两页结果，但您在保存时应导出所有测试结果。

可接受的其他保护措施

除了 TLS 外，您还可以使用其他类型的加密技术来保护开放平台数据的传输；前提是这些方案能提供同等的保护效力。在这种情况下，您应向 Meta 提交所用加密技术的详细信息以供审核：

加密技术为对称式还是非对称式？
采用何种加密算法（例如 AES、BitLocker、TDES、RSA）？
密钥长度最短为多少？

测试应用和系统以发现漏洞和安全问题

问题：您测试应用和系统以发现漏洞和安全问题的频率是否不低于每 12 个月一次？（例如，您是否开展了手动渗透测试？）

提问意图说明

开发者必须开展测试，积极寻找漏洞和安全问题，从而防患于未然

使用 Meta 开放平台的应用开发者通过他们配置和运行的应用/系统编写软件，然后利用这一软件来处理开放平台数据
软件和系统配置可能包含不法分子所觊觎的安全漏洞，导致开放平台数据遭到未经授权的访问

要求一览

适用于所有开发者：

您必须已通过以下任一方式，对用于处理开放平台数据的软件开展测试，以寻找安全漏洞：
- 对应用/系统执行渗透测试，或
- 对软件进行漏洞扫描/静态分析
测试结果必须显示不存在未解决的重大或高风险漏洞
测试必须在过去 12 个月内完成过

在服务器端处理开放平台数据的开发者还需满足更多要求：

您必须已通过以下任一方式，专门对服务器端软件开展了测试，以寻找安全漏洞：
- 对应用/系统执行渗透测试，或
- 漏洞扫描/静态分析。如果您正在使用云托管提供商的服务，您也必须对云配置开展测试，以发现安全问题。无论采用的是哪种托管方式，例如 BaaS、PaaS、IaaS、自托管或混合托管，此项要求均适用。

如果组织正考虑在开发流程中增加静态分析安全测试 (SAST)，这里有一份由美国国家标准技术研究所 (NIST) 维护的开源和商业工具列表可供参考，从而帮助您选用合适的工具。

证据提交指南

如果您需要提交有关已落实该保护措施的证据，请按照“准备证据”部分的说明，准备好政策/程序类和执行类证据。

如果组织在云或服务器环境中处理开放平台数据，则包括：

提交证据表明已经执行了渗透测试或运行了 SAST 工具。证据中应包含以下信息：
- 测试范围描述
- 测试完成日期（日期应在过去 12 个月内）
- 测试期间发现的漏洞的综述或列表综述或列表中必须说明漏洞属于哪一类严重程度（例如重大、高风险、中等风险、低风险、供参考）。通常，我们希望测试结果显示不存在未解决的重大或高风险漏洞

您用于处理开放平台数据的互联网可访问云或服务器软件（例如，网站或移动客户端使用的 REST API）必须纳入该测试的范围内才符合要求。

在适用情况下（即，如果您正在使用 AWS、GCP、Azure 或类似的云托管服务），请提交已进行云配置审核的证据，例如运行 NCC Scout Suite、AWS Config 或类似工具的输出结果。如果云配置审核不适用于组织，请在提交的证据中加上一个文档，说明为什么不适用云配置审核。
先**移除或消除敏感信息（比如详细的漏洞重现步骤），然后再提交证据**

如果组织不在云或服务器环境中处理开放平台数据，则包括：

提交证据表明已经执行了渗透测试或运行了 SAST 工具。证据中应包含以下信息：
- 测试范围描述
- 测试完成日期（日期应在过去 12 个月内）
- 测试期间发现的漏洞的综述或列表综述或列表中必须说明漏洞属于哪一类严重程度（例如重大、高风险、中等风险、低风险、供参考）。通常，我们希望测试结果显示不存在未解决的重大或高风险漏洞。
先**移除或消除敏感信息（比如详细的漏洞重现步骤），然后再提交证据**

证据示例

渗透测试 – 组织委托其他公司对用于集成 Meta API 和处理开放平台数据的服务器端软件开展渗透测试。测试公司完成测试，并发出总结测试结果的信函，示例如下。留意测试（或重测，如适用）报告结尾处的红色注释，此处重点标明了测试日期（必须为过去 12 个月内）并汇总了未解决的重大/高风险漏洞。请先消除敏感信息（特别是任何详细的漏洞重现步骤），然后再提交报告。

静态分析 – 如果使用不同的方法（例如 SAST 工具），将结果导出到一个文档中，在里面注明 SAST 工具运行日期，并列出测试结果（包括每个测试结果的类型及其严重程度/重大程度）。

云配置审核

开发者使用 NCC Scout Suite，应用其云服务提供商（在本例中为 AWS）的默认规则集来审核其云配置，以发现漏洞和安全问题。该工具生成了一个包含详细运行结果的 JSON 文件。在本例中，有多个问题的严重程度被标记为“危险”，开发者需要审核并解决这些问题。

NCC Scout Suite 生成的 JSON 原始文件包含了您云端环境的详细信息，这些资料本不应上传。此时，您应筛选响应结果，并按严重程度显示结果计数。

$ python3 scout.py aws –-no-browser
2022-08-22 11:39:38 localhost scout[76981] INFO Saving data to scoutsuite-report/scoutsuite-results/scoutsuite_results_aws-043954759379.js

$ cd scoutsuite-report/scoutsuite-results
$ tail -n +2 scoutsuite_results_aws-043954750000.js| jq '. | {last_run}' | pbcopy

{
 "last_run": {
 "ruleset_about": "This ruleset consists of numerous rules that are considered standard by NCC Group. The rules enabled range from violations of well-known security best practices to gaps resulting from less-known security implications of provider-specific mechanisms. Additional rules exist, some of them requiring extra-parameters to be configured, and some of them being applicable to a limited number of users.",
 "ruleset_name": "default",
 "run_parameters": {
 "excluded_regions": [],
 "regions": [],
 "services": [],
 "skipped_services": []
 },
 "summary": {
 "acm": {
 "checked_items": 4,
 "flagged_items": 2,
 "max_level": "warning",
 "resources_count": 2,
 "rules_count": 2
 },
 "awslambda": {
 "checked_items": 0,
 "flagged_items": 0,
 "max_level": "warning",
 "resources_count": 0,
 "rules_count": 0
 },
 "cloudformation": {
 "checked_items": 11,
 "flagged_items": 0,
 "max_level": "warning",
 "resources_count": 11,
 "rules_count": 1
 },
 "cloudfront": {
 "checked_items": 0,
 "flagged_items": 0,
 "max_level": "warning",
 "resources_count": 0,
 "rules_count": 3
 },
 "cloudtrail": {
 "checked_items": 153,
 "flagged_items": 4,
 "max_level": "danger",
 "resources_count": 17,
 "rules_count": 9
 },
 "cloudwatch": {
 "checked_items": 2,
 "flagged_items": 0,
 "max_level": "warning",
 "resources_count": 2,
 "rules_count": 1
 },
 "codebuild": {
 "checked_items": 0,
 "flagged_items": 0,
 "max_level": "warning",
 "resources_count": 0,
 "rules_count": 0
 },
 "config": {
 "checked_items": 17,
 "flagged_items": 0,
 "max_level": "warning",
 "resources_count": 1227,
 "rules_count": 1
 },
 "directconnect": {
 "checked_items": 0,
 "flagged_items": 0,
 "max_level": "warning",
 "resources_count": 0,
 "rules_count": 0
 },
 "dynamodb": {
 "checked_items": 0,
 "flagged_items": 0,
 "max_level": "warning",
 "resources_count": 1,
 "rules_count": 0
 },
 "ec2": {
 "checked_items": 760,
 "flagged_items": 108,
 "max_level": "danger",
 "resources_count": 44,
 "rules_count": 28
 },
 "efs": {
 "checked_items": 0,
 "flagged_items": 0,
 "max_level": "warning",
 "resources_count": 0,
 "rules_count": 0
 },
 "elasticache": {
 "checked_items": 0,
 "flagged_items": 0,
 "max_level": "warning",
 "resources_count": 0,
 "rules_count": 0
 },
 "elb": {
 "checked_items": 0,
 "flagged_items": 0,
 "max_level": "warning",
 "resources_count": 0,
 "rules_count": 3
 },
 "elbv2": {
 "checked_items": 42,
 "flagged_items": 4,
 "max_level": "danger",
 "resources_count": 0,
 "rules_count": 5
 },
 "emr": {
 "checked_items": 0,
 "flagged_items": 0,
 "max_level": "warning",
 "resources_count": 0,
 "rules_count": 0
 },
 "iam": {
 "checked_items": 801,
 "flagged_items": 27,
 "max_level": "danger",
 "resources_count": 87,
 "rules_count": 37
 },
 "kms": {
 "checked_items": 15,
 "flagged_items": 0,
 "max_level": "warning",
 "resources_count": 15,
 "rules_count": 1
 },
 "rds": {
 "checked_items": 1,
 "flagged_items": 0,
 "max_level": "warning",
 "resources_count": 27,
 "rules_count": 9
 },
 "redshift": {
 "checked_items": 0,
 "flagged_items": 0,
 "max_level": "warning",
 "resources_count": 0,
 "rules_count": 6
 },
 "route53": {
 "checked_items": 0,
 "flagged_items": 0,
 "max_level": "warning",
 "resources_count": 1,
 "rules_count": 3
 },
 "s3": {
 "checked_items": 121,
 "flagged_items": 34,
 "max_level": "warning",
 "resources_count": 7,
 "rules_count": 18
 },
 "secretsmanager": {
 "checked_items": 0,
 "flagged_items": 0,
 "max_level": "warning",
 "resources_count": 1,
 "rules_count": 0
 },
 "ses": {
 "checked_items": 0,
 "flagged_items": 0,
 "max_level": "warning",
 "resources_count": 0,
 "rules_count": 4
 },
 "sns": {
 "checked_items": 0,
 "flagged_items": 0,
 "max_level": "warning",
 "resources_count": 0,
 "rules_count": 7
 },
 "sqs": {
 "checked_items": 0,
 "flagged_items": 0,
 "max_level": "warning",
 "resources_count": 0,
 "rules_count": 8
 },
 "vpc": {
 "checked_items": 271,
 "flagged_items": 211,
 "max_level": "warning",
 "resources_count": 0,
 "rules_count": 9
 }
 },
 "time": "2022-08-22 11:42:25-0400",
 "version": "5.11.0"
 }
}

开发者还可使用 Amazon Web Services 规则集来开展云配置审核。

# Show that AWS Foundational Security Best Practices are enabled
$ aws securityhub get-enabled-standards 
{
 "StandardsSubscriptions": [
 {
 "StandardsSubscriptionArn": "arn:aws:securityhub:us-west-1:043954759379:subscription/aws-foundational-security-best-practices/v/1.0.0",
 "StandardsArn": "arn:aws:securityhub:us-west-1::standards/aws-foundational-security-best-practices/v/1.0.0",
 "StandardsStatus": "READY"
 }
 ]
}

# Show that aggregator is configured for a representative region used to process Platform Data
$ aws securityhub list-finding-aggregators

$ aws securityhub get-finding-aggregator --finding-aggregator-arn '{REPLACE-WITH-FINDING-AGGREGATOR-ARN}'

# Demonstrate that the ruleset is running by fetching active findings and counting the number of lines of output
$ aws securityhub get-findings --query 'Findings[?RecordState==`ACTIVE`]' --filters '{"GeneratorId":[{"Value": "aws-foundational-security","Comparison":"PREFIX"}]}' --output text | wc -l 

4876
# Demonstrate that there are no active critical severity findings
$ aws securityhub get-findings --query 'Findings[?Severity.Label==`CRITICAL`] | [?RecordState==`ACTIVE`] | [*][Title, GeneratorId]' --filters '{"GeneratorId":[{"Value": "aws-foundational-security","Comparison":"PREFIX"}]}'

[]

可接受的其他保护措施

如果您正在执行有效的漏洞披露计划 (VDP)，例如使用 BugCrowd 或 HackerOne 平台，那么您可以将此提交为替代保护措施，而不用开展渗透测试或漏洞扫描。为此，您必须提交证据证明：

VDP 中没有排除与您处理开放平台数据的方式相关的内容
实际上，过去 12 个月内一直在进行漏洞研究和报告，通常每月至少提交 1 份有效的漏洞报告
对提交的（有效）漏洞进行严重程度评分，例如使用 CVSS 3.1 进行评分
在合理的时间内（通常在提交日期后 90 天内）解决漏洞

在此情况下，证据中应包含：

对计划范围及其与用于处理开放平台数据的软件之间有何关联的描述。
过去 12 个月内通过该计划提交的实际漏洞的报告。该报告应包括漏洞名称、提交日期、解决日期（如果已解决）和严重程度分类/评分。

保护 Meta 应用密钥和 API 访问口令

问题：是否同时采用了以下两种方法来保护 Meta API 访问口令和应用密钥？

绝不将 Meta API 访问口令存储在客户端设备上可能遭到当前应用和用户以外的对象访问的地方。
如果存储在云端、服务器或数据中心环境，则结合使用数据保管库（例如 Vault by Hashicorp）和单独的密钥管理服务 (KMS)。

提问意图说明

应用密钥和访问口令是帐户安全的基础，关乎 Meta API 如何确定哪些操作允许执行。如果无授权方获得这些凭证的访问权，就能冒充开发者调用 Meta API，并执行我们对应用赋权的任何操作，例如从 Meta API 读取关于某位应用用户的数据。

您对 Meta 开放平台的使用包括访问敏感的凭证。具体包括：
- 访问口令 — 用户向应用授权时，软件会提供一种被称为访问口令的凭证，可用于后续的 API 调用
- 应用密钥 — Meta 会与开发者共享应用密钥，这是以组织内仅受信任方（例如应用管理员）拥有密钥访问权为基础的
如果无授权方能够读取这些敏感的凭证，他们可能会假冒您，使用这些凭证来调用 Meta API（这种行为有时被称为“令牌模拟”），从而无授权访问开放平台数据
因此必须防止这些凭证被无授权访问，以免遭人冒充

要求一览

访问口令

在客户端设备上 — Meta 访问口令不得以能让其他用户或流程读取的方式编写。
服务器端 — 如果您在服务器端处理或存储 Meta 访问口令，这些访问口令必须：
1. 结合使用数据保管库（例如 Vault by Hashicorp）和单独的密钥管理服务 (KMS) 进行保护，并且解密密钥的访问权仅限于应用本身
2. 不得记录到日志文件中

应用密钥 — 以下两项之一必须得到满足：

您不得将应用密钥暴露于安全的服务器环境以外，例如，应用密钥绝不能通过某个网络调用返回给浏览器或移动应用，并且此密钥不得嵌入到分发至移动或本地/桌面客户端的代码中
或者您必须以本地/桌面端的形式配置应用，以便 Meta API 不再信任包含此应用密钥的 API 调用

证据提交指南

如果您需要提交有关已落实该保护措施的证据，请按照“准备证据”部分的说明，准备好政策/程序类和执行类证据。

如果应用在服务器端处理 Meta 访问口令，请提供关于 Meta API 访问口令和应用密钥保护政策的文档，并举证证明您采取的保护措施（例如，使用数据保管库时，应证明数据值以加密格式存储，且应用配置为须提供应用密钥证明）。

确保您提交的证据中不包括（即已移除）任何密钥或访问口令的纯文本值。

证据示例

一家组织使用 AWS Secrets Manager 来安全存储敏感数据，包括 Meta 应用密钥。

组织对其 Meta 应用进行了配置，要求 API 调用必须提供应用密钥证明。

可接受的其他保护措施

如果您未使用数据保管库或未通过应用层级加密来保护服务器端存储的访问口令，您可以：
1. 使用数据保管库或应用加密功能来保护应用密钥，采用这种方式时，只能通过应用访问密钥
2. 同时对应用进行配置，要求所有 Meta API 调用都必须提供应用密钥证明
如果上述措施 #1 不可行（例如无法强制要求提供应用密钥证明，因为某些必要的 API 调用会受阻），则 Meta 会考虑您为了降低访问口令被无授权使用的风险而采取的其他任何措施，并与已存储的访问口令遭违规使用的风险进行比较

设置事故响应计划并测试事故响应系统和程序

问题：您是否至少每 12 个月检测一次安全事件响应系统和流程（例如，响应数据泄露或网络攻击的系统和流程）？

提问意图说明

对任何公司而言，数据安全事故都是不可避免的，不过是迟早的问题。因此，各组织机构有必要未雨绸缪，指定具体人员负责事故管控的具体事项、与利益相关方沟通、修复错漏和总结经验教训。

如果发生数据安全事故，应有现成的应对计划或手册可参考，并且培训了专门的小组来应对事故，这样能缩短事故的持续时间，并最终降低开放平台数据的曝光。
尽管不同组织的事故响应机制复杂度并不相同，我们要求至少要制定一个基础计划，涵盖一些关键活动：检测、反应、修复、复盘回顾，并指定具体人员承担特定职务和责任。

要求一览

开发者必须：

制定符合 Meta 最低标准的事故响应计划。
此计划文档必须至少涵盖以下方面：(1) 职务和责任，(2) 检测方法，(3) 根据适用法律义务作出反应（例如，向相关监管机构和数据主体发出数据泄露通知）并修复的步骤，以及 (4) 事故后复盘回顾程序
以文件的形式证明最近（12 个月内）对该计划进行了测试，并且计划提及的所有人员均参与了测试。

无论是否在服务器端处理开放平台数据，此要求都适用。

证据提交指南

请按照“准备证据”部分的说明，准备政策/程序和实施证据。

提交事故响应计划（一个或多个文档），内容应涵盖以下主题：职务和责任、检测方法、反应和修复步骤以及事故后复盘回顾程序。
- 如果您尚未制定事故响应计划，互联网上的许多资源均可作为参考，例如，Counteractive 的事故响应计划模板和参考资料与补充阅读。
提交您在过去 12 个月内测试过该计划的证据。此证据可采用不同的形式，但应包括：
- 场景描述（例如，响应勒索软件攻击的桌面演习）
- 进行测试的日期
- 每个参与者的职务
- 如果计划的“职务和责任”部分提及的任何人员没有参与，则分别说明每个人未参与的原因
请在提交此证据之前编辑其中包含的敏感信息（例如，个人姓名和电子邮件地址等个人身份识别信息）证据示例

事故响应计划

开发者已基于此模板创建完善的事故响应计划。这些图像仅展示了目录，但下方有一个指向完整模板的链接。

请参阅完整的 Counteractive 事故响应计划模板（docx 格式）

事故响应测试

开发者已通过桌面演习对其事故响应计划进行了测试，并基于此模板记录了结果。

此处仅包含前两页，而您提交时应提供完整文档。

对远程访问设置多重验证

问题：对于能够连接到云或服务器环境和/或访问您用于运行、维护、监控和操作特定系统（该系统被您用于存储 Meta 开放平台数据）的每个帐户，您是否对帐户远程访问设置了多重验证？

提问意图说明

不法分子获取机密数据访问权的常用手段之一是先获得开发者用于构建或运行其应用/系统的工具的访问权。有些复杂的工具可用于破解仅用密码来保护的帐户；多重验证能额外提供一层安全保护，防范此类风险。

软件开发者使用多种工具来构建、运行和管理其应用/系统。
他们常常通过网络远程使用这些工具，例如员工在家办公，通过这些工具交付新的软件功能或更新云配置。
使用单一验证（帐号和密码）的工具非常容易受到帐户接管攻击。例如，攻击者会使用各种工具，将从某个工具泄露的帐号和密码组合，用于尝试破解其他工具的访问权。
多重验证会在帐户登录时，在密码之外要求额外的验证因素，例如由身份验证器应用生成的代码，从而防范这类攻击。

要求一览

根据组织对开放平台数据的处理，对下述工具的远程访问必须使用多重验证来保护（即不能仅使用密码进行保护）：

用于运行和管理应用/系统的代码/配置变更的工具。
对云或服务器环境的管理级访问工具（如适用）。

具体而言，以下工具需要使用多重验证或可接受的其他保护措施：

协作/沟通工具 — 例如商务电邮或 Slack
代码存储库 — 例如，GitHub 或用于追踪应用/系统的代码/配置变更的其他工具
如果您在服务器端处理开放平台数据：
- 软件部署工具 — 用于将代码部署到云或服务器环境的工具，例如 Jenkins 或其他持续集成/持续部署 (CI/CD) 工具
- 管理工具 — 用于管理或监控云或服务器环境的入口或其他访问工具
- 服务器远程访问工具 — SSH、远程桌面或用于远程登录在服务器端运行的服务器的类似工具

关于多重验证的使用：

建议使用验证器应用或硬件（例如 YubiKey），其次是通过短信发送的验证码。
但组织可以使用任何多重验证方法。

证据提交指南

如果您需要提交有关已落实该保护措施的证据，请按照“准备证据”部分的说明，准备好政策/程序类和执行类证据。

执行类证据应证明多重验证已在适用于环境的上述工具中执行，即协作工具、代码存储库、云/服务器部署工具、云/服务器管理工具、云/服务器远程访问工具
执行情况将因配置而异：
- 例如，如果使用 SSO 提供商，针对整个组织的全局配置或针对每个应用程序的配置，执行情况可能如截图所示。
- 如果没有 SSO 提供商，针对特定工具的配置，执行情况可能如截图所示。
在所有情况下，我们都需要获得已为所有用户启用多重验证的证据，而不仅仅是某个帐户启用了多重验证的个别案例

证据示例

AzureAD

一个组织使用 AzureAD 作为其单点登录解决方案。此策略需要添加多重验证。

该策略随后应映射到其适配的云应用。使用此方法时，证据应显示整个选定项目部分，以明确哪些云应用需要多重验证。

Okta

此规则要求针对所有登录设置多重验证。

AWS IAM

这是一个 AWS IAM 策略示例，该策略允许使用多重验证配置，但在无多重验证的情况下禁止其他操作。

GitHub

一个组织已将 GitHub 身份验证配置为对组织中的每个人要求多重验证。

可接受的其他保护措施

对于组织中存在但未执行多重验证的任何类型远程访问工具，您都应该说明是否使用了以下一种或多种方法来防止帐户盗用：
- 高强度密码 — 例如，为密码复杂程度设置最低要求、禁止使用字典单词、禁止使用已知发生过泄露的密码。
- 验证失败惩罚 — 使用工具，在同一来源的登录尝试失败之后，延长开始下一次登录尝试的等待时间
- 自动锁定 — 例如，在 10 次登录尝试失败后自动阻止帐户登录

拥有用户帐户维护系统

问题：您是否拥有帐户维护系统（访问权限和管理权限的分配、撤销和审核）？

提问意图说明

拥有良好的帐户管理习惯是防止帐户被无授权使用，继而杜绝开放平台数据泄露的重要一环。具体来说，开发者必须确保对各种资源或系统的访问权在访问结束后予以撤销。

以帐户为基本单位，管理向用户授予系统、数据和管理功能访问权方面的工作
这些帐户被授予权限执行某些操作。建议的做法是仅向帐户授予满足其最低需求的权限，这就是最小权限原则
员工从组织离职后，务必立即禁用其持有的用户帐户，原因如下：
- (1) 预防此人（前员工）访问帐户；
- (2) 降低无授权人员偷偷使用此帐户的可能性。例如，不法分子可能会通过社交工程诈骗，让 IT 服务台为其修改被盗帐户的密码。如果此帐户属于在职员工，该员工就很可能会报告帐户无法登录的情况，而如果帐户属于离职员工但仍然可用，那么此帐户被盗用的情况很可能就无人发觉。
鉴于此，组织必须制定系统性的管理办法，用于管理帐户、授予访问权限/管理权限以及在不再需要时撤销权限。

要求一览

您必须拥有用于以下用途的工具/系统/应用的帐户管理工具或程序：
- 与他人沟通，例如 Slack 或商务电邮
- 交付软件，例如代码存储库
- 管理或运行其系统（适用于处理开放平台数据）
您必须定期审核（频率不低于 12 个月一次）访问权授予情况，并设置在以下情形中撤销授权的程序：(1) 授权不再必要；(2) 授权不再使用
您还必须设置程序，用于在员工离职时，立即撤销此人对这些工具的使用权
Meta 不要求
- 使用任何指定工具；开发者可自行选用目录产品（如 Google Cloud identity 或 Microsoft Azure Active Directory）、云产品（如 AWS Identity 和 Access Management [IAM]）或使用定期更新的电子表格。
- 使用统一的综合工具来管理各种访问类型下的帐户。

无论是否在服务器端处理开放平台数据，此要求都适用。

证据提交指南

请按照“准备证据”部分的说明，准备好政策/程序类和执行类证据。

政策/程序 – 提供有存档记录的政策和程序文档，文档中应涵盖帐户管理实践。我们希望文档中包含如下内容：帐户创建程序、权限授予程序、密码复杂性最低要求、帐户锁定政策、多重验证政策、帐户重置程序，以及在一段时间未使用帐户后或者有人员从组织离职时（例如员工辞职或被解雇时）撤销权限的流程。
执行类证据 – 提供证据，证明至少使用了以下一种工具或流程来管理帐户（或视情况注明不适用的情形）：(1) 企业邮箱和协作工具，(2) 代码存储库，(3) 云端/服务器部署工具，(4) 云端/服务器管理入口，(5) 云端/服务器远程登录（例如 SSH 或远程桌面）。对于具有代表性的特别工具或流程，应提供证明以下内容的证据：
- 从组织离职的人员已被撤销这些工具的访问权（例如，将用户帐户与权威的组织现有成员数据进行对比，并提供核对报告）
- 一段时间未使用的帐户已被撤销访问权（例如，当帐户非活跃期的上限为三个月时，提供的报告应证明具有代表性的活跃用户帐户持有人在最近 90 天内访问过帐户）

证据示例

政策/程序 – 一名开发者创建了访问权生命周期管理标准，其中涵盖访问权的授予、审核和撤销程序。

执行示例 – 离职人员已被撤销访问权

开发者使用 Workday 作为人力资源数据（包括员工在职状态）的权威来源。同时，还使用 Google Cloud Identity 作为身份提供商 (IdP)，用于管理用户帐户和授予信息系统和工具的访问权。

在举证证明离职人员已被撤销访问权时，开发者提交了一份报告，证明近期（例如，最近 12 个月内）出具的核对报告显示，非在职员工在 Google Cloud Identity 中不存在活跃用户帐户；非在职员工根据 Workday 现有员工报告确定。

执行示例 – 不再使用的帐户已被撤销访问权

开发者使用 Google Cloud Identity 作为身份提供商 (IdP)，用于管理用户帐户和授予信息系统和工具的访问权。

在举证证明不再使用的帐户（例如，最近 6 个月内未登录）已被撤销访问权时，开发者提交的证据显示，将用户目录按最近登录日期排序时，活跃用户帐户最近一次登录的日期均未超过上述时限。

执行示例 – GitHub（代码存储库）

开发者使用单点登录 (SSO) 工具进行身份管理，并授予信息系统和工具的访问权。开发者已将 GitHub 配置为需要 SSO 身份验证。

保持软件及时更新

问题：您是否拥有保持系统代码和环境（包括服务器、虚拟机、发布版本、库、软件包和杀毒软件）更新的系统？

提问意图说明

软件组件会定期更新或打补丁来修补安全漏洞，而当这些组件最终不再受支持时，它们的生命周期将宣告结束。封装或依赖这些组件的开发者必须保持其及时更新，以避免软件带着已知漏洞运行。

应用开发者需要使用多种第三方软件来运行那些处理开放平台数据的应用/系统。
以下为开发者使用的部分或全部第三方软件：
- 库、SDK、软件包组件 — 开发者会将这些组件与自己的自定义代码封装起来，打造为一款应用。
- 虚拟机镜像、应用容器和操作系统 — 应用要在一个或多个这类容器中运行，这类容器能提供虚拟化和网络及存储空间访问权等服务。
- 员工/开发贡献者使用的浏览器、操作系统和其他应用程序 — 在移动设备和笔记本电脑上运行，供开发者用于构建和运行其系统的软件。
安全漏洞通常出现在这些组件中，需要通过补丁进行修正。
漏洞经过补丁修正后，就会在公开的数据库中披露，并说明其严重性等级（低、中、高或重大）。
因此，使用 Meta 开放平台的开发者必须采用系统化方式来管理补丁，具体事项包括：
- 确定与其应用或系统相关的补丁
- 根据漏洞暴露情况，优先处理紧急项
- 将打补丁作为日常的一项业务活动坚持去做

要求一览

对于以下软件组件，如适用，您必须拥有一种定义明确且可重复的方式，用来确定可用补丁用于修正安全漏洞、优先处理风险等级高的事项以及日常打补丁：

用于云或服务器环境的库、SDK、软件包、应用容器和操作系统
用于客户端设备（例如在移动应用内）的库、SDK、软件包
由组织成员用于构建和运行其应用或系统的操作系统和应用程序，例如在员工笔记本电脑上运行的操作系统和浏览器

Meta 不要求为这些活动使用任何特定工具。一个组织通常会使用不同的方法来保持不同类型的软件及时更新（例如，随应用封装的库及员工笔记本电脑的操作系统更新）。

尽管您需要保持及时更新的组件集可能会有所不同，此要求适用于任何托管方法（例如 BaaS、PaaS、IaaS、自托管或混合托管）

下图说明了各种架构类型可能需要打补丁的情况。

证据提交指南

如果您需要提交有关已落实该保护措施的证据，请按照“准备证据”部分的说明，准备好政策/程序类和执行类证据。

首先是确定环境中的范围内软件类型，例如库、SDK、软件包、虚拟机映像、应用容器和操作系统，以及员工/开发贡献者使用的浏览器、操作系统和其他应用程序。

您可能拥有用于以下活动的一种或多种工具：

软件资产库存 — 使用截图式或文档式记录，指明某个工具或流程最终列出了需要打补丁的范围内资产列表，包括库、软件包、SDK、容器、应用服务器和操作系统。代表性软件类型（例如，云应用、客户端应用、员工设备）都需要有软件资产库存记录。
确定可用软件补丁 — 必须存在用于确定与软件库存资产相关的可用安全补丁的工具或流程。
优先处理 — 需要有为相关补丁分配优先级的工具或流程（例如 Jira 工单、GitHub 问题、跟踪电子表单）。
- 打补丁
- 使用截图式或文档式记录，指明在确定了相关补丁并按优先级处理后，这些补丁已部署到各目标位置。
其中应包括与问题解决时间和使用生命周期结束 (EOL) 的软件有关的政策。

证据示例

适用于 NodeJS 应用的 Snyk — 开发者使用 Synk 命令行界面 (CLI) 来识别具有已知安全漏洞的已封装第三方依赖项，并根据这些漏洞的严重性等级进行优先处理。

NPM Audit

一位开发者使用 NPM Audit 来查找 Node 应用程序中所用依赖项的漏洞。以下示例图像显示了需要打补丁的多个高严重性等级漏洞。

Trivy

一位开发者使用 Trivy 查找虚拟机映像中的漏洞。以下示例图像显示了此映像所含库中需要打补丁的高严重性等级漏洞。

Windows Server Update Services (WSUS)

一位开发者使用 Windows Server Update Services (WSUS) 来管理其所有服务器和台式电脑/笔记本电脑。该工具允许查看、批准和部署 Windows 更新。以下示例图像显示了 WSUS 工具的管理视图。

设立系统用于记录开放平台数据的访问情况，并追踪开放平台数据的发送和存储位置

提问意图说明

如果没有可靠的日志文件，开发者可能难以甚至无法检测开放平台数据被无授权访问的情况。

借助审计日志，组织可以记录事件发生的真实情况，例如，某位用户查询了包含开放平台数据的数据库表格
之后，这些日志可用于支持处理进程，例如根据可疑活动触发自动提醒，或在发现安全事件后进行取证分析

要求一览

如果您在服务器端处理开放平台数据，则在该环境中：

您应负责维护记录关键事件（例如访问开放平台数据、使用权限更高的帐户、更改审计日志配置）的审计日志
应将审计日志整理到一个中央存储库中，并保护其不被更改或删除

证据提交指南

如果要求您上传证据，则证据应能证明：

您可以掌握开放平台数据存储、访问和传输情况的最新信息，例如，通过提供具有以下作用的最新数据流程图来证明这一点：显示系统整体情况，指定存储开放平台数据的服务，以及显示入口点和出口点，包括预期传输到任何第四方服务的情况
您已采取措施，防止审计日志遭到篡改
与访问开放平台数据相关的事件已记录到日志中

监控开放平台数据以及开放平台数据可能离开系统的关键点（例如，第三方、公共端点）的传输情况

提问意图说明

了解应该如何处理开放平台数据并监控实际处理情况，这是组织确保开放平台数据仅用于预期目的的重要方式

开发者需要掌握开放平台数据如何存储、如何通过网络传输以及如何写入备份（可能在其他位置复制）的最新情况
例如，通过监控，可以发现开放平台数据以意外方式传输的情况，或未经适当加密通过网络传输的情况，以便采取行动

要求一览

如果您在服务器端处理开放平台数据，则在该服务器环境中，您应该：

维护准确的数据流程图，以显示在何处存储、处理及跨网络传输开放平台数据
针对将开放平台数据传输到系统之外的情况配置监控措施（例如，使用自动化监控产品的审计日志）
如果条件允许，配置监控系统，以便在开放平台数据意外传输的情况下发出可得到及时查看的提醒（另请参阅以下要求 — 设置自动化系统，用于监控日志和其他安全事件，以及针对异常或安全相关事件生成提醒）

证据提交指南

如果您需要提交有关已落实该保护措施的证据，请按照“准备证据”部分的说明，准备好政策/程序类和执行类证据。

您应该提供证据证明：

您可以掌握开放平台数据存储、访问和传输情况的最新信息，例如，通过提供具有以下作用的最新数据流程图来证明这一点：显示系统整体情况，指定存储开放平台数据的服务，以及显示入口点和出口点，包括预期传输到任何第四方服务的情况
已采取措施，防止审计日志遭到篡改
与开放平台数据传输相关的事件已记录在日志中；事件应包括时间、执行操作的用户或应用的身份以及来源和目标位置

设置自动化系统，用于监控日志和其他安全事件以及针对异常或安全相关事件生成提醒

提问意图说明

纯依靠人工来审核和识别现代互联网访问系统中的异常行为不太现实。相反，可以使用一些工具来收集日志文件和其他信号，并发出需要人工进一步调查的提醒。

要求一览

如果您在服务器端处理开放平台数据，则在该服务器环境中，您应该：

设置能够收集日志文件和其他事件的工具，建立在触发时可发出提醒的规则，并搭建一个将提醒发送给相关人员（例如，随时待命的安全调查员）的机制
在工具中收集相关信号（例如，Web 访问日志、身份验证尝试、具有高级权限的用户采取的操作）
不断调整和完善规则，平衡信噪比（例如，避免过多误报，同时不忽略需要调查的事件）

证据提交指南

通常而言，开发者会使用安全信息和事件管理 (SIEM) 工具来实现此目的，例如：

McAfee Enterprise Security Manager
SolarWinds Security Event Manager
Splunk Enterprise Security
Sumo Logic

您应提供证据证明以下几点：相关信号源被传输到其选择的工具中；已配置触发器或警报；提醒已发送给负责跟进的人员；以及最后，存在定期调整提醒的流程（例如，通过月度审核和更新周期）。

术语表

A

第三方 – 在风险管理术语中，第三方是指 Meta 开放平台上的开发者（第一方是 Meta；第二方是使用 Meta 产品的用户）。

第四方 – 在风险管理术语中，第四方是指为开发者的业务运营提供所需服务的公司（第一方是 Meta；第二方是 Meta 的用户；第三方是 Meta 开放平台上的开发者）。访问口令 – 软件用来调用 API 从而执行某些操作（例如，从用户个人主页读取数据）的一种凭证（比如密码）。

Amazon Web Services (AWS) – Amazon 推出的一整套云计算服务。

应用范围编号 (ASID) – 用户选择使用某个应用时 Meta 生成的唯一标识符。由于单个用户同时使用两个应用时，每个应用中生成的 ASID 不同，这使得数据集更难跨应用关联用户，从而更有利于保护用户隐私。

应用密钥 – Meta 通过应用面板提供给开发者的共享密钥。拥有应用密钥即可授权软件通过图谱 API 执行某些操作，因此开发者需要确保未获授权方无法访问该应用密钥。

应用入侵 – 如果不法分子利用组织应用中的配置错误或漏洞（例如网页应用中的软件漏洞）在未经授权的情况下访问组织的内部网络，则称为应用入侵。对应用开展渗透测试有助防止应用入侵。另请参见网络入侵。

应用容器 – 一个将软件代码和相关依赖项打包到一起的容器，可让应用在不同类型的服务器（即在不同的操作系统上运行的服务器，例如 Linux 或 Windows 服务器）上运行。开发者将创建打包其应用的容器镜像。应用容器引擎或运行时用于托管（运行）容器镜像。

应用加密 – 一种由应用软件自行完成加密和解密操作的数据保护方法。与之相对的是，当应用与远程服务器之间建立安全连接（例如使用 HTTPS）后，传输层安全协议 (TLS) 可无缝地加密传输中的数据，云服务提供商可提供以透明的方式加密静止数据的服务。

应用程序接口 (API) – 允许两台计算机通过网络相互对话（例如移动应用从中央天气预报系统获取某个地区当日的天气）的接口。

应用密钥证明 – 开发者生成的一个参数（应用密钥证明），用于证明他们拥有应用密钥，这为 Meta 调用 API 提供额外的安全保护。应用密钥证明是根据应用密钥和访问口令构建的一个散列函数（也称为单向函数）。配置应用时要求在调用图谱 API 期间须提供应用密钥证明，这样有助减少用户访问口令泄漏造成的潜在危害，因为在未提供额外应用密钥证明参数的情况下，这些访问口令是无法使用的。

B

后端即服务 (BaaS) – 一种云计算服务，为应用开发者提供一套服务器端功能，让开发者可以集中精力构建前端（即与用户交互的应用部分）。BaaS 解决方案与 PaaS 相似，并额外增加了用户身份验证和移动推送通知等服务。常见的 BaaS 产品示例如下：AWS Amplify、Azure Mobile Apps、Firebase 和 MongoDB Switch。

C

密文 – 加密数据的同义词，通过某种加密算法使得数据无法被读取，以此获得的文本即为密文。与密文相反的是纯文本。

客户端 – 通常，用户通过在浏览器中打开网站或者在手机或平板电脑上运行移动应用来使用互联网访问服务。该浏览器或移动应用即称之为本地客户端或客户端。客户端通过互联网从远程计算机（服务器）发出请求。

云计算 – 一种管理服务器计算机、网络和存储的方式，可免去组织对物理环境（即配备有服务器机架和网络电缆的数据中心）的担忧。或者，组织也可以按需准备这些资产，并为自己使用的服务付费。

云配置 – 组织设置的与其使用云服务提供商来运行某些软件有关的一组云计算选项。云配置的示例包括允许或阻止的网络连接类型、日志文件的写入位置和保存时长，以及经授权更改云配置的用户群。

补偿性控制 – 一种安全控制措施，它不同于某些基准要求，但目的是提供同等的风险保护。

D

数据库 – 允许存储、读取、更新和删除任意数据的软件。数据库可在客户端和服务器端上运行。集成 Meta 开放平台的组织通常将从图谱 API 获取的数据存储在服务器端上运行的数据库中。

解密 – 将加密数据转换回原始格式的过程。换句话说，解密就是将密文转换为纯文本。

E

加密 – 将数据转换为任何人都无法解密的格式的过程。换句话说，加密就是将纯文本转换为密文。

静止数据加密 – 将数据写入永久存储器（例如磁盘驱动器）时通过加密来保护数据的方式。静止数据加密为防止不法分子未经授权访问数据提供了一层额外保护，因为即使他们能够读取存储设备上的原始文件，看到的也只是密文，除非他们也获得解密密钥，否则将无法解密这些文本。

传输中加密 – 在网络中传输数据时通过加密来保护数据的方式。传输中加密可防止不法分子沿网络路径窃取数据，因为即使他们能够读取网络数据包，看到的也只是密文，除非他们也获得解密密钥，否则将无法解密这些文本。

生命周期结束 (EOL) 软件 – 当组织选择停止为软件产品提供支持（例如，创建补丁以解决安全漏洞）时，即认为该软件达到 EOL。由于 EOL 软件不再有人维护，因此运行该软件存在很大风险。

G

Google Cloud Platform (GCP) – Google 推出的一套云计算服务图谱 API，这是应用读取和写入 Meta 社交关系图谱的主要方式。所有 Meta SDK 和产品均以某种方式与谱图 API 互动。

H

散列函数 – 一种加密函数，它使用输入的任意数据创建一个短代码，而输出的该短代码无法逆转为原始输入。在密码学中，散列函数用于保护密码等数据：它不是以纯文本的形式存储用户的密码，因为这样存在密码被盗的风险，而是会先使用散列函数转换密码然后再存储。随后，为了确认用户输入了正确的密码，系统将使用相同的散列函数来转换输入，并将获得的散列值与存储值进行比较。这也称为单向函数，因为输出的散列值无法逆转为原始输入。

托管环境 – 指组织在其自有的数据中心或与其他客户共同租赁的数据中心运行的一组远程服务器、网络和存储设备。随着云计算变得越来越流行，这种配置在现代也相对少见。

I

身份提供商 (IdP) – 一种用于集中化管理数字身份和验证用户身份的云服务。使用 IdP 的组织通常会配置云应用来通过 IdP 进行用户身份验证。之后，组织可以通过在 IdP 中集中创建应用、为选定应用授予访问权限和禁用用户帐户来管理用户，而无需在每个云应用中重复进行这些操作。

身份和访问管理 (IAM) – 指用于管理帐户和授予系统访问权限的一类工具和流程。

基础设施即服务 (IaaS) – 一种云计算方法，可供客户配置计算、存储和网络服务，而无需对实物资产本身负责（例如，管理配备有服务器、网络设备和存储阵列的数据中心）。相比 Paas，IaaS 给予组织更多控制权来配置其云资产，但也增加了管理这些资产的复杂性。常见的 IaaS 产品示例如下：AWS EC2、Microsoft Azure IaaS 和 Google Compute Engine。

L

库 – 现有的软件构建模块，通常来自外部公司或开发者，用于在另一开发者的应用或系统中处理某些任务。库可以简化应用的开发过程，因为如果已经存在某个函数的库，开发者便无需浪费时间做重复的事。但是，库可能包含安全漏洞，或者其本身可能包括存在安全漏洞的其他库。因此，在将库用于自己的应用中时，开发者需要了解使用的是哪些库并持续更新这些库。

M

手机客户端或移动应用 – 用户从移动应用商店（例如，iOS App Store 或 Google Play 商店）下载并安装到手机或平板电脑的应用。通常，手机客户端通过互联网与组织的 REST API 进行通信，还可以与其他方进行通信（例如，通过 Android 版 Facebook SDK 与图谱 API 通信）。

多重身份验证 (MFA) – 一种身份验证方法，用户需要通过多个因素的验证，之后才能获得访问应用或系统的权限。与仅依赖密码验证用户身份的单因素身份验证相比，MFA 通常需要提供密码和以下一项或多项：通过邮件或短信发送的验证码、身份验证应用发送的验证码、生物特征识别扫描或安全密钥。通过 MFA，不法分子更加难以在未经授权的情况下强行进入帐户（例如使用已知的邮箱和常见密码反复尝试登录帐户，直到成功为止），这样可以防止帐户被盗用。

N

原生软件 – 下载并安装到笔记本电脑或移动设备上的应用称为原生软件（例如，iOS 版 Facebook 应用）。相反，在浏览器中运行的应用称为网页应用（例如，使用 Chrome 浏览器打开 Facebook）。

网络入侵 – 如果不法分子利用网络本身的配置错误或漏洞，在未经授权的情况下访问组织的内部网络，则称为网络入侵。防止网络入侵的措施之一是运行网络扫描，从而发现面向互联网的网络中存在的配置错误和漏洞。另请参阅应用入侵。

网络扫描 – 一种使用软件进行的风险管理流程，其目的是：(1) 发现网络上存在的、将对远程通信做出响应的动态服务器；(2) 检查其中是否有任何服务器在运行已知容易受到一个或多个安全漏洞攻击的旧版软件。例如，组织可以定期进行网络扫描，确保其网络边界内没有意外打开的端口。

Node 包管理器 (NPM) – 一种供 JavaScript 开发者将预先构建的包纳入开发者的应用或系统中，以此来加速开发的工具。NPM 包括如下功能：审核应用所使用的一组软件包，以及识别包含已知安全漏洞的软件包。

O

对象存储桶 – 一种位于云端的永久性存储器，它可以简化组织将文件（包括非常大的文件）存储到永久性存储器的过程，而无需为扩展存储阵列等实物资产而担忧，也不用担心如何备份这些文件才能确保在发生火灾或洪水等灾害时文件不会丢失。

操作系统 – 计算机或移动设备上运行的软件，可帮助应用运行和使用该计算机的处理器、内存、存储空间和网络资源。例如，Microsoft 的 Windows 操作系统、Apple 的 macOS 或 iOS 操作系统，以及 Linux 操作系统。

组织成员 – 在组织中担任某种角色和职责的人，例如员工、合同工、临时工、实习生或志愿者。

组织设备 – 组织成员在为组织工作时使用的计算机或移动设备。

P

开放平台条款 6.a.i – 指 Meta 开放平台条款的第 (6) 条标题 (a) 下的段落 (i)，其中描述了开放平台开发者的数据安全相关义务。

包 – 库的同义词

补丁 – 用于解决安全漏洞、修复漏洞或增加新功能的软件更新。所有类型的软件都要安装补丁，包括操作系统、容器、库和 SDK。

渗透测试 – 一种模拟攻击应用或系统的测试，测试员通过该测试尝试找到代码或配置中存在的漏洞，从而防止未经授权的人员利用这些漏洞来攻击应用或系统。渗透测试将使用网络罪犯所用的相似工具来进行侦查、扫描潜在的缺陷并测试可能被用于无授权访问的漏洞。渗透测试结束时，测试员将创建一份报告，描述测试结果并对每项结果划分严重程度，维护软件的组织则负责制定修复方案来解决漏洞。

纯文本 – 未加密数据的同义词，未通过加密来保护的数据称为纯文本。平台即服务 (PaaS) – 一种云计算方法，客户可通过使用该方法，将应用部署到云服务提供商管理的平台中。相比 IaaS，PaaS 能帮助客户简化管理，因为不仅是实物资产（即服务器、存储设备和网络设备），还有运行客户应用的操作系统和应用容器都由云托管管理。常见的 PaaS 产品示例如下：AWS Elastic Beanstalk、Google App Engine、Force.com。

端口 – 当客户端通过互联网与服务器建立连接时，目标地址有两个端口：(1) 服务器的互联网协议 (IP) 地址；以及 (2) 将收到特定应用程序响应的服务器的端口号。公共协议使用保留端口（例如，HTTPS 使用端口 443），但如果需要，开发者可为网络通信使用自定义端口。

R

REST API – 一种广泛采用的构建网页可访问服务的方式，其中客户端和服务器端之间通过 HTTP 协议进行通信。Meta 开放平台的开发者可以将 REST API 托管在类似 api.example.com 的子域上，让他们的移动应用可以收发开放平台数据。

S

安全外壳 (SSH) – 一种通信方案，管理员可通过该通信方案远程登录服务器并在这些服务器上运行程序。与 Telnet 等早期的协议不同，安全外壳协议得名于它对客户端和服务器端之间的通信进行了防窃取保护。也称为安全套接外壳。

Secure Sockets Layer (SSL) – 一种被淘汰和不安全的传输中加密协议。现代的安全协议称为传输层安全 (TLS) 协议。

服务器 – 通过网络远程提供服务的计算机。浏览器和移动应用通过互联网连接到服务器。

无服务器计算 – 一种云计算方式，其中物理基础设施、服务器操作系统和容器由云托管管理。开发者只负责自定义代码和相关的库以及云配置。

服务器端 – 位于网络连接另一侧（即服务器上）的数据或计算称为服务器端。与之相对的是，笔记本电脑或移动设备等本地设备上的数据或计算称为客户端。

单点登录 (SSO) – 应用依赖集中化的用户目录（即 IdP）来验证用户身份的一种配置。除了为组织集中化管理用户帐户和应用访问权限外，拥有唯一的一组凭证而不是每个不同的应用都有不同的凭证（例如，帐号和密码），这对用户来说也是有好处的。

软件开发工具包 (SDK) – 代码的一个构件模块，开发者可用它来简化开发流程以满足特定需求。例如，Meta 创建并维护 SDK，以便简化 iOS 和 Android 版图谱 API 开发者的工作。和使用库时一样，开发者将 SDK 用于自己的应用中时也需要持续更新这些 SDK。

软件即服务 (SaaS) – 允许客户通过互联网使用基于云的应用。不同于 PaaS 或 IaaS，SaaS 应用的客户不部署自定义代码，也不负责配置、升级或修复 SaaS 应用，因为所有这些都由 SaaS 软件提供商负责。常见的 SaaS 产品示例如下：Dopbox、MailChip、Salesforce、Slack。

静态分析 – 参见“静态应用程序安全测试”

静态应用程序安全测试 (SAST) – 通过运行一种专门针对源代码的工具来发现软件漏洞的方法。SAST 工具可发现潜在的漏洞，比如 OWASP Top 10（Web 应用程序十大最关键安全风险类别）项目中列出的漏洞，然后由开发者负责检查这些结果，区分漏报与误报，并修复软件中的漏洞。SAST 可使开发者在将软件部署到生产中之前发现其中存在的漏洞，因此能起到帮助作用，但与渗透测试不同的是，SAST 工具无法发现与应用的生产配置有关的漏洞。

T

透明数据加密 – 一种静止数据加密方式，通常适用于数据库存储（即数据库内容及其日志文件）。在这种配置中，数据库软件可管理加密密钥，并以透明的方式处理加密操作（写入时）和解密操作（读取时）。

传输层安全性 (TLS) – 一种传输中加密方案，它通过加密来保护通过网络传输的数据，以防止不法分子沿网络路径窃取数据。TLS 是被淘汰的早期技术 SSL 的现代安全版本。

双重验证 (2Fac) – 多重身份验证的同义词。Vault – 加密密钥、访问口令和其他凭证等敏感数据的机密管理系统。使用 Vault 可以严格控制访问其中所含机密的人，并提供其他服务，比如保存审计日志。

V

虚拟机 (VM) – 与应用容器非常类似，VM 在被称为 Hypervisor（虚拟机监控器）的主机上运行，而应用容器在容器引擎中运行。二者的主要区别在于，VM 镜像包含操作系统，而应用容器镜像则不包含操作系统。VM 和应用容器都包含应用和依赖项（比如库）。

虚拟私有云 (VPC) – AWS 使用该术语来指代一组云资源，这些云资源类似于云计算前时代数据中心中的传统网络。

漏洞 – 系统或应用中存在的缺陷，这些缺陷可能被不法分子利用（例如，不法分子未经授权读取数据）

漏洞披露计划 (VDP) – 组织向研究人员（有时称为文明黑客）征求安全漏洞报告的一种方式，这样便可以在不法分子利用漏洞之前发现它们并进行修复。要使 VDP 产生预期效果，需要有一组研究人员积极地寻找漏洞，由组织内部的分析员对收到的披露报告进行审核和分类，并由了解网络安全相关知识的工程师创建并部署漏洞补丁。

漏洞扫描 – 使用软件来查找服务器、网络和应用中存在的漏洞的一种方法。与渗透测试相比，漏洞扫描的运行成本更低，因而可以反复运行（例如，每月或每季度运行）；但通常渗透测试可发现漏洞扫描过程中未发现的漏洞，因为熟练的渗透测试人员所具备的分析能力和直觉是无法通过严格自动化的方法复刻的。另请参见网络扫描。

W

网页应用 – 网页应用是在浏览器内运行的程序，包括各种资源，比如 HTML 文件、JavaScript 代码、视频和其他素材以及用于设置样式的 CSS。不同于用户从应用商店下载移动应用并安装到手机，用户只需使用浏览器从远程服务器获取网页应用（例如 www.facebook.com），而无需进行安装。

弄了个S3做云盘

Fri, 28 Apr 2023 11:27:59 +0800

之前送的腾讯微云vip到期了，存的历史文件和照片需要找个新地方安家。

目前市面上免费产品，出乎意料都统一在5GB免费，不能满足需求。看各种付费方案，其实都有点坑（office365 ￥498家庭版还算有点良心，可以几个人合买用产品和1TB存储）

综合权衡了价格、安全、可靠之后，果断到AWS全球站开账号，买S3。

同步工具用的是“S3 Browser” ，这个界面工具可以非常方便的操作文件系统、提供了目录同步功能、提供了标记存储类型的功能。上传即标记为“IA”不常访问，可以极大降低存储费用。目前内地到HK区的S3上传非常给力，可以到6MB/S 。