AWS ClientVPNの構成図 7パターン
AWSのClientVPNには認証方式が複数あります。
認証方式により、構成やUXが微妙に変わり、その質問をいただくことが多いため、
ユーザ視点でどんな感じになるのかを、7パターンで整理してみたいと思います。
これ以外にも構成パターンはあると思いますが、それらは応用編で、
もし機会があればブログ化してみたいと思います。
構成は、認証方式に依存する形となります。
紹介するパターンは下記です。
- ADオンプレで認証
- AD(AWS managed)で認証
- SAML(Okta)で認証
- ADオンプレ+証明書で認証
- AD(AWS managed)+証明書で認証
- SAML(Okta)+証明書で認証
- 証明書のみで認証
(1)ADオンプレで認証
概要
こんな方向けです。
- 既存のオンプレADを認証情報として利用したい
- 認証はADユーザ/PASSのみでOK
処理の流れ
- クライアントPCがClientVPNのEndpointに接続します
- ADコネクタを通して、ClientVPNとオンプレADでユーザ情報が連携されます
- ADのユーザ情報で認証が実施されます
- ClientVPNが接続可能となります。 クライアントPCはVPC内にあるENI-NATを通じてVPCやオンプレと通信が可能となります
- VPC内のEC2と疎通が可能となります（RouteTableとSGの設定を忘れずに）
- オンプレのサーバと疎通が可能となります（サーバ側の疎通許可設定を忘れずに）
利用イメージ
ユーザが接続する時は下記の操作イメージです。
AWSが提供するClientVPNのソフトを起動します。
ユーザ名、パスワードを入力します
認証に通ると接続されます。
運用考慮点
ADとclientVPNの接続許可設定を連動させることができます 。
（例：特定のOUの人が、xx.xx.xx.xx/xxへの疎通が可能）
その設定を変更する際は、ADとClientVPNの設定を変更する必要があります
(2)AD(AWS managed)で認証
概要
こんな方向けです。
- AWSのマネージドのADを認証情報として利用したい
- 認証はADユーザ/PASSのみでOK
処理の流れ
- クライアントPCがClientVPNのEndpointに接続します
- ADのユーザ情報で認証が実施されます
- ClientVPNが接続可能となります。クライアントPCはVPC内にあるENI-NATを通じてVPCやオンプレと通信が可能となります
- VPC内のEC2と疎通が可能となります（RouteTableとSGの設定を忘れずに）
- オンプレのサーバと疎通が可能となります（サーバ側の疎通許可設定を忘れずに）
運用考慮点
(1)のパターンと同様です。
利用イメージ
(1)のパターンと同様です。
(3)SAML(Okta)で認証
概要
こんな方向けです。
- ID管理サービスを認証情報として利用したい（ADと紐付け不要、ADの管理したくない場合）
- 認証はID管理サービスのログインでOK
処理の流れ
- クライアントPCがClientVPNのEndpointに接続します
- ID管理サービス（Okta）のユーザ情報で認証が実施されます
- ClientVPNが接続可能となります。クライアントPCはVPC内にあるENI-NATを通じてVPCやオンプレと通信が可能となります
- VPC内のEC2と疎通が可能となります（RouteTableとSGの設定を忘れずに）
- オンプレのサーバと疎通が可能となります（サーバ側の疎通許可設定を忘れずに）
利用イメージ
ユーザが接続する時は下記の操作イメージです。
AWSが提供するClientVPNのソフトを起動します。
Oktaでの認証を求められるためid/passでログインします。
Oktaの認証に通るとclientVPNに接続可能となります。
利用イメージ(ユーザ管理)
Oktaでのユーザ管理は下記イメージです。
私も初めてOktaを利用したのですが、特に迷うことなく直感的に操作できました。
ユーザ管理画面です。
ユーザ登録画面です。
(4)ADオンプレ+証明書で認証
概要
こんな方向けです。
- 既存のオンプレADを認証情報として利用したい
- 認証はADユーザ/PASSとクライアント証明書による2要素の認証をしたい
処理の流れ
- クライアントPCがClientVPNのEndpointに接続します
- クライアントの持つ証明書が正しいことを確認します
- ADコネクタを通して、ClientVPNとオンプレADでユーザ情報が連携されます
- ADのユーザ情報で認証が実施されます
- ClientVPNが接続可能となります。クライアントPCはVPC内にあるENI-NATを通じてVPCやオンプレと通信が可能となります
- VPC内のEC2と疎通が可能となります（RouteTableとSGの設定を忘れずに）
- オンプレのサーバと疎通が可能となります（サーバ側の疎通許可設定を忘れずに）
運用考慮点
(1)に加えて証明書、認証局の管理が必要となります。
クライアント証明書を紛失した場合や、追加の証明書を発行したい場合等、
一般的な認証局の運用が発生します。
また、クライアント証明書を利用者に配布する必要があり、
証明書周りの運用が割と手間です。
利用イメージ
(1)のパターンと同様です。
(5)AD(AWS managed)+証明書で認証
概要
こんな方向けです。
- AWSのマネージドのADを認証情報として利用したい
- 認証はADユーザ/PASSとクライアント証明書による2要素の認証をしたい
処理の流れ
- クライアントPCがClientVPNのEndpointに接続します
- ADのユーザ情報で認証が実施されます
- クライアントの持つ証明書が正しいことを確認します
- ClientVPNが接続可能となります。クライアントPCはVPC内にあるENI-NATを通じてVPCやオンプレと通信が可能となります
- VPC内のEC2と疎通が可能となります（RouteTableとSGの設定を忘れずに）
- オンプレのサーバと疎通が可能となります（サーバ側の疎通許可設定を忘れずに）
運用考慮点
(1)に加えて証明書、認証局の管理が必要となります。
クライアント証明書を紛失した場合や、追加の証明書を発行したい場合等、
一般的な認証局の運用が発生します。
また、クライアント証明書を利用者に配布する必要があり、
証明書周りの運用が割と手間です。
利用イメージ
(1)のパターンと同様です。
(6)SAML(Okta)+証明書で認証
概要
こんな方向けです。
- ID管理サービスを認証情報として利用したい（ADと紐付け不要）
- 認証はID管理サービスのユーザ/PASSとクライアント証明書による2要素の認証をしたい
処理の流れ
- クライアントPCがClientVPNのEndpointに接続します
- ID管理サービス（Okta）のユーザ情報で認証が実施されます
- クライアントの持つ証明書が正しいことを確認します
- ClientVPNが接続可能となります。クライアントPCはVPC内にあるENI-NATを通じてVPCやオンプレと通信が可能となります
- VPC内のEC2と疎通が可能となります（RouteTableとSGの設定を忘れずに）
- オンプレのサーバと疎通が可能となります（サーバ側の疎通許可設定を忘れずに）
運用考慮点
(3)に加えて証明書、認証局の管理が必要となります。
クライアント証明書を紛失した場合や、追加の証明書を発行したい場合等、
一般的な認証局の運用が発生します。
また、クライアント証明書を利用者に配布する必要があり、
証明書周りの運用が割と手間です。
利用イメージ
(3)のパターンと同様です。
(7)証明書のみで認証
概要
こんな方向けです。
- 認証はクライアント証明書のみでOK
処理の流れ
- クライアントPCがClientVPNのEndpointに接続します
- クライアントの持つ証明書が正しいことを確認します
- ClientVPNが接続可能となります。クライアントPCはVPC内にあるENI-NATを通じてVPCやオンプレと通信が可能となります
- VPC内のEC2と疎通が可能となります（RouteTableとSGの設定を忘れずに）
- オンプレのサーバと疎通が可能となります（サーバ側の疎通許可設定を忘れずに）
運用考慮点
証明書、認証局の管理が必要となります。
クライアント証明書を紛失した場合や、追加の証明書を発行したい場合等、
一般的な認証局の運用が発生します。
また、クライアント証明書を利用者に配布する必要があり、
証明書周りの運用が割と手間です。
利用イメージ
特にユーザ/パスワードを入力することなく接続が可能です
どのパターンが良いのか
まず最初に認証がユーザ/パスワードのみで良いかを考えると良いかと思います。
ユーザ/パスワードのみの認証で十分な場合には(1)(2)(3)が候補です。
(1)(2)(3)は既存でADを利用しているかどうかで決めると良いと思います。
Enterpriseでセキュリティが厳しい場合は、
ユーザ/パスワードと証明書による認証で(4)(5)(6)が候補です。
(4)(5)(6)は既存でADを利用しているかどうかで決めると良いと思います。
(7)は現実的に利用する方は少ないと思います。
上記をまとめるにあたり、初めてOktaを利用してみたのですが、
個人的にはOktaがかなり使いやすく、Oktaおすすめです。
小規模の会社で、試しにClientVPNを利用してみるぐらいでしたら
パターン(3)が良いのではと思います。
証明書は、セキュリティ強度は上がると思うのですが、
人件費等の作業コストがかかることを考えると
Oktaのようなサービス利用料の方が
トータルで安くなるのかと思います。
