これは、「サービスとしてのソフトウェア」スタイルのアプリケーション用に「マルチテナント アーキテクチャ」を構築することに関する質問だと思います。
最初の問題は、データベースを分離することが良いアイデアかもしれないし、そうでないかもしれないということですが、それは最初に尋ねる質問ではありません。これが重要なレベルでデータベースにアクセスできる誰かが、すでにアプリケーションに侵入し、非常に損害を与えています。ほぼ確実に、データベース サーバーで任意のコマンドを実行できます。これは、1 つのアカウントへの損害だけでなく、インフラストラクチャ全体への損害に対処していることを意味します。これは「消灯」の瞬間であり、回復するまでシステム全体をシャットダウンする必要があります。
データベース サーバーにシェルが確立されていない場合は、アプリケーション レイヤーのセキュリティに問題があることを意味します。SQL インジェクション、または認証スキームでの特権昇格の何らかの方法です。繰り返しますが、どちらも「消灯」の瞬間です。
したがって、それらすべてが完全にカバーされていることを確認してください。開発ライフサイクルにセキュリティ テストを含めます。自動侵入テスト ツールを継続的インテグレーション システムの一部として使用することを検討してください。インフラ担当者が環境全体を強化していることを確認し、リリース候補に近づいたらサードパーティのセキュリティ監査を受けることを検討してください。セキュリティの問題に焦点を当てたコード レビュー プロセスを検討し、特定のセキュリティに関する考慮事項をコーディング基準に同意します。クロス サイト スクリプティング、SQL インジェクション、およびその他のアプリケーション レベルの脆弱性について、すべての開発者に伝えてください。
それがすべて完了したら、ドアをロックし、窓をボルトで固定しました。データベース戦略は、ジュエリーを安全に保つ方法と同じです。
別のデータベースを使用すると、セキュリティが強化されますが、これはユーザー管理に対応する戦略がある場合に限られます。ほとんどの Web アプリケーションでは、"admin" と "web app" の 2 種類のユーザーしか存在しません。「管理者」は、データベースの作成/変更 (データベース、テーブル、ビューなどの作成) を行うことができ、通常はデータの変更も行うことができます。「Web アプリ」にはデータ変更権限のみが必要で、データベース オブジェクトを変更する権限はありません。
データベースの分割を意味のあるものにするには、次のことを確認する必要があります。
- Web アプリケーションのファイル システムにアクセスできる攻撃者は、有効なユーザー名とパスワードにアクセスできないか、できたとしても 1 つのクライアントにしかアクセスできません。
- 攻撃者は「管理者」資格情報にアクセスできません
ただし、データベースを分割することが理にかなっている (セキュリティ以外の) 理由は他にもあります。人為的エラーのリスクを軽減し、システムをより細かいレベルでスケーリングできるようにし、さまざまなレベルのホスティングを提供できるようにします (「ゴールド」ユーザーは独自のサーバーを取得し、「シルバー」ユーザーは独自のデータベースを取得し、「ブロンズ」ユーザーは独自のデータベースを取得します)。 "彼らのチャンスをつかむ)。
これを実現するために解決しなければならない大きな問題は展開です。データベースに変更を加えて、新しいバージョンのコードをどのように展開するのでしょうか? これにより、テストプロセスが複雑になる可能性があります。