https://thedotnetblog.com/zh/tags/managed-identity/Articles, tutorials and insights from the .NET community.Hugozh@thedotnetblog (The .NET Blog)@thedotnetblogThu, 16 Jul 2026 00:00:00 +0000https://thedotnetblog.com/zh/news/emiliano-montesdeoca/cosmosdb-role-assignment-without-secrets/Thu, 16 Jul 2026 00:00:00 +0000Emiliano Montesdeocahttps://thedotnetblog.com/zh/news/emiliano-montesdeoca/cosmosdb-role-assignment-without-secrets/如果你的 Cosmos DB 应用仍然依赖于密钥，你在运维安全上已经落后了。<p>原文来源：<a href="https://devblogs.microsoft.com/cosmosdb/which-azure-cosmos-db-role-does-my-app-need/">Which Azure Cosmos DB Role Does My App Need?</a></p> <p>这个 Cosmos DB 指南中最重要的思想不是一个命令、一个角色 ID 或一个 CLI 技巧——而是架构性的：<strong>停止将凭据视为应用配置</strong>，开始将身份视为运行时状态。</p> <p>太多团队仍然使用连接字符串发布，因为这样感觉很快。其实不快。这是递延的风险。配置文件中的每个密钥都是一个等待发生的事故——一次匆忙的提交、一个复制的管道变量或一个泄漏的日志。托管身份加上数据平面 RBAC 几乎完全消除了这类故障。</p> <p>实际的挑战在于对<strong>控制平面</strong>和<strong>数据平面</strong>授权的混淆。这是很多本来很强大的团队浪费数天时间的地方。资源上的 Azure RBAC 角色不会自动授予文档访问权限，而 Cosmos 数据平面角色也不授予账户管理权限。如果你的团队没有在你的操作手册中明确记录这种分离，你将不断遇到脆弱的部署和难以调试的 403 错误。</p> <h3 id="我对生产团队的个人建议">我对生产团队的个人建议</h3> <ul> <li><strong>读取路径从 Data Reader 开始</strong>，只有确实需要写入的地方才使用 Data Contributor。</li> <li><strong>仅在每个账户有单一应用边界时才广泛授权</strong>。</li> <li><strong>如果你跨多个服务共享一个账户</strong>，尽早将范围缩小到数据库或容器边界，而不是等待审计压力。</li> </ul> <p>这是一类<strong>复利</strong>式的决策。当你用 <code>DefaultAzureCredential</code> 和仅端点配置来连接你的 .NET 应用时，每个环境都变得更干净：本地、CI、staging 和生产。你也能更快地进行事件响应，因为你可以通过角色分配来推理权限，而不是寻找神秘的密钥。</p> <p>文章还暗示了一个成熟团队应该接受的理念：<strong>权限是迭代式设计</strong>，而非一次性设置。你可以从足够宽的范围开始以完成交付，然后通过遥测和访问审查逐步收紧。最小权限不是一个哲学终点，而是一个交付习惯。</p> <p>如果你只从这篇文章中采纳一件事，那就是这个：<strong>先移除密钥，再优化角色</strong>。搞反顺序的团队通常会在会议上卡住。先移除密钥的团队通常先交付，再加固。</p> <p>在 2026 年，<strong>无密钥数据访问不是一个高级模式</strong>。它是在 Azure 上运行严肃 .NET 系统的最低负责任标准。</p>