何年も前にこれに苦労したので、これが私が望んでいた答えです：
一般に、これは非常に複雑であり、基本的なアプリケーションの見出しの答えは次のとおりです。ユーザーのアクセス許可は、実行するAPI呼び出しのPHPコードによって管理され、1人のDBユーザーで問題ありません。すべてのユーザーは、データの神聖さを侵害することを防ぐために、一般的にDB forappdevと直接対話することを避ける必要があります。
セキュリティと制限について考えるのは良いことですが、シンプルさが重要です。複雑にするほど、保守が難しくなるため、コーナーケースを見逃しやすくなります。
新しいWebユーザーを登録するたびに、新しいデータベースユーザーを作成する必要がありますか？
いいえ、データベースユーザーは特権によって区別されます。その結果、すべてのユーザーは、さまざまな特権レベルを持つ一連のグループに準拠します。データベースアカウントはWebアカウントとは別のものです。データベースへの接続はバックグラウンドで行われ、使用されているWebアカウントへのリンクはありません。
DBに直接接続するサービスごとにDBアカウントを作成することをお勧めします。大多数の場合、これは1つのサービス、つまりWebサーバーになります。アプリケーションが成長し、監査、マイクロサービス、セキュリティ、IOTなどの分離されたサービスが発生した場合、それらはおそらく独自のアカウントを持っているはずです。
CRUD特権は、Webサイトのすべてのユーザーに安全に付与できますか？
質問は誤った方向に進んでいます。CRUDをDBアカウントに渡すと、それが必要になります。 PHP内で管理されるCRUD権限の場合、実際にはアプリと特定のエンドポイントによって異なります。たとえば、すべてのユーザーがユーザーレコードを削除できるようにしたくない場合は、PHPコードで削除できないようにする必要があります。
何種類のDBユーザーが必要ですか？
数はデータベースによって異なります。通常、4つのグループ>
- データベース管理者
- データベース設計者
- カジュアルエンドユーザー
- ネイティブエンドユーザー
ただし、テーブルレベルの権限を付与する場合は、もう少し分岐する必要があります。これは、10個のDBアカウントが非常に少量であることを示唆しています。
特権が多ければ多いほど、より多くのスペースが必要になりますが、これはかなり細かい考慮事項であり、パフォーマンスに大きな役割を果たすべきではありません。複雑さは次の問題です。実際にテストするグループと順列の数を慎重に検討してください。上記の質問の場合、私は1人の趣味の開発者でした。DBAとしての1つのアカウントでおそらく問題ありません。複数のユーザーがDBに直接アクセスしている場合（おそらくアプリ開発者にとっては悪い考えです）、さまざまな権限でそれらを分割する可能性があります。
単純なアプリのテーブルレベルの権限について話すのは、やり過ぎです！