この質問は一般に、ここで尋ねられた過去の質問に似ていますが、Linuxに関連する質問を見たことはありません。
手近な例:a PHP WebアプリにはMySQLバックエンドがあります。その機能の一部として、他のリモートMySQLホストにアクセスし、それらのホストにいくつかのクエリを発行します。
これを可能にするために、PHPアプリはこれらのリモートデータベースの資格情報を必要とします。そのような資格情報を保存/取得するための適切な方法は何ですか?
アプリのユーザーがそのような認証情報を自分で提供しないことが必要です。また、このアプリには何十人ものユーザーがいる可能性があります。
アプリのすべてのユーザーはLDAPを介して識別されます。アプリとMySQLサーバーのセット全体が同じ内部ネットワーク内にあります(2段階のVPN検証が必要です)。セットアップ全体がLinuxマシンで実行されます。
この問題のリーズナブルソリューションとは何ですか?
PHPを実行しているユーザーのみがアクセスできるファイルに構成を保存する必要があります。Webユーザーがファイルにアクセスできないようにすることはできますが、PHPは資格情報にアクセスできなければならず、何をしてもそれらは実質的に保護されません。アプリケーションに与えることができるどんな秘密も発見される可能性があるので、いくつかを作ろうとすることには本当の利点はありません複雑なチェーン。
構成ファイルだけでなく、Webサーバーが使用するSQLアカウントがWebサーバーのIPからのみ使用できること、およびWebサーバーに必要な権限しか持たないことも確認する必要があります。あなたのウェブサーバーがハッキングされると、彼らはウェブサーバーのDBへのアクセスを取得しますが、あなたのウェブサーバーがハッキングされている場合は、スクリプトを置き換えるだけでWebサーバーにアクセスさせることができます。
あなたは専用サーバーにいると思いますか?共有ホスティングを使用している場合、PHPスクリプトを保護することはほとんど不可能です。
妥当な方法は、パスワードを専用の構成ファイルに格納し、ファイルのアクセス許可を制限して、これが所有者のみが読み取り可能になるようにすることです。
人々は「ああ、でも暗号化されていません」と泣くと思います。問題は、アプリケーションがデータベースに接続するためにプレーンテキストのパスワードを必要とすることです。したがって、パスワードを暗号化する場合は、キーを使用可能にする必要もありますが、これはポイントを無効にします。私はこれを改善するためにあらゆる種類のクレイジーな提案を見てきましたが、それらはすべて意味のあるセキュリティを追加せずに複雑さを追加するだけです。
もう1つの解決策は、アプリケーション内にsshクライアントを直接実装し、 JSch などのサードパーティライブラリに依存するか、ssh/ssh-agent
を拡張してデータベースからキーを直接受信して復号化することです。
*EDIT*
重要なことは、暗号化されたデータベースにキーを格納することによって達成しようとしていることです。
一時的な秘密鍵ファイルにアクセスできる攻撃者は、sshクライアントプロセスのメモリも読み取ることができます(したがって、とにかく鍵データにアクセスできます)。これらのデータは両方とも基本的に同じアクセス許可を持っている必要があるためです。ファイルを非表示にすることは、それをより安全にするようには見えません。
Db、webapp、およびssh接続に異なるユーザーを使用している場合は、dbにキーを格納し、それをwebappで復号化してsshにフィードすることで、プロセス全体にキーを分散させることで潜在的な攻撃ベクトルを開くだけです。これらすべて(db、app、ssh)で1人のユーザーのみを使用している場合、コードの複雑さ以外は何も得られません。
唯一の利点は、dbデータが盗まれてもWebアプリケーション(AFAIUに復号化アルゴリズムとパスワードが含まれている)が盗まれた場合に、システムを別のホストに転送しやすくなり、利益が得られることです。しかし、それはありそうですか?
つまり、キーを保護する場合は、sshのキーの内部暗号化を使用して、サービスの開始時にそれらをssh-agentにロードすることもできます(サービスが停止したら削除することを忘れないでください!)。ただし、ssh-agentは鍵を暗号化せずにメモリに保持するので、潜在的に読み取ることができることを忘れないでください。繰り返しますが、これはあなたが解決しようとしている問題ですか?
2つのマシン間の通信を保護する必要があるだけの場合は、sshよりも stunnel の方がサービスが優れている可能性があります。
これを行うには2つの方法があります。
これは可能ですが、もちろんこの重要なキーなしでは何も機能しません!
この場合、アプリケーションサーバーはパスワード各起動時を要求する必要があります。
これには、障害が発生するたびにサーバーを起動する責任があるhuman管理者が必要です。
もちろん、Webページの提供に使用される権限レベルは、サーバーの管理に使用される権限レベルと同じではありません。
しかし、これが唯一重要なことです。
いくつかの強化を行うことができます:非表示のファイル、画像ステガノなどを使用してパスワードを非表示にするが、これは少し役に立たない:
唯一重要なことは特権の昇格を防ぐです。
悪者がサーバーで高い特権に達すると、サーバーが彼のクレデンシャルを読み取るために使用する方法を取得するための段階的な起動プロセスは、ピースを食べるのと同じくらい簡単ですケーキの。
複雑な構造化システムですべての資格情報を正しく保存する最も簡単な方法は、基本システムのみで Debian GNU/Linux をインストールすることです。最初にDebianドキュメントに従って必要なサーバーのみをインストールします。
すべてが正しくインストールされたら、自分で設定を行う前に、すべてのドキュメントを閲覧するのにかなりの時間をかけます。
テストステップがあり、ローカルドメインで実行します。
これがどのように機能するかを十分に理解したと思うときだけ、私はこれをパブリックネットワークに置くことができました。