PostgreSQLデータベースを保護する方法-10のヒント

PostgreSQLデータベースサーバーのインストールプロセスが完了したら、本番環境に移行する前にサーバーを保護する必要があります。この投稿では、データベースのセキュリティを強化して、データを安全に保つ方法を紹介します。

1。クライアント認証制御

PostgreSQLをインストールすると、データベースクラスターのデータディレクトリにpg_hba.confという名前のファイルが作成されます。このファイルはクライアント認証を制御します。

postgresqlの公式ドキュメントから、pg_hba.confファイルを1行に1つずつのレコードのセットとして定義できます。各レコードは、接続タイプ、クライアントIPアドレス範囲（接続タイプに関連する場合）、データベース名、ユーザー名、およびこれらのパラメーターに一致する接続に使用される認証方法。接続タイプ、クライアントアドレス、要求されたデータベース、およびユーザー名が一致する最初のレコードは、認証を実行するために使用されます。

したがって、一般的な形式は次のようになります。

# TYPE  DATABASE        USER            ADDRESS                 METHOD

構成の例は次のとおりです。

# Allow any user from any host with IP address 192.168.93.x to connect
# to database "postgres" as the same user name that ident reports for
# the connection (typically the operating system user name).
#
# TYPE  DATABASE        USER            ADDRESS                 METHOD
 host     postgres              all             192.168.93.0/24         ident
# Reject any user from any host with IP address 192.168.94.x to connect
# to database "postgres
# TYPE  DATABASE        USER            ADDRESS                 METHOD
 host     postgres              all             192.168.94.0/24         reject

ルールを改良するために作成できる組み合わせはたくさんありますが（公式ドキュメントには各オプションが詳細に説明されており、いくつかの優れた例があります）、DATABASEallまたはADDRESSを使用して回線へのアクセスを許可するなどの許容度が高すぎるルールは避けてください。 0.0.0.0/0。

セキュリティを確保するために、ルールを追加するのを忘れた場合でも、下部に次の行を追加できます。

# TYPE  DATABASE        USER            ADDRESS                 METHOD
 host     all              all             0.0.0.0/0         reject

ファイルを上から下に読み取って一致するルールを見つけると、このようにして、アクセス許可を許可するために、上記の一致するルールを明示的に追加する必要があります。

2。サーバー構成

postgresql.confには、セキュリティを強化するために変更できるパラメータがいくつかあります。

パラメータlisten_addressを使用して、サーバーへの接続を許可するIPを制御できます。これは、既知のIPまたはネットワークからの接続のみを許可し、PostgreSQLに任意のIPからの接続を受け入れるように指示する「*」、「0.0.0.0：0」、「::」などの一般的な値を避けるための良い方法です。

postgresqlがリッスンするポート（デフォルトでは5432）を変更することもオプションです。これを行うには、ポートパラメータの値を変更します。

work_mem、maintenance_work_mem、temp_buffer、max_prepared_transactions、temp_file_limitなどのパラメーターは、サービス拒否攻撃が発生した場合に備えて覚えておくことが重要です。これらは、さまざまなレベル（db、user、session）で設定できるステートメント/セッションパラメータであるため、これらを適切に管理することで、攻撃の影響を最小限に抑えることができます。

3。ユーザーと役割の管理

ユーザー管理に関するセキュリティの黄金律は、ユーザーに必要な最小限のアクセスを許可することです。

これを管理することは必ずしも簡単ではなく、最初からうまく行わないと、非常に厄介になる可能性があります。

特権を管理下に置く良い方法は、役割、グループ、ユーザー戦略を使用することです。

postgresqlではすべてが役割と見なされますが、これにいくつかの変更を加える予定です。

この戦略では、3つの異なるタイプまたは役割を作成します。

役割の役割（プレフィックスr_で識別）
グループの役割（プレフィックスg_で識別）
ユーザーの役割（通常は個人名またはアプリケーション名）

ロール（r_roles）は、オブジェクトに対する特権を持つものになります。グループロール（g_ロール）にはr_ロールが付与されるため、r_ロールのコレクションになります。そして最後に、ユーザーロールには1つ以上のグループロールが付与され、ログイン権限を持つものになります。

この例を示しましょう。 example_schemaの読み取り専用グループを作成し、それをユーザーに付与します：

読み取り専用の役割を作成し、それにオブジェクト権限を付与します

CREATE ROLE r_example_ro NOSUPERUSER INHERIT NOCREATEDB NOCREATEROLE NOREPLICATION;
GRANT USAGE ON SCHEMA example to r_example_ro;
GRANT SELECT ON ALL TABLES IN SCHEMA example to r_example_ro;
ALTER DEFAULT PRIVILEGES IN SCHEMA example GRANT SELECT ON TABLES TO r_example_ro;

読み取り専用グループを作成し、そのグループに役割を付与します

CREATE ROLE g_example_ro NOSUPERUSER INHERIT NOCREATEDB NOCREATEROLE NOREPLICATION';
GRANT r_example_ro to g_example_ro;

app_userロールを作成し、読み取り専用グループに「参加」させます

CREATE ROLE app_user WITH LOGIN ;
ALTER ROLE app_user WITH PASSWORD 'somePassword' ;
ALTER ROLE app_user VALID UNTIL 'infinity' ;
GRANT g_example_ro TO app_user;

この方法を使用すると、特権の粒度を管理でき、ユーザーへのアクセスのグループを簡単に付与および取り消すことができます。ユーザーに直接オブジェクト権限を付与するのではなく、ロールにオブジェクト権限のみを付与し、ユーザーにのみログイン権限を付与することを忘れないでください。

これは、特定のデータベースへのパブリックアクセスを取り消して、ロールを介してのみ付与するなど、オブジェクトに対するパブリック特権を明示的に取り消すための良い方法です。

REVOKE CONNECT ON my_database FROM PUBLIC;
GRANT CONNECT ON my_database TO r_example_ro;

SUPERUSERアクセスを制限し、localhost/unixドメインからのスーパーユーザー接続のみを許可します。

特定のアプリユーザーやバックアップユーザーなど、さまざまな目的で特定のユーザーを使用し、必要なIPからのみそのユーザーの接続を制限します。

4。スーパーユーザー管理

強力なパスワードポリシーを維持することは、データベースを安全に保ち、パスワードのハッキングを回避するために必須です。強力なポリシーの場合は、特殊文字、数字、大文字と小文字を優先的に使用し、10文字以上にします。

LDAPやPAMなどの外部認証ツールもあり、パスワードの有効期限と再利用ポリシーを確認し、認証エラーでのアカウントのロックを処理するのに役立ちます。

5。データ暗号化（接続SSL）

PostgreSQLは、SSL接続を使用してクライアント/サーバー通信を暗号化し、セキュリティを強化するためのネイティブサポートを備えています。 SSL（Secure Sockets Layer）は、Webサーバーとブラウザーの間に暗号化されたリンクを確立するための標準的なセキュリティテクノロジーです。このリンクにより、Webサーバーとブラウザ間で渡されるすべてのデータがプライベートで統合されたままになります。

postgresqlクライアントはプレーンテキストでクエリを送信し、データも暗号化されずに送信されるため、ネットワークのなりすましに対して脆弱です。

postgresql.confでsslパラメータをonに設定することでSSLを有効にできます。

サーバーは、同じTCPポートで通常の接続とSSL接続の両方をリッスンし、SSLを使用するかどうかについて接続しているクライアントとネゴシエートします。デフォルトでは、これはクライアントのオプションですが、上記のpg_hba構成ファイルを使用して、一部またはすべての接続でSSLの使用を要求するようにサーバーをセットアップするオプションがあります。

6。保管時のデータ暗号化（pg_crypto）

暗号化には、1つの方法と2つの方法の2つの基本的な種類があります。ある意味では、データを読み取り可能な形式に復号化する必要はありませんが、基になる秘密のテキストが何であるかをユーザーが知っていることを確認したいだけです。これは通常、パスワードに使用されます。双方向の暗号化では、データを暗号化する機能と、許可されたユーザーがデータを意味のある形式に復号化できるようにする機能が必要です。クレジットカードやSSNなどのデータはこのカテゴリに分類されます。

一方向の暗号化の場合、pgcryptoにパッケージ化されたcrypt関数は、md5の方法よりも高いレベルのセキュリティを提供します。その理由は、md5では、ソルトがないために誰が同じパスワードを持っているかがわかるためです（暗号化では、ソルトは、データを「ハッシュ」する一方向関数への追加入力として使用されるランダムデータであり、パスワードです。またはパスフレーズ）、同じパスワードを持つすべての人が同じエンコードされたmd5文字列を持ちます。クリプトを使用すると、それらは異なります。

取得したいデータの場合、2つの情報が同じであるかどうかは知りたくありませんが、その情報はわかりません。また、許可されたユーザーのみが情報を取得できるようにする必要があります。 Pgcryptoにはこれを実現するためのいくつかの方法が用意されているため、Pgcryptoの使用方法の詳細については、https：//www.postgresql.org/docs/current/static/pgcrypto.htmlにある公式のpostgresqlドキュメントを確認してください。

7。ロギング

Postgresqlは、何を、いつ、どこでログに記録するかを制御するためのさまざまな構成パラメーターを提供します。

セッションの接続/切断、長時間実行されるクエリ、一時ファイルのサイズなどを有効にできます。これは、奇妙な振る舞いを特定するために、ワークロードについての知識を深めるのに役立ちます。次のリンクでロギングのすべてのオプションを取得できますhttps://www.postgresql.org/docs/9.6/static/runtime-config-logging.html

ワークロードの詳細については、サーバーによって実行されたすべてのSQLステートメントの実行統計を追跡する手段を提供するpg_stat_statementsモジュールを有効にすることができます。予想されるパターンに従わないクエリを特定するのに役立つように、このテーブルからデータを取り込み、SQLホワイトリストを生成するセキュリティツールがいくつかあります。

詳細については、https：//www.postgresql.org/docs/9.6/static/pgstatstatements.htmlをご覧ください。

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

8。監査

PostgreSQL Audit Extension（pgAudit）は、標準のPostgreSQLログ機能を介して詳細なセッションおよび/またはオブジェクト監査ログを提供します。

基本的なステートメントロギングは、log_statement=allの標準ロギング機能によって提供できます。これは、監視やその他の使用法では許容されますが、監査に一般的に必要な詳細レベルは提供されません。データベースに対して実行されたすべての操作のリストを用意するだけでは不十分です。また、監査人が関心を持つ特定のステートメントを見つけることが可能でなければなりません。標準のロギング機能はユーザーが要求したものを表示しますが、pgAuditはデータベースが要求を満たしている間に何が起こったかの詳細に焦点を合わせます。

9。パッチ適用

重要なセキュリティアップデートとパッチについては、PostgreSQLのセキュリティ情報ページを定期的かつ頻繁に確認してください。

OSまたはライブラリのセキュリティバグもデータベースリークにつながる可能性があることに注意してください。そのため、これらのパッチを最新の状態に保つようにしてください。

ClusterControlは、この情報を提供し、パッチとアップグレードを実行する運用レポートを提供します。

10。行レベルのセキュリティ

GRANTを介して利用できるSQL標準の特権システムに加えて、テーブルには、ユーザーごとに、通常のクエリで返される行、データ変更コマンドで挿入、更新、削除できる行を制限する行セキュリティポリシーを設定できます。この機能は、行レベルのセキュリティとも呼ばれます。

テーブルで行セキュリティが有効になっている場合、行を選択したり行を変更したりするためのテーブルへの通常のアクセスはすべて、行セキュリティポリシーによって許可されている必要があります。

これは、アカウント関係に関するポリシーを作成して、マネージャーロールのメンバーのみが行にアクセスできるようにし、アカウントの行のみにアクセスできるようにする簡単な例です。

CREATE TABLE accounts (manager text, company text, contact_email text);
ALTER TABLE accounts ENABLE ROW LEVEL SECURITY;
CREATE POLICY account_managers ON accounts TO managers USING (manager = current_user);

この機能の詳細については、公式のpostgresqlドキュメントhttps://www.postgresql.org/docs/9.6/static/ddl-rowsecurity.html

を参照してください。

詳細を知りたい場合は、データベースのセキュリティを強化するのに役立つリソースをいくつか紹介します…

https://www.postgresql.org/docs/9.6/static/auth-pg-hba-conf.html
https://www.postgresql.org/docs/9.6/static/ssl-tcp.html
https://www.postgresql.org/docs/current/static/pgcrypto.html
http://www.postgresonline.com/journal/archives/165-Encrypting-data-with-pgcrypto.html
https://github.com/pgaudit/pgaudit
https://www.postgresql.org/docs/9.6/static/pgstatstatements.html

結論

上記のヒントに従うと、サーバーの安全性は高まりますが、これはサーバーが壊れないという意味ではありません。

独自のセキュリティのために、Nessusなどのセキュリティテストツールを使用して、主な脆弱性を把握し、それらを解決することをお勧めします。

ClusterControlを使用してデータベースを監視することもできます。これにより、データベース内で何が起こっているかをリアルタイムで確認し、分析することができます。