AWS Transfer for SFTP のパブリックアクセスを特定 IP に限定する方法

AWS Transfer for SFTP のパブリックアクセスを特定 IP に限定する方法

AWS Transfer for SFTP へのパブリックアクセスを特定 IP に限定する方法を紹介します!
Clock Icon2019.06.26

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

現在、AWS Transfer for SFTP をパブリックエンドポイントで利用する場合に、特定 IP のみを許可するような機能はありません。しばらくして AWS Transfer for SFTP に VPC エンドポイントが追加されたので以下のエントリーを書きました。

[アップデート]Transfer for SFTP が PrivateLink に対応したので、アカウント間のファイル共有に使ってみる

この記事中で余談として「PrivateLink と NLB で特定パブリック IP 許可ができるか?」という考察を述べました。

  • パブリック NLB を前段においても NLB にはセキュリティグループも AWS WAF も紐づけできない
  • VPC エンドポイントに到達するソース IP アドレスは、NLB のプライベート IP になるため、VPC エンドポイントのセキュリティグループで制限することも出来ない

以上のことから

「結論としては、フルマネージドサービスのみでは、現状は出来ません(`・ω・´)キリッ」

という思い込みをブチまけておりました。

そう、思い込みだったんですね。。つい先日「出来るやんけー!」ということに気づいてしまいました。。なぜなら、公式の「よくある質問」に出来るって書いてるからです!

Q: 着信トラフィックにフィルターをかけて、自分の SFTP サーバーの VPC エンドポイントにアクセスすることは可能ですか?

A: はい。自分の SFTP サーバーの VPC エンドポイントを使用すると、同じ VPC にあるクライアント、ユーザーが指定したその他 VPC のクライアント、または、AWS Direct Connect、AWS VPN、VPC ピアリングなど、自分の VPC を拡張するネットワーク技術を使用している、オンプレミス環境にあるクライアントのみに、アクセスを可能にすることができます。NLB を作成し、そのターゲットを自分の SFTP サーバーの VPC エンドポイントとして指定すると、インターネットトラフィックがこのエンドポイントにアクセスできるようになります。VPC にある既存のファイアウォール、または自分のサブネットにおけるネットワークアクセスコントロールリスト (NACL) のルールは、着信したソース IP アドレスのアクセスを制限することができます。このセットアップについての詳細は、Network Load Balancer のドキュメントをご覧ください。(引用:AWS Transfer for SFTP のよくある質問)

すみません。私の思い込みでした!というか NACL の存在を失念してました!!

今回はお詫びに NLB + NACL を使って AWS Transfer for SFTP へのパブリックアクセスを特定 IP に限定する方法を検証したので、これでご勘弁ください!

はじめに

検証環境の概要

今回は以下の環境で検証しています。

項目 パラメータ 備考
リージョン ap-northeast-1(東京)
エンドポイントタイプ VPC
ロードバランサ NLB
ターゲットタイプ ip ターゲットには VPC エンドポイントの
プライベート IP を指定
許可する IP 59.xx.xx.xx/32 SOCKS プロキシ経由した場合
許可しない IP 58.xx.xx.xx/32

検証環境の構成図

図にすると以下のような環境になります。

NACL 未設定状態の確認

現時点では NACL を設定していないので、 58.xx.xx.xx の IP アドレスからも SFTP 接続できています。

$ curl https://checkip.amazonaws.com/
58.xx.xx.xx

$ sftp -i ssh-key.pem sftpuser@sftp-nlb-xxxxxxxxxx.elb.ap-northeast-1.amazonaws.com
Connected to sftpuser@sftp-nlb-xxxxxxxxx.elb.ap-northeast-1.amazonaws.com.
sftp> 

それでは、ここから特定 IP のみ接続できるように制限していきます。

NACL 設定

NLB & NACL でハマリそうなポイント

NACL は番号の低い順に評価されますので、デフォルトの ALL ALLOW よりも低い番号でルールを追加していきます。( ALL ALLOW は 100 → 300 に変更しました)

特定 IP のみを許可したいので、まずは 59.xx.xx.xx/32 からの SSH(22) を許可します。しかし、このままでは他の IP も ALL ALLOW で通信出来てしまうので、次に 0.0.0.0/0SSH(22) を拒否します。

アウトバウンドは特に制限しませんので、デフォルトのままです。パッと思いついた NACL のルールは、このような形です。

さて、結果はどうなるでしょうか? sftp でプロキシ経由のアクセスを試してみます。

$ sftp -o ProxyCommand='nc -x proxy.example.com:8080 %h %p' -i ssh-key.pem sftpuser@sftp-nlb-xxxxxxxxxx.elb.ap-northeast-1.amazonaws.com
nc: read failed (7/10): Broken pipe
ssh_exchange_identification: Connection closed by remote host
Connection closed

はい、通信できません。。

NLB & NACL 正しい設定

特定 IP は許可したのに、なぜ接続できないのでしょうか?

その答えは図にすると簡単でした。

今回、NLBをパブリック、VPCエンドポイントはプライベートという形でサブネットを分けて作成していましたので「通信元 --> NLB」(59.xx.xx.xx)は許可できていますが、「NLB --> VPCエンドポイント」(192.168.xx.xx)SSH(22) が NACL で許可されていないのです。NLB に入ってからの通信を意識できていないと、私のように小一時間ハマってしまうのでお気をつけください。

それでは NLB の所属する2つのサブネットで SSH(22) を許可します。設定は以下のとおりです。

通信確認してみましょう。まずはプロキシを経由しない 58.xx.xx.xx の通信です。

$ sftp -i ssh-key.pem sftpuser@sftp-nlb-xxxxxxxxxx.elb.ap-northeast-1.amazonaws.com
ssh: connect to host sftp-nlb-xxxxxxxxxx.elb.ap-northeast-1.amazonaws.com port 22: Network is down
Connection closed.
Connection closed

NACL が効いているので接続できませんね。

それでは、次に特定 IP である 59.xx.xx.xx からの通信を確認してみましょう。

$ export https_proxy=socks://proxy.example.com:8080
$ curl https://checkip.amazonaws.com/
59.xx.xx.xx

$ sftp -o ProxyCommand='nc -x proxy.example.com:8080 %h %p' -i ssh-key.pem sftpuser@sftp-nlb-xxxxxxxxxx.elb.ap-northeast-1.amazonaws.com
Connected to sftpuser@sftp-nlb-xxxxxxxxxx.elb.ap-northeast-1.amazonaws.com.
sftp>

接続されましたね!これで AWS Transfer for SFTP にパブリックアクセスで 特定 IP アドレスから利用できることが確認できました!

考慮点

特定 IP からの SFTP のみに制限したい場合、 SSH(22) を制限する必要があります。しかしながら、NACL はサブネット単位で設定されることになりますので SSH をはじめとして SFTP 以外の用途で SSH(22) を多用されている環境においてはよく検討ください。個人的には EC2 の運用管理に影響を及ぼさないためにも AWS Transfer for SFTP 専用のサブネットを設けてしまうのが簡単で良いんじゃないかと思います。

さいごに

先日は誤った認識をバラまいてしまって申し訳ございませんでした!もし、「パブリックアクセス限定できないんじゃ AWS Transfer for SFTP 使えんな・・・。」と断念された方がおられましたら、この記事を参考に再検討いただければと思います!

下調べと検証を行ったうえで記事を書いてますが、まだまだ思慮が足りてないな、と痛感しました!より良い記事をお届けできるように研鑽を積んでいきたいと思います!

以上!大阪オフィスの丸毛(@marumo1981)でした!

Share this article

facebook logohatena logotwitter logo

© Classmethod, Inc. All rights reserved.