AWS Verified Access プレビュー – 企業アプリケーションへの VPN レスの安全なネットワークアクセス

11 月 29 日、AWS Verified Access のプレビューを発表しました。AWS Verified Access は、VPN を必要とすることなく、企業がローカルまたはリモートで自社の企業アプリケーションに安全にアクセスすることを可能にする新しい安全な接続サービスです。

従来、外出先や在宅勤務時におけるアプリケーションへのリモートアクセスは VPN によって許可されていました。リモートワーカーは、VPN で認証されると、VPN ゲートウェイ、ファイアウォール、ID プロバイダー、エンタープライズデバイス管理ソリューションなど、サイロ化されたシステムで定義された複数のポリシーに応じて、さまざまなアプリケーションにアクセスできるようになります。通常、これらのポリシーは異なるチームによって管理されるため、重複が生じ、アプリケーションのアクセスに関する問題を診断するのが困難になる可能性があります。社内アプリケーションは、最新のエンタープライズパターンに合わせて調整された OIDC などの最新のプロトコルではなく、LAN を念頭に置いて構築された Kerberos などの古い認証プロトコルに依拠していることがよくあります。お客様からは、ポリシーの更新を展開するまでに数か月かかる場合があるとの声が寄せられていました。

Verified Access は、AWS ゼロトラストのセキュリティ原則を用いて構築されています。ゼロトラストは、従来のネットワークコントロールやネットワーク境界だけに依拠しない、またはこれらに基盤レベルで依拠しないデジタルアセットに関するセキュリティコントロールの提供に重点を置いた概念モデルおよび関連する一連のメカニズムです。

Verified Access は、セキュリティに関する複数の入力を活用してアプリケーションに対するアクセス権を付与することで、組織のセキュリティ体制を強化します。ユーザーとそのデバイスが指定されたセキュリティ要件を満たしている場合にのみ、アプリケーションに対するアクセス権を付与します。入力の例としては、ユーザーの ID やロール、デバイスのセキュリティ体制などがあります。Verified Access は、アクセス権を付与する前に、ユーザーまたはネットワークにかかわらず、各アプリケーションリクエストを検証します。各アプリケーションアクセスリクエストを評価することで、Verified Access は変化する状況に基づいてセキュリティ体制を調整できます。例えば、デバイスのセキュリティによってデバイスの状態がコンプライアンス違反であることが示された場合、Verified Access はアプリケーションへのアクセスを許可しなくなります。

私の見解では、Verified Access を採用することには主に 3 つのメリットがあります。

IT 管理者にとって使いやすいサービスです。IT 管理者は、安全なリモートアクセスを実現するために、アプリケーションを簡単に設定できるようになりました。これにより、企業アプリケーションへのアクセスを許可または拒否するマルチシステムセキュリティポリシーを管理および適用するための単一の設定ポイントが提供されます。

既存の ID プロバイダーとデバイス管理システムを維持できるようにするオープンエコシステムを提供します。この記事の末尾にすべてのパートナーを記載しました。

エンドユーザーにとって使いやすいサービスです。これは、私のお気に入りのメリットです。ワークフォースは VPN クライアントを使用する必要がなくなりました。ユーザーとデバイスが識別および検証されたら、シンプルなブラウザプラグインで安全にアクセス権を付与できます。現在、Chrome および Firefox のウェブブラウザをサポートしています。このことについては、私の個人的な経験を共有できます。Amazon は数年前に VPN レス戦略を採用しました。VPN クライアントを起動したり、一日中接続したままにしたりしなくても、社内のウェブアプリケーションのほとんどにアクセスできるため、同僚も私も助かっています。

実際の動作
ウェブサーバーをプライベート VPC にデプロイし、プライベート Application Load Balancer (https://demo.seb.go-aws.com) を通じてエンドユーザーに公開しました。アプリケーションの外部エンドポイント (secured.seb.go-aws.com) 用に TLS 証明書を作成しました。また、AWS Identity Center (AWS SSO の後継サービス) も設定しました。このデモでは、これをユーザー ID のソースとして使用します。これで、このアプリケーションをリモートワーカーに公開する準備ができました。

Verified Access エンドポイントの作成は 4 つのステップで行います。使用を開始するために、AWS マネジメントコンソールの VPC ページに移動します。最初に、信頼プロバイダーを作成します。信頼プロバイダーは、ユーザーとデバイスのために ID 情報を維持および管理します。アプリケーションリクエストが実行されると、信頼プロバイダーから送信された ID 情報は、アプリケーションリクエストを許可または拒否する前に Verified Access によって評価されます。左側のナビゲーションペインで [Verified Access trust provider] (Verified Access 信頼プロバイダー) を選択します。

[Create Verified Access trust provider] (Verified Access 信頼プロバイダーを作成) ページで、[Name] (名前) とオプションの [Description] (説明) を入力します。[Policy reference name] (ポリシー参照名) を入力します。これは、ポリシールールを操作するときに使用される識別子です。信頼できる情報源である [User trust provider] (ユーザー信頼プロバイダー) を選択します。このデモでは、ユーザー ID の信頼できる情報源として [IAM Identity Center] を選択します。Verified Access は、他の OpenID Connect 準拠プロバイダーとも連携します。最後に、[Create Verified Access trust provider] (Verified Access 信頼プロバイダーを作成) を選択します。

信頼プロバイダーが複数ある場合は、この操作を繰り返すことができます。例えば、エンドユーザーが本人であることを検証する ID ベースの信頼プロバイダーと、そのエンドユーザーのデバイスのセキュリティ状態を検証するデバイスベースの信頼プロバイダーがある場合があります。

その後、Verified Identity インスタンスを作成します。Verified Access インスタンスは、アプリケーションリクエストを評価し、セキュリティ要件が満たされた場合にのみアクセス権を付与する AWS のリージョンレベルのエンティティです。

[Create Verified Access instance] (Verified Access インスタンスを作成) ページで、[Name] (名前) とオプションの [Description] (説明) を入力します。先ほど作成した信頼プロバイダーを選択します。Verified Access インスタンスが作成されたら、信頼プロバイダーの種類をさらに追加できます。

3 つ目のステップでは、Verified Access グループを作成します。

Verified Access グループは、類似のセキュリティ要件を持つアプリケーションをまとめたものです。Verified Access グループ内の各アプリケーションは、グループレベルのポリシーを共有します。例えば、「金融」ユーザー向けにすべてのアプリケーションをグループ化し、1 つの共通ポリシーを使用できます。これにより、ポリシー管理が簡単になります。類似のアクセスニーズがあるアプリケーションのグループに 1 つのポリシーを使用できます。

[Create Verified Access group] (Verified Access グループを作成) ページで、[Name] (名前) のみを入力します。ポリシーは後で入力します。

設定をテストする前の 4 つ目の最終ステップは、エンドポイントを作成することです。

Verified Access エンドポイントは、Verified Access がアクセスを提供するアプリケーションを指定するリージョンレベルのリソースです。エンドユーザーはここに接続します。各エンドポイントには独自の DNS 名と TLS 証明書があります。着信リクエストを評価した後、エンドポイントは承認されたリクエストを社内アプリケーション (社内ロードバランサーまたはネットワークインターフェイス) に転送します。Verified Access は、ネットワークレベルおよびアプリケーションレベルのロードバランサーをサポートします。

[Create Verified Access endpoint] (Verified Access エンドポイントを作成) ページで、[Name] (名前) と [Description] (説明) を入力します。ここでは、作成した [Verified Access group] (Verified Access グループ) を参照します。

[Application details] (アプリケーションの詳細) セクションの [Application domain] (アプリケーションドメイン) で、エンドユーザーがアプリケーションにアクセスするために使用する DNS 名を入力します。このデモでは、secured.seb.go-aws.com を使用します。[Domain certificate ARN] (ドメイン証明書の ARN) で、DNS 名と一致する TLS 証明書を選択します。AWS Certificate Manager を使用して証明書を作成しました。

[Endpoint details] (エンドポイントの詳細) セクションで、[Attachment type] (アタッチメントタイプ) として [VPC] を選択します。このエンドポイントにアタッチする [Security groups] (セキュリティグループ) を 1 つ以上選択します。[Endpoint domain prefix] (エンドポイントのドメインのプレフィックス) として awsnewsblog と入力します。[Endpoint type] (エンドポイントのタイプ) としてロードバランサーを選択します。[Protocol] (プロトコル) (HTTP) を選択し、[Port] (ポート) (80) を入力します。[Load balancer ARN] (ロードバランサーの ARN) と、ロードバランサーがデプロイされるプライベート [Subnets] (サブネット) を選択します。

繰り返しますが、[Policy details] (ポリシーの詳細) セクションは空白のままにします。代わりにグループ内のポリシーを定義します。完了したら、[Create Verified Access endpoint] (Verified Access エンドポイントを作成) を選択します。作成には数分かかる場合があります。

さぁ、コーヒーを飲みながら足を伸ばしましょう。戻ってみると、Verified Access のエンドポイントが ✅[Active] (アクティブ) になっていることがわかります。[Endpoint domain] (エンドポイントのドメイン) をコピーして、CNAME レコードとしてアプリケーション DNS 名 (secured.seb.go-aws.com) に追加します。ここでは Amazon Route 53 を使用していますが、既存の DNS サーバーも使用できます。

その後、私のお気に入りのブラウザが https://secured.seb.go-aws.com をポイントするようにします。ブラウザは IAM Identity Center (旧称: AWS SSO) にリダイレクトされます。テストユーザーのユーザー名とパスワードを入力します。このスクリーンショットは掲載していません。リダイレクト後、「Unauthorized」(未承認) というエラーメッセージが表示されます。Verified Access エンドポイントでポリシーが定義されていないため、これは想定される動作です。デフォルトではすべてのリクエストを拒否します。

[Verified Access groups] (Verified Access グループ) のページで、[Policy] (ポリシー) タブを選択します。その後、[Modify Verified Access endpoint policy] (Verified Access エンドポイントポリシーを変更) ボタンを選択してアクセスポリシーを作成します。

認証されており、かつ、@amazon.com で終わるメールアドレスを持つあらゆるユーザーを許可するポリシーを入力します。これは、AWS Identity Center で定義したユーザーのために使用したメールアドレスです。context に続く名前は、[Verified Access trust provider] (Verified Access 信頼プロバイダー) を作成したときに [Policy reference name] (ポリシー参照名) として入力した名前であることに注意してください。ドキュメントページには、ポリシー構文、属性、使用できる演算子の詳細が記載されています。

permit(principal, action, resource)
when {
    context.awsnewsblog.user.email.address like "*@amazon.com"
};

数分後、Verified Access はポリシーを更新し、再び [Active] (アクティブ) になります。ブラウザを強制的に更新すると、認証されたユーザーが社内アプリケーションを使用できるようになったことがわかります。

料金と利用可能なリージョン

AWS Verified Access は現在、米国東部 (オハイオ、バージニア北部)、米国西部 (北カリフォルニア、オレゴン)、アジアパシフィック (シドニー)、カナダ (中部)、欧州 (アイルランド、ロンドン、パリ)、南米 (サンパウロ) という 10 の AWS リージョンでプレビュー版としてご利用いただけます。

通常どおり、料金は使用量に基づきます。前払いや固定料金はありません。1 つのアプリケーション (Verified Access エンドポイント) につき 1 時間ごとに課金され、アプリケーション数に応じて各階層の料金が適用されます。米国東部 (バージニア北部) リージョンの料金は、Verified Access エンドポイントごとに 1 時間あたり 0.27 USD からです。アプリケーションの数が 200 個を超えると、この料金は、エンドポイントごとに 1 時間あたり 0.20 USD となります。

さらに、Verified Access によって処理されるデータには、1 GB あたり 0.02 USD の料金がかかります。また、Verified Access を使用して転送されるすべてのデータについて、標準の AWS データ転送料金が発生します。

この請求モデルにより、小さな規模で始めて、自分のペースで拡張することが簡単になります。

今すぐ最初の Verified Access アクセスポイントを設定しましょう。

— seb

原文はこちらです。