オリジナルソース: Which Azure Cosmos DB Role Does My App Need?
この Cosmos DB ガイダンスの中で最も重要なアイデアは、コマンドでもロール ID でも CLI のトリックでもない。それはアーキテクチャ上のものである:資格情報をアプリ設定として扱うのをやめ、ID をランタイム状態として扱い始めること。
あまりに多くのチームが、高速に感じられるという理由で接続文字列を出荷し続けている。それは高速ではない。延期されたリスクである。設定ファイル内のすべてのキーは、急いだコミット、コピーされたパイプラインパラメータ、漏洩したログを待つインシデントとなる。マネージド ID とデータプレーン RBAC は、そのクラスの障害をほぼ完全に排除する。
実践的な課題は、コントロールプレーンとデータプレーンの認可の混乱である。ここで、多くの優れたチームが何日も無駄にする。リソースに対する Azure RBAC ロールは自動的にドキュメントアクセスを付与せず、Cosmos DB データプレーンロールはアカウント管理を付与しない。チームがその分離をランブックに明示的に文書化していなければ、脆いデプロイとデバッグが難しい 403 エラーに繰り返し悩まされることになる。
本番チームへの私の意見付き推奨
- 読み取りパスには Data Reader から始め、書き込みが真に必要な場合にのみ Data Contributor を使用する。
- アカウントごとに単一のアプリケーション境界がある場合にのみ、広範囲にスコープする。
- アカウントをサービス間で共有している場合、監査のプレッシャーを待つのではなく、早期にデータベースまたはコンテナ境界にスコープを絞る。
これは複利で効く決定のひとつである。.NET アプリを DefaultAzureCredential とエンドポイントのみの設定で配線すると、ローカル、CI、ステージング、本番のすべての環境がクリーンになる。また、インシデント対応も迅速になる。なぜなら、謎のキーを探し回る代わりに、ロール割り当てを通じて権限を推論できるからである。
この記事はまた、成熟したチームが受け入れるべきことを示唆している:権限は反復設計であり、一度きりの設定ではない。デリバリー可能な範囲から始め、テレメトリとアクセスレビューで絞り込むことができる。最小特権は哲学的な終点ではなく、デリバリーの習慣である。
この投稿からひとつだけ採用するとすれば、これにしなさい:最初にシークレットを除去し、次にロールを最適化する。その順序を逆にしたチームは、通常、ミーティングで膠着する。最初にシークレットを除去するチームは、通常、出荷し、その後で強化する。
2026年において、シークレットなしのデータアクセスは高度なパターンではない。Azure 上の真剣な .NET システムにとっての最低限の責任ある基準である。
