ゼロトラスト
- AWS Verified Access はゼロトラストの基本原則に基づいて構築されています。
- ゼロトラストとは 社内外のネットワーク環境における、従来の「境界」の概念を捨て去り、守るべき情報資産にアクセスするものはすべて信用せずにその安全性を検証することで、情報資産への脅威を防ぐという、セキュリティの新しい考え方。
AWS Verified Access とは？
- VPN を使用することなく、アプリケーションへのセキュアなアクセスを提供するサービスです。
- アプリケーションを Verified Access に追加する前は、アプリケーションにはプライベートネットワーク経由でしかアクセスできませんでしたが、特定のユーザーが VPN を使用せずにインターネット経由で同じアプリケーションにアクセスできるようになります。
料金
- Verified Access に関連付けしたアプリケーションごとの時間単位の課金
- 処理されたデータに対して GB 単位での料金
仕組み
①ユーザーがアプリケーションへのアクセス要求を送信します。
②Verified Access は、グループのアクセス・ポリシーおよびアプリケーション固有のエンドポイント・ポリシーに照らして要求を評価します。
③アクセスが許可されると、リクエストはエンドポイントを経由してアプリケーションに送信されます。
やってみる
ざっくりこんな感じの構成にしてみました。
なお、東京リージョンはまだなのでバージニア北部で実行しています。
AWS IAM Identity Center でユーザーとグループの作成
Trust プロバイダー として、今回は、AWS IAM Identity Center を利用するため、AWS IAM Identity Center で次の通り、ユーザーとグループを作成しておきます。
| グループ | ユーザー |
|---|---|
| dev001 | user001 user002 |
| dev002 | user001 |
ACM で証明書の準備
ACM で、証明書を作成しておきます。今回、
dev001 グループは、dev001.example.com
dev002 グループは、dev002.example.com
にアクセスしたいため、それぞれ証明書を作成しておきます。
なお、ワイルドカードを使用したドメイン(*.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 信頼プロバイダー
Verified Access 信頼プロバイダーのタイプとして以下をサポートします。
- ユーザー信頼プロバイダー
- IAM Identity Center
- OIDC (OpenID Connect)
- デバイス信頼プロバイダー
- Jamf
- Crowdstrike
ここでは、IAM Identity Center を使用します。
Verified Access インスタンス
先程作成した Verified Access 信頼プロバイダーをアタッチし、Verified Access インスタンスを作成します。
Verified Access グループ
先程作成した Verified Access インスタンスに Verified Access グループをアタッチします。
ポリシーの詳細ですが、
policy-reference-name は、Verified Access 信頼プロバイダーで設定したポリシー参照名なので、ここでは dev、グループ ID は、AWS IAM Identity Center のグループのID（dev001 グループの ID）を入力します。
ポリシーの記載例についてはドキュメントを参考に。
Verified Access エンドポイント
Verified Access エンドポイント を先程作成した Verified Access グループに紐づけます。
アプリケーションドメインは、作成した証明書と同じもの（dev001.example.com）になるはずです。
アタッチメントタイプは VPC (しかありませんが...)、Verified Access エンドポイントでは、ENI が作成されるのでそれに関連づけるセキュリティグループを指定します。
エンドポイントドメインプレフィックスは、Verified Access エンドポイント用に作成される DNS 名の先頭に付加される識別子ですので、何でも良いですが、ここでは dev001 としました。
エンドポイントタイプは、次の 2 種類から選択することが可能ですが、今回はロードバランサーは準備していないので、ネットワークインターフェースを指定しています。
- ネットワークインターフェース
- ロードバランサー
プロトコルは、次の通りですが、今回はWEBサーバーに SSL で構築していないので、HTTP にしています。
- HTTP
- HTTPS
ポリシーですが、Verified Access エンドポイントは、Verified Access グループのポリシーを継承します。よってここでは、何も設定していません。
CNAME レコードの登録
アプリケーションドメインを Verified Access エンドポイントドメインで名前解決できるように、Route53 で CNAME レコードに登録します。
Verified Access エンドポイントからの確認。
Route53 での CNAME の登録。
セキュリティグループの変更
EC2インスタンスのセキュリティグループで、Verified Access エンドポイントからのポート 80 からのアクセスのみ許可するように設定します。
dev002
dev002 も dev001 と同様に以下のリソースを作成、変更していきます。
- Verified Access グループ
- Verified Access エンドポイント
- CNAME レコードの登録
- セキュリティグループの変更
動作確認
想定通り、user002 は dev002 グループに所属していないため、アクセス拒否となりそれ以外はアクセスできるようになりました。
| dev001.example.com | dev002.example.com | |
|---|---|---|
| user001 |  |
 |
| user002 |  |
 |
ログ
-
Verified Access はすべてのアクセス試行をログに記録するため、セキュリティ・インシデントや監査要求に迅速に対応することができます。
-
Verified Access は、以下の宛先にアクセスログの公開をサポートしています。
- CloudWatch Logs
- S3
- Kinesis Data Firehose
-
CloudTrail ですべての Verified Access API のイベントをキャプチャします。
アップデート情報
HTTPS 以外もアクセス可能になりました。