

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

# 暗号化標準
<a name="standards"></a>

標準はポリシーから算出されます。これらは範囲が狭く、実装のフレームワークとアーキテクチャを定義するのに役立ちます。例えば、組織のポリシーが保管中のデータを暗号化する場合、標準は必要な暗号化のタイプを定義し、ポリシーの遵守方法に関する一般的な指示を提供します。

通常、暗号化標準では以下を指定します。
+ 使用する暗号化のタイプ
+ 暗号化キーの最小仕様
+ 暗号化キーにアクセスできるユーザー
+ 暗号化キーを保存する場所
+ 暗号化またはハッシュ手法を選択するときに適切なキー強度を選択する基準
+ キーローテーションの頻度

暗号化ポリシーの更新はほとんど必要ありませんが、暗号化標準は変更される可能性があります。サイバーセキュリティ業界は、絶えず変化する脅威の状況に合わせて絶えず進化しています。そのため、エンタープライズデータに可能な限り最善の保護を提供するために、最新のテクノロジーとベストプラクティスを採用するように標準を変更する必要があります。

エンタープライズ組織では、副取締役、取締役、またはデータスチュワードは通常、暗号化標準を定義し、コンプライアンス責任者は通常、それらを確認して承認します。

組織で暗号化標準を定義および維持するときは、次のカテゴリの要因を考慮してください。
+ [コストとパフォーマンスに関する考慮事項](#cost-performance)
+ [キーアクセスコントロール](#access-control)
+ [暗号化タイプ](#encryption-types)
+ [暗号化キーの仕様](#encryption-key-specifications)
+ [キーストレージの場所](#key-storage-location)

## コストとパフォーマンスに関する考慮事項
<a name="cost-performance"></a>

保管中のデータの暗号化標準を決定するときは、以下の運用上の要因を考慮してください。
+ 利用可能なハードウェアリソースは、 標準を大規模にサポートできる必要があります。
+ 暗号化のコストは、キーの長さ、データ量、および暗号化の実行に必要な時間によって異なります。例えば、対称暗号化と比較すると、非対称暗号化では長いキーが使用され、時間がかかります。
+ エンタープライズアプリケーションのパフォーマンス要件を検討します。アプリケーションで低レイテンシーと高スループットが必要な場合は、対称暗号化を使用することをお勧めします。

## キーアクセスコントロール
<a name="access-control"></a>

最小特権の原則に基づいて、暗号化キーのアクセス制御ポリシーを特定します。最小特権とは、ユーザーに職務を遂行するために必要最小限のアクセス権を付与するという、セキュリティのベストプラクティスです。標準で、以下のアクセスコントロールポリシーを定義します。
+ キー暗号化キーとデータキーを管理するロールを識別します。
+ 主要なアクセス許可を定義し、ロールにマッピングします。例えば、キー管理者権限を持つユーザーと、キーユーザー権限を持つユーザーを定義します。キー管理者はキー暗号化キーを作成または変更でき、キーユーザーはデータを暗号化および復号し、データキーを生成できます。

## 暗号化タイプ
<a name="encryption-types"></a>

標準では、組織に適した暗号化タイプと機能を定義します。
+ 対称暗号化アルゴリズムと非対称暗号化アルゴリズムを使用するタイミングを文書化します。詳細については、よくある質問セクション[非対称暗号化が必要なのはいつですか?](faq.md#faq-asymmetric-encryption)の**[対称暗号化はいつ必要ですか?](faq.md#faq-symmetric-encryption)「」と「」を参照してください。
+ エンベロープ暗号化を使用するかどうかを決定し、状況を定義します。詳細については、*よくある質問*セクションの[エンベロープ暗号化が必要なのはいつですか?](faq.md#faq-envelope-encryption)「」を参照してください。
+ トークナイゼーションやハッシュなど、暗号化の代替手段をいつ使用するかの基準を定義します。

## 暗号化キーの仕様
<a name="encryption-key-specifications"></a>

キー強度やアルゴリズムなど、暗号化キーに必要な仕様を定義します。これらの仕様は、ポリシーで定義されている規制およびコンプライアンス体制に準拠している必要があります。次の仕様を定義することを検討してください。
+ 対称暗号化タイプと非対称暗号化タイプの両方の最小キー強度とアルゴリズムを定義します。キー強度の要因には、長さ、ランダム性、一意性が含まれます。
+ 暗号化アルゴリズムの新しいバージョンを実装するタイミングを定義します。例えば、標準では、*リリースから 30 日以内にアルゴリズムの最新バージョンを実装*するか、*常に最新のリリースより 1 つ古いバージョンを使用する*ように指定できます。
+ 暗号化キーをローテーションする間隔を定義します。

## キーストレージの場所
<a name="key-storage-location"></a>

標準では、暗号化キーの保存先を決定する際には、次の点を考慮してください。
+ コンプライアンスおよび規制要件により、暗号化キーの保存先が規定される場合があります。
+ キーを一元的な場所に保存するか、対応するデータとともに保存するかを決定します。詳細については、*よくある質問*セクションの[暗号化キーを一元管理する必要があるのはなぜですか?](faq.md#faq-central-management)「」を参照してください。
+ 集中型ストレージを選択した場合は、ハードウェアセキュリティモジュール (HSM) などのエンタープライズマネージドインフラストラクチャにキーを保存するか、 などのマネージドサービスプロバイダーにキーを保存するかを決定します AWS Key Management Service。詳細については、*よくある質問*セクションの[ハードウェアセキュリティモジュール (HSM) をいつ使用する必要がありますか?](faq.md#faq-hsm)「」を参照してください。