AWS Verified Accessで実現するゼロトラスト

## 導入
- 2023年10月9日から、AWS Verified Accessが東京リージョンで利用可能となりました！ 
    - [AWS Verified Access が 2 つの追加の AWS リージョンで利用可能になりました](https://aws.amazon.com/jp/about-aws/whats-new/2023/10/aws-verified-access-two-regions/)
- AWS Verfied Accessを利用すると、ゼロトラストの基本原則に基づき、プライベートアプリケーションへのVPNレスでのアクセスを実装することができます。
- 本記事では、`ゼロトラストの基本原則`を簡単に説明した上で、[公式チュートリアル](https://docs.aws.amazon.com/verified-access/latest/ug/getting-started.html#getting-started-step1)を参考に、AWS Verified Accessを実際に構築してみます。

## ゼロトラストの基本原則について
- [AWS でのゼロトラスト](https://aws.amazon.com/jp/security/zero-trust/)では、AWSでゼロトラストを構築するための基本原則について、以下3点をあげています。
1. 可能な場合は、ID 機能とネットワーク機能を併用します。**→Verified Accessであれば、`IAM Identity Center`や`OpenID Connect`との統合により、IDとネットワークの併用によるアクセス制御ができそうです。**
2. 特定のユースケースから逆算して作業する**→Verified Accessは主に、組織内部アプリケーションへのアクセス制御用途で採用されると思いますが、[ポリシーの例](https://docs.aws.amazon.com/verified-access/latest/ug/trust-data-iam-add-pol.html)等を参考にした、組織のニーズ・ユースケースを踏まえたアクセスポリシー設計が肝になりそうです**
3. システムとデータの価値に応じてゼロトラストを適用します**→ゼロトラストに限らず、セキュリティ対策の目的は`リスクを許容可能な程度にコントロールする`ことであり、費用対効果を無視した過剰なセキュリティ対策は避ける必要があります。**


## AWS Verified Accessの構築

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3562653/4a9af953-e953-5874-24a4-30facd29ebb0.png)


### IAM Identity Centerの有効化
- [ステップ 1: IAM ID センターを有効にする](https://docs.aws.amazon.com/singlesignon/latest/userguide/get-started-enable-identity-center.html)を参考に、`IAM Identity Center`を`東京リージョン`で有効化します。

### 内部アプリケーションの構築

- プライベートサブネット上にLambda関数を作成します。
```python
def lambda_handler(event, context):
    return {
        'statusCode': 200,
        'headers': {'Content-Type': 'text/html'},
        'body': '<p>Access Allowed!!!</p>'
    }
```

- 内部用ALB向けにオレオレ証明書を作成し、ACMにインポートします。
```bash
# 秘密鍵の作成
openssl genrsa 2048 > server.key

# CSRの作成
openssl req -new -key server.key > server.csr
# CSRの確認
openssl req -in server.csr -text

# オレオレ証明証の作成
openssl x509 -days 3650 -req -sha256 -signkey server.key < server.csr > server.crt
```

- ALBのターゲットグループを作成し、先程作成したLambda関数をターゲットとして指定します。
![スクリーンショット 2023-10-10 22.52.44.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3562653/b741a9b1-871e-29a8-9098-04dabfe18867.png)

- プライベートサブネット上に内部用ALBを作成し、先程作成したターゲットグループを紐づけます。

- 内部用ALB向けに、Route53のプライベートホストゾーンにレコードを作成します。
    - レコードタイプ： A
    - エイリアス： 有効化
    - トラフィックのルーティング： 先程作成したALBを指定


### Verified Accessインスタンスと信頼プロバイダーを作成する
- VPCコンソールにアクセスし、ナビゲーションペインから`Verified Access インスタンス`を選択します。
- `Verified Accessインスタンスを作成`を押下し、インスタンスを作成します。
![スクリーンショット 2023-10-10 22.57.37.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3562653/de2eade7-9c7f-93b7-57a6-6018c51e0e9e.png)

- インスタンス作成画面で`Verified Access 信頼プロバイダーを作成`を押下して、別タブで信頼プロバイダーを作成します。
![スクリーンショット 2023-10-10 23.06.09.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3562653/7a77b93e-17ef-9526-b295-4fd400494352.png)

- 元のタブに戻り、先ほど作成した信頼プロバイダーをアタッチして、インスタンスを作成します。![スクリーンショット 2023-10-10 23.07.05.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3562653/24580867-6ba1-7c2c-950b-1bb43f6500a6.png)

### Verified Accessグループを作成する
- ナビゲーションペインから`Verified Access グループ`を選択し、`Verified Access グループを作成`を押下します。
- 先程作成したインスタンスをアタッチします。
- ポリシーには無条件のアクセス許可を設定します。
```
permit(principal,action,resource) when {true};
```
![スクリーンショット 2023-10-10 23.12.49.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3562653/c98b2c27-c85f-5f1a-f312-5c2162140958.png)

### Verified Accessエンドポイントを作成する
- 事前準備として、
    - Verified Accessエンドポイント用SGを作成します。
        - 自身のグローバルIPアドレスからのインバウンドHTTPS通信のみを許可するように設定しました。
    - Verified Accessエンドポイント用パブリック証明書をACMで作成します。(自身が持つパブリックなカスタムドメインに対して、エンドポイント用サブドメインを切る必要があります）

- ナビゲーションペインから`Verified Access エンドポイント`を選択し、`Verified Access エンドポイントを作成`を押下します。
    - アプリケーションドメイン： 自身が持つカスタムドメインに対して、サブドメイン`hoge`を切りました。
    - ドメイン証明書のARN： 先程作成したACMのパブリック証明書を指定しました。
![スクリーンショット 2023-10-10 23.51.31.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3562653/00ea2c8a-fac5-e74b-297d-1446005061f5.png)
![スクリーンショット 2023-10-10 23.54.19.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3562653/691ae08f-6bf9-f434-9680-e3d99bde2e74.png)

- エンドポイントドメインをカスタムドメインのホストゾーンにCNAMEとして登録します。
![スクリーンショット 2023-10-11 0.35.25.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3562653/519a2a02-8846-9c56-63c5-99eb960f0366.png)


### 動作確認
- Verified Access エンドポイントのアプリケーションドメインに対して、Webブラウザからアクセスします。
![スクリーンショット 2023-10-11 0.42.29.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3562653/ae02383a-0e20-36eb-08f8-ea3482e46960.png)
- サインインすると、無事Lambda関数が実行されました！
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3562653/c3fd8b42-21d1-0deb-c161-a3e9317e5e5d.png)

## 最後に
- 今回の記事では、AWS Verified Accessを実際に構築してみました。
- 次回以降の記事では、(ゼロトラストつながりで)`NIST SP800-207 ゼロトラスト・アーキテクチャ`の解説や、アクセスポリシーの設計についてDeepDiveできればと思います。

## 注意事項
- 本記事は万全を期して作成していますが、お気づきの点がありましたら、ご連絡よろしくお願いします。
- なお、本記事の内容を利用した結果及び影響について、筆者は一切の責任を負いませんので、予めご了承ください。