翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
内部オペレーション
このトピックでは、グローバルに分散されたスケーラブルな Payment Cryptography およびキー管理サービスのカスタマーキーと暗号化オペレーションを保護するためにサービスが実装する内部要件について説明します。
トピック
HSM の仕様とライフサイクル
AWS Payment Cryptography は、市販の HSM のフリートを使用します。HSM は FIPS 140-2 レベル 3 認証を受けており、PCI セキュリティ標準審議会が承認した PCI PTS デバイスリスト
すべての HSM は PCI モードで運用され、PCI PTS HSM セキュリティポリシーに基づいて設定されます。 AWS Payment Cryptography のユースケースをサポートするために必要な関数のみが有効化されています。 AWS Payment Cryptography では、クリアテキスト PINsの印刷、表示、または返却は行いません。
HSM デバイスの物理的セキュリティ
サービスで使用できるのは、配送前に製造元によって AWS Payment Cryptography 認証局 (CA) によって署名されたデバイスキーを持つ HSMs のみです。 AWS Payment Cryptography は、HSM 製造元およびデバイス証明書の信頼のルートである製造元の CA のサブ CA です。製造元の CA は ANSI TR 34 を実装し、PCI PIN セキュリティ附属書 A および PCI P2PE 附属書 A への準拠を証明しています。製造元は、 AWS Payment Cryptography CA によって署名されたデバイスキーを持つすべての HSM が AWS の指定されたレシーバーに出荷されていることを確認します。
PCI PIN Security の要求に従い、製造元は HSM の出荷とは異なる通信チャネルを介してシリアル番号のリストを提供します。これらのシリアル番号は、HSM を AWS データセンターにインストールするプロセスの各ステップで確認されます。最後に、 AWS Payment Cryptography 演算子は、インストールされた HSM のリストを製造元のリストと照合してから、 AWS Payment Cryptography キーの受信を許可された HSM のリストにシリアル番号を追加します。
HSM は常に安全な保管場所に保管されるか、以下を含む二重管理下に置かれます。
-
メーカーから AWS ラックアセンブリ施設への出荷。
-
ラックの組み立て中。
-
ラックアセンブリ施設からデータセンターへの出荷。
-
受領およびデータセンターの安全な処理室への設置。HSM ラックは、カードアクセス制御ロック、アラーム付きドアセンサー、カメラによる二重制御を実現します。
-
オペレーション中。
-
廃止作業中および廃棄中。
各 HSM について chain-of-custody、個々の説明責任を持つ完全な が維持および監視されます。
HSM の初期化
HSM は、シリアル番号、製造元がインストールしたデバイスキー、ファームウェアチェックサムによって ID と整合性が検証された後にのみ Payment AWS Cryptography フリートの一部として初期化されます。HSM の信頼性と整合性が検証されたら、PCI モードの有効化を含む設定が行われます。その後、 AWS Payment Cryptography リージョンのメインキーとプロファイルのメインキーが確立され、HSM がサービスで利用可能になります。
HSM のサービスと修理
HSM には、デバイスの暗号境界に違反する必要のない保守可能なコンポーネントがあります。これらのコンポーネントには、冷却ファン、電源、バッテリーが含まれます。HSM または HSM ラック内の別のデバイスの修理が必要な場合、ラックが開いている間ずっとデュアルコントロールが維持されます。
HSM の廃止作業
廃止は、HSM の障害 end-of-life または障害が原因で発生します。HSM は、機能していればラックから取り出す前に論理的にゼロ化され、AWS データセンターの安全な処理室内で廃棄されます。廃棄される前に、修理のためにメーカーに返却されたり、別の目的で使用されたり、安全な処理室から持ち出されたりすることはありません。
HSM ファームウェアの更新
HSM ファームウェアの更新は、PCI PTS HSM および FIPS 140-2 (または FIPS 140-3) にリストされているバージョンとの整合性を維持するために必要な場合、更新がセキュリティに関連する場合、またはお客様が新しいバージョンの機能からメリットを得ることができると判断された場合に適用されます。 AWS Payment Cryptography HSMs、PCI PTS HSM にリストされているバージョンと一致する off-the-shelf ファームウェアを実行します。新しいファームウェアバージョンは PCI または FIPS 認定ファームウェアバージョンとの整合性が検証され、機能性テストを経てすべての HSM に展開されます。
オペレーターアクセス
オペレーターは、ごくまれに、通常の運用中に HSM から収集された情報では問題を特定したり変更を計画したりするには不十分であるというトラブルシューティングに、コンソール以外でも HSM にアクセスできます。以下のステップが実行されます。
-
トラブルシューティングアクティビティが作成され承認され、コンソール以外のセッションがスケジュールされます。
-
HSM は顧客処理サービスから削除されます。
-
主キーは二重制御下で削除されます。
-
オペレーターは、コンソール以外でも HSM にアクセスして、承認されたトラブルシューティング作業を、デュアルコントロールのもとで実行できます。
-
コンソール以外のセッションが終了すると、HSM で初期プロビジョニング処理が実行され、標準ファームウェアと設定が戻され、メインキーが同期されてから HSM がサービスを受けている顧客に返却されます。
-
セッションの記録は変更追跡に記録されます。
-
セッションから得られた情報は、future 変更を計画するために使用されます。
-
コンソール以外のアクセスレコードはすべて、プロセスのコンプライアンスと、HSM モニタリング、 non-console-access 管理プロセス、またはオペレータトレーニングへの潜在的な変更についてレビューされます。
キー管理
リージョン内のすべての HSM はリージョンメインキーと同期されます。リージョンメインキーは少なくとも 1 つのプロファイルメインキーを保護します。プロファイルメインキーはカスタマーキーを保護します。
すべてのメインキーは HSM によって生成され、ANSI X9 TR 34 および PCI PIN Annex A に沿った非対称技術を使用した対称キー分散によって配布されます。
トピック
[Generation] (生成)
AES 256 ビットのメインキーは、PCI PTS HSM 乱数ジェネレーターを使用して、サービス HSM フリートにプロビジョニングされた HSM の 1 つで生成されます。
リージョンメインキー同期
HSM リージョンメインキーは、ANSI X9 TR-34 で定義されている次のようなメカニズムを使用して、リージョナルフリート全体のサービスによって同期されます。
-
キー分散ホスト (KDH) とキー受信デバイス (KRD) のキーと証明書を使用する連携認証により、公開キーの認証と整合性を確保します。
-
証明書は PCI PIN Annex A2 の要件を満たす認証局 (CA) によって署名されますが、AES 256 ビットキーの保護に適した非対称アルゴリズムとキー強度は除きます。
-
分散型対称キーの識別とキー保護は ANSI X9 TR-34 および PCI PIN Annex A1 と同じです。ただし、AES 256 ビットキーの保護に適した非対称アルゴリズムとキー強度は除きます。
リージョンメインキーは、以下の方法でリージョンの認証とプロビジョニングが行われた HSM に対して設定されます。
-
メインキーはリージョンの HSM で生成されます。その HSM はキー分散ホストとして指定されます。
-
リージョン内のプロビジョニングされたすべての HSM は、HSM のパブリックキーと再生不可能な認証情報を含む KRD 認証トークンを生成します。
-
KRD トークンは、KDH が HSM の ID とキーを受け取る許可を検証した後に KDH 許可リストに追加されます。
-
KDH は HSM ごとに認証可能なメインキートークンを生成します。トークンには KDH 認証情報と、作成対象の HSM にのみロード可能な暗号化されたメインキーが含まれています。
-
各 HSM には、その HSM 用に構築されたメインキートークンが送信されます。HSM 自身の認証情報と KDH 認証情報を検証した後、メインキーは KRD プライベートキーによって復号化され、メインキーにロードされます。
1 つの HSM をリージョンと再同期する必要がある場合は以下を参照してください。
-
ファームウェアと設定を使用して再検証され、プロビジョニングされます。
-
そのリージョンで初めて導入された場合は以下を参照してください。
-
HSM は KRD 認証トークンを生成します。
-
KDH はトークンを許可リストに追加します。
-
KDH は HSM のメインキートークンを生成します。
-
HSM はメインキーをロードします。
-
HSM がサービスで利用可能になります。
-
これにより、次のことが保証されます。
-
リージョン内の AWS Payment Cryptography 処理用に検証された HSM のみが、そのリージョンのマスターキーを受信できます。
-
AWS Payment Cryptography HSM のマスターキーのみをフリートの HSM に配布できます。
リージョンメインキーのローテーション
リージョンメインキーは、暗号期間の満了時、万が一、キーの侵害が疑われる場合、またはキーのセキュリティに影響があると判断されたサービスの変更後にローテーションされます。
最初のプロビジョニングと同様に、新しいリージョンメインキーが生成され、配布されます。保存したプロファイルメインキーは、新しいリージョンメインキーに変換する必要があります。
リージョンメインキーローテーションは顧客処理には影響しません。
プロファイルメインキーの同期
プロファイルメインキーはリージョンメインキーによって保護されます。これにより、プロファイルは特定の地域に制限されます。
プロファイルメインキーは、それに応じてプロビジョニングされます。
-
プロファイルメインキーは、リージョンメインキーが同期された HSM で生成されます。
-
プロファイルメインキーは、プロファイル設定やその他のコンテキストで保存され、暗号化されます。
-
このプロファイルは、リージョンメインキーを持つリージョン内のすべての HSM が顧客の暗号化機能に使用されます。
プロファイルメインキーのローテーション
プロファイルメインキーは、暗号期間の満了時、キーの侵害が疑われるとき、またはキーのセキュリティに影響すると判断されたサービスの変更後にローテーションされます。
ローテーション手順は以下の通りです。
-
初期プロビジョニングと同様に、新しいプロファイルメインキーが生成され、保留中のメインキーとして配布されます。
-
バックグラウンドプロセスにより、カスタマーキーマテリアルが確立されたプロファイルメインキーから保留中のメインキーに変換されます。
-
すべてのカスタマーキーが保留中のキーで暗号化されると、保留中のキーはプロファイルメインキーに昇格します。
-
バックグラウンド処理により、期限切れのキーで保護されているカスタマーキー情報が削除されます。
プロファイルメインキーローテーションは顧客処理には影響しません。
保護
キーはキー階層にのみ依存して保護されます。主なキーを保護することは、すべてのカスタマーキーの紛失や漏洩を防ぐために重要です。
リージョンメインキーは、HSM で認証され、サービス用にプロビジョニングされた場合にのみバックアップから復元できます。これらのキーは、特定の HSM の特定の KDH からの連携認証可能な暗号化されたメインキートークンとしてのみ保存できます。
プロファイルマスターキーは、地域ごとに暗号化されたプロファイル設定とコンテキスト情報とともに保存されます。
カスタマーキーはキーブロックに保存され、プロファイルマスターキーで保護されます。
すべてのキーは HSM 内にのみ存在するか、同等かそれ以上の暗号強度を持つ別のキーで保護されて保管されます。
耐久性
トランザクション暗号化とビジネス機能のカスタマーキーは、通常、停止の原因となる極端な状況でも利用できる必要があります。 AWS Payment Cryptography は、可用性ゾーンと AWS リージョン全体で複数レベルの冗長モデルを使用します。Payment Cryptography オペレーションについて、サービスが提供するものよりも高い可用性と耐久性を求めるお客様は、マルチリージョンアーキテクチャを実装する必要があります。
HSM 認証とメインキートークンは保存され、HSM をリセットする必要がある場合にメインキーを復元したり、新しいメインキーと同期したりするために使用できます。トークンはアーカイブされ、必要に応じて二重制御下でのみ使用されます。
通信セキュリティ
外部
AWS Payment Cryptography API エンドポイントは、1.2 以降の TLS や、リクエストの認証と整合性のための署名バージョン 4 などの AWS セキュリティ基準を満たしています。
受信 TLS 接続はNetwork Load Balancerで終了し、内部 TLS 接続を介して API ハンドラーに転送されます。
内部
サービスコンポーネント間、およびサービスコンポーネントと他の AWS サービス間の内部通信は、強力な暗号化を使用する TLS によって保護されます。
HSM は、サービスコンポーネントからのみアクセスできる非仮想プライベートネットワーク上にあります。HSM とサービスコンポーネント間のすべての接続は、TLS 1.2 以上の連携 TLS (mTLS) で保護されています。TLS と mTLS の内部証明書は、AWS プライベート認証局を使用して Amazon Certificate Manager によって管理されます。内部 VPC と HSM ネットワークは、予期しないアクティビティや設定変更がないか監視されます。
カスタマーキーの管理
では AWS、お客様の信頼が最優先事項です。お客様の AWS アカウントでサービスにアップロードまたは作成したキーを完全に管理し、キーへのアクセスを設定する責任はお客様にあります。
AWS Payment Cryptography は、サービスによって管理されるキーの HSM の物理的なコンプライアンスとキー管理に全責任を負います。これには、HSM メインキーの所有権と管理、および AWS Payment Cryptography キーデータベース内の保護されたカスタマーキーのストレージが必要です。
カスタマーキースペースの分離
AWS Payment Cryptography は、キーが別のアカウントと明示的に共有されていない限り、キーを所有するアカウントへのプリンシパルの制限を含む、すべてのキー使用にキーポリシーを適用します。
バックアップとリカバリ
リージョンのキーとキー情報は、 AWSによって暗号化されたアーカイブにバックアップされます。アーカイブを復元 AWS するには、 による二重制御が必要です。
キーブロック
すべてのキーは ANSI X9 TR-31 形式のキーブロックに保存されます。
キーは、 でサポートされている暗号文やその他のキーブロック形式からサービスにインポートできます ImportKey。同様に、キーがエクスポート可能な場合は、キーエクスポートプロファイルでサポートされている他のキーブロック形式または暗号グラムにエクスポートできます。
キーの使用
キーの使用は、サービス KeyUsage によって設定された に制限されます。このサービスは、要求された暗号オペレーションに対して不適切なキーの使用、使用方法、またはアルゴリズムを使用する要求をすべて拒否します。
キー交換関係
PCI PIN セキュリティと PCI P2PE では、PIN を暗号化するキー (それらのキーの共有に使用される KEK を含む) を共有する組織は、それらのキーを他の組織と共有しないことが義務付けられています。対称キーは、同じ組織内を含め、2 者間でのみの共有がベストプラクティスです。これにより、キーの侵害が疑われ、影響を受けたキーの交換を余儀なくされることによる影響を最小限に抑えることができます。
2 者以上の当事者間でキーを共有する必要があるビジネスケースでも、当事者の数は最小限に抑える必要があります。
AWS Payment Cryptography には、これらの要件内でキーの使用を追跡および適用するために使用できるキータグが用意されています。
例えば、サービスプロバイダーと共有されるすべてのキーに「KIF」=「PosStation」を設定することで、異なるキー注入施設の KEK と BDK を識別できます。もう 1 つの例は、支払いネットワークと共有されているキーに「ネットワーク」=PayCard「」というタグを付けることです。タグ付けを行うと、アクセス制御を作成したり、キー管理の実施や実証に役立つ監査レポートを作成したりできます。
キー削除
DeleteKey は、お客様が設定可能な期間後に、データベース内のキーを削除対象としてマークします。この期間が過ぎると、キーは回復不能に削除されます。これは、キーが誤ってまたは悪意を持って削除されるのを防ぐための安全メカニズムです。削除対象としてマークされたキーは、 以外のアクションでは使用できません RestoreKey。
削除したキーは、削除後 7 日間はサービスバックアップに残ります。この期間中、復元することはできません。
閉鎖された AWS アカウントのキーは削除対象としてマークされます。削除期間に達する前にアカウントを再アクティブ化すると、削除対象としてマークされたキーはすべて復元されますが、無効になります。これらのキーを暗号化オペレーションに使用するには、ユーザーが再び有効にする必要があります。
ログ記録とモニタリング
内部サービスログには以下が含まれます。
-
CloudTrail サービスによって行われた AWS サービス呼び出しのログ
CloudWatch HSM からのログまたはイベントに直接記録された両方のイベントの CloudWatch ログ
HSM とサービスシステムからのログファイル
ログアーカイブ
すべてのログソースは、キーを含む機密情報を監視し、フィルタリングします。ログは体系的に見直され、機密性の高い顧客情報が含まれていないことが確認されます。
ログへのアクセスは、職務遂行に必要な個人に限定されています。
すべてのログは、AWS のログ保持ポリシーに従って保持されます。
