Dell EMC Data Domain Encryption - よくある質問(FAQ)
Summary: このナレッジベース記事では、よくある質問 (FAQ) をまとめて、参照しやすいようにまとめています。
Instructions
暗号化設定
質問:DDでの暗号化(DARE)の構成
答える:DARE暗号化は、次の手順でDDに構成できます。
-
暗号化ライセンスの追加
-
セキュリティ担当者を追加し、セキュリティ担当者権限権限を有効にする
-
暗号化の有効化
1)暗号化ライセンスの追加:
有効な暗号化ライセンスが追加されたライセンス ファイルを用意します
次のコマンドを使用し、使用可能なライセンス ファイルを使用してDDのeライセンスをアップデートします。
eライセンス アップデート
2)セキュリティ担当者を追加し、SO認証を有効にします:
a)次のコマンドを使用して、「security」としての役割を持つユーザーを追加します。
ユーザーによるsecuserロール セキュリティの追加
b)次のコマンドを使用して、セットアップでSecurity Officer Authorizationを有効にします。
許可ポリシー セット security-officer enabled
3.DARE暗号化の有効化:
次のコマンドを使用してDARE暗号化を有効にします。
Filesys暗号化有効
質問:静止データ暗号化機能でサポートされているプラットフォームは何ですか
答える:静止データ暗号化機能は、EDP(Encryption Disablement Project)システムを除き、すべてのData Domainシステムでサポートされています。
質問:ユーザーがDDでデータをクリア テキストで保存するには、どうすればよいですか
答える:ユーザーは、セットアップで暗号化がオフになっていることを確認することで、データが平文で保存され、DDで暗号化されていないことを確認できます。
ユーザーは、次のコマンドを使用してDDの暗号化を無効にすることができます。
Filesys暗号化無効化
質問:静止データ暗号化機能でサポートされているバックアップ アプリケーション/プロトコルはどれですか
答える:DD DARE機能は、基盤となるバックアップ アプリケーションやDDで使用されるプロトコルに依存しません
質問: Data Domainシステムで選択できる暗号化アルゴリズムはどれですか
答える:DD Encryptionソフトウェアは、CBC(暗号ブロック連鎖)またはGCM(Galois Counter Mode)を使用するAES 128または256ビット アルゴリズムをサポートします。
GCMは、対称キー暗号ブロック暗号の動作モードです。これは、認証とプライバシー(機密性)の両方を提供するように設計された認証済み暗号化アルゴリズムです。名前が示すように、GCM は、よく知られた暗号化のカウンター モードと新しい Galois 認証モードを組み合わせたものです。GCMの認証面では、暗号化されたデータがData Domainシステムによって実行され、他の手段によって「注入」されていないことが保証されます。これは、データが暗号化されているCBCとは異なりますが(プライバシー面)、暗号化されたデータの信頼性はチェックされません
CBCモードでは、プレーン テキストの各ブロックは、暗号化される前に前の暗号テキスト ブロックと排他的ORで結合されます。このように、各暗号テキストブロックは、その時点までに処理されたすべてのプレーンテキストブロックに依存します。また、各メッセージを一意にするには、最初のブロックで初期化ベクトルを使用する必要があります。CBCは、暗号化によってのみデータのプライバシー(機密性)を保証します。暗号化アルゴリズムまたはプロセスの認証は行われません
質問:DDの暗号化アルゴリズムを変更するにはどうすればよいですか?
回答:セットアップで特定の暗号化アルゴリズムを設定する場合は、次のコマンドを使用します。
Filesys暗号化アルゴリズム セット
Example:
# filesys encryption algorithm set {aes_128_cbc | aes_256_cbc | aes_128_gcm | aes_256_gcm}
質問:暗号化が有効になった後、既存のデータで暗号化を確実に行うにはどうすればよいでしょうか
答える:次のコマンドを使用して、DDFSに既存のデータを強制的に暗号化させることができます。
# filesys encryption apply-changes
これにより、次のクリーン サイクルが通常よりもかなり長くなり、リソースを大量に消費します
質問:DDで暗号化を無効にする方法を教えてください
答える:encryption disableコマンドを使用して、DDで暗号化機能を無効にします。
Filesys暗号化無効化
これにより、受信I/Oの暗号化のみが無効になります。既存の暗号化されたデータは、apply-changesを使用して手動で復号化されるまで暗号化されたままです
質問:DDファイル システムの再起動を必要とする暗号化コマンドを有効にするには、どのコマンドを使用します
答える:次の暗号化コマンドを有効にするには、DDファイル システムを再起動する必要があります。
Filesys暗号化の有効化/無効化 - Data Domainシステムで暗号化を有効/無効にします。
Filesys暗号化アルゴリズムの設定 - ユーザーが暗号化アルゴリズムを選択できるようにします。
Filesys暗号化アルゴリズムのリセット - 暗号化アルゴリズムを CBC モードの AES 256 にリセットします(デフォルト)。
質問: Data Domainファイル システムを設定/使用するために無効にする必要がある暗号化コマンドはどれですか
答える:次の暗号化コマンドを設定または使用するには、Data Domainファイル システムを無効にする必要があります。
暗号化パスフレーズの変更
暗号化のロック/ロック解除
暗号化に関する一般的な質問
質問:DD EncryptionはすべてのDDシステムでサポートされていますか
答える:DD Encryptionソフトウェア オプションは、DDシステムでサポートされますが、DDシステムが暗号化を有効化できない暗号化無効化プロジェクト(EDP)でない場合、主にロシア リージョンのシステムで販売されています
質問:DDシステムでの暗号化はどのように実行されます
答える:暗号化は、DDOSのOpenSSLとRSA BSafe(RSA BSafeは、DDシステムが静止データを暗号化するために使用するFIPS 140-2検証済みの暗号化ライブラリーです)ライブラリーを使用して行われます。
質問:システムで使用されているBSafeのバージョンは何ですか
答える:DDOS 7.10の時点で使用されているBSafeバージョンは、「BSAFE Micro Edition Suite 4.4.0.0」および「BSAFE Crypto-C Micro Edition: 4.1.4.0"
質問: DDOSで暗号化を構成するために使用できるユーザー インターフェイスは何ですか
答える:暗号化は、CLI、UI、またはREST APIを使用して構成できます。REST APIはDDOSリリース8.0以降で追加されました。
質問:データの選択的暗号化は可能ですか? MTreeまたはファイルを1つだけにしたいですか
答える:選択的暗号化はできません。暗号化はシステム全体でのみ有効または無効にすることができ、選択的に有効または無効にすることはできません。クラウド サポートを備えたシステムでは、クラウド階層とクラウド ユニットの単位で暗号化を有効または無効にすることができます。
質問:暗号化キーまたはアカウント パスワードは、データファイル、プログラム、または認証ディレクトリーでエンティティが認証を行うときなど、クリア テキストまたは脆弱な暗号で送信または保存されていますか
答える:そんなことはありません
質問:システムで使用されているOpenSSLのバージョンは何ですか
答える:DDOS 7.10リリース時点で、opensslバージョンは「OpenSSL 1.0.2zd-fips」です
質問: 静止データ暗号化は、ユーザーやアプリケーションからのデータ アクセスからどのように保護しますか
答える:
-
静止データの暗号化とは、ディスク サブシステム上に存在するデータを暗号化することです。暗号化または復号化は圧縮レイヤーで行われます。ユーザーまたはアプリケーションは、Data Domainシステムとクリア テキスト データを送受信しますが、Data Domainシステムに物理的に存在するすべてのデータは暗号化されます。
-
すべての暗号化はファイル システムとネームスペースの下で行われ、ユーザーやアプリケーションからは認識されません。ユーザーまたはアプリケーションがファイルまたはディレクトリへのアクセスをすでに許可している場合、データは暗号化に関係なくネイティブ形式で読み取ることができます。
-
DD Encryptionは、侵入者が他のネットワーク セキュリティ制御を回避し、適切な暗号化キーを使用せずに暗号化されたデータにアクセスした場合、そのデータを読み取りおよび使用できないように設計されています。
質問:重複排除後に暗号化されますか
答える:はい、暗号化は重複排除されたデータで行われます。データは、ディスクに保存される前に暗号化されます。
質問:Data Domainはデータのセキュリティをどのように確保しますか
答える:データは、静止データ暗号化機能を使用して保護されます。さらに、デバイスが削除されると(ヘッドスワップ、ファイル システム ロック)、パスフレーズはシステムから削除されます。このパスフレーズは暗号化キーの暗号化に使用されるため、データはさらに保護されます
質問:暗号化するとどのようなアラートが生成されます
答える:アラートは、次の場合に生成されます。
-
侵害された暗号化キーが存在する場合
-
暗号化キー テーブルがいっぱいになり、システムにキーを追加できない場合
-
自動キーのエクスポートに失敗した場合
-
自動キー ローテーションに失敗した場合
-
暗号化が無効になっている場合
-
システム パスフレーズが変更された日時
質問:DDOSのセキュリティ認定はありますか?
回答:Data DomainシステムはFIPS 140-2に準拠しています。
質問:暗号化キーはどこに保存されますか
答える:暗号化キーは、DDOSシステムのコレクション パーティションに永続的に保存されます。
質問:誰かがData Domainシステムからハード ドライブを取り出した場合、そのハード ドライブからデータを復号化できますか
答える:暗号化キーは、システム ヘッドに格納されているシステム パスフレーズを使用して暗号化されます。暗号化キーはディスクに保存されていますが、システム パスフレーズがないと暗号化キーを復号化できません。したがって、データの暗号化に使用されるキーがわからない場合、ハードドライブから復号化することはできません。
質問:リカバリー、特にディザスター リカバリーにはどのような暗号化キーとパスワードが必要ですか
答える:キーは安全なファイルにエクスポートし、システムの外部に保持することができます。このファイルのリカバリは、エンジニアリングの助けを借りて行われます。また、リカバリー時に、お客様はkeys exportコマンドの実行時に使用したパスフレーズを知っている必要があります
質問:システムをリモートの場所に転送する前にファイル システムをロックする方法。
答える:以下はその手順です。
-
ファイル システムを無効化します。
sysadmin@itrdc-DD630-42# filesys無効化
-
ファイル システムをロックし、新しいパスフレーズを入力します(これには、上記のセキュリティ ユーザーによる認証が必要です)。
sysadmin@itrdc-DD630-42#filesys暗号化ロック
このコマンドには、「セキュリティ」ロールを持つユーザーによる承認が必要です。
Please present credentials for such a user below.
ユーザー名:secuser
パスワード:
現在のパスフレーズを入力します。
新しいパスフレーズを入力:
新しいパスフレーズの再入力:
パスフレーズが一致しました。
これで、ファイル システムがロックされました。 -
新しいパスフレーズを紛失したり忘れたり しないでください 。このパスフレーズがないと、ファイル システムのロックを解除できません。つまり、DDR上のデータにアクセスできません。リモートの場所に到達したときにシステムのロックを解除するには、次のコマンドを使用します。
sysadmin@itrdc-DD630-42# filesys encryption unlock
このコマンドには、「セキュリティ」ロールを持つユーザーによる承認が必要です
該当するユーザーの認証情報を以下に提示してください。
ユーザー名:secuser
パスワード:
パスフレーズを入力:
パスフレーズが検証されました。ファイルシステムを起動するには、「filesys enable」を使用します。
-
これで、ファイル システムを通常どおりに有効化して使用できるようになりました
質問:storage sanitizeコマンドはファイル システムの暗号化と何らかの関係がありますか
答える:いいえ。ファイル システムの暗号化とストレージのサニタイズは、2つの独立した機能です。
質問:EDP(暗号化無効化プロジェクト)システムでネットワーク経由の暗号化はサポートされていますか
答える:EDPシステムでは、静止データ暗号化(DARE)またはワイヤ経由の暗号化(レプリケーションまたはddboostを使用)を有効にすることはできません。
システム パスフレーズ
質問:システム パスフレーズとは何ですか
答える:DDOSには、システム レベルのパスフレーズを設定することで、システム内の認証情報を保護するためのプロビジョニングがあります。パスフレーズは、マシンで使用可能なAES 256暗号化キーを生成するために使用されるスマートカードのような、人間が判読できる(理解できる)キーです。
これには、次の 2 つの利点があります。
-
これにより、管理者は暗号化キーを操作することなくパスフレーズを変更できます。パスフレーズを変更すると、キーの暗号化が間接的に変更されますが、ユーザー データには影響しません。パスフレーズを変更しても、基盤となるData Domainシステム暗号化キーは変更されません。Data Domainシステム キーの暗号化は変更されますが、システム キーは同じままです。
-
これにより、物理Data Domainシステムに、パスフレーズは保存せずに、システムに暗号化キーを付けて出荷できます。このように、輸送中に箱が盗まれた場合、システムには暗号化されたキーと暗号化されたデータしかないため、攻撃者はデータを簡単に回復できません。
パスフレーズは、Data Domainストレージ システムの非表示の部分に内部的に保存されます。これにより、Data Domainシステムが起動し、管理者の介入なしにデータ アクセスのサービスを継続できます。
パスフレーズの作成または変更:
-
システム パスフレーズは、管理者がData Domainシステムで認証した後にCLIを使用して作成できます。
-
システム パスフレーズは、管理者とセキュリティ ロール ユーザー(セキュリティ担当者など)がData Domainシステムで認証した後に、CLIを使用して変更できます(1人の管理者が独立して変更することはできません)。
質問:パスフレーズはいつ使用されますか
答える:システム パスフレーズは、ファイル システム暗号化、クラウド アクセス、証明書管理、Boostトークン、スケールアウト環境でのシステム構成モジュール、ライセンス情報など、さまざまなDDOSコンポーネントでプライマリー キーとして使用されます。DDOSソフトウェアは、このシステム パスフレーズを設定および変更するメカニズムを提供します。また、システム パスフレーズをディスクに保存するかどうかを制御するオプションも用意されています。これは、DDシステムの転送中にセキュリティを強化するために特に使用されます。
質問:DDシステムの安全な転送のためにパスフレーズはどのように使用されます
答える:このプロセスでは「filesys encryption lock」コマンドを使用します。これにより、ユーザーはパスフレーズを変更してファイル システムをロックできます。ユーザーは、暗号化キーを再暗号化する新しいパスフレーズを入力しますが、新しいパスフレーズは保存されません。暗号化キーは、「filesys encryption unlock」コマンドを使用してファイル システムのロックを解除するまでリカバリできません。
このプロセスは「Confluence Lab セキュリティ設定ガイド」で説明されています
質問:パスフレーズが変更された場合はどうなりますか? データには引き続きアクセスできます
答える:はい。パスフレーズを変更しても、基盤となるData Domainシステムの暗号化キーは変更されず、暗号化キーの暗号化のみが変更されます。したがって、データ アクセスには影響しません
質問:パスフレーズがシステムに設定されているかどうかを確認するにはどうすればよいですか
答える:システムにパスフレーズが設定されている場合、「system passphrase set」コマンドを実行すると、パスフレーズがすでに設定されていることを示すエラーがスローされます
質問:パスフレーズを紛失または忘れた場合はどうなります
答える:ボックスがロックされている間にお客様がパスフレーズを紛失すると、データも失われます。バックドアやそれにアクセスするための代替方法はありません。そのパスフレーズを管理するための適切なプロセスがないと、このような事態が偶発的に発生する可能性があり、キーやデータをリカバリーすることはできません。ただし、システムに統合された保護メカニズムにより、暗号化されたキーが失われたり破損したりすることはありません
質問:忘れたシステム パスフレーズをリセットするメカニズムはありますか
答える:システム パスフレーズは、カスタマー サポートの支援を受けた特定のシナリオでのみ強制的にリセットできます。DDOS 7.2で導入された強制アップデート メカニズムは、特定の条件が満たされている場合にのみ使用できます。詳細については、KB記事20983「Data Domain: DDOS v7.2以降で紛失したシステム パスフレーズをリセットする方法(記事を表示するにはDellサポートへのログインが必要)
質問: DDシステムにシステム パスフレーズを保存しないようにするオプションはありますか
答える:デフォルトでは、システム パスフレーズはData Domainシステム上の非表示の場所に保存されます。システム オプション「system passphrase option store-on-disk」を使用すると、これを変更し、パスフレーズをディスクに保存しないようにすることができます。
Embedded Key Manager(EKM)
最上位レベルのコマンド:
system# filesys encryption embedded-key-manager <オプション>
質問:Embedded Key Managerでは、キー ローテーションはサポートされています
答える: はい。Data Domainシステムごとのキー ローテーションは、Embedded Key Managerでサポートされています。管理者はUIまたはCLIを使用して、キー ローテーション期間(週次または月次)を設定できます
質問:埋め込み型キー管理機能は有料ですか
答える:この機能は無料です。この機能は、標準のDD Encryptionソフトウェア ライセンス オプションの一部として含まれています。
質問:お客様はローカル キー管理から外部キー管理(EKM)に移行できますか
答える
-
はい。外部キー マネージャーはいつでも有効にできます。ただし、使用されているローカル キーはData Domainシステムに残ります。外部キー マネージャーは、EKMキーを管理できません。既存のデータを再暗号化する必要はありません。お客様のコンプライアンス データをEKMキーで再暗号化する必要がある場合は、新しいRWキーでapply-changesを使用して手動で暗号化する必要があります。切り替え後のEKMキーの破棄は必須ではありません。
-
キーマネージャー スイッチは、アクティブ キーをKMIPのキーに自動的に切り替えます。
-
切り替えが発生したときのKMIPキーMUIDの外観の例
Key-ID Key MUID State Key Manger Type 1 be1 Deactivated DataDomain 2 49664EE855DF71CB7DC08309414C2B4C76ECB112C8D10368C37966E4E2E38A68 Activated-RW KeySecure
-
質問:キー ローテーションを無効または有効にするとどうなります
答える:
-
UIまたはCLIからキー ローテーションを有効にしない場合のデフォルトの暗号化機能は、キー ローテーション無効です。このシナリオでは、すべてのデータが既存のアクティブ キーで暗号化されます。
-
キー ローテーションが有効になっている場合は、ローテーション頻度に基づいてキーがローテーションされ、データは最新のアクティブ キーで暗号化されます。
外部キー マネージャー
質問:DDでサポートされている外部キー マネージャーは何ですか
答える:次の外部キー マネージャーをサポートしています。
-
Gemalto KeySecure(DDOSリリース7.2でサポートを追加)
-
Vormetric(DDOSリリース7.3でサポートを追加)
-
CipherTrust(DDOSリリース7.7で追加されたサポート)
-
IBM GKLM(DDOSリリース7.9で追加されたサポート)
質問:外部キー マネージャーとの統合を有効にするには、別途ライセンスが必要です
答える:はい。External Key MangerをDDと統合するには、それぞれのベンダーからの個別のライセンスが必要です
質問:一度にサポートするキー マネージャーの数はどれくらいですか
答える:DDシステム上の任意の時点でアクティブにできるキー マネージャーは1つのみです
質問:KMIP External Key Managerを構成する方法の詳細はどこで入手できます
答える: DDOS向けKMIP統合ガイドには、DDでサポートされているさまざまな外部キー マネージャーの構成に関する詳細情報が記載されています
質問:DDの外部キー マネージャーの証明書はどのように管理されます
答える:外部キー マネージャーの構成中に、CA証明書(CA証明書は自己署名証明書またはサード パーティーによる署名付き)とホスト証明書を生成する必要があります。外部キー マネージャー サーバーで構成が完了したら、ユーザーはCA証明書とホスト証明書をDDシステムにインポートする必要があります。次に、外部キー マネージャーを構成して有効にします。
質問:CAとは
答える:認証局(CA)は、ピア間で最初に信頼された共有エンティティとして機能し、署名付き証明書を発行して、各当事者が他方を信頼できるようにします。証明書は通常、サーバーまたはクライアントの ID として機能します。
質問:ローカルCA署名付き証明書とは何ですか、CA署名付き証明書とは何ですか
答える:CA署名付き証明書は、公的に信頼されている認証局(CA)によって発行および署名された証明書です。CA署名済み証明書は自動的に信頼されます。秘密署名キーはKey Managerシステム内に保存されているため、ローカルCAは署名付き証明書を発行できます。外部CAはプライベート キーを保存しません。代わりに、外部CAは、システム内のさまざまなインターフェイスとサービスの信頼できるエンティティーとして使用されます
質問:DDで証明書署名リクエストを作成する方法
答える:Data Domainシステムで、次のCLIコマンドを使用してCSRを生成します。この方法では、プライベート キーが外部キー マネージャーに公開されることはありません。
adminaccess証明書証明書署名リクエスト
質問:キー マネージャーを切り替えることはできますか
答える:外部キー マネージャーから組み込みキー マネージャーへの切り替えが許可されており、シームレスです。ただし、Embedded Key ManagerからExternal Key Managerに切り替えるには、適切な証明書のインストールと構成が必要です。2つの外部キー マネージャー間の切り替え(例: KMIP-CipherTrust、DSM-Ciphertrust、GKLMへのCipherTrustも許可されます。キー マネージャー キーの移行もサポートされています(詳細については、KMIP統合ガイドを参照してください)。
質問:外部キー マネージャーの接続がダウンした場合はどうなりますか? その場合、データにアクセスできます
答える:はい。キー マネージャーに接続できない場合でもデータにアクセスできます。これは、DDシステムにもキーのコピーを保存しているためです。外部キー マネージャーとの接続がない場合、新しいキーを作成することも、キーの状態を同期することもできません
質問:DDにキーを保存するのではなく、外部キー マネージャーにのみ保存する方法はありますか
答える:DIAの目的で、DDシステムにキーのコピーを常時保存します。この設定は変更できません
質問:KMIPとの統合によるパフォーマンスへの影響はありますか
答える:いいえ。外部キー マネージャーを使用しているため、パフォーマンスへの影響はありません。
質問:環境内の選択したData Domainに対してKMIPソリューションを活用することは可能ですか
答える:はい。お客様は、Data Domainシステムに適した暗号化方法を非常に柔軟に選択できます。一部のData DomainシステムではData Domainの組み込みキー マネージャーを引き続き活用し、環境内の他のData DomainシステムではKMIPを使用した暗号化キー ローテーションを引き続き利用できます
質問:Data DomainからKMIPへの通信は安全ですか
答える:はい。Data Domainは、X509証明書の相互認証セッションを介してTLSと通信します。ユーザーは、Data Domain CLIを使用して、適切なX509証明書をData Domainシステムにインポートできます。この証明書は、DDとKMIP間の安全なチャネルを確立するために使用されます。
キーのライフサイクル管理
質問:DD Encryptionオプションにはどのようなキー管理機能がありますか
答える:キー マネージャーは、複数の暗号化キーの生成、配布、ライフサイクル管理を制御します。保護システムでは、組み込みキー マネージャーまたはKMIP準拠の外部キー マネージャーのいずれかを使用できます。一度に有効にできるキー マネージャーは1つだけです。保護システムで暗号化が有効になっている場合、Embedded Key Managerがデフォルトで有効になります。外部キー マネージャーが構成されている場合は、それが組み込みキー マネージャーに置き換わり、手動で無効にするまで有効なままです。組み込みキー マネージャーから外部キー マネージャーに切り替えると、新しいキーがシステムに追加され、リリース7.1.
からファイル システムを再起動する必要がなくなります質問:Data Domainシステムのさまざまなキー状態は何ですか
Data Domainシステム上のさまざまなキーの状態は次のとおりです。
-
Activated-RW: DDシステム上にこの状態にあるキーは1つだけで、データの読み取りと書き込みに使用されます。このキーは、コンテナーを再暗号化するために GC プロセスでも使用されます。
-
保留中-アクティブ化済み: どのDDシステムでも、この状態のキーは1つだけです。これにより、次回のファイル システムの再起動後にActivated-RWになるキーが特定されました。現在、この状態は暗号化を有効にした時点でのみ存在します。他の時間保留でアクティブ化されたキーは作成されません。
-
Activated-RO: 外部キー マネージャーは、複数のアクティブ化されたキーを持つことができます。最新のキーはActivated-RWにあり、残りはこの状態です。キー マネージャーと状態を同期できない場合、DDシステムでキーがこの状態になることがあります。
-
非 アクティブ:これは、DDシステム上の既存のデータを読み取るために使用されます。
-
侵害:お客様が外部キー マネージャー キーを侵害した場合、状態は次回のキー同期後にそのキーに変更されます。
-
Marked-For-Destroyed: お客様がキーに破棄のマークを付けると、キーの状態はMarked-For-Destroyedになります。GCが実行されると、Marked-For-Destroyedキーで暗号化されたすべてのコンテナが、Activated-RWキーを使用して再暗号化されます。
-
滅びる:Marked-For-Destroyed状態のキーは、関連付けられているデータがない場合にこの状態になります。
-
破壊-侵害: Compromised 状態のキーは、関連付けられているデータがない場合、この状態になります。
質問:ディザスター リカバリーのために暗号化キーをエクスポートできますか
答える:キーは、次のコマンドを使用して手動でエクスポートできます。
「Filesys暗号化キーのエクスポート」
DDシステムでは、新しいキーが追加されたり、システムからキーが削除されたりした場合にも、デフォルトでキーのエクスポートも行われます。
エクスポートされたファイルは、暗号化された形式で/ddr/var/.securityに存在します。その後、このファイルをDDRからコピーし、後でディザスター リカバリーの状況で使用できる安全な場所に保存する必要があります。
注:ディザスター リカバリー用のキーをインポートするには、リカバリー プロセスが発生した災害のタイプによって異なるため、カスタマー サポートの介入が必要です。次のコマンドを使用して、エクスポートされたキーファイルをインポートできます。
Filesys暗号化キーのインポート <ファイル名>
質問:KMIPによって生成されたキーはData Domainシステムに保存されていますか
答える:はい。KMIPから取得した暗号化キーは、暗号化された方法でData Domainシステムに保存されます
質問:KMIPアプライアンスのキー状態の変更は、Data Domainシステムにどのように適用されますか
答える:キーの同期は毎日行われます。使用可能な新しいキーがある場合、またはキーの状態が変更された場合、同期によってローカル キー テーブルが更新されます。DDは、毎日深夜にKMIPから重要なアップデートを受信します。
質問:DDとKMIPの間でキーの状態を手動で同期することは可能です
答える:はい。Data Domain CLIまたはUIを使用して、DDとKMIPの間でキー状態を手動で同期できます。「filesys encryption keys sync」は、そのために使用されるコマンドです。
質問:DDがKMIPからキーのアップデートを受信する時刻を変更することはできますか
答える:いいえ。DDがKMIPからキーのアップデートを受信する時刻を変更することはできません。
質問:Data Domainシステムでサポートされているキーの数に制限はありますか
答える:DDOS 7.8以降では、Data Domainシステムのシステム上で常に最大1024個のキーを持つことができます。Activated-RWには1つのキーのみがあり、残りのキーは他の状態である可能性があります
質問:Data Domainシステム上の異なるデータセットに異なるキーを使用できますか? これは構成可能ですか
答える:いいえ。システム内で一度にサポートされるアクティブ キーは1つだけです。受信データはすべて現在のアクティブ キーを使用して暗号化されます。キーは、Mツリーのような細かい単位では制御できません。
質問:キーの上限に達したときに通知はありますか
答える:はい。キーの上限である1,024に達するとアラートが発生します
質問:キーの上限に関するアラートをクリアするには、どうすればよいですか
答える:キーの最大制限アラートをクリアするには、いずれかのキーを削除する必要があります。
質問:Data Domainシステム上の特定のキーに関連づけられているデータの量を確認できます
答える:はい。これはDDでは確認できますが、KMIPサーバーでは確認できません。ユーザーは、Data Domain CLIとUIを使用して、特定のキーに関連付けられているデータの量を確認できます
質問: DDシステム上のキーの使用年数を確認できます
答える:はい、UIを使用してEKMキーで表示できます
質問:新しいキーが有効になるまでの期間が経過しても、古いキーは機能しますか
答える:暗号化キーの有効期限はありません。古いキーは、キー ローテーション後に読み取り専用キーになり、DDOSに残ります。
質問:Data Domainシステムに関連づけられているデータがない場合、暗号化キーは自動的に削除されます
答える:いいえ、キーは自動的に削除されません。ユーザーは、DD CLIまたはUIを使用して、キーを明示的に削除する必要があります。
質問:Data Domainシステム上に関連づけられているデータがある場合でも、キーを削除できますか
答える:いいえ。キーにデータが関連づけられている場合は削除できません。データが関連づけられているキーを削除するには、他のキーを使用してデータを再暗号化する必要があります。
質問:KMIPでキーが削除された場合、そのキーはData Domainのキー リストからも削除されます
答える:いいえ。ユーザーは、DD CLIまたはUIを使用して、キーを個別に削除する必要があります。
質問:マルチサイトのData Domain環境では、すべての場所にKMIPが必要です
答える:いいえ。Data Domainを使用するすべてのサイトにKMIPを用意する必要はありません。1つのKMIPサーバーを指定できます。DDシステムが同じKMIPサーバーを使用している場合は、DDシステムごとに個別のキー クラスを設定することをお勧めします
質問:キーが侵害された場合、古いキーで暗号化されたデータを取得するプロセスはありますか
答える:この場合、お客様はKMIPサーバーでキーを侵害済みとしてマークする必要があります。次に、DDOSシステムで「filesys encryption keys sync」を実行し、「filesys encryption apply-changes」を実行してからGC (filesys clean)を実行します。GCの実行では、侵害されたキーで暗号化されたすべてのデータが、新しいキーを使用して再暗号化されます。GCが完了すると、キーの状態は[compromised-destroyed]に変更されます。後でそのキーを削除できます。
暗号化とレプリケーション
質問:DDレプリケーションはサポートされていますか?また、DD Encryptionソフトウェア オプションとの相互運用が可能です
答える:はい。DD ReplicationはDD Encryptionオプションとともに使用できます。そのため、あらゆる種類のレプリケーションを使用して暗号化されたデータをレプリケートできます。各レプリケーション形式は、暗号化に対して独自に機能し、同じレベルのセキュリティを提供します。
質問:暗号化を使用するには、ソース システムとデスティネーション システムの両方で同じバージョンのDD OSを実行している必要がありますか
答える:レプリケーション互換性マトリックス(互換性マトリックスについては管理者ガイドを参照)が設定されている場合は、ソースとデスティネーションが異なるDDOSバージョンにあっても、レプリケーションでDAREを使用できます。
質問:レプリケーションは暗号化とどのように連携しますか
答える:これは、使用されているレプリケーションの形式によって異なります
構成されたレプリケーションがMREPLまたはMFRの場合:
MREPLまたはMFRを使用する場合、お客様が達成したいことに応じて、ソースまたはデスティネーションのいずれかでDD Encryptionのライセンスを取得または有効化できます。
-
ソースとデスティネーションの両方で暗号化が有効になっている場合: ソース システムに取り込まれたデータは、ソース システムの暗号化キーで暗号化されます。ソースはローカル データを復号化し、デスティネーション システムの暗号化キーを使用して再暗号化してから、レプリケート時に暗号化されたデータをデスティネーションにレプリケートします。
-
ソースで暗号化が無効になっていて、デスティネーションで暗号化が有効になっている場合は、次のようになります。ソースに取り込まれたすべてのデータは暗号化されません(明らかな理由により)。ただし、レプリケートする場合、ソースはデスティネーション システムの暗号化キーを使用してデータを暗号化してから、暗号化されたデータをデスティネーション システムにレプリケートします。
-
ソースで暗号化が有効になっていて、デスティネーションで暗号化が無効になっている場合: ソース システムに取得されるすべてのデータは、ソース システムの暗号化キーで暗号化されます。ソースはデータを復号化し、レプリケート時に暗号化されていないデータをデスティネーションData Domainシステムにレプリケートします。
-
レプリケーション コンテキストが設定された後にレプリカで暗号化が有効になっている場合、現在レプリケートされている新しいセグメントは、レプリカのソースで暗号化されます。暗号化が有効化される前にレプリカに存在していたセグメントは、暗号化によって変更が適用され、デスティネーションでGCが実行されない限り、暗号化されていない状態のままになります。
構成済みのレプリケーションがCREPL:の場合
コレクション レプリケーションでは、ソース システムとデスティネーション システムの両方が同じDDOSリリースを実行している必要があります。したがって、暗号化は両方で有効または無効にする必要があります。暗号化設定の不整合もあってはなりません。暗号化キーは、ソースとデスティネーションで同じです。
-
ソースとデスティネーションの両方で暗号化が有効になっている場合: ソース システムに取得されるすべてのデータは、ソース システムの暗号化キーを使用して暗号化されます。レプリケート時に、ソースは暗号化されたデータを暗号化された状態でデスティネーションData Domainシステムに送信します。コレクション レプリケーションはソースData Domainシステムの正確なレプリカに関するものであるため、デスティネーションData Domainシステムはソースと同じキーを持ちます。デスティネーションは読み取り専用システムであるため、レプリケーションの外部でデスティネーションData Domainシステムにデータを書き込むことはできません。
-
ソースとデスティネーションの両方で暗号化が無効になっている場合: ソース システムに取得されるすべてのデータは暗号化されません(明らかな理由により)。レプリケートする場合、ソースは暗号化されていない状態でデータを送信(レプリケート)し、デスティネーションData Domainシステムでは暗号化されていないままになります。デスティネーションは読み取り専用システムであるため、レプリケーションの外部でデスティネーションData Domainシステムにデータを書き込むことはできません。
質問:デスティネーションのキーはソースData Domainシステムに無期限に保存されていますか
答える:デスティネーションの暗号化キーがソースData Domainシステムに保存されることはありません。レプリケーション セッションがアクティブな間のみメモリーに保持(暗号化)されます。これは、コレクション レプリケーションを除くすべての種類のレプリケーションに適用されます。コレクション レプリケーション(CREPL)では、同じ暗号化キーのセットがソースとデスティネーションに存在します。
質問:レプリケーション コンテキストの確立後にCREPLシステムで暗号化を有効にすることはできますか
答える:はい。この場合、ソースとデスティネーションの両方で暗号化を有効にする必要があります。レプリケーション コンテキストを無効化することで、ソースとデスティネーションで暗号化を有効にできます。レプリケートされた新しいセグメントは、レプリカ上で暗号化されます。暗号化が有効化される前にレプリカに存在していたセグメントは、暗号化されていない状態のままになります
質問:DD Encryptionは、DD Replicationソフトウェア オプションの有線経由の暗号化機能と同時に有効にできますか
答える:はい。ネットワーク経由の暗号化とD@REの両方を同時に有効にして、さまざまなセキュリティ目標を達成することができます
質問:DD Encryptionソフトウェア オプションとDD Replicationソフトウェア オプションの有線暗号化機能の両方を同時に有効にするとどうなりますか
答える:最初のソースは、デスティネーション暗号化キーを使用してデータを暗号化します。その後、すでに暗号化されたデータは、このデータを宛先に送信する間に、ネットワーク経由の暗号化のために2回目に暗号化されます。有線経由の復号化が完了した後、データは宛先の暗号化キーを使用して暗号化された形式で保存されます
質問:ソースとデスティネーションで暗号化が有効になっている場合、パスフレーズは両方で同じである必要がありますか
答える:構成されたレプリケーションがコレクション レプリケーション(CREPL)である場合、パスフレーズは同じである必要があります。他の種類のレプリケーション(MREPL、MFRなど)の場合、パスフレーズはソースとデスティネーションで異なる場合があります
質問:宛先で暗号化が有効になっている場合(CREPLには適用されません)、レプリケートされたデータと他のアクセスポイントからのデータ(たとえば、ローカルバックアップ経由)の両方が暗号化されますか? レプリケートされたディレクトリのみが暗号化され、他のアクセスが暗号化されないレプリカ上の2つを分離する方法はありますか
答える:いいえ。エントリー ポイントに関係なく、レプリカ(デスティネーション)ですべてのデータが暗号化されます。暗号化は、MTreeまたはディレクトリー レベルの単位でのみ有効または無効にすることはできません。
質問:MREPLまたはMFRの実行中に、ソースとデスティネーションの間でキーを交換する方法は
答える:レプリケーションの関連づけフェーズでは、ターゲット マシンは現在の暗号化アルゴリズムとキー情報をソースに安全に転送します。レプリケーション コンテキストは、常に共有シークレットで認証されます。この共有秘密は、Diffie-Hellman キー交換プロトコルを使用して「セッション」キーを確立するために使用されます。このセッション キーは、Data Domainシステム暗号化キーの暗号化と復号化に使用されます。
質問:レプリケーション トラフィックの暗号化に関して、Data Domainの「ネットワーク経由の暗号化」機能に使用される暗号化アルゴリズムのタイプは何ですか
答える:レプリケーション認証モードが「one-way」または「two-way」に設定されている場合、DHE(Ephemeral Diffie-Hellman)がセッション キーの交換に使用されます。サーバー認証はRSAを使用して行われます。AES 256ビットGCM暗号は、ネットワーク経由でレプリケートされたデータをカプセル化するために使用されます。暗号化カプセル化層は、デスティネーション システムに格納されるとただちに削除されます。
一方向は、宛先の証明書のみが認定されていることを示します。2つの方法は、ソース証明書と宛先証明書の両方が検証されていることを示します。認証モードを使用する前に相互信頼が確立されている必要があります。また、暗号化を続行するには、接続の両側でこの機能を有効にする必要があります。
レプリケーション認証モードが「anonymous」に設定されている場合、セッション キー交換にはAnonymous Diffie-Hellman(ADH)が使用されますが、この場合、ソースとデスティネーションはキー交換前に相互に認証されません。また、authentication-mode が指定されていない場合は、anonymous がデフォルトとして使用されます
質問:ファイル システムを再起動しないキー ローテーションは、すべての種類のレプリケーションで動作します
答える:ファイル システムの再起動なしのキー ローテーションは、DREPL (DREPL のサポートはすでに終了しています) と差分レプリケーション (LBO とも呼ばれます) を除くあらゆる種類のレプリケーションで機能します
質問: 証明書または PKI キー ペアがない場合、宛先の暗号化キーは、キー交換中にどのように保護されます
答える:すべてのData Domainレプリケーション ペア間には、Diffie-Hellmanキー交換を使用した共有セッション キーの確立に使用される共有シークレットがあります。その共有キーは、宛先の暗号化キーの暗号化に使用されます。
レプリケーション認証に使用される共有シークレットと、Diffie-Hellmanキー交換プロトコルを使用して割り当てられる共有セッション キーには違いがあります。レプリケーション認証に使用される共有シークレットは、2つのData Domainシステムが初めてレプリケーション コンテキストを確立するときに、Data Domainソフトウェアによって確立されます。また、コードに埋め込まれたパラメーターを使用して交換される Diffie-Hellman によっても合意されます。これはシステムに永続的に格納され、2つのシステム間のすべてのレプリケーション セッションが認証されます。レプリケーション セッション キー(デスティネーションの暗号化キーの暗号化に使用されるキー)は、以前に確立された共有シークレットとの別のDiffie-Hellman交換を使用して確立され、セキュア キー交換プロトコルが駆動されます。このキーは永続的ではなく、レプリケーション コンテキストがアクティブな間のみ存在します
質問:レプリケーション ペアの両方のData Domainで同じ外部キー マネージャー(KMIPキー マネージャーなど)ソリューションを使用する必要がありますか、それとも一方のシステムで外部キー マネージャーを使用し、もう一方のシステムで組み込みキー マネージャーを使用できますか
答える:コレクション レプリケーション ペアを除き、レプリケーション ペア内の両方のシステムで同じキー マネージャーを使用する必要はありません。
コレクション レプリケーションでは、両方のData Domainシステムを同じキー マネージャーで構成する必要があります。ただし、この場合も、唯一のソースはキー マネージャーとのキーの同期であり、それらのキーは宛先にも送信されます。他のレプリケーション タイプでは、ソースとデスティネーションで異なるキー マネージャーを使用できます。
暗号化と移行
質問:暗号化が有効になっているシステムでは、データ移行はサポートされていますか
答える:はい。データ移行は、暗号化が有効になっているシステムでサポートされています。データ移行を開始する前に、前提条件としてソース システムとデスティネーション システムの暗号化設定を一致させる必要があります。また、移行を開始する前に、DIAの目的でソース システム上の暗号化キーをエクスポートしてバックアップしておくことをお勧めします
質問:データ移行は、暗号化が有効なシステムのアクティブ階層とクラウド階層の両方の移行でサポートされていますか
答える:はい。データ移行は、暗号化対応システムのアクティブ階層とクラウド階層の両方の移行でサポートされています。チェックされた前提条件属性のリストは、暗号化が有効になっている階層に基づいて適用されます
質問:移行の一環として保持される暗号化設定はどれですか
答える:暗号化されたデータと暗号化キーはそのまま移行されますが、データ移行を成功させるには、暗号化キー マネージャー、システム パスフレーズ、その他の暗号化構成などの設定を手動で検証し、一致させる必要があります。既存のキーマネージャー証明書もデスティネーション システムに転送されます。移行後に、デスティネーション システムで暗号化キーマネージャーの構成を再度設定する必要があります。
質問:移行中にソースとデスティネーションの間でどのような暗号化互換性チェックが行われますか
答える:システム パスフレーズ、暗号化ステータス、キー マネージャー構成の詳細、システムのFIPSモード設定は、移行を成功させるためにソース システムとデスティネーション システムで同一にする必要がある暗号化設定の一部です。このKB記事183040「Data Domain: クラウド対応DDシステムの移行手順(記事を表示するにはDellサポートへのログインが必要)では、クラウドが有効なシステム間の移行手順について詳しく説明しています。アクティブ階層のみの移行にも同じ設定が適用されます。
質問:[Encryption Disablement Project]設定がオンになっているシステム間での移行はサポートされていますか
答える:両方がEDPであるか、両方が非EDPである場合、2つのシステム間でのデータ移行がサポートされます。ネットワーク上の暗号化が明示的にオフになっている場合、EDPシステムから非EDPシステムへのデータ移行は許可されます。(MIGRATION_ENCRYPTION sysparamを使用)
クラウド階層での暗号化
質問:クラウド階層で暗号化はサポートされていますか
答える:はい、クラウド階層では暗号化がサポートされています。デフォルトでは、クラウド階層での暗号化は無効になっています。「cloud enable」コマンド プロンプトが表示され、クラウド階層で暗号化を有効にするかどうかを選択できます。
質問:KMIPと外部キー マネージャーはクラウド階層でサポートされていますか
答える:はい。KMIPと外部キー マネージャーは、DDOS 7.8以降のクラウド階層でサポートされています。
質問:クラウドで暗号化を有効にできる粒度はどれくらいですか
答える:暗号化は、各クラウド ユニットと各階層で個別に有効または無効にすることができます
質問:クラウド ユニットには独立したキーがありますか
答える:いいえ。キー管理は、DDのアクティブ階層とクラウド階層の両方で共通です。暗号化が有効になっている場合、キーはそれぞれのユニット/階層/CPにコピーされます。クラウドではなくアクティブで暗号化が有効になっている場合、アクティブ階層のキーはクラウドには反映されず、その逆も同様です。これはクラウド ユニットにも適用されます。(たとえば、CP1 で暗号化が有効になっていて、CP2 で暗号化が有効になっていない場合、CP1 キーは CP2 に反映されません。
質問:クラウドでキーを削除できますか
答える:いいえ、クラウドからのキーの削除はサポートされていません。
質問:クラウド ユニットのデータ暗号化キーはどこで管理されますか
答える:キーはcpに関連づけられており、各クラウド ユニットは異なるcpです。すべての cps からの鍵のコピーは、アクティブな cp に保存されます。
質問:ディザスター リカバリー中にクラウド キーをリカバリーする方法を教えてください。
回答:cpnamevalはCPリカバリーの一部としてクラウドにミラーリングされ、暗号化キーはcpnamevalにリカバリーされます。次に、ddr_key_utilツールを実行してキーを回復する必要があります。
注:ディザスター リカバリーにはカスタマー サポートの介入が必要です。
質問:クラウド階層でのみ暗号化が有効になっている場合に、データ移動を実行できます
答える:いいえ。データ移動のために、クラウド階層とアクティブ階層の両方で暗号化を有効にする必要があります
質問:クラウド階層で外部キーマネージャーを有効にすることはできますか
答える:はい、クラウド階層で外部キー マネージャーを有効にすることができます。この機能は7.8以降でサポートされています。アクティブ階層で有効なキーの破棄または削除を除くすべての操作は、外部キー マネージャーの観点からクラウド階層でも有効です。
暗号化とガベージ コレクション
質問:静止データの暗号化では、グローバル クリーニング プロセスはどのような役割を果たしますか。また、暗号化を初めて有効にする際にパフォーマンス インパクトはありますか
答える:静止データの暗号化を初めて有効にすると、グローバル クリーニングのパフォーマンスに影響します。これは、ディスク上の既存のコンテナーから読み取り、新しいコンテナーに書き込む必要があるデータは、再圧縮、暗号化、ディスクへの書き戻しを行う前に、読み取り、暗号化、および展開する必要があるためです。大量の既存データを保持しているDDで暗号化が有効化されている場合に、「filesys encryption apply-changes」コマンドが実行されると、後続のグローバル クリーニング サイクルで、システム上の既存データはすべて暗号化されます。つまり、すべてのデータを読み取り、展開、圧縮、暗号化し、ディスクに書き込む必要があります。その結果、「filesys encryption apply-changes」実行後の最初のグローバル クリーニング サイクルに通常よりも時間がかかる場合があります。お客様は、DDシステムがいっぱいにならずにクリーニングを完了できるように、DDシステムに十分な空き容量があることを確認する必要があります(そうしないとバックアップが失敗します)。
質問:進行中の取得/リストアのクリーン サイクルにパフォーマンス インパクトはありますか
答える:はい。パフォーマンスへの影響はあります。その影響は通常、クリーニング サイクルの間に取得/リストアされるデータの量によって異なります
質問:既存のデータの暗号化にはどのくらいの時間がかかりますか
時間を見積もるには、次のKB記事を参照してください。Data Domain: 保存データ暗号化の適用に要する時間を計算します。
暗号化とヘッドスワップ
質問:暗号化が有効になっているときにヘッドに障害が発生した場合、お客様はディスクを別のData Domainシステムに移動し、ディスクにアクセスできますか
答える:暗号化キーはData Domainシステム ヘッド自体に関連付けられていないため、ディスクを別のData Domainシステム ヘッドに移動して、そこでキーにアクセスできます。新しいData Domainシステム ヘッドでは、ファイル システムがロックされているため、「filesys encryption unlock」コマンドでパスフレーズを入力する必要があります。
質問:お客様がヘッドスワップ操作時にパスフレーズを忘れた場合はどうなります
答える:その間、古いヘッドを接続し、サポートと連携してパスフレーズをリセットしてから、新しいヘッドに接続し直してヘッドスワップ手順を完了できます。
暗号化のパフォーマンス
質問:暗号化の使用時にストレージ消費量にどのような影響が見られますか
答える:ユーザー データを含む一部の暗号化パラメーターの保存に関連するオーバーヘッドが約1%であるため、ごくわずかです
質問:静止データ暗号化を使用すると、スループット(書き込みと読み取り)にどのような影響が観察されますか
答える:暗号化を使用する場合の取り込みスループットへの影響は、プロトコルとプラットフォームによって異なります。一般に、総スループットでは控えめなパフォーマンスの低下が、次の割合で示されます。
CBCモード
最初のフル: 書き込み時に~10%のパフォーマンス低下
増分: 書き込み時に~5%のパフォーマンス低下
リストア: READs
GCMモードで5〜20%のパフォーマンス低下
最初のフル: 書き込み時に10 - 20%のパフォーマンス低下
増分: 書き込み時に5 -10%のパフォーマンス低下
リストア: 5 - 20% READsのパフォーマンス低下
これらの数値は、静止データ暗号化のオーバーヘッドに固有のものです(ネットワーク経由の暗号化は個別に計上されます)
おすすめの方法
質問:キー ローテーション ポリシーに関するベスト プラクティスは何ですか
答える:自動キー ローテーション ポリシーはデフォルトでは有効になっていません。お客様が有効にしました。暗号化キーは頻繁にローテーションすることをお勧めします。外部KMIPキー マネージャーを使用してシステムを構成する場合は、今後キーが侵害された場合に対処できるように、キーを頻繁にローテーションすることをお勧めします。KMIPがクラウド階層で構成されている場合、推奨されるキー ローテーション間隔は1週間です。KMIPがアクティブ階層のみで構成されている場合、推奨されるキー ローテーション ポリシーは1か月です。ただし、取得レートに基づいて、お客様はキー ローテーションの頻度を増減することもできます。組み込みキー マネージャーが構成されている場合は、1〜3か月のキー ローテーション ポリシーが推奨されます。
質問:お客様が複数のDDシステムで同じKMIPサーバーを使用している場合、KMIPキー クラスのベスト プラクティスは何ですか
答える:同じKMIPサーバーを使用している場合は、DDシステムごとに個別のキー クラスを設定することをお勧めします。これにより、1つのDDOSシステムで行われたキー ローテーションは、他のDDOSシステムに存在するキーの状態に影響を与えません。
Additional Information
詳細については、ドキュメント「Dell EMC PowerProtect DDシリーズ アプライアンス: 暗号化ソフトウェア(delltechnologies.com)
暗号化:テクニカル ホワイト ペーパーPowerProtect DDシリーズ アプライアンス: 暗号化ソフトウェア
DD Encryptionに関連するその他のドキュメント(管理者ガイド、コマンド リファレンス ガイド、セキュリティ構成ガイド)については、記事126375、PowerProtectおよびData Domainのコア ドキュメントを参照してください。
KMIP統合ガイドと互換性マトリックス
このビデオをご覧ください。