いわさです。
AWS Verified Access は AWS 上にデプロイしたプライベート Web アプリケーションに信頼されたユーザー・信頼されたデバイスからのアクセスを与えることが出来るサービスです。
この Verified Access では信頼したプロバイダーのユーザー/デバイスに対して、さらに条件付きでのアクセス機能を提供することが出来ます。
その際に Cedar を使ってポリシーを定義します。
先日のアップデートで、このポリシー定義が楽になりそうな「ポリシーアシスタント」という機能がリリースされました。
アップデートアナウンスには色々と便利になりそうなことが書いてありますが、実際に何が出来るのかは画面を見たほうが早いだろう。ということで実際に Verified Access 経由でアクセス出来る Web アプリケーションをデプロイしてポリシーアシスタントを使ってみましたので、どんな使い勝手なのかなどを紹介したいと思います。
検証用 Verified Access 環境一式を作成
私は普段、次のテンプレートを検証用に使っておりまして、AWS IAM Identity Center が有効化されている AWS アカウントに対してデプロイすると、10 分くらいでプライベート Web アプリケーションと Verified Access 一式が自動でデプロイされます。
% rain deploy template.yaml hoge1122verified --profile hogeadmin
Deleted existing, empty stack.
Enter a value for parameter 'BaseAMI' (existing value: /aws/service/ami-amazon-linux-latest/amzn2-ami-hvm-x86_64-gp2):
Enter a value for parameter 'ApplicationDomain' (existing value: hoge.fuga.tak1wa.com):
Enter a value for parameter 'HostZoneId' (existing value: Z05132602TL6PL61SUQV2):
Creating change set .˙
CloudFormation will make the following changes:
Stack hoge1122verified:
+ AWS::EC2::VPCGatewayAttachment AttachGateway
+ AWS::CertificateManager::Certificate Certificate
+ AWS::Route53::RecordSet DnsWebRecord
+ AWS::EC2::EIP EipNatGateway1
+ AWS::EC2::VerifiedAccessEndpoint HogeEndpoint
+ AWS::EC2::VerifiedAccessGroup HogeGroup
+ AWS::EC2::VerifiedAccessInstance HogeInstance
+ AWS::EC2::SecurityGroup HogeSecurityGroup
+ AWS::EC2::VerifiedAccessTrustProvider HogeTrustProvider
+ AWS::EC2::InternetGateway InternetGateway
+ AWS::EC2::NetworkInterface MyNetworkInterface
+ AWS::EC2::NatGateway NatGateway1
+ AWS::EC2::Route ProtectedRoute1
+ AWS::EC2::RouteTable ProtectedRouteTable1
+ AWS::EC2::SubnetRouteTableAssociation ProtectedSubnet1RouteTableAssociation
+ AWS::EC2::Subnet ProtectedSubnet1
+ AWS::EC2::RouteTable PublicRouteTable
+ AWS::EC2::Route PublicRoute
+ AWS::EC2::SubnetRouteTableAssociation PublicSubnet1RouteTableAssociation
+ AWS::EC2::Subnet PublicSubnet1
+ AWS::EC2::VPC VPC
+ AWS::IAM::InstanceProfile WebProfile
+ AWS::IAM::Role WebRole
+ AWS::EC2::SecurityGroup WebServerSecurityGroup
+ AWS::EC2::Instance WebServer
Do you wish to continue? (Y/n)
Deploying template 'template.yaml' as stack 'hoge1122verified' in ap-northeast-1.
Stack hoge1122verified: CREATE_COMPLETE
Successfully deployed hoge1122verifiedテンプレートパラメータで設定したカスタムドメインにアクセスすると、IAM Identity Center の認証が要求され、認証するとそのまま Web アプリケーションにアクセスが出来ます。テンプレートってやつは便利だなぁ。
この時点のポリシーはテンプレートの中身を見て頂くとわかるのですが、permit(principal,action,resource) when { true };が設定されているので、信頼されたプロバイダーのユーザーであれば無条件にアクセスを許可している状態です。
ポリシーアシスタントを使う
では早速ポリシーアシスタントを使ってみましょう。
ポリシーアシスタントは、対象の Verified Access インスタンスの詳細画面から起動することが出来ます。
そして次の画面では Verified Access へアクセスするユーザーのメールアドレスと、対象のエンドポイントを選択します。
つまり、ポリシーアシスタントの大前提としてまずデプロイ済みの Verified Access 環境が必要になる点に注意してください。
この環境では Verified Access と IAM Identity Center を統合させているので、先程ログインに使った IAM Identity Center ユーザーのメールアドレスを取得し、入力してみます。
名前やデバイス識別子はここでは割愛します。
認証結果についてはデフォルトで選択されている「最新の認証結果」を選択します。
Verified Access アクセスログの有効化が必須
ここで次へ進むと次のようなエラーメッセージが表示されました。
Verifed Access インスタンスのアクセスログが有効になっていないとのこと。
Verified Access はオプションで、エンドポイントの認証に関するアクセスログを出力することが出来ます。
どうやらこのポリシーアシスタントはアクセスログを使うようです。
有効化しましょう。
S3 出力では NG
Verified Access アクセスログの出力先は S3、CloudWatch、Firehose の 3 つそれぞれに任意で出力が可能です。
コストを考えると S3 が良さそうか？と考えて S3 のみまずは有効化してみました。
この状態でポリシーアシスタントを起動してみましたが、アクセスログが有効になっていないと判定されました。ダメかー！
CloudWatch Logs 出力であれば OK
S3 に出力したログをそのまま Verified Access が読み取ってくれるのはちょっとむずかしいのではないかなと思ったので、S3 じゃダメなのはちょっと想像出来ました。
ここは CloudWatch Logs でいってみましょう。
おっ、エラーメッセージの内容が変わりましたね。
別のエラーが出力されていますが、アクセスログが有効化されていないという状況からは変わりました。
CloduWatch Logs を有効化するのは正しそうな気がします。
エラー内容からの推察ですが、おそらく前画面で次へを押したタイミングのタイムスタンプベースでログを検索しているような気がします。
一度ひとつ前の画面に戻って再度「次へ」ボタンを押してみましょう。
今度はもっとわかりやすいエラーメッセージに変わりました。
Verified Access のアクセスログは有効化後のアクティビティから出力されるので、単純に対象ユーザーのログが確認出来なかったのだと思われます。
対象ユーザーのアクセスログ出力後に使う
また、Verified Access のエンドポイント（カスタムドメイン）経由でアプリケーションにアクセスしてみましょう。
CloudWatch Logs には Verified Access のアクセスログが出力されていることを確認しました。
これでどうだ。
ポリシーアシスタントの操作を進めてみると、今度はポリシー編集画面が表示されました。
これが今回のアップデートされた機能の肝の部分になります。
この画面のとおり、要はポリシーアシスタントというのは、過去のアクセスログを検証用コンテキスト情報としてグループポリシーあるいはエンドポイントポリシーの変更をトライアンドエラーで作成することが出来る機能です。
左側にアクセスログから抽出された対象ユーザーのコンテキスト情報が、右側に現在設定されているポリシーが表示されています。
この画面上でポリシーに変更を加えて、次の下部にあるポリシーテスト機能を使って、ポリシーの評価結果を確認しながら修正を繰り返すことが出来ます。
グループポリシーを変更してみる
試しにグループポリシーを変更してみたいと思います。
変更前は IAM Identity Center のユーザーであれば無条件でアクセスを許可していました。
コンテキスト情報を見る感じだと、IAM Identity Center のユーザーが所属するグループ情報が含まれています。
特定のグループに所属している場合にのみアクセスを許可するようにポリシーを変更してみましょう。
変更後に画面下部の「ポリシーをテスト」ボタンを押すと、対象ユーザーのコンテキストがこのポリシーでどのように評価されるのかをシミュレーションしてくれます。
確認したポリシーが良さそうであれば次のステップに進みます。
最後のステップではポリシーの変更差分をもとに最終確認を行います。
この画面で「変更を適用」ボタンを押すと実際にポリシーが更新されます。
Verified Access を経由してプライベートアプリケーションを利用しているユーザーに影響が出る可能性がありますので確定は慎重に行いましょう。
Verified Access グループのグループポリシーを確認してみると実際に変更されていることも確認出来ました。
さいごに
本日は AWS Verified Access の新機能「ポリシーアシスタント」を使ってみました。
従来もコンテキスト情報をアクセスログに出力し、それをもとにポリシーを変更あるいは次のようなテストツールを使うことで、ポリシーの作成を行うことが出来ました。
今回のアップデートによってマネジメントコンソール上でアクセスログを使ってポリシーのテストを行うことが出来るようになりました。
前提としてアクセスログが必要になるので、ポリシーを固める前にシステムにアクセスさせる必要があります。
そのため、このツールの位置づけとしては新規で Verified Access を構築後にテストしながらポリシーを作成したり、あるいは既存の運用環境で既に Verified Access を使っている状態で、ポリシー変更の妥当性を確認したりする際に使えそうです。
5
