16

ゴール

3 人のユーザーでデータベースを作成し、その権限を制限します (大声で考えているだけなので、ユーザーの分離も修正の余地があります)。

  1. スーパーユーザー - このユーザーは、データベースの最初のプロビジョニングを許可します。アプリケーション データベースを作成し、他のユーザーを作成して、権限を設定します。デフォルトpostgresのスーパーユーザーが機能するので、これで完了です。
  2. 管理者 - このユーザーは、プロビジョニング中に作成されたデータベースにのみアクセスできます。管理者はすべてのテーブルのすべてのデータをCRUDでき、テーブルなども CRUD できます。「このデータベースのみのスーパーユーザー」タイプの状況。アプリケーションが更新されている場合、管理者は、データベースの移行を処理するために自動ツールによって使用されるユーザーです。
  3. アプリ ユーザー - このユーザーは、最終的に Web アプリの機能をサポートするユーザーです。これは、Web ページなどのユーザーとは関係がないことに注意してください。これは、サーバーがクエリの実行、データの挿入および削除に利用するユーザーです。このユーザーが何かのアクセス許可を変更したり、テーブルやインデックス、または構造的なものを作成/破棄したりできないことを明示的に望んでいません。

私が試したこと

まず最初に、(一般的に優れた) PostgreSQL のドキュメントを見ると、Grant のページにかなり目がくらみます。PostgreSQL のロールと権限について数時間読んだ後、私は一般的に混乱しています。もう少し作業すれば、管理者ユーザーに必要なものを突き止めることができると思いますが、「アプリユーザー」にかなりこだわっています。私はここまで来ました (命名とパスワードはすべて単なるプレースホルダーです):

$ psql -U postgres
postgres=# CREATE USER "app-admin" WITH PASSWORD 'password';
CREATE ROLE
postgres=# CREATE USER "app-user" WITH PASSWORD 'password';
CREATE ROLE
postgres=# CREATE DATABASE "test-database" WITH OWNER "app-admin";
CREATE DATABASE
postgres=# \c "test-database"
You are now connected to database "test-database" as user "postgres".
test-database=# DROP SCHEMA "public";
DROP SCHEMA
test-database=# CREATE SCHEMA "app" AUTHORIZATION "app-admin";
CREATE SCHEMA

そして、ここで私は確信が持てなくなります。私が避けようとしている答えは、「デフォルトですべてを取り消してから、すべての異なるオブジェクトのすべての異なるレベルで必要なすべての特権を列挙する」ということだと思います。そこに何が必要なのかわからないので、それを避けようとしています。それが答えである場合、私はただ身を潜めてもっとたくさん読む必要がありますが、一般的に、そのような道をたどり始めると、何かを見落としています.

問題

権限を制限しapp-userて、構造データを変更できないようにする (たとえば、テーブルを追加または破棄できない) が、行に接続して何かを実行できるようにする (行レベルのセキュリティは私のレーダーにさえありません)。この特権の一般的なモデルは、PostgreSQL が期待するものと実際には同期していませんか? このようなことを達成するために、その「助成金」ページのすべてのオプションを確認しなければならない場合、何かが欠けているように感じます。それ。

環境

初めてのエンド ツー エンドの Web アプリケーションを構築しようとしています。私は一般的なソフトウェア開発と Web アプリ開発を十分に行ってきました。今では、日常的に当たり前のことと考えている部分を理解しようとしています。最小権限の原則を念頭に置きながら、PostgreSQL サーバーをセットアップしようとしています。

サイドクエスト

私が開発チームに参加したばかりの Web アプリでこれが行われたのを見たことはありませんが、それらは一般的に小規模であり、あまり使用されていません。これを行うと、実際に何かが達成されますか? このようなことをする理由、またはそれが悪いまたは効果のないアイデアである理由について、説得力のある理由を誰かが持っていますか? 最終的に SQL インジェクションの脆弱性に遭遇したとしても、データベース ユーザーのアクセスが制限されるため、被害が軽減されると想定していました。それは見当違いですか？

この件に関して私が見つけたきちんとした記事：

4

2 に答える 2