AWSのデータ分析に関するベストプラクティスをまとめてみた
kurochan
デロイト トーマツ ウェブサービス株式会社（DWS）公式ブログ
AWS Verified AccessとJamfでデバイス認証してみた
yoshi
1. はじめに
寒い日が続きますね。最近、最寄りのスパにロウリュサウナが設置されたので、毎週、整い（トトノイ）にいっているyoshiです。
今回は、AWS Verified AccessとJamfでデバイス認証を検証してみたので、検証する上でポイントになったところを書きたいと思います。
Verified AccessとClient VPNの違いや、Verified Accessのセットアップ方法などについては、ネット上に既にたくさん情報があるので、今回は割愛させていただきます。
2. Verified Accessの構成
今回、Verified AccessのJamfによるデバイス認証を検証をするための環境として、以下を前提としています。
- プライベートサブネット内に、EC2を構築し、Nginxを立ち上げ、社内業務アプリケーションとみなします。前段に内部ALBを配置し、Verified Accessエンドポイント作成時にALBを指定します。
- 外部IdPにOktaを使用し、OIDCでユーザー認証を行うようにします。
- アプリケーションのエンドポイントとなるドメインは会社のテスト用ドメインを使用し、自己署名証明書をACMにインポートし、Verified Accessエンドポイント作成時にドメインと証明書を指定します。
実際の構築手順は、以下のブログ記事が参考になります。
AWS Verified Access Integration with 3rd party identity providers
https://aws.amazon.com/jp/blogs/networking-and-content-delivery/aws-verified-access-integration-with-3rd-party-identity-providers/
外部のIdPとしてOktaを使用し、アプリケーション単位でアクセスポリシーを作成し、ユーザーの認証、認可を実現しています。
OktaのEngineeringグループのメンバーだけが、Engineeringグループ用のアプリケーションのエンドポイントにアクセスでき、Oktaのユーザー属性に基づいた「きめ細かいアクセス制御」が実現できています。
構成図
実際にアプリケーションにアクセスしてみます。Oktaのログインに成功すると、Nginxの画面が表示されます。
今回は、外部IdPとしてOktaを使用しましたが、IAM Identity Centerを使用したい場合はこちらの記事を参照ください。
AWS Verified Access Preview — VPN-less Secure Network Access to Corporate Applications
https://aws.amazon.com/jp/blogs/aws/aws-verified-access-preview-vpn-less-secure-network-access-to-corporate-applications/
3. デバイス認証の設定
前提となる環境が準備できたら「デバイス信頼プロバイダ」を作成していきます。
「デバイス信頼プロバイダ」では、CrowdStrike、Jamf、JumpCloudが使用できますが、私の手元の端末には既にJamfがインストールされており、検証できる環境があったので、今回は、Jamfを使用しました。
以下の手順に従い、Jamf側の設定と、Verified Access側の「デバイス信頼プロバイダ」の設定をしていきます。
Integrating AWS Verified Access with Jamf Device Identity
https://learn.jamf.com/en-US/bundle/technical-paper-aws-verified-access/page/Overview.html
に書かれている手順に従って、Jamf側で、Device Identityの設定、Jamf Trust App、Chrome拡張の端末へのインストールを行います。
Device-based trust providers for Verified Access
https://docs.aws.amazon.com/verified-access/latest/ug/device-trust.html
に書かれている手順に従って、Jamfを指定した「デバイス信頼プロバイダ」を作成し、Verified Accessインスタンスに関連付けをします。
また、公式のドキュメントだと分かりづらい部分もあり、以下のブログも大変参考になりました。
Integrating AWS Verified Access with Jamf as a device trust provider
https://aws.amazon.com/jp/blogs/security/integrating-aws-verified-access-with-jamf-as-a-device-trust-provider/
構成図
具体的な構築手順については触れませんが、構築していく中でいくつかハマったポイントがありましたので、一つ一つ見ていきたいと思います。
4. ハマったところ
4.1 Device Identityが有効になっていなかった
手元の端末は既にJamfの構成プロファイルの配布がされており、Jamf Trust Appもインストール済みでした。
ドキュメントの指示に従い、Chrome拡張をインストールしましたが、端末の情報をうまくVerified Accessに送信できていないようでした。
これは、「Device Identity」の設定が無効化されていたことが原因でした。
アクティベーションプロファイルの作成時に、「Device Identity」を有効化しておく必要がありました。
アクティベーションプロファイルを作成し直し、端末にインストールし直すことで、「Device Identity」が有効になりました。
注意することは、アクティベーションプロファイル作成時に、Authenticationで、「Without identity provider」「Assign random identifier」を選択することです。
これをすることで、各デバイスにランダムな識別子が割り当てられ、IdPの認証なしでも、デバイスごとの識別と管理が可能となり、ユーザーの匿名性を保ちながらセキュアなアクセス制御を実現できるようになります。
Jamf Trust Appを開いて、「Device Identity is running」となっていればOKです。
4.2 OktaのSign-in redirect URIsの更新が必要だった
Verified Accessインスタンスに「ユーザー信頼プロバイダ」だけアタッチしている場合は問題なくアプリケーションにアクセスできるのですが、「デバイス信頼プロバイダ」もアタッチすると、以下のような「400 Bad Request」のエラーが出るようになりました。
「400 Bad Request」を調べてみると、
このエラーが返されるのは、認証リクエストで使用した${redirect_uri}の値が、許可されたサインインリダイレクトURIとして、OktaのOpen IDクライアントに登録されていないためです。
Oktaのシステムログをみると、RedirectUriがOktaに登録済みの「Sign-in redirect URIs」とは異なっていました。
Verified Accessエンドポイントの「デバイス検証ドメイン」の値をOkta側の「Sign-in redirect URIs」に追加する必要があったようです。
「デバイス信頼プロバイダ」を追加したことで、ユーザー認証後にアプリへ直接リダイレクトされるのではなく、まずデバイス検証のために「デバイス検証ドメイン」へリダイレクトされるようになり、Verified AccessがOktaに認証リクエストを送る際のredirect_uriも、「デバイス検証ドメイン」の値がセットされていた
と考えられます。
追加後、改めてエンドポイントにアクセスしてみると、今度はアクセスすることができました。
参考
Integrating AWS Verified Access with device trust providers
https://aws.amazon.com/jp/blogs/networking-and-content-delivery/integrating-aws-verified-access-with-device-trust-providers/
4.3 ログが有効に活用できてなかった
Verified Accessのログは、Verified Accessインスタンスの「Verified Accessインスタンスのログ記録設定」で設定でき、CloudWatch Logsに出力していましたが、ログを見ても詳細な情報が出力されておらず、エラーの原因を調べるには不十分でした。
アクセスログ設定の「信頼コンテキストを含める」がデフォルトでは未チェックなので、開発時、デバック時などはチェックをいれることで、信頼プロバイダからのクレーム（ユーザーやデバイスなどの属性情報）がログに含まれるようになり、トラブルシューティングがしやすくなります。
OktaやJamfから収集した属性情報もログに表示されるようになりました。
参考
How to use AWS Verified Access logs to write and troubleshoot access policies
https://aws.amazon.com/jp/blogs/security/how-to-use-aws-verified-access-logs-to-write-and-troubleshoot-access-policies/
4.4 ポリシー参照名を理解していなかった
アクセスポリシーは、Verified AccessグループまたはVerified Accessエンドポイントで作成でき、「Cedar」というポリシー言語で記述します。
最初は書き方がわからず、他の記事で紹介されているポリシーをそのまま使おうとして、自分が設定したのとは異なる間違った「ポリシー参照名」を使用していました。
OktaやJamfなどの「信頼プロバイダ」から取得したデータを検証するには「ポリシー参照名」を使用します。
今回は「ユーザー信頼プロバイダ」の「ポリシー参照名」を「okta」、「デバイス信頼プロバイダ」の「ポリシー参照名」を「jamf」に設定したので、ポリシーのルール内で「context.okta」、「context.jamf」という形で参照します。
このポリシーでは、Oktaの特定のグループに所属しているか、ユーザーのメールアドレスが会社のドメインであるか、デバイスがJamfで管理され、リスク評価が「LOW」または「SECURE」であるかを評価し、全ての条件が成り立った場合のみアクセスを許可しています。
アプリケーション単位での、ユーザー属性やデバイス属性に基づく「きめ細かいアクセス制御」が実現できています。
参考
A walk through AWS Verified Access policies
https://aws.amazon.com/jp/blogs/security/a-walk-through-aws-verified-access-policies/
5. まとめ
今回は、AWS Verified AccessとJamfでデバイス認証を実際に検証してみて、最初思っていたより、つまずいたところ、ハマったところがありました。
Verified Accessを使用したゼロトラストな環境の構築などの情報は数多くありましたが、デバイス認証に関する情報は少ないと感じましたので、今回検証した内容をブログとして書かせていただきました。
ドキュメントが見つけられなかった部分は実際に手を動かしながら確認していくしかありませんでしたが、基本的なことではありますが、Oktaのシステムログや、Verified Accessのアクセスログが問題解決の助けになったと感じています。
AWS Verified Accessを使用して、ゼロトラストな環境を構築したり、デバイス認証を検討されている方の参考になればと思います。
AUTHOR
