文書番号: 000019875
質問：DD
での暗号化(DARE)の構成方法答え：DARE暗号化は、次の手順でDDに構成できます。
暗号化ライセンスの追加
セキュリティ担当者を追加し、セキュリティ担当者権限権限を有効にする
暗号化の有効化
1)暗号化ライセンスの追加:
有効な暗号化ライセンスが追加されたライセンス ファイルを用意します。
次のコマンドを使用し、使用可能なライセンス ファイルを使用してDDのeライセンスをアップデートします。
eライセンス アップデート
2)セキュリティ担当者を追加し、SO認証を有効にします。a)次のコマンドを使用して、「セキュリティ」としての役割を持つユーザーを追加します。
ユーザーによる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以降で追加されました。
質問：データの選択的暗号化は可能ですか? 1つのMTreeまたはファイルのみをご希望ですか?
答え：選択的暗号化はできません。暗号化はシステム全体でのみ有効または無効にすることができ、選択的に有効または無効にすることはできません。クラウド サポートを備えたシステムでは、クラウド階層とクラウド ユニットの単位で暗号化を有効または無効にすることができます。
質問：暗号化キーまたはアカウント パスワードは、エンティティが認証を行うとき、データ ファイル、プログラム、または認証ディレクトリーで、クリア テキストまたは脆弱な暗号で送信または保存されていますか?
答え：絶対にだめです。
質問：システムで使用されているOpenSSLのバージョンは何ですか?
答え：DDOS 7.10リリースの時点で、opensslバージョンは「OpenSSL 1.0.2zd-fips」
です。質問: 静止データ暗号化は、ユーザーやアプリケーションからのデータ アクセスからどのように保護しますか?
答え：
質問：重複排除後に暗号化が行われますか?
答え：はい、暗号化は重複排除されたデータで行われます。データは、ディスクに保存される前に暗号化されます。
質問：Data Domainはどのようにしてデータのセキュリティを確保しますか?
答え：データは、静止データ暗号化機能を使用して保護されます。さらに、デバイスが削除されると(ヘッドスワップ、ファイル システム ロック)、パスフレーズはシステムから削除されます。このパスフレーズは暗号化キーの暗号化に使用されるため、データはさらに保護されます。
質問：暗号化によってどのようなアラートが生成されますか?
答え：アラートは、次の場合に生成されます。
質問：DDOSのセキュリティ認定はありますか?
回答：Data DomainシステムはFIPS 140-2に準拠しています。
質問：暗号化キーはどこに保存されますか?
答え：暗号化キーは、DDOSシステムのコレクション パーティションに永続的に保存されます。
質問：誰かがData Domainシステムからハード ドライブを取り出した場合、データを復号化できますか?
答え：暗号化キーは、システム ヘッドに格納されているシステム パスフレーズを使用して暗号化されます。暗号化キーはディスクに保存されていますが、システム パスフレーズがないと暗号化キーを復号化できません。したがって、データの暗号化に使用されるキーがわからない場合、ハードドライブから復号化することはできません。
質問：リカバリー、特にディザスター リカバリーにはどのような暗号化キーとパスワードが必要ですか?
答え：キーは安全なファイルにエクスポートし、システムの外部に保持することができます。このファイルのリカバリは、エンジニアリングの助けを借りて行われます。また、リカバリー時に、お客様はkeys exportコマンドの実行時に使用したパスフレーズを知っている必要があります。
質問：システムをリモート サイトに移動する前にファイル システムをロックする方法。
答え：以下はその手順です。
ファイル システムを無効化します。
sysadmin@itrdc-DD630-42# filesys無効化
ファイル システムをロックし、新しいパスフレーズを入力します(これには、上記のセキュリティ ユーザーによる認証が必要です)。
sysadmin@itrdc-DD630-42# filesys encryption lock
このコマンドには、「セキュリティ」ロールを持つユーザーによる許可が必要です。
Please present credentials for such a user below.
ユーザー名:secuser
パスワード:
現在のパスフレーズを入力します。
新しいパスフレーズを入力:
新しいパスフレーズの再入力:
パスフレーズが一致しました。
これで、ファイル システムがロックされました。
新しいパスフレーズを紛失したり忘れたり しないでください 。このパスフレーズがないと、ファイル システムのロックを解除できません。つまり、DDR上のデータにアクセスできません。リモートの場所に到達したときにシステムのロックを解除するには、次のコマンドを使用します。
sysadmin@itrdc-DD630-42# Filesys暗号化アンロック
このコマンドには、「セキュリティ」ロールを持つユーザーによる許可が必要です。
該当するユーザーの認証情報を以下に提示してください。
Username:secuser
Password:Enter the passphrase:
パスフレーズが検証されました。ファイルシステムを起動するには、「filesys enable」を使用します。
これで、ファイル システムを通常どおりに有効化して使用できるようになりました
質問：storage sanitizeコマンドはファイル システムの暗号化と何らかの関係がありますか?
答え：いいえ。ファイル システムの暗号化とストレージのサニタイズは、2つの独立した機能です。
質問：EDP(暗号化無効化プロジェクト)システムでネットワーク経由の暗号化はサポートされていますか?
答え：EDPシステムでは、静止データ暗号化(DARE)またはワイヤ経由の暗号化(レプリケーションまたはddboostを使用)を有効にすることはできません。
質問：システム パスフレーズとは何ですか?
答え：DDOSには、システム レベルのパスフレーズを設定することで、システム内の認証情報を保護するためのプロビジョニングがあります。パスフレーズは、マシンで使用可能なAES 256暗号化キーを生成するために使用されるスマートカードのような、人間が判読できる(理解できる)キーです。
これには、次の 2 つの利点があります。
パスフレーズは、Data Domainストレージ システムの非表示の部分に内部的に保存されます。これにより、Data Domainシステムが起動し、管理者が介入することなくデータ アクセスのサービスを継続できます。
パスフレーズの作成または変更:
質問：パスフレーズはいつ使用されますか?
答え：システム パスフレーズは、ファイル システム暗号化、クラウド アクセス、証明書管理、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」を使用すると、これを変更し、パスフレーズをディスクに保存しないようにすることができます。
最上位レベルのコマンド:
system# filesys encryption embedded-key-manager <オプション>
質問：Embedded Key Managerでは、キー ローテーションはサポートされていますか?
答え： はい。Data Domainシステムごとのキー ローテーションは、Embedded Key Managerでサポートされています。管理者はUIまたはCLIを使用して、キー ローテーション期間(週次または月次)を設定できます。
質問：埋め込み型キー管理機能は有料ですか?
答え：この機能は無料です。この機能は、標準のDD Encryptionソフトウェア ライセンス オプションの一部として含まれています。
質問：お客様はローカル キー管理から外部キー管理(EKM)に移行できますか?
答え
Key-ID Key MUID State Key Manger Type 1 be1 Deactivated DataDomain 2 49664EE855DF71CB7DC08309414C2B4C76ECB112C8D10368C37966E4E2E38A68 Activated-RW KeySecure
質問：キー ローテーションを無効または有効にするとどうなりますか?
答え：
質問：DDでサポートされている外部キー マネージャーは何ですか?
答え：次の外部キー マネージャーをサポートしています。
質問：外部キー マネージャーとの統合を有効にするには、別途ライセンスが必要ですか?
答え：はい。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がデフォルトで有効になります。外部キー マネージャーが構成されている場合は、それが組み込みキー マネージャーに置き換わり、手動で無効にするまで有効なままです。Embedded Key ManagerからExternal Key Managerに切り替えると、新しいキーがシステムに追加され、リリース7.1からファイル システムを再起動する必要がなくなります。
質問：Data Domainシステムのさまざまなキー状態はどのようなものですか?
Data Domainシステム上のさまざまなキーの状態は次のとおりです。
質問：ディザスター リカバリーのために暗号化キーをエクスポートできますか?
答え：キーは、次のコマンドを使用して手動でエクスポートできます。
「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サーバーを指定できます。同じ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のライセンスを取得または有効化できます。
構成されたレプリケーションがCREPLの場合:
コレクション レプリケーションでは、ソース システムとデスティネーション システムの両方が同じDDOSリリースを実行している必要があります。したがって、暗号化は両方で有効または無効にする必要があります。暗号化設定の不整合もあってはなりません。暗号化キーは、ソースとデスティネーションで同じです。
質問：デスティネーションのキーはソース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 Mode
First Full: 書き込み
時の~10%のパフォーマンス低下 増分: 書き込みリストアで~5%のパフォーマンス低下:
5 - 20% READs
のパフォーマンス低下 GCMモード
の最初のフル: 書き込み
時の10 - 20%のパフォーマンス低下 増分: 書き込みリストアで5 -10%のパフォーマンス低下:
5 - 20% READsのパフォーマンス低下
これらの数値は、静止データ暗号化のオーバーヘッドに固有のものです(ネットワーク経由の暗号化は個別に計上されます)
質問：キー ローテーション ポリシーに関するベスト プラクティスは何ですか?
答え：自動キー ローテーション ポリシーはデフォルトでは有効になっていません。お客様が有効にしました。暗号化キーは頻繁にローテーションすることをお勧めします。外部KMIPキー マネージャーを使用してシステムを構成する場合は、今後キーが侵害された場合に対処できるように、キーを頻繁にローテーションすることをお勧めします。KMIPがクラウド階層で構成されている場合、推奨されるキー ローテーション間隔は1週間です。KMIPがアクティブ階層のみで構成されている場合、推奨されるキー ローテーション ポリシーは1か月です。ただし、取得レートに基づいて、お客様はキー ローテーションの頻度を増減することもできます。組み込みキー マネージャーが構成されている場合は、1〜3か月のキー ローテーション ポリシーが推奨されます。
質問：お客様が複数のDDシステムで同じKMIPサーバーを使用している場合、KMIPキー クラスのベスト プラクティスは何ですか?
答え：同じKMIPサーバーを使用している場合は、DDシステムごとに個別のキー クラスを設定することをお勧めします。これにより、1つのDDOSシステムで行われたキー ローテーションは、他のDDOSシステムに存在するキーの状態に影響を与えません。
詳細については、ドキュメント「Dell EMC PowerProtect DDシリーズ アプライアンス: 暗号化ソフトウェア(delltechnologies.com)
暗号化：テクニカル ホワイト ペーパーPowerProtect DDシリーズ アプライアンス: 暗号化ソフトウェア
DD Encryptionに関連するその他のドキュメント(管理者ガイド、コマンド リファレンス ガイド、セキュリティ構成ガイド)については、記事126375、PowerProtectおよびData Domainのコア ドキュメントを参照してください。
KMIP統合ガイドと互換性マトリックス
このビデオをご覧ください。
Data Domain, Data Domain
Data Domain, Data Domain Encryption
21 2月 2024
10
How To