SSM経由で安全接続！ローカルからプライベートRDSへ繋ぐ設定手順

はじめに

セキュリティの観点から、AWS上のデータベース（RDSやAurora）はパブリックアクセスを無効化し、プライベートサブネットに配置するのが鉄則です。しかし、開発作業や運用メンテナンスにおいて、ローカルPCのGUIツール（DBeaverやpgAdminなど）からデータベースに直接接続したいケースは多々あります。

本記事では、踏み台サーバー（EC2）にSSHポートを開放することなく、AWS Systems Manager（SSM）のセッションマネージャー経由で安全にポートフォワーディングを行い、ローカルPCからプライベートRDSへ接続するための具体的な手順と設計のベストプラクティスを解説します。

前提知識/必要な理由

従来、プライベートサブネット内のRDSにアクセスするには、パブリックサブネットに踏み台サーバーを構築し、SSHの22番ポートを開放して「SSHトンネル」を張る手法が一般的でした。しかし、この方法には以下のデメリットがあります。

踏み台サーバーのセキュリティグループで22番ポートをインターネットに公開する必要があり、ブルートフォース攻撃などのセキュリティリスクが高まる。
踏み台サーバーにログインするためのSSH鍵（Key Pair）の管理や配布の手間が発生する。
誰がいつアクセスしたのかという監査ログ（トレース）が残りにくい。

AWS Systems Manager（SSM）のポートフォワーディング機能を利用すれば、踏み台サーバーのインバウンドポートを完全に「すべて閉じた」状態で、IAM権限による厳格なアクセス制御のもと、安全なトンネルラインを確立できます。

具体的な設定手順・設計方法

ステップ1：SSM用踏み台EC2の構築とIAMロールの設定

まず、SSMの踏み台となるEC2インスタンス（Linux）をプライベートサブネット、またはNATゲートウェイ経由でインターネットにアウトバウンド通信ができるサブネットに作成します。このEC2がSSM経由で制御されるために、適切なIAMロールをアタッチする必要があります。

1. IAMコンソールから、信頼関係に「ec2.amazonaws.com」を指定したロールを作成します。

2. ポリシーテンプレートとして、AWS管理ポリシーである AmazonSSMManagedInstanceCore をアタッチします。

3. 作成したIAMロールを、踏み台EC2インスタンスに「IAMインスタンスプロフィール」として割り当てます。

ステップ2：セキュリティグループの設計・設定

セッションマネージャーはEC2内部で稼働するSSM AgentがAWSのSSMエンドポイントとHTTPS（443ポート）でアウトバウンド通信を行うことで動作します。そのため、踏み台EC2のインバウンドルールは「すべて空（許可なし）」で問題ありません。

通信を許可する必要があるのは、踏み台EC2からRDSへのアクセスのみです。以下のようにセキュリティグループを設計します。

踏み台EC2用のセキュリティグループ（例: sg-bastion）
- インバウンドルール：なし（空にする）
- アウトバウンドルール：すべてのトラフィック（または、RDSのデータベースポートとHTTPS/443のみ）
RDS用のセキュリティグループ（例: sg-rds）
- インバウンドルール：踏み台EC2のセキュリティグループ（sg-bastion）からのデータベースポート（例: PostgreSQLの場合は5432）のみを許可

ステップ3：ローカルPC環境のセットアップ

ローカルPCからSSM経由でポートフォワーディングを実行するには、ローカル環境に「AWS CLI」と、拡張プラグインである「Session Manager Plugin」をインストールする必要があります。

1. AWS CLIのインストール
お使いのOSに合わせてAWS CLIをインストールし、接続用IAMユーザーの認証情報を aws configure コマンドで設定しておきます。

2. Session Manager Pluginの導入
Session Manager Pluginは通常のAWS CLIとは異なる外部プラグインです。これをインストールしないとポートフォワーディングが動作しません。

MacOSの場合は、以下のHomebrewコマンド、またはAWS公式インストーラーから導入できます。

brew install --cask session-manager-plugin

Windowsの場合は、AWS公式ページから SessionManagerPlugin.msi をダウンロードして実行してください。インストール後、以下のコマンドで導入確認を行います。

session-manager-plugin --version

ステップ4：ポートフォワーディングコマンドの実行と接続確認

準備が整ったら、ローカルPCのターミナルから以下のAWS CLIコマンドを実行します。これにより、ローカルの指定ポート（例: 15432）へのアクセスが、踏み台EC2（i-xxxxxx）を経由して、宛先RDSのエンドポイント（xxxx.rds.amazonaws.com）のポート（5432）へ転送されます。

aws ssm start-session \
  --target i-XXXXXXXXXXXXXXXXX \
  --document-name AWS-StartPortForwardingSessionToRemoteHost \
  --parameters '{"host":["xxxx.xxxxxx.ap-northeast-1.rds.amazonaws.com"],"portNumber":["5432"],"localPortNumber":["15432"]}'

コマンド実行後、ターミナルに「Waiting for connections…」と表示されればトンネルの確立は成功です。この状態を維持したまま、DBeaverなどのデータベースGUIクライアントを起動し、接続先ホストを localhost、ポートを 15432 に指定して接続をテストしてください。

実務での注意点

SSM Agentの起動確認： 踏み台EC2でSSM Agentが最新バージョンで正常起動している必要があります。特に独自AMIや古いOSを使用している場合は、手動でAgentを最新化してください。
IAMポリシーの最小権限原則： 開発者にセッションマネージャーの利用を許可する際、任意のインスタンスへのアクセスを防ぐため、IAMポリシーの Resource 句で対象の踏み台EC2インスタンスARNを指定し、権限を制限（最小権限の原則）するように設計してください。
接続タイムアウトの考慮： デフォルトのセッションタイムアウト設定によって、一定時間操作を行わないと接続が切断される場合があります。必要に応じて、SSMのPreferences設定からタイムアウト時間を調整してください。

まとめ

SSMポートフォワーディングを活用することで、SSHキーの管理コストをゼロにし、インバウンドポートが閉じた非常に堅牢な「セキュアな踏み台」を構築可能です。これによりセキュリティ監査への対応も容易になります。AWSインフラを設計・構築する際は、本構成を標準構成の1つとして採用することを強くお勧めします。