セキュリティ フレーム: 暗号化 | 軽減策
- [アーティクル]
-
-
| 製品/サービス |
[アーティクル] |
|
Web アプリケーション |
|
|
[データベース] |
|
|
IoT デバイス |
|
|
IoT クラウド ゲートウェイ |
|
|
Dynamics CRM モバイル クライアント |
|
|
Dynamics CRM Outlook クライアント |
|
|
Identity Server |
|
承認済みの対称ブロック暗号とキー長のみを使用する
| タイトル |
詳細 |
|
コンポーネント |
Web アプリケーション |
|
SDL フェーズ |
Build |
|
適用できるテクノロジ |
ジェネリック |
|
属性 |
該当なし |
|
参照 |
該当なし |
|
手順 |
製品では、組織の暗号アドバイザーによって明示的に承認された対称ブロック暗号および関連付けられたキー長のみを使用する必要があります。 Microsoft での承認済みの対称アルゴリズムには、次のブロック暗号が含まれます。 - 新しいコードでは、AES-128、AES-192、AES-256 が許容されます。
- 既存のコードとの下位互換性を確保するために、three-key 3DES が許容されます。
- 対称ブロック暗号を使用する製品では、次の点に注意してください。
- 新しいコードでは、Advanced Encryption Standard (AES) が必須となります。
- three-key Triple Data Encryption Standard (3DES) は、下位互換性を確保するために既存のコードで許容されます。
- RC2、DES、2-key 3DES、DESX、Skipjack など、他のすべてのブロック暗号は、古いデータの復号化にのみ使用できます。暗号化に使用する場合は置き換える必要があります。
- 対称ブロック暗号化アルゴリズムでは、128 ビットの最小キー長が必須となります。 新しいコードに推奨されるブロック暗号化アルゴリズムは AES だけです (AES-128、AES-192、AES-256 はすべて許容されます)。
- 現在、three-key 3DES は、既存のコードで既に使用されている場合には許容されますが、AES に移行することをお勧めします。 DES、DESX、RC2、Skipjack は安全と見なされなくなりました。 これらのアルゴリズムは、下位互換性を確保するために既存のデータの復号化にのみ使用できます。データは、推奨されるブロック暗号を使用して再暗号化する必要があります。
対称ブロック暗号は、いずれも承認済みの暗号モードで使用する必要があることに注意してください。承認済みの暗号モードでは、適切な初期化ベクトル (IV) を使用する必要があります。 通常、適切な IV は乱数であり、定数値ではありません。 組織の暗号委員会によるレビュー後に、従来の暗号化アルゴリズムまたは未承認の暗号化アルゴリズムと短いキー長を、(新しいデータの書き込みではなく) 既存のデータの読み取りに使用することが認められる場合があります。 ただし、この要件の例外を申請する必要があります。 さらに、エンタープライズ デプロイでは、データの読み取りに脆弱な暗号が使用されているときに、製品で管理者に警告することを検討する必要があります。 このような警告は、説明的ですぐに実行できる内容にします。 グループ ポリシーによって、脆弱な暗号の使用を制御するのが適している場合もあります。 管理された暗号化方式の指定で許容される .NET のアルゴリズム (優先順) - AesCng (FIPS に準拠している)
- AuthenticatedAesCng (FIPS に準拠している)
- AESCryptoServiceProvider (FIPS に準拠している)
- AESManaged (FIPS に準拠していない)
これらのアルゴリズムはいずれも、machine.config ファイルに変更を加えずに SymmetricAlgorithm.Create メソッドまたは CryptoConfig.CreateFromName メソッドを使用して指定することはできないことに注意してください。 また、.NET 3.5 より前のバージョンの .NET での AES の名前は RijndaelManaged であることにも注意してください。AesCng と AuthenticatedAesCng は CodePlex から入手できますが、基になる OS に CNG が必要です。 |
対称暗号に承認済みのブロック暗号モードと初期化ベクトルを使用する
| タイトル |
詳細 |
|
コンポーネント |
Web アプリケーション |
|
SDL フェーズ |
Build |
|
適用できるテクノロジ |
ジェネリック |
|
属性 |
該当なし |
|
参照 |
該当なし |
|
手順 |
対称ブロック暗号はいずれも承認済みの対称暗号モードで使用する必要があります。 承認済みのモードは CBC と CTS だけです。 具体的には、電子コード ブック (ECB) 動作モードは避ける必要があります。ECB を使用する場合は、組織の暗号委員会のレビューが必要となります。 OFB、CFB、CTR、CCM、GCM、またはその他の暗号化モードを使用する場合は、常に組織の暗号委員会によるレビューを受ける必要があります。 CTR などの "ストリーム暗号モード" のブロック暗号で同じ初期化ベクトル (IV) を再利用すると、暗号化されたデータが露呈する可能性があります。 また、対称ブロック暗号はいずれも適切な初期化ベクトル (IV) で使用する必要があります。 通常、適切な IV は暗号強度が高い乱数であり、定数値ではありません。 |
承認済みの非対称アルゴリズム、キー長、パディングを使用する
| タイトル |
詳細 |
|
コンポーネント |
Web アプリケーション |
|
SDL フェーズ |
Build |
|
適用できるテクノロジ |
ジェネリック |
|
属性 |
該当なし |
|
参照 |
該当なし |
|
手順 |
禁止された暗号化アルゴリズムの使用は、製品のセキュリティに重大なリスクをもたらすので避ける必要があります。 製品では、組織の暗号委員会によって明示的に承認されている暗号化アルゴリズム、関連付けられたキー長、パディングのみを使用する必要があります。 -
RSA - 暗号化、キー交換、署名に使用できます。 RSA 暗号化では、OAEP または RSA-KEM パディング モードのみを使用する必要があります。 既存のコードでは、互換性の確保のみを目的として、PKCS #1 v1.5 パディング モードを使用できます。 null パディングの使用は明示的に禁止されています。 新しいコードでは、2048 ビット以上のキーが必要です。 既存のコードは、組織の暗号委員会によるレビュー後に、下位互換性の確保のみを目的として、2048 ビット未満のキーをサポートできます。 1024 ビット未満のキーは、古いデータの復号化または検証にのみ使用できます。暗号化または署名操作に使用する場合は置き換える必要があります。
-
ECDSA - 署名にのみ使用できます。 新しいコードでは、256 ビット以上のキーを使用する ECDSA が必要です。 ECDSA ベースの署名では、NIST が承認した 3 つの曲線 (P-256、P-384、P521) のいずれかを使用する必要があります。 徹底的に分析された曲線は、組織の暗号委員会によるレビュー後にのみ使用できます。
-
ECDH - キー交換にのみ使用できます。 新しいコードでは、256 ビット以上のキーを使用する ECDH が必要です。 ECDH ベースのキー交換では、NIST が承認した 3 つの曲線 (P-256、P-384、P521) のいずれかを使用する必要があります。 徹底的に分析された曲線は、組織の暗号委員会によるレビュー後にのみ使用できます。
-
DSA - 組織の暗号委員会によるレビューおよび承認後に許容される場合があります。 セキュリティ アドバイザーに連絡して、組織の暗号委員会によるレビューのスケジュールを設定してください。 DSA の使用が承認された場合、長さが 2048 ビット未満のキーの使用を禁止する必要があることに注意してください。 CNG は、Windows 8 以降で 2048 ビット以上のキー長をサポートします。
-
Diffie-Hellman - セッション キーの管理にのみ使用できます。 新しいコードでは、2048 ビット以上のキー長が必要です。 既存のコードは、組織の暗号委員会によるレビュー後に、下位互換性の確保のみを目的として、2048 ビット未満のキー長をサポートできます。 1024 ビット未満のキーは使用できません。
|
承認済みの乱数ジェネレーターを使用する
| タイトル |
詳細 |
|
コンポーネント |
Web アプリケーション |
|
SDL フェーズ |
Build |
|
適用できるテクノロジ |
ジェネリック |
|
属性 |
該当なし |
|
参照 |
該当なし |
|
手順 |
製品では、承認済みの乱数ジェネレーターを使用する必要があります。 そのため、C ランタイム関数の rand などの擬似ランダム関数、.NET Framework の System.Random クラス、GetTickCount などのシステム関数をコードで使用することはできません。 双対楕円曲線乱数ジェネレーター (DUAL_EC_DRBG) アルゴリズムの使用は禁止されています。 -
CNG - BCryptGenRandom (呼び出し元が 0 より大きい IRQL (つまり、PASSIVE_LEVEL) で実行されている場合を除き、BCRYPT_USE_SYSTEM_PREFERRED_RNG フラグを使用することをお勧めします)。
-
CAPI - cryptGenRandom
-
Win32/64 - RtlGenRandom (新しい実装では、BCryptGenRandom または CryptGenRandom を使用する必要があります) * rand_s * SystemPrng (カーネル モードの場合)
-
.NET - RNGCryptoServiceProvider または RNGCng
-
Windows ストア アプリ - Windows.Security.Cryptography.CryptographicBuffer.GenerateRandom または .GenerateRandomNumber
-
Apple OS X (10.7 以降)/iOS(2.0 以降) - int SecRandomCopyBytes (SecRandomRef random, size_t count, uint8_t *bytes )
-
Apple OS X (10.7 より前)- /dev/random を使って乱数を取得します
-
Java(Google Android Java コードを含む) - java.security.SecureRandom クラス。 Android 4.3 (Jelly Bean) の場合、開発者は Android の推奨回避策に従い、アプリケーションを更新して、/dev/urandom または /dev/random のエントロピーで PRNG を明示的に初期化する必要があります。
|
対称ストリーム暗号は使用しない
| タイトル |
詳細 |
|
コンポーネント |
Web アプリケーション |
|
SDL フェーズ |
Build |
|
適用できるテクノロジ |
ジェネリック |
|
属性 |
該当なし |
|
参照 |
該当なし |
|
手順 |
対称ストリーム暗号 (RC4 など) は使用しないでください。 製品では、対称ストリーム暗号ではなく、ブロック暗号を使用する必要があります。具体的には、キー長が 128 ビット以上の AES を使用します。 |
承認済みの MAC/HMAC/キー付きハッシュ アルゴリズムを使用する
| タイトル |
詳細 |
|
コンポーネント |
Web アプリケーション |
|
SDL フェーズ |
Build |
|
適用できるテクノロジ |
ジェネリック |
|
属性 |
該当なし |
|
参照 |
該当なし |
|
手順 |
製品では、承認済みのメッセージ認証コード (MAC) アルゴリズムまたはハッシュ ベース メッセージ認証コード (HMAC) アルゴリズムのみを使用する必要があります。 メッセージ認証コード (MAC) はメッセージに添付される情報の一部です。MAC により、メッセージの受信者は、秘密キーを使用して送信元の信頼性とメッセージの整合性を確認することが可能になります。 基になるすべてのハッシュ アルゴリズムまたは対称暗号化アルゴリズムも使用が承認されていれば、ハッシュ ベースの MAC (HMAC) またはブロック暗号ベースの MAC の使用が許容されます。現時点では、これには HMAC-SHA2 関数 (HMAC-SHA256、HMAC-SHA384、HMAC-SHA512) と、ブロック暗号ベースの MAC である CMAC/OMAC1 および OMAC2 (これらは AES に基づいています) が含まれます。 プラットフォームの互換性を確保するために、HMAC-SHA1 の使用が許容される場合もありますが、この手順の例外を申請し、組織の暗号委員会のレビューを受ける必要があります。 HMAC を 128 ビット未満に切り捨てることは許可されていません。 顧客独自の方法を使用したキーとデータのハッシュは承認されておらず、使用前に組織の暗号委員会によるレビューを受ける必要があります。 |
承認済みの暗号化ハッシュ関数のみを使用する
| タイトル |
詳細 |
|
コンポーネント |
Web アプリケーション |
|
SDL フェーズ |
Build |
|
適用できるテクノロジ |
ジェネリック |
|
属性 |
該当なし |
|
参照 |
該当なし |
|
手順 |
製品では、SHA-2 ファミリのハッシュ アルゴリズム (SHA256、SHA384、SHA512) を使用する必要があります。 短い MD5 ハッシュを念頭に置いて設計されたデータ構造に合わせるために 128 ビット出力長が必要な場合など、短いハッシュが必要な場合、製品チームは SHA2 ハッシュのいずれか (通常は SHA256) を切り捨てることができます。 SHA384 は SHA512 の切り捨てられたバージョンです。 セキュリティ上の目的で暗号化ハッシュを切り捨てる場合、128 ビット未満に切り捨てることは許可されていません。 新しいコードでは、MD2、MD4、MD5、SHA-0、SHA-1、RIPEMD の各ハッシュ アルゴリズムは使用しないでください。 これらのアルゴリズムでは、ハッシュの競合が計算的に可能であるため、実質的にアルゴリズムを破ることになります。 管理された暗号化方式の指定で許容される .NET のハッシュ アルゴリズムは次のとおりです (優先順)。 - SHA512Cng (FIPS に準拠している)
- SHA384Cng (FIPS に準拠している)
- SHA256Cng (FIPS に準拠している)
- SHA512Managed (FIPS に準拠していない) (HashAlgorithm.Create または CryptoConfig.CreateFromName の呼び出しで、アルゴリズム名として SHA512 を使用する)
- SHA384Managed (FIPS に準拠していない) (HashAlgorithm.Create または CryptoConfig.CreateFromName の呼び出しで、アルゴリズム名として SHA384 を使用する)
- SHA256Managed (FIPS に準拠していない) (HashAlgorithm.Create または CryptoConfig.CreateFromName の呼び出しで、アルゴリズム名として SHA256 を使用する)
- SHA512CryptoServiceProvider (FIPS に準拠している)
- SHA256CryptoServiceProvider (FIPS に準拠している)
- SHA384CryptoServiceProvider (FIPS に準拠している)
|
強力な暗号化アルゴリズムを使用してデータベース内のデータを暗号化する
| タイトル |
詳細 |
|
コンポーネント |
データベース |
|
SDL フェーズ |
Build |
|
適用できるテクノロジ |
ジェネリック |
|
属性 |
該当なし |
|
参照 |
暗号化アルゴリズムの選択 |
|
手順 |
暗号化アルゴリズムによって定義されるデータ変換は、未承認ユーザーが容易に復元できないものです。 SQL Server では、管理者と開発者は、DES、Triple DES、TRIPLE_DES_3KEY、RC2、RC4、128 ビット RC4、DESX、128 ビット AES、192 ビット AES、256 ビット AES など、多数のアルゴリズムの中から選択できます。 |
SSIS パッケージを暗号化し、デジタル署名する必要がある
| タイトル |
詳細 |
|
コンポーネント |
データベース |
|
SDL フェーズ |
Build |
|
適用できるテクノロジ |
ジェネリック |
|
属性 |
該当なし |
|
参照 |
デジタル署名を使用してパッケージのソースを特定する、脅威と脆弱性の対策 (Integration Services) |
|
手順 |
パッケージのソースは、パッケージを作成した個人または組織です。 不明なソースや信頼されていないソースのパッケージを実行することは危険な場合があります。 SSIS パッケージの不正な改ざんを防ぐには、デジタル署名を使用する必要があります。 また、保存中や転送中にパッケージの機密性を確保するために、SSIS パッケージを暗号化する必要があります。 |
重要なセキュリティ保護可能なデータベース リソースにデジタル署名を追加する
| タイトル |
詳細 |
|
コンポーネント |
データベース |
|
SDL フェーズ |
Build |
|
適用できるテクノロジ |
ジェネリック |
|
属性 |
該当なし |
|
参照 |
ADD SIGNATURE (Transact-SQL) |
|
手順 |
重要なセキュリティ保護可能なデータベース リソースの整合性を検証する必要がある場合、デジタル署名を使用する必要があります。 ストアド プロシージャ、関数、アセンブリ、トリガーなど、セキュリティ保護可能なデータベース リソースにデジタル署名することができます。 これが役立つ状況の例を紹介します。ISV (独立系ソフトウェア ベンダー) が、顧客に提供されたソフトウェアのサポートを提供するとします。 ISV はサポートを提供する前に、そのソフトウェアのセキュリティ保護可能なデータベース リソースが誤って改ざんされたり、悪意のある試みによって改ざんされたりしていないことを確認する必要があります。 セキュリティ保護可能なリソースがデジタル署名されていれば、ISV はデジタル署名を確認し、そのリソースの整合性を検証できます。 |
SQL Server EKM を使用して暗号化キーを保護する
| タイトル |
詳細 |
|
コンポーネント |
データベース |
|
SDL フェーズ |
Build |
|
適用できるテクノロジ |
ジェネリック |
|
属性 |
該当なし |
|
参照 |
SQL Server 拡張キー管理 (EKM)、Azure Key Vault を使用する拡張キー管理 (SQL Server) |
|
手順 |
SQL Server 拡張キー管理を使用すると、データベース ファイルを保護する暗号化キーを、スマート カード、USB デバイス、EKM/HSM モジュールなどの外部デバイスに保存できます。 これにより、データベース管理者 (sysadmin グループのメンバーを除く) からのデータの保護も実現され、 そのデータベース ユーザー以外はアクセスできない外部 EKM/HSM モジュール上の暗号化キーを使用してデータを暗号化できます。 |
暗号化キーがデータベース エンジンに公開されないようにする必要がある場合は AlwaysEncrypted 機能を使用する
| タイトル |
詳細 |
|
コンポーネント |
データベース |
|
SDL フェーズ |
Build |
|
適用できるテクノロジ |
SQL Azure、OnPrem |
|
属性 |
SQL バージョン - V12、MsSQL2016 |
|
参照 |
Always Encrypted (データベース エンジン) |
|
手順 |
Always Encrypted は、Azure SQL Database や SQL Server データベースに格納された、クレジット カード番号や国民識別番号および地域識別番号 (米国の社会保障番号など) などの機密データを保護することを目的とした機能です。 Always Encrypted を使用すると、クライアントはクライアント アプリケーション内の機密データを暗号化することができます。暗号化キーがデータベース エンジン (SQL Database や SQL Server) に公開されることはありません。 これにより、Always Encrypted では、データの所有者 (データを表示できるユーザー) とデータの管理者 (アクセス権は付与しないユーザー) を分離できます。 |
IoT デバイスで暗号化キーを安全に保存する
| タイトル |
詳細 |
|
コンポーネント |
IoT デバイス |
|
SDL フェーズ |
Build |
|
適用できるテクノロジ |
ジェネリック |
|
属性 |
デバイスの OS - Windows IoT Core、デバイスの接続 - Azure IoT device SDK |
|
参照 |
Windows IoT Core 上の TPM、Windows IoT Core 上での TPM のセットアップ、Azure IoT device SDK の TPM |
|
手順 |
対称秘密キーまたは証明書の秘密キーは、TPM やスマート カード チップのようなハードウェアで保護された記憶域に安全に保存します。 Windows 10 IoT Core では TPM の使用をサポートしています。いくつかの互換性のある TPM を使用できます (Discrete TPM (dTPM))。 ファームウェア TPM またはディスクリート TPM を使用することをお勧めします。 ソフトウェア TPM は、開発およびテストにのみ使用します。 TPM が使用可能であり、キーがプロビジョニングされたら、機密情報をハードコーディングせずに、トークンを生成するコードを作成する必要があります。 |
例
TpmDevice myDevice = new TpmDevice(0);
// Use logical device 0 on the TPM
string hubUri = myDevice.GetHostName();
string deviceId = myDevice.GetDeviceId();
string sasToken = myDevice.GetSASToken();
var deviceClient = DeviceClient.Create( hubUri, AuthenticationMethodFactory. CreateAuthenticationWithToken(deviceId, sasToken), TransportType.Amqp);
上記のように、デバイスの主キーはコード内にはありません。 代わりに、スロット 0 の TPM に格納されます。 TPM デバイスは、有効期間の短い SAS トークンを生成します。このトークンは、IoT Hub への接続に使用されます。
IoT Hub に対する認証用に十分な長さのランダムな対称キーを生成する
| タイトル |
詳細 |
|
コンポーネント |
IoT クラウド ゲートウェイ |
|
SDL フェーズ |
Build |
|
適用できるテクノロジ |
ジェネリック |
|
属性 |
ゲートウェイの選択 - Azure IoT Hub |
|
参照 |
該当なし |
|
手順 |
IoT Hub にはデバイス ID レジストリがあり、デバイスのプロビジョニング時に、ランダムな対称キーが自動的に生成されます。 Azure IoT Hub ID レジストリのこの機能を使用して、認証に使用するキーを生成することをお勧めします。 また、IoT Hub では、デバイスの作成時にキーを指定することもできます。 デバイスのプロビジョニング時に IoT Hub の外部でキーを生成する場合は、ランダムな対称キーまたは 256 ビット以上のキーを作成することをお勧めします。 |
PIN の使用を要求し、リモート ワイプを許可するデバイス管理ポリシーが設定されていることを確認します。
| タイトル |
詳細 |
|
コンポーネント |
Dynamics CRM モバイル クライアント |
|
SDL フェーズ |
デプロイ |
|
適用できるテクノロジ |
ジェネリック |
|
属性 |
該当なし |
|
参照 |
該当なし |
|
手順 |
PIN の使用を要求し、リモート ワイプを許可するデバイス管理ポリシーが設定されていることを確認します。 |
PIN/パスワード/自動ロックを要求し、すべてのデータを暗号化する (BitLocker など) デバイス管理ポリシーが設定されていることを確認する
| タイトル |
詳細 |
|
コンポーネント |
Dynamics CRM Outlook クライアント |
|
SDL フェーズ |
Build |
|
適用できるテクノロジ |
ジェネリック |
|
属性 |
該当なし |
|
参照 |
該当なし |
|
手順 |
PIN/パスワード/自動ロックを要求し、すべてのデータを暗号化する (BitLocker など) デバイス管理ポリシーが設定されていることを確認する |
Identity Server を使用するときは、署名キーがロールオーバーされていることを確認する
| タイトル |
詳細 |
|
コンポーネント |
Identity Server |
|
SDL フェーズ |
デプロイ |
|
適用できるテクノロジ |
ジェネリック |
|
属性 |
該当なし |
|
参照 |
Identity Server - キー、署名、暗号化 |
|
手順 |
Identity Server を使用するときは、署名キーがロールオーバーされていることを確認します。 「参照」のリンク先ドキュメントでは、Identity Server を利用するアプリケーションを停止させずにこれを計画する方法を説明しています。 |
Identity Server で暗号強度が高いクライアント ID とクライアント シークレットが使用されていることを確認する
| タイトル |
詳細 |
|
コンポーネント |
Identity Server |
|
SDL フェーズ |
Build |
|
適用できるテクノロジ |
ジェネリック |
|
属性 |
該当なし |
|
参照 |
該当なし |
|
手順 |
Identity Server で暗号強度が高いクライアント ID とクライアント シークレットが使用されていることを確認します。 クライアント ID とクライアント シークレットを生成するときは、次のガイドラインに従ってください。 - クライアント ID として、ランダムな GUID を生成します。
- シークレットとして、暗号化されたランダムな 256 ビット キーを生成します。
|