こんにちは、
Discourse のインストールが初めてで、最近、会社のフォーラム/コミュニティページとして Digital Ocean の Droplet にセットアップしました。
インストール中に、SMTP パスワードの入力が保護されておらず、app.yml ファイルに平文で保存されていることに気づきました。
これは潜在的なセキュリティ上の問題のように思えます。しかし、私はネットワークやセキュリティの専門家ではないため、いくつかの理由からこの方法で問題ないのかもしれません。ただし、IT マネージャーを納得させるためには、なぜこのように設計されているのかをより深く理解することが役立ちます。
Discourse は多くの企業で広く利用されているため、このトピックはすでに十分に議論されていると推測しています。
ご支援いただければ幸いです。
よろしくお願いいたします、
Jason
信頼できない誰かが app.yml ファイルにアクセスできる場合、SMTP パスワードの問題は最も心配すべきことではありません。
どのように保護することを提案しますか？
ハッシュは一方通行であり、元のデータに戻すことはできません。
ユーザーのパスワードは、復元する必要がないためハッシュ化されます。データベース内のパスワードハッシュは、ユーザーがログインを試みる際のみ参照されます。入力されたパスワードのハッシュ値が、そのユーザーレコードに保存されているパスワードハッシュと比較されます。
SMTP パスワードや API キーなどは、プレーンテキストで保存することが一般的です。これらは元の形式で送信される必要があるため、ハッシュ化すると使用できなくなります。もしサードパーティがパスワードのハッシュを受け入れる場合、保護手段としてのハッシュ化には何のメリットもありません。
上記で Jay が述べたように、サーバーの物理的な整合性が侵害され app.yml にアクセスされてしまった場合、SMTP パスワードのリセットよりもはるかに深刻な問題に直面していることになります。
ここで重要な注意点として、SMTP パスワードを他の場所で使用すべきではありません。これは Discourse に限ったことではなく、すべてのシステムおよびすべてのアカウントにおける優れたセキュリティプラクティスです。
Jay が言った通り、誰かが app.yml にアクセスできれば、他にもっと深刻な問題が発生している可能性があります。つまり、その人物はおそらくサーバーの完全なルート権限、本番データベースへのアクセス権も持っているということです。
ここで最善の策は、サーバーのセキュリティを確実に確保することです。
皆様、ご返信ありがとうございます。
サーバーを保護することが第一の防衛線であることには同意します。ただし、今回の場合は私が Digital Ocean の Droplet に Discourse をインストールしているため、私には制御できません。
@Stephen さん、SMTP パスワードに関する背景情報をご共有いただきありがとうございます。このような用途では平文で保存することが一般的だとは知りませんでした。前述の通り、これは私の専門外のことです。単に気になった点であり、質問したまでです。
ありがとうございます！
Jason
正確にはそうではありません 
SSH キーのみでのログインに制限をかける、ファイアウォールを稼働させる、セキュリティパッチを定期的に適用するといった対策が可能です。これらは Droplet のセキュリティを確保する上で非常に重要な要素です。
その通りです。そして、ファイルシステムを暗号化していない限り（これは難しい作業です）、彼らを信頼する必要があります。彼らはサーバーとネットワークに物理的にアクセスできるからです。
説明した通り、それを使用するにはパスワードが必要になります。