私たちのウェブサイトのSSLキーを秘密にする方法は?


12

私たちのウェブサイトのSSLキーを秘密にしておきたい。これは2つのUSBスティックに保管され、1つはセーフティボックスに、もう1つは安全に保管します。そして、完全に安全であるようにWebサーバーに適用するのは私だけです。

を除く...

少なくともIISでは、キーをエクスポートできます。そのため、管理者であれば誰でもキーのコピーを取得できます。これを回避する方法はありますか?または、定義上、すべての管理者はすべてのキーにフルアクセスできますか?

更新: 完全に信頼できるシステム管理者がいます。これにつながったのは、そのうちの1人が辞めたことです(彼らは私たちの会社に1時間通勤し、新しい会社に5分通勤しました)。私はこの個人を信頼していますが、誰かが去ったときにActive Directoryアカウントを無効にするのと同じように、SSLを使用できないように保証する方法が必要だと考えました。

そして、私が最も簡単だったのは、それを持っているのが私だけだということです。私たちの証明書は1月に期限切れになるため、これが可能であればプラクティスを変更するときでした。答えに基づいて、私たちはできないように見えます。

したがって、これは新しい質問につながります-証明書にアクセスできる人が去ったとき、新しい証明書を取得して既存の証明書を取り消すのが標準的な方法ですか?または、去った人が信頼できる場合、私たちは持っている証明書を続けますか?


5
使用しているサーバーでエクスポートできない場合でも、メモリ内にある必要があるため、抽出できます。私が見る唯一のオプションは、スマートカードのようにハードウェア暗号化モジュールを使用することです。キーを持つキーは3つだけですが、マシンに物理的にアクセスできる人は誰でもそれを盗むことができます。盗まれた場合でも、それを取り消すことができます。
user2313067 14

27
管理者を信頼できない場合、人事上の問題があります。
マイケルハンプトン

5
そもそもなぜこれらのUSBメディアにキーをコピーしたのですか?SSLで使用される秘密鍵は、使用されるサーバー以外の場所にある必要はありません。(もちろん、サーバーのバックアップコピーに含まれている場合がありますが、サーバー上の他のデータよりもそのキーをバックアップすることは重要ではありません。古いもの。)
kasperd 14

私はこの分野の専門家ではありませんが、その中に留まり、署名要求のみが入り、署名が出てくるキーを含むハードウェア暗号化モジュールは存在しませんか?はんだ付けするか、サーバーに接着することで解決できます。
マテガ14

回答:


26

サーバーへの管理(またはしばしば物理的)アクセス権を持つ人は、秘密鍵を抽出できるようになります。エクスポート、メモリスニッフィング、または他のそのような策略を通じてかどうか。

管理者は、Webサーバーの秘密鍵にアクセスできます。これを事実として受け入れ、それを回避します。システム管理者が信頼できない場合、より優れたシステム管理者、または少なくともWebサーバーにアクセスできるシステム管理者が必要になる場合があります。管理セキュリティの妄想の問題である場合、システム管理者を信頼する能力に関して、より深い問題がある可能性があります。

これは、すべての人に秘密鍵へのアクセスを許可するべきだということではありません。アクセスが許可される前に、常にアクセスが必要です。それを念頭に置いて、ウェブサイトを完全に制御するシステム管理者が秘密鍵をエクスポートできないようにするために極端な対策を講じますが、それでもほとんど追跡不可能な方法でウェブサイト自体を操作できますか?ここで信頼できるようになりました。それが、対処する必要がある問題の核心だと思います。


2
「管理者はWebサーバーの秘密キーにアクセスできます。これを事実として受け入れ、回避してください」の+1。「管理者権限を持つユーザーがXを実行できないようにする方法」の効果に対する質問 より深い問題を示しています。管理者権限の付与に不信感がありすぎるか、ゆるすぎる。
ブランドン14

2
私が尋ねた理由で更新しました。システム管理者の懸念ではなく、ベストプラクティスに従うことを望んでいます。
デビッドティーレン14

11

キーをインポートするとき、エクスポート不可としてマークするオプションがあります。これにより、IISまたは証明書MMCを使用してエクスポートできなくなります。少なくとも、それは少し難しくなります。

ただし、マシンの管理者アカウントを持っている場合、またはマシンに物理的にアクセスできる場合は、他の手段でキーを取得できます。



0

これは、「中間CA」が役立つ場所です。

以下のこの例の「ルートCA」は、あなたではなくSSL会社が所有するものです。

ルートCAによって作成されたキーを直接制御することはできないため、ルートCAによって署名されたキーが危険にさらされた場合、それらを無効にするためにそれらを通過する必要があります。

だが:

Root CA (SSL company)
 |
 +-Intermediate CA (You)
   |
   +-Server Key for site

中間に別のCAを配置し、購入したSSL証明書にサーバー証明書に直接署名するのではなく、独自のCA証明書に署名させる場合、以下のサーバー証明書の制御を保持し、失効証明書を発行するか、それ以下が危険にさらされた場合は何でもできます。

中間CA秘密鍵は自分で管理し、管理者はそれを見る必要はありません。

これを行うこともできます:

Root CA (SSL company)
 |
 +-Intermediate CA (You)
   |
   +-Server Key 1 for site
   +-Server Key 2 for site 
   +-Server Key 3 for site

侵害に備え、事前に証明書を生成できるため、個々のキーが失効した場合にすばやく切り替えることができます。管理者は、1が妥協するまで2または3のキーを取得しません。このスキームについてサイトに通知することができます。また、これにより、終わりはあなたのサイトを破壊しません。


1
これにより、信頼できないCAのユーザーに対してSSL警告が発生しませんか?
ceejayoz

1
企業のイントラネット設定などで、ユーザーのブラウザにCAを信頼できる証明書としてインストールできる場合にのみ、これはうまく機能すると思います。私は自分の華麗な計画に何か問題があることを知っていました。:(
LawrenceC 14

0

サーバー以外に秘密鍵を格納することを提案する多くの記事がありますが、それらの秘密鍵はコード署名証明書のためです。自分だけがアクセスできるオフラインコンピューターにキーがあり、一部のソフトウェアが書き込まれ、オフラインサーバーから秘密キーを取得し、コードに署名したとします。もう一度コード。

最善の解決策は常にあり、今後もキーをオフラインで保存することです。どのようにそれを行うかは完全にあなた次第です(いくつかの方法があります)、オフィスの安全な場所、または誰かがポケットに入れるのが簡単ではない場所でしっかりと保護することを忘れないでください。

続きを読む:https : //www.thesslstore.com/blog/heres-what-happens-when-your-private-key-gets-compromised/

対照的に、SSL証明書は、WebサイトがHTTPS通信を有効にするためのものです。プライベートキーは、Webサーバーによるすべてのハンドシェイク中に必要です。したがって、オフラインで保存することはできません。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.