re:Invent 2023: AWSのリモート接続ソリューション最新動向と活用事例
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2023 - Secure remote connectivity to AWS (NET202)
この動画では、AWSのリモート接続ソリューションについて詳しく解説しています。AWS Client VPN、EC2 Instance Connect、Session Manager、そしてAWS Verified Access (AVA)といった最新のサービスの特徴や使い方を学べます。特に、AVAを導入してゼロトラスト原則を維持しながらユーザー体験を向上させたAvalon Healthcare Solutionsの事例は興味深いです。セキュリティと利便性の両立に悩むエンジニアにとって、貴重な情報源となるでしょう。 ※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
本編
AWS上のSecure Remote Connectivityセッションの概要
はい、皆さん、聞こえますか？素晴らしい。AWS上のSecure Remote Connectivityへようこそ。私はTom Adamskiと申します。Principal Solution Architectで、ネットワーキングに関することなら何でも担当しています。今日は、AWS接続ソリューション、特にリモート接続ソリューションを担当するPrincipal Product ManagerのShovan Dasと一緒です。そして、ゲストのJuan SuarezさんがAvalon Healthcare Solutionsの具体的なユースケースについてお話しします。
アジェンダに入る前に、企業接続とリモート接続の違いについて説明したいと思います。企業接続というと、よくVPNやPLS、光ファイバー接続などを通じて、オンプレミスのデータセンターや支社など、異なるネットワーク間を接続することを考えます。 そして、その方程式のもう一方の側にリモート接続があります。これは、インターネット上のどこかにユーザーがいて、プライベートリソース、つまりプライベートネットワークやネットワーク内の特定のアプリケーションへのアクセスを提供する必要がある場合です。今日のセッションの残りの部分では、右側に焦点を当てていきます。
アジェンダでは、リモートアクセスの考慮事項、つまりリモートアクセスソリューションを決定する際に考えるべきことについて話します。そして、異なるユースケースについて説明します。ネットワーク全体へのアクセスを提供する場合のネットワークユースケースと、アプリケーションアクセスのユースケースについて説明します。アプリケーションアクセスは、SSH/RDPとHTTPSに分けて説明します。そして、HTTPSの例として、Juanさんから顧客事例をご紹介いただきます。
リモートアクセス接続ソリューションの考慮事項とTCP/IPモデル
さて、リモートアクセス接続ソリューションを決定する際に考慮すべきことは何でしょうか？まず、どのリソースにアクセスを提供するのか、そのリソースがどこにあるのかを把握する必要があります。また、それらのリソースにアクセスするユーザーに対して、どの程度の信頼性と検証が必要かを決める必要があります。そして最後に、アクセスをどのように監査するかです。すべてのリクエストを監査する必要があるのか、それともネットワークにアクセスしたという事実だけを監査すれば十分なのでしょうか。これはほんの一例です。考慮すべき点は他にもたくさんあります。 考慮すべき点を把握するのに役立つのが、サイバーセキュリティフレームワークです。NIST Cybersecurity Framework、ISO 27001、CISなどのフレームワークには、リスク評価の実施や環境内のリスクの特定、懸念事項の把握、そして何らかの緩和計画の提供に関するガイダンスがあります。
そして、その緩和計画を使って接続ソリューションを決定することができます。先ほど述べたように、ネットワークアクセスとアプリケーション層アクセスという2つの異なるユースケースについて説明しますが、それがどういう意味なのかを説明したいと思います。そのために、TCP/IPモデルを使用します。ネットワーキングに詳しい方なら、このモデルをご存じだと思います。 また、7層からなるもう少し複雑なOSIモデルもご存じでしょう。これはそのシンプルバージョンです。このモデルを使用して、環境内のノード間でネットワークトラフィックを転送する際に関与する異なる層を把握します。
では、下から順に見ていきましょう。まず、ネットワークアクセス層があります。これは物理的な接続、つまりファイバーや、その上で動作するイーサネットなどのプロトコルを指します。その上にネットワーク層があり、これはIPアドレス層で、IPv4やIPv6アドレスが含まれます。さらにその上にTCPがあり、接続を確立します。UDPもこの層にあります。そして最後に、実際にネットワーク上で転送されるアプリケーション、つまりHTTP、FTP、SSHなどがあります。今日は2つの異なるユースケースを扱います。1つはネットワークアクセス、つまりリモートユーザーに実質的にIPアドレスへのアクセスを提供すること。もう1つはアプリケーション層アクセスで、特定のアプリケーションへのきめ細かなアクセスについてです。
これらのカテゴリーにAWSのサービスを分類すると、ネットワークレベルのアクセスについては、AWS Client VPNについて話します。SSHやRDPを使用するアプリケーションのユースケースについては、Amazon EC2 Instance ConnectとSystems Managerの一部であるSession Managerについて触れます。そして、アプリケーション層については、AWS Verified Access（AVA）について説明します。
AWS Client VPNの概要とアーキテクチャ
さて、ネットワーク層アクセスから始めましょう。ここでは、Client VPNについて話します。これはAWSが提供する管理型リモートアクセスソリューションで、需要に応じて自動的にスケールすることができます。自前でリモートアクセスサービスを展開する必要はなく、すべてが管理されています。アクセスに対してきめ細かな制御を適用できますが、これはネットワークアクセスソリューションなので、これらの制御はIPアドレスに基づくものであることを覚えておいてください。そして最後に、今日お話しするすべてのサービスに当てはまることですが、どこからでもリソースにアクセスできるという点です。Client VPNはネットワークレベルのアクセスなので、そのネットワーク上のほぼすべてのリソースにアクセスできます。
では、アーキテクチャを見ていきましょう。まず高レベルの概要、高レベルのアーキテクチャから始めて、その後、各コンポーネントを個別に詳しく見ていきます。
高レベルでは、AWSリージョンがあります。その中に、プライベート環境であるVPCがあります。そのVPC内に、何らかのリソースがあります。これはEC2インスタンス（仮想マシン）、データベース、ロードバランサー、またはコンテナかもしれません。実際には、IPアドレスを持っているものであれば何でも当てはまります。
リモートユーザーにこれらのリソースへのアクセスを許可したい場合、AWS Client VPN エンドポイントをプロビジョニングし、そのエンドポイントを VPC に関連付ける必要があります。そして、ユーザーのマシンに Client VPN エンドポイントへの TLS 接続を確立するための適切なソフトウェアがあることを確認しなければなりません。 この時点で、認証と認可を行い、ユーザーがアクセスしようとしているリソースへのアクセスが許可されているかどうかを確認します。許可されている場合は、トラフィックを目的地に転送します。
AWS Client VPNの詳細機能と設定オプション
これらのコンポーネントのいくつかを詳しく見ていきましょう。まずはリモートユーザーから始めます。リモートユーザーは Client VPN ソフトウェアを実行する必要があります。 AWS は Windows、Mac、Linux マシンにインストールできるソフトウェアを提供しています。オープンソースの OpenVPN ソフトウェアを使用して VPN を確立することもできますが、機能が制限されるため、違いについてはドキュメントを確認してください。
接続の観点から、Client VPN はフルトンネルとスプリットトンネルの両方をサポートしています。フルトンネルでは、目的地に関係なく、あらゆる目的地へのトラフィックがまずトンネルを経由するべきだと指定します。スプリットトンネルでは、TLS トンネルを経由すべき特定の IP アドレスブロックを定義し、それ以外の目的地への接続はリモートユーザーのローカルネットワーク接続を使用します。
複数のユーザーが同時に接続している場合、VPC を経由せずに直接クライアント間のフローを有効にするオプションもあります。これは比較的最近の機能です。
次に、認証と認可に焦点を当てましょう。これから説明するオプションはすべて互換性があるので、どのオプションを使用するかを決めることができます。まず、相互 TLS から始めましょう。リモートユーザーにクライアント証明書を提供し、その証明書が有効である限り、Client VPN はユーザーを認証します。これは単独で使用することも、Active Directory や SAML などの他の認証方法と組み合わせてポリシー決定を行うこともできます。
Active DirectoryとSAMLを使用すると、きめ細かな認可ルールを設定できます。例えば、ユーザーが特定のグループに属している場合、この例では Engineering グループですが、特定の宛先へのアクセスを許可することができます。ここでの宛先は個別のIPアドレスですが、ネットワーク全体を指定することもできます。
Client VPNのもう一つの機能として、Lambda connection handlerがあります。これは非常に興味深い機能です。Lambdaはサーバーレス環境で、自分のコードを持ち込んでClient VPNエンドポイントと統合することができます。ユーザーが認証を行った後、私たちは事前に定義されたLambda関数に多くの情報を送信します。そして、その情報を使って好きなことができます。例えば、リモートユーザーのパブリックIPアドレスを取得し、ジオデータベースと照合してそのユーザーがどの国から接続しているかを確認し、認証に成功したとしてもそのユーザーをブロックすることができます。これは、Client VPNにオプションで追加できる追加のゲートのようなものです。
AWS Client VPNのネットワーク接続とセキュリティ設定
では、最後の部分であるClient VPNエンドポイントとVPCの関連付けを見てみましょう。高可用性を確保するために、複数のアベイラビリティーゾーンと関連付けることをお勧めします。関連付けの方法は、どのサブネットと関連付けるかを決定することです。それらのサブネットで、Client VPNはElastic Network Interface（ENI）をプロビジョニングします。これは仮想NICと考えることができます。
リモートユーザーからのすべてのトラフィックは、それらのリモートユーザーに割り当てられたIPアドレスに関係なく、ソースアドレスNATされ、実質的にそれらのネットワークインターフェースのIPアドレスに変換されます。これの副次的な利点は、この例ではSecurity Group Bと呼ばれるセキュリティグループをそれらのネットワークインターフェースの周りに配置し、そのセキュリティグループをVPC内の既存のリソースで参照できることです。
私のSecurity Group Aでは、HTTPトラフィックを許可していますが、Client VPNエンドポイントからのトラフィックを識別するSecurity Group Bからのみ許可しています。NATを行うもう一つの利点は、ルーティング可能な限り、どの宛先にもトラフィックを送ることができることです。つまり、ローカルVPCだけでなく、Transit Gateway、Cloud WAN、ピアリング接続、AWS PrivateLink エンドポイントなどの他のネットワーキング構成を通じて、多くの他の宛先に接続できます。
オンプレミスのリソースにも接続できます。企業のデータセンターに接続することができます。サイト間VPNやDirect Connect、あるいはインターネットへの接続を可能にするネットワーク接続があれば大丈夫です。必要に応じて、追加のファイアウォールを経路上に配置することもできます。ここではAWS Network Firewallの例を示していますが、サードパーティのベンダーを使用して経路上に配置し、それぞれの宛先へのトラフィックを検査してから到達させることもできます。なお、ピアリング接続上に矢印がないのは意図的です。これはサポートされていない機能です。
SSHアクセスの課題とEC2 Instance Connectの導入
ログの観点から言えば、AWS Client VPNはAmazon CloudWatchにログ情報を記録できます。ログエントリの例を見てみると、実際にはLambda接続ハンドラーに送信している情報とよく似ています。接続しているユーザーに関する多くの情報が含まれています。これは認証に失敗して接続できなかった場合の失敗例です。次にアプリケーションに話を移しましょう。ここでは、単にネットワークへのアクセスを提供するのではなく、特定のアプリケーション層にアクセスするより細かい接続について説明します。まずはSSHとRDPから始めます。時間の都合上、両方を取り上げることができなかったので、SSHを選びました。RDPもサポートされていると考えてください。RDPについて詳しく知りたい場合は、後ほどお話しできます。
これを見たことがあるかもしれません。コンソールでインスタンスに接続すると、EC2インスタンスに接続するためのさまざまなオプションがある画面が表示されます。最初の3つについて説明します。時間の都合上、EC2シリアルコンソールについては触れませんが、これがEC2インスタンスへのアウトオブバンドアクセスであることだけは覚えておいてください。セキュリティグループやNACLを誤って設定してしまい、何らかの理由でインスタンスにアクセスできなくなった場合でも、EC2シリアルコンソールを使用して常にアウトオブバンドのバックアップアクセスが可能です。
基本から始めましょう。SSHアクセスがどのように見えるかを説明し、SSHアクセスの課題について触れ、そしてそれらの課題がどのように2つのソリューションによって解決されるかを説明します。ここにEC2インスタンスがあり、リモートユーザーがそのインスタンスにSSH接続する必要があります。これを機能させるためにはいくつかの設定が必要です。まず、インスタンスにパブリックIPアドレスまたはElastic IPアドレスを割り当てる必要があります。インターネットとの間でアクセスを可能にするインターネットゲートウェイを作成する必要があります。ルーティングも設定しなければなりません。ここではルートテーブルを示していませんが、ルートテーブルが存在し、正しく設定されていることを確認する必要があります。
次に、インスタンスの周りにセキュリティグループを設定し、特定のIPアドレスからのSSHトラフィックを許可する必要があります。ここでは「リモートユーザーから」と言っていますが、これはリモートユーザーのIPアドレスが分かっている場合です。IPアドレスが不明な場合は、インターネット上のどこからでも許可しなければならないかもしれません。そして、SSHはPKIを使用するので、秘密鍵と公開鍵のペアが必要です。秘密鍵は常に隠されており、ユーザーだけが知っています。一方、公開鍵はインスタンスに置かれます。これらが一致していれば、ユーザーはSSHセッションを確立できます。
では、CLI アクセスの例を見てみましょう。ユーザーは SSH コマンドを実行し、割り当てられた秘密鍵を指定し、ユーザー名を指定し、接続先インスタンスの IP アドレスを指定します。すべてが正常であれば、目的のインスタンスへの SSH セッションを確立できます。では、これにはどのような課題があるでしょうか？まず、公開鍵と秘密鍵の管理です。ここでは単一のユーザーと単一のインスタンス、つまり単一のキーペアを示しましたが、何百人ものユーザーと何百台ものインスタンスがある場合を想像してみてください。常に公開鍵と秘密鍵の管理が必要で、さらに定期的にローテーションする必要があります。実は、このローテーションが最も難しい部分なのです。
次に、インターネットとの間に公開パスを設定する必要があります。VPC を完全に隔離したい場合でも、SSH を機能させるためには、インターネットゲートウェイと公開 IP アドレスが必要になります。そして、セキュリティグループの観点からは、世界中のどこからでもトラフィックを許可する必要があります。ここでは、Amazon EC2 Instance Connect と AWS Systems Manager の Session Manager という2つのソリューションを見ていきます。
EC2 Instance Connectの詳細と設定オプション
まずは EC2 Instance Connect から始めましょう。常に2つのオプションがあります。1つはインターネットゲートウェイを使用するもの、もう1つはインターネットゲートウェイを使用しないオプションです。インターネットゲートウェイを使用するものから始めましょう。基本的な EC2 Instance Connect では、EC2 インスタンス、Elastic IP アドレス、インターネットゲートウェイ、そしてリモートユーザーからのアクセスを許可するセキュリティグループは引き続き必要です。しかし今回は、EC2 インスタンスと直接通信する代わりに、EC2 Instance Connect サービスを使用し、そのサービスがパブリックインターネット経由でインスタンスと通信します。ユーザーは AWS CLI を使用して EC2 Instance Connect サービスとやり取りします。
特定のインスタンス ID への SSH 接続を指定すると、そのインスタンスに接続するための適切なポリシーがあるかどうかを確認できます。これにより、OS の外部で Identity and Access Management を使用して、実際に SSH 接続が許可されているかどうかを検証できます。
許可されている場合、その場で一時的な公開鍵と秘密鍵が生成されます。これらのキーは各セッションごとに一時的に生成されるため、もはやキーの管理を心配する必要はありません。すべてが正常に機能すれば、ユーザーは TLS を使用して EC2 Instance Connect サービスとセッションを確立し、そのセッション内で SSH 接続を確立することができます。
EC2 Instance Connect はブラウザアクセスもサポートしています。 ブラウザを使いたい場合も可能です。ただし、追加の IP 範囲を許可するようにセキュリティグループを更新することを忘れないでください。 このアクセスに関するポリシーの一例をご紹介します。このポリシーでは、特定のタグ値を持つインスタンスであれば、誰でも接続できるようになっています。もちろん、これはあくまで一例で、ポリシーは必要に応じて自由に設定できます。
インターネットゲートウェイの必要性をなくしたい場合は、EC2 Instance Connect エンドポイントを使用できます。インターネットゲートウェイの代わりに、 VPC 内のエンドポイントを通じて EC2 Instance Connect サービスにプライベートに接続する方法があります。エンドポイントにはセキュリティグループがあるので、トラフィックはサービスからエンドポイントまでプライベートに、そしてエンドポイントから EC2 インスタンスまでプライベートに流れます。 エンドポイントにセキュリティグループがあるため、インスタンスのセキュリティグループでそのセキュリティグループを参照し、この EC2 Instance Connect エンドポイントからの SSH トラフィックのみを許可することができます。
Systems Manager Session Managerの概要と機能
接続の仕組みは同じです。CLI を使用する場合、エンドポイントの存在を自動的に検出するので、特別な指定は必要ありません。インスタンスへの接続を要求するだけで、ポリシーをチェックします。 許可されていれば、その場でキーを作成し、インスタンスへのセッションを確立できます。ブラウザアクセスでも同じプロセスが適用されます。
エンドポイントの観点からは、いくつかの設定オプションがあります。 IP 保持を有効にするかどうかを決めることができます。IP 保持を無効にすると、EC2 インスタンスに到達するトラフィックは、エンドポイントの IP アドレスから来ているように見えます。 IP 保持を有効にすると、リモートユーザーの実際のクライアント IP アドレス（パブリック IP アドレス）が EC2 インスタンスまで保持され、ログで確認できるようになります。
では次に、Systems Manager の一部である Session Manager に話を移しましょう。 Systems Manager は、すでに使用しているかもしれない、あるいは使用することになるかもしれないサービス群です。EC2 インスタンスだけでなく、オンプレミスの仮想マシン、さらには他のクラウドプロバイダーのマシンのオーケストレーションや管理に使用されます。コマンドの送信や、今回の例のように、リモートアクセスに特化した Session Manager の使用などが可能です。
Systems Managerの場合、EC2インスタンスや使用したい仮想マシンにエージェントをデプロイする必要があります。ただし、特にAmazon Linuxなど、ほとんどのEC2インスタンスでは、エージェントが自動的にプリインストールされています。
Session Managerのアーキテクチャを見てみましょう。EC2インスタンス、インターネットゲートウェイ、リモートユーザーがあり、今回はSession Managerと通信します。 興味深いことに、Session ManagerがEC2インスタンスと通信するのではなく、EC2インスタンスがSession Managerへのアウトバウンド接続を行います。このアウトバウンド接続を行うには、適切な権限が必要で、これはSystems Managerロール（SSMロール）を割り当てることで実現します。
このロールにより、インスタンスはSession Managerサービスに接続する権限を得ます。ネットワークパスがあれば、この場合はパブリックネットワークパスで、インターネットゲートウェイとパブリックIPアドレスを使ってSession Managerサービスに接続できます。セキュリティグループの観点から見ると、面白い結果になります。EC2インスタンスがアウトバウンド接続を行うため、インバウンドルールは必要ありません。インバウンドルールを完全にロックダウンしても構いません。
実際、インバウンドルールを1つも設定しなくても、SSHは機能します。リモートユーザーも、AWS CLIを使用して接続しますが、 今回はAWS Systems Manager (SSM)を使用してターゲットインスタンスへのセッションを開始します。ここでも、Identity and Access Management ポリシーと照合して、ユーザーが実際にそのインスタンスに接続する権限があるかどうかを確認できます。 認証されれば、TLSセッションが確立され、キーがプロビジョニングされます。
このアプローチは、 EC2 Instance Connectと同様にブラウザアクセスもサポートしているので、両方のオプションが利用可能です。インターネットゲートウェイを使用したくない場合は、このシナリオでエンドポイントを使用することもできます。 Systems Managerエンドポイントを使用すれば、EC2インスタンスがインターネットゲートウェイやパブリックIPアドレスを使用せずに、完全にプライベートにSession Managerサービスと通信できます。他の部分は全て同じままです。
AWS Verified Access（AVA）の導入と主要機能
それでは、ポリシーがどのように見えるか見てみましょう。複雑に見えても心配しないでください。これは200レベルのセッションですが、できることの一例を垣間見るだけです。このシナリオでは、このポリシーを持つ人が特定のインスタンスにSSMセッションを開始することを許可しています。ここでオプションとして追加した項目が1つあります：SSMドキュメントを指定できるのです。SSMドキュメントは、ユーザーがインスタンスに接続する際に適用される一連の指示です。
この例のSSMドキュメントでは、誰かが接続するとすぐに、特定のログパスに注目し、そのログパスに表示されるものを即座に「tail」、つまり効果的に監視したいと指定しています。リモートユーザーがこのポリシーをどのように使用するか、例を見てみましょう。SSMコマンドを変更して、SSMドキュメントを使用することを指定する必要があります。ドキュメントの使用を強制するかどうかは選択できます。常に全員にドキュメントを使用させたい場合、誰かがそれを含めなければ、IAMだけで接続をブロックできます。
すべてが正しければ、ユーザーはセッションを確立し、すぐにポリシーの情報、特にそのSSMドキュメントの情報が実行され、ユーザーはログに表示されるエントリーを見始めます。Session Managerはセッションアクティビティのログ記録もサポートしています。これらのログはStorage ServiceかCloudWatchのいずれかに送信できます。ここに特定のエントリーの例があります。誰かがインスタンスに接続したこと、接続した人が使用したロール、そして彼らがどのユーザーとして実行していたかが分かります。下には、彼らが実行したコマンドが表示されています。パブリックIPアドレスにpingを打ち、成功応答を得たようです。つまり、コンソールで行うことはすべてログに記録し、CloudWatchやS3に送信できるのです。
EC2 Instance ConnectとSession Managerについて話しましたが、いくつか類似点があります。エージェントを使用したくない、またはまだ持っていない場合は、EC2 Instance Connectが最適です。LinuxやWindowsを実行しているEC2インスタンスに接続してアクセスする簡単な方法です。Session Managerの場合はエージェントが必要ですが、すでにそのエージェントがあれば、MacOSを含むより多くのオペレーティングシステムや、EC2のようなAWSのリソース、さらにはオンプレミス環境のリソースにも接続できます。Session Managerでは、インバウンドのSSHアクセスを許可する必要がありません。インスタンスからの接続はアウトバウンドのみだからです。最後に、両方ともSSHキーの管理を心配する必要がなく、ブラウザとCLIのアクセスをサポートし、Identity and Access Managementに対してアイデンティティを効果的にチェックします。
AWS Verified Accessのアーキテクチャと実装の詳細
アプリケーションアクセスのユースケースに移りたいと思います。Shovanがそれについて詳しく説明します。私はShovan Dasで、EC2 VPCチームのプロダクトマネージャーです。Client VPNと次の製品であるAWS Verified Accessを担当しています。AVAとも呼んでいるので、私がAVAと言うのを聞くかもしれません。Tomが最初に言ったように、リソースへのアクセスを考える際には3つのことを考慮する必要があります。まず、リソースは何か？この場合はHTTPアプリケーションです。2つ目は、ユーザーがアプリケーションやリソースにアクセスできるようにするために、どの程度の信頼や検証が必要か？そして3つ目は、監査基準は何か？ということです。
それでは、HTTPアプリケーションをこれらの観点から見ていきましょう。
HTTPアプリケーションは通常、EC2やVPCなどのAWSサービスを使用してエンジニアリングチームによって開発されます。これらのアプリケーションは、全従業員がアクセスする必要のあるIT Help Deskシステムから、財務チームや経営陣のみが使用すべき機密性の高い財務アプリケーションまで多岐にわたります。セキュリティ管理者として、誰がどのアプリケーションにアクセスできるか、そしてどのような条件下でアクセスできるかを細かく制御する必要があります。さらに、数百から数千のアプリケーションが存在する可能性があるため、管理や監査が容易なソリューションが必要です。
ユーザーの視点からすると、シンプルさが求められます。ラップトップを開き、ウェブブラウザにアプリケーションのドメイン名を入力するだけで、どこからでもアクセスできることを望んでいます。例えば、生産性を維持するためにLas Vegasからアプリケーションに接続したいと思うかもしれません。
これらのフィードバックを考慮して、私たちは昨年のre:Inventで発表したAWS Verified Access（AVA）を開発しました。AVAは主に3つのことを行います。まず、ユーザーや従業員がどこからでもアプリケーションに接続できるようにし、モビリティと生産性を向上させます。次に、AWS Verified Accessはゼロトラストの原則に基づいて構築されており、より優れたセキュリティ態勢と細かなセキュリティ制御を提供します。最後に、管理が簡単で、VPCやアカウントの場所に関係なく、すべてのアプリケーションに対して1つのVerified Accessインスタンスのみが必要で、アイデンティティとデバイスの状態に基づいてアクセスを管理する単一のポリシーセットで済みます。
AVAがAWSのゼロトラスト原則に基づいて構築されていると言及しましたが、それが何を意味するのか明確にしましょう。まず、ネットワーキング以外の信号、つまりアイデンティティやデバイスの状態などを重視します。より多くの信号を使用するほど、アクセスを許可する前のセキュリティ態勢と信頼レベルが向上します。次に、継続的な検証を重視します。例えば、Application 1にアクセスしたい場合、Verified Accessはポリシーを実行し、私のアイデンティティとデバイスの状態をチェックしてからアクセスを許可します。その後、Application 2にアクセスしたい場合、再度ポリシーに対して検証が行われます。さらに、少し時間が経ってからApplication 1に再びアクセスしようとしても、何か変更があった可能性があるため、検証プロセスが再度実行されます。
ゼロトラストは新しい概念ではなく、顧客は以前から実装してきましたが、複雑で面倒になる可能性があります。Verified Accessはこの複雑さを解決します。従来は、開発者がアイデンティティサービスと統合し、ネットワークチームがVPNポリシーを管理し、ITチームがデバイスのコンプライアンス条件を決定するといった具合でした。これにより、少なくとも3つの異なるチームが管理する3セットのポリシーが生まれ、新しいアプリケーションの展開やポリシーの変更に時間がかかっていました。
Verified Accessを使用すると、すべてのアプリケーションに対して単一のゲートウェイを持つことができます。セキュリティ管理者は、誰がどのような条件下でアプリケーションにアクセスできるかを決定する単一のポリシーセットを定義します。顧客が新しいアプリケーションを展開したり、ポリシーを変更したりするのに数分しかかからないケースを見てきました。AVAの背後に新しいアプリケーションを置き、ポリシーを変更し、短時間でユーザーとスタッフが使用できるようにすることができます。
Verified Accessについて詳しく見てみましょう。ユーザーがラップトップを開いてブラウザにアプリケーションのウェブドメイン名を入力すると、すべてのHTTPリクエストがこのVerified Accessゲートウェイに到達します。ここでポリシーを作成でき、アイデンティティやデバイスの状態を含む第三者プロバイダーからデータを取得します。そのデータとポリシーを使用して、ユーザーがアプリケーションに接続できるかどうかを決定します。ポリシーが許可する場合、ユーザーは接続でき、リクエストをアプリケーションにルーティングします。
これらのポリシーは、先ほど説明したように細かく設定できます。例えば、すべての従業員がIT Help Deskにアクセスできるが、財務アプリケーションにアクセスするには、ユーザーが財務チームに所属し、マルウェア対策が実行されているコンプライアンスに準拠したデバイスを持ち、特定のOSバージョンを使用している必要があるといった具合です。そのような条件を満たした場合のみ、アプリケーションにアクセスできます。二つ目は、先ほど話した監査基準です。Verified Accessは、許可されたものも拒否されたものも、すべてのアプリケーションリクエストを記録します。これは顧客にとって非常に価値があります。なぜなら、その情報を使用してトラブルシューティングを行ったり、コンプライアンスチェックを実施したり、監査を行ったり、セキュリティインシデントを調査したりすることができるからです。
三つ目は、Verified Accessがオープンなエコシステムの構築を目指していることです。私たちは、サードパーティのプロバイダー、アイデンティティプロバイダー、デバイス状態プロバイダーと統合しているので、ゼロトラストアーキテクチャに移行する際に、既存のセキュリティやITサービスを変更する必要はありません。ゼロトラストアーキテクチャへの移行をできるだけシンプルにしたいと考えています。 パートナーについて言えば、こちらがパートナー一覧です。アイデンティティパートナー、デバイスパートナー、そしてこれらのログを消費して豊富な洞察を提供するパートナーがいることがわかります。私たちは常にこのパートナーエコシステムを拡大する努力をしています。これにより、Verified Accessに移行する際に何も変更する必要がないようにしています。ここにリストされていないサービスがあり、そのパートナーと話をしてほしい場合は、喜んで対応します。お知らせいただければ、彼らと話をしてオンボーディングすることができます。
簡単に管理できるという話をしましたが、具体的に見ていきましょう。まず最初に、セキュリティ管理者やネットワーク管理者、つまり中央の管理チームがVerified Accessインスタンスを作成します。このVerified Accessは、異なるチーム、異なる開発者、異なるVPC、そして異なるアカウントで管理されているすべてのアプリケーションに対して機能します。次に、Identity ProviderとDevice Management Providerに接続します。そして、開発者の協力を得て、アプリケーションをVerified Accessに組み込み、ポリシーを作成します。ポリシーを作成すれば、そのアプリケーションはすべてのユーザーが利用できるようになります。何千人もの従業員全員が、単にDNS名やドメイン名を入力するだけでアプリケーションにアクセスでき、ポリシーがアクセスを許可すべきかどうかを判断します。
では、Verified Accessにアプリケーションを追加する方法を見てみましょう。先ほど説明したように、これらのアプリケーションはVPC内にあります。このVPCは開発者が所有し、別のアカウントにあります。これらのアプリケーションは常にApplication Load BalancerやNetwork Load Balancerなどのロードバランサーの前面に配置されています。場合によっては、Elastic Network Interfaceだけのこともあります。Verified Accessは共有可能なので、Resource Access Manager (RAM)によって共有されます。セキュリティ管理者がこれを開発者アカウントと共有し、開発者はALBやNLBをVerified Accessに組み込むことができます。
組み込みが完了すると、Verified AccessはユーザーのリクエストがルーティングされるエンドポイントのDNS名を提供します。管理者の立場からすると、その名前を見て、エンドポイントのドメイン名をアプリケーションのドメイン名にマッピングするだけです。これにより、ユーザーや従業員は異なるサイトを見る必要がありません。ブラウザでは、従来通りwww.myapplicationexample.comと入力するだけで、すべてのアプリケーションがここにルーティングされます。Verified Accessが行うもう一つのことは、エンドポイントからアプリケーションのVPCにハイパープレーンENIをドロップすることです。このハイパープレーンENIはポイントツーポイントの接続サービスで、完全に簡単なテナンシーです。管理者の立場からすると、エンドポイントとアプリケーションを接続するためのバックエンドでの接続作業は必要ありません。私たちがそれを処理します。ユーザーがアクセスできる条件のポリシーを作成するだけです。
AWS Verified Accessの最新機能と統合パートナー
よくお客様から質問されるのが、「アプリケーションごとにポリシーを作成できる柔軟性は良いですね。でも、何千ものアプリケーションがあるのに、本当に何千ものポリシーを作成する必要があるのでしょうか？」
もっと簡単に管理する方法はないのでしょうか？」はい、あります。アプリケーションをグループ化することができます。多くの場合、アプリケーションには似たようなアクセス基準やセキュリティ要件があります。例えば、すべての生産性アプリケーションには似たような基準があり、ITアプリケーションや財務アプリケーションにはそれぞれ独自の基準があります。そこで、それらをグループ化し、グループ全体に対して1つのポリシーを作成します。これをグループポリシーと呼びます。
すべてのアプリケーションはこのグループポリシーを継承します。 場合によっては、より厳格な制御が必要なアプリケーションがあるかもしれません。同じグループに属していても、少し高いハードルが必要な場合です。そのような場合、オプションでアプリケーションごとのポリシーを付加することができます。リクエストが来ると、AWS Verified Accessはまずグループポリシーを実行し、その後アプリケーションごとのポリシーがある場合はそれを実行します。両方のポリシーが承認した場合、そのリクエストをアプリケーションに接続します。
このサービスは昨年のAWS re:Inventで発表しましたが、1年以内にお客様のフィードバックに基づいて多くの機能をリリースしました。これは、この分野への我々のコミットメントと、お客様と協力してこの領域でイノベーションを起こしていることを示しています。まず最初に行ったのは、AWS WAFとの統合です。お客様から、ゼロトラストの細かいポリシーと強力な境界防御を組み合わせたいという要望があったからです。これにより、強力な境界防御を構築し、SQLインジェクションやマルウェアなどの広範なインターネットの脅威をフィルタリングできるようになりました。WebACLをAWS Verified Accessに割り当てるか関連付けるだけで、そのエンドポイントに来るすべてのトラフィックがこのWebACLを通してフィルタリングされます。
次に行ったのは、AWS Verified Accessが受け取るアイデンティティコンテキストを渡してほしいというお客様の要望に応えることでした。これには、ユーザーがIT部門か財務部門かといった情報や、メールアドレス、エイリアス、その他の詳細が含まれます。主な理由は、アプリをカスタマイズしたいということでした。例えば、企業の社員名簿を開くと、それがあなた用にカスタマイズされています。彼らはそのアイデンティティ情報を使ってアプリをカスタマイズしたかったのです。彼らの観点からすると、アイデンティティシステムと統合する必要がないので、1つの統合を省略でき、AWS Verified Accessからのトークンを消費するだけで済みます。
もう1つのユースケースは、セキュリティコンテキストとして使用できることです。このHTTPヘッダーはAWS Verified Accessによって署名されているので、アプリケーションが署名されたヘッダーを受け取らない場合、そのHTTPリクエストは別の場所から来たことを意味します。その場合、AWS Verified Accessによって検証されていないため、HTTPリクエストを破棄することができます。さて、3つ目にお客様が言ったのは、ユーザーごとの細かいポリシーは非常に強力だが、初期段階では、ポリシーを書いたり作成したりする際に、トラブルシューティングが容易なものが欲しいということでした。
そこで、我々は拡張ログと呼ばれる機能を考案しました。この機能を有効にすると、アイデンティティチーム、アイデンティティサービス、またはデバイス管理サービスから来るすべてのリクエストをログに記録し、それをアクセス記録と共に保持します。トラブルシューティングが必要な場合、アイデンティティチームやデバイス管理チームとオフラインで作業する必要はありません。直接ログに行き、AWS Verified Accessが受け取ったデータ、シグナル、クレームを確認し、その情報を使ってポリシーを三角測量することができます。
さらに一歩進んで、先週、ポリシーアシスタント機能をリリースしました。これは、先ほどお見せした拡張ログ機能を基にしています。 これはかなりクールな機能で、グラフィカルな方法でトラブルシューティングができます。例えば、私がITチームに「先週アクセスできたアプリケーションにアクセスできなくなった」と言ったとします。ITチームはこのポリシーアシスタントコンソールに来て、私のユーザー名を入力し、このフィルターに記入して、「Shovanがこの特定のアプリケーションに対して最後にアクセスを拒否された記録を見たい」と言えば、AWS Verified Accessがこの情報を引き出します。
左側には、ポリシー評価に使用された私のアイデンティティとデバイスの状態から受け取ったすべてのクレームが表示されます。右側には実際のポリシーが表示されます。ShovanがHRフロントデスクに所属していて、ポリシーではHRフロントデスクにアクセスを許可すべきだと書かれているので、正常に機能していることがわかります。ここでポリシーの変更をしたい場合は、新しいポリシーを入力できます。これはすべてオフラインシミュレーションで、その効果をシミュレートできます。例えば、ShovanはCrowdStrikeの準拠デバイスも持っているべきだと言っているとします。ポリシーをシミュレートし、テストして、データに基づいてアクセスが許可されるか拒否されるかの効果を確認できます。
すべてが問題なく、 満足し、繰り返し確認して納得したら、そのポリシーをチェックインするだけです。一部の顧客からは、ポリシー作成にかかる時間が数日から15分か20分程度に短縮されたと言われており、その意味でかなり強力です。
また、オープンなエコシステムを構築したいと考えていたので、 デバイス管理パートナーのオンボーディングプロセスを簡素化しました。アイデンティティパートナーのオンボーディングは、SAMLやOIDCベースの標準ベースだったため、かなり簡単でした。今回、デバイス管理パートナー向けのプロセスを簡素化し、わずか1週間でオンボーディングできるようにしました。この新しいプロセスで、JumpCloudをオンボーディングしました。これで、デバイス分野では3番目のパートナーとなります。デバイス側では、すでにJAMFとCrowdStrikeがパートナーとなっています。
JumpCloudがどのように機能するかを説明しますと：JAMFやCrowdStrikeなど、すべてのパートナーは、 デバイスのセキュリティを管理するエージェントをデバイス上で実行しています。AWS Verified Accessにはブラウザ拡張機能があり、パートナーのエージェントと通信して情報を取得し、HTTPヘッダーにパックしてAWS Verified Accessに送信し、アクセスを検証します。JumpCloudの場合、すでにブラウザ拡張機能を持っているので、 私たちのロジックを彼らのブラウザ拡張機能に組み込み、HTTPヘッダーをパックしてAWS Verified Accessに送信しています。
JumpCloudのお客様にとって良いニュースは、ブラウザ拡張機能を変更する必要がないということです。引き続き現在のブラウザ拡張機能をお使いいただけます。また、彼らのブラウザ拡張機能はモバイルデバイスでも動作するので、JumpCloudのお客様はデスクトップからもモバイルデバイスからもHTTPアプリケーションにアクセスできるようになりました。
では、ここからはJuanに引き継ぎます。 彼は私たちのお客様の一人で、Verified Accessに関する彼らのユースケースと視点についてお話しいただきます。Juanはサイバーセキュリティの専門家なので、彼のお話を楽しみにしています。
Avalon Healthcare SolutionsにおけるAWS Verified Accessの実装事例
ありがとうございます。皆さん、こんにちは。Juan Suarezと申します。Avalon Healthcare Solutionsの Senior Information Security Analyst を務めています。Avalon Healthcare Solutionsは、デジタル化された検査結果を使用して予測分析を行うことで、健康保険プランと検査機関のケア改善を支援しています。また、リアルタイムで検査ベースのポリシーを適用することでコスト削減も実現しています。 私たちには30社以上の顧客がおり、その数は増え続けています。現在、3,800万人以上のメンバーを管理しています。
ご覧の通り、健康保険プランの顧客は電子健康記録を私たちに信頼して預けています。この信頼を得るために、私たちは年間を通してHITRUST認証を維持しています。これは非常に厳しい監査で、700以上のコントロールがあります。監査を経験したことがある方はご存じかもしれませんが、非常に厳しく、私たちのプロセスと手順、技術的コントロール、管理的コントロールが審査されます。 Avalonは、ポリシーを適用することで適切な検査を提供するユニークな立場にあります。私たちはこれらのデジタル化された検査結果のデータを収集する能力と、これらの検査結果から情報を抽出する能力を持っており、最終的には顧客が適切なケアを提供するのを支援しています。
このスライドを作成していたとき、私たちのEnterprise Cloud Technology PresidentであるEric Ellis氏に、 なぜゼロトラストがAvalonにとってそれほど重要なのかを尋ねました。彼は次のように答えました。「私たちの最も重要な目標の1つは、ゼロトラストの原則を揺るぎなく維持しながら、エンドユーザーエクスペリエンスを最適化することです。」この言葉は私にとって非常に意味があります。なぜなら、ここで彼はゼロトラストとエンドユーザーエクスペリエンスという2つの非常に重要なポイントを強調しているからです。
リモート接続のソリューションを探していたとき、私たちはこれらのリモート活動のセキュリティ設定を検討しました。このソリューションでゼロトラストのポリシーと原則を適用できるでしょうか？このソリューションを監査できるでしょうか？Avalonのゼロトラストに関するHITRUST要件をどこまで細かく設定できるでしょうか？同時に、ユーザー体験も考慮しました。結局のところ、ユーザーがユーザーらしく振る舞えるようにしたいのです。また、実装にかかる時間も考慮しました。時間とリソースが限られている中で、インフラを再設計したり、DMZを作成したり、アクセス制御リストやセキュリティグループを作成したりすると、既存の安全な環境に手を加えることで、システムの設定ミスのリスクが生じる可能性があることも認識していました。
AWS Verified Access (AVA)を実装する前の私たちのインフラはこのようでした。これは従来の経験で、ユーザーのタイプによって異なりました。Webアプリケーションや開発者向けの下位環境アプリケーションにアクセスするには、VPNクライアントを使用していました。ネットワークエンジニアの場合は、VPNにログインしてファイアウォールを管理していました。特定のユースケースとして、私たちのTableauサーバーには多くのPHIデータや検査結果が含まれており、顧客向けに多くのレポートを作成しています。ゼロトラスト原則を適用しているため、これらのシステムは環境内で非常に孤立していることがあります。ご覧のように、ユーザーはこのリソースにアクセスするためにワークスペースにログインする必要がありました。
これにより、エンドユーザーの体験が非常に複雑になりました。Avalonに参加する際、一部のユーザーは「VPNが必要ですか？ワークスペースが必要ですか？環境内の特定のリソースにアクセスするためにジャンプボックスが必要ですか？」と尋ねることがありました。これはまた、エンジニアにとって運用上の負担も生み出しました。VPNクライアントを更新し、ワークスペースが更新されていることを確認し、ワークスペースに脆弱性がないことを確認する必要がありました。これにより多くのオーバーヘッド作業が発生しました。Tableauサーバーが環境内で非常に孤立していたため、外部ユーザーにアクセスを提供する際に課題がありました。リモートの顧客とレポートやデータを共有する必要があります。DMZやインフラを再設計せずに、このアプリケーションへのアクセスをどのように提供すればよいでしょうか？
ここでAVAが私たちにとってのソリューションとなりました。今では、エンドユーザーはただコンピューターを開き、ブラウザを起動し、必要なURLに移動するだけです。VPNにログインしたり、ジャンプボックスにアクセスしたり、ワークスペースに入ったりする必要はありません。非常にシンプルな操作です。クラウドチームがAWSでポリシーを適用し作成し、ユーザーのIDもサードパーティのIDプロバイダーであるOktaに存在します。IAMチームはクラウドチームと協力して、ゼロトラスト原則を維持しています。外部ユーザーのIDがすでにOktaに存在しているため、サーバーを移動したり新しいインフラやDMZを作成したりすることなく、サーバーとそこにあるすべてのレポートのデータへのアクセスを提供することができます。
これが、エンドユーザーがTableauサーバーにアクセスしようとする際の現在のユースケースです。ユーザーがURLにアクセスすると、AVAがインフラチームが構築した多くのポリシーを処理します。ユーザーは認証されているか？ユーザーは承認されているか？AVAはユーザーをIDPにリダイレクトし、ユーザーが認証を行い、MFAを入力し、正しいセキュリティグループに属しているか、正しいプロファイル属性を持っているか、指定されたドメインからアクセスしているかを確認します。すべてが問題なければ、ブラウザはユーザーをAVAにリダイレクトし、サーバーは元の場所に残ったまま、ACLとIAMの側面でゼロトラストポリシーが適用されます。
そこで終わりではありません。Tableau serverもOpenID Connectをサポートしているので、エンドユーザーにシングルサインオン体験を提供したいと考えました。 この設定では、ユーザーのブラウザをOktaに戻し、シングルサインオン体験のための認証と認可を確実に行います。ここで強調したいのは、Tableau serverとAVAの両方が同じOktaのクライアントを指していますが、認可コードとJWTトークンを復号化するための固有のシークレットを持っているということです。
私たちはAVAが大好きで、 また多くのシステムがデータセンターで分断されているため、AVAの実装インフラにSecurity Information and Event Management（SIEM）技術を導入する予定です。非常に分断されているFTP UIがあり、これらをAVAの前に置きたいと考えています。また、チケットシステムもあります。これらは、スキャナーやハッカーが悪用して潜在的にインシデント対応を引き起こす可能性のあるオープンなウェブ上に置く必要はありません。私の名前はJuanで、Avalon Healthcare Solutionsの者です。この特定のユースケースについてお聞きいただき、ありがとうございました。
セッションのまとめと質疑応答の案内
Juan、Avalonのユースケースを詳しく説明してくれてありがとう。エンドユーザーの体験を簡素化しながらセキュリティを向上させた興味深い例でした。まとめると、HTTPアクセス用のAVAについて話し、 次にSSHとRDPアクセス用のEC2 Instance Connectがあり、 最後にネットワークアクセス用のAWS Client VPNがあります。私たちは異なるニーズに対して異なるサービスを構築しているので、これらのサービスをぜひ探索してみてください。質問がある場合は、Tom、Juan、そして私が回答できます。このトークを楽しんで新しいことを学んだ方は、アンケートにご協力いただき、フィードバックをお寄せください。どうもありがとうございました。
※ こちらの記事は Amazon Bedrock を様々なタスクで利用することで全て自動で作成しています。
※ どこかの機会で記事作成の試行錯誤についても記事化する予定ですが、直近技術的な部分でご興味がある場合はTwitterの方にDMください。
Discussion