“写笔记”支持四种格式——Word 文档、Excel 表格、Markdown、纯文本，起稿或二次编辑时都能随时切换，同一篇笔记想用哪种形态来记，都由你说了算。
md、txt、csv、json 这类纯文本则原样载入，不做多余加工。拿一张现成的表倒进来、改几笔、再导出去，等于白用一台免费的格式转换器。
要带走就在右上角点“下载”，可导出 PDF、Word、Markdown、Excel、TXT 等格式；列表卡片“⋯”菜单里，也有同样的下载入口。
在“工具”页点“＋ 上传工具”即可发布：填好名称与链接，再用 Markdown 把使用方法写清楚——能解决什么问题、怎么装、怎么用，比堆介绍实在。
要分发安装包就一并上传压缩包（ZIP、RAR、7Z、TAR.GZ，最大 35MB），别人在详情页一键下载；只放链接不带附件也可以。
工具按大家的收藏热度排序，好用的自然会被顶上来。发布后可在详情页或卡片菜单里编辑、下架。
写笔记时勾上“隐藏”，这篇就只存在于你自己的账号里：不进列表、不进搜索、不上首页精选，也不会出现在任何公开的页面，链接发给别人同样打不开。
适合放密码、草稿、日记这类只给自己看的内容；想公开，去“发布”打开它，把“隐藏”的勾去掉再保存，之后编辑会默认保持原状态，不会悄悄变回公开。
你的内容会同时保存在多个副本上，系统定期做备份与完整性校验，再配合异地容灾机制：就算某台机器出问题，数据也不会丢，可以长期放心存放；特别重要的资料，仍建议你另外再留一份备份。
全站跑在容器化、模块化的现代架构上，更新、部署、回滚都很快，扩展性和稳定性都按长期运营的标准来设计（Built for reliability, designed to scale）。
这个网站最早只是一个人的笔记仓库，后来慢慢长成现在的知识中枢。设计上很克制——没有广告、没有追踪、没有推荐算法，只是干干净净地存放一些东西；既然做好了，就公开出来，万一有人用得上呢。
不做大而全，不做平台梦，保持简单、保持克制、保持好奇。所有内容都由用户贡献、由用户维护：不会突然冒出付费墙，不会在角落塞广告位，也不会把你的数据卖给第三方。
产品会持续迭代，站内日志页记录着每一次改动，改了什么都有迹可循；想了解这个站是怎么一步步走到今天的，翻翻日志就能看到来龙去脉。
如果在这里看到涉嫌违规的内容，点对应卡片右侧的“举报”按钮就能提交，我们会尽快核实处理；也谢谢你花一点时间，一起把这里维护干净。
对Entra扩展的每一次变更都是控制平面事件：监控契约
先说个背景。之前的两篇文章（Microsoft Entra可扩展性是一份礼物，但它也是控制平面 和 保护决定Entra信任谁的代码）我聊了两个静态决策：代码放哪儿，以及用什么凭证去调用外部服务。
代码位置：放在一个专用的控制平面订阅里，直接挂在根管理组下面，或者挂在专用的控制平面管理组下面。绝对不要放在平台身份订阅或者应用 landing zone 里。
凭证选择：默认用托管标识，如果要离开 Azure 调用外部服务就用联合身份凭证，证书是中间过渡方案，静态对称密钥永远不用。
这两个决策都是一次性的。你定好了，走开，几个月都不用碰它。
但第三个决策不是这样。它是持续性的，而且也是大多数团队悄悄跳过的那一个：你怎么知道那个 Function App 上部署的代码还是你审阅过的版本？你怎么知道那个 Logic App 的工作流定义从上星期二起没有被重写过？你怎么知道没人会在周六凌晨3点给那个托管标识加一个联合身份凭证？
答案就是监控。
不是那种“我们开了 Log Analytics”的监控。而是带着一份特定操作契约的监控。
姿态反转
对于大多数 Azure 工作负载来说，默认的操作姿态是“合理信任”。工程师部署，流水线运行，配置稍微漂移，团队每周审阅一次变更，异常最终会被发现。
但对于一个 Microsoft Entra 扩展来说，这个姿态是错的。默认必须反过来。
一旦 Entra 扩展进入生产环境，对它的每一次变更默认都是可疑的。不是“需要审阅”，不是“先查查再说”。是可疑。
默认状态是：当一个托管自定义声明提供程序的 Function App 触发警报时，“SOC 正在调查，请证明这次变更是经过批准的”。如果你不能在团队响应 SLA 内证明这个变更是被批准的，那就把它当作事故处理，回滚。
这个姿态是故意严苛的。
原因还是我在第一篇文章里讲的那个核心问题：RBAC 继承链。一个比你高四个管理组的参与者，可以通过继承链悄悄替换你的 Function App 代码。你不能指望部署面很小，你必须让警报面足够响亮。
这个反转就是本文要讲的监控契约。
三个变更面
一个生产环境中的 Entra 扩展有三个变更面，每个都需要自己的强制诊断控制、自己的警报、以及操作契约上的独立一行。
面1：运行时本身
这是大多数团队首先想到的面，也是大多数团队监控不足的面。
- Function App 上部署的代码
- Logic App 的工作流定义
- 应用设置
- 环境变量
- 运行时版本
- 配置的自定义域名
这些每一个都是一个旋钮，只要被转动，下一次 Entra 调用这个扩展时行为就会改变。
对于自定义声明提供程序的 Function App，需要警报的 Azure Resource Manager 操作有：
Microsoft.Web/sites/extensions/write # 新部署推送
Microsoft.Web/sites/config/appsettings/write # 应用设置变更，包括对 Key Vault 秘密的引用
Microsoft.Web/sites/config/web/write # 运行时版本、启动命令或常规配置变更
Microsoft.Web/sites/publishxml/action # 生成发布配置文件凭证——这是在正常流水线外部署代码的最简单方式之一
对于动态审批的 Logic App，类似的操作有：
Microsoft.Logic/workflows/write # 工作流定义本身被修改
Microsoft.Logic/workflows/connections/write # API 连接被创建或修改
Microsoft.Web/connections/write # 包括连接指向的身份验证目标
每一个都应该由活动日志警报支持，作用域限定在控制平面订阅，并配置一个指向 SOC 主要接收通道的操作组。不是团队的聊天频道，不是邮件列表。是 SOC 的接收通道。
面2：身份和RBAC
这个面看起来跟扩展本身毫无关系，所以最容易忽略。
扩展本身没变，变的是它的爆炸半径。
需要在控制平面订阅上警报的具体事件：
Microsoft.Authorization/roleAssignments/write 发生在继承路径上的任何位置，从资源一直到订阅。一个参与者（或用户访问管理员、所有者）刚刚出现在链上的某个层级。走一遍继承链，问自己：这个新的主体现在是否对 Function App 有有效的参与者权限？如果有，SOC 需要知道。
Microsoft.ManagedIdentity/userAssignedIdentities/federatedIdentityCredentials/write 发生在范围内任何用户分配的托管标识上。一个新的联合身份凭证本质上就是从 Azure 外部以该身份行事的新方式。把它当作凭证发放事件来处理，因为它就是。
Microsoft.KeyVault/vaults/accessPolicies/write 和 Microsoft.Authorization/roleAssignments/write 作用域限定在 Key Vault 上。逻辑跟 RBAC 继承一样，但后果更尖锐：对 Key Vault 有所有者权限，在操作上就等同于拥有其中每一个证书的所有者权限。
Entra 审计日志中的应用注册凭证事件。支撑扩展的 Function App 和 Logic App 都由 Entra 中的应用注册或托管标识做前端。在应用注册中添加新的客户端密钥、证书或联合凭证，这本身就是值得警报的事件，没有例外。Entra 审计日志会将这些捕获为“更新应用程序 – 证书和机密管理”事件，把它们导入同一个 SOC 接收通道。
面3：Entra 侧的绑定
这个面完全存在于 Entra 中，不在 Azure 里。
自定义声明提供程序通过自定义身份验证扩展配置绑定到应用程序。动态审批 Logic App 通过权利管理自定义扩展绑定到访问包。这些绑定就是让 Entra 真正调用你的代码的东西。绑定变了，Entra 现在调用的就是别人写的代码了。
两个值得单独设置警报的事件：
Entra 审计日志中自定义身份验证扩展的变更：端点 URL 被重新指向、API 身份验证配置被更改、扩展被禁用。
权利管理自定义扩展的变更：新的回调 URL、新的身份验证方法、消费该扩展的访问包策略的变更。
IGA 团队已经在监控的同一个 Entra 审计日志源覆盖了大部分内容。额外的一步是确保 SOC 能同时看到这些事件和 Azure 活动日志事件，因为“Entra 绑定移动了”和“一小时前新目标上发生了一次部署”之间的关联，正是你希望分析师能够讲述的故事。
强制诊断：让信号不容置疑
警报只有在信号到达警报引擎时才会触发。三个控制措施将诊断从“我们在大多数资源上启用了它”转变为订阅本身的属性。
使用 deployIfNotExists 的 Azure Policy 进行诊断设置。在控制平面管理组上应用内置或自定义策略，强制在其下创建的每一个 Function App、每一个 Logic App、每一个 Key Vault、每一个存储账户、每一个托管标识都将诊断日志发送到一个专用的租户级 Log Analytics 工作区。策略是 deployIfNotExists，不是 audit，所以缺失的诊断设置由平台修复，而不仅仅是报告出来。
（这部分原文有现成的内置策略示例，但我手头没有完整的策略定义代码，你可以去 Azure 门户里搜“Deploy Diagnostic Settings for Function App to Log Analytics workspace”之类的内置策略，或者自己写一个。关键点是：用 deployIfNotExists 而不是 auditIfNotExists。）
第二层：活动日志诊断设置。确保控制平面订阅本身的活动日志被流式传输到同一个 Log Analytics 工作区。Azure 策略可以做到这一点，但更简单的方法是在订阅级别手动配置诊断设置，或者通过管理组级别的策略来强制执行。
第三层：Entra 审计日志的持续导出。在 Entra 管理中心的“诊断设置”中，创建一个将 AuditLogs 和 SignInLogs 流式传输到同一个 Log Analytics 工作区的设置。这样你就能在一个地方看到 Azure 活动日志和 Entra 审计日志。
操作契约：谁在什么时候做什么
有了信号还不够，你得定义当警报触发时谁负责做什么。这就是操作契约。
对于每个警报，契约应该明确：
- 警报名称：清晰描述触发条件
- 严重性：Sev0（立即响应）到 Sev3（工作时间内响应）
- 响应时间：从警报触发到有人开始调查的时间
- 升级路径：如果第一响应者没处理，谁接手
- 回滚条件：什么情况下自动回滚，什么情况下需要人工判断
- 事后分析要求：每次事故后需要什么级别的文档
举个例子，对于 Function App 代码变更的警报：
| 字段 | 值 |
|---|---|
| 警报名称 | Function App 代码部署检测 |
| 严重性 | Sev1 |
| 响应时间 | 15分钟 |
| 升级路径 | 初级工程师 → 高级工程师 → 架构师 |
| 回滚条件 | 如果15分钟内无法确认是经批准的部署，自动回滚 |
| 事后分析 | 需要记录变更来源、批准状态、影响范围 |
对于联合身份凭证添加的警报：
| 字段 | 值 |
|---|---|
| 警报名称 | 托管标识联合凭证变更 |
| 严重性 | Sev0 |
| 响应时间 | 5分钟 |
| 升级路径 | 初级工程师 → 安全工程师 → SOC 经理 |
| 回滚条件 | 立即移除该凭证，除非能立即确认是经批准的变更 |
| 事后分析 | 需要记录谁批准、为什么需要、是否有替代方案 |
一些实际考虑
你可能会问：“这听起来工作量很大。”
是的。但让我问你一个问题：你更愿意每周花两个小时调整警报规则，还是愿意在周六凌晨3点被叫起来处理一个被攻破的 Entra 扩展？
而且说实话，这里的大部分工作是一次性的。设置好 Azure Policy，配置好诊断设置，写好操作契约，然后就是定期的演练和调整。
另一个常见问题是：“我们团队很小，没有专门的 SOC。”
没关系。你不需要一个24/7的 SOC 团队。你需要的是：
- 把警报路由到正确的人（可能是你团队里的资深工程师）
- 明确的响应流程
- 自动化的回滚能力（比如用 Azure Automation 或 Logic App 来自动回滚未经批准的变更）
最后，不要试图一次性完成所有事情。从最关键的警报开始——运行时变更和身份变更——然后再逐步扩展。
总结
Entra 扩展的控制平面本质决定了你不能用对待普通 Azure 工作负载的方式来对待它。普通工作负载可以容忍一定程度的配置漂移和延迟检测。Entra 扩展不行。
三个关键点：
- 反转默认姿态：每一次变更都是可疑的，直到被证明是清白的
- 覆盖三个变更面：运行时、身份和RBAC、Entra侧绑定，缺一不可
- 强制诊断：用 Azure Policy 确保信号不会被遗漏
做好这些，你才能安心睡觉，知道你的 Entra 扩展不会在半夜被人悄悄替换掉。
系列文章索引：
- Part 1: Microsoft Entra 可扩展性是一份礼物，但它也是控制平面
- Part 2: 保护决定 Entra 信任谁的代码
- Part 3: 对 Entra 扩展的每一次变更都是控制平面事件：监控契约（本文）