Azure Database for PostgreSQL フレキシブル サーバーのセキュリティ

適用対象: Azure Database for PostgreSQL - フレキシブル サーバー

Azure Database for PostgreSQL フレキシブル サーバー インスタンス上のデータを保護するために、複数のセキュリティ レイヤーを使用できます。 この記事では、これらのセキュリティ オプション概説しています。

企業は、競争の優位性を高める重要な意思決定活動を推進するために、データベースの格納データにますます依存しており、堅牢なデータベース セキュリティ対策の必要性はかつてないほど高まっています。 セキュリティ上の欠陥は、機密データの公開を含む致命的な結果を引き起こすおそれがあり、組織が風評被害にさらされる場合があります。

情報の保護と暗号化

Azure Database for PostgreSQL フレキシブル サーバーは、次の 2 つの方法でデータを暗号化します。

• 転送中のデータ: Azure Database for PostgreSQL フレキシブル サーバーは、Secure Sockets Layer と Transport Layer Security (SSL/TLS) を使用して転送中のデータを暗号化します。 暗号化は既定で適用されます。 SSL\TLS を使用した接続セキュリティの詳細については、この ドキュメントを参照してください。 セキュリティを強化するために、 Azure Database for PostgreSQL フレキシブル サーバーで SCRAM 認証を有効にすることを選択できます。

  推奨されませんが、必要に応じて、レガシ クライアントの非互換性のため、require_secure_transport サーバー パラメーターを OFF に更新することで、TLS\SSL と非 TLS/SSL の両方のフレキシブル サーバーへの接続を許可するオプションがあります。 ssl_max_protocol_version サーバー パラメーターを設定することで、TLS バージョンを設定することもできます。

• 保存データ: ストレージ暗号化の場合、Azure Database for PostgreSQL フレキシブル サーバーは FIPS 140-2 検証済み暗号化モジュールを使用します。 データは、バックアップと、クエリの実行中に作成される一時ファイルも含め、ディスク上で暗号化されます。

  このサービスでは、Azure Storage 暗号化に含まれる AES 256 ビット暗号を含む Galois/Counter Mode (GCM) モードが使用され、キーはシステムで管理されます。 これと同様の他の保存時暗号化テクノロジーが、SQL Server や Oracle データベースの透過的データ暗号化のようなものです。 ストレージの暗号化は常にオンになっており、無効にすることはできません。

ネットワークのセキュリティ

Azure Database for PostgreSQL フレキシブル サーバーを実行している場合、主に次の 2 つのネットワーク オプションがあります。

• プライベート アクセス: サーバーを Azure 仮想ネットワークにデプロイできます。 Azure 仮想ネットワークは、非公開で、セキュリティで保護されたネットワーク通信の提供に役立ちます。 仮想ネットワーク内のリソースでは、プライベート IP アドレスを介して通信できます。 詳細については、 Azure Database for PostgreSQL フレキシブル サーバーのネットワークの概要を参照してください。

  ネットワーク セキュリティ グループのセキュリティ規則を使用して、仮想ネットワーク サブネットとネットワーク インターフェイスに出入りできるネットワーク トラフィックの種類をフィルター処理できます。 詳細については、 ネットワーク セキュリティ グループの概要を参照してください。

• パブリック アクセス: サーバーはパブリック エンドポイントを介してアクセスできます。 パブリック エンドポイントは、パブリックに解決できる DNS アドレスです。 そこへのアクセスは、既定ですべての接続をブロックするファイアウォールによってセキュリティ保護されます。

  IP ファイアウォール規則では、各要求の送信元 IP アドレスに基づいてサーバーへのアクセス権を付与します。 詳細については、 ファイアウォール規則の概要を参照してください。

Microsoft Defender for Cloud サポート

Microsoft Defender for オープンソース リレーショナル データベース は、データベースへのアクセスや悪用を試みる、通常とは異なる、害を及ぼす可能性のある試みを示す異常なアクティビティを検出します。 Defender for Cloud では、異常なアクティビティに関する セキュリティ アラート が提供されるため、潜在的な脅威を検出し、発生した脅威に対応できます。 このプランを有効にすると、Defender for Cloud により、異常なデータベース アクセスとクエリ パターン、および不審なデータベース アクティビティが検出されたときにアラートが提供されます。

これらのアラートは、Defender for Cloud のセキュリティ アラート ページに表示され、次のものが含まれます:

• それらをトリガーした疑わしいアクティビティの詳細
• 関連する MITRE ATT&CK 戦術
• 脅威を調査して軽減する方法に関して推奨されるアクション
• Microsoft Sentinel を使用して調査を続けるためのオプション

Microsoft Defender for Cloud とブルート フォース攻撃

ブルート フォース攻撃は、最も洗練されていないハッキング方法であるにもかかわらず、最も一般的で非常に成功したハッキング方法の 1 つです。 このような攻撃の背後にあるのは、パスワード推測の試みを無限に行えば、最終的には正しいパスワードにたどり着く、という理論です。 Microsoft Defender for Cloud がブルート フォース攻撃を検出すると、 アラートがトリガー され、ブルート フォース攻撃が発生したことを認識します。 また、単純なブルート フォース攻撃と、有効なユーザーに対するブルート フォース攻撃やブルート フォース攻撃の成功を分離することもできます。

Microsoft Defender プランからアラートを取得するには、次のセクションに示すように、まず アラートを有効にする 必要があります。

Microsoft Defender for Cloud の強化されたセキュリティを有効にする

1. Azure portal から、左側のウィンドウの [セキュリティ] メニューに移動します
2. [Microsoft Defender for Cloud] を選択します
3. 右側のウィンドウで [有効にする] を選択します。

アクセス管理

Azure Database for PostgreSQL フレキシブル サーバー データベースアクセス許可を大規模に管理する最善の方法は、ロールの概念を使用 することです。 ロールには、データベース ユーザーまたはデータベース ユーザーのグループを指定できます。 ロールは、データベース オブジェクトを所有でき、それらのオブジェクトの特権を他のロールに割り当てて、誰がどのオブジェクトにアクセスできるかを制御できます。 また、あるロールのメンバーシップを別のロールに付与することで、メンバー ロールが別のロールに割り当てられた特権を使用できるようにすることもできます。 Azure Database for PostgreSQL フレキシブル サーバーを使用すると、データベース ユーザーに直接アクセス許可を付与できます。 適切なセキュリティ対策として、アプリケーションとアクセスの最小要件に基づいて特定のアクセス許可セットを持つロールを作成することをお勧めします。 その後、各ユーザーに適切なロールを割り当てることができます。 ロールは、データベース オブジェクトにアクセスするための 最小特権モデル を適用するために使用されます。

Azure Database for PostgreSQL フレキシブル サーバー インスタンスは、PostgreSQL によって作成される組み込みロールに加えて、3 つの既定のロールが定義された状態で作成されます。 これらのロールは、コマンドを実行して確認できます:

SELECT rolname FROM pg_roles;

ロールの一覧を次に示します:

• azure_pg_admin
• アズレス
• 管理者ロール

Azure Database for PostgreSQL フレキシブル サーバー インスタンスを作成するときに、 管理者ロールの資格情報を指定します。 この管理者ロールを使用して、より多くの PostgreSQL ロールを作成できます。

たとえば、以下では例として "demouser" という名前のユーザーまたはロールを作成することができます

 CREATE USER demouser PASSWORD password123;

アプリケーションで管理者ロールを使用しないでください。

クラウドベースの PaaS 環境では、Azure Database for PostgreSQL フレキシブル サーバー スーパーユーザー アカウントへのアクセスは、クラウド オペレーターのみがコントロール プレーン操作に制限されます。 このため、azure_pg_admin アカウントは擬似スーパーユーザー アカウントとして存在します。 管理者ロールは、azure_pg_admin ロールのメンバーです。
ただし、サーバー管理者アカウントは、azuresu ロール (スーパーユーザー特権を持ち、コントロール プレーン操作の実行に使用される) の一部ではありません。 このサービスは管理対象の PaaS サービスなので、Microsoft だけがスーパー ユーザー ロールの一部になります。

お使いのサーバーのロール一覧を定期的に監査することができます。 たとえば、psql クライアントを使用して接続し、pg_roles テーブルにクエリを実行すると、すべてのロールが、他のロールの作成、データベースの作成、レプリケーションなどの権限と共に一覧表示されます。

select * from pg_roles where rolname='demouser';
-[ RECORD 1 ]--+---------
rolname        | demouser
rolsuper       | f
rolinherit     | t
rolcreaterole  | f
rolcreatedb    | f
rolcanlogin    | f
rolreplication | f
rolconnlimit   | -1
rolpassword    | ********
rolvaliduntil  |
rolbypassrls   | f
rolconfig      |
oid            | 24827

Azure Database for PostgreSQL フレキシブル サーバーの監査ログ は、Azure Database for PostgreSQL フレキシブル サーバーでも使用でき、データベース内のアクティビティを追跡できます。

スキーマ アクセスを制御する

Azure Database for PostgreSQL フレキシブル サーバーに新しく作成されたデータベースには、データベースのパブリック スキーマに既定の権限セットがあり、すべてのデータベース ユーザーとロールがオブジェクトを作成できます。 Azure Database for PostgreSQL フレキシブル サーバー インスタンスで作成したデータベースへのアプリケーション ユーザー アクセスをより適切に制限するには、これらの既定のパブリック特権を取り消す方法を検討することをお勧めします。 その後、データベース ユーザーに対して特定の特権をより細かく付与できます。 例えば:

• アプリケーション データベース ユーザーが Public スキーマ内にオブジェクトを作成することができないようにするには、public ロールから public スキーマに対する作成特権を取り消します。

  REVOKE CREATE ON SCHEMA public FROM PUBLIC;
  

• 次に、新しいデータベースを作成します。

  CREATE DATABASE Test_db;
  

• この新しいデータベースの PUBLIC スキーマから、すべての特権を取り消します。

  REVOKE ALL ON DATABASE Test_db FROM PUBLIC;
  

• アプリケーション db ユーザーのカスタム ロールを作成します

  CREATE ROLE Test_db_user;
  

• このロールを持つデータベース ユーザーが、データベースに接続できるようにします。

  GRANT CONNECT ON DATABASE Test_db TO Test_db_user;
  GRANT ALL PRIVILEGES ON DATABASE Test_db TO Test_db_user;
  

• データベース ユーザーを作成します

  CREATE USER user1 PASSWORD 'Password_to_change'
  

• ユーザーに対して、接続および SELECT の特権が定義されたロールを割り当てます

  GRANT Test_db_user TO user1;
  

この例では、ユーザー user1 はテスト データベース Test_dbに接続でき、すべての特権を持ちますが、サーバー上の他のデータベースにはアクセスできません。 このユーザーに、そのデータベースとそのオブジェクトに対して ole ALL PRIVILEGES を\rするのではなく、 SELECT、INSERT、EXECUTE などのより選択的なアクセス許可を提供することをお勧めします。PostgreSQL データベースの特権の詳細については、PostgreSQL ドキュメントの GRANT コマンドと REVOKE コマンドを参照してください。

PostgreSQL 15 でのパブリック スキーマの所有権の変更

Postgres バージョン 15 から、パブリック スキーマの所有権が新しいpg_database_owner ロールに変更されました。 これにより、すべてのデータベース所有者がデータベースのパブリック スキーマを所有できるようになります。
詳細については、 PostgreSQL リリース ノートを参照してください。

ロールベースのセキュリティに伴う PostgreSQL 16 の変更点

PostgreSQL データベース ロールでは、その特権を定義する多くの属性を持つことができます。このような属性の 1 つは CREATEROLE 属性です。これは、ユーザーとロールの PostgreSQL データベース管理にとって重要です。 PostgreSQL 16 において、この属性に大きな変更が導入されました。 PostgreSQL 16 では、 CREATEROLE 属性を持つユーザーは、任意のロールのメンバーシップを誰にも渡す機能を持たなくなりました。代わりに、この属性を持たない他のユーザーと同様に、 管理者オプションを持つロールのメンバーシップのみを配布できます。 また、PostgreSQL 16 では、 CREATEROLE 属性を使用しても、非ユーザーは新しいユーザーをプロビジョニングできますが、削除できるのは自分が作成したユーザーのみです。 CREATEROLE 属性を持つユーザーによって作成されなかったユーザーを削除しようとすると、エラーが発生します。

PostgreSQL 16 では、新しく改良された組み込みロールも導入されました。 PostgreSQL 16 の新しい pg_use_reserved_connections ロールでは、reserved_connections経由で予約された接続スロットを使用できます。 pg_create_subscription ロールを使用すると、スーパーユーザーはサブスクリプションを作成できます。

行レベルのセキュリティ

行レベル セキュリティ (RLS) は、Azure Database for PostgreSQL フレキシブル サーバー セキュリティ機能です。これにより、データベース管理者は、1 つ以上のロールに対して特定のデータ行の表示方法と動作方法を制御するポリシーを定義できます。 行レベルのセキュリティは、Azure Database for PostgreSQL フレキシブル サーバー データベース テーブルに適用できる追加のフィルターです。 ユーザーがテーブルに対してアクションを実行しようとすると、クエリ条件またはその他のフィルター処理の前にこのフィルターが適用され、セキュリティ ポリシーに従ってデータが絞り込まれたり拒否されたりします。 SELECT、INSERT、UPDATE、DELETE などの特定のコマンドに対して行レベルのセキュリティ ポリシーを作成し、すべてのコマンドに指定できます。 行レベルのセキュリティのユース ケースには、PCI 準拠の実装、分類された環境、共有ホスティング/マルチテナント アプリケーションなどがあります。

SET ROW SECURITY 権限を持つユーザーのみ、テーブルに行セキュリティ権限を適用できます。 テーブル所有者は、テーブルに対して行セキュリティを設定できます。 OVERRIDE ROW SECURITY と同様に、これは現在は暗黙的な権限です。 行レベルのセキュリティでは、既存の GRANT アクセス許可はオーバーライドされず、きめ細かいレベルの制御が追加されます。 たとえば、特定のユーザーが行を指定することができるように ROW SECURITY FOR SELECT を設定すると、そのユーザーが対象の列またはテーブルに対する SELECT 権限も持つ場合にのみ、そのユーザーにアクセス権が付与されます。

カスタムで作成された "マネージャー"ロールのメンバーのみが特定のアカウントの行にのみアクセスできるようにするポリシーを作成する方法を示す例を次に示します。 次の例のコードは 、PostgreSQL ドキュメントで共有されています。

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);

USING 句により WITH CHECK 句が暗黙的に追加されます。これにより、マネージャー ロールのメンバーが、他のマネージャーに属する行に対して SELECT、DELETE、または UPDATE 操作を実行できず、また他のマネージャーに属する新しい行を INSERT できないことが保証されます。 次の例のように、DROP POLICY コマンドを使用して行セキュリティ ポリシーを削除できます:

DROP POLICY account_managers ON accounts;

ポリシーを削除した可能性がありますが、依然としてロール マネージャーは他のマネージャーに属しているデータを表示できません。 これは、行レベルのセキュリティ ポリシーがアカウント テーブルで引き続き有効になっているためです。 行レベルのセキュリティが既定で有効になっている場合、PostgreSQL では既定の拒否ポリシーが使用されます。 次の例のように、行レベルのセキュリティを無効にできます:

ALTER TABLE accounts DISABLE ROW LEVEL SECURITY;

行レベルセキュリティのバイパス

PostgreSQL には BYPASSRLS と NOBYPASSRLS アクセス許可があり、ロールに割り当てることができます。NOBYPASSRLS は既定で割り当てられます。 Azure Database for PostgreSQL フレキシブル サーバーの新しくプロビジョニングされたサーバーでは、行レベルセキュリティ特権のバイパス (BYPASSRLS) は次のように実装されています。

• Postgres 16 以降のバージョン管理されたサーバーについては、 標準の PostgreSQL 16 の動作に従います。 azure_pg_admin管理者ロールによって作成された管理者以外のユーザーは、必要に応じて BYPASSRLS 属性\特権を使用してロールを作成できます。
• Postgres 15 以前のバージョン管理されたサーバーの場合。 では 、azure_pg_admin ユーザーを使用して、BYPASSRLS 特権を必要とする管理タスクを実行できますが、管理者ロールにはスーパーユーザー特権がないため、BypassRLS 特権を持つ非管理者ユーザーを作成することはできません。これは、クラウドベースの PaaS PostgreSQL サービスで一般的です。

パスワードを更新する

セキュリティ強化のために、管理者のパスワードとデータベース ユーザーのパスワードを定期的にローテーションすることを推奨します。 大文字と小文字、数字、および特殊文字を使用して、堅牢なパスワードを使用することが推奨されます。

SCRAM を使用する

Salted Challenge Response Authentication Mechanism (SCRAM) は、レインボーテーブル攻撃、中間者攻撃、格納されたパスワード攻撃を防ぐいくつかの重要なセキュリティ機能を追加すると同時に、非 ASCII 文字を含む複数のハッシュ アルゴリズムとパスワードのサポートを追加することで、パスワード ベースのユーザー認証のセキュリティを大幅に向上させます。

SCRAM 認証では、クライアントは身元証明を生成するために暗号化作業に参加します。 そのため、SCRAM 認証は、計算コストの一部をクライアント (ほとんどの場合はアプリケーション サーバー) にオフロードします。 SCRAM を採用すると、より強力なハッシュ アルゴリズムに加えて、PostgreSQL への分散型サービス拒否 (DDoS) 攻撃に対する保護も提供されます。これは、サーバーの CPU オーバーロードを防いでパスワード ハッシュを計算することで実現します。

クライアント ドライバーが SCRAM をサポートしている場合は、既定のととして scram-sha-256できます。

管理者パスワードのリセット

ガイド に 従って管理者パスワードをリセットします。

データベース ユーザー パスワードの更新

クライアント ツールを使用して、データベース ユーザーのパスワードを更新できます。
たとえば、

ALTER ROLE demouser PASSWORD 'Password123!';
ALTER ROLE

Azure Policy のサポート

Azure Policy は 、組織の標準を適用し、コンプライアンスを大規模に評価するのに役立ちます。 コンプライアンス ダッシュボードを通じて、環境の全体的な状態を評価するための集計ビューを提供します。これには、リソースごと、およびポリシーごとの粒度でドリルダウンできる機能が備わっています。 既存のリソースの一括修復と新しいリソースの自動修復を使用して、お客様のリソースでコンプライアンスを実現するのにも便利です。

組み込みのポリシー定義

組み込みポリシーは Microsoft によって開発およびテストされ、一般的な標準とベスト プラクティスを確実に満たしており、追加の構成を必要とせずに迅速に展開できるため、標準のコンプライアンス要件に最適です。 組み込みのポリシーは、多くの場合、広く認識されている標準とコンプライアンス フレームワークをカバーします。

以下のセクションでは、Azure Database for PostgreSQL フレキシブル サーバー用の Azure Policy 組み込みポリシー定義のインデックスを示します。 [ソース] 列のリンクを使用すると、Azure Policy GitHub リポジトリのソースを表示できます。

カスタム ポリシー定義

カスタム ポリシーは、固有のセキュリティ ポリシーやコンプライアンス要件など、組織の特定の要件に合わせて正確に調整できます。 カスタム ポリシーを使用すると、ポリシー ロジックとパラメーターを完全に制御できるため、高度な、きめ細かいポリシー定義が可能になります。

関連コンテンツ

• Azure Database for PostgreSQL フレキシブル サーバーのファイアウォール規則。
• Azure Database for PostgreSQL フレキシブル サーバーのパブリック アクセスとプライベート エンドポイント。
• Azure Database for PostgreSQL フレキシブル サーバーでの仮想ネットワーク統合。