本記事は Microsoft Learn の「Azure Storage セキュリティを構成する」というモジュールをまとめたものである。
Azure Storage セキュリティの戦略を確認する
管理者はデータを保護するために、暗号化、認証、認可、資格情報管理、ファイルアクセス許可、プライベート署名などの戦略を使用する。Azure Storage では、こうした一般的な戦略に基づくセキュリティ機能が提供されている。
Azure Storage のセキュリティ戦略について知っておくべきこと
保存時の暗号化
- Storage Service Encryption (SSE) を使い、Azure Storage に書き込まれるすべてのデータを 256 ビット AES で自動暗号化。読み取り時には自動復号化。追加コストやパフォーマンス低下なし
- VHD 暗号化 では、Windows は BitLocker、Linux は dm-crypt を使用
転送中の暗号化
- クライアントと Azure 間の通信には HTTPS を推奨
- ストレージアカウントで 安全な転送 を有効にすると、HTTP 接続を拒否し、SMB 3.0 でのファイル共有も保護
暗号化モデル
- サーバー側暗号化（SSE）では、Azure 管理キー、Key Vault 管理キー、ハードウェア管理キーが選択可能
- クライアント側暗号化では、キーをオンプレミスや別の安全な場所で管理可能
要求の承認
- Microsoft Entra ID と マネージド ID を使用した承認を推奨。共有キーよりセキュリティと利便性が高い
RBAC（ロールベースアクセス制御）
- 必要なときだけアクセス権を付与
- ストレージアカウント単位で RBAC ロールを割り当てることで、権限管理を細かく制御可能
ストレージ分析
- Storage Analytics により、リクエストのログ、使用傾向分析、問題診断が可能
認可のセキュリティを使うときに考慮すべきこと
| 認可戦略 | 説明 |
|---|---|
| Microsoft Entra ID | クラウドベースの ID 管理サービス。RBAC を用いて、ユーザーやグループ、アプリケーションに細かくアクセス権を割り当てられる。 |
| 共有キー | ストレージ アカウントのアクセスキーを使い、暗号化署名文字列を生成。要求の Authorization ヘッダーで送信してアクセスを認可する。 |
| 共有アクセス署名 (SAS) | 特定のリソースへのアクセス権を、指定した期間と許可範囲で委任できる。 |
| コンテナー・BLOB の匿名アクセス | パブリックに設定したコンテナーや BLOB へは、任意のユーザーが匿名で読み取りアクセス可能。読み取り要求に認可は不要。 |
Shared Access Signature を作成する
SAS は Azure Storage リソースへの制限付きアクセス権を付与する URI である。
これにより、ストレージ アカウントのアクセスキーを危険にさらさずに、特定のリソースを安全に共有できる。
-
SAS の基本
ストレージアカウントキーにアクセスできないクライアントに対して、SAS URI を発行して特定のリソースへのアクセスを制限付きで許可できる。通常は、他のユーザーやサービスに読み書き権限を与える用途で使う -
ユーザー委任 SAS
Microsoft Entra の資格情報でセキュリティ保護された SAS で、BLOB でのみ使用できる -
アカウントレベルの SAS
サービスレベル SAS でできる権限に加え、アカウント全体のリソースや機能へのアクセスも許可できる -
サービスレベルの SAS
BLOB、キュー、テーブル、Files のいずれかのストレージサービスにおいて、1つのリソースへのアクセスを提供できる -
保存されたアクセスポリシー
サーバー側で SAS を使用する際、SAS をグループ化してポリシーで追加制限を指定可能
リスク管理に関する推奨事項
| 推奨事項 | 説明 |
|---|---|
| 作成・配布には HTTPS を使用 | HTTP で渡すと中間者攻撃で SAS が悪用される可能性があるため、常に HTTPS を使用する。 |
| 保存されたアクセスポリシーを参照 | アクセスポリシーを使うと、アカウントキーを再生成せずに SAS を失効できる。キーの有効期限は遠い将来に設定。 |
| SAS の有効期限を短く設定 | 期間を制限することで、SAS が侵害された場合のリスクを低減。BLOB 書き込み量も制限できる。 |
| クライアントに自動更新を要求 | 有効期限が切れる前に SAS を更新させ、サービス停止時の再試行余裕を確保。 |
| 開始時刻の設定に注意 | "今すぐ" に設定するとクロック差によりエラーが発生することがある。開始時刻は過去 15 分以内に設定するか指定しない。 |
| 最小アクセス許可を定義 | 必要最小限の権限のみ付与し、SAS が侵害された場合の被害を抑える。 |
| 書き込まれたデータを検証 | クライアントが書き込んだデータを確認し、破損や悪意あるデータからアカウントを保護。 |
| SAS を万能と考えない | リスクが大きい操作では、SAS ではなく中間層サービスや別のアクセス管理方法を検討。公開リソースはコンテナーをパブリックにする方が簡単な場合もある。 |
URI パラメーターと SAS パラメーターを識別する
Shared Access Signature (SAS) は、パラメーターとトークンを組み合わせた URI を生成し、この URI を使うことで特定の Azure Storage リソースに制限付きアクセスが可能になる。
URI 定義について知っておくべきこと
サービスレベルの SAS では、URI のパラメーターを使ってアクセス権、対象リソース、有効期間、署名情報を指定し、BLOB など特定リソースへの制限付きアクセスを安全に提供できる。
https://myaccount.blob.core.windows.net/?restype=service&comp=properties&sv=2015-04-05&ss=bf&st=2015-04-29T22%3A18%3A26Z&se=2015-04-30T02%3A23%3A26Z&sr=b&sp=rw&sip=168.1.5.60-168.1.5.70&spr=https&sig=F%6GRVAZ5Cdj2Pw4tgU7IlSTkWgn7bUkkAg8P6HESXwmf%4B
| パラメーター | 例 | 説明 |
|---|---|---|
| リソース URI | https://myaccount.blob.core.windows.net/?restype=service&comp=properties |
Azure Storage のエンドポイントと操作対象を指定。GET でプロパティ取得、SET でプロパティ設定。 |
| Storage バージョン | sv=2015-04-05 |
使用する Azure Storage バージョンを指定。 |
| Storage サービス | ss=bf |
SAS が適用されるサービスを指定（Blob Storage、Azure Files など）。 |
| 開始時刻 | st=2015-04-29T22%3A18%3A26Z |
SAS の有効開始時刻（UTC）。省略可能で、すぐに有効にすることも可能。 |
| 有効期限 | se=2015-04-30T02%3A23%3A26Z |
SAS の有効期限（UTC）。 |
| リソース | sr=b |
SAS でアクセス可能なリソースを指定（例: Blob）。 |
| アクセス許可 | sp=rw |
読み取り・書き込みなど、付与する権限を指定。 |
| IP 範囲 | sip=168.1.5.60-168.1.5.70 |
アクセスを許可するクライアントの IP アドレス範囲を指定。 |
| プロトコル | spr=https |
SAS によるアクセスを許可するプロトコル（HTTP/HTTPS）を指定。 |
| 署名 | sig=F%6GRVAZ5Cdj2Pw4tgU7IlSTkWgn7bUkkAg8P6HESXwmf%4B |
HMAC 署名でアクセス認証。SHA256 と Base64 エンコードで生成。 |
Azure Storage の暗号化を決定する
Azure Storage のデータは、自動的に暗号化・復号化され、コードやアプリを変更せずに保護される。ストレージ アカウント作成時に生成される 2 つの 512 ビットアクセスキーは、共有キー認証や SAS トークンでのアクセス承認に使用される。アクセスキーは Azure Key Vault で管理し、定期的なローテーションや再生成で安全性を維持できる。
Azure Storage の暗号化について知っておくべきこと
Azure Storage の暗号化には以下の特徴がある：
- データは書き込まれる前に自動で暗号化される
- データ取得時に自動で復号される
- 暗号化やキー管理はユーザーに透過的に行われる
- すべてのデータは 256 ビット AES によって保護される
- 暗号化はすべてのストレージ アカウントで常に有効で、無効化はできない
Azure Storage の暗号化を構成する
Azure Storage の暗号化は、Azure ポータルで暗号化の種類を指定して構成できる。キーは自分で管理することも、Microsoft に管理を任せることも可能で、ストレージのセキュリティを確保するために適切な暗号化の設定方法を検討する必要がある。
-
インフラストラクチャの暗号化
- ストレージ アカウント全体または暗号化スコープ単位で有効化可能
- データはサービス レベルとインフラストラクチャ レベルの 2 回、異なるアルゴリズムとキーで暗号化される
-
プラットフォームで管理されるキー (PMK)
- Azure が完全に生成、保存、管理するキー
- ユーザーは操作不可
- 既定で Azure Data Encryption-at-Rest に使用
-
カスタマーマネージドキー (CMK)
- ユーザーが読み取り、作成、削除、更新、管理するキー
- キーはユーザー所有のコンテナーまたは HSM に保存
- BYOK (Bring Your Own Key) では外部からキーをインポート可能
カスタマーマネージドキーを作成する
Azure Storage の暗号化キーは、Azure Key Vault を使って管理できる。Key Vault API によりキーを生成できるほか、独自に作成したキーをキーコンテナーに格納して利用することも可能である。
カスタマーマネージドキーについて知っておくべきこと
カスタマーマネージドキーは、ユーザー自身が暗号化キーを作成・管理することで、柔軟性と制御性を高められる。Azure Storage の暗号化にも利用可能であり、新しいキーや既存のキーコンテナーを活用できる。ストレージアカウントとキーコンテナーは同じリージョン内である必要があるが、サブスクリプションは異なっていても問題ない。
- 独自キーの作成により柔軟性と制御性が向上
- 暗号化キーのアクセス制御、無効化、監査、ローテーション、定義を管理可能
- Azure Storage 暗号化で使用可能
- 新規キーまたは既存キーコンテナーを使用可能
- ストレージアカウントとキーコンテナーは同一リージョン内で必要、サブスクリプションは異なっても可
顧客が管理するキーを構成する
Azure portal では、カスタマー マネージド暗号化キー (CMK) を設定できる。暗号化キーは Microsoft に管理させることも、自分で管理することも可能である。独自にキーを作成する場合は、Azure Key Vault を利用して CMK を作成する方法を検討するとよい。
- 暗号化の種類: キー管理を Microsoft または顧客自身で選択
- 暗号化キー: URI を入力して指定するか、既存のキー コンテナーから選択
Azure Storage セキュリティのベストプラクティスを適用する
Storage Insights は、Azure Storage アカウント全体の監視機能を提供する。これにより、Azure Storage サービスのパフォーマンス、容量、可用性を統合的に把握できる。
Storage Insights の利点は何ですか?
- 詳細なメトリックとログ: ストレージ操作に関する詳細なメトリック、ログ、診断情報を提供。待機時間、スループット、容量使用率、トランザクションなどの KPI を監視可能
- セキュリティとコンプライアンスの強化: 実用的な分析情報とアラートにより、セキュリティ問題を迅速に特定・対応可能
- ロールベースのアクセス制御 (RBAC): Microsoft Entra ID、接続文字列、ACL などと統合され、安全なデータアクセスを保証
- 統合ビュー: Azure Storage サービスのパフォーマンス、容量、可用性を統一的に表示し、ストレージアカウントの効率とセキュリティ維持に寄与
Storage Insights のセキュリティの使用
- リアルタイム監視: ストレージアカウントをリアルタイムで監視し、使用状況の傾向追跡、パフォーマンス監視、異常アラートの設定が可能
- セキュリティ監査: 包括的な監視と詳細なログにより、セキュリティ問題の特定やコンプライアンス維持を支援
- 健康分析と最適化: ストレージアカウントの正常性を分析し、最適なパフォーマンスとセキュリティを確保
演習: Azure Storage を管理する
組織では現在、オンプレミスのデータストアにデータを保存している。ほとんどのファイルは頻繁にアクセスされないため、アクセス頻度の低いファイルを低価格のストレージ層に移すことでコストを最小化したい。さらに、Azure Storage が提供するネットワークアクセス、認証、認可、レプリケーションなどの保護機能を確認したい。最後に、Azure Files がオンプレミスのファイル共有のホスティングにどの程度適しているか評価したい。
アーキテクチャ図
タスク 1: ストレージ アカウントの作成と構成
- Azure ポータルにサインイン
- 「ストレージ アカウント」を検索して選択し、次に「+ 作成」をクリック
-
「ストレージ アカウントの作成」ブレードの [基本] タブで、以下の設定を指定（その他はデフォルトのまま）
- サブスクリプション：自分の Azure サブスクリプション名
- リソース グループ：az104-rg7（新規作成）
- ストレージ アカウント名：3～24文字の英数字でグローバルに一意な名前
- リージョン：(US) East US
- パフォーマンス：Standard（Premium も選択可能）
- 冗長性：Geo-redundant storage（他のオプションも確認可能）
- リージョンの可用性イベント時にデータへの読み取りアクセスを許可：チェックを入れる
- 詳細設定タブで情報アイコンを確認して選択肢を学ぶ。デフォルトのままにする
- ネットワークタブでPublic network access（パブリック ネットワーク アクセスを 無効 に設定（インバウンドを制限、アウトバウンドは許可）
- データ保護タブを確認。デフォルトのソフト削除保持期間は 7 日。Blob のバージョン管理も有効化可能。デフォルトを使用
- 暗号化タブを確認。追加セキュリティオプションもあるがデフォルトを使用
- 確認および作成を選択し、検証完了後に 作成 をクリック
- ストレージアカウントがデプロイされたら リソースに移動 を選択
- 概要ブレードを確認。ストレージ アカウントは Blob コンテナー、ファイル共有、キュー、テーブルで使用可能で、追加設定も変更可能
-
セキュリティ + ネットワーク ブレードでネットワークを選択
- Public network access が無効になっていることを確認
- Manage を選択し、Public network access を Enabled（有効）に変更
- Public network access の範囲を Enable from selected networks（選択したネットワークから有効）に変更
- IPv4 Addresses セクションで Add your client IPv4 address（クライアント IPv4 アドレスを追加）を選択
- 変更を保存
- データ管理ブレードで 冗長性 を選択。プライマリおよびセカンダリ データセンターの情報を確認する
- [Data management（データ管理）] ブレードで Lifecycle management（ライフサイクル管理） を選択し、Add a rule（ルールの追加） をクリック
- ルール名に Movetocool を指定
- ルールの適用範囲を制限するオプションを確認
- 次へ（Next）をクリック
-
Add rule ページで、最終更新日が30日以上前の BLOB を Cool ストレージに移動
- 他の条件やオプションも確認可能
- 設定を確認したら Add をクリック
- ルール名に Movetocool を指定
タスク 2: セキュアな BLOB ストレージの作成と構成
BLOB コンテナーの作成と時限保持ポリシーの設定
- Azure ポータルでストレージ アカウントを開き、Data storage ブレードで Containers を選択
- + Add container をクリックして、以下の設定でコンテナーを作成
- コンテナー作成後、右端の省略記号 (…) をクリックして Access Policy を選択
- Immutable blob storage エリアで Add policy を選択
- 保存する
BLOB アップロードの管理
- コンテナー画面に戻り、作成したデータコンテナーを選択して [Upload] をクリック
- Upload blob ブレードで Advanced セクションを展開
- [Upload] をクリック
- 新しいフォルダーが作成され、ファイルがアップロードされたことを確認
- アップロードしたファイルを選択し、[…] メニューのオプション（Download、Delete、Change tier、Acquire lease）を確認
- ファイルの URL をコピー（Settings → Properties ブレード）し、新しい InPrivate ブラウザ ウィンドウに貼り付け
- XML 形式のメッセージで ResourceNotFound または PublicAccessNotPermitted が表示されることを確認
コンテナーの公開アクセスレベルが Private に設定されているため、匿名アクセスはできない。そのため、ResourceNotFound または PublicAccessNotPermitted と表示されるのは正常。
Blob Storage への限定アクセスを構成
- アップロードしたファイルに戻り、右端の …（省略記号） を選択
- Generate SAS を選択し、設定を指定（その他はデフォルトのまま）
- Generate SAS token and URL をクリック
- Blob SAS URL をクリップボードにコピー
- 新しい InPrivate ブラウザ ウィンドウを開き、コピーした Blob SAS URL にアクセス
タスク3: Azure File ストレージの作成と構成
ファイル共有を作成し、作成したファイル共有にファイルをアップロードする
- Azure portal でストレージ アカウントに戻り、Data storage ブレードで File shares をクリック
- + File share をクリック
- Basics タブでファイル共有に名前を付ける（例: share1）
- Access tier オプションを確認。デフォルトの Transaction optimized のまま
- Backup タブに移動し、Enable backup がチェックされていないことを確認（ラボ構成を簡略化するため）
- Review + create をクリックし、Create を選択。ファイル共有のデプロイが完了するまで待機
Storage Browser を開き、ファイルをアップロードする
- ストレージ アカウントに戻り、Storage Browser を選択。Azure Storage Browser は、アカウント内のすべてのストレージ サービスをすばやく確認できるポータル ツール
- File shares を選択し、share1 ディレクトリが存在することを確認
- share1 ディレクトリを選択し、+ Add directory を確認。フォルダー構造を作成可能
- Upload を選択。任意のファイルを参照し、Upload をクリック
ストレージアカウントへのネットワークアクセスを制限する
- ポータルで Virtual networks を検索して + Create を選択する
- リソースグループを選び、仮想ネットワーク名を
vnet1と入力する - 他のパラメータは既定のまま Review + create を選んで Create をクリックする
- デプロイ完了後、Go to resource を選択する
-
Settings セクションで Service endpoints ブレードを選択する
- Add を選択する
- Services ドロップダウンで Microsoft.Storage を選択する
- Subnets ドロップダウンで Default subnet をチェックする
- Add をクリックして変更を保存する
- ストレージアカウントに戻る
- Security + networking ブレードで Networking を選択する
- Public network access の下で Manage を選択する
- Add a virtual network を選び、Add existing network を選択する
-
vnet1と default subnet を選び、Add をクリックする - IPv4 Addresses セクションで自分のマシンの IP アドレスを削除する（許可されるトラフィックは仮想ネットワークのみ）
- Save をクリックして変更を保存する
- Storage browser を選んでページを更新する
- ファイル共有または blob コンテンツに移動する
