私は仕事中の小さな内部Webアプリケーションを始めました。これは主に概念実証ですが、実際のアプリケーションのように扱いたいと思っています。私はDBAとしての経験はあまりなく、私のグループの人もそうではありません（PoCであるため、特に重要なことはありません）。異なるクエリタイプに対して別々のSQLアカウントを設定する必要がありますか？
私は、このWebアプリケーションが公開されていれば、異なるクエリタイプのDBサーバーに別々のアカウントを持っているべきですか？例えば。 SELECTクエリのための1つのSQLアカウントと、UPDATE/DELETEのためのもう1つのSQLアカウントを持っていますか？私はそうすることに特別な利点があると自分自身に確信することはできませんが、私はその技術を聞いたことがあるので、ある程度の価値があるはずです。
さまざまな種類のタスク（バッチジョブとWebサービスなど）に異なるアカウントを持ち、それぞれに接続数などを制限すると便利です。つまり、バッチジョブが狂ったら、あなたのWebアプリケーションを取り出すことはできません。
また、異なる権限の異なるアカウントが必要な場合もあります。たとえば、管理者とユーザーのアプリが別々の場合は、自分のアカウントを持つ必要があります。これは、ユーザーのアプリケーションが侵害された場合、データに大きなダメージを与えることができないようにするのに役立ちます。
この2つの点では、アプリケーションが書き込みを行わない場合にのみ、「読み取り専用」ユーザーを持つと便利です。
クエリタイプには別のアカウントは必要ありません。通常、データベースへの接続は、Webアプリケーションにアクセスするユーザーとは関係のないデータベースユーザーを使用します。
匿名ユーザーがサイトにアクセスする際に使用されるメインアカウントがアクセスできるクエリの種類を制限することができます。しかし、私はそのサブセット内でクエリごとに別のユーザーが必要とは思わない。
あなたが注目したいのは、特定の種類のクエリではなく、各ユーザーがアクセスできるデータベース/テーブルです。
の両方のアプリケーションで使用されているこれらの勘定タイプは、私があなたが指している練習がsql injection attacksを回避しようとしていると思います。あなたの入力を確実に害さないようにするには、おそらく必要ありません。覚えておいてくださいbobby tables！
読み取り専用アカウントのもう1つの理由は、管理者がシステムアクティビティと生産上の問題をデバッグする際にdb上で直接レポートを実行できるようにするためです。
「公開」アプリケーションでは、サービスアカウントを使用してデータベースにアクセスし（クエリの実行、ストアドプロシージャの実行）、コードレベルでのユーザーアクセス制御を計算することをお勧めします。
これにより、新しいユーザーをデータベースのセキュリティマネージャに追加する必要がなくなります。
別のSQLデータベースアカウントが使用されているのを見たことがあるのは、アプリケーション機能を分離することだけであり、それでもサービスアカウントです。すなわち
を削除し、ReportServiceの
これらの2つの概念を組み合わせて（コード内のユーザーアクセス、サービスの機能差別）、ユーザーアクセス制御メカニズムが機能していることを効果的に単体テストできます。それ以外の場合は、データベースにユーザーを設定してから、データベースからどのような動作を得るかを確認する必要があります。
はい。 Principle of least privilegeを参照してください。最小限 特権またはちょうど最小特権の原則として知られても、情報セキュリティ、コンピュータ 科学、および他の分野で
、最小特権の 原理は、 、 が必要との特定の 抽象化レイヤでコンピューティング環境 、（例えば プロセスとして、我々が検討している層の 基づいて、ユーザまたはプログラム）すべてのモジュール は、そのlegitimaに必要 ているだけな の情報やリソースにアクセスできる必要がありますテー 目的。 1 [2]のユーザーに適用された場合、すべての回で、すべてのユーザーが が 限り少ない権限で実行する必要があり 概念に言及少なくとも 用語ユーザアクセスや 最小特権ユーザーアカウント（LUA） も使用され、できるだけ少ない特権でアプリケーション を起動してください。
企業がこの原則を受け入れるのに役立つ多くの技術があります。多くの人々は、各階層のエンドユーザーのアイデンティティを維持し、質問に答えることに重点を置いた技術と同じカテゴリーに分類されます。
「本当のユーザー」は誰ですか？
最小権限の原則を無視し、中間層/アプリケーションサーバーとデータベース間のすべての対話に単一の共有データベースユーザーアカウントを使用することの決定結果とリスクには、少なくとも注意する必要があります。データベースアプリケーション開発者としての生産性を維持し、アプリケーションに堅牢なセキュリティ機能を提供する方法もあります。この空間での技術の
例としては、これらに限定されない：
セキュリティ以外にも最小特権の原則を採用することには他にも利点があります。多くのデータベースでは、読み取り専用接続は、トランザクションを認識したりトランザクションに参加したりする必要がないため、パフォーマンスが向上します。
「SQLアカウント」についての質問です。あなたの答えは冗長です。 – tialaramex