| 製品/サービス |
[アーティクル] |
|
Web アプリケーション |
|
|
データベース |
|
|
IoT デバイス |
|
|
IoT クラウド ゲートウェイ |
|
|
Dynamics CRM モバイル クライアント |
|
|
Dynamics CRM Outlook クライアント |
|
|
Identity Server |
|
承認された対称ブロック暗号とキーの長さのみを使用してください
| タイトル |
詳細 |
|
コンポーネント |
Web アプリケーション |
|
SDL フェーズ |
建築する |
|
適用できるテクノロジ |
ジェネリック |
|
属性 |
なし |
|
参考文献 |
なし |
|
手順 |
製品は、組織の Crypto Advisor によって明示的に承認された対称ブロック暗号と関連するキー長のみを使用する必要があります。 Microsoft で承認されている対称アルゴリズムには、次のブロック暗号が含まれます。 - 新しいコードの場合、AES-128、AES-192、および AES-256 を使用できます
- 既存のコードとの下位互換性のために、3 キーの 3DES を使用できます
- 対称ブロック暗号を使用する製品の場合:
- 新しいコードには Advanced Encryption Standard (AES) が必要です
- 3 キーの 3DES (Triple Data Encryption Standard) は、下位互換性のために既存のコードで許可されています
- RC2、DES、2 Key 3DES、DESX、Skipjack など、他のすべてのブロック暗号は、古いデータの復号化にのみ使用でき、暗号化に使用する場合は置き換える必要があります
- 対称ブロック暗号化アルゴリズムの場合、128 ビットの最小キー長が必要です。 新しいコードに推奨されるブロック暗号化アルゴリズムはAESのみです(AES-128、AES-192、AES-256はすべて受け入れられます)
- 3 キー 3DES は、既存のコードで既に使用されている場合に、現在許容されます。AES への移行をお勧めします。 DES、DESX、RC2、およびSkipjackは、セキュアとは見なされなくなりました。 これらのアルゴリズムは、下位互換性のために既存のデータを復号化するためにのみ使用でき、データは推奨されるブロック暗号を使用して再暗号化する必要があります
すべての対称ブロック暗号は、適切な初期化ベクトル(IV)を使用する必要がある承認済み暗号モードで使用する必要があることに注意してください。 適切なIVは、通常、乱数であり、定数値ではありません 従来の暗号化アルゴリズムまたはその他の方法で承認されていない暗号化アルゴリズムの使用と、既存のデータの読み取りに (新しいデータを書き込むのではなく) より短いキー長を使用することは、組織の Crypto Board のレビュー後に許可される場合があります。 ただし、この要件に対する例外を申請する必要があります。 さらに、エンタープライズ展開では、データの読み取りに弱い暗号化が使用されている場合、製品で管理者に警告することを検討する必要があります。 このような警告は、説明的で実行可能なものでなければなりません。 場合によっては、グループ ポリシーで弱い暗号の使用を制御することが適切な場合があります マネージド暗号化の俊敏性のために許可された .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 フェーズ |
建築する |
|
適用できるテクノロジ |
ジェネリック |
|
属性 |
なし |
|
参考文献 |
なし |
|
手順 |
すべての対称ブロック暗号は、承認された対称暗号モードで使用する必要があります。 承認されているモードは CBC と CTS のみです。 特に、電子コードブック (ECB) の操作モードは避けるべきです。ECBの利用には、組織のCrypto Boardの審査が必要です。 OFB、CFB、CTR、CCM、GCM、またはその他の暗号化モードのすべての使用は、組織の暗号化委員会によって確認される必要があります。 CTRなどの「ストリーミング暗号モード」のブロック暗号で同じ初期化ベクトル(IV)を再利用すると、暗号化されたデータが公開される可能性があります。 すべての対称ブロック暗号は、適切な初期化ベクトル (IV) と共に使用する必要があります。 適切な IV は、暗号的に強力な乱数であり、定数値ではありません。 |
承認された非対称アルゴリズム、キーの長さ、パディングを使用する
| タイトル |
詳細 |
|
コンポーネント |
Web アプリケーション |
|
SDL フェーズ |
建築する |
|
適用できるテクノロジ |
ジェネリック |
|
属性 |
なし |
|
参考文献 |
なし |
|
手順 |
禁止されている暗号化アルゴリズムの使用は、製品のセキュリティに重大なリスクをもたらすため、回避する必要があります。 製品では、組織の Crypto Board によって明示的に承認された暗号化アルゴリズムと、関連するキーの長さとパディングのみを使用する必要があります。 -
RSA- 暗号化、キー交換、および署名に使用できます。 RSA 暗号化では、OAEP モードまたは RSA-KEM パディング モードのみを使用する必要があります。 既存のコードでは、互換性のためにのみ PKCS #1 v1.5 パディング モードを使用できます。 null パディングの使用は明示的に禁止されています。 新しいコードには、キー >= 2048 ビットが必要です。 既存のコードでは、組織の Crypto Board によるレビュー後の下位互換性のためにのみ、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- は、組織のCrypto Boardからの審査と承認を経て、受け入れられる場合があります。 セキュリティアドバイザーに連絡して、組織のCrypto Boardのレビューをスケジュールしてください。 DSA の使用が承認された場合は、長さが 2048 ビット未満のキーの使用を禁止する必要があることに注意してください。 CNG は、Windows 8 の時点で 2048 ビット以上のキー長をサポートしています。
-
Diffie-Hellman- は、セッション キー管理にのみ使用できます。 新しいコードには、キーの長さ >= 2048 ビットが必要です。 既存のコードでは、組織の Crypto Board によるレビュー後の下位互換性のためにのみ、2048 ビット < キー長がサポートされている場合があります。 1024ビット < キーは使用できません。
|
承認された乱数ジェネレーターを使用する
| タイトル |
詳細 |
|
コンポーネント |
Web アプリケーション |
|
SDL フェーズ |
建築する |
|
適用できるテクノロジ |
ジェネリック |
|
属性 |
なし |
|
参考文献 |
なし |
|
手順 |
商品は、承認された乱数ジェネレーターを使用する必要があります。 したがって、C ランタイム関数 rand、.NET Framework クラスの System.Random、GetTickCount などのシステム関数などの擬似ランダム関数は、このようなコードでは使用しないでください。 双対楕円曲線乱数発生器(DUAL_EC_DRBG)アルゴリズムの使用は禁止されています -
CNG- BCryptGenRandom(呼び出し元が 0 より大きい IRQL [つまり、PASSIVE_LEVEL] で実行される可能性がある場合を除き、BCRYPT_USE_SYSTEM_PREFERRED_RNG フラグの使用をお勧めします])
-
CAPI- cryptGenランダム
-
Win32/64- RtlGenRandom (新しい実装では BCryptGenRandom または CryptGenRandom を使用) * rand_s * SystemPrng (カーネルモード用)
-
で囲まれています。NET- RNGCryptoServiceProvider または RNGCng
-
Windowsストアアプリ- Windows.Security.Cryptography.CryptographicBuffer.GenerateRandom または .乱数の生成
-
Apple OS X (10.7+)/iOS(2.0+)- int SecRandomCopyBytes (SecRandomRef ランダム、size_t数、uint8_t *バイト)
-
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 フェーズ |
建築する |
|
適用できるテクノロジ |
ジェネリック |
|
属性 |
なし |
|
参考文献 |
なし |
|
手順 |
RC4 などの対称ストリーム暗号は使用しないでください。 対称ストリーム暗号の代わりに、製品はブロック暗号、特にキー長が 128 ビット以上の AES を使用する必要があります。 |
承認されたMAC/HMAC/キー付きハッシュアルゴリズムを使用
| タイトル |
詳細 |
|
コンポーネント |
Web アプリケーション |
|
SDL フェーズ |
建築する |
|
適用できるテクノロジ |
ジェネリック |
|
属性 |
なし |
|
参考文献 |
なし |
|
手順 |
製品では、承認済みメッセージ認証コード (MAC) またはハッシュベースのメッセージ認証コード (HMAC) アルゴリズムのみを使用する必要があります。 メッセージ認証コード (MAC) は、受信者が秘密キーを使用して送信者の信頼性とメッセージの整合性の両方を確認できるようにする、メッセージに添付された情報の一部です。 ハッシュベース MAC (HMAC) または ブロック暗号ベース MAC のいずれかの使用は、すべての基礎となるハッシュまたは対称暗号化アルゴリズムも使用が承認されている限り許容されます。現在、これには HMAC-SHA2 機能(HMAC-SHA256、HMAC-SHA384、HMAC-SHA512)とCMAC/OMAC1およびOMAC2ブロック暗号ベースのMAC(これらはAESに基づく)が含まれます。 プラットフォームの互換性のために HMAC-SHA1 の使用が許可される場合がありますが、この手順の例外を提出し、組織の暗号レビューを受ける必要があります。 HMAC を 128 ビット未満に切り捨てることは許可されていません。 キーとデータをハッシュするために顧客の方法を使用することは承認されていないため、使用する前に組織のCrypto Boardのレビューを受ける必要があります。 |
承認された暗号化ハッシュ関数のみを使用してください
| タイトル |
詳細 |
|
コンポーネント |
Web アプリケーション |
|
SDL フェーズ |
建築する |
|
適用できるテクノロジ |
ジェネリック |
|
属性 |
なし |
|
参考文献 |
なし |
|
手順 |
製品では、SHA-2 ファミリーのハッシュ アルゴリズム (SHA256、SHA384、SHA512) を使用する必要があります。 短い MD5 ハッシュを念頭に置いて設計されたデータ構造に適合させるために、128 ビットの出力長など、より短いハッシュが必要な場合、製品チームは SHA2 ハッシュ (通常は SHA256) の 1 つを切り捨てることができます。 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 フェーズ |
建築する |
|
適用できるテクノロジ |
ジェネリック |
|
属性 |
なし |
|
参考文献 |
暗号化アルゴリズムの選択 |
|
手順 |
暗号化アルゴリズムは、承認されていないユーザーが簡単に取り消すことができないデータ変換を定義します。 SQL Server では、管理者と開発者は、DES、Triple DES、TRIPLE_DES_3KEY、RC2、RC4、128 ビット RC4、DESX、128 ビット AES、192 ビット AES、256 ビット AES など、いくつかのアルゴリズムから選択できます |
SSIS パッケージは暗号化し、デジタル署名する必要があります
| タイトル |
詳細 |
|
コンポーネント |
データベース |
|
SDL フェーズ |
建築する |
|
適用できるテクノロジ |
ジェネリック |
|
属性 |
なし |
|
参考文献 |
デジタル署名、脅威、脆弱性の軽減策を使用してパッケージのソースを特定する (Integration Services) |
|
手順 |
パッケージのソースは、パッケージを作成した個人または組織です。 不明なソースや信頼されていないソースのパッケージを実行することは危険な場合があります。 SSIS パッケージの不正な改ざんを防ぐために、デジタル署名を使用する必要があります。 また、保管/輸送中のパッケージの機密性を確保するために、SSIS パッケージは暗号化する必要があります |
重要なデータベース セキュリティ保護可能なリソースにデジタル署名を追加する
| タイトル |
詳細 |
|
コンポーネント |
データベース |
|
SDL フェーズ |
建築する |
|
適用できるテクノロジ |
ジェネリック |
|
属性 |
なし |
|
参考文献 |
署名を追加 (Transact-SQL) |
|
手順 |
重要なデータベースのセキュリティ保護可能なリソースの整合性を検証する必要がある場合は、デジタル署名を使用する必要があります。 ストアド プロシージャ、関数、アセンブリ、トリガなどのデータベースのセキュリティ保護可能なリソースは、デジタル署名できます。 これが役立つ場合の例を次に示します: ISV (独立系ソフトウェア ベンダー) が、顧客の 1 人に配信されたソフトウェアにサポートを提供したとします。 ISV は、サポートを提供する前に、ソフトウェア内のセキュリティ保護可能なデータベースが誤って、または悪意のある試みによって改ざんされていないことを確認したいと考えています。 セキュリティ保護可能なリソースがデジタル署名されている場合、ISV はデジタル署名を検証し、その整合性を検証できます。 |
SQL Server EKM を使用して暗号化キーを保護する
| タイトル |
詳細 |
|
コンポーネント |
データベース |
|
SDL フェーズ |
建築する |
|
適用できるテクノロジ |
ジェネリック |
|
属性 |
なし |
|
参考文献 |
SQL Server 拡張キー管理 (EKM)、Azure Key Vault を使用した拡張キー管理 (SQL Server) |
|
手順 |
SQL Server Extensible Key Management を使用すると、データベース ファイルを保護する暗号化キーを、スマートカード、USB デバイス、EKM/HSM モジュールなどのオフボックス デバイスに格納できます。 これにより、データベース管理者 (sysadmin グループのメンバーを除く) からのデータ保護も可能になります。 データは、データベース ユーザーのみが外部 EKM/HSM モジュールでアクセスできる暗号化キーを使用して暗号化できます。 |
暗号化キーをデータベース エンジンに公開しない場合は、AlwaysEncrypted 機能を使用します
| タイトル |
詳細 |
|
コンポーネント |
データベース |
|
SDL フェーズ |
建築する |
|
適用できるテクノロジ |
SQL Azure、OnPrem |
|
属性 |
SQL バージョン - V12、MsSQL2016 |
|
参考文献 |
Always Encrypted (データベース エンジン) |
|
手順 |
Always Encrypted は、Azure SQL Database または SQL Server データベースに格納されているクレジット カード番号や国/地域の ID 番号 (米国の社会保障番号など) などの機密データを保護するために設計された機能です。 Always Encrypted を使用すると、クライアントはクライアント アプリケーション内の機密データを暗号化でき、暗号化キーがデータベース エンジン (SQL Database または SQL Server) に表示されることはありません。 その結果、Always Encrypted では、データの所有者 (および表示可能) とデータを管理するユーザー (ただし、アクセス権を持たないユーザー) が分離されます |
暗号化キーをIoTデバイスに安全に保存します
| タイトル |
詳細 |
|
コンポーネント |
IoT デバイス |
|
SDL フェーズ |
建築する |
|
適用できるテクノロジ |
ジェネリック |
|
属性 |
デバイス OS - Windows IoT Core、デバイス接続 - Azure IoT device SDKs |
|
参考文献 |
Windows IoT Core での TPM、 Windows IoT Core での TPM の設定、 Azure IoT Device SDK TPM |
|
手順 |
対称キーまたは証明書の秘密キーは、TPM やスマート カード チップなどのハードウェアで保護されたストレージに安全に格納されています。 Windows 10 IoT Core は TPM のユーザーをサポートしており、 ディスクリート 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);
ご覧のとおり、デバイスの主キーはコードに存在しません。 代わりに、TPM のスロット 0 に格納されます。 TPM デバイスは、IoT Hub への接続に使用される有効期間の短い SAS トークンを生成します。
IoT Hub への認証に十分な長さのランダムな対称キーを生成する
| タイトル |
詳細 |
|
コンポーネント |
IoT クラウド ゲートウェイ |
|
SDL フェーズ |
建築する |
|
適用できるテクノロジ |
ジェネリック |
|
属性 |
ゲートウェイの選択 - 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 フェーズ |
建築する |
|
適用できるテクノロジ |
ジェネリック |
|
属性 |
なし |
|
参考文献 |
なし |
|
手順 |
PIN/パスワード/自動ロックを必要とし、すべてのデータを暗号化するデバイス管理ポリシーが設定されていることを確認します (BitLocker など)。 |
Identity Serverの使用時に署名キーがロールオーバーされていることを確認する
| タイトル |
詳細 |
|
コンポーネント |
アイデンティティサーバー |
|
SDL フェーズ |
デプロイメント |
|
適用できるテクノロジ |
ジェネリック |
|
属性 |
なし |
|
参考文献 |
なし |
|
手順 |
Identity Serverの使用時に署名キーがロールオーバーされていることを確認してください。 参照セクションのリンクでは、Identity Serverに依存するアプリケーションを停止させることなく、これを計画する方法を説明しています。 |
暗号的に強力なクライアントIDとクライアントシークレットがIdentity Serverで使用されていることを確認します
| タイトル |
詳細 |
|
コンポーネント |
アイデンティティサーバー |
|
SDL フェーズ |
建築する |
|
適用できるテクノロジ |
ジェネリック |
|
属性 |
なし |
|
参考文献 |
なし |
|
手順 |
暗号的に強力なクライアント ID とクライアント シークレットが Identity Server で使用されていることを確認します。 クライアント ID とシークレットを生成する際には、次のガイドラインを使用する必要があります。 - クライアント ID としてランダムな GUID を生成する
- 暗号的にランダムな 256 ビット キーをシークレットとして生成します
|