Amazon Web Services ブログ
ゼロトラストアーキテクチャ: AWS の視点
本投稿は、AWS の CISO オフィスのディレクターを務める Mark Ryland と AWS Identity の専門家である Quit Van Deman による寄稿を翻訳したものです。
アマゾン ウェブ サービス（AWS）の使命は、安全なシステムの構築、デプロイ、迅速な反復処理を行う際に行う作業がより少なくなるようにお客様に代わってイノベーションを行うことです。お客様からはセキュリティの観点について以下のような質問をよくいただきます、 “システムとデータの機密性、完全性、可用性を適切なレベルに確保し、スピードと俊敏性を向上させるのに最適なパターンは何ですか？“。ゼロトラスト・アーキテクチャまたはゼロトラスト・ネットワーキングのカテゴリーに該当するセキュリティアーキテクチャパターンが、これらの質問にどのように答えることができるか、お客様から具体的な質問を受ける機会が増えてきました。
このブログでは、ゼロトラストの名前を使用する技術への関心の高まりや、ゼロトラストに関する様々なコンセプトやモデルへの関心が高まっていることを踏まえ、私たちの視点をお伝えしたいと考えています。ゼロトラストの定義と指針を共有し、その名前の裏にある大きなサブドメインについて見ていきます。また、AWS が初期の頃から今日言われているゼロトラストの原則をどのように AWS クラウドの基本機能に取り入れたか、また最近の多くの開発ではどのように取り組んでいるかについても説明します。最後に、AWS が、お客様にとって最重要であるセキュリティ目標に焦点を当てて、ゼロトラストへの取り組みをどのように支援できるかを見ていきます。技術的アプローチにはトレンドがありますが、基本となるセキュリティ目標は時間の経過とともに不変となる傾向があります（これらについての概要は、AWSのWell-Architected フレームワークの設計原則を参照して下さい）。
ゼロトラストの定義と指針
一般的な定義から始めましょう。ゼロトラストは、従来のネットワーク制御やネットワーク境界のみに依存しない、または根本的に依存しない、デジタル資産に関するセキュリティコントロールを提供することにフォーカスした概念モデルおよびそれに関連したメカニズムのセットです。ゼロトラストのゼロとは基本的に信頼を減らしていくことを意味しており、究極的にはゼロになるかもしれません。（対象を人として考えるかソフトウェアコンポーネントと考えるかにかかわらず） トラスト（信頼）は歴史的には、従来のネットワーク内のアクターのいる場所によって確立されてきました。ゼロトラストの世界では、ネットワークを中心とした信頼モデルは、他の技術によって拡張または置き換えられます。ここでいう他の技術とは、一般的にはアイデンティティを中心としたコントロールと言い換えることができます。これにより、以前と同等あるいはより優れたセキュリティメカニズムが提供されます。より優れたセキュリティメカニズムとは、全体的なセキュリティの度合いが同等であっても、ユーザビリティや柔軟性が向上する場合を含む広義なものとご理解下さい。続いて、ゼロトラストについて、より詳細かつ実現可能なアプローチを二つの側面から考えてみましょう。
最初の側面はネットワークに関する課題です。すべてのネットワークパケットがすべてのホストまたはエンドポイント間で流れることを許可し、ネットワーク層の上にすべてのセキュリティコントロールを実装することで 、ゼロトラストを達成しますか？ または、システムをより小さな論理コンポーネントに分割し、より厳しいネットワーク・セグメントまたはパケット・レベルの制御（いわゆるマイクロ・セグメントまたはマイクロペリメータ）を実装しますか？ 新しいタイプの信頼の境界を強制するゲートウェイまたはプロキシ技術を追加しますか？ネットワークの分離には引き続き VPN テクノロジーを使用しますが、ネットワーク境界が設置され、必要に応じてセッションが切断されていることにユーザーが気付かないように、よりダイナミックかつユーザーエクスペリエンスから隠された構成となっているのですか？または、これらの技術のいくつかの組み合わせでしょうか？
もう一つの側面は、アイデンティティとアクセス管理に関する課題です。 PC 、タブレット、携帯電話でウェブアプリケーションにアクセスしようとしている人間と対象として話していますか？ それとも、マシン間通信、ソフトウェア間の通信におけるすべての要求が、何らかの技術を使用して認証・認可されることについて話していますか？あるいは、我々はこれら二つのいくつかの組み合わせを考えているかもしれません。たとえば、認証の強度、デバイスタイプ、所有権、対策状況のアセスメント結果、健全性、ネットワークの場所など、ユーザーの状況に関する特定のセキュリティ関連プロパティまたは属性が、ユーザが対話しているソフトウェアシステムに伝播され、ダイナミックにアクセス権限が変更される場合です。
このように、ゼロトラストをより詳しく見始めると、すぐに混乱してしまうかもしれません。なぜなら、多くの異なるトピックや概念が暗黙的に含まれているからです。その一方で、より容易に、柔軟で安全なソフトウェアシステムを構築する機会も明確に示されています。混乱と機会の両方から私達を導いてくれるのに役立つ 、いくつかの原則は何でしょうか。
AWSにおけるゼロトラストの第一の指針は、概念モデルによってネットワークの場所への依存度は低下するものの、ネットワーク制御と境界の役割は、セキュリティアーキテクチャ全体にとって引き続き重要であるということです。言い換えれば、最高のセキュリティは、アイデンティティ中心とネットワーク中心のツールの二者択一ではなく、両方を効果的に組み合わせて使用することによって得られます。アイデンティティ中心のコントロール、例えば AWS API エンドポイントとの対話に使用される AWS SigV4 リクエスト署名プロセスは、署名されたAPIリクエストを個別に、かつ全てに対して認証および認可、非常にきめ細かなアクセス制御を提供します。一方で、ネットワーク中心のツール、 Amazon Virtual Private Cloud (Amazon VPC) 、セキュリティグループ、 AWS PrivateLink 、 VPC エンドポイント、は、理解しやすく利用がが簡単で、システムから不要なノイズをフィルタリングし、アイデンティティ中心のコントロールを運用する上で優れたガードレールを提供します。理想的には、これら二種類のコントロールは共存するだけでなく、互いに認識し強化する必要があります。たとえば、 VPC エンドポイントは、論理ネットワーク境界にアイデンティティ中心のルールを記述し制御できるポリシーをアタッチする機能を提供します。この場合、プライベートネットワークは Amazon VPC から近くの AWS サービスエンドポイントに向かう途中までで閉じます。
AWS におけるゼロトラストの第二の指針は、ゼロトラストが様々な文脈で異なる意味を持つ可能性があるということです。ゼロトラストの関するものがわかりにくい主要な理由の一つは、この用語が、ネットワークの場所または境界によりセキュリティの課題を低減させるという基本的な技術的コンセプトにおいて、多くの異なるユースケースを含むことです。何を組織のために達成しようとしているかは、ユースケースにより大きく異なります。前述のように、ゼロトラストの目標の一般的な例は、従業員の俊敏性（訳注:便利なサービスを迅速にとりいれて業務効率を改善していく等）とモビリティの確保（訳注：ブラウザとモバイルアプリ、インターネットを使用してビジネスシステムとアプリケーションにアクセスすること）から、新しいクラウドベースのアプリケーション内部で慎重にセグメント化されたマイクロサービスアーキテクチャの作成に至るまで、多岐にわたります。私たちが解決しようとしている特定の問題に焦点を当て、新しい視点と新しいツールでその問題に取り組むことで、セキュリティ上の課題に対する新しいアプローチが本当にゼロトラストの概念の適用なのか、もしくはゼロトラストの概念のどの程度の適用なのかといった、価値の低い議論に惑わされることを避けることができます。
第三の指針は、ゼロトラストの概念は、保護対象のシステムとデータの組織的価値にあわせて適用する必要があるということです。ゼロトラストの概念モデルと関連するメカニズムの適用は、時間の経過とともに防御の深さを向上させ、クラウドのもつ可視性とソフトウェアによる定義の向上を通じて、すでに確立したセキュリティコントロールをより良くしていきます。うまく適用すると、ゼロトラストの原則は、特に重要なワークロードに対して、セキュリティの基準を大幅に高めることができます。しかし、ゼロトラストの手法は、原則通り厳格に適用されてしまうと、アップグレードされたシステムや新しいシステムへの従来の技術の取り込みを制限し、労力に見合ったメリットがない組織に対して過度に負担をかけ、イノベーションを失速させる事になります。多くのビジネスシステムでは、ネットワーク制御とネットワーク境界は引き続き重要であり、しばらくの間、おそらくは永遠に、一般的に適切なコントロールであり続けるでしょう。ゼロトラストの概念は置き換えではなく、既存のセキュリティコントロールや概念に追加するものと考えるのが最善であると信じています。
現在の AWS におけるゼロトラストの原則と機能の例
AWS におけるゼロトラストの最も顕著な例は、数百万のお客様がさまざまなパブリックネットワークとプライベートネットワークを介してAWS マネジメントコンソールを使用する、または AWS API を安全な方法で呼び出すことで、日々 AWS とコミュニケーションしていることが挙げられます。コンソール、AWS コマンドラインインターフェイス（ AWS CLI ）または AWS API が書き込まれたソフトウェアのいずれから呼び出されたにかかわらず、最終的にこれらのコミュニケーションはすべて、インターネットから到達可能なエンドポイントを持つ一連の Web サービスに到達します。 AWS API インフラストラクチャのセキュリティは、ネットワークの到達可能性には全く依存していません。これらの署名付き API リクエストのそれぞれが、グローバルで毎秒数百万のリクエストに対して毎秒数百万のレートで認証および認可が行われています。お客様は、 AWS Signature v4 署名プロセスによって強化された トランスポート層セキュリティ（ TLS ）プロトコルの暗号強度は、基盤として通過するネットワークの信頼性がどうあれ、リクエストが適切に保護されることを知っているので、安心してリクエストを行うことができます。興味深いことに、クラウドベースの API の使用は、ゼロトラストの議論で言及されることはほとんどありません。これは AWS が最初から API を保護するため、このアプローチで先行していたためであり、おそらく、すべてのクラウドセキュリティについての議論の前提的なものとなっているからと想定されます。
同様に、おそらくよく理解されていないかもしれませんが、個々の AWS サービスがサービス機能の運用と提供のために相互呼び出しを行う必要がある場合も、お客様が使用するのと同じメカニズムによって行われています。これは、サービスにリンクされたロールの形式でこの動作を確認できます。たとえば、 AWS Auto Scaling が Amazon Elastic Compute Cloud（Amazon EC2） API を呼び出して、お客様のアカウント側で EC2 インスタンスを作成または終了する必要があると判断した場合、 AWS Auto Scaling サービスは、お客様がアカウントに設定した、サービスにリンクされたロールを AssumeRole し、結果として AWS から一時的な認証情報を受け取ります。この認証情報を使用して SigV4 プロセスを使用して適切な EC2 API へのリクエストに署名します。受信側では、 AWS アイデンティティとアクセス管理（ IAM ） が EC2への着信呼び出しの認証および認可を行います。 言い換えれば、これらは両方とも AWS サービスですが、 AWS Auto Scaling と EC2 には固有の信頼関係やネットワークなどが存在せず、二つのサービス間のセキュリティモデルの基礎として、お客様に代わって運用される強力なアイデンティティ中心のコントロールを使用しています。 お客様は、あるサービスに付与している権限と、それらの権限の使用に関する AWS CloudTrail の記録の両方を、完全に可視化することができます。
AWS ポートフォリオにおけるゼロトラスト機能についての他の優れた例として、IoT サービスがあります。AWS IoT Core をリリースした際に、当時の一般的な業界標準に加え、IoTデバイスをサービスエンドポイントに接続する際にTLS ネットワーク暗号化と最新のクライアント認証（証明書ベースのMutual TLS を含む）を常に要求するという戦略的な決定を下しました。その後、 FreeRTOS にTLSサポートが追加され、従来は機能しないと思われていた小型CPUと小型メモリデバイスのクラス全体に対してモダンで安全な通信が可能になりました。AWS IoT Greengrass では、ローカルネットワークがあることを前提とし、リモートゲートウェイを使用することで、既存のセキュリティのないデバイスを操作する方法を開発しました。また、AWS Lambda 関数を実行してセキュリティを検証し、クラウドへの安全なプロキシー機能を提供することもできます。これらの例では、AWS のセキュリティベースラインに準拠することにより、ゼロトラストの主要な基本コンポーネントが、従来はオープンインターネットを介した膨大な量の認証されておらず暗号化されていないネットワークメッセージングが標準であったテクノロジードメインに何をもたらしたのかをハイライトしています。
AWS によるゼロトラストジャーニーへの支援
お客様のゼロトラストへの移行を支援するために、ゼロトラストを構築する際にコアとして使える AWS クラウドで利用可能なアイデンティティ管理機能とネットワーキング機能を標準機能として提供しています。AWS サービスは、シンプルな API 呼び出しによってこの機能を提供しており、インフラストラクチャや追加のソフトウェアコンポーネントを構築、保守、運用する必要はありません。話をわかりやすくするために、次の三つの異なるユースケースを背景に、これらの機能について検討します。
- コンポーネント間の特定のフローを許可し、不要な水平方向のネットワークアクティビティを排除します。
- 社内アプリケーションへのスムースなアクセスを可能にします。
- IoT などのデジタルトランスフォーメーションプロジェクトの保護
最初のユースケースでは、主にマシン間の通信に重点を置き、コンポーネント間の特定のフローを許可して、水平方向へのネットワークアクティビティに起因するリスクを排除します。言い換えると、二つのコンポーネントがネットワーク経由で相互に通信する必要がない場合は、これらのシステムが同じネットワークまたはネットワークセグメント内に存在していても、それらのコンポーネントは通信できないはずです。これにより、接続されたシステム間の接点が大幅に減少し、特に機密データにつながる不要な経路が排除されます。このユースケースでは、初期の頃から Amazon EC2 の一部として提供しているセキュリティグループ（ EC2 インスタンスの仮想 FW 機能）から議論を開始する必要があります。セキュリティグループは、南北のトラフィック（データセンターと外部との通信）と東西のトラフィック（データセンター内のデバイス間の通信）の両方に対して、高度にダイナミックなソフトウェア定義ネットワーク（ Software Defined Network ）のマイクロペリメター（決めの細かい境界）を提供します。セキュリティグループの割り当ては、リソースが出入りする際に自動的に行われ、一つのセキュリティグループのルールは、同じ Amazon VPC 内または、同じリージョンまたは異なるリージョン内のより大きなピアネットワーク間で ID によって互いを参照できます。これらのプロパティを使用すると、セキュリティグループは、関連するプロパティからグループメンバーシップが特定のネットワークフローを許可するかどうかを決定する一種のアイデンティティ・システムとして機能します。これにより、グループのメンバーシップが増減する際、ルールを最新の状態に保つという運用上の負担を伴わずに、非常に細かいルールを作成できます。同様に、PrivateLink は、マイクロペリメーターとマイクロセグメンテーションとの間に非常に有用なビルディングブロックを提供します。PrivateLink を使用することにより、負荷分散されたエンドポイントを二つの VPC 間の狭い一方向ゲートウェイとして公開できます。また、ゲートウェイにアクセスできるユーザーや受信パケットが到達できる場所をアイデンティティ ベースの制御により決定することができます。反対方向にネットワーク接続を開始することは許可されておらず、VPC 間のルートも必要ありません。現在、何千ものお客様が PrivateLink をセキュアなマイクロサービスアーキテクチャの基本的なビルディングブロックとして使用しています。また、サプライヤからの PaaS および SaaS サービスへのセキュアでプライベートアクセスも実現しています。
AWS API についての議論に戻ると、API リクエストの認証と認可のための AWS SigV4 署名プロセスは、もはや AWS サービスだけのためではありません。Amazon API Gateway サービスを使用すると、AWS SigV4 と同様の強化されたインターフェイスアプローチを実現できます。これによりソフトウェアインターフェイスをオープンなインターネット上で安全に使用することができるようになります。API Gateway は、分散型サービス拒否攻撃 ( DDoS ) 保護、レート制限、および複数の認証オプションの1つとして、AWS IAM のサポートを提供します。AWS IAM 認証を選択した場合は、IAM ポリシー言語のすべての記述機能を使用して、API を呼び出すことができるユーザーとその呼び出し元を定義する標準的な IAM ポリシーを作成できます。呼び出し元は、AWS 認証情報を使用してリクエストに署名します。これは通常、コンピューティングリソースにアタッチされた IAM ロールの形式で提供され、IAM はこれらのポリシーに従って API へのすべての呼び出しの一つ一つを認証し、認可します。API は、一つのステップで、AWS API を保護する、大規模にスケールされた、かつ極めて高性能でグローバルに利用可能な IAM サービスの背後に保護されます。管理やメンテナンスは不要です。API Gateway フロントエンドからバックエンド実装への呼び出しは、Mutual TLS によって保護されるため、API Gateway のみがバックエンド実装を呼び出すことができます。この強力なアイデンティティ中心のコントロールには、二つの選択肢があります。バックエンド実装をパブリックネットワーク上に安全に配置する、または、VPC との統合モデルの追加、すなわち VPC 内部で実行されているバックエンド実装への API Gateway 呼び出しがアイデンティティ中心のコントロール（ Mutual TLS ）と、ネットワーク中心のコントロール （ API Gateway からコードへのプライベート接続)によって保護されるモデルです。これらの機能の組み合わせによって達成されるセキュリティは、おそらくクラウドでしか実現できません。東西のトラフィックの懸念に関する議論は過大に感じられ、過去の制約に基づくものとなったように見えるでしょう。
二番目のユースケースは、社員の社内アプリケーションへの摩擦のないアクセスを可能にし、セキュリティを損なうことなく、従業員のモビリティを向上させることです。従来、これらのアプリケーションは、強力な VPN のフロントドアの背後に存在していました。しかし、VPN は拡張にコストがかかり、現代の従業員が必要とするさまざまなモバイルデバイスと必ずしも互換性があるとは限りません。このユースケースの目的は、VPN ベースのフロントドアを排除できるように、個々のアプリケーションの保護を適切にすることです。これを達成するために、AWS のお客様は業界、リスク許容度、開発者の成熟度、その他の要因に応じて、幅広い技術ソリューションを選択したいと述べています。その一端には、 Desktop As a sevice – Amazon Workspaces を好むお客様も多いですし、または Appilcation As a service – Amazon AppStream 2.0 – ゼロトラストに強力で柔軟なドット単位のプロキシーのアプローチを提供するモデルを好むお客様も多数います。従来のセキュリティ制御はこれらの中間仮想デバイスに適用され、PC 、タブレットまたは HTML5 クライアントを使用するユーザーに対して、インターネット経由で、または必要に応じて追加のネットワーク制御と境界の背後に、仮想化されたデスクトップまたはアプリケーションでアクセスすることで、デスクトップのようなリッチな体験を提供できます。ユーザーの手元にある終端デバイスのセキュリティを心配することはありません。同じように、お客様はモバイルデバイス管理やその他の煩雑で高価なテクノロジーを導入することなく、携帯電話からエンタープライズアプリケーションに安全にアクセスするためのより良い方法を求めています。この要件を満たすために、Amazon WorkLink を立ち上げ、AWS クラウドで複雑なウェブアプリケーションをレンダリングする安全なプロキシサービスを提供しました。Amazon WorkLink は、（インタラクティブ機能のためのごく少量の JavaScript と）画像のみを携帯電話にストリーミングします 。機密性の高い企業データは、モバイルデバイスに保存またはキャッシュされることはありません。
一方で、社内 Web アプリケーションをインターネットに直接接続したいお客様もいらっしゃいます。これらのお客様には、AWS Shield、AWS WAF、Application Load Balancer と OpenID Connect (OIDC) 認証の組み合わせにより、完全に管理されたアイデンティティ対応型のネットワーク保護スタックが提供できます。Shield は、常時起動型の攻撃検出と自動インライン軽減をマネージド型 DDoS 保護サービスとして提供します。これにより、アプリケーションのダウンタイムとレイテンシーを最小限に抑えることができます。AWS WAF はウェブアプリケーションファイアウォールで、AWS や AWS Marketplace で提供されるルールグループおよび独自のカスタムルールを適切に組み合わせることで、インフラストラクチャに到達する前にウェブリクエストを監視および保護することができます。アプリケーションロードバランサーで認証を有効にすることで、（通常の負荷分散機能を超えて）、既存の ID プロバイダー ( IdP ) と直接統合して、ユーザーの認証作業の負荷を軽減し、IdP がもつ既存機能（強力な認証、デバイスのポスチャー評価、条件付きアクセスおよびポリシーの強制）を活用できます。この組み合わせにより、社内のカスタムアプリケーションは SaaS アプリケーションと同じくらい柔軟になります。最新のアイデンティティ標準を採用した共通のセキュリティモデルでアプリケーションポートフォリオを統合しながら、従業員は SaaS と同じくどこでも作業できる柔軟性を享受できます。
三番目のユースケース（ IoT など）のデジタル変革プロジェクトのセキュリティ確保は、最初の二つとは非常に大きく異なります。コネクテッド・カーを考えてみましょう。コネクテッド・カーはモバイルネットワークとインターネットを介して重要な計測ストリームをクラウドベースの分析環境に中継し、処理と洞察を得ます。これらのワークロードは常に従来のエンタープライズネットワークの外部に存在しており、その状況に対応するセキュリティモデルが必要です。AWS IoT サービスファミリは、フリート内のすべてのデバイスに固有のデバイス ID を発行し、これらの ID と関連するアクセス制御ポリシーを使用して、クラウドとの通信方法と対話方法を安全に制御するためのスケーラブルなソリューションを提供します。これらのデバイスのセキュリティは、AWS IoT Device Defender、無線でのソフトウェアアップデート、さらにはオペレーティングシステム全体のアップグレード (現在は FreeRTOS に組み込み済) を使用して簡単に監視および維持でき、長期にわたってデバイスを安全かつセキュアに保つことができます。今日のビジネスにすぐに適用できないかもしれませんが、今後、レイテンシーを最小限に抑え、ユーザーエクスペリエンスを向上させるために、ますます多くの IT ワークロードがエッジに近づくにつれ、このユースケースは普及していくでしょう。
It’s still Day 1
この記事が ゼロトラストについての我々のビジョンを伝えるのに役立ち、基盤となるセキュリティ原則と高度な機能が、AWS クラウドとお客様が当社のサービスを基に構築する環境の両方のセキュリティ水準を向上させるセキュリティモデルを表していると考えてることを強調しました。
Amazon ではお客様とそのニーズを深堀りすることなく、仕事がなされることは決してありません。私たちには構築したい機能がたくさんあり、さらに多くのガイダンスを提供し続けます。創業者のジェフ・ベゾスの言葉でありコアビジョンでもある ”It’s still Day1” を反映して、皆様からのご意見と、一緒にクラウドジャーニーを続けることを楽しみにしています。