TCPプロトコルに対するAWS Verified Access接続サポート機能のご紹介

2025年2月8日のJaws-UG横浜#83 AWS re:Invent 2024 re:Cap SecurityのLT登壇で使用した資料です。

Transcript

3. ⚫ ⚫ ⚫ • • ⚫ ⚫ ⚫ ⚫ • ⚫ ⚫
4. ⚫ ⚫ ⚫ ⚫ ⚫ ⚫ ⚫ ⚫ ⚫ ⚫ ⚫ Trusted Providers Verified Access Instance Verified Access Group Access Policy Verified Access Endpoint AWS Verified Access VPC Private subnet Instances Amazon RDS instance
5. ⚫ ⚫ ⚫ ➢ ➢ ⚫ ➢ ⚫ • •
6. ⚫ 1 Network CIDR ( ) EC2 SSH Verified Access EC2 SSH 2 Network CIDR ( ) EC2 SSH Verified Access EC2 SSH 3 Amazon RDS RDS RDS DB Verified Access RDS DB
7. ⚫ ⚫ Windows11 PC AWS IAM Identity Center AWS Verified Access VPC Private subnet Public subnet Amazon Route 53 (サブドメイン登録) Cloudflare (親ドメイン登録) EC2 Instance Windows11 PC AWS IAM Identity Center AWS Verified Access VPC Public subnet Private subnet PostgreSQL Instance IAM Identity Center Cloudflare Route 53 ※ VPC EC2 IAM Identity Center VPC RDS (PostgreSQL) Public Hosted zone
8. ⚫ ⚫ ⚫ ⚫ ⚫ ⚫ ⚫ ⚫ ⚫ ⚫ ⚫ ⚫ ⚫
9. ⚫ ⚫ ⚫ ➢
10. ⚫ ⚫ ⚫ ⚫ ⚫ ⚫
11. ⚫ ⚫ ⚫ ➢ ➢ ➢ ➢ ➢ ⚫ ➢ ➢ ➢ ➢ ➢ ➢ ➢ ➢ ⚫ ➢
12. ⚫ ⚫ ⚫ ➢ ➢ ⚫ ➢ ⚫ IAM Identitiy Center
13. ⚫ ⚫ Network CIDR Endpoint ( ) Amazon RDS Endpoint C:¥Users¥k-miy¥.ssh>ssh -i MyEC2Key.pem ubuntu@10-0-2-44.vae- 0b3273cacae75d57f.aws.kmiya.work The authenticity of host '10-0-2-44.vae-0b3273cacae75d57f.aws.kmiya.work (2406:da14:fa3:2b01::a00:22c)' can't be established. ED25519 key fingerprint is SHA256:S+r+jgjS6MS7nU6J3ulUtsKADlVdg/avTNvqVb3b8P4. This key is not known by any other names. Are you sure you want to continue connecting (yes/no/[fingerprint])? yes Warning: Permanently added '10-0-2-44.vae- 0b3273cacae75d57f.aws.kmiya.work' (ED25519) to the list of known hosts. Welcome to Ubuntu 24.04.1 LTS (GNU/Linux 6.8.0-1018-aws x86_64) : : To run a command as administrator (user "root"), use "sudo <command>". See "man sudo_root" for details. ubuntu@ip-10-0-2-44:~$ C:¥Users¥k-miy>psql --host=vae-0274e92e7a441a552.vai- 05b2396c145de0d2b.prod.verified-access.ap-northeast-1.amazonaws.com -- port=5432 --username=postgres --password --dbname=db01 Password: psql (16.6) SSL connection (protocol: TLSv1.3, cipher: TLS_AES_256_GCM_SHA384, compression: off) Type "help" for help. db01=>
14. ⚫ 項目 原因 対応 1 Connectivity Clientの初期画面で「サイ ンイン」ボタンを押しても、ブラウザの ログオン画面が起動しない。 Windows PCの場合は、AWSドキュメントの記 載のとおり、C:¥ProgramData¥Connectivity Clientフォルダの中にクライアント構成ファイ ルを配置する必要があったが、Connectivity Client実行プログラムが配置されている別フォ ルダに格納していたため。(ユーザー側で構成 ファイルを配置するフォルダは自由に決めれな いらしい。) PCにも依存するが、検証にしようしたPC では、該当のフォルダはエクスプローラー 上、「隠しファイル/隠しフォルダ」扱い となっていた。故にデフォルトの設定だと フォルダが表示されない。そのため、「隠 しファイル/隠しフォルダ」も表示するよ うにPCの設定を変更し、クライアント構成 ファイルを該当フォルダにコピー。 2 Connectivity Clientのサインインが終わ り、Client画面上、接続完了と表示され ているにもかかわらず、SSHやpsqlコマ ンド発行時にVerified Accessが提供する エンドポイントのドメインが見つからな いと言われ、コマンド発行エラーになる クライアント側のWindows11 PCにおいて、 IPV6がIPV4よりも優先度が高くなっていたため。 VPC側のリソースに対するIPはIPV4で設定して いるので、IPV6で検索されると、見つかるもの も見つからなくなる。 下記のQiita記事を参考に、Windows11 PC の設定を、IPV4の優先度をIPV6より高くす ることで解消。 https://qiita.com/MeetMacaron/items/c dd8c80afcd02c0e9531 3 上記の項番2の事象解決後、再度 Connectivity Clientのサインインを実施。 Client画面上、接続完了と表示されてい るにも関わらず、リソースへのアクセス 時にConnection Timeoutとなる。 Verified Accessログ(今回はS3に格納するよう に設定)を参照したところ、アクセス拒否(ス テータスコード403)が返っていた。当初、 Verified Accessのアクセスポリシーは「ユー ザーのE-mailアドレスに「+test@gmail.com」 の文字が含まれている場合に許可する」といっ た設定をしていたが、サインインする際のユー ザー名にE-mailアドレスを含まないユーザー(E- mailアドレスはIAM Identity Centerで紐づけて はいたが)でログオンしようとして拒否されてい たことが判明。 IAM Identity Centerでグループを定義し、 登録しておいたユーザーを該当グループ内 に移動。Verified Accessのアクセスポリ シーを「該当のグループに属するユーザー のみ許可する」という設定に変更すること で解決。 ※現状はVerified Accessログの中身を見る までは、実際にアクセス許可されているか 否かはわからない。また、アクセスログは Connectivity Clientでサインアウトしない と作成されない模様。
15. ⚫ ⚫ ⚫ ➢ ➢ ◆ ◆ ➢ ⚫ ➢ ➢ ⚫ ➢ ➢