web-dev-qa-db-ja.com

https Webサーバーの起動後に秘密鍵を削除することでセキュリティ上の利点はありますか?

HTTPS経由でページを提供するWebサーバーがあるとします。プロセスの実行開始後、秘密鍵を削除した場合、サーバーが侵害された場合の秘密鍵の回復が妨げられますか?攻撃者が特権アクセスを取得したとすると、メモリスクレーパーは秘密鍵を回復できませんか?

この設計は、隠すことによるセキュリティの悪い例にすぎませんか?

2
Python Novice

それだけの価値はありません。

私はその質問が意味することを理解しています: "秘密鍵をRAMのみに保存する場合、これはセキュリティに役立ちますか?"

多分。しかし、これは展開の地獄を綴ります。

この状況は、再起動のために物理的に存在しなければならないサーバーに似ていると思います。ブートパスワードと同じように。これは非常に実用的ではありません。このモデルから得られるのは、オフライン攻撃に対する耐性です。誰かがサーバーを持って立ち去ったようなものです。サーバーの物理的なセキュリティを本当に信頼していない場合は、実際にこれを防御することをお勧めします。しかし、オフライン攻撃から防御するためのより伝統的な方法は、フルディスク暗号化です。

抽出できない秘密鍵が必要な場合は、 [〜#〜] hsm [〜#〜] の購入を検討する必要があります。 (私が知っている最も安いものは $ 500 YubiHSM です。)または、何らかの方法でキーをオフサーバーに保存します CloudFlareKeyless SSL動作します

これらのソリューションの利点は、オンライン攻撃も機能しなくなることです。 RAMから秘密鍵を抽出することもできなくなりました。(そして、AFAIK秘密鍵はRAM haystackで見つけやすい針の1つです。すでにボックスにルートがあります。 リンク:ErrataSecリンク:HeartLeechリンク:SecSe 。)

3
StackzOfZtuff

あなたは2つのタイプのセキュリティについて話している:

  1. 利用可能な秘密鍵に依存するSSL接続の機密性と
  2. 秘密鍵が脆弱になる前に危険にさらされるシステムの整合性。

クライアントとWebサーバー間で確立されるSSL接続は、セッションキー交換を完了できるように、使用可能な秘密キーに依存します。

攻撃者がシステムにアクセスして昇格された特権を取得した場合は、ファイルシステムの秘密鍵が簡単に機能することを確認してください。ただし、スーパーユーザーはすべてのシステムメモリでMMAP_PHYSを実行し、少し手間をかけて鍵をスキャンすることもできます。

したがって、いいえ、秘密鍵を削除しても、停電や再起動などが発生した場合を除いて、(メモリからの)秘密鍵の回復が妨げられることはありません。基本的に、システムリソース(キー)を侵入者から保護するために、システムの整合性を保証する必要があります。

この設計は、隠すことによるセキュリティの悪い例にすぎませんか?

いいえ、隠すことによるセキュリティではありません。 SSLは、適切な暗号化の概念に基づいています。多層防御では、秘密鍵(読み取り:システムの整合性)を、強制アクセス制御などの他のセキュリティ層で保護する必要があります。

1
Whome