Close menu
Toggle menu

ゼロトラストセキュリティとAWSでの設計概要

2025-03-12

ゼロトラストセキュリティとは

昨今、導入企業も増えてきたゼロトラストセキュリティについて、ゼロトラストセキュリティの原則とAWSでこれを導入するときの設計概要について紹介します。

まず、ゼロトラストセキュリティとは、アプリケーションのコンポーネントやマイクロサービスが互いに分離しており、どのコンポーネントやマイクロサービスも他のコンポーネントやマイクロサービスを信頼していないというモデルです。
これは、あらゆるソースからの入力を潜在的に悪意のあるものとみなすように設計されたセキュリティの考え方です。
基礎となる内部ネットワーク・ファブリックを信頼しないことから始まり、さらにすべてのマイクロサービスにおける入力と出力の評価におよびます。
加えて、個々のコンポーネント、マイクロサービス、またはアイデンティティの侵害から保護するために、多層防御アプローチを設計することも含まれます。

従来のネットワークセキュリティとの違い

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

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には、セキュリティを含む６つの明確な柱（運用性、セキュリティ、信頼性、パフォーマンス効率、コスト最適化、および持続可能性）が含まれています。このフレームワークを基に、ゼロトラストをAWSアーキテクチャに適用した例としてwebホスティングサービスの設計を考えてみましょう。

画像

上記で表現されているアーキテクチャは、セキュリティを考慮したWell architectedの一例です。

AWSのセキュリティサービス

システムは、以下のサービスを活用して一般的な攻撃ベクターから保護されています。

  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や改ざん対策の強化

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

  1. 各インスタンスから一貫した量のトラフィックが流れることを確認できるように、追加のメトリクスとモニタリングを実装する。

  2. Amazon CloudWatch Anomaly Detectionを実装し、機械学習（ML）アルゴリズムを使用して、Amazon EC2インスタンスが異常に大量のネットワークトラフィックを生成するなどの特定のメトリクスを分析する。

  3. 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ログと組み合わせることで、バックアップがこれらのインスタンスによって書き込まれ、改ざんされていないことを検証することができます。未承認のユーザーがインスタンスにアクセスした場合、過去のバックアップから読み出すことはできません。

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

画像

まとめ

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

もしAWSでのクラウド化をご検討の際は上記のようなセキュリティポリシーや原則を理解し導入することで、AWSの責任共有モデルの最大の利点を生かし享受できると考えております。

オンプレミスからのクラウド移行や現在のクラウド化におけるセキュリティや設計にご不安がございましたら、ご相談も承っております。お気軽にお問い合わせください。

お問い合わせ先

株式会社Sprobe
電話：03-6228-3425
問い合わせフォーム

ご質問・ご相談がございましたらお気軽にお問い合わせください。