こんにちは。ネクストモードの韓です。
今回はAWS上にある非公開アプリケーションをインターネット経由で特定の人だけが利用する手法をOkta と AWS Verified Access で実践してみます。
AWS上に構築した関係者だけが使うアプリケーションへのアクセス方法は様々あります。
Direct ConnectやVPNは設備の維持管理が必要となりますしそれなりに料金が掛かります。固定IPを信頼したアクセス制御はインターネットに公開する必要があることと、社内環境のようにIPが固定できない在宅や出先でのアクセス制御が難しいという点があります。NetskopeのようなZTNAを活用するのも良いソリューションですがこれだけのために導入するのは難しいと思われます。
今回は、プライベートサブネットにあるアプリケーションへAWS Verified Access(以降、AVA)のエンドポイント経由を介してインターネットからアクセスします。
アクセスの際 AVA は認証が必要となるのですが、認証プロバイダを Okta とします。
※ AWS Verified Access は GA となっておりますが、執筆時の2023年7月時点では東京・大阪リージョンでは未だ利用ができないため、北米のオレゴンリージョンで試行しました。
Oktaの管理コンソールに入り、アプリケーションメニューを開き、「アプリ統合を作成」を選びます
サインイン方法は OIDC、アプリケーションタイプは Webアプリケーションを選択し、次へ進みます。
アプリ名、ロゴを入力し、付与コードは認証コードであること確認します。
サインイン・リダイレクトURIは https://{アクセス用ドメイン}/authorization-code/callback
を指定、サインアウト・リダイレクトURIは今回はデフォルトのままとしました。
保存を行うと連携のためのクライアント資格情報が作成されます。
ここからはAWSでの操作となります。
①ユーザー信用プロバイダー、②OIDCを選択します。
③~⑥の発行者や各種エンドポイントは後述の情報を参照して入力します。
⑦⑧のクライアントIDおよびクライアントシークレットは、前工程で作成たOktaアプリの情報を入力します。
⑨スコープには openid profile groups
を入力します
※ 各種エンドポイント情報の取得について
ブラウザで以下にアクセスすると OIDC 連携の際に必要な情報を取得することが出来ます。
https://{ご利用のOktaドメイン}.okta.com/.well-known/openid-configuration
以下のようにブラウザに表示されます (※ JSON整形プラグインを使用)ので、各エンドポイントの値をコピーして信頼プロバイダー設定に転記します。
インスタンス作成時に先程作成した信頼プロバイダーを指定します。
Verified Accessグループを作成します。インスタンスは先程作成したものを指定します。
ポリシーでは認証を通過したユーザーが実際にアクセスできるかを条件式で指定できます。
今回は認証プロバイダーである Okta で適切に権限付与する前提としますので、認証が通れば利用可とする以下の設定を入力します。
permit(principal,action,resource)
when {
true
};
Verified Accessエンドポイントはインターネットからアクセスポイントとなります。
先に作成したVerified Accessグループと、事前に用意した証明書を指定します。
エンドポイントはVPCとし、セキュリティグループを指定し、エンドポイントタイプはロードバランサー、ターゲットとなるサブネットを指定します。
なお、エンドポイント ドメインプレフィックスは任意の文字列を指定可能です(詳細は後述)。
ポリシー設定はグループ設定と同じ以下としました。
permit(principal,action,resource)
when {
true
};
エンドドメイン ドメインプレフィックスは、作成されたエンドポインのトドメインの先頭に着くもので、任意のものを指定できます。
このエンドポイントドメインを値としたCNAMEレコードを作成することで、ドメインと紐付けることができ、Webアクセスが可能となります。
OktaとAVAの設定は以上となります。
AVAのほうでは認証プロバイダーが認めたユーザ全てにアクセスが可能としました。
そのため認証プロバイダーである Okta でアプリへのアクセス制御を行います。
ユーザまたはグループに対して割り当てが自由であるため柔軟な運用ができるとともに、各アプリへのアクセス制御を一元管理できるメリットがあります。
ブラウザで指定のドメインにアクセスしてみると、Oktaにリダイレクトされ認証が要求されます。Oktaで指定したアプリケーションアイコンも表示されており、認証連携は成功です。
Okta FastPass または ユーザ名&パスワードで認証することで、所定のアプリケーションに接続することが出来ました。
なお、Oktaでアプリへのアサインを行っていないと認証が通らず401エラー画面が表示されます。
最近はゼロトラストのソリューションがたくさん出てきてワクワクしますね。インターネット非公開のプライベートアプリケーションに安全にアクセスできる AVA は素晴らしいソリューションだと思います。
そのポリシー設定でIdPからくる情報でアクセス制御ができるのですが、アプリケーション毎に個別設定をしなければならず管理が大変だと感じました。
ですが、Oktaのような管理が強力なIdPを用いることで、一旦設定したアプリへの権限付与はAWSのナレッジがないメンバーでも可能となり、管理の統一化とガバナンス強化が見込める良い組み合わせになりました。