AWS Client VPN の認証：IAM の権限はログイン方法ではない

ユーザーに AWS Client VPN エンドポイントの作成や記述を許可しても、そのユーザーがエンドポイントに接続できるようになるわけではありません。これは二種類の異なる ID です。IAM は AWS API の呼び出しを管理し、エンドポイントはそこに設定されたクライアント認証方式だけを受け付けます。したがって、コンソールで広い権限を持っていても、VPN クライアントが提示できるものを何も持たないことがあります。エンドポイントがどの方式を信頼するかを決め、次に与えようとしているアクセスにフルトンネルが適切な形かを決めてください。

API の ID はトンネルの ID ではない

「IAM ロールはアタッチ済みなのに、なぜ VPN は失敗するのか」と尋ねられたとき、答えはたいてい、接続の流れのどの段階もそのロールを読まないというものです。クライアントは証明書、AD のユーザー名とパスワード、または SAML アサーションを提示します。エンドポイントはそのいずれかを検証し、その後アドレスを割り当てます。

IAM は依然として重要ですが、より後の別の場所で重要です。エンドポイントの作成、サブネットの関連付け、ルートの公開、認可ルールの記述は API の操作です。こうした権限は必要とする運用者に限定し、すべてのユーザーにエンドポイントのアクセスルールを書き換える能力を与えないでください。

エンドポイントがサポートする方式から選ぶ

AWS Client VPN は、証明書ベースの相互認証、Active Directory 認証、SAML ベースのフェデレーション認証を受け付けます。どのクライアント方式を選んでもサーバー証明書は必要であり、複数の方式を組み合わせた設定では両方の成功が必要で、片方だけでは足りません。

証明書は導入が最も安価で、大規模になると最も間違えやすい方法です。すべてのユーザーに資格情報が必要で、退職のたびに失効が必要になるからです。ディレクトリ認証はそのライフサイクルを既存のシステムへ移します。フェデレーションはそれを ID プロバイダーへ移し、クライアントにブラウザーの手順を追加します。

クライアントをデバッグする前に、エンドポイント自体の設定を読んでください。ユーザーベースの方式と併用して相互認証が有効になっている場合、有効な証明書を持っていてもディレクトリアカウントがないクライアントは失敗し、そのエラーはたいてい一般的なハンドシェイクの問題のように見えます。

フェデレーションはアクセスキーの受け渡しではない

SAML の設定は、IAM のアクセスキーや引き受けたロールのトークンをトンネルに流し込むものではありません。ID プロバイダーが本人を認証してアサーションを返し、エンドポイントが設定した信頼の下でそれを受け入れます。その結果できるセッションは VPN セッションであり、AWS API のセッションではありません。

この違いが、誰が何を切り分けられるかを決めます。IdP の問題はトンネルが存在する前のブラウザーやクライアントのエラーとして現れ、トンネルの問題はアサーションの成功後に現れます。どちらのコンソールを開く前に、自分が見ているのはどちらかを確認してください。

ログインの後も、ルートと認可が決める

認証はセッションにアドレスを与えますが、セッションに宛先を与えるわけではありません。エンドポイントのルートは、どのサブネットへ送るかをクライアントに伝え、認可ルールは、どのユーザーがそれらのサブネットのどれに到達できるかを決め、セキュリティグループと宛先自身の権限が残りを決めます。

だからこそ、認証に成功したユーザーでもデータベースに到達できないことがあります。サブネットのルートテーブルの関連付け、ユーザーのグループの認可ルール、宛先のセキュリティグループをこの順に確認してください。それぞれが異なる種類のタイムアウトを生むからです。

単一のプライベートデータベースなら、ポート転送と比べる

本当の作業が単一のプライベートデータベースへの承認された接続一つなら、フルネットワークトンネルは要件ではなく選択です。AWS Systems Manager Session Manager は IAM を通じて管理ノードへのポート転送セッションを開くことができ、そのノードがプライベートネットワーク上のデータベースに到達します。ユーザーが VPC のアドレスを受け取ることはありません。管理ノードがデータベースのポートに到達できる唯一のホストになり、これはたいていセキュリティレビューが求めていたものです。その場合、ユーザーに必要なのは VPN プロファイルではなく、ローカルのクライアントとセッションのコマンドです。

トレードオフは範囲と前提条件の対比です。ポート転送には、管理ノード上の SSM エージェント、そのノードからデータベースへのネットワーク到達性、ユーザーのマシン上の Session Manager プラグイン、そしてその特定のセッションを開始する権限が必要です。すべてのサブネットへの経路ではなく、トンネルのようになんでもないプロトコルを運ぶわけでもありません。

いずれの場合も、データベース自身の ID はそのままにしてください。経路が IAM で認可されたからといって TLS の検証やデータベースの認証が消えるわけではなく、承認されたセッションはユーザーがどのテーブルを読めるかについて何も語りません。

範囲とライフサイクルで選んでください。多くのユーザーが多くの宛先を必要とし、証明書やディレクトリのライフサイクルを運用できるならトンネル、少数の人が一つのサービスを必要とし、ネットワークアドレスを配りたくないなら転送セッションです。いずれの場合も、認証方式、認可ルール、データベースのログインを三つの別々の事実として記録してください。それぞれ別に失敗するからです。