暗号化されたオフサイトバックアップ-暗号化キーを保存する場所


16

定期的なオンサイトバックアップ(耐火金庫に保管)に加えて、AESで暗号化されたテープを月に一度オフサイトに送信します。したがって、ある日、エイリアンの熱線によって気化した場合、少なくとも1つの最近のバックアップから回復する必要があります。

128ビットの暗号化キーはオンサイトでのみ保存されることを除きます。したがって、真の災害の場合、実際には1つの暗号化されたバックアップが残され、それを復号化する方法はありません

質問:暗号化キーをオフサイトに保存するための最良のポリシーは何ですか?

どの方法を選択してもセキュリティ監査に合格する必要があるため、「自宅にコピーを保管する」ことは適切ではなく、「オフサイトテープに保管する」ことは、そもそもそれらを暗号化する目的に反します。検討中のオプションには、次のものがあります。

  • 銀行のセーフティボックス
  • パスワードで保護された形式でクラウドまたは地理的に離れたネットワークに保存されます(たとえば、KeepassやPassword Safeなどのソフトウェアを使用)

もちろん、2番目のオプションには別の疑問があります。そのパスワードをどのように安全に保つです。


3
キーにアクセスできるユーザーは何人ですか?そして、それ自体で、または全員/数人が関与することを要求しますか?たとえば、キー分割システムがあります。5人が鍵の一部を持ち帰り(それ自体では役に立たない)、鍵の5つの部分のうち3つで鍵を再構築できます。リンクはありませんが、後で調べるかもしれません。
グラント

暗号化されたデータにキーを保存します。キーを取得するには、キーを知っている必要があります。
カズ

3
秘密のRSAキーを非常に安全な場所生成して保存し、対応するRSA公開キーをバックアップシステムに配置します。バックアップを行うときは、ランダムなAESキーを生成し、RSA公開キーで暗号化し、暗号化されたAESキーバックアップと共に保存します。
デビッドシュワルツ

回答:


13

これは非常に主観的です。適切なアドバイスを提供するには、業界と特定の規制要件について詳しく知る必要があると思います。規制されていない業界の小企業にとって十分かもしれないものは、規制された業界の大企業ではおそらく機能しません。

銀行がボックスへのアクセス権を持つ当事者を認証することになっているため(通常、許可された当事者のリストに対して写真IDを使用)、鍵をセーフティボックスに保管するだけで十分な場合があります。箱を開けるのに必要な物理キーもあります。これらの属性と物理的に安全な場所に保管されているボックスを組み合わせると、キーを保管するのに適した場所のように見えます。個人的には、私はテープが紛失/盗難されて、セーフティボックスに出入りするのではなく、セーフティボックス自体から盗まれるのではないかと心配しています。別の方法として、鍵データを保存するためだけに名前が付けられたさまざまな許可された関係者がいる別の銀行にセーフティボックスを取得することもできます。

あなたが社内の弁護士を持っていないと仮定すると、企業の顧問に鍵を保管してもらいたいかもしれません。

オタクで技術的になるために、秘密鍵をいくつかの部分に分割できるさまざまなアルゴリズムがあり、秘密を再構築するために必要な数の関係者の協力が必要です(しきい値スキームと呼ばれます)。私はこれらのスキームの実用的な実装をすぐには知りませんが、あなたが十分に検索すればそこにあると確信しています。鍵マテリアルを複数のパーティに配布して、それらの一部が集まって鍵を再構築できるようにすることができます。キーの個々の部分(またはしきい値が必要とするよりも少ない数)の侵害は、キーの侵害を引き起こしません。

編集:

クイック検索は上がってsharesecretを、GPLにしきい値スキームの実装を。


しきい値スキームは、優れた技術的特性を持っているように聞こえますが、キー管理もかなり複雑になります。私たちは比較的小さな組織であり、人々は行き来します。そのため、私はもっと「設定して忘れる」ソリューションを探しています。
トッドオーウェン

2
弁護士を雇うというアイデアは、私にとって好ましい音をキープします。記録のために、業界はヘルスケアであり、私たちの懸念はクライアントのプライバシーを保護することです。
トッドオーウェン

4

かなり明白な解決策の1つは、キーのコピーを別のオフサイトの場所に保管することです。例:銀行の預金ボックスまたは完全に独立した別のオフサイト保管会社。

要件の厳格さによっては、キーを会社の取締役、弁護士、会計士に任せることが適切な場合があります。


4

実用的なソリューション:

USBドライブで4096ビットのプライベートsshキーを生成します。次に、truecryptを使用して高度に暗号化されたファイルコンテナを作成し、sshキーを「キーファイル」として使用します。つまり、暗号化されたドライブはsshキーファイルでロック解除されます。ファイルコンテナをパーティションのようにマウントし、その上にファイルシステム(mkfs.ext4など)を作成します。パーティションをマウントし、アーカイブするパスワードファイルを書き込みます。すべてのマウントを解除し、USBキーとアーカイブテープを送信します。作成したファイルコンテナは、(かなり安全に)オペレーションドロップボックスアカウント、フロッピーディスク(だれが真剣に見ますか)などに入れることができます。基本的に、キーファイルがないと、バックアップにアクセスできません。 、オフサイトに保存されたキーファイルは、保存する暗号化されたパーティションなしでは役に立ちません...どこでも。

これは複雑な解決策のように聞こえるかもしれませんが、おそらく正しい方向を示してくれるでしょう。または、暗号化されたフラッシュドライブで十分な場合があります。

https://www.ironkey.com/

http://www.pcworld.com/article/254816/the_best_encrypted_flash_drives.html

どのソリューションを使用する場合でも、最も重要なことは非常に明確で、何をすべきかについての現在の指示です。たとえば、同じ日にエイリアンゾンビがバスにぶつかった場合、オフィスを破壊しました。バックアップに付随する「災害の場合」のパケットのような単純なもので十分です。


0

私は大規模な組織で働いており、証明書サーバーのバックアップを暗号化するための同様のシステムがあります。使用するキー、共有IDなどのキーフレーズを保護する独立した独自の社内システムがあります。

システムは、ユーザーID、インシデント番号、理由などを使用してキーのパスワードを「チェックアウト」する必要があります。使用が完了したら、再度チェックインする必要があります。24時間後にチェックインしない場合システムは自動的にチェックインし、チェックインしていないマネージャーなどにメールを送信します。

パスフレーズなどをチェックアウトしている間は誰もパスフレーズなどを取得できず、チェックアウトを行うときに追加のチャレンジ/レスポンスがあります。システムは完全に異なる場所に収容されています。

大規模な組織であるため、それは価値のある費用でしたが、同様の活動を行うことができる製品があるかもしれません。


-1

このスレッドでセーフティボックス、弁護士、その他の複雑な方法を使用したのはすごいことです。すべて完全に不要です。

秘密鍵は基本的に小さなテキストファイルに含めることができますか?したがって、SpiderOakアカウントを設定し、ファイルをクラウドに同期します。次に、火災によりサイト全体が失われた場合、他のオフサイトの場所からバックアップストレージテープを取得し、SpiderOak Webサイトからログインして秘密キーファイルをダウンロードします。SpiderOak Webサイトにログインするために必要なのは、ユーザー名とパスワードだけです。そのため、おそらくあなたと組織内の他の誰かがそのことを頭の中で覚えているでしょう。お気に入りの2つの映画などの名前を選択します。覚えにくい。

SpiderOakは、データにアクセスするためにユーザー名とパスワードのみを必要とするため、優れています。また、高度に暗号化されています。また、暗号化/復号化キーを保存せず、データが何であるかを知らず、アカウント内のデータにアクセスできないため、DropBoxよりも安全です。ただし、DropBoxは従業員または米国政府が令状でデータにアクセスできるようになっています。DropBoxを使用する場合は、KeyPassファイル内にキーを配置し、それにアクセスするためのパスワードを覚えておく必要があります。

結局のところ、それはキーが入ったシンプルなテキストファイルです。SpiderOakまたはDropBoxのいずれかでそのキーにアクセスする他の人は、キーの目的、ロック解除の内容、または物理バックアップの場所さえもまったく知りません。だから、たとえ彼らがそれを手に入れたとしても、彼らにとっては実質的に役に立たない。


この答えが嫌い
nsij22

SpiderOakの機能と高度な暗号化標準の説明は正確かもしれませんが、暗号化されていない秘密キーを外部サーバーに保存することはありません。
ラファエルブガジュスキー
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.