PostgreSQLの特権とセキュリティ-パブリックスキーマのロックダウン

はじめに

前回の記事では、PostgreSQLスキーマの理解の基本、作成と削除のメカニズムを紹介し、いくつかのユースケースを確認しました。この記事では、これらの基本事項を拡張し、スキーマに関連する特権の管理について説明します。

より多くの用語のオーバーロード

しかし、明確にする必要がある予備的な問題が1つあります。前回の記事で、「スキーマ」という用語のオーバーロードに関連する混乱の可能性のあるポイントについて詳しく説明したことを思い出してください。 PostgreSQLデータベースのコンテキストでのその用語の特殊な意味は、リレーショナルデータベース管理システムで一般的に使用される方法とは異なります。「パブリック」という単語に関連する現在のトピックについて、同様の可能性のある別の用語のカーファッフルがあります。

最初のデータベース作成時に、新しく作成されたPostgresqlデータベースには、「public」という名前の事前定義されたスキーマが含まれています。これは他のスキーマと同じですが、同じ単語が「すべてのユーザー」を表すキーワードとしても使用されます。そうでない場合は、...待機...スキーマ特権管理などの実際のロール名が使用される可能性があります。。以下の例で、重要性と2つの異なる用途を明らかにします。

スキーマ権限のクエリ

スキーマ特権を付与および取り消すためのサンプルコードを使用してこれを具体化する前に、スキーマ特権を調べる方法を確認する必要があります。 psqlコマンドラインインターフェイスを使用して、\dn+コマンドでスキーマと関連する特権を一覧表示します。新しく作成されたsampledbデータベースの場合、パブリックスキーマの次のエントリが表示されます。

sampledb=# \dn+ 
                          List of schemas
  Name  |  Owner   |  Access privileges   |      Description      
--------+----------+----------------------+------------------------
 public | postgres | postgres=UC/postgres+| standard public schema
        |          | =UC/postgres         |
(1 row)

最初の2列と4列目は非常に単純です。前述のように、「public」という名前のデフォルトで作成されたスキーマを示し、「標準のパブリックスキーマ」と呼ばれ、「postgres」の役割によって所有されます。（スキーマの所有権は、特に指定されていない限り、スキーマを作成する役割に設定されます。）アクセス権をリストする3番目の列は、ここで重要です。特権情報の形式は、特権付与者、特権、および「grantee =privacy / grantor」の形式の特権付与者の3つの項目を提供します。つまり、等号の左側には、特権を受け取る役割があります。等号のすぐ右側には、特定の特権を指定する文字のグループがあり、最後にスラッシュの後に特権に付与された役割があります。特権は付加的であるため、プラス記号で区切られてリストされている、そのような特権情報の仕様が複数存在する場合があります。

スキーマの場合、別々に付与できる2つの特権があります。「USAGE」の場合はU、「CREATE」の場合はCです。前者は、スキーマに含まれるテーブルやビューなどのデータベースオブジェクトをルックアップする機能を持つロールに必要です。後者の特権により、ロールはスキーマにデータベースオブジェクトを作成できます。さまざまなタイプのデータベースオブジェクトに関連する他の特権については他の文字がありますが、スキーマについては、UとCのみが適用されます。

したがって、上記の特権リストを解釈するために、最初の仕様は、postgresユーザーにパブリックスキーマでの更新と作成の特権が付与されたことを示しています。

上記の2番目の仕様では、等号の左側に空の文字列が表示されていることに注意してください。これは、前述のPUBLICキーワードによってすべてのユーザーに付与された特権が示される方法です。

すべてのユーザーにパブリックスキーマの使用と作成特権を付与するという後者の仕様は、一般的なセキュリティ原則のベストプラクティスに反していると見なされる場合があります。この場合、デフォルトで制限されたアクセスから開始し、データベース管理者が適切なものを明示的に付与する必要があります。最低限必要なアクセス権限。パブリックスキーマに対するこれらのリベラルな特権は、利便性とレガシー互換性のためにシステムで意図的に構成されています。

また、許可特権の設定を除いて、パブリックスキーマについて特別なことは、前の記事で説明したように、それがsearch_pathにもリストされていることだけです。これも同様に便宜上です。search_path構成とリベラルな特権を組み合わせると、スキーマなどの概念がないかのように新しいデータベースを使用できるようになります。

パブリックスキーマの歴史的背景

この互換性の懸念は、スキーマ機能がPostgreSQLの一部ではなかった約15年前（PostgreSQLバージョン7.3より前、バージョン7.3リリースノートを参照）に起因します。自由な特権を持つパブリックスキーマの構成と、バージョン7.3でスキーマが導入されたときのsearch_pathの存在により、スキーマに対応していない古いアプリケーションとの互換性が可能になり、アップグレードされたデータベース機能を変更せずに機能できるようになりました。

それ以外の場合、パブリックスキーマについて特に特別なことは何もありません。一部のDBAは、ユースケースでパブリックスキーマの要件がない場合はそれを削除します。他の人はデフォルトの特権を取り消すことによってそれをロックダウンします。

コードを表示-権限を取り消す

これまでに説明したことを説明し、拡張するために、いくつかのコードを実行してみましょう。

スキーマ特権は、GRANTコマンドとREVOKEコマンドで管理され、それぞれ特権を追加および撤回します。パブリックスキーマをロックダウンするための具体的な例をいくつか試してみますが、一般的な構文は次のとおりです。

REVOKE [ GRANT OPTION FOR ]
    { { CREATE | USAGE } [, ...] | ALL [ PRIVILEGES ] }
    ON SCHEMA schema_name [, ...]
    FROM { [ GROUP ] role_name | PUBLIC } [, ...]
    [ CASCADE | RESTRICT ]

したがって、最初のロックダウンの例として、パブリックスキーマから作成権限を削除しましょう。これらの例では、小文字の「public」はスキーマを指し、データベースに存在する可能性のある他の有効なスキーマ名に置き換えることができることに注意してください。大文字の「PUBLIC」は「すべてのユーザー」を意味する特別なキーワードであり、代わりに特定の役割名または役割名のコンマ区切りのリストに置き換えて、よりきめ細かいアクセス制御を行うことができます。

sampledb=# REVOKE CREATE ON SCHEMA public FROM PUBLIC;
REVOKE
sampledb=# \dn+
                          List of schemas
  Name  |  Owner   |  Access privileges   |      Description       
--------+----------+----------------------+------------------------
 public | postgres | postgres=UC/postgres+| standard public schema
        |          | =U/postgres          | 
(1 row)

このスキーマ特権のリストと最初のリストとの唯一の違いは、2番目の特権仕様に「C」がないことです。コマンドが有効であったことを確認します。postgresユーザー以外のユーザーは、テーブル、ビュー、またはその他のオブジェクトを作成できなくなります。パブリックスキーマ。

パブリックスキーマからの作成権限を取り消す上記のコマンドは、最近公開された脆弱性CVE-2018-1058の推奨される緩和策であることに注意してください。これは、パブリックスキーマのデフォルトの権限設定から発生します。

さらなるレベルのロックダウンでは、使用特権を削除することにより、スキーマへのルックアップアクセスを完全に拒否する必要があります。

sampledb=# REVOKE USAGE ON SCHEMA public FROM PUBLIC;
REVOKE
sampledb=# \dn+
                          List of schemas
  Name  |  Owner   |  Access privileges   |      Description       
--------+----------+----------------------+------------------------
 public | postgres | postgres=UC/postgres | standard public schema
(1 row)

所有者以外のユーザーが利用できるすべてのスキーマ特権が取り消されたため、2番目の特権仕様全体が上記のリストに表示されなくなります。

2つの別々のコマンドで行ったことは、すべての特権を次のように指定する1つのコマンドで簡潔に実行できたはずです。

sampledb=# REVOKE ALL PRIVILEGES ON SCHEMA public FROM PUBLIC;
REVOKE

さらに、スキーマ所有者から特権を取り消すこともできます：

sampledb=# REVOKE ALL PRIVILEGES ON SCHEMA public FROM postgres;
REVOKE
sampledb=# \dn+
                        List of schemas
  Name  |  Owner   | Access privileges |      Description       
--------+----------+-------------------+------------------------
 public | postgres |                   | standard public schema
(1 row)

ただし、スキーマの所有者は、所有権のおかげで明示的に割り当てられているかどうかに関係なく、所有されているスキーマに対する完全な特権を保持しているため、実際には何も達成されません。

パブリックスキーマのリベラルな特権の割り当ては、最初のデータベース作成に関連する特別なアーティファクトです。既存のデータベースに後で作成されるスキーマは、特権を割り当てずに開始するというベストプラクティスに準拠しています。たとえば、「private」という名前の新しいスキーマを作成した後でスキーマ特権を調べると、新しいスキーマには特権がないことがわかります。

sampledb=# create schema private;
CREATE SCHEMA
sampledb=# \dn+
                          List of schemas
  Name   |  Owner   |  Access privileges   |      Description       
---------+----------+----------------------+------------------------
 private | postgres |                      | 
 public  | postgres |                      | standard public schema
(2 rows)

今日のホワイトペーパーをダウンロードするClusterControlを使用したPostgreSQLの管理と自動化PostgreSQLの導入、監視、管理、スケーリングを行うために知っておくべきことについて学ぶホワイトペーパーをダウンロードする

コードを表示-権限の付与

特権を追加するコマンドの一般的な形式は次のとおりです。

GRANT { { CREATE | USAGE } [, ...] | ALL [ PRIVILEGES ] }
    ON SCHEMA schema_name [, ...]
    TO role_specification [, ...] [ WITH GRANT OPTION ]
where role_specification can be:
  [ GROUP ] role_name
  | PUBLIC
  | CURRENT_USER
  | SESSION_USER

このコマンドを使用すると、たとえば、

を使用して使用権限を追加することにより、すべてのロールがプライベートスキーマ内のデータベースオブジェクトを検索できるようにすることができます。

sampledb=# GRANT USAGE ON SCHEMA private TO PUBLIC;
GRANT
sampledb=# \dn+
                          List of schemas
  Name   |  Owner   |  Access privileges   |      Description       
---------+----------+----------------------+------------------------
 private | postgres | postgres=UC/postgres+| 
         |          | =U/postgres          | 
 public  | postgres |                      | standard public schema
(2 rows)

スキーマにデフォルト以外の特権を割り当てたので、最初の仕様としてpostgres所有者にUC特権がどのように表示されるかに注意してください。 2番目の指定=U/ postgresは、すべてのユーザーに使用特権を付与するユーザーpostgresとして呼び出したGRANTコマンドに対応します（ここで、等号の左側の空の文字列は「すべてのユーザー」を意味します）。

たとえば、「user1」という名前の特定のロールには、次の方法でプライベートスキーマに対する作成権限と使用権限の両方を付与できます。

sampledb=# GRANT ALL PRIVILEGES ON SCHEMA private TO user1;
GRANT
sampledb=# \dn+
                          List of schemas
  Name   |  Owner   |  Access privileges   |      Description       
---------+----------+----------------------+------------------------
 private | postgres | postgres=UC/postgres+| 
         |          | =U/postgres         +| 
         |          | user1=UC/postgres    | 
 public  | postgres |                      | standard public schema
(2 rows)

一般的なコマンドフォームの「WITHGRANTOPTION」句についてはまだ触れていません。聞こえるように、この句は、付与されたロールに、それ自体が指定された特権を他のユーザーに付与する権限を許可します。これは、特権リストで、特定の特権に追加されたアスタリスクで示されます。

sampledb=# GRANT ALL PRIVILEGES ON SCHEMA private TO user1 WITH GRANT OPTION;
GRANT
sampledb=# \dn+
                          List of schemas
  Name   |  Owner   |  Access privileges   |      Description       
---------+----------+----------------------+------------------------
 private | postgres | postgres=UC/postgres+| 
         |          | =U/postgres         +| 
         |          | user1=U*C*/postgres  | 
 public  | postgres |                      | standard public schema
(2 rows)

結論

これで今日のトピックは終わりです。ただし、最後に、スキーマアクセス権限についてのみ説明したことを忘れないでください。 USAGE特権では、スキーマ内のデータベースオブジェクトを検索できますが、読み取り、書き込み、実行などの特定の操作のためにオブジェクトに実際にアクセスするには、ロールはそれらの特定のデータベースオブジェクトに対するそれらの操作に対して適切な特権も持っている必要があります。