私が担当しているプロダクトの検証環境はIP制限をしています。更にはその前段に、全プロダクト共通の認証基盤があり、認証基盤の検証環境も同様にIP制限がされている状態です。開発者が検証環境にアクセスできるように全社VPNのIPはもちろん許可していますが、
という問題があるため、開発者の自宅IPも許可しているのが現状です。この運用には下記のような課題があり、今回これらを解決したいと思います。
IP許可設定の運用負荷が高い。
- 開発者の増減や、自宅のルーター再起動・PC再起動でIPが変わることもある
- WorkSiteプロダクトだけでは完結せず、毎回認証基盤にも依頼をする必要がある
自宅IPは必ずしも個人に紐づいているわけではないため、例えば開発者が住んでいるマンション全体を許可してしまう可能性もありセキュリティに問題がある。
🧑💻技術アーキテクチャ
システム概要図
概要
- AWSのClient VPN Endpointを構築し、クライアント(PCやスマートフォン)とVPCの間でVPN通信をさせます。
- VPN確立後、クライアントからのインターネット通信はVPCを経由することなり、その際送信元IPがNatGatewayによってNatされ、NatGatewayにアタッチしているEIPのIPなります。この仕組みでIP固定化を実現します。
認証方式について
ClientVPNの認証方式は3つありますが、今回はActive Directory（以下AD。）によるユーザー認証方式を採用しました。 なお、各認証方式に対するコメントを以下に記しておきます。
1. クライアント証明書による相互認証
AWSのコストはかからず安価ですが、ユーザーの増減があればクライアント証明書の発行/失効の作業が発生してしまうため不採用にしました。
2. AD によるユーザー認証(採用)
AWS SSO用のADが存在しているので、連携させて貰えればADの構築が必要無いのと、ユーザーの増減は今まで通りADでやってもらえればよいので、ClientVPN側ではユーザー増減に伴う作業が発生しないメリットがあります。AD Connector の費用はかかってしまいますが、それでも他の方式よりメリットが大きいため採用しました。
3. SAML によるユーザーフェデレーション認証
AWS SSOと連携できるため、「2. ADによるユーザー認証」と同等のメリットがあるかつ、AD Connectorの費用がかからないため、最有力候補だったのですが、モバイルデバイス(Android/iOS)からのSAMLベースのフェデレーション認証を行うためのVPNクライアントが現時点で存在しないことが判明したため不採用となりました。
(参考URL)
https://docs.aws.amazon.com/vpn/latest/clientvpn-user/connect.html
https://docs.aws.amazon.com/vpn/latest/clientvpn-user/connect-aws-client-vpn-connect.html
Q&A
Q：なぜNICが冗長化されていないですか?
A：NICの費用を削減するためです。今回構築する仕組みはサービスにクリティカルな用途ではないため、冗長構成にせず１つのサブネットのみに関連付けさせるように、可用性よりもコスト削減を優先しました。
Q：認証基盤のIP制限運用はどうなりますか?
A：NatGatewayにアタッチされているEIPを許可設定してもらえれば、その後は原則なにも運用が発生しない想定です。またNatGatewayにアタッチされているEIPは念のため2つ共許可設定してもらいます。（xxx.xxx.xxx.xxx, yyy.yyy.yyy.yyy）
Q：なぜ既存のADと同じVPC内に構築しなかったのですか?
A：「ADを管理しているのが標準化チーム」「本仕組みを構築するPlatformチーム」とチームが分かれているため、管理のし易さを優先して、各チームが管理しているアカウントで作成する方針にしました。将来統合する可能性もあります。
Q：ADのユーザー全てが利用可能になってしまうのでしょうか?ユーザーを絞ることは可能でしょうか?
A：Client VPN の承認ルールを使用することで、ADのSIDまたはIDPのグループ名を使って認可設定が可能です。標準化チームのADでは、「許可セット」と「ADグループ」が基本的に１対１の構成になっているので、どのAWSアカウントのどの許可セット という単位でユーザーを絞ることができます。
Q：なぜ 1.1.1.1, 8.8.8.8 というDNSが構成図にあるのでしょうか?
A： ClientVPN接続後、名前解決ができなくなる人が複数人いたため、ClientVPN側でカスタムDNSサーバーとしてパブリックDNSサーバーを明示的に指定しました。
その他の選択肢（及びWhy not?: なぜ別の方法にしなかったのか？）
情シスにスマホにも導入可能なVPNの構築を依頼する
概要
既存の全社VPNだと社内LANに入れることになるので、会社端末ではないスマートフォンに導入できない。そもそも会社端末のスマートフォンですら、現状全社VPNを導入する仕組みは無い。 本目的では、社内LANに入る必要は無く、IP制限許可のためにIP固定化さえできればよいので、新たに社内LANに入れないVPNを作ってもらい、会社端末ではないスマートフォンに導入できる仕組みを作ってもらう。
Why not?
情シスに相談したが断られた。
当プロダクトサービスにはユーザー認証があるのでそもそもIP制限を外す
Why not?
ユーザー認証はあるが個人とは紐づいておらず、使いまわしている。そのためIP制限がないと開発者が退職後もアクセスできてしまう。 使いまわしているユーザーは多く、それらのパスワードを開発者が退職するたびに変更するのは運用負荷が高いから却下。
また認証基盤は他プロダクトも使用しているので、当プロダクトの一存でIP制限を外すことはできない。
懸念事項
費用
| 名前 | 料金/時間 | 日あたりの時間 | 月あたりの日数 | 個数 | 小計 | 備考 |
|---|---|---|---|---|---|---|
| AWS Client VPN エンドポイントアソシエーション | $0.15 | 24 | 30 | 1 | $108.00 | 費用削減のため1つのサブネットにしか関連付けしない |
| AWS Client VPN 接続 | $0.05 | 1 | 20 | 10 | $10.00 | 10個のクライアントが営業日に1時間VPN接続をすると仮定 |
| AD Connector | $0.08 | 24 | 30 | 1 | $57.60 | サイズ: スモール |
| 合計月額 | $175.60 |
NatGatewayは他の仕組みでも利用されるため本試算には入れていません。
