私は、機密性の高いデータを処理するWebアプリケーションを構築しています。セキュリティの向上に関する私の考えは、ログイン情報用のデータベースと機密データを含む完全に別のデータベースを作成することです。安全なデータベースの認証は、ログインデータベースによる2つの部分認証と機密データベース内のユーザーアカウントの検証に依存します。ログイン情報とミッションクリティカルな情報のためにデータベースを分けていますか？
私の質問は、そこにはもっと良い解決策がありますか？これらのデータベースを両方とも単一のサーバーに保守すると、大きなセキュリティ上の欠陥がありますか？単一のデータベースを保守するだけで安全なデータベースの内容を暗号化するほうが価値がありますか？安全なデータベースの内容を暗号化し、別のユーザー/設定ファイルで別々に認証されたアクセス権を持っていることは残念ですか？
希望はこれが理にかなっています。ありがとう。
Webアプリケーションの可能性が最も高い攻撃方法によって異なります。 SQLインジェクションがアプリのリスクである場合、別のデータベースを持つことは、ユーザーが正当にログインして、既にアクセスしているテーブルの他のレコードを読み込むようにアプリをスプーフィングすることに役立ちません。
1つのアプローチは、ユーザーごとに固有の暗号化キーを使用して各レコードを暗号化することです。そうすれば、1人のユーザーアカウントに妥協してしまえば、他の行はぎこちなくなります。これは非常に遅いですが、情報がの場合はとなります。
もう1つの方法は、機密情報をweb-appで直接照会できるようにしないことです。あなたのWebアプリケーション&はDMZで動作し、機密データベースはファイアウォールの背後で動作し、DMZと区別します。その後、必要に応じてデータを取得するために、Webサービスまたは厳密に制限されたデータベースロールを使用します。次に、Webサービス/データベース側では、ログインしたユーザーが参照できるレコードのみをコードに渡すことができます。
セキュリティはチェーンのようなものです。最も弱いリンクは、すべてが壊れるところです。
したがって、1つ以上のデータベースを使用しても問題はありません。システム全体を安全にするためには、両方を安全にする必要があります。
クレジットカード情報を保存するためのPCIコンプライアンス基準を調べる必要があります。実装するのは本当に苦痛ですが、その価値はあります。クレジットカードなどを保管していない場合は、一部のコーナーをカットすることができます。
本当に安全なソリューションには、ハードウェア、ソフトウェア、およびネットワークのセットアップが必要です。「ソリューション」はありません。
http://www.pcicomplianceguide.org/merchants-20071022-gaining-pci-compliance.php
これは役に立ちました。 PCIコンプライアンスには、安全なアプリケーションを構築する際に考えるべき素晴らしい点がいくつかあります。あなたが何か安全なものをプログラムするときは、そのほとんどが直感的ですが、チェックリストを持つのは良いことです。 – OverlordvI
私の考えは、3つのデータベースを使用することです（これはばかげて聞こえたら教えてください）。データベース1：ユーザーデータが限定され、公開のみのアクセス権があります。データベース2：認証データベース。データベース1にアカウントを作成できる管理者のみがアクセスできます。ログインすると、ユーザーはアカウントを作成できます（データベース1に存在する場合）。アカウントを作成することが許可されます。データベース3は権限ベースであり、Webプログラムによって定義されたACLを持っています（他はMySQLレベルで定義されています）。データベース3には重要な情報が含まれています。 – OverlordvI