AWS Verified Access を使ってのプライベートなアクセス

# ゼロトラスト

- AWS Verified Access はゼロトラストの基本原則に基づいて構築されています。
- ゼロトラストとは 社内外のネットワーク環境における、従来の「境界」の概念を捨て去り、守るべき情報資産にアクセスするものはすべて信用せずにその安全性を検証することで、情報資産への脅威を防ぐという、セキュリティの新しい考え方。

# AWS Verified Access　とは？

- VPN を使用することなく、アプリケーションへのセキュアなアクセスを提供するサービスです。
- アプリケーションを Verified Access に追加する前は、アプリケーションにはプライベートネットワーク経由でしかアクセスできませんでしたが、特定のユーザーが　VPN　を使用せずにインターネット経由で同じアプリケーションにアクセスできるようになります。

# 料金

- Verified Access に関連付けしたアプリケーションごとの時間単位の課金
- 処理されたデータに対して GB 単位での料金

https://aws.amazon.com/jp/verified-access/pricing/

# 仕組み

![スクリーンショット 2023-07-01 17.09.36.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/280929/1c8ec979-258a-79a4-ef02-09094220ab49.png)

①ユーザーがアプリケーションへのアクセス要求を送信します。
②Verified Access は、グループのアクセス・ポリシーおよびアプリケーション固有のエンドポイント・ポリシーに照らして要求を評価します。
③アクセスが許可されると、リクエストはエンドポイントを経由してアプリケーションに送信されます。

# やってみる

ざっくりこんな感じの構成にしてみました。
![AWS2.drawio.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/280929/e0ac41ce-f3f6-17b1-521e-1bb620a1b992.png)

なお、東京リージョンはまだなのでバージニア北部で実行しています。

## AWS IAM Identity Center でユーザーとグループの作成

https://docs.aws.amazon.com/ja_jp/singlesignon/latest/userguide/manage-your-identity-source-sso.html

Trust プロバイダー として、今回は、AWS IAM Identity Center を利用するため、AWS IAM Identity Center で次の通り、ユーザーとグループを作成しておきます。

|グループ|ユーザー|
|---|---|
|dev001|user001  user002|
|dev002|user001|

## ACM で証明書の準備

https://docs.aws.amazon.com/ja_jp/acm/latest/userguide/gs-acm-request-public.html

ACM で、証明書を作成しておきます。今回、
　dev001　グループは、dev001.example.com
　dev002　グループは、dev002.example.com
にアクセスしたいため、それぞれ証明書を作成しておきます。
![スクリーンショット 2023-07-04 18.06.41.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/280929/f884ca7c-c983-297e-125e-5776ce526ec2.png)

なお、ワイルドカードを使用したドメイン(*.example.com)では後程記述する Verified Access エンドポイントでエラーとなるため、FQDN での登録が必要です。

## アプリケーションの準備

それぞれのプライベートサブネットに、dev001 と dev002 の EC2インスタンス(Webサーバー)を準備しておきます。
今回は、
　dev001 グループは、ec2-dev001 に、
　dev002 グループは、ec2-dev002 に、
にアクセスできるように分けたいため、このようにします。

|サブネット|EC2インスタンス|
|---|---|
|Private-Subnet-dev001|ec2-dev001|
|Private-Subnet-dev002|ec2-dev002|

## Verified Access の作成

### Verified Access 信頼プロバイダー

https://docs.aws.amazon.com/ja_jp/verified-access/latest/ug/trust-providers.html

Verified Access 信頼プロバイダーのタイプとして以下をサポートします。

- ユーザー信頼プロバイダー
  -  IAM Identity Center
  -  OIDC (OpenID Connect)
- デバイス信頼プロバイダー
  -  Jamf
  -  Crowdstrike

ここでは、IAM Identity Center を使用します。

![スクリーンショット 2023-07-01 18.42.45.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/280929/c83809aa-3f8c-a719-5a94-c5c3abe35eeb.png)

### Verified Access インスタンス

https://docs.aws.amazon.com/ja_jp/verified-access/latest/ug/verified-access-instances.html

先程作成した Verified Access 信頼プロバイダーをアタッチし、Verified Access インスタンスを作成します。
![スクリーンショット 2023-07-01 18.46.40.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/280929/611476bf-c4c0-4255-d940-48c23fffa94a.png)

### Verified Access グループ
 
先程作成した Verified Access インスタンスに Verified Access グループをアタッチします。
ポリシーの詳細ですが、
policy-reference-name は、Verified Access 信頼プロバイダーで設定したポリシー参照名なので、ここでは dev、グループ ID は、AWS IAM Identity Center のグループのID（dev001 グループの ID）を入力します。
![スクリーンショット 2023-07-01 18.54.47.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/280929/a2289aa1-95fb-2e92-e1c9-c52202fbc14c.png)

ポリシーの記載例についてはドキュメントを参考に。

https://docs.aws.amazon.com/ja_jp/verified-access/latest/ug/auth-policies.html

### Verified Access エンドポイント

https://docs.aws.amazon.com/ja_jp/verified-access/latest/ug/verfied-access-endpoints.html

Verified Access エンドポイント を先程作成した Verified Access グループに紐づけます。
アプリケーションドメインは、作成した証明書と同じもの（dev001.example.com）になるはずです。
![スクリーンショット 2023-07-04 18.38.21.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/280929/ce344254-c36f-3da2-6901-79ff0eeaad33.png)

アタッチメントタイプは VPC (しかありませんが...)、Verified Access エンドポイントでは、ENI が作成されるのでそれに関連づけるセキュリティグループを指定します。

エンドポイントドメインプレフィックスは、Verified Access エンドポイント用に作成される DNS 名の先頭に付加される識別子ですので、何でも良いですが、ここでは dev001 としました。

エンドポイントタイプは、次の 2 種類から選択することが可能ですが、今回はロードバランサーは準備していないので、ネットワークインターフェースを指定しています。

- ネットワークインターフェース
- ロードバランサー

プロトコルは、次の通りですが、今回はWEBサーバーに SSL で構築していないので、HTTP にしています。

- HTTP
- HTTPS

![スクリーンショット 2023-07-04 18.48.36.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/280929/7b565c6e-3a0f-3359-f91b-4357daf36765.png)

ポリシーですが、Verified Access エンドポイントは、Verified Access グループのポリシーを継承します。よってここでは、何も設定していません。
![スクリーンショット 2023-07-04 18.57.49.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/280929/4c8afa28-00fb-b4e8-47e8-b30808b12982.png)

## CNAME レコードの登録

アプリケーションドメインを Verified Access エンドポイントドメインで名前解決できるように、Route53 で CNAME レコードに登録します。

Verified Access エンドポイントからの確認。
![スクリーンショット 2023-07-04 19.09.15.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/280929/24576cad-a574-281f-8bc7-d09f6630fa64.png)

Route53 での CNAME の登録。
![スクリーンショット 2023-07-04 19.07.26.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/280929/029f6ec6-9283-dbc7-53ef-76466c3d8ac7.png)

## セキュリティグループの変更

EC2インスタンスのセキュリティグループで、Verified Access エンドポイントからのポート 80 からのアクセスのみ許可するように設定します。
![スクリーンショット 2023-07-04 19.18.17.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/280929/820f73f4-bdc4-359f-3b5a-709993f981b6.png)

## dev002 

dev002 も dev001 と同様に以下のリソースを作成、変更していきます。

- Verified Access グループ
- Verified Access エンドポイント
- CNAME レコードの登録
- セキュリティグループの変更

## 動作確認

想定通り、user002 は　dev002　グループに所属していないため、アクセス拒否となりそれ以外はアクセスできるようになりました。

||dev001.example.com|dev002.example.com|
|---|---|---
|user001|![スクリーンショット 2023-07-04 20.08.37.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/280929/8322b037-f143-74e0-77af-7a4fce4cc86e.png)|![スクリーンショット 2023-07-04 20.08.51.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/280929/0dfa20f6-a359-faf2-3f61-c15280c2ef65.png)|
|user002|![スクリーンショット 2023-07-04 20.08.12.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/280929/445bc6c9-3441-4c68-0f9c-317dfc55857c.png)|![スクリーンショット 2023-07-04 20.07.59.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/280929/85d6af31-2a17-81c0-c1a0-ac45311d795a.png)|

# ログ

https://docs.aws.amazon.com/ja_jp/verified-access/latest/ug/access-logs.html

- Verified Access はすべてのアクセス試行をログに記録するため、セキュリティ・インシデントや監査要求に迅速に対応することができます。

- Verified Access は、以下の宛先にアクセスログの公開をサポートしています。
  - CloudWatch Logs
  - S3
  - Kinesis Data Firehose

- CloudTrail ですべての Verified Access API のイベントをキャプチャします。

# アップデート情報

HTTPS 以外もアクセス可能になりました。

https://aws.amazon.com/jp/blogs/news/aws-verified-access-now-supports-secure-access-to-resources-over-non-https-protocols/