ストレージ アカウントと信頼性

  • [アーティクル]

Azure ストレージ アカウントは、高速の一貫した応答時間を必要とするワークロードや、1 秒あたりの入出力操作数 (IOP) が多いワークロードに最適です。 ストレージ アカウントには、以下のようなすべての Azure Storage データ オブジェクトが含まれています。

  • BLOB
  • ファイル共有
  • キュー
  • テーブル
  • ディスク

ストレージ アカウントを使用すると、HTTP または HTTPS 経由でどこからでもアクセスできるデータ用の一意の名前空間が提供されます。

さまざまな機能をサポートする各種ストレージ アカウントの詳細については、「ストレージ アカウントの種類」を参照してください。

Azure ストレージ アカウントがアプリケーション ワークロードの回復性をどのようにサポートするかについては、次の記事を参照してください。

以下のセクションでは、Azure ストレージ アカウントと信頼性に特有の設計上の考慮事項、構成チェックリスト、および推奨される構成オプションについて説明します。

設計上の考慮事項

Azure ストレージ アカウントは、次のような考慮事項を踏まえて設計されています。

  • 汎用 v1 ストレージ アカウントでは、すべての Azure Storage サービスにアクセスできますが、最新の機能が利用できない場合があるほか、GB 単価もやや高いことがあります。 ほとんどの場合では、汎用 v2 ストレージ アカウントを使用することをお勧めします。 v1 を使用する理由には以下のようなものがあります。

    • アプリケーションで、クラシック デプロイ モデルが必要な場合。
    • トランザクションが集中する、または geo レプリケーション帯域幅を大幅に使用するが、大容量である必要はないアプリケーションの場合。
    • 2014 年 2 月 14 日より前のストレージ サービス REST API、または 4.x より前のバージョンのクライアント ライブラリを使用する必要がある場合。 アプリケーションをアップグレードすることはできません。

詳細については、「ストレージ アカウントの概要」を参照してください。

  • ストレージ アカウント名は 3 から 24 文字にする必要があり、数字と小文字のみを含めることができます。
  • 現在の SLA 仕様については、「ストレージ アカウントの SLA」を参照してください。
  • 特定のシナリオに最適な冗長オプションを決定するには、「Azure Storage の冗長性」を参照してください。
  • ストレージ アカウント名は、Azure 内で一意である必要があります。 複数のストレージ アカウントが同じ名前を持つことはできません。

チェック リスト

信頼性を考慮して Azure ストレージ アカウントを構成しましたか?

  • BLOB データの論理的な削除を有効にする。
  • Microsoft Entra ID を使用して、BLOB データへのアクセスを承認します。
  • Azure RBAC を使用してMicrosoft Entraセキュリティ プリンシパルにアクセス許可を割り当てる場合は、最小限の特権の原則を考慮してください。
  • マネージド ID を使用して BLOB とキュー データにアクセスする。
  • BLOB のバージョン管理または不変 BLOB を使用して、ビジネス クリティカルなデータを格納する。
  • ストレージ アカウントに対する既定のインターネット アクセスを制限する。
  • ファイアウォール規則を有効にします。
  • 特定のネットワークにネットワーク アクセスを制限します。
  • 信頼された Microsoft サービスによるストレージ アカウントへのアクセスを許可します。
  • すべてのストレージ アカウントで [安全な転送が必須] オプションを有効にする。
  • Shared Access Signature (SAS) トークンを HTTPS 接続のみに制限する。
  • ストレージ アカウントへのアクセスに共有キー認証を使用することを避ける。
  • アカウント キーを定期的に再生成します。
  • クライアントに発行するすべての SAS に対して失効計画を作成する。
  • 即席 SAS、SAS サービス、またはアカウント SAS には、短期間の有効期限を使用する。

構成に関する推奨事項

Azure ストレージ アカウントを構成するときに、次の推奨事項を考慮して信頼性を最適化します。

推奨 Description
BLOB データの論理的な削除を有効にする。 Azure Storage BLOB の論理的な削除を使用すると、削除されてしまった BLOB データを回復できます。
Microsoft Entra ID を使用して、BLOB データへのアクセスを承認します。 Microsoft Entra ID は、BLOB ストレージへの要求を承認するための共有キーよりも優れたセキュリティと使いやすさを提供します。 共有キーに固有の潜在的なセキュリティ脆弱性を最小限に抑えるために、可能な場合は BLOB アプリケーションとキュー アプリケーションでMicrosoft Entra承認を使用することをお勧めします。 詳細については、「Microsoft Entra ID を使用して Azure BLOB とキューへのアクセスを承認する」を参照してください。
Azure RBAC を使用してMicrosoft Entraセキュリティ プリンシパルにアクセス許可を割り当てる場合は、最小限の特権の原則を考慮してください。 ユーザー、グループ、またはアプリケーションにロールを割り当てる場合は、そのセキュリティ プリンシパルに対して、それぞれのタスクを実行するために必要なアクセス許可のみを付与します。 リソースへのアクセスを制限することで、意図しない、または悪意のあるデータの誤用を防ぐことができます。
マネージド ID を使用して BLOB とキュー データにアクセスする。 Azure Blob と Queue Storage では、Azure リソースのマネージド ID を使用したMicrosoft Entra認証がサポートされます。 Azure リソースのマネージド ID は、Azure 仮想マシン (VM)、関数アプリ、仮想マシン スケール セット、およびその他のサービスで実行されているアプリケーションからのMicrosoft Entra資格情報を使用して、BLOB およびキュー データへのアクセスを承認できます。 Azure リソースのマネージド ID をMicrosoft Entra認証と共に使用することで、クラウドで実行されるアプリケーションに資格情報を格納したり、サービス プリンシパルの期限切れに関する問題を回避したりできます。 詳細については、「Azure リソースに対するマネージド ID を使用して BLOB およびキュー データへのアクセスを認証する」を参照してください。
BLOB のバージョン管理または不変 BLOB を使用して、ビジネス クリティカルなデータを格納する。 BLOB のバージョン管理を使用してオブジェクトの以前のバージョンを保持したり、訴訟ホールドや時間ベースの保持ポリシーを使用して、WORM (Write Once, Read Many) 状態で BLOB データを保存したりすることを検討します。 不変 BLOB は読み取ることができますが、保持間隔中は変更や削除ができません。 詳細については、「不変ストレージを使用してビジネスに不可欠な BLOB データを保存する」を参照してください。
ストレージ アカウントに対する既定のインターネット アクセスを制限する。 既定では、ストレージ アカウントへのネットワーク アクセスは制限されておらず、インターネットから送信されるすべてのトラフィックに対して開かれています。 ストレージ アカウントへのアクセスは、可能な限り特定の Azure 仮想ネットワーク にのみ付与するか、プライベート エンドポイントを使用して、仮想ネットワーク (VNet) 上のクライアントが Private Link を介して安全にデータにアクセスできるようにする必要があります。 詳細については、「Azure Storage のプライベート エンドポイントを使用する」を参照してください。 インターネット経由でアクセスする必要があるストレージ アカウントについては、例外を設けることができます。
ファイアウォール規則を有効にします。 ストレージ アカウントへのアクセスを、Azure 仮想ネットワーク (VNet) 内の指定した IP アドレス、IP 範囲、またはサブネットのリストから発信された要求に制限するように、ファイアウォール規則を構成します。 ファイアウォール規則の構成の詳細については、「Azure Storage ファイアウォールおよび仮想ネットワークを構成する」を参照してください。
特定のネットワークにネットワーク アクセスを制限します。 ネットワークへのアクセスを、アクセスを必要としているクライアントをホストしているネットワークに限定することで、組み込みのファイアウォールや仮想ネットワーク機能を利用したり、プライベート エンドポイントを利用したりして、リソースがネットワーク攻撃にさらされることを防ぎます。
信頼された Microsoft サービスによるストレージ アカウントへのアクセスを許可します。 ストレージ アカウントのファイアウォール規則を有効にすると、Azure 仮想ネットワーク (VNet) 内で動作しているサービス、または許可されたパブリック IP アドレスから送信された要求でない限り、データに対して受信した要求は既定でブロックされます。 ブロックされる要求には、他の Azure サービスからの要求、Azure portal からの要求、ログおよびメトリック サービスからの要求などが含まれます。 例外を追加して、信頼された Microsoft サービスがストレージ アカウントにアクセスできるようにすることによって、他の Azure サービスからの要求を許可できます。 信頼済みの Microsoft サービスを例外に追加する方法の詳細については、「Azure Storage ファイアウォールおよび仮想ネットワークを構成する」を参照してください。
すべてのストレージ アカウントで [安全な転送が必須] オプションを有効にする。 [安全な転送が必須] オプションを有効にすると、ストレージ アカウントに対して行われるすべての要求が、セキュリティで保護された接続を経由して実行される必要があります。 HTTP 経由で行われた要求はすべて失敗します。 詳細については、「Azure Storage で安全な転送が必要」を参照してください。
Shared Access Signature (SAS) トークンを HTTPS 接続のみに制限する。 クライアントが SAS トークンを使用して BLOB データにアクセスするときに HTTPS を要求することで、盗聴のリスクを最小限に抑えることができます。 詳細については、「Shared Access Signatures (SAS) を使用して Azure Storage リソースへの制限付きアクセスを許可する」を参照してください。
ストレージ アカウントへのアクセスに共有キー認証を使用することを避ける。 Microsoft Entra ID を使用して Azure Storage への要求を承認し、共有キーの承認を防ぐことをお勧めします。 共有キーによる認証が必要なシナリオでは、共有キーを配布する代わりに、SAS トークンを使用することをお勧めします。
アカウント キーを定期的に再生成します。 アカウント キーを定期的に交換することで、悪意のあるアクターにデータが公開されるリスクが軽減されます。
クライアントに発行するすべての SAS に対して失効計画を作成する。 SAS が侵害された場合は、その SAS を即座に失効させることをお勧めします。 ユーザーの委任 SAS を失効させるには、ユーザーの委任キーを失効させて、そのキーに関連付けられているすべての署名をただちに無効にします。 保存されているアクセス ポリシーに関連付けられているサービス SAS を失効させるには、保存されているアクセス ポリシーを削除するか、ポリシーの名前を変更するか、または有効期限を過去の時間に変更します。
即席 SAS、SAS サービス、またはアカウント SAS には、短期間の有効期限を使用する。 SAS が侵害された場合でも、有効である期間はほんの短い期間になります。 この方法は、保存されているアクセス ポリシーを参照できない場合に特に重要です。 また、短期間の有効期限は、BLOB にアップロード可能な時間が制限されるので、BLOB に書き込むことのできるデータの量も制限します。 クライアントでは、SAS を提供するサービスを使用できない場合に再試行する時間を考慮して、有効期限までに余裕を持って SAS を更新する必要があります。

次のステップ

ストレージ アカウントとセキュリティ