4

セキュリティで保護された Web 接続を介してユーザーの機密データを収集し、後で自動化された復号化と再利用のためにサーバーに安全に保存する必要があるシステムを構築しています。また、システムは、ユーザーが保護されたデータの一部 (例: *****ze) を表示したり、Web 経由で完全に変更したりできるようにする必要があります。システムは妥当なレベルのセキュリティを提供する必要があります。

私は次のインフラストラクチャを考えていました：

アプリ (ウェブ) サーバー 1

  1. 安全な Web 接続のための適切な TLS サポートを備えた Web サーバー。

  2. 公開鍵アルゴリズム (RSA など) を使用して、入力されたユーザーの機密データを暗号化し、 App Server 1またはDB Server 1のどこにも保存せずに、一方向のアウトバウンド セキュア チャネル (ssh-2 など) 経由でApp Server 2に送信します。

  3. ユーザーパスワード依存の対称鍵アルゴリズムを使用して、入力されたデータの一部 (最後の数文字/数字など) を暗号化し、DB サーバー 1に保存して、後でユーザーの Web セッション中にアプリケーションサーバー 1で取得できるようにします。

  4. ユーザーが Web 経由でデータを変更する場合は、ステップ 2 を再利用します。

DB サーバー 1

  1. セキュリティで保護されていない非機密ユーザー データを保存します。
  2. アプリケーション サーバー 1で暗号化された機密ユーザー データの一部を保存します (上記の手順 3 を参照) 。

アプリ サーバー 2

  1. App Server 1またはDB Server 1には何も送信 しない でください。
  2. アプリケーション サーバー 1から暗号化されたユーザーの機密データを受信し、 DB サーバー 2に保存します。
  3. 暗号化されたユーザーの機密データを ローカル スケジュールに従ってDB サーバー 2から取得し、適切なキー管理でアプリ サーバー 2にローカルに保存されている秘密キー (アプリ サーバー 1の手順 2 を参照)を使用して復号化します。

DB サーバー 2

  1. 暗号化されたユーザーの機密データを保存する ( App Server 2のステップ 2 を参照)

アプリ (Web) サーバー 1またはDB サーバー 1 、あるいはその両方が侵害された場合、攻撃者はユーザーの機密データ (暗号化されているかどうかにかかわらず) を取得できなくなります。とにかくよく知られている公開鍵と暗号化アルゴリズムへのアクセスだけが攻撃者に与えられます。ただし、攻撃者は Web サーバーを変更して、現在ログインしているユーザーのパスワードを平文で取得し、DB サーバー 1 に保存されているユーザーの機密データの一部を解読することができます ( App Server 1を参照)。、ステップ 3) は大したことではありません。攻撃者は、(コードの変更を介して) 潜在的な攻撃中にユーザーが Web 経由で入力した機密データを傍受することもできます。後で私はリスクが高いと考えますが、攻撃者が誰かに気付かれずにコードを変更するのは難しい (そうですか?) ことを考えると、あまり心配する必要はないと思います。

App Server 2と秘密鍵が侵害された場合、攻撃者はすべてにアクセスできますが、App Server 2またはDB Server 2は Web 向けではないため、問題にはなりません。

このアーキテクチャはどの程度安全ですか? 暗号化アルゴリズムと安全なプロトコルがどのように機能するかについての私の理解は正しいですか?

ありがとうございました！

4

3 に答える 3

3

貴社のシステムの目的が明確でないため、適切な回答ができないと思います。デザインに関するフィードバックをいただけるとありがたいのですが、目的がなければ少し難しいです。

ただし、これをお勧めします：

最初に脅威モデルを厳密に文書化して分析する

考えられるすべての攻撃シナリオの固定された厳格なリストを作成する必要があります。ローカルの攻撃者など、誰を防御しようとしていますか? また、「適切なキー管理を使用して」のようなことも言います。しかし、これは最も難しいことの 1 つです。したがって、これを正しく行うことができると思い込まないでください。これをどのように行うかを完全に計画し、誰による攻撃を防止するかを具体的に関連付けます。

脅威モデルを作成する必要がある理由は、どの角度で脆弱になるかを判断する必要があるためです。こうなるからです。

また、理論は良いですが、それもお勧めします。暗号化の実装も非常に重要です。物事を正しく行うと思い込むだけでなく、乱数がどこから来るのかなどについて本当に注意する必要があります。

これが少し漠然としていることは承知していますが、少なくとも正式で強力な脅威モデルを考え出すことは、あなたにとって非常に役立つと思います.

于 2009-09-21T01:46:40.457 に答える
1

ここまでは順調ですね。非常に安全なアーキテクチャに向けて順調に進んでいます。ファイアウォール、パスワード ポリシー、ロギング、監視、アラートなど、他にも考慮すべき懸念事項がありますが、これまでに説明したことはすべて非常に堅実です。データの機密性が十分に高い場合は、サード パーティによるセキュリティ監査を検討してください。

于 2009-09-21T01:38:26.363 に答える
1

Web サーバーからアプリ サーバーへの通信に公開鍵を使用することはお勧めしません。両方のシステムを制御する場合は、暗号化の通常の秘密システムだけです。アプリ サーバーの ID はわかっているので、キーを安全に保つことは問題ではありません。秘密鍵を変更または更新する必要がある場合は、接続を介して漏洩しないように手動で行ってください。

私が最も注意することは、DMZ 内のサーバー (Web サーバーのみであるべき) から、ネットワークの内部にあるボックスへのデータ転送の方向です。正当なドメインが侵害され、マルウェアを訪問ユーザーに配布することがますます一般的になりつつあります。それは悪いことですが、マルウェアがユーザーに対してだけではなく、ネットワークに対して向かうようになれば、ビジネスは完全に混乱してしまいます。

また、マルウェアの配布を防ぐための sql インジェクションやシステムの強化/パッチ適用の防止についても何も見ませんでした。これは、最初の最も重要な考慮事項です。セキュリティが重要な場合は、サーバー間通信の小さなカスタマイズと頻繁なパッチ適用に柔軟に対応できるアーキテクチャになります。ほとんどの Web サイトは、大手の正当な企業であっても、侵害されたとしてもセキュリティ ホールを修正することはありません。そもそも危険にさらされたくない場合は、セキュリティ ホールを継続的に修正し、セキュリティ ホールが発生しないように変更する必要があります。

マルウェアの配布者にならないように、クライアント側のスクリプトを含むメディアの配信方法について厳格なルールを作成することをお勧めします。クライアント側のスクリプトは、クライアント システムで実行される JavaScript、ActiveX、Flash、Acrobat、Silverlight、およびその他のコードまたはプラグインに含まれています。異常なコード フラグメントをすぐに識別できるように、そのコンテンツを提供するためのポリシーが存在する必要があります。私のお勧めは、絶対にしないことですクライアント側のコードをブラウザーに直接埋め込みますが、常に何らかの外部ファイルを参照します。また、8 つの小さな JavaScript ファイルの代わりに 1 つの大きな JavaScript ファイルを提供するなど、より良いアセット コントロールを提供し、帯域幅を節約するために、同じ考えを持つメディアを統合することをお勧めします。また、ディレクトリ構造でドメインを参照する外部コンテンツ配信システムに、そのようなすべてのメディアを強制することもお勧めします。こうすることで、メディアがサーバーから直接提供されることはなく、直接提供された場合は、悪意のある可能性があり、セキュリティ レビューが必要であるとすぐに特定できます。

于 2009-09-21T02:10:30.280 に答える