製品/サービス |
[アーティクル] |
コンピューターの信頼の境界 |
|
Web アプリケーション |
|
[データベース] |
|
Web API |
|
Azure Document DB |
|
Azure IaaS VM の信頼の境界 |
|
Service Fabric の信頼の境界 |
|
Dynamics CRM |
|
Azure ストレージ |
|
モバイル クライアント |
|
WCF |
|
機密情報を含むバイナリを難読化する
タイトル |
詳細 |
コンポーネント |
コンピューターの信頼の境界 |
SDL フェーズ |
デプロイ |
適用できるテクノロジ |
ジェネリック |
属性 |
該当なし |
参照 |
該当なし |
手順 |
取引上の秘密や、リバース エンジニアリングされてはならない機密のビジネス ロジックなどの機密情報が含まれているバイナリを、難読化します。 これは、アセンブリのリバース エンジニアリングを停止するためです。 この目的には、CryptoObfuscator などのツールを使うことができます。 |
ユーザー固有の機密データを保護するために暗号化されたファイル システム (EFS) を使うことを検討する
タイトル |
詳細 |
コンポーネント |
コンピューターの信頼の境界 |
SDL フェーズ |
Build |
適用できるテクノロジ |
ジェネリック |
属性 |
該当なし |
参照 |
該当なし |
手順 |
コンピューターに物理的にアクセスする敵対者からユーザー固有の機密データを保護するために、暗号化されたファイル システム (EFS) を使うことを検討します。 |
アプリケーションによってファイル システムに保存される機密データを暗号化する
タイトル |
詳細 |
コンポーネント |
コンピューターの信頼の境界 |
SDL フェーズ |
デプロイ |
適用できるテクノロジ |
ジェネリック |
属性 |
該当なし |
参照 |
該当なし |
手順 |
EFS を強制できない場合は、アプリケーションによってファイル システムに保存される機密データを暗号化します (DPAPI などを使用)。 |
機密コンテンツがブラウザーにキャッシュされないようにする
タイトル |
詳細 |
コンポーネント |
Web アプリケーション |
SDL フェーズ |
Build |
適用できるテクノロジ |
ジェネリック、Web フォーム、MVC5、MVC6 |
属性 |
該当なし |
参照 |
該当なし |
手順 |
ブラウザーは、キャッシュと履歴のために情報を保存できます。 これらのキャッシュされたファイルはフォルダーに保存されます (Internet Explorer の場合は Temporary Internet Files フォルダー)。 これらのページが再び参照されると、ブラウザーはキャッシュからページを表示します。 機密情報 (住所、クレジット カードの詳細、社会保障番号、ユーザー名など) がユーザーに表示された場合、この情報がブラウザーのキャッシュに保存されるので、ブラウザーのキャッシュを調べることで、または単にブラウザーの [戻る] ボタンをクリックすることで、情報を取得できる可能性があります。 すべてのページについて、cache-control 応答ヘッダーの値を "no-store" に設定します。 |
例
<configuration>
<system.webServer>
<httpProtocol>
<customHeaders>
<add name="Cache-Control" value="no-store" />
<add name="Pragma" value="no-cache" />
<add name="Expires" value="-1" />
</customHeaders>
</httpProtocol>
</system.webServer>
</configuration>
例
これは、フィルターによって実装できます。 次の例を使うことができる場合があります。
public override void OnActionExecuting(ActionExecutingContext filterContext)
{
if (filterContext == null || (filterContext.HttpContext != null && filterContext.HttpContext.Response != null && filterContext.HttpContext.Response.IsRequestBeingRedirected))
{
//// Since this is MVC pipeline, this should never be null.
return;
}
var attributes = filterContext.ActionDescriptor.GetCustomAttributes(typeof(System.Web.Mvc.OutputCacheAttribute), false);
if (attributes == null || **Attributes**.Count() == 0)
{
filterContext.HttpContext.Response.Cache.SetNoStore();
filterContext.HttpContext.Response.Cache.SetCacheability(HttpCacheability.NoCache);
filterContext.HttpContext.Response.Cache.SetExpires(DateTime.UtcNow.AddHours(-1));
if (!filterContext.IsChildAction)
{
filterContext.HttpContext.Response.AppendHeader("Pragma", "no-cache");
}
}
base.OnActionExecuting(filterContext);
}
Web アプリの構成ファイルの機密データを含むセクションを暗号化する
タイトル |
詳細 |
コンポーネント |
Web アプリケーション |
SDL フェーズ |
Build |
適用できるテクノロジ |
ジェネリック |
属性 |
該当なし |
参照 |
MSDN: autocomplete 属性、HTML での AutoComplete の使用、HTML サニタイズの脆弱性、オートコンプリートをまた有効にするのですか |
手順 |
autocomplete 属性は、フォームがオートコンプリートをオンまたはオフにするかどうかを指定します。 オートコンプリートがオンのとき、ブラウザーは前にユーザーが入力した値に基づいて値を自動的に完成させます。 たとえば、新しい名前とパスワードがフォームに入力されて、フォームが送信されるとき、ブラウザーはパスワードを保存する必要があるかどうかを尋ねます。その後、フォームが表示されるとき、名前とパスワードは自動的に入力されるか、または名前が入力されると完成されます。 ローカルにアクセスできる攻撃者は、ブラウザーのキャッシュからクリア テキストのパスワードを入手する可能性があります。 既定ではオートコンプリートは有効なので、明示的に無効にする必要があります。 |
例
<form action="Login.aspx" method="post " autocomplete="off" >
Social Security Number: <input type="text" name="ssn" />
<input type="submit" value="Submit" />
</form>
ユーザーの画面に表示される機密データをマスクする
タイトル |
詳細 |
コンポーネント |
Web アプリケーション |
SDL フェーズ |
Build |
適用できるテクノロジ |
ジェネリック |
属性 |
該当なし |
参照 |
該当なし |
手順 |
パスワード、クレジット カード番号、SSN などの機密データは、画面に表示するときにマスクする必要があります。 これは、承認されていない人物がデータにアクセスするのを防ぐためです (たとえば、サポート担当者が表示しているユーザーの SSN 番号を肩越しに見る、など)。 これらのデータ要素がプレーン テキストで表示されず、適切にマスクされるようにします。 この処理は、入力 (例: 入力の種類 = "パスワード") として受け入れる際や、画面に戻る際 (例: クレジットカード番号の最後の4桁のみが表示する) に行う必要があります。 |
動的データ マスクを実装して、権限を持たないユーザーへの機密データの露出を制限する
タイトル |
詳細 |
コンポーネント |
データベース |
SDL フェーズ |
Build |
適用できるテクノロジ |
SQL Azure、OnPrem |
属性 |
SQL バージョン - V12、SQL バージョン - MsSQL2016 |
参照 |
動的なデータ マスキング |
手順 |
動的データ マスクの目的は、アクセスすべきではないユーザーがデータを閲覧することを防ぎ、デリケートなデータの公開を制限することにあります。 動的データ マスクは、ユーザーが直接データベースに接続し、徹底的なクエリを実行して、デリケートなデータの漏えいを防ぐことを目的としてはいません。 動的データ マスクは SQL Server の他のセキュリティ機能 (監査、暗号化、行レベルのセキュリティなど) を補完するものであり、この機能をそれらと併用して、データベースの機密データの保護を強化することを強くお勧めします。 この機能は SQL Server 2016 以降と Azure SQL Database によってのみサポートされることに注意してください。 |
パスワードを salt ハッシュ形式で保存する
タイトル |
詳細 |
コンポーネント |
データベース |
SDL フェーズ |
Build |
適用できるテクノロジ |
ジェネリック |
属性 |
該当なし |
参照 |
.NET Crypto API を使ったパスワードのハッシュ |
手順 |
カスタム ユーザー ストア データベースにパスワードを保存してはなりません。 パスワード ハッシュは、代わりに salt 値を使って保存する必要があります。 ユーザーの salt が常に一意であることを確認し、パスワードを保存する前に 150,000 以上の作業因子反復回数で b-crypt、s-crypt、または PBKDF2 を適用して、ブルート フォース攻撃を受けないようにします。 |
データベースの列の機密データを暗号化する
データベース レベルの暗号化 (TDE) を有効にする
タイトル |
詳細 |
コンポーネント |
データベース |
SDL フェーズ |
Build |
適用できるテクノロジ |
ジェネリック |
属性 |
該当なし |
参照 |
SQL Server の透過的なデータ暗号化 (TDE) について |
手順 |
SQL Server の Transparent Data Encryption (TDE) 機能は、データベースの機密データを暗号化し、証明書でデータを暗号化するために使われるキーを保護するのに役立ちます。 これにより、キーを持たないユーザーはデータを使うことができません。 TDE では、"静止した" データ、つまりデータとログ ファイルが保護されます。 この暗号化は、法律、規制、およびさまざまな業界で確立されているガイドラインの多くに準拠できるようになっています。 |
データベースのバックアップを暗号化する
タイトル |
詳細 |
コンポーネント |
データベース |
SDL フェーズ |
Build |
適用できるテクノロジ |
SQL Azure、OnPrem |
属性 |
SQL バージョン - V12、SQL バージョン - MsSQL2014 |
参照 |
SQL データベース バックアップの暗号化 |
手順 |
SQL Server には、バックアップの作成中にデータを暗号化する機能があります。 バックアップを作成するときに暗号化アルゴリズムと暗号化機能 (証明書または非対称キー) を指定することで、暗号化されたバックアップ ファイルを作成できます。 |
Web API に関連する機密データがブラウザーの記憶域に保存されないようにする
タイトル |
詳細 |
コンポーネント |
Web API |
SDL フェーズ |
Build |
適用できるテクノロジ |
MVC 5、MVC 6 |
属性 |
ID プロバイダー - ADFS、ID プロバイダー - Microsoft Entra ID |
参照 |
該当なし |
手順 |
一部の実装では、Web API の認証に関連する機密性の高いアーティファクトがブラウザーのローカル記憶域に格納されます。 たとえば、adal.idtoken、adal.nonce.idtoken、adal.access.token.key、adal.token.keys、adal.state.login、adal.session.state、adal.expiration.key などの Microsoft Entra 認証成果物です。 これらのアーティファクトはすべて、サインアウトした後またはブラウザーを終了した後でも使用可能です。 敵対者がこれらのアーティファクトにアクセスできた場合、それを再利用して保護されたリソース (API) にアクセスできます。 Web API に関連するすべての機密アーティファクトが、ブラウザーの記憶域に保存されないようにします。 クライアント側に記憶することが避けられない場合は (たとえば、Implicit OpenIdConnect/OAuth フローを利用するシングル ページ アプリケーション (SPA) は、アクセス トークンをローカルに保存する必要があります)、永続性のない記憶域の選択肢を使います。 たとえば、LocalStorage ではなく SessionStorage を選びます。 |
例
次の JavaScript のスニペットは、ローカル記憶域に認証アーティファクトを保存するカスタム認証ライブラリのものです。 このような実装は避ける必要があります。
ns.AuthHelper.Authenticate = function () {
window.config = {
instance: 'https://login.microsoftonline.com/',
tenant: ns.Configurations.Tenant,
clientId: ns.Configurations.AADApplicationClientID,
postLogoutRedirectUri: window.___location.origin,
cacheLocation: 'localStorage', // enable this for Internet Explorer, as sessionStorage does not work for localhost.
};
Azure Cosmos DB に保存される機密データを暗号化する
タイトル |
詳細 |
コンポーネント |
Azure Document DB |
SDL フェーズ |
Build |
適用できるテクノロジ |
ジェネリック |
属性 |
該当なし |
参照 |
該当なし |
手順 |
ドキュメント DB に保存する前にアプリケーション レベルで機密データを暗号化するか、または Azure Storage や Azure SQL のような他のストレージ ソリューションに機密データを保存します。 |
Virtual Machines によって使われるディスクを、Azure Disk Encryption を使って暗号化する
タイトル |
詳細 |
コンポーネント |
Azure IaaS VM の信頼の境界 |
SDL フェーズ |
デプロイ |
適用できるテクノロジ |
ジェネリック |
属性 |
該当なし |
参照 |
Azure Disk Encryption を使用して仮想マシンに使用されるディスクを暗号化する |
手順 |
Azure Disk Encryption は、現在プレビュー段階の新しい機能です。 この機能を使用すると、IaaS Virtual Machine に使用される OS ディスクとデータ ディスクを暗号化できます。 Windows の場合、ドライブの暗号化には、業界標準の BitLocker 暗号化テクノロジが使用されます。 Linux の場合、ディスクの暗号化には DM-Crypt テクノロジが使用されます。 DM-Crypt は Azure Key Vault と統合されているので、ディスクの暗号化キーを制御および管理できます。 Azure Disk Encryption ソリューションでは、次の 3 つのユーザー暗号化シナリオがサポートされています。 - ユーザーが暗号化した VHD ファイルおよびユーザーが提供した暗号化キーから作成した新しい IaaS VM で暗号化を有効にして、キーを Azure Key Vault に保存します。
- Azure Marketplace から作成された新しい IaaS VM での暗号化を有効にします。
- Azure で既に実行されている既存の IaaS VM での暗号化を有効にします。
|
Service Fabric アプリケーションでシークレットを暗号化する
タイトル |
詳細 |
コンポーネント |
Service Fabric の信頼の境界 |
SDL フェーズ |
Build |
適用できるテクノロジ |
ジェネリック |
属性 |
環境 - Azure |
参照 |
Service Fabric アプリケーションでのシークレットの管理 |
手順 |
シークレットは、ストレージ接続文字列、パスワード、プレーン テキストで処理できないその他の値など、機密情報である可能性があります。 Azure Key Vault を使って、Service Fabric アプリケーションのキーやシークレットを管理します。 |
セキュリティ モデリングを実行し、必要に応じて部署/チームを使います。
タイトル |
詳細 |
コンポーネント |
Dynamics CRM |
SDL フェーズ |
Build |
適用できるテクノロジ |
ジェネリック |
属性 |
該当なし |
参照 |
該当なし |
手順 |
セキュリティ モデリングを実行し、必要に応じて部署/チームを使います。 |
重要なエンティティでの共有機能へのアクセスを最小限にします。
タイトル |
詳細 |
コンポーネント |
Dynamics CRM |
SDL フェーズ |
デプロイ |
適用できるテクノロジ |
ジェネリック |
属性 |
該当なし |
参照 |
該当なし |
手順 |
重要なエンティティでの共有機能へのアクセスを最小限にします。 |
Dynamics CRM の共有機能に関連するリスクおよび適切なセキュリティ プラクティスについてユーザーをトレーニングします。
タイトル |
詳細 |
コンポーネント |
Dynamics CRM |
SDL フェーズ |
デプロイ |
適用できるテクノロジ |
ジェネリック |
属性 |
該当なし |
参照 |
該当なし |
手順 |
Dynamics CRM の共有機能に関連するリスクおよび適切なセキュリティ プラクティスについてユーザーをトレーニングします。 |
例外管理での構成の詳細の表示を禁止する開発標準規則を含める
タイトル |
詳細 |
コンポーネント |
Dynamics CRM |
SDL フェーズ |
デプロイ |
適用できるテクノロジ |
ジェネリック |
属性 |
該当なし |
参照 |
該当なし |
手順 |
開発外部の例外管理で構成の詳細の表示を禁止する開発標準規則を含めます。 コード レビューまたは定期的な検査の一部として、これをテストします。 |
Azure Storage Service Encryption (SSE) for Data at Rest (プレビュー) を使う
タイトル |
詳細 |
コンポーネント |
Azure Storage |
SDL フェーズ |
Build |
適用できるテクノロジ |
ジェネリック |
属性 |
StorageType - BLOB |
参照 |
Azure Storage Service Encryption for Data at Rest (プレビュー) |
手順 |
Azure Storage Service Encryption (SSE) for Data at Rest は、データの安全性を保護して組織のセキュリティおよびコンプライアンス要件を満たすのに役立ちます。 この機能を使用すると、Azure Storage はストレージに保存する前にデータを自動的に暗号化し、取得する前に復号化します。 暗号化、復号化、キーの管理は、ユーザーにはまったく意識されずに行われます。 SSE は、ブロック BLOB、ページ BLOB、および追加 BLOB にのみ適用されます。 テーブル、キュー、ファイルなど、他の種類のデータは暗号化されません。 暗号化と復号化のワークフロー: - ユーザーがストレージ アカウントで暗号化を有効にします
- ユーザーが Blob Storage に新しいデータを書き込むと (PUT Blob、PUT Block、PUT Page など)、使用可能なものの中で最も強力なブロック暗号化の 1 つである 256 ビット AES 暗号化を使って、すべての書き込みが暗号化されます
- ユーザーがデータにアクセスすると (GET Blob など)、データは自動的に復号化されてユーザーに返されます
- 暗号化が無効になっている場合は、新しい書き込みは暗号化されず、既存の暗号化されたデータはユーザーが書き込み直すまで暗号化された状態のままになります。 暗号化が有効になっている間、Blob Storage への書き込みは暗号化されます。 ユーザーがストレージ アカウントの暗号化の有効/無効を切り替えても、データの状態は変わりません
- すべての暗号化キーは、Microsoft によって保管、暗号化、管理されます
現時点では暗号化に使われるキーは Microsoft が管理していることに注意してください。 Microsoft は、社内ポリシーの定義に従って、キーを生成し、キーの安全な保存と定期的な循環を管理しています。 将来的には、ユーザーが独自の 暗号化キーを管理し、Microsoft が管理するキーからユーザーが管理するキーに移行する機能を追加する予定です。 |
クライアント側暗号化を使って、Azure Storage に機密データを保存する
タイトル |
詳細 |
コンポーネント |
Azure Storage |
SDL フェーズ |
Build |
適用できるテクノロジ |
ジェネリック |
属性 |
該当なし |
参照 |
Microsoft Azure Storage のクライアント側の暗号化と Azure Key Vault、チュートリアル: Azure Key Vault を使用した Microsoft Azure Storage 内の BLOB の暗号化と復号化、Azure 暗号化拡張機能で Azure Blob Storage にデータを安全に保存する |
手順 |
.NET Nuget パッケージ用 Azure Storage クライアント ライブラリは、開発者が Azure Storage にアップロードする前にクライアント アプリケーション内のデータを暗号化し、クライアントにダウンロードするときにデータを復号化する作業を支援します。 また、このライブラリは Azure Key Vault との統合にも役立ち、ストレージ アカウント キー管理に利用することができます。 ここでは、クライアント側暗号化のしくみを簡単に説明します。 - Azure ストレージ クライアント SDK は、1 回使用の対称キーであるコンテンツ暗号化キー (CEK) を生成します
- ユーザー データは、この CEK を使用して暗号化されます
- CEK は、キー暗号化キー (KEK) を使用してラップ (暗号化) されます。 KEK は、キー識別子によって識別され、非対称キー ペアまたは対称キーのどちらでもよく、ローカルに管理することも、Azure Key Vault に保存することもできます。 Storage クライアント自体が KEK にアクセスすることはありません。 クライアントは、Key Vault によって提供されるキー ラップ アルゴリズムを呼び出すだけです。 ユーザーは、必要に応じてキー ラップ/ラップ解除にカスタム プロバイダーを使うことができます
- 暗号化されたデータは、Azure Storage サービスにアップロードされます。 細かなレベルの実装の詳細については、「参照」セクションのリンクを参照してください。
|
携帯電話のローカル ストレージに書き込まれた機密データまたは PII データを暗号化する
タイトル |
詳細 |
コンポーネント |
モバイル クライアント |
SDL フェーズ |
Build |
適用できるテクノロジ |
ジェネリック、Xamarin |
属性 |
該当なし |
参照 |
Microsoft Intune ポリシーを使用してデバイスの設定と機能を管理する、Keychain Valet |
手順 |
アプリケーションがユーザーの PII (メール アドレス、電話番号、名、姓、個人設定など) のような機密情報をモバイル デバイスのファイル システムに書き込む場合、ローカル ファイル システムに書き込む前に暗号化する必要があります。 アプリケーションがエンタープライズ アプリケーションの場合は、Windows Intune を使ってアプリケーションを発行する可能性を調査します。 |
例
Intune は、機密データを保護するように次のセキュリティ ポリシーで構成できます。
Require encryption on mobile device
Require encryption on storage cards
Allow screen capture
例
アプリケーションがエンタープライズ アプリケーションではない場合は、ファイル システムに対して実行できる暗号化操作を使い、プラットフォームが提供するキーストアとキーチェーンを使って暗号化キーを保存します。 次のコード スニペットでは、xamarin を使ってキーチェーンからキーにアクセスする方法を示します。
protected static string EncryptionKey
{
get
{
if (String.IsNullOrEmpty(_Key))
{
var query = new SecRecord(SecKind.GenericPassword);
query.Service = NSBundle.MainBundle.BundleIdentifier;
query.Account = "UniqueID";
NSData uniqueId = SecKeyChain.QueryAsData(query);
if (uniqueId == null)
{
query.ValueData = NSData.FromString(System.Guid.NewGuid().ToString());
var err = SecKeyChain.Add(query);
_Key = query.ValueData.ToString();
}
else
{
_Key = uniqueId.ToString();
}
}
return _Key;
}
}
生成されたバイナリをエンド ユーザーに配布する前に難読化する
タイトル |
詳細 |
コンポーネント |
モバイル クライアント |
SDL フェーズ |
Build |
適用できるテクノロジ |
ジェネリック |
属性 |
該当なし |
参照 |
Crypto Obfuscation For .NET |
手順 |
生成されるバイナリ (apk 内のアセンブリ) は、アセンブリのリバース エンジニアリングを止めるために難読化する必要があります。この目的には、CryptoObfuscator などのツールを使うことができます。 |
clientCredentialType を Certificate または Windows に設定する
タイトル |
詳細 |
コンポーネント |
WCF |
SDL フェーズ |
Build |
適用できるテクノロジ |
.NET Framework 3 |
属性 |
該当なし |
参照 |
Fortify |
手順 |
暗号化されていないチャネルを介してプレーン テキスト パスワードで UsernameToken を使うと、攻撃者にパスワードが暴露され、SOAP メッセージを傍受できます。 UsernameToken を使うサービス プロバイダーは、プレーン テキストで送信されるパスワードを受け付ける場合があります。 暗号化されていないチャネル経由でプレーン テキスト パスワードを送信すると、資格情報が攻撃者に暴露されて SOAP メッセージを傍受できるようになります。 |
例
次の WCF サービス プロバイダーの構成では、UsernameToken を使っています。
<security mode="Message">
<message clientCredentialType="UserName" />
clientCredentialType を Certificate または Windows に設定してください。
WCF セキュリティ モードを有効にしない
タイトル |
詳細 |
コンポーネント |
WCF |
SDL フェーズ |
Build |
適用できるテクノロジ |
ジェネリック、NET Framework 3 |
属性 |
セキュリティ モード - トランスポート、セキュリティ モード - メッセージ |
参照 |
MSDN、Fortify Kingdom、WCF セキュリティの基礎 CoDe マガジン |
手順 |
トランスポートまたはメッセージのセキュリティが定義されていません。 トランスポートまたはメッセージのセキュリティなしでメッセージを送信するアプリケーションは、メッセージの機密性または整合性を保証できません。 WCF セキュリティのバインドが None に設定されている場合、トランスポートとメッセージのセキュリティはどちらも無効になります。 |
例
次の構成は、セキュリティ モードを None に設定します。
<system.serviceModel>
<bindings>
<wsHttpBinding>
<binding name=""MyBinding"">
<security mode=""None""/>
</binding>
</bindings>
</system.serviceModel>
例
すべてのサービス バインドのセキュリティ モードは 5 つです。