Webアプリのパスワードの管理と展開
Webアプリのパスワードと秘密キーを管理および展開するためのベストプラクティスは何ですか？例えば。データベースまたはFacebook APIなどの外部サービスにアクセスするためのパスワード。私が言及しているのは、HerokuやEC2などの特定のプロバイダーではなく、専用ハードウェアまたは一般的なクラウドプロバイダーを使用することです。
HSMなしで実行できる最善の方法は、資格情報をプレーンテキストファイルで、Webアプリユーザーのみがアクセスできる読み取り保護されたディレクトリに展開することです。すべてのパスワードが記載された1つのファイル、またはユーザーごとのファイル、または環境変数に保存する必要がありますか？それらをサーバーに実際に配置する方法を教えてください。構成管理ツール（chef/puppetなど）を使用してそれらをデプロイし、最新の状態に保つことができますか？これらの資格情報はどのように保存する必要がありますか？それらは、構成管理構成を含むソース管理ディレクトリに暗号化形式で保存する必要がありますか？役立つかもしれない使用するツールに関する推奨事項はありますか？ （keyczar、シークレットサーバーなど）パスワードが暗号化されている場合、DevOpsチーム間で復号化キーを共有するための良い方法は何ですか？ （ラストパス、キーパスなど？）
それは長い質問のリストであることは知っていますが、これらはすべて、適切な答えを見つけられなかったものです。誰かがうまくやっているケーススタディなのか、さまざまな代替案の間でトレードオフがなされるのか、明らかに避けなければならないことや目的とするものなのか、私はどんな情報にも興味があります。どのようなベストプラクティスが存在し、役立つツールを持っているのか、自分の状況に合わせて判断して自分で解決する必要があるのか、私には本当にわかりません。
あなたの質問は非常にあいまいで、多くの分野をカバーしています。例が最も役に立ちます。
質問のタイトルに基づいて、アプリケーションに必要な資格情報を安全に処理する方法に興味があるようです。これがMicrosoft環境の場合、機密情報（SQLログオン資格情報など）を格納するために使用されるweb.configのセクションを暗号化できます。この投稿は良い説明を提供します： why-to-use-rsa-for-dpapi-web-farm-encryption 。つまり、Webサーバーが1つしかない場合は [〜＃〜] dpapi [〜＃〜] が推奨されるソリューションですが、Webファームには RSAキー が推奨されます。
ただし、エンタープライズパスワード管理ソリューションにも興味があると思います。 SANSの講師Jason Fossenは、彼の Windows Security Blog に素晴らしいエントリーを投稿しました。彼は、ローカルアカウントに一意のパスワードを割り当て、非対称暗号化を利用してパスワードを集中管理された場所に保存するスクリプトを作成しました。エントリでは、パスワードボールトまたはエンタープライズパスワード管理のスペースにある多くの商用製品についても言及しています。
HSMは通常、ドメイン/エンタープライズ管理者などの重要なアカウント、または重要なインフラストラクチャで使用される証明書にのみ使用されます。これらのエンタープライズパスワード管理ソリューションは、一般的または日常的な使用に最適です。
かなり前に、私は Lieberman ソリューションを調べたところ、非常にクールであることがわかりました。資格情報にアクセスしているユーザー、どの資格情報にアクセスしたか、そしてもちろんいつ記録するかについての完全な監査があります。一時的なアカウントを設定する柔軟性もあります（x時間にのみ有効）。これは、請負業者、コンサルタントなどに役立ちます。
いくつかの基本的な原則に戻ることが役立つと思います。よい出発点は、アプリケーションまたは管理者がユーザーのプレーンテキストパスワードを知っている理由がないように設計することです。ハッシュ化/暗号化されたバージョンのパスワードのみが必要です。パスワードがわからない場合は、パスワードをユーザーとやり取りする必要はありません。
次に行うことは、リスクと結果の評価です。主なリスクとは何か、それらのリスクが特定された場合の結果はどうなるか。これにより、必要なセキュリティのレベルと許容できるオプションがわかります。
問題は、リスク評価を満たす安全な方法で新しいユーザーをセットアップ/登録する方法の痛風の1つになります。いくつかのオプションがあり、その多くは、持っている情報によって異なります。ほとんどのソリューションは、使用できるワンタイムパスワードまたはワンタイムリンクを提供することに依存しています。どちらにもタイムアウトが発生し、その後は使用できなくなります。彼らがパスワードまたはリンクを使用するとき、彼らは「本当の」パスワードなどを設定することを強いられるでしょう。
この問題は、このワンタイムパスワードまたはリンクをユーザーに伝えるための最良の方法を見つけることの1つになります。これは、プライベートメール、SMS、電話など、利用可能なオプションの組み合わせと、情報が悪用された場合のリスクと結果に依存します。
リスクと結果の評価は重要です。セキュリティと保護のレベルがリスクと結果のレベルと十分に一致していない場合、ユーザーはサービスに不満を抱く可能性があります。彼らはそれが十分に安全ではないと考えてそれを使用しないようにするか、またはそれを使用するのが難しすぎてそれを使用しないようにするでしょう。