アプリケーションのユーザーごとに個別のデータベースアカウントを使用するのは良い習慣ですか？

私が使用しているアプリケーションはサーバーベースであり、多くのユーザーに対して1つのデータベースアカウントを使用します。アプリケーションコードは、ユーザーができることまたはシングルユーザーを制御します。

各ユーザーが独自のデータベースアカウントを必要とし、データベースサーバーが各ユーザーに許可および禁止すべきことに関するポリシールールの実施に依存している、成功した複雑なビジネスアプリケーションはありますか？

複数の人が1つのデータベースの情報に貢献し、他の人（たとえば、顧客レコードにすべてアクセスする必要がある組織内の同僚）が保存した情報にアクセスできるアプリケーションについて考えています。

このタイプのセットアップには名前もありますか？

データレベルで実施される本当に厳密な制御が必要な場合。たとえば、広範囲にわたる監査。複数のユーザーが同じアカウントを共有している場合、監査はあまり良くありません。データデータベースに直接アクセスする必要があるユーザーがいる場合。

セキュリティがそれほど厳しくない場合、通常はデータベースを直接公開することさえしません。サービスがあり、クライアントはサービスからデータを取得する必要があります。

Webアプリケーションでは、通常、データベース（ポート1433など）は直接公開されないため、セキュリティレベルがあります。Webアプリケーションは、ユーザーがまだ持っていないデータベースに直接アクセスした場合でも、直接データベースへのアクセスを。

ログインとパスワードがクライアントアプリケーションにある場合、ハッキングされる可能性があります。ドメインの場合、統合セキュリティを使用できます。

データベースでは、非常に細かい制御が可能です。しかし、行レベルの制御は少し作業です。データベースはビジネスルールに適したツールではありません。通常、ビジネスルールと詳細なセキュリティはアプリケーションレベルで適用されます。

管理者が使用するストアドプロシージャがいくつかあり、どの管理者を追跡するかを混在モードにすることができます。また、レポートを直接生成するユーザーに読み取り専用アクセスを許可できます。

ここでの課題は、データベースアクセスが抽象化によって管理されることです。ユーザーが自分で接続する代わりに、ユーザーは基本的に、一般化されたアプリケーションロールのIDを引き継ぎます。個々の接続の可視性が失われるだけでなく、すべての個々のユーザーに対して異なるタイプのアクセスを定義する粒度も失われます。

このアプローチを使用する主な理由は単純さです。多くのアプリケーションは、アプリケーションのユーザーがデータベースの知識を持たないように設計されています。特にアプリケーションが独自の内部セキュリティを管理している場合、彼らは本当にそれを必要としません。ほとんどの個々のユーザーはデータベースに直接接続することはないので、明示的なログインを定義する必要はありません。

データベースにセキュリティを管理させることを考慮する必要があるのは、データベースに直接接続するユーザーがいる場合のみです。これは、彼らがあなたのアプリケーションを迂回していることを意味し、それ自体ではセキュリティを強制することができません。ここでの利点は、セキュリティをより詳細に定義できることです。欠点は、ユーザーとそのアクセス許可を管理するためのオーバーヘッドが高いことです。

この種のアクセスの必要性を感じている場合は、役割ベースのアクセス制御を使用します。データベース内で必要なアクセス許可の種類に基づいてロールを定義し、それらのロールの下で個々のユーザーをグループ化する必要があります。これにより、セキュリティモデルの監査と制御が向上し、直接アクセスを管理するときに制御不能になります。

これにはハイブリッドアプローチがあります。データベースによってセキュリティを部分的に管理する場合は、複数のアプリケーションユーザーを作成し、各ユーザーをロールで定義し、それらのユーザーが果たすロールに基づいてそれらのユーザーに明示的にアクセスを許可します。つまり、セキュリティモデルの一部でデータベースエンジンを活用できますが、それでもアプリケーション内で何らかの管理が必要です。これにより、アプリケーションのユーザーモデルの複雑さが増しますが、使用中のさまざまなログインの粒度が細かくなります。

できるだけ早く、最も詳細なレベルでセキュリティの実施を開始する必要があります。この点でロールが役立ちます-一度に多くのテーブルにアクセスできるようにすることは悪夢ではありません。

皆のための単一のアカウントは、ここや他の場所での素晴らしい質問源です-「レコードxが削除されました。誰がそれをしたのかを知るにはどうすればいいですか？」-答えはできません-個々のアカウントと監査なし。

「監査」とは、すべての人がアカウントを持っていることはすべて非常に良好ですが、それはあなたが本当のセキュリティを持っているという意味ではありません。たとえば、HRテーブル内のレコードが削除された場合、HRテーブルへのアクセス権を持つ誰かがそれを行った、つまりx人がいるということしかわかりません。

システムに、アクションXを実行した個々のレベルまで追跡できるようにアクションをログに記録するトリガーが必要です（これを自動化できるOracleなどのRDBMSがない場合）。

いずれの場合も、常にできるだけ早くセキュリティをきめ細かくする必要があります。「知る必要がある」人だけがテーブルにアクセスできるようにします。そして、常にテーブルへのアクションのタイムスタンプを含めます-人々は頻繁に他の人にIDを与えます-「ジミー、あなたは17時49分にオフィスで唯一の人でした...」と言うことができるなら矢筒の別の矢印。

RDBMSを提供してくれたなら、あなたの状況により具体的/関連性のあるアドバイスを得ることができますか？

はい、そうです。単一の強力なユーザーとしてアプリケーションからデータベースに接続することは、最小特権の原則に違反します。これは、ほとんどのSQLインジェクション攻撃の根本的な原因です。

これは通常、無知のために、単純化のため、またはパフォーマンスのために行われます。

多くの場合、データベースは長寿命であり、同時に複数のアプリケーションによって使用されます。複数のアプリケーションを使用する代わりに、データベースでアクセス制御を集中化することにより、リソースを節約できます。

行セキュリティ、列セキュリティ、および偽装/プロキシ認証をサポートするデータベースサーバー（実際のデータベースユーザー+接続プーリングをサポート）を選択する必要があります。

また、Wordpressなどの「プラグイン」ベースのアプリケーションの場合は、未熟なプラグイン作成者が原因でSQLインジェクションを回避するのが難しいため、より安全です。各プラグインは、アプリケーション全体ではなく、dbログインを取得します。