Azure Database for PostgreSQL - フレキシブル サーバーのセキュリティ
適用対象: 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 コマンドを作成する機能が有効になりました。 現時点では、DROP ステートメントを除き、機能は想定どおりに動作しています。 言い換えると、現在、CAST を作成した後に、その 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 |
カスタム ポリシー定義
カスタム ポリシーは、固有のセキュリティ ポリシーやコンプライアンス要件など、組織の特定の要件に合わせて正確に調整できます。 カスタム ポリシーを使用すると、ポリシー ロジックとパラメーターを完全に制御できるため、高度な、きめ細かいポリシー定義が可能になります。