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 認証済みの暗号モジュールを使用します。 データは、バックアップと、クエリの実行中に作成される一時ファイルも含め、ディスク上で暗号化されます。
このサービスでは、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 フレキシブル サーバー インスタンスは、定義された 3 つの既定のロールを伴って作成されます。 これらのロールは、 コマンドを実行して確認できます。
SELECT rolname FROM pg_roles;
azure_pg_admin
azuresu
管理者ロール
Azure Database for PostgreSQL- フレキシブル サーバーを作成している際に、管理者ロールの資格情報を指定します。 この管理者ロールを使用して、追加の PostgreSQL ロールを作成することができます。
たとえば、以下では例として demouser
という名前のユーザー/ロールを作成することができます。
postgres=> CREATE USER demouser PASSWORD 'password123';
管理者ロールはアプリケーションで使用しないでください。
クラウドベースの PaaS 環境内では、Azure Database for PostgreSQL - フレキシブル サーバーのスーパーユーザー アカウントへのアクセスは、クラウド オペレーターによるコントロール プレーン操作のみに制限されます。 このため、azure_pg_admin
アカウントは擬似スーパーユーザー アカウントとして存在します。 管理者ロールは、azure_pg_admin
ロールのメンバーです。
ただし、サーバー管理者アカウントは、azuresu
ロール (スーパーユーザー特権を持ち、コントロール プレーン操作の実行に使用される) の一部ではありません。 このサービスは管理対象の PaaS サービスなので、Microsoft だけがスーパー ユーザー ロールの一部になります。
Note
特定の暗黙的なキャストの作成など、スーパーユーザーのみのアクセス許可の多くは、Azure Database for PostgreSQL - フレキシブル サーバーでは使用することができません。これは、azure_pg_admin
ロールが PostgreSQL スーパーユーザー ロールのアクセス許可と一致しないためです。
お使いのサーバーのロール一覧を定期的に監査することができます。 たとえば、psql
クライアントを使用して接続し、pg_roles
テーブルにクエリを実行すると、すべてのロールが、ロールの追加作成、データベースの作成、レプリケーションなどの権限と共に一覧表示されます。
postgres=> \x
Expanded display is on.
postgres=> 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 - フレキシブル サーバー内で新しく作成されたデータベースには、既定の特権セットがデータベースの 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 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 ロールにより、スーパーユーザーはサブスクリプションを作成できます。
行レベルのセキュリティ
行レベルのセキュリティ (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 を使用した Azure Database for PostgreSQL - デフォルトの md5
ではなく scram-sha-256
として、フレキシブル サーバーへのアクセスをセットアップできます。
管理者パスワードのリセット
管理者パスワードをリセットするには、手引きに従います。
データベース ユーザー パスワードの更新
クライアント ツールを使用して、データベース ユーザーのパスワードを更新できます。
たとえば、 にします。
postgres=> ALTER ROLE demouser PASSWORD 'Password123!';
ALTER ROLE