web-dev-qa-db-ja.com

セキュリティを強化するために、いくつかの分離された（異なる物理サーバー）DBMSでデータを分割することについての理論？

次のシナリオを想定します。

1-非常に賢明な情報が同じ物理サーバーにデプロイされているWebアプリ（WEBSERVER1上）とそのデータベース（DBMS1上）（簡略化のために言っておきます）。ユーザーは、特別なセキュリティ対策の傘下でWebアプリを操作します。これらのセキュリティ対策は、Webアプリのユーザーが少数であり、DMBS1とWEBSERVER1が存在する特別なネットワークロケーションを尊重しているという事実を考慮に入れています。適用されたセキュリティ対策の一部（DBMS1のデータとWEBSERVER1へのアクセスを保護するために適用された）は、この条件を満たすユーザーにのみ適用できることを説明するためにこれを言いました。このユーザーのセットをUSERS1と呼びましょう。

2-他のユーザーとアプリケーション（APIエクスポージャーを介して）もDBMS1のアクセスデータ（CRUD）を必要とします（それらをUSERS2と呼びます）が、物理的な場所のために、USERS1に適用したのと同じセキュリティ対策をUSERS2に適用することはできません。ユーザーの数とそれらの制御。さらに、USERS2に許可を適用することは非常に重要です。つまり、USERS2は、アクセスが許可されたDBMS1のデータにアクセスすることができます。

ある同僚は、データに対してUSERS2 CRUDを使用できるように、メインのDBMS1とWEBSERVER1から分離して、異なるDBMS2と異なるWEBSERVER2をデプロイしてセキュリティを強化することを提案しています。私が見る限り、これは、あるDMBSから別のDMBSにデータを同期するメカニズムがあることを意味します。ファイアウォールと資格情報は、DBMS2サーバーが危険にさらされても、侵入者が承認ポリシーに違反してDBMS1にデータを書き込むことができないように設定できます。これをアーカイブするには、USERS2認証設定（DBMS1で指定）と複製されたデータの間のマップである必要があります-DBMS1とDBMS2の間で同期され、データ複製のプロセスはDBMS1のサーバーグループから開始され、DMBS1サーバーにDMBS2にアクセスするための資格情報があります。 DBMS2サーバーは、DBMS1にアクセスする方法について何も知りません。

この種のアーキテクチャの価値は、USERS2が相互作用しているDBMSとWEBSERVER2の展開で見つけた悪用可能なセキュリティホールを分離して含むことにあると思います。

USERS2の資格情報の保護とセキュリティ対策のコンプライアンスは、DMBS1を管理する組織のドメイン外にあることに注意してください。

私の質問は次のとおりです。

この種のアーキテクチャについて書かれた何かが存在しますか？承認ポリシーに応じてDMBS2の作成と変更のプロセスを自動化するためのツール/手順はどうですか？

このアーキテクチャについての助けやオリエンテーション、批評家に感謝します。

説明を裏付ける図を含めています。矢印の方向は、誰がコミュニケーションを開始するかということだけです。グラフィックがひどいことはわかっていますが、いくつかの情報を追加したいと思います。 enter image description here

EDIT：このDBMS-Web_Serverアーキテクチャと DZMデュアルファイアウォール の類似点は明らかです。

data-leakagefederationarchitecturedatabases
3
canciobello

私はあなたの質問を理解するのに苦労していますが、答えを試みさせてください。 2つのユーザーグループがあるようです。

  • 内部Webアプリユーザー
  • 外部APIユーザー

また、これらのユーザーは同じデータベースに異なるレベルのアクセスを必要としているようです。

上記が当てはまる場合は、次の構造をお勧めします。

  • WebアプリとAPIをホストするWebサーバー。 Webアプリを特定の人に制限して、外の世界にアクセスできます。
  • Webサーバーからのみアクセス可能なデータベースサーバー。内部ユーザー、外部ユーザーなどは直接アクセスできません。すべてがWebサーバーを通過する必要があります。

アクセスセットアップ中のデータベースでは、2つのスキーマがあります。

  • 全員
  • 内部

したがって、データベースには次のような4つのテーブルがある可能性があります。

internal.SuperSecretTable
internal.DarkCompanySecrets
external.WhoCares
external.HaveAtIt

2つのユーザーロールもあります：-employee-apiUser

employeeロールはinternalスキーマとexternalスキーマの両方にアクセスできますが、apiUserロールはexternalにのみアクセスできます。スキーマ。これらの役割に、機能するために必要な最低限の権限を付与します。

お役に立てれば！

1
Abe Miessler