Amazon Aurora DSQL のセキュリティ対策：アクセス制御のベストプラクティス

本記事は、2025 年 8 月 15 日に公開された Securing Amazon Aurora DSQL: Access control best practices を翻訳したものです。

Amazon Aurora DSQL は、常時利用可能なアプリケーションのための最速のサーバーレス分散 SQL データベースです。
革新的なアクティブ-アクティブ分散アーキテクチャにより、Aurora DSQL はシングルリージョン構成で 99.99% の可用性、マルチリージョン構成で 99.999% の可用性を実現するように設計されており、高可用性アプリケーションの構築に最適です。

パブリックエンドポイントと AWS PrivateLink エンドポイントを使用して、Aurora DSQL クラスターにアクセスできます。
このポストでは、AWS の内部と外部の両方から、パブリックエンドポイントと PrivateLink を介したプライベート VPC エンドポイントを使用して、Aurora DSQL クラスターへのアクセスを制御する方法をご紹介します。

Aurora DSQL パブリックエンドポイントを使用したアクセス制御

パブリックエンドポイントを介して Aurora DSQL にアクセスすることで、VPN や AWS Direct Connect のセットアップなしで、外部アプリケーションやオンプレミスシステムが Aurora DSQL クラスターに接続できる柔軟性が得られます。しかし、この利便性は強力なアクセス制御とバランスを取る必要があります。Aurora DSQL は AWS Identity and Access Management (IAM) と統合されており、ID ベースのアクセス許可を適用することで、承認されたロールのみが接続を開始できます。ユーザーロール、IP アドレス範囲、または仮想プライベートクラウド (VPC) 識別子に基づいて、アクセスを許可または拒否する詳細なポリシーを定義できます。たとえば、必要な dsql:DbConnect または dsql:DbConnectAdmin アクセス許可がない状態でユーザーが接続を試みた場合、パブリックエンドポイントに到達可能であっても、アクセス拒否エラーが発生します。

IAM ポリシー、セキュリティグループ、ネットワークアクセスコントロールリスト (ネットワーク ACL) を組み合わせることで、環境間での安全なアクセスを可能にしながら、Aurora DSQL クラスターへのアクセスを厳密に管理できます。
パブリックエンドポイントを介して Aurora DSQL クラスターにアクセスする場合、セキュリティのために以下のアクセス制御を実装することが不可欠です:

最小権限の原則 – 各データベースのロールまたはユーザーに必要最小限の IAM アクセス許可を付与します。
IP ベースのアクセス制御 – 指定した IP アドレスまたは IP アドレス範囲からの接続のみを許可します。

次の図は、このセットアップのアーキテクチャを示しています。

パブリックエンドポイントを使用したオンプレミスから Aurora DSQL へのアクセス制御の管理

このセクションでは、パブリックエンドポイントを使用して、オンプレミスネットワークから Aurora DSQL クラスターへのアクセスを安全に管理する手順を段階的に説明します。

IAM 権限を使用したデータベースアクセスの制御

Aurora DSQL は認証に従来のパスワードを使用しません。代わりに、AWS SDK によって生成される短期間有効な認証トークンを使用します。
ユーザーまたはアプリケーションが Aurora DSQL クラスターに接続を試みると、Aurora DSQL はトークンを検証し、呼び出し元の IAM ポリシーを評価してアクセスを許可するかどうかを判断します。
このアプローチは、更新頻度の低さや資格情報の漏洩といった、長期間有効なパスワードに関連するリスクを軽減することでセキュリティを強化します。

IAM ベースのトークン認証を使用することで、明示的に承認されたロールとユーザーのみがデータベースに接続できるようになります。
また、システムにアクセスできるユーザーの一元管理と監査が可能になります。

これを実証するために、まず Amazon Elastic Compute Cloud (Amazon EC2) インスタンスの IAM ロールに Aurora DSQL のアクセス許可 (dsql:DbConnect または dsql:DbConnectAdmin) を割り当てずに、Aurora DSQL クラスターのパブリックエンドポイントへの接続を試みます。


 export PGSSLMODE=require
 export PGPASSWORD=$(aws dsql generate-db-connect-admin-auth-token --hostname $CLUSTER_ENDPOINT --region us-east-1)
 [root@ip-10-0-0-40 ~ ]# psql --quiet --username admin --dbname postgres --host $CLUSTER_ENDPOINT
 psql: error: connection to server at "xxxxxxxxxxxxxxxxxxxxxxxxxx.dsql.us-east-1.on.aws" (18.97.33.130), port 5432 failed: FATAL: unable to accept connection, access denied
 DETAIL: Session Id: kvs6xpvbygqtwayg2o6pzp7lgi
 HINT: User: arn:aws:sts::123456789012:assumed-role/EC2Role/i-b188560f is not authorized to perform: dsql:DbConnectAdmin on resource: arn:aws:dsql:us-east-1:123456789012:cluster/xxxxxxxxxxxxxxxxxxxxxxxxxx because no identity-based policy allows the dsql:DbConnectAdmin action

これは、パブリックエンドポイントを介してアクセスする場合でも、IAM 認証を適用することで Aurora DSQL クラスターが保護されていることを示しています。
適切なポリシーを持たない接続試行は拒否され、不正アクセスを効果的に防止します。
次に、以下の IAM ポリシーを Amazon EC2 インスタンスの IAM ロールに関連付けます。
このポリシーは、管理者ロール (dsql:DbConnectAdmin) とカスタムデータベースロール (dsql:DbConnect) の両方を使用してクラスターに接続するための権限を付与します。

注意: このブログ全体を通して、山括弧（< >）で囲まれた値 を必ずご自身の情報に置き換えてください。


{
    "Version": "2012-10-17",
    "Statement": [

        {
            "Sid": "StatementAllow",
            "Effect": "Allow",
            "Action": [
                "dsql:DbConnect",
                "dsql:DbConnectAdmin"
            ],
            "Resource": [
                "arn:aws:dsql:<AWS-Region>:<account-id>:cluster/examplecluster"
            ]
        }
    ]
}

次に、以下のコマンドを実行して PostgreSQL の SSL モードを require に設定し、安全な接続を強制します。
Aurora DSQL はすべての接続に SSL を必須とし、SSL を使用しない接続の試みは拒否されます。

export PGSSLMODE=require

次に、認証トークンを生成し、PGPASSWORD 環境変数に格納します。
デフォルトでは、Aurora DSQL の認証トークンは 15 分 (900 秒) で有効期限が切れます。
ただし、このチュートリアルでは、1 時間 (3,600 秒) で有効期限が切れるように設定した、より長い有効期限を持つトークンを生成します。

export PGPASSWORD=$(aws dsql generate-db-connect-admin-auth-token --hostname $CLUSTER_ENDPOINT --region us-east-1 --expires-in 3600)

必要な接続パラメータを設定したので、Aurora DSQL クラスターへの接続をテストしてみましょう。

[root@ip-10-0-0-40 ~ ]# psql --quiet --username admin --dbname postgres --host $CLUSTER_ENDPOINT

 postgres=> select current_user ;
 current_user
 -----------------
 admin
(1 row)

前述のコードと出力は、パブリックエンドポイントを介してアクセスした場合でも、Aurora DSQL が IAM ベースの認証を効果的に実施していることを示しています。
安全で制御されたアクセスのために、常に最小権限の原則に従い、データベースアクセスを必要とするロールとユーザーに対して、必要な権限 (dsql:DbConnect または dsql:DbConnectAdmin) のみを付与してください。
定期的に IAM ポリシーを監査し、セキュリティリスクを軽減するために、長期間有効な認証情報の代わりに短期間のみ有効な認証トークンを使用してください。

IP アドレスまたは範囲に基づいたデータベースアクセスの制御

ここでは、ソース IP アドレスに基づいて Aurora DSQL クラスターへのアクセスを制限する方法を説明します。
この方法は、ネットワークレベルのセキュリティ層を追加し、信頼できる IP アドレスまたは CIDR ブロックからの接続のみを許可します。
aws:SourceIp 条件を含む IAM ポリシーを使用することで、ロールベースのアクセス制御を補完する明示的な許可または拒否ルールを定義できます。
これは、特定の企業オフィス、オンプレミスデータセンター、または既知のバスティオンホストへのアクセスを許可する場合に特に便利です。

次のコード例は、接続要求が指定された範囲外の IP アドレスから発信された場合に、Aurora DSQL クラスターへのアクセスを拒否する ID ベースの IAM ポリシーを作成する方法を示しています。
このポリシーでは、"Effect": "Deny" 条件により、信頼された IP アドレス (この場合は 203.0.113.1/32) 以外からのリクエストをブロックします。
このアプローチにより、ユーザーまたはロールが必要な Aurora DSQL の権限を持っている場合でも、承認された IP からの接続のみが許可されます。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "StatementDeny",
            "Effect": "Deny",
            "Action": [
                "dsql:DbConnect",
                "dsql:DbConnectAdmin"
            ],
            "Resource": [
                "arn:aws:dsql:<AWS-Region>:<account-id>:cluster/examplecluster"
            ],
            "Condition": {
                "NotIpAddress": {
                    "aws:SourceIp": "203.0.113.1/32"
                }
            }
        },
        {
            "Sid": "StatementAllow",
            "Effect": "Allow",
            "Action": [
                "dsql:DbConnect",
                "dsql:DbConnectAdmin"
            ],
            "Resource": [
                "arn:aws:dsql:<AWS-Region>:<account-id>:cluster/examplecluster"
            ]
        }
    ]
}

異なる送信元 IP アドレスを持つ Amazon EC2 インスタンスから Aurora DSQL に接続する

前のセクションで説明した IP ベースの制限の有効性を検証するために、IAM ポリシーで定義された許可範囲外の異なるパブリック IP アドレスを持つ Amazon EC2 インスタンスから、Aurora DSQL クラスターへの接続を試みてみましょう。
ポリシーでは 203.0.113.1/32 に一致しない IP アドレスからのアクセスを明示的に拒否しているため、他のすべての IAM 権限が正しく設定されていても、この Amazon EC2 インスタンスからの接続試行は失敗するはずです。

接続をテストする前に、Amazon EC2 インスタンスのパブリック IP アドレスが、IAM ポリシーで定義された許可 IP 範囲の外にあることを確認する必要があります。Amazon EC2 Instance Metadata Service Version 2 (IMDSv2) を IMDSv2 トークンと共に使用して、インスタンスのパブリック IPv4 アドレスを安全に取得するには、以下のコマンドを実行します：

# IMDSv2 トークンを生成
 TOKEN=$(curl --silent -X PUT "http://169.254.169.254/latest/api/token" \
-H "X-aws-ec2-metadata-token-ttl-seconds: 21600")

# トークンを使用してパブリック IP アドレスを取得
 public_ipv4=$(curl --silent -H "X-aws-ec2-metadata-token: $TOKEN" \
http://169.254.169.254/latest/meta-data/public-ipv4)

# IP を表示
 echo $public_ipv4
 192.0.2.1

IAM ポリシーは 203.0.113.1/32 以外のソース IP アドレスからのアクセスを明示的に拒否するため、パブリック IP アドレスが 192.0.2.1 である Amazon EC2 インスタンスからの接続試行は正しく拒否されます。
これにより、IP ベースの制限が意図したとおりに強制されていることが確認できます。

[root@ip-10-0-0-40 ~ ]# psql --quiet --username admin --dbname postgres --host $CLUSTER_ENDPOINT
 psql: error: connection to server at "examplecluster.dsql.us-east-1.on.aws" (18.97.33.130), port 5432 failed: FATAL: unable to accept connection, access denied

 DETAIL: Session Id: abcdefghijaklmnop2ryunhve
 HINT: User: arn:aws:sts:: 12345678910:assumed-role/EC2Role/i-b188560f is not authorized to perform: dsql:DbConnectAdmin on resource: arn:aws:dsql:us-east-1:12345678910:cluster/examplecluster with an explicit deny in an identity-based policy

上記のコードは、ユーザーまたはロールが適切な権限を持っている場合でも、Aurora DSQL が IP ベースの拒否ルールに従い、アクセスを信頼できるネットワーク境界に制限することを示しています。

許可されたソース IP アドレスを持つ Amazon EC2 インスタンスからの Aurora DSQL への接続

IP ベースのアクセスポリシーが期待通りに機能することを確認するため、IAM ポリシーで許可された IP 範囲 (203.0.113.1/32) に一致するパブリック IP アドレスを持つ Amazon EC2 インスタンスから Aurora DSQL クラスターに接続します。

インスタンスのパブリック IP アドレスが許可された範囲内にあり、IAM ロールに必要な dsql:DbConnect または dsql:DbConnectAdmin 権限があるため、接続はエラーなく成功するはずです。

接続をテストする前に、Amazon EC2 インスタンスのパブリック IP アドレスが、IAM ポリシーで定義された許可 IP 範囲 (203.0.113.1/32) 内にあることを確認しましょう。
これを行うために、IMDSv2 トークンを使用してインスタンスのパブリック IPv4 アドレスを安全に取得します。

# IMDSv2 トークンを生成
 [root@ip-10-0-0-40 ~ ]# export PGSSLMODE=require
 [root@ip-10-0-0-40 ~ ]# export PGPASSWORD=$(aws dsql generate-db-connect-admin-auth-token --hostname $CLUSTER_ENDPOINT — region us-east-1)

# トークンを使用してパブリック IP アドレスを取得
 [root@ip-10-0-0-40 ~ ]# TOKEN=$(curl --silent -X PUT "http://169.254.169.254/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600")
 [root@ip-10-0-0-40 ~ ]# public_ipv4=$(curl — silent -H "X-aws-ec2-metadata-token: $TOKEN" http://169.254.169.254/latest/meta-data/public-ipv4)

# IP を表示
 [root@ip-10-0-0-40 ~ ]# echo $public_ipv4
 203.0.113.1

IAM ポリシーで IP アドレス 203.0.113.1 からのアクセスを許可するように正しく設定し、認証トークンや SSL モードなどの必要な接続パラメータをすべて設定したので、Aurora DSQL クラスターに正常に接続できるようになりました。

[root@ip-10-0-0-40 ~ ]# psql --quiet --username admin --dbname postgres --host $CLUSTER_ENDPOINT

 postgres=> select current_user ;
 current_user
 --------------
 admin

これにより、IP ベースのアクセス制御が正しく機能し、明示的に許可された IP アドレスからの接続のみを許可していることが確認できます。

PrivateLink とプライベート DNS エンドポイントを使用した Aurora DSQL へのアクセス制御

このセクションでは、PrivateLink とプライベート DNS エンドポイントを使用して Aurora DSQL に安全にアクセスする方法を探ります。
このアプローチにより、VPC と Aurora DSQL 間のトラフィックを完全に AWS ネットワーク内に留めることができ、パブリック IP アドレス、インターネットゲートウェイ、または NAT デバイスが不要になります。

PrivateLink を使用すると、インターフェース VPC エンドポイントを作成して、Aurora DSQL を自身の VPC の一部であるかのように接続できます。
プライベート DNS と組み合わせることで、これらのエンドポイントを使用してアプリケーションは標準のホスト名を使用して Aurora DSQL クラスターを解決しアクセスできるようになり、トラフィックはプライベートかつ安全にルーティングされます。
この構成は、データのプライバシーと低レイテンシー、安全な接続が重要な要件となる内部ワークロードやハイブリッド環境で特に有用です。

次の図は、PrivateLink を使用して Aurora DSQL クラスターへのアクセスを制御する方法を示しています。

前提条件

以下のセクションに進む前に、次の前提条件を満たしていることを確認してください。

Amazon VPC
VPC 内のコンピューティングリソース (Amazon EC2 インスタンスなど)
単一の AWS リージョンにある Aurora DSQL クラスター
インターフェース VPC エンドポイントの作成と Aurora DSQL へのアクセスに必要なIAM アクセス許可

PrivateLink インターフェイスエンドポイントの作成

Aurora DSQL の PrivateLink サポートにより、VPC にインターフェース VPC エンドポイントをプロビジョニングできます。
これらのエンドポイントを使用すると、パブリック IP アドレスやインターネット接続を必要とせずに、アプリケーションからプライベートに Aurora DSQL に接続できます。
Amazon VPC 内にデプロイされたアプリケーションは、インターフェースエンドポイントを介してプライベート DNS ホスト名を使用し、Aurora DSQL に安全にアクセスできます。
これにより、トラフィックは AWS ネットワーク内に完全に閉じられ、セキュリティとパフォーマンスの両方が向上します。
PrivateLink インターフェースエンドポイントの作成手順の詳細については、AWS PrivateLink を使用した Amazon Aurora DSQL クラスターの管理と接続をご参照ください。

PrivateLink インターフェイスエンドポイントを設定したら、次のステップでは、詳細な ID ベースの制御を通じて Aurora DSQL クラスターへのアクセスを制御するメカニズムを検討します。

VPC エンドポイントポリシーを使用したデータベースアクセスの制限

VPC エンドポイントポリシーを使用することで、ネットワーク内の信頼された IAM プリンシパルとリソースにのみアクセスを許可する堅牢なデータ境界を定義できます。
このアプローチにより、不正アクセスのリスクを最小限に抑え、Aurora DSQL クラスターへのアクセス方法をポリシーに基づいた厳密な制御ができます。

以下の例では、接続リクエストが特定の IAM ロールから発信されていない場合に、Aurora DSQL クラスターへのアクセスを拒否するアイデンティティベースの IAM ポリシーを作成する方法を示します。
このポリシーでは、"Effect": "Deny" 条件により、信頼された IAM ロール EC2Role 以外からのリクエストをブロックします。
同時に、このポリシーは examplecluster Aurora DSQL クラスターに対する dsql:DbConnect および dsql:DbConnectAdmin アクションに適用されます。
このアプローチにより、承認された IAM ロールを使用した接続のみが許可されることを確実にします。

{
  "Statement": [
    {
      "Effect": "Deny",
      "Principal": "*",
      "Action": "*",
      "Resource": "arn:aws:dsql:<AWS-Region>:<account-id>:cluster/examplecluster",
      "Condition": {
        "StringNotEquals": {
          "aws:PrincipalArn": "arn:aws:iam:::role/EC2Role"
        }
      }
    },
    {
      "Effect": "Allow",
      "Principal": "*",
      "Action": [
        "dsql:DbConnect",
        "dsql:DbConnectAdmin"
      ],
      "Resource": "arn:aws:dsql:<AWS-Region>:<account-id>:cluster/examplecluster"
    }
  ]
}

認可されていない IAM ロールを使用した Aurora DSQL 接続のテスト

前述の VPC エンドポイントポリシーが意図したとおりに機能していることを確認するため、許可されていない IAM ロールを使用して Amazon EC2 インスタンスから Aurora DSQL クラスターへの接続を試みます。
この場合、インスタンスに関連付けられているロール (ec2-admin-role) は、VPC エンドポイントポリシーで明示的に許可されているロール (ec2-role) とは異なります。

まず、インスタンスに関連付けられている IAM ロールを確認しましょう：


 [root@ip-10-0-0-34 ~ ]# TOKEN=$(curl --silent -X PUT "http://169.254.169.254/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600")
 [root@ip-10-0-0-34 ~ ]# curl --silent -H "X-aws-ec2-metadata-token: $TOKEN" http://169.254.169.254/latest/meta-data/iam/security-credentials/

 ec2-admin-role

接続パラメータを以下のように設定します。

# Set environment variables
 export CLUSTERID=your-cluster-id
 export REGION=us-east-1
 export SERVICE_IDENTIFIER=dsql-fnh4 # This should match the identifier in your service name
# Construct the hostname
 export HOSTNAME="$CLUSTERID.$SERVICE_IDENTIFIER.$REGION.on.aws"

# Generate authentication token
 export PGPASSWORD=$(aws dsql --region $REGION generate-db-connect-admin-auth-token --hostname $HOSTNAME)

それでは接続して結果を確認してみましょう：

[root@ip-10-0-0-34 ~ ]# psql --d postgres --h $HOSTNAME --U admin
 psql: error: connection to server at "examplecluster.dsql-fnh4.us-east-1.on.aws" (10.0.0.0), port 5432 failed: FATAL: unable to accept connection, access deniedDETAIL: Session Id: sfs65e33upgza5iywqh64wd7sq
 HINT: User: arn:aws:sts::123456789012:assumed-role/ec2-admin-role/i-XXXXXXXXXXX is not authorized to perform: dsql:DbConnectAdmin on resource: arn:aws:dsql:us-east-1:123456789012:cluster/examplecluster with an explicit deny in a VPC endpoint policy

VPC エンドポイントポリシーは、権限のない IAM ロール (ec2-admin-role) のアクセスを正しく拒否しました。

許可された IAM ロールを使用した Aurora DSQL 接続のテスト

VPC エンドポイントポリシーが意図した IAM アイデンティティに対してアクセスを許可していることを検証するため、承認された IAM ロール (ec2-role) で設定された Amazon EC2 インスタンスから接続を開始します。

まず、インスタンスに関連付けられた IAM ロールを確認します。

[root@ip-10-0-0-40 ~ ]# TOKEN=$(curl --silent -X PUT "http://169.254.169.254/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600")
[root@ip-10-0-0-40 ~ ]# curl --silent -H "X-aws-ec2-metadata-token: $TOKEN" http://169.254.169.254/latest/meta-data/iam/security-credentials

 ec2-role

これにより、Amazon EC2 インスタンスが許可された IAM ロール (ec2-role) を使用していることが確認できます。

次に、接続パラメータを設定し、Aurora DSQL クラスターへの接続を開始します。


 export PGSSLMODE=require
 export PGPASSWORD=$(aws dsql --region $REGION generate-db-connect-admin-auth-token — hostname $HOSTNAME)

 psql --d postgres --h $HOSTNAME --U admin
 psql (15.6, server 16.9)
 WARNING: psql major version 15, server major version 16.
 Some psql features might not work.
 SSL connection (protocol: TLSv1.3, cipher: TLS_AES_128_GCM_SHA256, compression: off)
 Type "help" for help.

 postgres=> select current_user ;
 current_user
 ----------------
 admin
(1 row)

リクエストが承認された IAM ロールから発信された場合、VPC エンドポイントポリシーによってアクセスが正しく許可され、接続は想定通りに成功します。

セキュリティグループを使用した Aurora DSQL へのトラフィックの制限

セキュリティグループは、インバウンドとアウトバウンドの両方のトラフィックを制御する、AWS リソースの仮想ファイアウォールとして機能します。Aurora DSQL PrivateLink VPC エンドポイント (インターフェイスエンドポイント) を使用する場合、セキュリティグループは VPC 内の特定のコンピューティングリソース、IP 範囲、またはサブネットへのクラスターアクセスを制限する強力なメカニズムを提供します。

このセクションでは、セキュリティグループを使用して Aurora DSQL クラスターへの接続を制御し、テストシナリオを通じて設定を順を追って説明します。

Amazon EC2 インスタンスに関連付けられたセキュリティグループの特定

Aurora PostgreSQL に接続を試みる Amazon EC2 インスタンスに関連付けられているセキュリティグループのリストを最初に取得します。

# Get EC2 metadata token
 TOKEN=$(curl --silent -X PUT "http://169.254.169.254/latest/api/token" \ -H "X-aws-ec2-metadata-token-ttl-seconds: 21600")

# List attached security groups
 curl --silent -H "X-aws-ec2-metadata-token: $TOKEN" \ http://169.254.169.254/latest/meta-data/security-groups

#Example Output:
 SecGroup-MySQL
 SecGroup-PG
 SecGroup-DSQL

PrivateLink エンドポイントのセキュリティグループの確認

次に、Aurora DSQL PrivateLink エンドポイントに現在関連付けられているセキュリティグループを確認してみましょう。

aws ec2 describe-vpc-endpoints \
--vpc-endpoint-ids vpce-03ae184e1b904ecb5 \
--query "VpcEndpoints[0].Groups"

#Example Output:
 [
	{
   "GroupId": "sg-0b457c8e654a695f5",
   "GroupName": " SecGroup-ec2"
   }
 ]

Amazon EC2 インスタンスと PrivateLink エンドポイントに共通のセキュリティグループがないことがわかります。そのため、明示的に許可しない限り、接続は失敗する可能性が高いです。

セキュリティグループの不一致による接続の試行

Amazon EC2 インスタンスから Aurora PostgreSQL クラスターへの接続を試み、アクセスが許可されているかどうかを確認するためにタイムアウトを設定します。PGCONNECT_TIMEOUT 変数を設定して、10 秒後に接続がタイムアウトするようにしています。


 export HOSTNAME="$CLUSTERID.$SERVICE_IDENTIFIER.$REGION.on.aws"
 echo $HOSTNAME
 examplecluster. dsql-fnh4.us-east-1.on.aws
 export PGCONNECT_TIMEOUT=10
 export PGPASSWORD=$(aws dsql --region $REGION generate-db-connect-admin-auth-token --hostname $HOSTNAME)

 psql --quiet --username admin --dbname postgres --host $HOSTNAME

#Example Output:
 psql: error: connection to server at " examplecluster. dsql-fnh4.us-east-1.on.aws" (10.0.0.0), port 5432 failed: timeout expired connection to server at " examplecluster. dsql-fnh4.us-east-1.on.aws (10.0.0.0), port 5432 failed: timeout expired

上記の出力は、VPC エンドポイントの制限されたセキュリティグループ設定により、Amazon EC2 インスタンスが Aurora DSQL エンドポイントに到達できないことを示しています。

エンドポイントへの適切なセキュリティグループの割り当て

エンドポイントに適切なセキュリティグループを関連付けるために、Amazon EC2 インスタンスで使用されているセキュリティグループを特定します。

aws ec2 describe-security-groups \
--filter Name=group-name,Values= SecGroup-DSQL \
--query "SecurityGroups[0].GroupId"

#Example Output:
"sg-078a098b3069c40de"

次に、既存の PrivateLink エンドポイントにセキュリティグループ sg-078a098b3069c40de を追加します。

aws ec2 modify-vpc-endpoint \
--vpc-endpoint-id vpce-03ab184c1d904efg5 \
--add-security-group-ids sg-078a098b3069c40de

aws ec2 describe-vpc-endpoints \
--vpc-endpoint-ids vpce-privatelink-id \
--query "VpcEndpoints[*].Groups"

# Example Output
 [
	{
   "GroupId": " sg-078a098b3069c40de",
   "GroupName": " SecGroup-DSQL"
   }
 ]

Amazon EC2 インスタンスからの接続の再テスト

正しいセキュリティグループを VPC エンドポイントに関連付けたので、Amazon EC2 インスタンスから接続を再試行します。

psql --quiet --username admin --dbname postgres --host $HOSTNAME

 postgres=>postgres=> select current_user ;
 current_user
 --------------
 admin

Aurora DSQL クラスターへの接続が成功し、PrivateLink を介したアクセスを有効にするためにはセキュリティグループの整合性が重要であることが確認できました。

Aurora DSQL PrivateLink エンドポイントでセキュリティグループを使用することで、IAM と VPC エンドポイントポリシーを補完する、重要なネットワークレベルのアクセス制御が提供されます。
Amazon EC2 インスタンスと VPC インターフェースエンドポイントに適切にセキュリティグループを関連付けることで、VPC 内の信頼できるリソースのみが Aurora DSQL クラスターに接続できるようになります。
このアプローチは、最小権限アクセスモデルを実施するだけでなく、意図しない、または許可されていないネットワークトラフィックがセンシティブなデータを扱うエンドポイントに到達することを防ぐことで、全体的なセキュリティ体制を強化します。

Aurora DSQL 向けの追加の IAM ベースのアクセス制御ポリシー

セキュリティと監査の目的に応じて、IAM では Aurora DSQL クラスターに接続できるユーザーと、その接続試行の発信元となる VPC を制御するための柔軟なオプションを提供しています。
以下のサンプルポリシーは、環境に合わせた VPC ベースおよびアイデンティティベースのアクセス制御を適用するための出発点として活用できます。

IAM は世界中のデータセンターのコンピュータからアクセスされるサービスで、結果整合性と呼ばれる分散コンピューティングモデルを使用して動作していることに注意してください。
これは、IAM や関連する AWS サービスで行った変更 (例えば属性ベースのアクセスコントロール (ABAC) タグの更新など) が、すべてのエンドポイントに反映され、表示されるまでに時間がかかる可能性があることを意味します。
この遅延は、データがサーバー間、レプリケーションゾーン間、AWS リージョン間で伝送される必要があるために発生します。
さらに、IAM はパフォーマンスを向上させるためにキャッシュを使用しており、これによってさらなる遅延が発生することがあります。
その結果、キャッシュされたデータが期限切れになるまで、変更が即座に反映されない場合があります。
詳細については、変更が即座に反映されないを参照してください。

IAM 条件を使用した Aurora DSQL クラスターのパブリックアクセスのブロック

Aurora DSQL のパブリックエンドポイントへのアクセスを厳密に制御するために、承認された VPC または PrivateLink エンドポイントから発信されないすべてのトラフィックをブロックできます。

以下の IAM ポリシーは、条件キーを使用して、接続リクエストが VPC またはインターフェースエンドポイントから発信されていない場合にアクセスを拒否します。

この例では、リクエストに有効な VPC ソース IP (aws:VpcSourceIp)、ソース VPC 識別子 (aws:SourceVpc)、または VPC エンドポイント識別子 (aws:SourceVpce) が含まれていない場合、ユーザーまたはロールが必要な Aurora DSQL のアクセス許可を持っていても、接続の試行は拒否され、インターネットからのアクセスがすべて効果的に防止されます。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Resource": "arn:aws:dsql:<AWS-Region>:<account-id>:cluster/examplecluster",
            "Effect": "Deny",
            "Action": [
                "dsql:DbConnect",
                "dsql:DbConnectAdmin"
            ],
            "Condition": {
                "Null": {
                    "aws:VpcSourceIp": "true",
                    "aws:SourceVpc": "true",
                    "aws:SourceVpce": "true"
                }
            }
        }
    ]
}

このポリシーは、信頼できるプライベートネットワークまたは明示的に設定された VPC インターフェースエンドポイントからの接続のみを許可することで、Aurora DSQL クラスターがパブリックインターネットに意図せず公開されることを防ぐ、強力なセーフガードとして機能します。

信頼できる VPC への Aurora DSQL PrivateLink アクセスの制限

Aurora DSQL へのアクセスを事前に定義された VPC グループ (例えば、承認された本番環境やステージング環境のネットワーク) からのみに制限する必要がある環境では、信頼された VPC ID からのリクエストでない限り、接続の試行を拒否できます。
次の例では、接続が vpc-abc または vpc-xyz のいずれかからでない場合、dsql:DbConnect と dsql:DbConnectAdmin の両方を拒否します。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "RestrictDSQLDBConnectToSpecificVPCs",
            "Effect": "Deny",
            "Action": [
                "dsql:DbConnect",
                "dsql:DbConnectAdmin"
            ],
            "Resource": "*",
            "Condition": {
                "ForAnyValue:StringNotEquals": {
                    "aws:SourceVpc": [
                        "vpc-abc",
                        "vpc-xyz"
                    ]
                }
            }
        }
    ]
}

このポリシーを設定することで、呼び出し元が必要な IAM 許可を持っていても、他の VPC からの接続試行はすべて拒否されます。

指定した VPC からの Aurora DSQL PrivateLink 接続の制限

高度に管理された環境では、Aurora DSQL へのアクセスを単一の VPC からのみに制限する必要がある場合があります。
以下のポリシーでは、VPC vpc-xyz からの接続以外のすべての接続試行を拒否します。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "RestrictDSQLDBConnectToVPC",
            "Effect": "Deny",
            "Action": [
                "dsql:DBConnect"
            ],
            "Resource": "*",
            "Condition": {
                "StringNotEquals": {
                    "aws:SourceVpc": "vpc-xyz"
                }
            }
        }
    ]
}

これは、Aurora DSQL クラスターへのアクセスを、社内アプリケーションで使用される中央データサービス VPC のような、厳密に管理された VPC からのみに制限する必要がある場合に有用です。

Aurora DSQL PrivateLink における VPC および IAM ベースのアクセス制御の適用

最高レベルの制御を実現するために、同じポリシー内でネットワークベースの制限とアイデンティティベースの制限の両方を組み合わせることができます。
次の例では、リクエストが vpc-xyz から発信され、IAM ロール ApprovedRole またはユーザー ApprovedUser のいずれかを使用する場合にのみ、dsql:DbConnect を許可します。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "RestrictDSQLDBConnectByVPCAndPrincipal",
            "Effect": "Allow",
            "Action": [
                "dsql:DBConnect"
            ],
            "Resource": "*",
            "Condition": {
                "StringEquals": {
                    "aws:SourceVpc": "vpc-xyz",
                    "aws:PrincipalArn": [
                        "arn:aws:iam::444455556666:role/ApprovedRole",
                        "arn:aws:iam::444455556666:user/ApprovedUser"
                    ]
                }
            }
        }
    ]
}

このアプローチでは、承認された VPC からのリクエストであっても、信頼された IAM 主体の 1 つから発行される必要があります。
これにより、Aurora DSQL へのアクセスを許可する前に、ID とネットワークの起点を組み合わせることで、強力な多層防御を実現します。

セキュリティのベストプラクティス

Aurora DSQL 用に PrivateLink を設定する際は、データとインフラストラクチャを保護するために、複数のレイヤーでアクセス制御を実装することが重要です。全体的なセキュリティ対策を強化するために、以下のセキュリティのベストプラクティスを検討してください：

セキュリティグループ – VPC インターフェースエンドポイントに厳密に定義されたセキュリティグループを関連付けます。これらは、承認された Amazon EC2 インスタンスやアプリケーションサブネットなど、VPC 内の特定の信頼できるリソースからのトラフィックのみを許可し、PostgreSQL の場合は通常 TCP 5432 など、必要なポートへのアクセスを制限する必要があります。
IAM ポリシー – VPC エンドポイントの作成、変更、削除を制御する IAM ポリシーを定義することで、最小権限アクセスを実施します。これにより、承認されたエンドユーザーとサービスのみが Aurora DSQL クラスターへのネットワークアクセスを管理できるようになります。
ネットワーク ACL – ネットワーク ACL を使用して、ステートレスなサブネットレベルのトラフィックフィルタリングを提供します。セキュリティグループと併せて追加の保護層を提供するため、VPC エンドポイントのネットワークインターフェースをホストするサブネットに必要な着信および発信トラフィックのみを許可するようにネットワーク ACL を設定します。

これらのベストプラクティスを組み合わせることで、AWS 環境内の Aurora DSQL 接続を保護する、堅牢な多層防御戦略を構築できます。

デプロイ計画に関する考慮事項

Aurora DSQL を PrivateLink でデプロイする際は、以下の点を考慮してください：

共有エンドポイント – 同じサービス名を使用する場合、複数の Aurora DSQL クラスターで 1 つの PrivateLink インターフェースエンドポイントを共有できます。これにより、接続が簡素化され、運用オーバーヘッドを削減できます。
リージョンの範囲 – PrivateLink エンドポイントはリージョン固有です。同一リージョン内の Aurora DSQL クラスターにのみアクセスできます。PrivateLink を介したリージョン間アクセスはサポートされていません。
コストに関する考慮事項 – インターフェースエンドポイントとデータ処理の料金を含む、標準的な PrivateLink の料金が適用されます。PrivateLink の使用料は Aurora DSQL の使用料とは別に請求されるため、コスト計画に含める必要があります。
接続制限 – PrivateLink エンドポイントを介して同時に確立できる接続数は、Aurora DSQL の接続制限によって制限されます。スロットリングや接続エラーを避けるため、ワークロードの設計がこれらの制限に適合していることを確認してください。

これらの考慮事項を早期に理解することで、Aurora DSQL と PrivateLink を中心とした、安全でスケーラブル、かつコスト効率の高いアーキテクチャを設計することができます。

まとめ

この投稿では、パブリックエンドポイントと PrivateLink エンドポイントの両方を使用して、Aurora DSQL クラスターへの安全な接続とアクセス制御を実現する方法について説明しました。
VPC 内からでも、オンプレミスのデータセンターからでも、Aurora DSQL にアクセスする際に、ここで説明したアプローチを使用することで、トラフィックをプライベートに保ち、きめ細かいアクセス制御を実施し、セキュリティのベストプラクティスに準拠することができます。

VPC インターフェイスエンドポイント、セキュリティグループ、IAM ポリシー、VPC エンドポイントポリシーを使用することで、信頼できるリソースとアイデンティティのみにアクセスを制限する堅牢なセキュリティ境界を構築できます。
Aurora DSQL の接続に関する安全でスケーラブルなソリューションを設計する際は、この記事の知見をアーキテクチャの判断材料として活用してください。

Amazon Web Services ブログ