4

これは私が抱えている特定の問題に関するものではありませんが、このプロジェクトには多くの問題があるため、何かを解決する必要があります。

英国のいくつかの大企業に展開する Web アプリケーションを作成しています。これを間違えると、莫大な費用がかかる可能性があります。

各企業のデータを非常に安全に保つ必要があるため、組織ごとに新しいデータベースを作成することをお勧めします。このようにして、データは完全に分離され、1 つのデータベースが侵害された場合、すべての組織のデータが失われます。これにより、すべてのデータが危険にさらされる前に、セキュリティの問題に対応する時間が得られます。私の質問は次のとおりです。

  1. これの短期的および長期的な利点は何ですか (もしあれば)
  2. これの短期的および長期的な欠点は何ですか (もしあれば)
  3. これは良い習慣ですか?
  4. 私が予想する方法でセキュリティの問題を解決するでしょうか?

前もって感謝します

4

3 に答える 3

4

これは、「サービスとしてのソフトウェア」スタイルのアプリケーション用に「マルチテナント アーキテクチャ」を構築することに関する質問だと思います。

最初の問題は、データベースを分離することが良いアイデアかもしれないし、そうでないかもしれないということですが、それは最初に尋ねる質問ではありません。これが重要なレベルでデータベースにアクセスできる誰かが、すでにアプリケーションに侵入し、非常に損害を与えています。ほぼ確実に、データベース サーバーで任意のコマンドを実行できます。これは、1 つのアカウントへの損害だけでなく、インフラストラクチャ全体への損害に対処していることを意味します。これは「消灯」の瞬間であり、回復するまでシステム全体をシャットダウンする必要があります。

データベース サーバーにシェルが確立されていない場合は、アプリケーション レイヤーのセキュリティに問題があることを意味します。SQL インジェクション、または認証スキームでの特権昇格の何らかの方法です。繰り返しますが、どちらも「消灯」の瞬間です。

したがって、それらすべてが完全にカバーされていることを確認してください。開発ライフサイクルにセキュリティ テストを含めます。自動侵入テスト ツールを継続的インテグレーション システムの一部として使用することを検討してください。インフラ担当者が環境全体を強化していることを確認し、リリース候補に近づいたらサードパーティのセキュリティ監査を受けることを検討してください。セキュリティの問題に焦点を当てたコード レビュー プロセスを検討し、特定のセキュリティに関する考慮事項をコーディング基準に同意します。クロス サイト スクリプティング、SQL インジェクション、およびその他のアプリケーション レベルの脆弱性について、すべての開発者に伝えてください。

それがすべて完了したら、ドアをロックし、窓をボルトで固定しました。データベース戦略は、ジュエリーを安全に保つ方法と同じです。

別のデータベースを使用すると、セキュリティが強化されますが、これはユーザー管理に対応する戦略がある場合に限られます。ほとんどの Web アプリケーションでは、"admin" と "web app" の 2 種類のユーザーしか存在しません。「管理者」は、データベースの作成/変更 (データベース、テーブル、ビューなどの作成) を行うことができ、通常はデータの変更も行うことができます。「Web アプリ」にはデータ変更権限のみが必要で、データベース オブジェクトを変更する権限はありません。

データベースの分割を意味のあるものにするには、次のことを確認する必要があります。

  • Web アプリケーションのファイル システムにアクセスできる攻撃者は、有効なユーザー名とパスワードにアクセスできないか、できたとしても 1 つのクライアントにしかアクセスできません。
  • 攻撃者は「管理者」資格情報にアクセスできません

ただし、データベースを分割することが理にかなっている (セキュリティ以外の) 理由は他にもあります。人為的エラーのリスクを軽減し、システムをより細かいレベルでスケーリングできるようにし、さまざまなレベルのホスティングを提供できるようにします (「ゴールド」ユーザーは独自のサーバーを取得し、「シルバー」ユーザーは独自のデータベースを取得し、「ブロンズ」ユーザーは独自のデータベースを取得します)。 "彼らのチャンスをつかむ)。

これを実現するために解決しなければならない大きな問題は展開です。データベースに変更を加えて、新しいバージョンのコードをどのように展開するのでしょうか? これにより、テストプロセスが複雑になる可能性があります。

于 2012-05-04T14:03:06.923 に答える
0

ほぼ確実に、データベースを分離します。@Anigel が言うように、おそらく個別のサーバーでさえ、その管理とコストはより複雑になるため、正確な要件によって異なります。

  • 利点の 1 つは、将来のある時点で、おそらく 1 つのクライアントのデータが大きくなるため、新しいサーバーに分割するのが容易になるか、プラットフォームのアップグレードを取得しても別のクライアントはアップグレードしない可能性があることです。

  • clientX_で始まる名前のすべてのテーブルを選択するのではなく、データベース全体をダンプ/ロードできれば、バックアップと復元が簡単になります。

  • 別のデータベースを使用すると、パフォーマンスの測定が容易になります。

開始するためのいくつかの簡単なアイデア。

于 2012-05-04T13:39:52.127 に答える
0

@Lee Price、会社ごとに個別のデータベースを維持することは素晴らしいことです。

利点:

  • データベースを安全に保ちます

  • テーブルのサイズが劇的なパフォーマンスを提供する単一の会社に制限されている長い間。操作は高速になります。

  • 企業のデータを簡単に操作できます。

  • サポートの面で助けてください

短所:

  • すべての会社のスキーマ変更を追跡する必要がある

  • 別々のデータベースを維持する

  • 個別のバックアップを維持する

  • 単一のデータベースと比較して、より多くのスペースを占有します

しかし、個人的には、企業ごとに個別のデータベースを使用することをお勧めします.

于 2012-05-04T13:44:06.470 に答える