1

私は他の関連する質問の山を読みました...私が持っている質問に実際に答えているものは何もないようです.

私のアプリケーションは、いくつかの異なるサードパーティのサイトと統合されます。(ebay、paypal、google、amazon...) これは製品管理システムであり、あらゆる場所に製品をプッシュしています...

もちろん、これらすべてのサイトと対話するため、ユーザー名、パスワード、トークンなどが必要です..これらのものをそのまま保存することは本当に良い考えではないと思いますが、それでも生で取得できる必要があります、送信する XML または HTTP ヘッダーに埋め込むことができます。

情報を保存する方法について誰か提案がありますか? Rails GEMはありますか？

4

1 に答える 1

1

サーバー環境変数に格納することは、 Twelve-Factor App の方法論に従って、資格情報を DB、サードパーティの資格情報などに格納するためのベスト プラクティスです。それらの保管方法は、使用しているものとセットアップ方法によって異なります。これにより、信用情報をソース管理、データベース、およびサーバー環境のローカルに保持することが促進されます。環境変数にアクセスするには、次のように使用できますENV。

ENV['something']

制限とセキュリティに関する懸念:

環境変数に数千以上のパスワード/資格情報を保存している場合、実現可能性とセキュリティの観点から、それらを使用するかどうかを決定するのに役立ついくつかのことがあります。

  1. Web アプリケーションまたはサービスを実行している OS ユーザーが、Rails アプリケーションのルート ディレクトリとサブディレクトリのみへの読み取り専用アクセス権を持っているため、資格情報/シークレット ファイルの既知の (相対または絶対) パスへの読み取りアクセス権を持っている場合、および開発者が、クライアントに返される変数に読み取られるファイルへのパス名の一部としてリクエスト パラメータを使用するサービスを誤って作成すると、アプリケーションのユーザーがすべてのクレデンシャルをリモートでダンプする可能性があります。アプリケーションを実行している OS ユーザーが簡単に推測できないパス名でこれらの資格情報をアクセスしにくい場所に置くと、そのエクスプロイトがそれらの資格情報をダンプするために成功裏に使用されるリスクが軽減されます。

  2. また、サーバー環境外でこれらの資格情報を使用するのを難しくするために、できることを行う必要があります。このように、アプリ/サービスのエクスプロイトを介してすべての資格情報をダンプしたが、その環境外でそれらの資格情報を使用できない場合、それらの価値ははるかに低くなります。

  3. env 変数に格納できる量の制限は、おそらくあなたが思っているよりも高いでしょう。たとえば、RVM がロードされた macOS では、bash 関数などで大量の環境スペースを浪費しますが、4278 53 文字の長さの資格情報 (例: bcrypt-ed) を取得できました。

test.sh

#!/bin/bash
set -ev
for i in `seq 1 4278`;
do
    export CRED$i='...........................................'
done
ruby -e 'puts "#{ENV.size} env vars in Ruby. First cred=#{ENV["CRED1"]}"'

出力：

$ time ./test.sh
for i in `seq 1 4278`;
do
    export CRED$i='...........................................'
done
seq 1 4278
ruby -e 'puts "#{ENV.size} env vars in Ruby. First cred=#{ENV["CRED1"]}"'
4319 env vars in Ruby. First cred=...........................................

real    0m0.342s
user    0m0.297s
sys 0m0.019s

それを超えると、 になりましruby: Argument list too longた。

  1. アプリに環境変数の値を吐き出す可能性のあるサービスがある場合、安全性が低下するため、環境変数に資格情報を保存したくないことは明らかですが、私の経験では、開発に遭遇したことはありませんすべてのシステム プロパティと環境変数を吐き出す可能性のある Java 管理コンソールのようなものを除いて、ENV が意図的に公開された状況。

  2. クレドを DB に保存すると、通常は SQL インジェクションの悪用がはるかに一般的であるため、リスクが高くなります。これが、通常、パスワードのハッシュのみが DB に格納され、他のサービスへの暗号化された資格情報が格納されない理由の 1 つです。

  3. 攻撃者がサーバー自体にログインし、Web アプリ/サービスを実行しているユーザーの環境にアクセスできる場合、または資格情報を含むファイルを見つけて読み取ることができる場合は、運が悪いです。

于 2013-02-25T22:15:47.727 に答える