9

多くのユーザーが MySQL データベースにアクセスできるアプリケーションがあります。今、私が混乱しているのは、ユーザーの管理方法です。私が見ているように、ユーザーには 2 つの異なるタイプがあります - APPLICATION ユーザーと DATABASE ユーザーです。これらは同じものであるべきですか、それとも異なるものですか？

説明しましょう。これは私が今それをどのように機能させているかです:

ユーザーがアプリケーションにログインすると、単一のデータベース アカウントが MySQL にログインし、アプリケーションのユーザー名が存在するかどうかを確認し、パスワード ハッシュを比較します。これらはすべて、MySQL の App Users テーブルに保存されます。これらのユーザーはすべて、同じ MySQL アカウントを使用してデータベースにアクセスします。

アプリ内の各ユーザーも個別の MySQL ユーザーにする必要がありますか?

4

1 に答える 1

9

データベースへのアクセスが制御されたアプリケーション (または Web サービス) を介してのみ許可されている場合、多くの場合、すべてのアプリケーションアカウントに対して1 つのデータベース アカウントが使用されます。これは、一元化されたユーザー管理のない環境で特に当てはまります。AD 上の SQL Server (たとえば、SharePoint の場合など) では、統合認証を使用することが実用的な場合があります。

理由は簡単です。

データベース アカウントをアプリケーション アカウントと同期しようとするのは悪夢です。また、アプリケーションがすべての SQL データ アクセスとクエリを制御するため (つまり、直接ログインがないため)、データベース アクセス レベルに関してユーザー A をユーザー B から分離する必要はほとんどありません。

この構成では、アプリケーションがユーザー アクセスの認証、承認、および識別を担当します。

そうは言っても、さまざまなレベルのアクセス権を持つさまざまなデータベース アカウントを持つことは良いことです。これらは次のようになります。

  1. app_user; 通常のアプリケーション ユーザーが行う必要があるすべてのことを行うことができます。不変の設計では、これにより、ほとんど/すべてのテーブルに対する削除/更新アクセスが除外される場合があります。さまざまなタイプの「通常の」ユーザー用に別のアカウントを作成したというケースにまだ遭遇したことはありません。繰り返しますが、この時点では、アクセスの責任はアプリケーションにあります。
  2. app_admin; app_user ができるすべてのことを実行でき、高レベルの管理者のみが持つべき特別なテーブルへの [更新] アクセス権を持っています。これは、実行中のアプリケーションの「ルート」アカウントです。このアカウントではスキーマの変更を許可しないでください。これは、ほとんどのアプリケーションの「ライブ」の側面ではありません。
  3. データベース管理者; まあ、データベースを変更できる人。重要なことは、このアカウントを使用してアプリケーションから接続しないことです。これは開発者/SA アカウントです。スキーマの変更を含め、すべてを行うことができます。

マルチテナント アプリケーションの場合、テナントごとに "app_user" アカウント (および場合によってはスキーマまたはデータベース) が存在する場合があります。

まだ別のオーセンティケーターを展開しているように聞こえるので、salt (大きなランダム) + ハッシュ (bcrypt/scrypt/pbkdf2 - no sha!)を正しく実装するために時間をかけてください。または、外部オーセンティケータまたは既存の精査済みライブラリを検討してください。そして、いつものように、プレースホルダーを使用してください。

于 2013-07-04T18:19:27.593 に答える