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

[アーティクル]
08/15/2024

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

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

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

情報の保護と暗号化

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

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

レガシクライアントの非互換性により、あまりおすすめできませんが、必要であれば、require_secure_transport サーバーパラメーターをオフに更新することで、Azure Database for PostgreSQL - フレキシブルサーバーへの接続で TLS\SSL を無効にできます。 ssl_max_protocol_version サーバーパラメーターを設定することで、TLS バージョンを設定することもできます。
保存データ: Azure Database for PostgreSQL フレキシブルサーバーは、ストレージ暗号化に FIPS 140-2 認証済みの暗号モジュールを使用します。データは、バックアップと、クエリの実行中に作成される一時ファイルも含め、ディスク上で暗号化されます。

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

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

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

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

ネットワークセキュリティグループのセキュリティ規則を使用して、仮想ネットワークサブネットとネットワークインターフェイスに出入りできるネットワークトラフィックの種類をフィルター処理できます。詳細については、ネットワークセキュリティグループの概要に関するページをご覧ください。
パブリックアクセス: サーバーには、パブリックエンドポイントを介してアクセスできます。パブリックエンドポイントは、パブリックに解決できる DNS アドレスです。そこへのアクセスは、既定ですべての接続をブロックするファイアウォールによってセキュリティ保護されます。

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

Microsoft Defender for Cloud サポート

オープンソースリレーショナルデータベース用 Microsoft Defender によって、通常とは異なる、害を与えるおそれがあるアクセスや悪用がデータベースに対して試みられていることを示す異常なアクティビティを検出します。 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 の強化されたセキュリティを有効にする

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

Note

Microsoft Defender プランで "オープンソースリレーショナルデータベース" 機能が有効になっている場合、Azure Database for PostgreSQL フレキシブルサーバーリソースに対して Microsoft Defender が既定で自動的に有効になっていることを確認します。

アクセス管理

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

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

SELECT rolname FROM pg_roles;

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

azure_pg_admin
azuresu
管理者ロール

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 フレキシブルサーバーで CAST コマンドを作成する機能が有効になりました。 CREATE CAST ステートメントを実行するには、ユーザーが azure_pg_admin グループのメンバーである必要があります。現時点では、CAST を作成後にドロップすることはできないことにご注意ください。

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

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

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

アプリケーションデータベースユーザーが 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 テストデータベースに接続でき、すべての特権を付与されていますが、サーバー上の他の DB に対しては接続も特権もありません。もう少し考慮するのであれば、このユーザー/ロールに、データベースとそのオブジェクトに対する ALL PRIVILEGES を付与するのではなく、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 属性を持つユーザーは、すべてのロールのメンバーシップをすべてのユーザーに付与することができなくなります。代わりに、この属性を持たない他のユーザーと同様に、ADMIN OPTION を持つロール内のメンバーシップのみを付与することができます。また PostgreSQL 16 では、スーパーユーザー以外のユーザーは CREATEROLE 属性によって引き続き新しいユーザーをプロビジョニングすることはできますが、削除することができるのは CREATEROLE 属性を持つユーザーが作成したユーザーのみとなります。 CREATEROLE 属性を持つユーザーによって作成されていないユーザーを削除しようとすると、エラーが発生します。

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

重要

Azure Database for PostgreSQL - フレキシブルサーバーでは、ユーザーに pg_write_all_data 属性を付与することはできません。そのようにすると、ユーザーは、これらのオブジェクトに対して INSERT、UPDATE、DELETE 権限を持つかのように、すべてのデータ (テーブル、ビュー、シーケンス) を書き込み、明示的に付与しなくても、すべてのスキーマに対する USAGE 権限を持つことができるようになります。回避策として、データベースとオブジェクトごとに、より限定的なレベルで同様のアクセス許可を付与することをお勧めします。

行レベルのセキュリティ

行レベルのセキュリティ (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 権限も持つ場合にのみ、そのユーザーにアクセス権が付与されます。

次の例は、カスタムで作成された "manager" ロールのメンバーのみが特定のアカウントの行にのみアクセスできるようにするポリシーの作成方法を示しています。次の例の中のコードは、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 句が暗黙的に追加されます。これにより、manager ロールのメンバーが、他のマネージャーに属する行に対して 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 特権を必要とする管理タスクを実行できますが、クラウドベースの PaaS PostgreSQL サービスでよくあるように、管理者の役割にはスーパーユーザー特権がないため、BypassRLS 特権を持つ非管理者ユーザーを作成することはできません。

パスワードを更新する

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

SCRAM を使用する

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

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

クライアントドライバーが SCRAM をサポートしている場合、SCRAM を使用した Azure Database for PostgreSQL - デフォルトの md5 ではなく 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 Portal)	説明	効果	バージョン(GitHub)
Microsoft Entra 管理者が PostgreSQL フレキシブルサーバーに対してプロビジョニングされている必要がある	Microsoft Entra 管理者の PostgreSQL フレキシブルサーバーに対するプロビジョニングを監査して Microsoft Entra 認証を有効にします。 Microsoft Entra 認証を使用すると、アクセス許可の管理が簡易化され、データベースユーザーとその他の Microsoft サービスの ID を一元管理できます	AuditIfNotExists、Disabled	1.0.0
PgAudit を使用した監査が PostgreSQL フレキシブルサーバーに対して有効である必要がある	このポリシーは、pgaudit の使用が有効になっていない環境内の PostgreSQL フレキシブルサーバーを監査するのに役立ちます。	AuditIfNotExists、Disabled	1.0.0
PostgreSQL フレキシブルサーバーでは接続の調整が有効でなければならない	このポリシーは、接続の帯域幅調整が有効になっていない環境内のすべての PostgreSQL フレキシブルサーバーを監査するのに役立ちます。この設定により、無効なパスワードログインエラーが多すぎる場合に、IP ごとに一時的な接続の帯域幅調整を行うことができます	AuditIfNotExists、Disabled	1.0.0
PostgreSQL フレキシブルサーバーの診断設定を Log Analytics ワークスペースにデプロイする	リージョンの Log Analytics ワークスペースへのストリーミングを行うための PostgreSQL フレキシブルサーバーの診断設定を、この診断設定がない PostgreSQL フレキシブルサーバーが作成または更新された場合にデプロイします	DeployIfNotExists、Disabled	1.0.0
PostgreSQL フレキシブルサーバーの切断はログに記録する必要がある	このポリシーは、log_disconnections が有効になっていない環境内のすべての PostgreSQL フレキシブルサーバーを監査するのに役立ちます	AuditIfNotExists、Disabled	1.0.0
PostgreSQL フレキシブルサーバーでは [SSL 接続を強制する] を有効にする必要がある	Azure Database for PostgreSQL では、Secure Sockets Layer (SSL) を使用する Azure Database for PostgreSQL フレキシブルサーバーからクライアントアプリケーションへの接続がサポートされています。お使いのデータベースフレキシブルサーバーとクライアントアプリケーション間に SSL 接続を強制すると、サーバーとお使いのアプリケーション間のデータストリームを暗号化することにより、中間者 (man in the middle) 攻撃から保護するのに役立ちます。この構成では、PostgreSQL フレキシブルサーバーへのアクセスに対して SSL が常に有効になります	AuditIfNotExists、Disabled	1.0.0
Azure Database for PostgreSQL フレキシブルサーバーの geo 冗長バックアップを有効にする必要がある	Azure Database for PostgreSQL フレキシブルサーバーを使用すると、データベースサーバーの冗長オプションを選択できます。これを、geo 冗長バックアップストレージに設定できます。これに設定すると、データはサーバーがホストされているリージョン内に格納されるだけでなく、リージョンの障害が発生した場合に復旧オプションを提供するために、ペアリージョンにもレプリケートされます。バックアップに対して geo 冗長ストレージを構成できるのは、サーバーの作成時だけです	Audit、Disabled	1.0.0
PostgreSQL フレキシブルサーバーではログチェックポイントが有効でなければならない	このポリシーは、log_checkpoints 設定が有効になっていない環境内のすべての PostgreSQL フレキシブルサーバーを監査するのに役立ちます	AuditIfNotExists、Disabled	1.0.0
PostgreSQL フレキシブルサーバーではログ接続が有効でなければならない	このポリシーは、log_connections 設定が有効になっていない環境内のすべての PostgreSQL フレキシブルサーバーを監査するのに役立ちます	AuditIfNotExists、Disabled	1.0.0
PostgreSQL フレキシブルサーバーは保存データの暗号化にカスタマーマネージドキーを使用する必要がある	PostgreSQL フレキシブルサーバーの保存時の暗号化を管理するためにカスタマーマネージドキーを使用します。既定では、データはサービスマネージドキーを使用して保存時に暗号化されますが、規制コンプライアンス標準を満たすには、一般にカスタマーマネージドキーが必要です。カスタマーマネージドキーを使用すると、自分が作成して所有する Azure Key Vault キーを使用してデータを暗号化できます。ローテーションや管理など、キーのライフサイクルを完全に制御し、責任を負うことになります	Audit、Deny、Disabled	1.0.0
PostgreSQL フレキシブルサーバーは TLS バージョン 1.2 以降を実行している必要がある	このポリシーは、1.2 未満の TLS バージョンで実行されている環境内の PostgreSQL フレキシブルサーバーを監査するのに役立ちます	AuditIfNotExists、Disabled	1.0.0
PostgreSQL フレキシブルサーバーに対してプライベートエンドポイントを有効にする必要がある	プライベートエンドポイント接続は、Azure Database for PostgreSQL へのプライベート接続を有効にすることで、通信のセキュリティを強化します。既知のネットワークからのトラフィックへのアクセスを有効にし、Azure 内の IP アドレスも含めて他のすべての IP アドレスからのアクセスを防ぐために、プライベートエンドポイント接続を構成します	AuditIfNotExists、Disabled	1.0.0

カスタムポリシー定義

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

次の方法で共有

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

情報の保護と暗号化

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

Microsoft Defender for Cloud サポート

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

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

アクセス管理

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

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

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

行レベルのセキュリティ

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

パスワードを更新する

SCRAM を使用する

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

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

Azure Policy のサポート

組み込みのポリシー定義

カスタムポリシー定義

フィードバック

その他のリソース

次の方法で共有

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

情報の保護と暗号化

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

Microsoft Defender for Cloud サポート

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

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

アクセス管理

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

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

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

行レベルのセキュリティ

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

パスワードを更新する

SCRAM を使用する

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

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

Azure Policy のサポート

組み込みのポリシー定義

カスタム ポリシー定義

関連するコンテンツ

フィードバック

その他のリソース

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

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

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

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

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

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

カスタムポリシー定義