この記事は約4分で読めます。
この記事は1年以上前に書かれたものです。
内容が古い可能性がありますのでご注意ください。
こんにちは。今年のスギ花粉量は例年の10倍と聞き、恐れおののいているCS2課の畑野です。
私が中途入社後、IE課の研修で悩んだVPC内のインスタンス間ルーティングについて記事にしてみました。
実現したいこと
お客様のセキュリティ方針により、ファイアウォールのような機能ではなく、ルーティング制御で踏み台サーバ(EC2)から直接データベースサーバ(RDS)へ通信出来ない設計にして欲しいとのご要望がありました。
ご要望の背景は過去に踏み台サーバ経由でデータベースサーバへ接続出来てしまい、情報漏洩してしまったというセキュリティ事故に起因するものでした。
この要件を満たすため、踏み台サーバからデータベースサーバへのルーティング制御で接続を禁止してみます。
構成
検証用にサブネット構成を3層とし、パブリックに踏み台サーバ、プロテクテッドにWebサーバ、プライベートにDBサーバを配置します。
図の赤矢印の箇所が今回、通信させたくない箇所です。
パブリックはインターネットから通信可、プロテクテッド、プライベートはインターネットからの通信は不可とします。 ルートテーブルは構成図の通り、各サブネットで分けます。
また、ルーティング制御で通信制御したいためセキュリティグループではDBサーバへの通信を許可し、下記の設定とします。
- 踏み台サーバ
- アウトバウンド方向の通信は全許可
- Webサーバ
- アウトバウンド方向の通信は全許可
- DBサーバ
- インバウンドは
172.20.32.0/22からTCP/3306で接続出来るよう許可します。
- インバウンドは
WebサーバからDBサーバへの接続
まずは各サーバへの接続を確認します。ひとまずインターネット経由で踏み台サーバへSSH接続します。その後、WebサーバへSSH接続し、WebサーバからmysqlコマンドでDBサーバへ接続します。
踏み台サーバからDBサーバへの接続
次に踏み台サーバから直接DBサーバへ接続を試みます。
ルートテーブルを確認
改めてルートテーブルを確認してみると、172.20.32.0/22 localのルーティングが存在します。
プロテクテッド、プライベート用のルートテーブルも同様です。
さらになんとこのルートは削除出来ません。
また、踏み台サーバの所属するパブリックのルートテーブルにDBサーバへの172.20.34.0/24宛の通信をBlackholeに向けるルーティングを追加し、DBサーバ宛の通信を破棄する事も出来ません。
どうやら既存のルートテーブルでは踏み台サーバ→DBサーバへはルーティング上は通信出来てしまうようです。
それではどうすれば？
踏み台、Webサーバが所属するVPCとDBサーバが所属するVPCを分けます。
その後、VPCピアリング接続し、各ルートテーブルに行き帰りのルーティングを追加します。
追加ルーティングは赤字の箇所です。
こうすることで踏み台サーバが利用するパブリック用ルートテーブルには192.168.22.0/24向けのルーティングがないため、直接DBサーバへ接続出来なくなります。
改めて踏み台サーバからDBサーバへ接続してみる
踏み台サーバからDBサーバへの通信を確認してみます。
踏み台サーバからSYN(Flags [S])パケットを送信していますが、SYN/ACK(Flags [S.])のパケットが返って来ていないことからDBサーバへは接続出来ていないと判断出来そうです。
※DBサーバのセキュリティグループで踏み台サーバからの通信は許可してあります
ついでにパブリック用のルートテーブルとプライベート用のルーティングテーブルにお互いに通信するためのルートを追加すると、踏み台サーバからも接続が出来ることを確認出来ました。 よって、ルートがないことで通信が出来ていないことが検証出来ました。
所感
VPC内のルートテーブルにあるVPC CIDR宛のルーティングを削除出来ないことが分かり、踏み台サーバからDBサーバへのルーティングを制御出来ず、八方塞がりの思いでした。
1つのVPC内でサブネットを分けた多段ネットワーク構成を作ることは良くあると思いますが、セキュリティグループやネットワークACLで通信制御する以外にもこのような方法もあります。
今回の構成は案の1つですが、どなたかの参考になれば幸甚です。
最後に
私は中途入社後、IE課という組織で研修を受けました。今回の例はその研修で学んだことを記事にしてみました。 IE課のトレーニングカリキュラムについては、弊社鎌田のブログ記事をご覧下さい。
