[アーティクル]
10/08/2015

年 9 月 2015

ボリューム 30 番号 9

Microsoft Azure - Azure Key Vault による機微な情報の保護

Rahul Nath | 年 9 月 2015

最近ビルドされる多くのアプリケーションは、データベースなどの外部システムへの接続文字列を始めとして、さまざまな形式で機微な情報を扱います。通常、このようにキーとなる情報は、アプリケーションの構成ファイルの一部として配置されます。しかし、この情報は、配置先のサーバーにアクセスできるユーザーなら、プレーンテキストとして入手できます。この状況が深刻なセキュリティの脅威になることは間違いありません。

Microsoft Azure Key Vault は、ハードウェアセキュリティモジュール (HSM) を基盤とするクラウドホスト型のサービスです。このサービスの目的は、集中管理する中央の場所から暗号化キーなどの機微な情報 (Key Vault 用語では「シークレット」) を管理することです。キーやシークレットに適切な URI を指定すれば、REST API からこのサービスにアクセスすることができます。Key Vault では、HSM を基盤とするキーではなく、ソフトウェアキーを作成することもできます。どちらのキーの場合も、キーのプライベート部分は Key Vault の境界から出ることはなく、確認することも共有することもできません。

今回は、大企業 Contoso 社が、開発をさまざまなベンダーに外部委託して、基幹業務 (LOB) アプリケーションをビルドするというシナリオを想定して説明を行います。このアプリケーションは、複数のサードパーティ製サービスにアクセスして、顧客の個人情報 (PII) など、機微な情報を扱います。ここでは、まず既存の実装を調べ、これが同社に及ぼすセキュリティの問題を確認してから、Azure Key Vault を使用してその問題を解決します。

既存のアプリケーション

Contoso 社は大手自動車メーカーで、現在は 1 つの LOB アプリケーションをビルドし、1 つのプラットフォームで顧客や関連業者に向けてインターネット接続型のコネクティッドカーエクスペリエンスを提供しています。同社には小規模 IT チームが 1 つしかないため、アプリケーションの開発をさまざまなベンダーに外部委託し、アプリケーションのそれぞれ異なる部分の作成を依頼しています。このアプリケーションはクラウドホスト型で、多様な API を公開して、さまざまなエンティティがこのアプリケーションを操作できるようにしています。また、外部サービスのデータを利用するためにサードパーティ製アプリケーション API も使用し、Web サービス経由で公開する Contoso の社内アプリケーションを呼び出します。

アプリケーションでは PII を扱います。この PII は機密性が高く、安全に保存しなければなりません。当初は、こうした機微な情報の扱い方をあまり深く議論せず、それぞれのベンダーが独自のアプローチを採用しました。ほとんどの接続文字列は、配置ごとに変更できるよう、アプリケーション構成ファイルに含めていました。PII 情報を暗号化するためのキーはアプリケーションにハードコードされ、同社の Web サービスと接続するための証明書の詳細情報の一部はアプリケーションのデータベースに保存していました。その結果、同社はこうした機微な情報を管理できなくなり、最終的にはアプリケーション開発ベンダーと共有することになりました。これは推奨されることではありません。同社は、これ以上に深刻な脅威として、配置先のサーバーにアクセスできれば、PII データを実に簡単に改ざんできることにも気付きました。同社は、機微な情報のメンテナンスとアクセスのアプローチを統一する必要に迫られています。

アプリケーションの改修

Contoso 社は、機微な情報を管理し、他のアプリケーションと一貫性を持たせてエクスペリエンスを統一するために、さまざまな案を検討しました。同社は、セキュリティチームが集中管理しやすいキーストアと、アプリケーションごとに異なる情報アクセスポリシーを提供する方法を求めていました。さらに、日常の監視に大きなメンテナンスオーバーヘッドを伴うことは避けたいとも考えていました。

同社は、Azure Key Vault を選択しました。Azure Key Vault では、ソフトウェアキーと HSM を基盤とするキーを使用でき、PEX ファイルから既存のキーをインポートできます。少量の情報 (シークレット) を安全にクラウドに格納でき、必要に応じてその情報にアクセスできます。このサービスは Azure プラットフォーム上で管理およびメンテナンスされるため、メンテナンスのオーバーヘッドは一切かかりません。

Key Vault は、他人からはキーを確認または抽出できない、非常にセキュアなプラットフォームとなるよう構築されています。また、保管場所へのアクセスや操作のためにリッチな API が用意され、Microsoft .NET Framework で動作するアプリケーション向けの C# API ライブラリも備えています。Contoso 社は、さまざまなアプリケーションベンダーがセキュアな情報を操作する方法を制限したいと考えていることから、さまざまなアプリケーションやベンダーの操作方法を制御できる Key Vault を適切な選択肢と考えました。さらに、同社のエンジニアはさまざまなサーバーの管理に Windows PowerShell スクリプトを多用しているため、Key Vault を Windows PowerShell から完全に管理できることも選択要因になりました。

Key Vault の作成: Contoso 社の IT チームのセキュリティ管理者は、Key Vault のセットアップと、キーやシークレットの管理を担当します。Azure Key Vault は、Windows PowerShell コマンドレットを使って作成および管理でき、最新版の Azure PowerShell (0.9.2 以降) を利用できます。Azure PowerShell プロンプトで Azure サブスクリプションに接続したら、Key Vault のコマンドレットの実行に必要な AzureResourceManager モードに切り替えます。次に、New-AzureKeyVault コマンドレットを使用して、保管場所の名前 (グローバルに一意)、リソースグループ、および場所を指定して新しい保管場所を作成します。

Switch-AzureMode AzureResourceManager
New-AzureResourceGroup –Name 'ContosoResourceGroup' –Location 'East Asia'
New-AzureKeyVault -VaultName 'ContosoKeyVault' -ResourceGroupName
  'ContosoResourceGroup' -Location 'East Asia'

コマンドが正しく実行されると、キーの保管場所の名前や、保管場所を一意に識別可能な URI など、新しく作成した Key Vault の詳細情報が、Azure PowerShell コンソールに出力されます。

Key Vault のセットアップ: Azure Key Vault は、暗号化キーの作成や保存だけではなく、シークレットの保存も可能にします。シークレットとは、特定のセマンティクスを持たない、サイズ制限があるオクテットオブジェクトです。

保管場所内の暗号化キーは、JSON Web Key オブジェクトとして表されますが、現状では RSA キーのみをサポートします。保管場所内にキーを作成したら、そのキーのパブリック部分のみが保管場所の境界外で利用可能になります。

キーの保管場所には、キーとシークレットの両方を保持でき、その 2 つに対する外部からのアクセスは個別に制御できます。キーとシークレットはどちらもバージョン管理が行われるオブジェクトで、新しく作成されたものは、保管場所の URL、オブジェクト名、バージョン番号によって一意に識別されます。同じ名前でオブジェクトを作成すると、毎回その名前の新しいオブジェクトが作成され、新しいバージョン番号が付与され、最新バージョンになります。バージョン番号を指定しないでオブジェクトにアクセスすると、最新バージョンが返されます。保管場所内のオブジェクトを一意に識別するオブジェクト ID のフォーマットは以下のとおりです。この ID は、API を使ってキーやシークレットにアクセスするときに使用します。

https://{keyvault-name}.vault.azure.net/{object-type}/{object-name}/{object-version}

このフォーマットの各要素の意味は以下のとおりです。

keyvault-name           : Globally unique key vault name
object-type               : Either "keys" or "secrets," indicating the type of object
object-name              : Unique name within a key vault
object-version           : System generated string, optionally used to          
                              identify a specific version of object

Azure Key Vault のキーは、JSON Web Key (JWK) オブジェクトとして表されますが、キーの型が Azure Key Vault 実装に対して一意になるように、JWK の基本仕様が拡張されています。現状、Azure Key Vault は、RSA アルゴリズム (非対称アルゴリズム) のみをサポートします。Azure Key Vault は、キーに対する操作として、作成、インポート、更新、削除、一覧、取得、バックアップ、およびリストアをサポートしており、REST API と Windows PowerShell コマンドレットを使用して実行できます。Contoso 社のアプリケーションは特定の PII 情報の暗号化と暗号化解除にキーを使用するため、キーを保管場所に作成する必要があります。同社のエンジニアは、以下のスクリプトを使用して、同社の保管場所内で一意名を持つ新しいキーを Azure Key Vault に追加します。

Add-AzureKeyVaultKey -VaultName 'ContosoKeyVault' -Name 'ContosoPIIKey'
  -Destination 'Software'

このスクリプトが正しく実行されると、ContosoKeyVault 内に新しいソフトウェア RSA キーが作成されます。このキーは、一意 ID (https://ContosoKeyVault.vault.azure.net/keys/ContosoPIIKey/ bfacf5f768ae42ffb0a0bca448aead87 など) で識別できます。エンジニアは、この一意 ID をアプリケーションベンダーと共有します。

Azure Key Vault のシークレットは、最大長がそれぞれ 25K のオクテットシーケンスで、あらゆる型のデータを受け入れ、安全に保管します。Key Vault はシークレットに対する操作として、作成、取得、一覧、削除、および更新をサポートしており、REST API と Windows PowerShell コマンドレットを使用して実行できます。Contoso 社のアプリケーションはアプリケーション構成ファイル内に接続文字列を保存しているため、同社のエンジニアは、この文字列を Key Vault に移動することに決めました。Key Vault ではこのような文字列が安全に保管されますが、依然として一意 ID を使用すればアクセスできます。以下のスクリプトは、SQL データベース接続文字列を保管場所に追加します。

$ContosoSQLConnectionString = ConvertTo-SecureString -String
  "ContosoSQLConnectionString"
  -AsPlainText -Force
Set-AzureKeyVaultSecret -VaultName "ContosoKeyVault" -Name
  "ContosoSQLConnectionString"
  -SecretValue $ContosoSQLConnectionString

このスクリプトが正しく実行されると、ContosoKeyVault 内にシークレット値が作成されます。このシークレット値は、一意 ID (https://ContosoKeyVault.vault.azure.net/secrets/ContosoSQLConnectionString/90018dbb96a84117a0d2847ef8e7189d など) で識別できます。エンジニアは、この一意 ID をアプリケーションベンダーと共有します。

Key Vault を使用するためのアプリケーションの認証: この時点では、新しく作成した保管場所には、それを作成した Azure アカウントからしかアクセスできません。他のアカウントからはアクセスできません。Contoso 社では、さまざまなクライアントアプリケーションからその保管場所にアクセスすることを考えています。Azure Key Vault へのアクセスは、Azure Active Directory (Azure AD) アプリケーショントークンを使用して安全性を確保します。そのため、同社のエンジニアは、最初に Azure AD 内にアプリケーションを作成し、認証キー (共有シークレット) または証明書のいずれかでセキュリティを確保する必要があります。認証キーによるアクセスを使用してセキュリティが確保される Azure AD アプリケーションは、Azure の管理ポータルの [Active Directory] オプションの [アプリケーション] タブで作成できます。しかし、このようにすると機微な情報を再びクライアントアプリケーション構成ファイルに保管すること (最も避けたいこと) になるため、認証キーによる Key Vault の保護は Contoso 社の要望には沿いません。また、Key Vault をすべての機微な情報を保管するただ 1 つの場所とするため、資格情報へのアクセスを許可することも同様に避けなければなりません。そこで、Contoso 社は証明書ベースの認証を利用することに決めました。これにより、証明書を必要とするアプリケーションに証明書を直接配置し、さらにパスワードによってその証明書を保護します。

証明書認証を使用する Azure AD アプリケーションは、Windows PowerShell コマンドラインを使って作成できます。Contoso 社は、複数の社内アプリケーションを保護するための証明書を生成するメカニズムを既に所持しているため、同じサービスを利用して Azure AD アプリケーション用の証明書を生成できます。証明書を用意したら、以下のスクリプトを使って、Azure AD アプリケーションを作成できます。

$certificateFilePath = "C:\certificates\ContosoADApplication.cer"
$x509Certificate2 = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2
$x509Certificate2.Import($certificateFilePath)
$rawCertData = $x509Certificate2.GetRawCertData()
$credentialValue = [System.Convert]::ToBase64String($rawCertData)
$startDate= [System.DateTime]::Now
$endDate = $startDate.AddYears(1)
$newADApplication = New-AzureADApplication -DisplayName
  "ContosoKeyVaultADApplication"
  -HomePage  "https://www.contoso.com" -IdentifierUris "https://www.contoso.com" 
  -KeyValue  $credentialValue -KeyType "AsymmetricX509Cert" -KeyUsage "Verify"
  -StartDate $startDate -EndDate $endDate

Key Vault と Azure AD アプリケーションの作成後は、この 2 つを相互にリンクする必要があります。そこで、Azure AD アプリケーションから取得したアプリケーショントークンを使用して、Key Vault に対して認証を行います。これは、AzureKeyVaultAccessPolicy コマンドレットを使用して行います。このとき、PermissionToKeys パラメーターと PermissionToSecrets パラメーターを使用して、Key Vault での Azure AD アプリケーションのアクセス許可も設定します。

PermissionToKeys パラメーターには、アプリケーションに許可するキー操作権限の配列を指定します。この配列には、受け入れ可能な値 (Decrypt、Encrypt、UnwrapKey、WrapKey、Verify、Sign、Get、List、Update、Create、Import、Delete、Backup、Restore、All) のリストを渡します。PermissionToSecrets パラメーターには、アプリケーションに許可するシークレット操作権限の配列を指定します。この配列には、受け入れ可能な値 (Get、List、Set、Delete、All) のリストを渡します。これらの権限は、保管場所内にあるすべてのキーとシークレットに適用されます。特定のキーやシークレットを選択して権限を与えることできません。キーまたはシークレットを選択して権限を与える必要がある場合は、選択したキーやシークレットの権限を管理するため、別の保管場所を作成する必要があります。Key Vault 自体のセットアップ自体に費用はかかりませんが、これは変更される可能性があるため、別の保管場所を作成する前に、Key Vault の価格がどのように設定されているかをチェックしてください。同じキーやシークレットに異なるアクセスレベルを与えるには、複数の Azure AD アプリケーションを作成し、それらに別の権限レベルを与えます。

Contoso 社のエンジニアは、Azure AD アプリケーションと Key Vault を関連付け、保管場所でのアプリケーションの権限を指定するため、以下のスクリプトを使用します。

$ServicePrincipal = New-AzureADServicePrincipal -ApplicationId $newADApplication.ApplicationId
Set-AzureKeyVaultAccessPolicy -VaultName 'ContosoKeyVaultRahul' -ObjectId  $ServicePrincipal.Id
  -PermissionsToKeys encrypt,decrypt,get -PermissionsToSecrets get
$ServicePrincipal.ApplicationId

クライアントアプリケーションから Key Vault への接続: Azure AD アプリケーションを作成し、Key Vault と関連付けたら、クライアントアプリケーションから Azure AD アプリケーションを使用して、Key Vault に対する認証を受けます。Contoso 社のアプリケーションは .NET プラットフォームで開発されているため、アプリケーションベンダーは Microsoft.Azure.KeyVault NuGet パッケージ (bit.ly/1Ji6xcS、英語) を使用して Key Vault に接続します。

Azure AD アプリケーションによるクライアントアプリケーションの認証は、NuGet パッケージとしても利用可能な Azure AD 認証ライブラリ (ADAL) を使用すれば簡単に実現できます。Azure AD アプリケーションによる認証のためにクライアントアプリケーションに必要なのは、構成ファイル内に配置可能なクライアント ID と証明書 ID (拇印など) だけです。この 2 つは機微な情報ではないため、構成ファイルに配置しても安全です。

C# SDK が提供する KeyVaultClient クラスを図 1 に示します。このクラスのコンストラクターは、Azure AD アプリケーションから有効なトークンを提供するため、コールバックメソッドを受け取ります。このコールバックメソッドは、クライアントを使用して暗号化操作を実行するたびに毎回呼び出されます。アプリケーションの構成ファイルの拇印の情報を使用するカスタム関数 GetCertificateByThumbprint により、有効な証明書が取得され、Azure AD アプリケーションに対する認証に使われます。ADAL ライブラリが Azure AD アプリケーションから最初に受信したトークンをキャッシュし、トークンが失効するまで、それ以降のすべての呼び出しにキャッシュからのトークンを提供します。

図 1 Key Vault への接続

var keyVaultClient = new KeyVaultClient(async (authority, resource, scope) =>
{               
  string azureAdApplicationId =
     ConfigurationManager.AppSettings["AzureAdApplicationId"];
  string certificateThumbprint =
    ConfigurationManager.AppSettings["CertificateThumbprint"];
  X509Certificate2 certificate =
    GetCertificateByThumbprint(certificateThumbprint);
  var clientAssertionCertificate =
    new ClientAssertionCertificate(azureAdApplicationId, certificate);
  var authenticationContext = new AuthenticationContext(authority);
  var result =
    await authenticationContext.AcquireTokenAsync(resource,  
    clientAssertionCertificate);
  return result.AccessToken;
});

キーとシークレットを使用するクライアントアプリケーションの構成: ここでクライアントアプリケーションのベンダーは、必要な接続文字列とキー情報を保管場所から取得するために、Contoso 社のエンジニアと共有するキーとシークレットの ID を使用するように既存のアプリケーションを更新する必要があります。キーの ID 自体は機微な情報ではないので、アプリケーションの構成ファイルに配置しても安全です。

Key Vault にシークレットとして保存されている接続文字列などの機微な情報が必要な場合は、以下のように KeyVaultClient を使用して保管場所から読み取るように、既存のコードを置き換えます。

var connectionStringIdentifier =
  ConfigurationManager.AppSettings["ConnectionStringIdentifier"];
var contosoSQLConnectionString =
  await keyVaultClient.GetSecretAsync(connectionStringIdentifier);

上記のコードでは、まず構成ファイル内に格納されていた接続文字列のシークレット ID を検索し、見つかった ID と SDK クライアントを使用して、シークレット値 (今回は接続文字列) を取得しています。その後は必要に応じて、この接続文字列を使ってアプリケーションデータベースに接続します。

アプリケーションで PII 情報を暗号化または暗号化解除する必要がある場合は、SDK クライアントを使用し、使用するキー ID を指定するように、既存のコードを置き換えます。以下のコードは、なんらかのテキストを暗号化した後、その暗号化解除して元のテキストに戻す方法を示しています。

// Within the actual application, encryption and decryption
// would happen at different parts.
var contosoPIIKeyIdentifier =
  ConfigurationManager.AppSettings["ContosoPIIKeyIdentifier"];
Byte[] textToEncrypt = Encoding.Unicode.GetBytes("Consumer PII Information");
var encryptedResult =
  await keyVaultClient.EncryptAsync(contosoPIIKeyIdentifier, "RSA_OAEP",  textToEncrypt);
var decryptedResult =
  await keyVaultClient.DecryptAsync(contosoPIIKeyIdentifier,
  "RSA_OAEP", encryptedResult.Result);
var text = Encoding.Unicode.GetString(decryptedResult.Result);

Key Vault のメンテナンス: Contoso 社のエンジニアは、キー ID に関連付けられるキー値の変更、シークレット ID に関連付けられるシークレット値の更新、新しいキーとシークレット値の作成、Azure AD アプリケーションの認証に使用する証明書の更新など、Key Vault を有効期限までメンテナンスします。

保管場所内でキーやシークレットを作成または更新する場合は、前述のようなスクリプトを使用します。キーまたはシークレット用に指定したオブジェクト ID が保管場所に存在しなければ、必ず新しいオブジェクトが作成されます。保管場所で、既存の ID の新しいバージョンが自動的に作成され、そのバージョンが最新版になります。古い値も保管場所に保持され、URI の識別子名とバージョン番号を参照することで、その値を使用できます。クライアントアプリケーションは、アプリケーション要件に基づいて、ID のバージョン番号を含めるかどうかを決定できます。アプリケーションのバージョンが異なる場合、異なる保管場所、同じ保管場所にあり名前が異なる ID、ID となる URI で明示的に指定されたバージョン番号を持つ同じ名前の ID のいずれかを選択できます。Contoso 社のセキュリティポリシーでは、エンジニアが以下のワークフローに従うため、キー、接続文字列のようなシークレット値、および証明書を頻繁に (定期的に) 変更することを求めています。

保管場所に格納されたキーが新しいバージョンに更新されるとき、保存しているデータをそのキーで暗号化したクライアントアプリケーションは、新しいキーを使用するように暗号化済みのデータを移行する必要がある。
Contoso 社のクライアントアプリケーションは、データの暗号化に使用したキーのバージョンを管理し、同じデータの暗号化を解除する際は常にそのキーを使用する。
データの暗号化を解除する際、アプリケーションは常に新しいキーの情報を使用する。これにより、キーの値が作成されたとき、アプリケーションを新しいキー値へ確実に移行できる。

シークレット値を更新するプロセスは、シークレットが表す値の種類によって異なります。値が接続文字列のような情報の場合は、まずシークレット値をスタンバイサービスに切り替えてから、プライマリサービスの証明書情報を抜き出し、プライマリサービス用に更新した証明書を使ってシークレットを更新します。Azure Storage などの特定のサービスについては、主キーや 2 次キーのどちらかを更新する際に残りのキーを利用できるため、プロセスはより単純になります。値がアプリケーションのみに関連しているシークレットの場合は、そのシークレットを直接更新して、すべて新しい値を反映するようにします。

Azure AD アプリケーションの保護に使用する証明書を変更する必要があるときは、Contoso 社のエンジニアが Windows PowerShell スクリプトを使用して更新します。Azure AD アプリケーション用の証明書を更新するには、Azure AD モジュールをインストールする必要があります。このモジュールは、https://msdn.microsoft.com/ja-jp/library/azure/jj151815.aspx#bkmk_installmodule に記載されています。Contoso社のエンジニアは、図 2 のスクリプトを使用して、Azure AD アプリケーションを保護するための新しい証明書をアップロードします。

図 2 新しい証明書をアップロードするための Azure PowerShell スクリプト

$certificateFilePath = "C:\certificates\ContosoADApplicationNew.cer"
$x509Certificate2 =
  New-Object System.Security.Cryptography.X509Certificates.X509Certificate2
$x509Certificate2.Import($certificateFilePath)
$rawCertData = $x509Certificate2.GetRawCertData()
$credentialValue = [System.Convert]::ToBase64String($rawCertData)
$startDate= [System.DateTime]::Now
$endDate = $startDate.AddYears(1)
$msolCredentials = get-credential
connect-msolservice -credential $msolCredentials
New-MsolServicePrincipalCredential -ServicePrincipalName $ServicePrincipal.ApplicationId
  -Type Asymmetric -Value $credentialValue -StartDate $startDate -EndDate $endDate

どのアプリケーションも証明書の資格情報をまったく使わなくなったら、Constoso 社のエンジニアは Get-MsolServicePrincipalCredential コマンドレットを使用して、削除する資格情報の ID を取得後、以下のスクリプトを実行してサービスプリンシパルから資格情報キーを削除します。

$servicePrincipalCredential = Get-MsolServicePrincipalCredential
  -ServicePrincipalName $ServicePrincipal.ApplicationId -ReturnKeyValues 0
Remove-MsolServicePrincipalCredential
  -ServicePrincipalName $ServicePrincipal.ApplicationId
  -KeyIds $servicePrincipalCredential[0].KeyId

上記のスクリプトは、コマンドレットの使用法を簡単に示すため、リストの先頭にある資格情報を単純に削除しています。実際のアプリケーションでは、削除する証明書の資格情報の ID を明示的に指定することになります。

複数の配置の処理: アプリケーションが現時点で利用しているのは、Azure AD アプリケーションの ID、Azure AD アプリケーションを認証する証明書を識別する拇印による証明、およびキーとシークレットのさまざまな ID だけです。アプリケーションを別途配置する場合は、キーの異なる保管場所を使用することができます。開発用に配置する場合、各アプリケーションベンダーはそれぞれ自社の Azure サブスクリプションを使用して、ここまで説明した手順に従ってキーの保管場所を作成し、この保管場所をセットアップして、アプリケーションが想定するキーとシークレットをその保管場所に格納した後、構成ファイルを更新します。Contoso チームがテスト目的でアプリケーションを配置する必要がある場合、チームは、自社のサブスクリプションで配置した保管場所から得た詳細情報を使って構成ファイルを更新します。

まとめ

Contoso 社は、Azure Key Vault に切り替えたことで、同社のアプリケーションに深刻な影響を与えていたセキュリティリスクのほとんどを簡単に解消できるようになり満足しています。アプリケーションのコードをほんのわずかに変更するだけで、予定していた作業のすべてを遂行できるようになり、それによりさまざまな種類の機微な情報を簡単に管理できるようになりました。同社は Azure Key Vault への切り替えによって負担が軽減されたことにより、他のLOB アプリケーションを再検討し、そのセキュリティを向上させることにも前向きになっています。Azure Key Vault は、ほとんどのアプリケーションにとって今すぐにも利用でき、暗号化キーを含む機微な情報を簡単かつ安全に格納し管理できるサービスです。

Rahul Nathは、Windows のリッチクライアントアプリケーションから、Azure プラットフォーム上の大規模アプリケーションまで、幅広い経験を持つ開発者、コンサルタント、兼ブログ執筆者です。Twitter (twitter.com/rahulpnath、英語) で彼をフォローしたり、rahulpnath.com (英語) で公開されている彼のブログを読んだりすることができます。

この記事のレビューに協力してくれたマイクロソフト技術スタッフの Amit Bapat に心より感謝いたします。
Amit Bapat は、現在 Microsoft Azure Key Vault のプログラムマネージャーを務めています。Amit はマイクロソフトに入社する前、Intel で Intel Xeon プロセッサのプロダクトマーケティングを含むさまざまな職務、多くのソフトウェアプロジェクトの技術担当、および Intel CPU の設計における CAD エンジニアを務めていました。

Microsoft Azure - Azure Key Vault による機微な情報の保護

既存のアプリケーション

アプリケーションの改修

まとめ

その他のリソース