Azure リソースに名前を付ける際の考慮事項

Azure リソース名に機密情報や制限付き情報を含めてはならないのは、それがコンプライアンス境界の外で保存またはアクセスされる可能性があるためです。そのことにより、サポートやトラブルシューティングが容易になります。 機密情報の例には、次の対象となるデータが含まれます。

顧客の VM、ストレージ アカウント、データベース、Azure Import/Export、Azure Managed Redis、ExpressRoute、Azure AI Search、App Service、API Management、および顧客データの保持、処理、または送信に適した他の Azure サービスに格納または処理されるデータには、機密データが含まれている可能性があります。 ただし、これらの Azure サービスのメタデータには、機密性の高いデータや制限されたデータを含めることはできません。 このメタデータには、Azure サービスの作成時と保守時に入力されたすべての構成データが含まれます。これには、次のものが含まれます。

  • サブスクリプション名、サービス名、サーバー名、データベース名、テナント ロール名、リソース グループ、デプロイ名、リソース名、リソース タグ、回線名など。
  • 配送業者名、追跡番号、説明、返品情報、ドライブ一覧、パッケージ一覧、ストレージ アカウント名、コンテナー名など、Azure Import/Export のメディアを転送するために使用されるすべての発送情報。
  • API の一部として検索/クエリ文字列で REST API に送信される HTTP ヘッダー内のデータ。
  • デバイス/ポリシー/アプリケーション、および Intune に送信される その他のメタデータ

Azure リソース名には、ソフトウェア、システム、コンテナーなどのクラウド サービス リソースを識別または構成するために使用される、ユーザーまたはユーザーに代わって提供される情報が含まれます。 ただし、顧客が作成したコンテンツやメタデータはリソース内に含 まれません (データベースの列名やテーブル名など)。 Azure リソース名には、Azure Resource Manager レベルのオブジェクトに割り当てる名前と、Azure にデプロイされたリソースが含まれます。 たとえば、仮想ネットワーク、仮想ハード ディスク、データベース サーバーとデータベース、仮想ネットワーク インターフェイス、ネットワーク セキュリティ グループ、キー コンテナーなどのリソースの名前が挙げられます。

上記の例は、名前を付けることができるリソースの種類のサブセットです。 この一覧は完全に網羅されたものではなく、新しいクラウド サービスが追加されるにつれて、将来リソースの種類が変わる可能性があります。

名前付け規則

Azure リソースの名前は、次のように、より大きなリソース ID の一部です。

/subscriptions/<subscriptionID>/resourceGroups/<ResourceGroupName>/providers/<ResourceProvider>/<ResourceType>/<ResourceName>

仮想マシンのリソース ID の例を次に示します。

/subscriptions/<subscriptionID>/resourceGroups/<ResourceGroupName>/providers/Microsoft.Compute/virtualMachines/<virtualMachineName>

名前付けに関する考慮事項

ビジネスやミッションの機能に敏感な名前は避ける必要があります。 このガイダンスは、大規模なリソース グループの名前から、その中のエンド リソースの名前まで、前述の条件を満たすすべての名前に適用されます。 また、規制要件を示す名前は避ける必要があります。次に例を示します。

また、リソースの名前付け とタグ付けの決定ガイドを確認するときは、リソース タグの名前付けを検討してください。

次の例のシナリオでは、Microsoft の担当者が完全なリソース ID を使用する可能性があるので、運用上のセキュリティを確保するために、リソースの名前付け規則を理解し、考慮する必要があります。

  • Microsoft サポート担当者は、サポート イベント中にリソースの完全なリソース ID を使用して、お客様のサブスクリプション内の適切なリソースを確実に特定できます。
  • Microsoft 製品エンジニアリング担当者は、テレメトリ データの定期的な監視中に完全なリソース ID を使用して、ベースラインまたは平均システム パフォーマンスからの逸脱を特定できます。
  • 内部で検出されたインシデント中に影響を受けるリソースに関する顧客へのプロアクティブな通信。

次のステップ