23/07/28 16:09

Okta ✕ AWS Verified Access を使いプライベートアプリにインターネットからアクセスする

こんにちは。ネクストモードの韓です。

今回はAWS上にある非公開アプリケーションをインターネット経由で特定の人だけが利用する手法をOkta と AWS Verified Access で実践してみます。

内部アプリを特定の人だけに利用させる方法

AWS上に構築した関係者だけが使うアプリケーションへのアクセス方法は様々あります。

インターネット公開せずDirect Connect や Site-to-Site VPNを用いた閉域接続経由でアクセスする
インターネット公開した上で固定IPからのみ許可する
Netskope のようなZTNAソリューションを用いて AWS に直接アクセスを行う

Direct ConnectやVPNは設備の維持管理が必要となりますしそれなりに料金が掛かります。固定IPを信頼したアクセス制御はインターネットに公開する必要があることと、社内環境のようにIPが固定できない在宅や出先でのアクセス制御が難しいという点があります。NetskopeのようなZTNAを活用するのも良いソリューションですがこれだけのために導入するのは難しいと思われます。

AWS Verified Access と Okta を使ってアクセス

今回は、プライベートサブネットにあるアプリケーションへAWS Verified Access(以降、AVA)のエンドポイント経由を介してインターネットからアクセスします。

アクセスの際 AVA は認証が必要となるのですが、認証プロバイダを Okta とします。

構成図

※ AWS Verified Access は GA となっておりますが、執筆時の2023年7月時点では東京・大阪リージョンでは未だ利用ができないため、北米のオレゴンリージョンで試行しました。

やってみた

準備するもの

内部Webアプリケーション
アクセスするためのドメイン取得と証明書(ACM)
認証プロバイダとしての Okta

Okta アプリケーションの作成

Oktaの管理コンソールに入り、アプリケーションメニューを開き、「アプリ統合を作成」を選びます

アプリ統合を作成

サインイン方法は OIDC、アプリケーションタイプは Webアプリケーションを選択し、次へ進みます。

アプリ統合のサインイン方法

アプリ名、ロゴを入力し、付与コードは認証コードであること確認します。

サインイン・リダイレクトURIは https://{アクセス用ドメイン}/authorization-code/callback を指定、サインアウト・リダイレクトURIは今回はデフォルトのままとしました。

アプリ統合の詳細設定

保存を行うと連携のためのクライアント資格情報が作成されます。

クライアントの資格情報

AWS Verified Accessの設定

ここからはAWSでの操作となります。

AVA 信頼プロバイダーを作成

①ユーザー信用プロバイダー、②OIDCを選択します。

③～⑥の発行者や各種エンドポイントは後述の情報を参照して入力します。

⑦⑧のクライアントIDおよびクライアントシークレットは、前工程で作成たOktaアプリの情報を入力します。

⑨スコープには openid profile groups を入力します

信頼プロバイダーの作成画面

※ 各種エンドポイント情報の取得について

ブラウザで以下にアクセスすると OIDC 連携の際に必要な情報を取得することが出来ます。

https://{ご利用のOktaドメイン}.okta.com/.well-known/openid-configuration

以下のようにブラウザに表示されます (※ JSON整形プラグインを使用)ので、各エンドポイントの値をコピーして信頼プロバイダー設定に転記します。

Oktaの詳細情報を参照

Verified Accessインスタンスの作成

インスタンス作成時に先程作成した信頼プロバイダーを指定します。

AVAインスタンスの作成

Verified Access グループの作成

Verified Accessグループを作成します。インスタンスは先程作成したものを指定します。

AVAグループの作成

ポリシーでは認証を通過したユーザーが実際にアクセスできるかを条件式で指定できます。

今回は認証プロバイダーである Okta で適切に権限付与する前提としますので、認証が通れば利用可とする以下の設定を入力します。

permit(principal,action,resource)
when {
    true
};

Verified Access エンドポイントの作成

Verified Accessエンドポイントはインターネットからアクセスポイントとなります。

先に作成したVerified Accessグループと、事前に用意した証明書を指定します。

AVAエンドポイントの作成

エンドポイントはVPCとし、セキュリティグループを指定し、エンドポイントタイプはロードバランサー、ターゲットとなるサブネットを指定します。

なお、エンドポイントドメインプレフィックスは任意の文字列を指定可能です(詳細は後述)。

AVAエンドポイントの詳細

ポリシー設定はグループ設定と同じ以下としました。

permit(principal,action,resource)
when {
    true
};

エンドドメインドメインプレフィックスは、作成されたエンドポインのトドメインの先頭に着くもので、任意のものを指定できます。

エンドポイントドメインの参照

このエンドポイントドメインを値としたCNAMEレコードを作成することで、ドメインと紐付けることができ、Webアクセスが可能となります。

OktaとAVAの設定は以上となります。

利用者の割り当て(アサイン)

AVAのほうでは認証プロバイダーが認めたユーザ全てにアクセスが可能としました。

そのため認証プロバイダーである Okta でアプリへのアクセス制御を行います。

ユーザまたはグループに対して割り当てが自由であるため柔軟な運用ができるとともに、各アプリへのアクセス制御を一元管理できるメリットがあります。

Oktaアプリへのアサイン

接続してみる

ブラウザで指定のドメインにアクセスしてみると、Oktaにリダイレクトされ認証が要求されます。Oktaで指定したアプリケーションアイコンも表示されており、認証連携は成功です。

Oktaへ認証がリダイレクトされた画面

Okta FastPass またはユーザ名&パスワードで認証することで、所定のアプリケーションに接続することが出来ました。

なお、Oktaでアプリへのアサインを行っていないと認証が通らず401エラー画面が表示されます。

まとめ

最近はゼロトラストのソリューションがたくさん出てきてワクワクしますね。インターネット非公開のプライベートアプリケーションに安全にアクセスできる AVA は素晴らしいソリューションだと思います。

そのポリシー設定でIdPからくる情報でアクセス制御ができるのですが、アプリケーション毎に個別設定をしなければならず管理が大変だと感じました。

ですが、Oktaのような管理が強力なIdPを用いることで、一旦設定したアプリへの権限付与はAWSのナレッジがないメンバーでも可能となり、管理の統一化とガバナンス強化が見込める良い組み合わせになりました。

Okta, AWS, 技術