web-dev-qa-db-ja.com

スクリプトがsshに使用するパスワードを安全に保存する方法はありますか?

つまり、まず、SSHでキー認証を使用する必要があります。説明する必要はありません。

ここでの問題は、サーバーの(大きな)束があり、これらのそれぞれに接続できるスクリプトが必要なことです。

可能な限りキー認証を使用しますが、すべてのサーバーで使用できるわけではありません(これを制御することはできません)。そのため、ログインでSSHを使用するか、Telnetでログインすることもあります。

そのため、一部のユーザーはパスワードをdbに保存しただけで、スクリプトは必要に応じてそれを取得します。問題は、その方法でそれを行うことは本当に安全に見えないということです。それを少し安全にする方法はありますか?

それを保存する特定の方法が好きですか?

16
wokati

スクリプトがこれらのサーバーのいずれかに接続できる場合、スクリプトへのアクセス権(またはスクリプトが実行されるマシンへの特権アクセス権)を持つユーザーは、それらのサーバーのいずれかに接続できます。

スクリプトが自律的に実行する必要がある場合、すべてのベットはオフになります。ここでの答えはいいえ、そのような環境でパスワードを保存する絶対的に安全な方法はありません。絶対に安全なおよび何かを行う実際的な方法はありません。

不可避を回避しようとする代わりに、多層防御に焦点を当てる必要があります

もちろん、必死にパスワードを適切に保護する必要があります。これは通常、スクリプトとは別のファイルにそれらを保持し、制限的なファイルシステムのアクセス許可を構成することを意味します。これは、セキュリティの観点から、この面でできることのすべてです。

他の方法では、プロセスにobscurityを確実に追加できます。パスワードを暗号化すると、攻撃者は復号化キーを検索する必要があります。ある種のオペレーティングシステムで保護されたストレージを使用すると、一般に他のユーザーがキーにアクセスするのを防ぐことができます(そのため、攻撃や使用が複雑になる以外は、ファイルシステムのアクセス許可に勝る利点はありません)。これらの対策は、攻撃を遅延しますが、決定的な攻撃者に対する攻撃を防ぐことはできません。


それでは、少しの間パスワードをpublicとして扱いましょう。被害を軽減するために何ができますか?

古いテスト済みのソリューションは、これらの資格情報が実行できることを制限することです。 UNIXシステムでは、これを行うための良い方法は、スクリプト用に別のユーザーをセットアップして、そのユーザーの機能を制限することです。およびアクセスされたサーバー。ユーザー機能を制限できます SSHレベルシェルレベル 、または SELinuxのような必須のアクセス制御メカニズム を使用して制限できます。

あなたが考慮したいと思うかもしれない何かはサーバーにスクリプトロジックを移動することです。そうすれば、制御が簡単で、特に...

モニター。サーバーへのアクセスを常に監視します。ログ認証とに対して実行されたコマンドは、logのみを追加することが望ましい。たとえば、auditdを使用してスクリプトファイルの変更を監視することを忘れないでください。


もちろん、質問が示唆するように、サーバーを制御できない場合、これらのメカニズムの多くは役に立ちません。その場合は、サーバーの管理者に連絡して、スクリプトと潜在的なセキュリティについて知らせることをお勧めします落とし穴。

24
goncalopp

簡単に言えば、いいえ。

長い答えは:いいえ、完全に安全な方法はありません。 (これには、サーバー上の他のユーザーがアクセスできる環境変数が含まれます。)入手できる最も近いのは、それらを何らかの暗号化形式(keepass、GPG暗号化ファイル、またはそれらの行に沿った何か)で保存することです。しかし、ある時点で、スクリプトがパスワードを使用できるようにパスワードを復号化する必要があり、その時点で脆弱になります。

つまり、スクリプトの実行元のサーバー、ネットワーク、およびターゲットサーバーの両方で、詳細なセキュリティを詳細に検討する必要があります。

14
Jenny D

Dbのパスワードを2番目のパスワードで暗号化し、このパスワードを別の(3番目の)マシンに保存し、dbからパスワードを取得する必要のあるスクリプトが最初にこの3番目のマシンに接続して復号化パスワードを取得するシステムを配置できます。 、3番目のマシンから取得したパスワードを使用してdbのパスワードを復号化し、機能します。

もちろん、これは実際には追加のセキュリティを追加するものではありません。十分な権限を持つ攻撃者は、3台目のマシンにパスワードを要求することもできます。

しかし重要なのは、サードパーティがサードパーティのマシンを制御できるということです。上司やセキュリティ担当者、または管理していないサーバーを管理しているサードパーティ。

このようにして、彼らに問題が発生した場合、あなたが仕事を辞め、彼らがあなたを置き換える人を信用していない場合、またはあなたのスクリプトが彼らのマシンへのアクセスを停止することを望んでいる場合、彼らは3番目のプラグを引っ張ることができますマシン、スクリプトはパスワードにアクセスできなくなります。

0
Jens Timmerman