多くのユーザーを持つ Web アプリケーションを作成しています。各ユーザーは、アプリケーションにアクセスするための独自のログインとパスワードを持っています。アプリケーションのデータはデータベースに保存されます。
アプリケーションには多くのユーザーがいるため、アプリケーションを介してユーザーをデータベースに接続させる正しい方法を知りたいです。
データベースのユーザー (アカウント) を多数作成するか、単純にマスター/ルートを使用してアプリケーションからデータベースに接続する方がよいでしょうか?
編集/注: アプリケーション ユーザーはデータベースに直接アクセスできません。データベースはアプリケーションと同じサーバーにあり、外部アクセスに対して開かれません。
それぞれに長所と短所があります。
データベースへの認証に共有サービス アカウントを使用すると、データベースへの接続をより効率的にプールできるという利点があります。つまり、ユーザー間で接続を再利用できるため、各ユーザーが個別に認証する場合に必要となる、新しい接続を開くというコストのかかる操作を最小限に抑えることができます。明確な短所は、システムの最も強力なユーザーが実行できる必要があることをアカウントの権限で実行できる必要があるため、ユーザーが実行している SQL の検証に特に注意する必要があることです。
各ユーザーにアカウントを使用すると、アプリケーションに独自のカスタム承認スキームを実装する必要なく、さまざまなユーザーに権限を割り当てる際の柔軟性が高まります。また、DB 接続を確認すると、誰が接続されているかがわかるため、システムの監査が少し簡単になります。最後に、このアプローチにより、SQL インジェクションに対する脆弱性を軽減できます。つまり、各ユーザーのアカウントをロックダウンして (できれば DB プラットフォームでロールベースのセキュリティを使用して)、ユーザーに許可する必要があることだけを実行できるようにすることができます。
したがって、たとえば、何らかの方法で DELETE FROM UsersTable を挿入すると、それがロックされ、検証ロジックを通過したとしても、挿入されたコマンドは失敗します。
データベース ツール (特に MS Access) の使用方法を知っていて、データベース サーバーに直接アクセスできるユーザーがいる場合は、別の考慮事項があります。ユーザーごとの認証モデルを使用すると、経験豊富なユーザーがアプリケーションを迂回してデータベースに対して直接作業を行うという問題が発生する可能性があります。ユーザーが多数のプログラマーである場合は、共有アカウントを使用することをお勧めします。
少量のトランザクションを実行する多数の同時ユーザーによってアプリのトラフィックが非常に多い場合は、DB アクセスに共有サービス アカウントを使用します。
同時にシステムに接続するユーザーが少ない場合、またはオブジェクトへの承認のセキュリティや制御を強化したい場合は、アカウント/ユーザーごとのスキームを使用します。
標準的な解決策は、アプリケーションがデータベースに接続するための 1 つのマスター ログイン/パスワードを持つことです。次に、次のような列を持つテーブルを作成します。
パスワードはセキュリティ上の問題を引き起こすことに注意してください。パッケージを使用して認証を処理するか、この件についてよく読んでください。強力な暗号化なしでデータベースにユーザー パスワードを保存しないでください。