Azureストレージの暗号化(SSE)とお客様管理キー(CMK)を徹底解説！セキュリティ対策の基本

1. Azureストレージの暗号化SSEとは？

1. Azureストレージの暗号化SSEとは？

Azure Storage（アジュール・ストレージ）を利用する際、最も基本的なセキュリティ機能がSSE（Service-Side Encryption：サービス側暗号化）です。これは、クラウド上にデータを保存する瞬間に自動でデータを暗号化し、読み取る際に自動で復号（ふくごう：元に戻すこと）する仕組みです。

SSEの最大の特徴は、利用者が意識しなくても最初から有効になっている点です。追加料金もかからず、パフォーマンスへの影響もほとんどありません。例えるなら、マンションの共用玄関にオートロックが標準装備されているような状態です。データは「AES-256」という、銀行や軍事レベルでも使われる非常に強力な暗号化アルゴリズム（計算手順）で守られています。

しかし、標準の状態では「暗号化に使う鍵（キー）」をMicrosoft（マイクロソフト）が管理しています。これをPMK（Provider-Managed Key：プロバイダー管理キー）と呼びます。多くの場合、これだけで十分安全ですが、企業のコンプライアンス（法令遵守）や厳しいセキュリティ要件がある場合、鍵の管理を自分たちで行いたいというニーズが出てきます。そこで登場するのが「お客様管理キー（CMK）」です。

2. お客様管理キー(CMK)の仕組みとメリット

2. お客様管理キー(CMK)の仕組みとメリット

お客様管理キー（Customer-Managed Key：CMK）とは、暗号化に使用する鍵を、ユーザー自身が作成・管理できる仕組みのことです。これにより、データへのアクセス制御をより細かく、かつ強力に行うことが可能になります。

CMKを利用する場合、鍵はAzure Key Vault（アジュール・キー・ボルト）という、鍵管理専用の非常に安全なサービスに保存されます。鍵を自分で管理することの大きなメリットは、以下の3点です。

• 鍵の回転（ローテーション）: 定期的に鍵を新しく作り直すことができ、漏洩（ろうえい）のリスクを下げられます。
• アクセス制御: 誰がいつ鍵を使ったかというログを監視でき、不正利用を防げます。
• 即時無効化: 万が一の際、Key Vaultにある鍵を無効にすれば、たとえデータそのものが手元にあっても誰も中身を読めなくなります。

歴史的に見ると、かつてクラウドサービスは「中身がブラックボックスで不安」と言われることもありましたが、このようなCMKの仕組みが普及したことで、銀行や公的機関でも安心してクラウドを活用できるようになりました。まさに、自分で金庫の合鍵を持ち、いつでも鍵穴を交換できる権利を持っているようなイメージです。

3. C#でAzure Key Vaultの鍵を参照する準備

3. C#でAzure Key Vaultの鍵を参照する準備

お客様管理キーをプログラムから制御したり、設定を確認したりする場合、C#（シーシャープ）などの言語を使って自動化することが多いです。まずは、鍵を管理するKey Vaultにアクセスするための基本的なコードを見てみましょう。

以下のサンプルは、Azure SDKを使用して、特定のキーコンテナー（鍵の保管場所）に接続するための準備コードです。認証には「DefaultAzureCredential」という、開発環境でも本番環境でもスムーズに動く便利なクラスを使います。

using Azure.Identity;
using Azure.Security.KeyVault.Keys;
using System;

// Key VaultのURLを指定します
string vaultUri = "https://my-secure-vault.vault.azure.net/";

// 認証情報を作成（Azureにログインしている情報を使用）
var client = new KeyClient(new Uri(vaultUri), new DefaultAzureCredential());

try
{
    // 鍵の情報を取得してみる
    KeyVaultKey key = client.GetKey("my-encryption-key");
    Console.WriteLine($"鍵の名前: {key.Name}");
    Console.WriteLine($"鍵の種類: {key.KeyType}");
}
catch (Exception ex)
{
    Console.WriteLine($"エラーが発生しました: {ex.Message}");
}

鍵の名前: my-encryption-key
鍵の種類: RSA

このように、プログラムから鍵のメタ情報（属性）にアクセスできるようになります。暗号化そのものはAzureのシステムが行いますが、その「元となる鍵」を正しく指定できているかを確認することは、システム運用において非常に重要です。

4. 暗号化状態をAzure CLIで確認する

4. 暗号化状態をAzure CLIで確認する

Azureの操作はブラウザ（ポータル）だけでなく、コマンドライン（CLI）で行うのがプロの現場では一般的です。特に、大量のストレージアカウントの暗号化設定を一括で確認する際には、スクリプトが力を発揮します。

ここでは、特定のストレージアカウントが「Microsoft管理キー」を使っているのか、それとも「お客様管理キー（CMK）」を使っているのかを確認するコマンドを紹介します。

az storage account show --name mystorageaccount --resource-group myResourceGroup --query "encryption.keySource"
"Microsoft.Storage"

上記の実行結果で "Microsoft.Storage" と表示された場合は、標準の管理キーが使われていることを意味します。もしCMKが設定されていれば、ここに "Microsoft.Keyvault" と表示されます。このように、設定が正しく反映されているかをコマンド一つでチェックできるのは、インフラ管理の基本です。

5. SQL Database等と連携する際の暗号化の考え方

5. SQL Database等と連携する際の暗号化の考え方

Azure Storageだけでなく、Azure SQL Database（エスキューエル・データベース）などのサービスでも暗号化は重要です。ストレージに保存されたデータ（CSVファイルなど）をSQLにインポートする際、どちらのレイヤーでも暗号化が施されていることで「多層防御（たそうぼうぎょ）」が実現します。

データベース内のユーザー情報を管理する例を考えてみましょう。以下のようなデータがある場合、ストレージ上ではファイル全体が暗号化され、データベース上では「透過的データ暗号化（TDE）」という機能で守られます。

id | name         | age | email
---+--------------+-----+-------------------
1  | 佐藤健一     | 32  | kenichi@test.jp
2  | 鈴木美咲     | 24  | misaki@test.jp
3  | 高橋浩司     | 45  | koji@test.jp
4  | 田中愛子     | 29  | aiko@test.jp

SQLで特定の条件のデータを抽出する際も、裏側で常に復号と暗号化が繰り返されていますが、ユーザーはそれを意識する必要はありません。

-- 30歳以上のユーザーを取得するシンプルなクエリ
SELECT id, name, email
FROM users
WHERE age >= 30;

id | name         | email
---+--------------+-------------------
1  | 佐藤健一     | kenichi@test.jp
3  | 高橋浩司     | koji@test.jp

データがどこにあっても（静止データ）、移動していても（転送中のデータ）、常に暗号化されている状態を保つことが、現代のITシステムには不可欠です。

6. C#で暗号化設定を更新する高度な操作

6. C#で暗号化設定を更新する高度な操作

次に、既存のストレージアカウントに対して、お客様管理キーを使用するように設定を変更するイメージをコードで見てみましょう。これは、セキュリティポリシーが変更され、既存のバケットやコンテナの保護レベルを上げたい場合に役立ちます。

※以下のコードは概念を理解するための簡略化されたものです。実際にはAzure管理用のライブラリ（Azure.ResourceManager.Storage）を使用します。

using Azure.ResourceManager.Storage;
using Azure.ResourceManager.Storage.Models;

// ストレージアカウントの暗号化設定を定義
var encryption = new StorageAccountEncryption();
encryption.KeySource = Azure.ResourceManager.Storage.Models.StorageKeySource.MicrosoftKeyvault;
encryption.KeyVaultProperties = new StorageAccountKeyVaultProperties()
{
    KeyName = "my-encryption-key",
    KeyVaultUri = new Uri("https://my-secure-vault.vault.azure.net/"),
    KeyVersion = "" // 空にすると最新バージョンが自動的に使用されます
};

Console.WriteLine("ストレージアカウントの暗号化をCMKに切り替えます...");
// この後、UpdateAsyncメソッドなどで設定を適用します

プログラムで設定を行うことで、手作業によるミス（設定漏れ）を防ぐことができます。特に「KeyVersion」をあえて指定しないことで、Key Vault側で鍵を新しくした際に、自動でストレージ側も新しい鍵を使い始める「自動回転」の設定が可能になります。

7. Key VaultとManaged Identityの密接な関係

7. Key VaultとManaged Identityの密接な関係

お客様管理キー（CMK）を利用する上で、避けて通れないのがManaged Identity（マネージド・アイデンティティ）です。これは「ストレージアカウント自身に、Key Vaultへ鍵を取りに行く権限を与える」仕組みのことです。

従来は、サーバーにパスワードや秘密鍵のファイルを置いておく必要がありましたが、これではそのファイル自体が盗まれる危険がありました。Managed Identityを使えば、合言葉やパスワードをどこにも保存することなく、Azureのシステムが「このストレージアカウントは本人だ」と証明してくれます。これを「パスワードレス」と呼び、セキュリティの理想形とされています。

設定の流れとしては以下のようになります。

• ストレージアカウントで「マネージド恒久 ID」を有効にする。
• Key Vaultのアクセス制御（IAMまたはアクセス構成）で、そのIDに対して「鍵の取得・暗号化・復号」の許可を与える。
• ストレージアカウントの設定で、CMKとしての使用を有効化する。

この3つのステップを踏むことで、鉄壁の守りが完成します。一見複雑に見えますが、一度設定してしまえば、後はAzureがすべて自動で鍵の受け渡しを行ってくれます。

8. 二重暗号化でさらに高い安全性を目指す

8. 二重暗号化でさらに高い安全性を目指す

Azureには「インフラストラクチャ暗号化」と呼ばれる、さらに高度なオプションも存在します。これは、サービス層での暗号化（SSE）に加えて、物理的なディスク層でも別の鍵を使って暗号化を行う二重暗号化（Double Encryption）です。

万が一、一つの暗号化アルゴリズムに欠陥が見つかったとしても、もう一つの層がデータを守ってくれるという、まさに「二重の鍵」です。特に機密性の高い個人情報や、金融データを扱う場合には、この設定が推奨されます。ただし、この設定はストレージアカウントを作成する時にしか有効にできないため、設計段階で検討しておく必要があります。

このように、Azure Storageには初心者向けの「おまかせ設定」から、プロ向けの「こだわり設定」まで、幅広い選択肢が用意されています。まずは標準のSSEを理解し、必要に応じてCMKや二重暗号化へステップアップしていくのが良いでしょう。

まとめ

まとめ

これまでの内容を振り返ると、Azure Storageにおけるデータ保護の根幹は、強力な暗号化技術によって支えられていることがわかります。標準機能であるSSE（Service-Side Encryption）は、すべてのユーザーが意識することなく利用できる「安全の土台」です。この土台の上に、特定のビジネス要件や高度なセキュリティポリシーを満たすための選択肢として、CMK（Customer-Managed Key：お客様管理キー）や二重暗号化が存在しています。

特に重要なポイントは、鍵の管理主体を誰にするかという点です。利便性を優先するならMicrosoft管理キー（PMK）で十分ですが、コンプライアンス遵守や「鍵の回転（ローテーション）」、「アクセスの即時停止」といった制御権を手元に置きたい場合には、Azure Key Vaultを活用したCMKの導入が不可欠となります。また、これらを実現するためには、パスワードを必要としない認証の仕組みであるManaged Identityとの連携が、設定の鍵を握っています。

セキュリティをプログラムで制御する実践例

システムの運用フェーズでは、ポータル画面からの手動操作ではなく、C#を用いた自動化や、コマンドライン（CLI）による一括チェックが推奨されます。例えば、複数のストレージアカウントに対して、現在の暗号化設定が「Microsoft.Storage（標準）」なのか「Microsoft.Keyvault（お客様管理）」なのかを自動判定するロジックを組み込むことで、設定漏れによる事故を未然に防ぐことができます。

以下に、C#を使用してストレージアカウントのプロパティから暗号化設定を詳しく読み取り、画面に出力する実践的なサンプルコードを示します。このコードでは、暗号化のソースがどこにあるかを判定し、安全性を確認する流れを再現しています。

using System;
using Azure.Identity;
using Azure.ResourceManager;
using Azure.ResourceManager.Storage;

// Azureのリソース操作を行うためのクライアント初期化
ArmClient armClient = new ArmClient(new DefaultAzureCredential());

// 対象となるストレージアカウントのリソースIDを指定
string resourceId = "/subscriptions/your-sub-id/resourceGroups/myRG/providers/Microsoft.Storage/storageAccounts/mystorage";
ResourceIdentifier id = new ResourceIdentifier(resourceId);
StorageAccountResource storageAccount = armClient.GetStorageAccountResource(id);

// アカウントの詳細情報を取得
StorageAccountData data = storageAccount.GetData();

Console.WriteLine($"ストレージアカウント名: {data.Name}");
Console.WriteLine($"現在の暗号化ソース: {data.Encryption.KeySource}");

if (data.Encryption.KeySource == StorageKeySource.MicrosoftKeyvault)
{
    Console.WriteLine("<i class=\"bi bi-shield-check\"></i> お客様管理キー(CMK)で保護されています。");
    Console.WriteLine($"Key Vaultの場所: {data.Encryption.KeyVaultProperties.KeyVaultUri}");
}
else
{
    Console.WriteLine("<i class=\"bi bi-info-circle\"></i> 標準のMicrosoft管理キーを使用中です。");
}

ストレージアカウント名: mystorage
現在の暗号化ソース: Microsoft.Keyvault
<i class="bi bi-shield-check"></i> お客様管理キー(CMK)で保護されています。
Key Vaultの場所: https://my-secure-vault.vault.azure.net/

また、データベース層との連携においても、データの安全性を確認する習慣が大切です。SQL Database側でユーザー情報を管理する際、ストレージ側の暗号化と組み合わさることで、多層的な保護が完成します。以下は、セキュリティ監査の際によく使われる、ユーザーのステータスを確認するためのSQLクエリの例です。

id | user_name     | security_level | last_login
---+---------------+----------------+--------------------
1  | 管理者 A      | High           | 2026-03-01 10:00:00
2  | 運用担当 B    | Medium         | 2026-03-05 14:30:00
3  | 閲覧ユーザー C | Low            | 2026-03-10 09:15:00
4  | 監査役 D      | Critical       | 2026-03-15 11:45:00

-- セキュリティレベルがHigh以上のユーザーを抽出
SELECT user_name, security_level
FROM system_users
WHERE security_level IN ('High', 'Critical')
ORDER BY id ASC;

user_name     | security_level
--------------+----------------
管理者 A      | High
監査役 D      | Critical

データは単に保存するだけでなく、「誰が」「どのように」守っているかを明確にすることが、信頼されるシステム構築の第一歩です。Azureが提供する多様な暗号化オプションを正しく理解し、プロジェクトの規模や機密性に応じて最適な手法を選択していきましょう。