Amazon Web Services ブログ

AWS上でどのようにゼロトラストアーキテクチャを考えていくか

2021年7月追記：
AWSにおけるゼロトラストに関するアップデートされた情報は、以下をご参照ください。
https://aws.amazon.com/jp/security/zero-trust/

また、本Blogを詳細にアップデートしたBlog記事もありますので適宜ご参照ください。
「ゼロトラストアーキテクチャ: AWS の視点」
https://aws.amazon.com/jp/blogs/news/zero-trust-architectures-an-aws-perspective/

—————————————————————–

厳しい規制への対応やリスク回避を考慮事項として擁するお客様は、レガシーアプリケーションのリファクタリングや新しいアプリケーションのデプロイに際し、ゼロトラストアーキテクチャに関心を向けることがあります。このブログでは、お客様がお客様のアプリケーションを評価し、ゼロトラストの原則とAmazon Web Services (AWS)を利用して安全でスケーラブルなアーキテクチャを構築するための手助けを行います。

ゼロトラストとは？

ゼロトラストセキュリティとは、アプリケーションのコンポーネントやマイクロサービスが互いに分離しており、どのコンポーネントやマイクロサービスも他のコンポーネントやマイクロサービスを信頼していないというモデルです。これは、あらゆるソースからの入力を潜在的に悪意のあるものとみなすように設計されたセキュリティの考え方です。基礎となる内部ネットワーク・ファブリックを信頼しないことから始まり、さらにすべてのマイクロサービスにおける入力と出力の評価におよびます。加えて、個々のコンポーネント、マイクロサービス、またはアイデンティティの侵害から保護するために、多層防御アプローチを設計することも含まれます。
（訳者注：ゼロトラストは特定の製品やソリューションを指すものではなく多層的なセキュリティ手法を踏まえた概念として、現在アメリカ国立技術標準研究所（NIST）においても、SP800-207（本blog執筆時点においてはドラフト）として定義化が進められています。）

伝統的なネットワークセキュリティの設計は、セキュリティの境界に依拠します。境界内のすべてのものは信頼され、境界外のものは信頼できないものとみなされます。ゼロトラストネットワークは、ビジネスデータや機密リソースへの意図しないアクセスのリスクを低減するために、リアルタイムですべてのアクションとリソースを評価します。

ゼロトラストの原則を用いたAWS上での設計

ゼロトラストアーキテクチャをよりよく理解するために、脅威モデリングにより、従来のアーキテクチャやクラウドネイティブアーキテクチャとを比較してみましょう。脅威モデリングは、ユーザーはすべての潜在的な攻撃の可能性を評価してリスクを定義し、管理策を決定するための試みです。脅威モデルの一つであるSTRIDEでは、以下のようなカテゴリの脅威を特定しています。

ユーザーIDのなりすまし（Spoofing）
データの改ざん（Tempering）
ソースの否認（Repudiation）
情報漏洩（Information Disclosure）
サービスの拒否（Denial of Service）
特権の昇格（Elevation of Privilege）

AWSのベストプラクティスアーキテクチャ

AWSでは、AWS上でWell-Architectedなアプリケーションを設計するための基礎となるツールを提供しています。AWS Well-Architected Frameworkは、AWSのベストプラクティスとワークロードを比較し、安定的かつ効率的なシステムを構築するためのガイダンスを得るための戦略を紹介しています。Well-Architected Frameworkには、セキュリティを含む5つの明確な柱が含まれています。このフレームワークを基に、ゼロトラストをAWSアーキテクチャに適用した例としてWebアプリケーションを考えてみましょう。

従来からのWeb三層アーキテクチャ
図1: Webサイトホスティングの例

表現されているアーキテクチャは、セキュリティを考慮したWell architectedの一例です。システムは、以下のサービスを活用して一般的な攻撃ベクターから保護されています。

  1. Elastic Load Balancing (ELB)/Application Load Balancer (ALB)による負荷分散により、複数のアベイラビリティゾーンとAmazon Elastic Compute Cloud (Amazon EC2) Auto Scalingグループに負荷を分散し、サービスの冗長化と疎結合を実現します。
  2. AWSのSecurity Groupを利用した仮想ファイアウォールでは、インスタンスにセキュリティを移動させ、Webサーバとアプリケーションサーバの両方にステートフルなホストレベルのファイアウォールを提供します。
  3. Amazon Route 53を利用したDNS（Domain Name System）はDNSサービスを提供し、ドメイン管理を簡素化します。
  4. Amazon CloudFrontによるエッジキャッシングにより、顧客へのレイテンシが減少します。
  5.  AWS Web Application Firewall（AWS WAF）とAmazon CloudFrontによるエッジセキュリティは、XSSやSQLインジェクションなどの悪意のあるトラフィックをお客様が定義したルールでフィルタリングします。
  6. AWS Shieldを利用した分散型サービス拒否（DDoS）攻撃対策は、一般的に悪用されるネットワーク層やトランスポート層に対するDDoS攻撃からインフラを自動的に保護します。

ゼロトラストの適用

それではここで先ほど定義したアーキテクチャを再評価してみましょう。各コンポーネントを、大きな信頼されたシステムの一部としてではなく、マイクロサービスとして保護します。例えば、AWS WAFを利用して、SQLインジェクション攻撃による改ざんや情報漏洩からどのように保護するかを評価します。ウェブサイトを利用するお客様は、設計としてはAmazon CloudFrontを経由して静的コンテンツと動的コンテンツの両方にアクセスします。AWS WAFのルールをCloudFrontの配信に適用することは理にかなっていますが、ELB/ALBは、誰かに発見される可能性のあるパブリックIPアドレスを使用することになります。リスク緩和策としては、同じWAFルールをロードバランサーに対して直接適用することが考えられます。

ウェブサーバとアプリケーションサーバ間はどうでしょうか。これらは伝統的に”内部”のコンポーネントと考えられており、それらの間を流れるデータは同じ精査の対象にはなりませんでした。しかし、ゼロトラストモデルでは、すべてのコンポーネントと通信は信頼されていないとみなす必要があります。通信方法によってはAWS WAFは適切なソリューションではないかもしれませんが、別のレイヤーにおけるフィルタリング（ホストベースまたはネットワークベース）を実装して、入力がアプリ層に取り込まれる前に入力の検証を行うことになります。さらに、これら二層間のコマンドの認証および認可は、AWSがAPI署名にAWS Signature Version 4を使用しているのと同様に、継続的に行われることとなります（訳者注：AWSではAPIコマンドの発行に際して、署名により認証情報を付加します）

AWS WAFのルールや入力値の検証（local input validation）は、さまざまな攻撃からの保護に有効です。では、DDoSに対する保護はどうでしょうか。AWS Shieldは最も一般的なボリューメトリック攻撃や枯渇（Exhaustion）攻撃からの保護に有効です。さらに、システムの他の要素からの潜在的な脅威を評価するべきです。上記のベストプラクティスアーキテクチャでは、Webサーバーインスタンスへの一見正常だが意味をなさないリクエストによって、アプリケーションサーバを溢れさせる可能性には対応できません。また、セキュリティグループの設定ミスにも対応できません。これに対しゼロトラストモデルでは次のように設計します。

  • 各インスタンスから一貫した量のトラフィックが流れることを確認できるように、追加のメトリクスとモニタリングを実装する。
  • Amazon CloudWatch Anomaly Detectionを実装し、機械学習（ML）アルゴリズムを使用して、Amazon EC2インスタンスが異常に大量のネットワークトラフィックを生成するなどの特定のメトリクスを分析する。
  • Amazon Simple Notification Service（Amazon SNS）に異常検出を通知すると、カスタムのAmazon Lambda関数がトリガーされ、自動スケーリンググループの問題のあるAmazon EC2インスタンスが削除され、停止され、さらに分析のために隔離されるよう設計する。

さらに情報漏洩(information disclosure)や改ざん(tampering)への防御を確保し、否認(repudiation)への耐性を確保するためには、暗号化と最小権限を実装することです。例えば、Web層がバックアップを作成する際に、AWS Key management Service (AWS KMS）の鍵を使用し、そのインスタンスロールのみがKMS:Encrypt権限を持つようにします。Web層は自身のバックアップを復号化する必要がないので、そのロールに対してKMS:Decryptを拒否するか省略します。そのインスタンスロールは、データを暗号化するためにKMSキーを使用する能力を持つ唯一のエンティティであり、監査のためのCloudTrailログと組み合わせることで、バックアップがこれらのインスタンスによって書き込まれ、改ざんされていないことを検証することができます。未承認のユーザーがインスタンスにアクセスした場合、過去のバックアップから読み出すことはできません。

これらは、お客様が実施可能な手段の一部に過ぎません。また、Application Load Balancer上でユーザー認証を追加したり、アプリケーション層とデータベースの間でAPI Gatewayを使用してクエリの検証を実行したりすることもできます。前述のアーキテクチャを利用して、ゼロトラストモデルを適用した場合、次のようなアーキテクチャになる可能性があります。

図2: ゼロトラストを考慮したWebサイトホスティングの例

ゼロトラストは、アーキテクチャ内のマイクロサービス間のネットワーク境界を構築する以上に様々な要素を含みます。コンポーネントの境界線を強化するだけでなく、脅威の発生源とそれらから保護するための投資も再考すべきです。ゼロトラストモデルは必ずしも適切であるとは限りません。2つ目の図（図2）は、ある程度のセキュリティ上のメリットがありますが、システム全体を維持するためのコスト、複雑さ、運用上のオーバーヘッドが増加していることも考慮する必要があります。ゼロトラストアーキテクチャを検討する際には、Well-Architectedフレームワークの5つの柱すべてを評価して、各ニーズ間のバランスを適切にとるようにしましょう。

このリファレンスアーキテクチャの詳細については、「Web Applications Hosting in the AWS Cloud」のホワイトペーパーをお読みください。AWS上でのWebアプリケーションのホスティングについては、チュートリアルを参照してください。

 

本blogはHow to think about Zero Trust architectures on AWSを、セキュリティ アシュアランス本部 本部長 松本照吾、技術統括本部 レディネス＆テックソリューション本部 セキュリティ ソリューション アーキテクト 中島智広が翻訳しました。