Amazon Redshift クラスターがパブリックアクセス可能となっている場合の対処方法について

2025.04.08 　最終更新日: 2025.04.09

このブログシリーズ 「クラウドセキュリティ 実践集」 では、一般的なセキュリティ課題を取り上げ、「なぜ危険なのか？」 というリスクの解説から、「どうやって直すのか？」 という具体的な修復手順（コンソール、AWS CLI、Terraformなど）まで、分かりやすく解説します。

この記事では、Amazon Redshift クラスターでパブリックアクセスを制限する内容について解説します。

画像に alt 属性が指定されていません。ファイル名: 13e11608c3ab504725ce4500088eb55e-1024x341.webp

ポリシーの説明

[PCI.Redshift.1] Amazon Redshift クラスターはパブリックアクセスを禁止する必要があります

https://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/redshift-controls.html#redshift-1

このコントロールは、Amazon Redshift クラスターがパブリックにアクセス可能かどうかをチェックします。このコントロールは、クラスター設定項目の PubliclyAccessible フィールドを評価します。

クラスター設定項目の PubliclyAccessible が true の場合はパブリックに公開されていると見なされ、是正が推奨されます。 その一方で、利用しているBIツールなどの要件によっては、パブリックアクセス設定を有効にせざるを得ないケースも考えられます。

その場合の代替的な対処法についても後述します。

修復方法

まずはシンプルにパブリックアクセスを無効にする方法についてまとめます。これは、PubliclyAccessible の設定を false にすれば解決できます。

AWSコンソールでの修正手順

以下の通りの手順で設定変更を行います。

① Amazon Redshiftにアクセスし、対象のクラスターを選択

②「設定」タブなどで「パブリックアクセス可能」が有効になっていることを確認します。（UI上で “Publicly accessible: Yes” やそれに類する表示があります）。

③「アクション」から「パブリックアクセス可能な設定を変更」をクリック

④「パブリックアクセス可能」のチェックボックスをオフにし、「変更を保存」をクリックします。（設定変更にはクラスターの変更処理が伴います）

Terraformでの修復手順

Terraformでは、aws_redshift_cluster リソース定義内の publicly_accessible 属性を false に設定することで、パブリックアクセスを無効化できます。

https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/redshift_cluster#publicly_accessible

# Redshift cluster
resource "aws_redshift_cluster" "redshift_cluster" {
  cluster_identifier  = "my-redshift-cluster"
  database_name       = "mydb"
  master_username     = "admin"
  master_password     = "YourStrongPasswordHere"  # Consider using AWS Secrets Manager
  node_type           = "dc2.large"
  cluster_type        = "single-node"  # or "multi-node" with number_of_nodes set
  
  # Security settings
  vpc_security_group_ids = [aws_security_group.redshift_sg.id] # 事前に定義されたSGを指定
  cluster_subnet_group_name = aws_redshift_subnet_group.redshift_subnet_group.name # 事前に定義されたサブネットグループを指定
  
  # ↓↓↓ ここでパブリックアクセスを無効化 (重要) ↓↓↓
  publicly_accessible    = false 
  # ↑↑↑ ここでパブリックアクセスを無効化 (重要) ↑↑↑
  
  # Enable encryption
  encrypted             = true
  # kms_key_id          = "your-kms-key-arn" # オプション: カスタムKMSキーを使用する場合
  
  # Enable logging
  logging {
    enable = true
    # bucket_name = "your-log-bucket-name" # オプション: ログバケットを指定する場合
    # s3_key_prefix = "redshift-logs/"     # オプション: ログプレフィックス
  }

  # Other optional settings
  skip_final_snapshot   = true  # 本番環境ではfalse推奨
  automated_snapshot_retention_period = 7
  preferred_maintenance_window = "sun:04:00-sun:04:30"

  tags = {
    Name = "my-redshift-cluster"
  }
}

Terraformコードのポイント:

  • publicly_accessible = false を設定することが、このポリシーに準拠するための最も直接的な方法です。
  • これにより、RedshiftクラスターにパブリックIPアドレスが割り当てられず、インターネットからの直接接続ができなくなります。
  • 同時に、vpc_security_group_ids で適切なセキュリティグループを、cluster_subnet_group_name でプライベートサブネットを含むサブネットグループを指定することが、VPC内でのセキュアなアクセス制御に不可欠です。

要件的にAWSサービス外からのアクセスが必要なケースはどうするべきなのか？

さて、BIツールなどのAWS外のサービスからアクセスする必要があるケースもあるかと思います。

その場合の対処方法について以下4点ありますがその中で今回手軽な2点をご紹介しますので、参考にしてみてください。

  1. 踏み台サーバーを経由して、Redshiftへアクセス可能にする
  2. セキュリティグループで制限して、Redshiftへアクセス可能にする
  3. VPNを構築し、特定のユーザーからRedshiftへアクセス可能にする
  4. Direct Connectを使用して自社の拠点からRedshiftへアクセス可能にする

1. 踏み台サーバ経由での接続

これはよく用いられる方法で、プライベートサブネット配下に設置したRedshiftに対してのアクセスを手軽かつ比較的低コストで実現可能になります。

実装方法:

  1. 低スペックなEC2インスタンス（例: t3.nano）をパブリックサブネット（インターネットゲートウェイへのルートを持つサブネット）配下に一つ用意します。
  2. 踏み台EC2インスタンスにアタッチするセキュリティグループのインバウンドルールで、SSH接続（デフォルトはTCP 22番ポート）の接続元IPアドレスを信頼できるIP（例: オフィスのIP、VPNの出口IP）のみに制限します。(SSHポート番号を変更したり、通常のSSH接続の代わりにAWS Systems Manager Session Manager経由での接続やポートフォワーディングを利用したりすると、さらに安全性が高まりますが、今回は説明を割愛します。)
  3. Redshiftクラスター用に専用のセキュリティグループを作成します。（例: redshift-sg）。
  4. redshift-sg のインバウンドルールで、踏み台EC2インスタンスのセキュリティグループからのTCP接続（Redshiftのポート、デフォルト5439番）を許可します。踏み台EC2インスタンスのセキュリティグループのアウトバウンドルールで、redshift-sg へのTCP接続（Redshiftのポート）を許可します。これにより、踏み台EC2とRedshift間でのみ通信が可能になります。
  5. pgAdmin、DBeaver、SQL Workbench/Jなどのクライアントツールを使用して、踏み台EC2インスタンスへのSSHトンネルを設定し、そのトンネル経由でRedshiftクラスターに接続できるか確認します。

2. IP制限の実施

何らかの理由で踏み台サーバーを経由せず、かつRedshiftクラスターにパブリックIPアドレスを持たせて外部からアクセスする必要がある場合（publicly_accessible = trueのままにする場合）の、次善策です。接続元が固定IPアドレスを持っている場合に有効です。

前提として、NACL（ネットワークACL）で該当の通信がブロックされていないことが必要です。

  • セキュリティグループで特定のIPからのインバウンド接続を許可

実装方法:

  1. AWS Consoleでの設定:
    • Redshiftクラスターにアタッチされているセキュリティグループを選択し、編集します。
    • 「インバウンドルール」タブで、「ルールを追加」をクリックします。
    • タイプで「Redshift」を選択（またはカスタムTCPでポート5439を指定）、プロトコルがTCPであることを確認し、ソースに許可したい固定IPアドレスをCIDR形式（例: xxx.xxx.xxx.xxx/32）で指定します。「ルールを保存」します。
  2. AWS CLIでの設定:
aws ec2 authorize-security-group-ingress \
  --group-id sg-1234567890abcdef0 \ # ご利用のセキュリティグループIDに合わせてください
  --protocol tcp \
  --port 5439 \ # Redshiftのポート番号
  --cidr xxx.xxx.xxx.xxx/32   # ご利用の固定IPアドレス/32

3.Terraformでの設定:

resource "aws_security_group_rule" "redshift_ingress_ip_limit" {
  # このルールを既存のRedshift用セキュリティグループに追加する
  security_group_id = aws_security_group.redshift_sg.id # 既存のSGリソース名に合わせる

  type              = "ingress"
  from_port         = 5439 # Redshiftのポート番号
  to_port           = 5439
  protocol          = "tcp"
  cidr_blocks       = ["xxx.xxx.xxx.xxx/32"] # ご利用の固定IPアドレス/32
  description       = "Allow access from specific BI tool IP"
}

最後に

今回は、Amazon Redshift クラスターでパブリックアクセスを制限する方法と、やむを得ず外部アクセスが必要な場合の代替策についてご紹介しました。 セキュリティの観点からは、可能な限り publicly_accessible = false とし、踏み台サーバー経由やVPN経由でのアクセスを推奨します。IPアドレス制限は、それが唯一の選択肢である場合の次善策として検討してください。ぜひこの記事を参考に、ご自身の環境に合った安全な設定を検討・実施してみてください。

ちなみに、より大規模でセキュアな接続が必要な場合は、ネットワーク設計全体を見直し、AWS Direct ConnectやAWS Site-to-Site VPNの利用を検討することになりますが、これらはVPCやオンプレミス環境全体の設計に関わるため、時間とコストを要する可能性があります。

この問題の検出は弊社が提供するSecurifyのCSPM機能で簡単に検出及び管理する事が可能です。

運用が非常に楽に出来る製品になっていますので、ぜひ興味がある方はお問い合わせお待ちしております。

最後までお読みいただきありがとうございました。この記事が皆さんの役に立てば幸いです。

この記事をシェアする

クラウドセキュリティ対策実践集一覧へ戻る

貴社の利用状況に合わせた見積もりを作成します。

見積もりを希望する
資料ダウンロード

料金プランを詳しく見る