<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>Cloud-Security | The .NET Blog</title><link>https://thedotnetblog.com/ja/tags/cloud-security/</link><description>Articles, tutorials and insights from the .NET community.</description><generator>Hugo</generator><language>ja</language><managingEditor>@thedotnetblog (The .NET Blog)</managingEditor><webMaster>@thedotnetblog</webMaster><lastBuildDate>Thu, 16 Jul 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://thedotnetblog.com/ja/tags/cloud-security/index.xml" rel="self" type="application/rss+xml"/><item><title>Cosmos DB Access Without Secrets Is the New Baseline</title><link>https://thedotnetblog.com/ja/news/emiliano-montesdeoca/cosmosdb-role-assignment-without-secrets/</link><pubDate>Thu, 16 Jul 2026 00:00:00 +0000</pubDate><author>Emiliano Montesdeoca</author><guid>https://thedotnetblog.com/ja/news/emiliano-montesdeoca/cosmosdb-role-assignment-without-secrets/</guid><description>Cosmos DB アプリが依然としてキーに依存しているなら、あなたはすでに運用セキュリティにおいて時代遅れである。</description><content:encoded>&lt;p&gt;オリジナルソース: &lt;a href="https://devblogs.microsoft.com/cosmosdb/which-azure-cosmos-db-role-does-my-app-need/"&gt;Which Azure Cosmos DB Role Does My App Need?&lt;/a&gt;&lt;/p&gt;
&lt;p&gt;この Cosmos DB ガイダンスの中で最も重要なアイデアは、コマンドでもロール ID でも CLI のトリックでもない。それはアーキテクチャ上のものである:&lt;strong&gt;資格情報をアプリ設定として扱うのをやめ&lt;/strong&gt;、ID をランタイム状態として扱い始めること。&lt;/p&gt;
&lt;p&gt;あまりに多くのチームが、高速に感じられるという理由で接続文字列を出荷し続けている。それは高速ではない。延期されたリスクである。設定ファイル内のすべてのキーは、急いだコミット、コピーされたパイプラインパラメータ、漏洩したログを待つインシデントとなる。マネージド ID とデータプレーン RBAC は、そのクラスの障害をほぼ完全に排除する。&lt;/p&gt;
&lt;p&gt;実践的な課題は、&lt;strong&gt;コントロールプレーン&lt;/strong&gt;と&lt;strong&gt;データプレーン&lt;/strong&gt;の認可の混乱である。ここで、多くの優れたチームが何日も無駄にする。リソースに対する Azure RBAC ロールは自動的にドキュメントアクセスを付与せず、Cosmos DB データプレーンロールはアカウント管理を付与しない。チームがその分離をランブックに明示的に文書化していなければ、脆いデプロイとデバッグが難しい 403 エラーに繰り返し悩まされることになる。&lt;/p&gt;
&lt;h3 id="本番チームへの私の意見付き推奨"&gt;本番チームへの私の意見付き推奨&lt;/h3&gt;
&lt;ul&gt;
&lt;li&gt;&lt;strong&gt;読み取りパスには Data Reader から始め&lt;/strong&gt;、書き込みが真に必要な場合にのみ Data Contributor を使用する。&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;アカウントごとに単一のアプリケーション境界がある場合にのみ&lt;/strong&gt;、広範囲にスコープする。&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;アカウントをサービス間で共有している場合&lt;/strong&gt;、監査のプレッシャーを待つのではなく、早期にデータベースまたはコンテナ境界にスコープを絞る。&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;これは&lt;strong&gt;複利で効く&lt;/strong&gt;決定のひとつである。.NET アプリを &lt;code&gt;DefaultAzureCredential&lt;/code&gt; とエンドポイントのみの設定で配線すると、ローカル、CI、ステージング、本番のすべての環境がクリーンになる。また、インシデント対応も迅速になる。なぜなら、謎のキーを探し回る代わりに、ロール割り当てを通じて権限を推論できるからである。&lt;/p&gt;
&lt;p&gt;この記事はまた、成熟したチームが受け入れるべきことを示唆している:&lt;strong&gt;権限は反復設計であり、一度きりの設定ではない&lt;/strong&gt;。デリバリー可能な範囲から始め、テレメトリとアクセスレビューで絞り込むことができる。最小特権は哲学的な終点ではなく、デリバリーの習慣である。&lt;/p&gt;
&lt;p&gt;この投稿からひとつだけ採用するとすれば、これにしなさい:&lt;strong&gt;最初にシークレットを除去し、次にロールを最適化する&lt;/strong&gt;。その順序を逆にしたチームは、通常、ミーティングで膠着する。最初にシークレットを除去するチームは、通常、出荷し、その後で強化する。&lt;/p&gt;
&lt;p&gt;2026年において、&lt;strong&gt;シークレットなしのデータアクセスは高度なパターンではない&lt;/strong&gt;。Azure 上の真剣な .NET システムにとっての最低限の責任ある基準である。&lt;/p&gt;</content:encoded></item></channel></rss>