この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
はじめに
CX事業本部の佐藤智樹です。
今回はre:Invent期間中に発表されたサービス、AWS Verified Accessの詳細を話すセッションが公開されたためこちらについてご紹介いたします。まずは大雑把にできることなど確認したい場合は、以下のブログをご確認お願いいたします。
セッションタイトル
Introducing AWS Verified Access: Secure Connections to your applications
登壇者
- Shovan Das氏 Product Manager EC2 VPC
- Jess Szmajda氏 GM VPN
タイトル
アジェンダ
本編
このプレゼンテーションでは、なぜ私たちがAWS Verified Accessを作るのか？このサービスの機能について話します。そしてVerified Accessのポリシー機能やアクセスポリシーの詳細な設定について紹介し、最後にデモで締め括ります。
Connectivity needs of customers
AWSでは、アプリケーションとワークロードのリソースをどのように接続したいかに関わらず、接続のニーズに対して幅広い選択肢を与えてくれます。お客さまはどうでしょうか。監査システムを持たないお客様もいると思います。そのために私達はAWS CLIを考え出しました。その後何が起きるかと言うと、お客様は単純なアプリへの接続により良いセキュリティとしてアプリケーションやデバイスへのアクセス制御を望むようになります。
単純な接続のためには、ネットワークアクセスを信頼する必要があります。ゼロトラストは概念的なモデルであり、ユーザーがアプリケーションやデバイスにアクセスできるために、非伝統的なネットワーク制御を使用する必要があると考えます。
ネットワークに接続すると、アプリケーションにアクセスしたり、他の属性を使用して接続をテストすることができます。例えば、アイデンティティやデバイスの使用停止、開始方法、アクセス期限などを使用して、リアルタイムに接続元のコンテキストを使用して接続させるべきか推定できるようになります。
上記によって何が変わるのか現状を見てみましょう。例えばあなたが自宅で仕事をしているとします。社内NWのアプリやディレクトリへの接続にはインターネットが必要になります。
しかし、IDやデバイスが一致して不正にアクセスされる可能性があります。そこでアクセスに対してゼロトラストの要素を取り入れようとします。
VPNを使うとどうでしょうか。デバイスベースポリシーとVPNポリシー、アプリポリシーを使って、IDやデバイスの検証をするとします。この場合、アプリケーション追加時に3つのポリシーを変更する必要があります。
Introducing Verified Access
お客様の声を聞き、効率的なセキュリティアクセスができるようにAWS Verified Accessを開発しました。ユーザはWebブラウザからアクセスでき、IDやデバイス状態は常に評価され、アプリケーションの追加はオペレーションなどはもっと簡素化します。
各アプリケーションは単一のポリシーで管理でき、数回のクリックで実現できます。管理者は単一のポリシーの更新にのみ集中することで管理範囲を抑えることができます。
例えば、財務金融アプリケーションのように、デバイスの状態を利用し、ユーザーがポリシーによってアプリにアクセスするか決定できます。これは、多くのお客様にとって非常に価値のあることです。なぜなら、そのデータを使って、コンプライアンスやセキュリティの問題を解決できるからです。
私達は色々な顧客を見ていますが、彼らはデバイス管理部門をもっていて、エンドポイントにあるデバイスのセキュリティを管理しています。そのような部署を含めて、ポリシーを定義するのに利用することができます。そして、外部のDevice Trust製品やIDPなどと連携できます。
Trust providerには、IDP/Device security pattern/Contextual data patternsが使えます。SIEM/observability providerと連携しリスク分析、分析結果を出すこともできます。またManaged Connectivity providerでVerified Accessへの接続を提供できます。
IDPとの接続には、既に別のIDPを使用している場合はIAM Identity Center(以降IDC)とSAML連携、未使用の場合はそのままIDCを使用、OIDC Idpを使う場合はそのまま連携することもできます。
デバイスの検証には、パートナーエージェントとブラウザの拡張機能を使います。現在はChromeとFirefoxでのみサポートされており、他の対応は計画中です。デバイスの検証を使用しない場合、拡張機能は不要ですがデバイスの状態は検証に利用できません。
(この後オブザーバビリティーの話があったのですが写真撮りそびれたので動画が公式から上がれば更新します)
上記のAWSのサービスを使って、Verified Accessへの接続を実装することができます。外部からの接続の場合はRoute53が使え、プライベートな場合の接続も可能です。
これらは私たちのパートナーです。これらのDevice/Network Trust製品やObservabillity製品と連携することができます。
既存のVPNからマイグレーションする場合にはどうすれば良いでしょうか。Verified Accessにアプリを追加し、VPNを維持した状態でVerified Accessに既存アプリを追加します。最終的にVPNのパスを消すことで移行できます。
How Verified Access works
どのような流れでVerified Accessは動くのでしょうか。まずはProviderに接続します。企業アプリに対してパブリックなエンドポイントがアタッチされます。その後ポリシーに応じて接続可否が決定され、ユーザは企業アプリにアクセスできます。
企業アプリとはなんでしょうか。疑問に思うかもしれないので紹介します。IDPやアプリケーション保護ができない場合、プライベートサブネットに配置し、接続を内部に閉じます。別のパターンとしてALB/NLBはパブリックとしてOIDCによる認証を実施する場合もあります。これらをゼロトラストの原則に従った形式に改良します。
Verified Accessのエンドポイントは別のAWSアカウントに作成され、ユーザ管理のALB/NLB/ENIと接続しCNAMEで繋げて、Verified Accessのエンドポイント経由でどこからでもアクセスできるようになります。
またポリシーや企業アプリはグループ化することができます。特定の業種などに応じてグルーピングできます。アプリの追加のたびグループを追加作成せず、任意のユーザに権限を付与できます。また細かく設定したい場合は、アプリケーションに応じたポリシーもオプションで作成できます。
Verified Access Policies
ここからはポリシーの書き方についてお話しします。私たちは、多様な製品を効率的に使用することを目的としてているため。真新しいポリシーの言語を使用していません。では、なぜそれを選んだのか、どのように使うのかについてお話ししましょう。
ポリシー言語を選択する際には、それを可能にするための3つの基準が必要だと考えています。まず、表現力があること。制限のためのポリシーを書く人は、実際に自由なコントロールを扱わなければなりません。次に、その分析をサポートするのに十分な厳密さであることです。私たちは、IAM Access Analyzerのような製品を導入し、検証されたアクセスを保持する必要があると感じています。最後に、スケーリングの過程で実際のフローを実行するのに十分な速度でなければなりません。Cedarは、この3つの制約をすべて満たし、私たちにとって効果的な方法なのです。
では、Syntaxを見てみましょう。最初に効果があり、次にprincipal, action, resourceのスコープを決定します。最後に条件のロジックで評価します。
(佐藤補足:記述の際は以下のドキュメントが参考になりそうです)
今すぐ深く理解しましょう。ユーザやデバイスの状態は画像左のように一緒に送られてきます。実際JSONオブジェクトの場合が多いです。JSONに対して適切なポリシーを作成し、データの一部をマッピングして受け取ります。例えば、メールが認証済みでデバイスのリスクが低い場合上部に適合します。またメールのドメインが一致し、デバイスのリスクが高い場合下部に適合します。
Cedarでは多くの演算子がサポートされています。例えば、EqualityやNotといった演算子があります。Like演算子、プロパティが存在するかどうかを確認する演算子などもあります。
さっそく使ってみましょう。この例ではユーザとデバイスをテストしています。すべての評価で許可されたときアクセスできます。1つ目ではfinanceグループでデバイスのassessment.overall(総合評価)が80以上の場合は許可。2つ目では、メールが特定のドメインを持っており、デバイスのリスクがLOWの場合は許可。3つ目は、HTTPのPOSTメソッドで、グループがAdministratorで、デバイスがパッチ適応済の場合は許可。4つ目は、デバイスのmanufacturer(製造メーカー)がShadyCorpの場合は拒否。というように条件づけてアクセス可否をポリシー設定できます。
Console walkthrough
ここからはデモを実行していました。実際にPrivate Subnetに閉じたサービスに対して、Verified Accessで外部アクセスできるようにするデモでした。デモが長く紹介しきれないため気になった部分のみ紹介します。
Verified Access用のService VPC内部ではアクセスポイントが3AZ上に分散して配置され可用性の心配などは最小限で済みそうです。
最終的には上記のような、Trusted ProviderとなるAWS IDCやJamf、CrowdStrikeと接続し、AWS Verified Access Instanceでポリシーの内容に応じて接続可否を決定し、仮設した企業アプリに対してアクセスしていました。
価格設定についても上記のように紹介されました。アプリケーションと関連付けている時間とデータ転送量で変わるようです。以下のページでも詳細や例が公開されています。
所感
Verified Accessの生まれた理由、新しく採用した言語Cedarの紹介、外部製品との関連の紹介など盛り沢山の内容でした。よりVerified Accessについての理解が深まるセッションだったので楽しかったです。動画や資料が公開されればそちらでも詳細確認することをおすすめします。まだプレビュー段階なので、実際に使ってみて東京リージョンでの使用要望や改善要望なども上げていきましょう！
後、内容に関係ないですがAWS IAM Identity CenterってIDCって略してました。早く公式の略名決まって欲しいですね。
5
