AWS VPCで、「踏み台」と呼ばれるサーバーがあります。
なぜ踏み台なのか。
「踏み台」は通常の意味では高いところのものを取るときなどに使う台のことですが、比喩的表現では何だか悪い意味で使われます。「他人を踏み台にして出世する」など、いかにも卑怯なイメージです。
元々の用語（英単語）では「bastion」なんですよ。日本語にすると「要塞」です。
AWS公式でも「Linux Bastion Hosts on the AWS Cloud」として、手法が紹介されています。これがおそらくAWS VPCで「踏み台」の手法が一般化されることになった起源です。
Linux Bastion Hosts on the AWS Cloud
ところが、日本語ページの題名は「AWS クラウドでの Linux 踏み台ホスト」ですよ。
AWS クラウドでの Linux 踏み台ホスト
なぜ「踏み台」などと訳したのか。他にいい言葉はなかったのでしょうか。
確かに「要塞サーバー」というほど役割が要塞をイメージさせるか、と言われると、まだしも「踏み台」の方が役割のイメージに近い気がします。
しかし私はいい言葉を思いつきました。「橋頭保」です。橋頭保サーバー。
元々の要塞の意味も少し残しつつ、役割のイメージにピッタリ。我ながら、いい言葉ですね。全く浸透する気配がないのが残念です。
以上で、記事の本題は記しましたので、ここからはおまけでVPCにおける踏み台の役割と構成、必要なセキュリティグループについてです。
踏み台サーバーの概要
下図のように、プライベートサブネットのEC2インスタンス（図のA）にOSログインしてメンテナンスする際に、
- このインスタンス自体は外部からは直接はアクセスできない（プライベートサブネットなので、外部からのアクセスを可能にするルートテーブルを割り当てていない）
- パブリックサブネットに置いたインスタンス（図のB）を外部（メンテナンスするチームの拠点）からアクセス可能にする
- B-A間は同一VPCのサブネットのため、暗黙のルーティングがされており、相互でアクセス可能
このような構成を作っておき、メンテナンスするチームはインスタンスBへリモートアクセス、ログインした後、インスタンスBを操作してインスタンスAへリモートアクセス、ログインします。この手法を「踏み台サーバーを利用したログイン」と言います。そしてBが「踏み台サーバー」です。
この手法は、次の2つの点においてアクセスを「限定」することで、セキュリティの向上を図っています。
- 踏み台サーバーは外部の「メンテナンスに必要なグローバルIPアドレス」からのアクセスのみを許可し、各インスタンスは踏み台サーバーからのアクセスのみを許可することで、通信元のIPアドレスを限定
- 踏み台サーバーを通常は停止させ、メンテナンスに必要な時間帯だけマネジメントコンソール等から起動することで、各インスタンスへ外部からアクセスできる時間帯を限定
踏み台サーバーの構成例
実際に踏み台サーバーを使用する構成の一例が以下です。
ここでは構成内容の表と構成図の掲載のみとし、各インスタンスの構築手順については触れません。
踏み台サーバー(B)
| OS | インスタンスタイプ | ドライブサイズ | 他設定 |
|---|---|---|---|
| Amazon Linux 2 | t3.nano | 8 GB | Elastic IPを割り当て |
メンテ対象サーバー(A)
（あくまでも一例なので、OS、インスタンスタイプ等を限定するものではありません）
| OS | インスタンスタイプ | ドライブサイズ | 他設定 |
|---|---|---|---|
| Windows Server 2016 | t3.small | 35 GB |
踏み台サーバーに必要なセキュリティグループ
さらに各インスタンスに下表のセキュリティグループを割り当てます。
セキュリティグループ名(例)：Sample-on-bastion-sg
割り当て先：踏み台サーバー(B)
Inbound
| TCP/UDP | ポート | 通信元 | 備考 |
|---|---|---|---|
| TCP | 22 | xxx.xx.xxx.xx/32 (メンテチーム拠点グローバルIP） |
Outbound
| TCP/UDP | ポート | 宛先 | 備考 |
|---|---|---|---|
| TCP | 3389 | 172.30.0.0/16 (VPC CIDR） | メンテ対象サーバーがLinuxの場合は、TCP/22等 |
| UDP | 3389 | 172.30.0.0/16 (VPC CIDR） | （UDPは不要でした） |
セキュリティグループ名(例)：Sample-from-bastion-sg
割り当て先：メンテ対象サーバー(A)
Inbound
| TCP/UDP | ポート | 通信元 | 備考 |
|---|---|---|---|
| TCP | 3389 | Sample-on-bastion-sgのsg-id | メンテ対象サーバーがLinuxの場合は、TCP/22等 |
| UDP | 3389 | Sample-on-bastion-sgのsg-id | （UDPは不要でした） |
Outbound
（なし）
補足
踏み台サーバーがAmazon Linuxであっては、メンテ対象サーバーであるWindows Serverにリモートデスクトップ接続できないので不便では、
というのは入門者であれば感じる疑問と思います。
しかし、「SSHポートフォワーディング」の機能を使うことで、何とクライアントPCから踏み台サーバーを経由してのリモートデスクトップ接続が可能なのです。そのため、踏み台サーバーは最小構成でコストも最小限のAmazon Linuxで問題ないです。
具体的な「SSHポートフォワーディング」の方法については、後日記事にする予定です。（↓しました）
