Amazon Web Services（AWS）リファレンスアーキ …...本書の主な目的は、AWSのセキュアなアーキテクチャの設計原則とガイドラインを説明するこ

Amazon Web Services（AWS）リファレンスアーキテクチャ

WHITE PAPER

2

WHITE PAPER | Amazon Web Services（AWS）リファレンスアーキテクチャ

目次

概要 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4

責任共有モデル . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4

AWSの主な概念 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5

リージョンとアベイラビリティゾーン . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5

VPC（仮想プライベートクラウド）. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6

サブネット . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6

ネットワーク ACL. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7

セキュリティグループ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7

ルートテーブル . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7

インターネットゲートウェイ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8

NATゲートウェイ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8

Elasticネットワークインタフェース . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8

AWS VPN. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9

仮想プライベートゲートウェイ. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9

カスタマーゲートウェイ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10

Transit gateway . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10

AWSにおける FortiGate VM次世代ファイアウォール . . . . . . . . . . . . . . . . . . .11

FortiManager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12

FortiGuardセキュリティサービス . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12

ライセンス . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12

3


目次

サポートされるインスタンスタイプ. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12

AWSでの FortiGateの起動 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13

FortiGateの初回起動でのブートストラップ. . . . . . . . . . . . . . . . . . . . . . . . . .13

フォーティネットファブリックコネクタ. . . . . . . . . . . . . . . . . . . . . . . . . . . .14

ダイナミックアドレスオブジェクト . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14

例：動的アドレスオブジェクトを使用したファイアウォールポリシーの作成 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15

単一 FortiGate-VMの AWS上での展開 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15

インバウンドトラフィックのインスペクション（垂直方向） . . . . . . . . . . .15

アウトバウンドトラフィックのインスペクション（垂直方向） . . . . . . . . .16

トラフィックインスペクション（水平方向）. . . . . . . . . . . . . . . . . . . . . . . .17

FortiGateが AWSで実現する高可用性と耐障害性 . . . . . . . . . . . . . . . . . . . . . .17

オンプレミスネットワークへのアウトバウンド接続における耐障害性. . . . .18

ユニキャスト HAを使ったアクティブ / パッシブ構成 . . . . . . . . . . . . . . . . . .18

アクティブ / パッシブ環境の耐障害性 - 2つのアベイラビリティゾーン . . . .19

アウトバウンドトラフィックの耐障害性 - アクティブ / アクティブフェイルオーバー. . . . . . . . . . . . . . . . . . . . . . . . . . .21

設計パターン . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .23

FortiGateオートスケーリングによる柔軟なロードバランシングのサンドイッチ構成 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .23

Transit VPC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24

耐障害性 FortiGate構成と AWS Transit Gatewayの統合 . . . . . . . . . . . . . . . .25

まとめ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .27

4

概要パブリッククラウド（クラウド）は、広く普及しているクラウドコンピューティングモデルです。クラウドサービスプロバイダーは、インフラストラクチャやストレージ、サーバーといったリソースをインターネット経由で企業に提供します。共有される物理ハードウェアは、サードパーティのプロバイダー側が所有して運用を担い、企業は必要に応じて使用します。このようなマルチテナント環境は、インフラストラクチャのコストを複数ユーザー間で分散できます。世界中の企業はクラウドの導入によって次のようなメリットを得ています。

コスト効率：クラウドインフラストラクチャを使用することで機器の購入と保守にかける多大なコストが不要になり、CapEx（設備投資）を大幅に削減できます。ハードウェア、設備、ユーティリティに要するリソースと時間を節約でき、ビジネス成長のために大規模データセンターを保持する必要がなくなります。

拡張性：帯域幅が増大し変動する企業にとってクラウドの使用は理想的なソリューションです。需要の増大に応じてクラウドキャパシティを容易に拡張できるため、物理インフラストラクチャに投資する必要はありません。このような俊敏性は、重要な競争力の 1つです。

災害復旧：データ損失は、どの組織にとっても重要な課題です。ラップトップや PCといった機器が破損しても、顧客データをクラウドに格納しておけば、常にデータを取り出すことができます。クラウドベースのサービスは、自然災害や停電などの緊急時の迅速なデータ復旧を可能にします。

俊敏性の向上：今日、企業の生産性を向上するには動的な態勢が必要です。プロセス、ツール、テクノロジー、ポリシーを常に進化させ、改善しなければなりません。企業の俊敏性は、迅速な意思決定、優先順位付け、顧客満足の向上につながります。クラウドの活用によって、より良いデリバリ、コラボレーション、新たなビジネスイニシアティブの展開を加速することができます。

責任共有モデル

クラウドプロバイダーはクラウドのセキュリティを管理しますが、クラウドでのセキュリティ対策はユーザーが責任を負います。コンテンツとアプリケーションの保護に使用するセキュリティ機能は、ユーザーが管理します。

図 1：責任共有モデル

セキュアな接続

クラウド基盤サービス

データベースネットワークストレージコンピュート

アプリケーション／

データのセキュリティ

ユーザーのアプリケーション、コンテンツ

ネットワークセキュリティ

インベントリと構成

ユーザー：クラウド「内」のセキュリティを管理

クラウドプロバイダー：クラウド「の」

セキュリティを管理

データのセキュリティアクセス制御

可視化と制御

5


クラウドプロバイダーは、ホストオペレーティングシステムや仮想化レイヤーからサービスを運用する設備の物理的なセキュリティに至るまで、あらゆるコンポーネントの運用、管理、制御を担います。その一方で、データの所有権と制御はユーザーにあり、ユーザーは、環境内の基本的なセキュリティの設定と導入の責任を負います。

Amazon Web Services（AWS）は、企業がアプリケーションの実行に使用するクラウドコンピューティングサービスを提供する最大手のプロバイダーの 1つです。フォーティネットFortiGate NGFW（次世代ファイアウォール）は、AWS上での使用において、優れた自動化機能によって企業が高度なサイバー攻撃に対抗できるよう支援します。

次のセクションでは、本設計ガイドに関連する AWSの主な構成要素を説明します。

AWSの主な概念本書の主な目的は、AWSのセキュアなアーキテクチャの設計原則とガイドラインを説明することにあるため、AWSの概念と主な AWSサービスに関する知識は、本書で解説する設計トピックを理解する上での前提条件となります。

リージョンとアベイラビリティゾーン

AWSクラウドインフラストラクチャは、AWSリージョンとアベイラビリティゾーンから構成されています。AWSリージョンは、物理的なロケーションで、世界中に分散され、リージョン内には複数のアベイラビリティゾーンが設置されています。アベイラビリティゾーンは、1つまたは複数のデータセンターから構成されます。電源、ネットワーキング、接続性が冗長化されており、それぞれは分散した設備に配置されます。アベイラビリティゾーンは、本番稼働のアプリケーションやデータベースの運用に対応します。アプリケーションやデータベースは、単一のデータセンターでは提供できない優れた可用性、フォルトトレランス、拡張性を得られます。

Amazonリージョンは、それぞれが完全に分離されています。これにより、最高レベルの対障害性と安定性が実現されます。アベイラビリティゾーンは独立していますが、同じリージョン内のアベイラビリティゾーン間は低レイテンシのリンクで相互接続されています。AWSでは、イン

専門用語の解説

n アベイラビリティゾーン：1つまたは複数のデータセンター。電源、ネットワーキング、接続性が冗長化され、分散した設備に設置される。

n AWSリージョン：複数のアベイラビリティゾーンが設置されている物理的なロケーション

スタンスやデータの配置に非常に柔軟に対応します。各 AWSリージョン内の複数のアベイラビリティゾーンのみならず、複数の地理的に離れた場所への配置や格納が可能です。アベイラビリティゾーンは、それぞれが独立した障害ゾーンとして設計され、標準的な都市部の、物理的に隔離された、冠水リスクの低い場所に設置されています。2019年 3月時点で、AWSクラウドは世界中で 20のリージョン内に 61のアベイラビリティゾーンを展開しており、さらに 12のアベイラビリティゾーンと 4つのリージョンの追加を計画しています 1。

図 2：AWSリージョンとアベイラビリティゾーン

AWS Cloud

Availability Zone

Availability Zone

Availability Zone

Availability Zone

Availability Zone

Availability Zone

低レイテンシリンク

低レイテンシリンク

Region : us-west-2（オレゴン） Region : eu-west-1（アイルランド）

1 「AWS Global Infrastructure」 AWS、2019 年 3 月：https://aws.amazon.com/about-aws/global-infrastructure/

https://aws.amazon.com/about-aws/global-infrastructure/

https://aws.amazon.com/about-aws/global-infrastructure/

6


アベイラビリティゾーンの耐障害性と分離機能を活用するには、アプリケーションとセキュリティサービスを分散し、複数のアベイラビリティゾーンで保護する必要があります。

VPC（仮想プライベートクラウド）

Amazon VPC（仮想プライベートクラウド）を使用して、ユーザーは定義済みの仮想ネットワークで AWSリソースを使用できます。この仮想ネットワークは、顧客が独自のデータセンターを運用できるという点で従来のネットワークに非常に似ており、さらに、拡張性に優れた AWS

インフラストラクチャを使用するメリットもあります。Amazon VPCでは、AWSクラウドの論理的に隔離されたセクションをプロビジョニングすることが可能で、このセクションでは、定義した仮想ネットワーク内で AWSリソースを起動できます。IPアドレス範囲の選択、サブネットの作成、ルートテーブル、ネットワークゲートウェイの設定など、仮想ネットワーク環境を完全に制御できます。VPCネットワークは、IPv4と IPv6両方のアドレスをサポートします。

ほとんどの AWSアカウントでは、デフォルトの VPCが提供され、各アベイラビリティゾーンのデフォルトサブネットが付属します。Amazon VPCに関する知識を持たないユーザーでも、デフォルトの VPCでインスタンスを起動できます。また、AWSでは、ユーザーはデフォルトの VPC以外に専用の VPCも作成できます。これにより、VPC CIDR（Classless InterDomain

Routing）、サブネット、ネットワーク構成の柔軟なカスタマイズが可能になります。

物理的なデータセンターのネットワークでは CIDRブロックの拡張作業が煩雑になることに対して、VPCでは、VPCの作成時に CIDRブロックを定義し、後でセカンダリ CIDRを追加することで範囲を拡張できるため、クラウドの動的なメリットを活用できます。VPCの作成時のCIDRの定義と割り当てはユーザーの任意ですが、RFC 1918「プライベート網のアドレス割り当て」に従って CIDRを使用することを強く推奨します。

デフォルトでは、VPC内のすべてのインスタンスは、同じ VPC内の他のインスタンスへのルートを持っています。ただし、定義された CIDRがパブリックルーティング可能な IPアドレス範囲であったとしても、インターネット接続はデフォルトでは有効になりません。インターネット接続を確立するには、インターネットゲートウェイを作成し、VPCにアタッチする必要があ

技術的なヒント 1

Amazon VPCでは、プライマリ CIDR

の変更はサポートされていません。

全体的なネットワークマップを検討してから、VPCを作成し、CIDR定義してください。CIDRを定義する方法は、物理的なデータセンターで CIDRを割り当てる際と同様です。これにより、AWSアカウントにインスタンスを実装した後で IPアドレスの重複が発覚する、といった問題を回避できます。

ります。これにより、インターネット接続を必要インスタンスにパブリック IPアドレスを割り当てることができます。Elastic IPアドレスも、インスタンスへの割り当てが可能です。VPCとオンプレミス間の接続を必要とする場合には、VPNゲートウェイデバイスを作成し、VPCにアタッチします。これにより、VPNゲートウェイとオンプレミスのカスタマーゲートウェイ間に IPsec VPN接続を確立できるようになります。

サブネット

VPCの作成が完了したのち、各アベイラビリティゾーンに 1つまたは複数のサブネットを追加できます。サブネットの作成では、VPC CIDRブロックのサブネットとなる CIDRブロックを指定する必要があります。サブネットは 1つのアベイラビリティゾーン内に配置し、複数のゾーンにまたがることはできません。サブネットのトラフィックがインターネットゲートウェイにルーティングされると、そのサブネットはパブリックサブネットとして認識されます。サブネットがインターネットゲートウェイにルーティングされない場合、サブネットはプライベートサブネットとして認識されます。

サブネットの CIDRブロックは、VPCの CIDRブロックと同じ場合（VPC内に 1つのサブネット）と、VPCの CIDRブロックのサブネットの場合（複数サブネット）があります。ブロックサイズは、/28ネットマスクから /16ネットマスクの間であり、VPC内でサブネット CIDRは重複できません。たとえば、VPC CIDRブロックが 10.0.0.0/24の場合、/25 CIDRサブネットを VPC内に 2つ作成できます。各サブネット CIDRブロックでは、最初の 4つの IPアドレスと最後の IPアドレスはユーザーが使用できない点と、インスタンスへの割り当てはできない点に注意してください。たとえば、サブネット CIDRが 10.0.0.0/24の場合、次に示す 5つのアドレスは予約済みです。

n 10.0.0.0: ネットワークアドレス

n 10.0.0.1: AWSが VPCルーター用に予約

n 10.0.0.2: AWSが DNSサーバー用に予約（VPC CIDR＋ 2のベース）AWSは、各サブネット範囲＋ 2のベースも予約

n 10.0.0.3: AWSの将来的な使用のために予約

n 10.0.0.255: ネットワークブロードキャストアドレス

7


ネットワーク ACLの使用に必要な知識

n VPCには、すべてデフォルトのNACLが付属します。このNACLは、インバウンドとアウトバウンドのIPv4トラフィックをすべてサポートします。

n ネットワークACLには、番号付きのルールリストが指定されています。番号の小さいルールから順に評価を行い、ネットワークACLに関連するサブネットのトラフィック送受信を許可するかどうかを判定します。

n ネットワーク ACLには、独立したインバウンド / アウトバウンドルールがあり、個々にトラフィックの許可 / 拒否を行います。

n ネットワーク ACLはステートレスです。許可されたインバウンドトラフィックへの応答は、アウトバウンドトラフィックのルールの適用対象となります。

ネットワーク ACL

ネットワーク ACL（アクセス制御リスト）は、VPCのオプションとして使用できるセキュリティレイヤーで、L4ステートレスファイアウォールとして 1つまたは複数のサブネットのインバウンド / アウトバウンドトラフィックを制御します。VPCではサブネット間ルーティングをデフォルトで使用できるため、ネットワーク ACLを使用することで、サブネットが VPC内の他のサブネットにアクセスする操作を禁止できます。

セキュリティグループ

セキュリティグループは、インスタンスの仮想レイヤー 4ファイアウォールとして機能し、インバウンド / アウトバウンドトラフィックを制御します。セキュリティグループは、インスタンスのネットワークインタフェースで適用されます。したがって、サブネット内のインスタンスを、それぞれ別のセキュリティグループに割り当てることが可能です。AWSでは、デフォルトで、ネットワークインタフェースに最大 5つのセキュリティグループを割り当てることができます。

ネットワーク ACLとは異なり、セキュリティグループはステートフルで、拒否アクションはサポートしません。

セキュリティグループはレイヤー 4ファイアウォールとしてのみ機能し、パケットを調査するアプリケーションレイヤーの可視化機能は備えていません。したがって、NGFWをセキュリティレイヤーに追加し、高度なサイバー攻撃の検出と防御を行う必要があります。

ルートテーブル

VPCには、暗黙的なルーターを備えており、VPC内の各サブネットをルートテーブルに関連付ける必要があります。ルートテーブルでは、サブネットから送信されるアウトバウンドトラフィックに対して、許可するルートが指定されています。

メインルートテーブル：VPCを作成すると、メインルートテーブルが自動生成されます。メインルートテーブルは、他のルートテーブルに明示的に関連付けられていないすべてのサブネットのルーティングを制御します。メインルートテーブル内のルートは、削除、追加、変更が可能です。メインルートテーブルは削除できません。

カスタムルートテーブル：メインルートテーブル以外に、ユーザーが追加できるルートテーブルです。サブネットとカスタムルートテーブルを関連付けることで、サブネットルートのアウトバウンドトラフィックを個別に明示的に制御できます。

すべての Amazon VPCルートテーブルには、デフォルトでローカルルートエントリーが付属しますが、このエントリーを詳細なルートプレフィックスで上書きすることはできません。このルートエントリーにより、すべてのインスタンスに、VPC内の他のインスタンスへのルートが提供されます。ただし、詳細なプレフィックスルールがないため、サブネット内トラフィックとサブネット間トラフィックをネットワークセキュリティアプライアンスへとネイティブステアリングすることはできません。

図 3は、VPCのメインルートテーブルと、プライベートサブネットに関連付けられているカスタムルートテーブルを示しています。いずれのルートテーブルにもローカルルートエントリーがあり、削除できません。

図 3：Amazon VPCネットワークの基礎

セキュリティグループの主な特徴

n「許可」ルールの適用は可能ですが、「拒否」ルールは適用できません。

n インバウンドトラフィックとアウトバウンドトラフィックには別のルールを指定できます。

n「許可」ルールは、すべてセキュリティグループに明示的に追加する必要があります。追加しない場合、デフォルトの AWSアクションが適用され、すべてのトラフィックをブロックします。

n セキュリティグループはステートフルです。インスタンスからリクエストが送信されると、関連するセキュリティグループのインバウンドルールに関係なく、リクエストに対する応答トラフィックは許可されます（逆も同様）。

n 別のホストからインスタンスへのインバウンドトラフィックを許可するには、セキュリティグループのインバウンドルールを更新する必要があります。これは、AWSは、デフォルトではインバウンドルールが作成されないためです。

AWS Cloud

Availability Zone 1

インターネットゲートウェイ

ルーター

NATゲートウェイ

Webサーバー

パブリックサブネット

プライベートサブネット

データベースサーバー

ルートテーブル - パブリックサブネット

ルートテーブル -プライベートサブネット

宛先

宛先

ターゲット

ターゲット

インターネット

8


ENIの特徴

n プライマリプライベート

IPv4アドレス

n 1つまたは複数のセカンダリ

プライベート IPv4アドレス

n 1つのプライベート IPv4アドレスに対して 1つの Elastic IPアドレス（IPv4）

n 1つのパブリック IPv4アドレス

n 1つまたは複数のセキュリティ

グループ

n MACアドレス

n 送信元 / 宛先チェックフラグ

インターネットゲートウェイ

VPCルーティングの設計上、インターネットゲートウェイがアタッチされていない状態では、VPC、プライベートサブネット、パブリックサブネット内のインスタンスによるインターネットを介した通信はできません。インターネットゲートウェイは、パブリック IPv4アドレスが割り当てられたインスタンスのネットワークアドレス変換を行います。

インターネットゲートウェイを作成して VPCにアタッチした後、インターネット行きのトラフィックからインターネットゲートウェイへとダイレクトするルートを、パブリックサブネットと関連付けられたルートテーブルに追加する必要があります（図3）。また、インスタンスがインターネットを介して通信できるようにするには、パブリック IPアドレス、またはパブリック IP

アドレスに関連付けられた Elastic IPアドレスの割り当てが必要です。インスタンスが識別できるのはプライベート IPアドレスのみのため、インターネットゲートウェイは、インスタンスのために論理的な 1対 1の NAT（ネットワークアドレス変換）を行う必要もあります。これにより、リターントラフィックの宛先が、インスタンスのパブリック IPアドレスになります。

NATゲートウェイ

NATゲートウェイは、プライベートサブネット内のインスタンスによるインターネット接続を可能にするマネージド AWSサービスです。また、一方的なインターネットトラフィックがプライベートインスタンスに到達できないようにします。インターネットに送信されるトラフィックの送信元 IPアドレスは、NATゲートウェイのパブリック IPアドレスに置換されます。同様に、インスタンスへの応答トラフィックのアドレスは、NATゲートウェイによってインスタンスのプライベート IPアドレスに戻されます。

NATの作成後、プライベートサブネットに関連付けられたルートテーブルを更新し、インターネット行きのトラフィックを NATゲートウェイへとポイントする必要があります。これにより、プライベートサブネット内のインスタンスはインターネットと通信できるようになります。たとえば、プライベートサブネットに関連付けられたルートテーブル（図 3）には、NATゲートウェイをターゲットとするデフォルトルートのルートエントリーが含まれています。このルートにより、インターネット行きのトラフィックはすべて NATゲートウェイ経由でルーティングされます。

AWSでは、NATインスタンスと NATゲートウェイという 2つのタイプの NATデバイスが提供されています。ただし、NATゲートウェイは AWSで管理されており、管理作業の手間がかからないという点で、NATゲートウェイを推奨します。

Elasticネットワークインタフェース

ENI（Elasticネットワークインタフェース）とは、VPC（仮想ネットワークカード）内の論理的なネットワーキングコンポーネントで、仮想のネットワークカードとなります。ユーザーは、アカウントでネットワークインタフェースを作成および構成し、それを VPC内のインスタンスにアタッチできます。ENIは、複数の属性を持っています。

インスタンスを起動すると、1つ以上のネットワークインタフェースが提供されます。このプライマリインタフェースは、切断できません。ENIと ENIが接続されているインタフェースが同じアベイラビリティゾーン内にある限り、これ以外のENIをすべてインスタンスからデタッチし、別のインスタンスにアタッチすることが可能です。

送信元 / 宛先チェック：送信元 / 宛先チェック属性は、インスタンスでの送信元 / 宛先チェックの有効性を制御します（デフォルトは有効）。インスタンスでこの属性を無効にすると、そのインスタンス宛て以外のネットワークトラフィックを処理できるようになります。たとえば、ファイアウォールサービスを実行するインスタンスでは、この値を無効にしてください。図 5では、FortiGateファイアウォールの 2番目のENI（プライベートインタフェース）の送信元 / 宛先チェックは無効になっています。これにより、インターネット行きのトラフィックは、ファイアウォールを経由します。

9


AWS VPN

AWS VPN（Site-to-Site）は、ユーザーのデータセンターや支社のネットワークを、IPsec

トンネルを介して AWSクラウドへと拡張し、仮想プライベートゲートウェイと AWS Transit

Gatewayの両方への接続をサポートします。ユーザーは、IPsecトンネルを介した BGP（Border

Gateway Protocol）をオプションで実行できます。

仮想プライベートゲートウェイ

仮想プライベートゲートウェイとは、Site-to-Site VPN接続の AWS側にある VPNコンセントレータです。仮想プライベートゲートウェイを VPCにアタッチし、VPC内の VPN終端点として機能させることができます。仮想プライベートゲートウェイの作成時には、ASN（自律システム番号）の割り当てが可能です。ただし、作成後の変更はできません。

仮想プライベートゲートウェイを作成して VPCにアタッチし、VPN接続を確立すると、仮想プライベートゲートウェイはユーザーのオンプレミスデータセンターへのゲートウェイとして機能します。リモートルーターのターゲットとしてルートテーブルに静的に追加する方法と、


仮想プライベートゲートウェイの作成時に ASNを指定しない場合、AWSはデフォルトで ASN 64512を割り当てます。

図 4：送信元 / 宛先チェックを有効にした場合のトラフィック転送

サーバー




宛先ターゲット


図 5：送信元 / 宛先チェックを無効にした場合のトラフィック転送

サーバー






10


BGPを介してリモートルートを学習した後、ルートテーブルに自動追加する方法があります。たとえば、図 6のルートテーブルの場合、10.17.0.0/16へのルートは動的に学習し、追加されます。

プライベートゲートウェイでSite-to-Site VPN接続を複数作成することは可能ですが、ネットワークパフォーマンスが低下する恐れがあります。これは、帯域幅に制限があることと、多くの企業で必要とされる、数ギガ規模のスループットの要件に対応できる動的な拡張性がないことが理由です。

カスタマーゲートウェイ

カスタマーゲートウェイとは、ユーザーのデータセンターで稼働する物理アプライアンスまたはソフトウェアアプリケーションを指します。AWSでは、VPN接続を確立する前に、AWSアカウントでカスタマーゲートウェイオブジェクトを作成する必要があります。カスタマーゲートウェイでは、VPN接続の作成に使用する、パブリックなルーティングが可能な IPアドレスが必要です。カスタマーゲートウェイデバイスの作成には、ネットワークに割り当てられている既存の ASNを使用できます。または、64,512～ 65,534の範囲のプライベート ASNを使用することも可能です。作成したカスタマーゲートウェイでは、VPN接続の確立に必要な構成を行います。フォーティネットは AWSチームと連携し、AWSから直接ダウンロード可能な構成テンプレートを提供しています。

図 6で示すように、Site-to-Site VPN接続にはトンネルが 2つあり、それぞれが、仮想プライベートゲートウェイの一意のパブリック IPアドレスを使用しています。両方のトンネルで冗長化構成を行うことが重要です。これにより、いずれかのトンネルが使用不能になった場合（システムダウンや保守など）、ネットワークトラフィックは、そのSite-to-Site VPN接続で使用可能なトンネルへと自動的にルーティングされます。

Transit gateway

最近まで、VPCの相互接続を行うための選択肢には制限がありました。ポイント間ピアリングを作成して各 VPCでネットワーキングを管理することは可能ですが、非常に複雑になってしまいます。また、共有 VPCにおいて、各 VPCからサードパーティルーター / ファイアウォールアプライアンスへの IPsecトンネルを作成することも可能です。このハブ &スポークトポロジを、Transit VPCを呼びます。


仮想プライベートゲートウェイがサポートできるネットワークスループットは、最大 1.25 Gbps です。また、ECMP（等価コストマルチパス）ルーティングはサポートしません。


IPsecトンネルを確立するには、ユーザーのゲートウェイでトンネルを初期化する必要があります。

図 6：AWS Site-to-Site VPN接続




宛先アクティブターゲット伝搬

IPSecトンネル

カスタマーゲートウェイVPNゲートウェイ

11


Transit Gatewayの主な特性

n VPC または VPN 接続を Transit

Gatewayにアタッチできます。

n Transit Gatewayにはデフォルトのルートテーブルがあり、オプションでルートテーブルを追加できます。

n デフォルトでは、Transit Gateway

にアタッチされている VPCおよびVPN接続は、デフォルトの Transit

Gatewayルートテーブルに関連付けられています。

n それぞれの Transit Gatewayは、1

つのルートテーブルに割り当てられています。

n 各ルートテーブルに関連付けるアタッチの数は、ゼロから複数です。

n VPC内のアベイラビリティゾーンに割り当て可能な Transit Gateway

のアタッチは、1つのみです。

n VPC または VPN 接続は、Transit

Gatewayのルートテーブルへとルートを動的に伝搬します。

VPC間接続とセキュリティ要件への対応には、Fortinet Transit VPCのような Transit VPCの導入を推奨します。AWS仮想プライベートゲートウェイは、各 VPCスポークに導入され、VPN接続を終端しますが、帯域幅に大きな制限があるためネットワークパフォーマンスが低下します。

AWS Transit Gatewayでは、大規模接続に対応した新しい分散サービスの使用によりこの問題の解決を図っています。ECMP（等価コストマルチパス）ルーティングをサポートするため、トラフィックは、同じ IPプレフィックスを伝搬する複数の VPN接続に対して均等に配分されます。

Transit Gatewayは AWSアカウント全体で機能しますが、アタッチできるのは、同じリージョン内の VPCのみです。

図 7の Transit Gatewayは、2つの異なる AWSアカウントにある 2つの VPCにアタッチされています。すべてのアタッチメントは、Transit Gatewayのデフォルトルートテーブルと関連付けられています。2番目のアカウントで使用する VPCのルートテーブルは更新され、Transit

Gatewayへのルートが含まれています。アカウント 1では、タイプ VPNの Transit Gatewayアタッチメントオブジェクトが 1つ作成されており、ハブ VPCにある FortiGate NGFWに Transit

Gatewayを接続します。また、各 AZに 1つずつ、合計 2つの Transit Gatewayアタッチメントが作成され、アカウント 1のスポーク VPCと Transit Gateway間接続の可用性を高めます。

AWSにおける FortiGate VM次世代ファイアウォールステートフルインスペクションと包括的なセキュリティ機能を融合した FortiGate NGFWテクノロジーは、コンテンツとネットワークを完全に保護します。このソリューションは、AWS上の環境で使用できます。

トップクラスの脅威データベース、脆弱性管理、フローベースのインスペクションといった高度な機能に加えて、アプリケーション制御、ウイルス対策、IPS、Webフィルター、VPNをはじめとする機能が連携し、最新の複雑なセキュリティ脅威を特定および軽減します。

強力なセキュリティを提供する FortiOSオペレーティングシステムは、マルウェアの検査と識別を考慮した専用の設計と、ダイレクト SR-IOV（シングルルート I/O仮想化）のサポートによって、高速かつ安定したパフォーマンスを実現します。

図 7：AWS Transit Gatewayのアーキテクチャ






ルートテーブル - プライベートサブネット

TGWデフォルトルートテーブル

Transit GW アタッチメント

宛先

CIDR

アクティブターゲット

アタッチメント

伝搬

AWS Cloud

AWS Cloud

アカウント 1

アカウント 2

Availability Zone 1

Availability Zone 1

Availability Zone 2

12


AWSにおける FortiGate-VMの

メリット

n FortiGuard Labsセキュリティサービスによって継続的に提供される脅威インテリジェンスを使用して、既知のエクスプロイトとマルウェアから保護

n クラウドアプリケーションを含む数千規模のアプリケーションを特定し、ネットワークトラフィックを詳細に検証

n 動的分析を使用して未知の攻撃を検知し、自動減災機能によって標的型攻撃を阻止

n AWS GuardDuty 脅威検知サービスがインシデント対応を自動化し、脅威インテリジェンスを提供

n Fortinetファブリックコネクタを介して AWSアカウントとネイティブに統合し、顧客のマルチクラウド環境全体にセキュリティポリシーを動的に適用

FortiManager

FortiManager仮想セキュリティ管理アプライアンスは、FortiManagerハードウェアアプライアンスと同等の強力なネットワークセキュリティ管理機能を AWSでも提供します。シンプルな積み上げ式のライセンス体系によって、ネットワーク環境に合わせて容易に拡張することができます。ハードウェアと仮想アプライアンスを組み合わせて導入してその両者を連携させて運用でき、共通の FortiManagerプラットフォームから一元管理することも可能です。

FortiGuardセキュリティサービス

FortiGuard Labsは、脅威の最新状況に関するリアルタイムの情報を駆使して、フォーティネットのさまざまなソリューション向けに包括的なセキュリティアップデートを提供します。セキュリティに対する脅威の研究者、エンジニア、犯罪科学のスペシャリストで構成されるチームが、脅威の監視を手掛ける世界有数の機関やネットワーク / セキュリティ分野を代表するベンダー、世界各国の捜査機関と協力して、優れたサービスをお届けします。

ライセンス

FortiGate-VM for AWSは、オンデマンドの PAYG（Pay-As-You-Go）モデルや BYOL（Bring-Your-

Own-License）モデルにより、さまざまなプライベート / パブリッククラウド環境を幅広い導入方法でサポートします。

BYOLは、販売代理店やディストリビューターから購入する年次ベースの永久ライセンスです。プラットフォームにかかわらず、プライベート / パブリッククラウドすべてに同じ注文ポリシーが適用されます。顧客は、インスタンスへの初回アクセス時にライセンスを有効にすることで、各種機能を使用できるようになります。このモデルは、既存のプライベートクラウド環境をパブリッククラウド環境へと移行するユースケースに最適です。既存のライセンスを使用する場合には、追加コストのみで AWSインスタンスを使用できます。

PAYGは、非常に柔軟なオプションです。新しい導入環境と必要に応じて成長する環境のいずれにも適しています。幅広いインスタンスタイプがサポートされるため、あらゆるユースケースにも対応できます。このライセンスでは、UTMバンドルで FortiOSが提供されます。PAYGを購入するには、AWSマーケットプレースでサブスクリプションを購入します。

サポートされるインスタンスタイプ

FortiGate-VMは AWS上で次のインスタンスタイプをサポートします。

アクティブ / パッシブ HA（高可用性）モードで実行する場合、FortiGate-VMインスタンス 1つあたり 4つのネットワークインタフェースが必要になります。

表 1：FortiGate-VMが AWS上でサポートするインスタンスタイプ

インスタンスタイプ vCPU NICの最大数（AWSで有効）

13


インスタンスタイプは、C4も使用できますが、AWSの高度なネットワーキングを活用してネットワークスループットを最大限に高めるには、C5

または C5nの使用を強く推奨します。

次の表は、通常購入可能な BYOLモデルです。

vシリーズは、デフォルトでは VDOMをサポートしないことにご注意ください。vモデルで VDOMを実行するには、VDOMライセンスの追加購入が必要です。

FortiOS 6.0.2以降の FortiGate-VMライセンスでは、FortiGateは vCPUの数に制限されなくなり、ライセンスのサポート数を上回る vCPUを使用するAWS内のVMインスタンスで実行できるようになりました。ライセンスで指定される vCPU数による制限がなくなったことで、仮想インスタンスの vCPU数にかかわらず FortiGateを実行できます。ただし、トラフィックを処理するのはライセンスで許可される vCPUのみであり、それ以外の vCPUは使用されません。

AWSでの FortiGateの起動

FortiGateの最も基本的な導入環境は、1つの FortiGateと、パブリックインタフェースとプライベートインタフェースが 1つずつ、合計 2つのネットワークインタフェースで構成されます。

FortiGateの初回起動でのブートストラップ

AWSユーザーデータとは、一連のコマンド / データセットであり、起動時に Amazon EC2（Elastic Compute Cloud）インスタンスにインジェクトできます。このデータを使用するかどうかは、EC2のゲスト OSに応じて決まります。AWSにおける FortiGate-VMはこの機能をサポートすることで、ゼロデイ構成など、FortiGateインスタンスに必要なブートストラップを自動化します。

ユーザーは、Amazon S3バケットを作成して BYOLインスタンスのライセンスファイルをアップロードする操作や、ゼロデイ構成ファイルを S3

バケットにアップロードする操作を実行できます。起動時に、S3バケットへのアクセスを許可する IAM（アイデンティティとアクセス管理）ロールを、FortiGateインスタンスにアタッチする必要があります。FortiGateインスタンスの起動時、ブートストラップのために、次のようなユーザーデータが渡されます。

{

“"bucket” : “unique-bucket-name”,

“region” : “us-west-2”,

“license” : “/FGVM020000000000.lic”,

“config” : “/fgtconfig-init.txt”,

}

表 2：FortiGate-VMモデル（BYOL）

モデル名 vCPU - 最大vCPU – 最小

図 8：FortiGate-VM on AWS

パブリックサブネットプライベートサブネット

14


フォーティネットファブリックコネクタ

動的なネットワーク環境がますます拡大する中で、急速に変化するオペレーションに対応できる俊敏性を実現するには、セキュリティソリューションを、ネットワーキングなどの ITインフラストラクチャとさらに緊密に統合する必要があります。

マルチクラウド環境では、パブリッククラウド、プライベートクラウド、物理エンティティがそれぞれ分離された集合体のため、それぞれ異なるセキュリティ管理手法が必要とされ、管理者の作業負担が増大します。また、サイトやテナントごとにセキュリティソリューションが異なり、セキュリティ管理の一貫性を欠くため、異なるクラウドでのセキュリティ態勢の統一は多くの企業が直面する大きな課題となっています。

フォーティネットのファブリックコネクタは、APIなどのインタフェースを備えることで、プラットフォームの拡張性を高めます。すぐに使える統合機能が組み込まれており、FortiGate /

FortiManagerと、主要な SDN（ソフトウェア制御によるネットワーク）や AWSをはじめとするパブリッククラウドソリューションとのオーケストレーションを実現します。

ダイナミックアドレスオブジェクト

フォーティネットファブリックコネクタは、SDN（プライベートクラウド）とクラウド（パブリッククラウド）向けの FortiGate（スタンドアロンシステムとして）または FortiManager（複数の FortiGate NGFWを管理）を、サードパーティ SDNまたはクラウドプラットフォームと統合します。FortiManagerの場合、FortiGateファイアウォールポリシーで保護する動的アドレスグループオブジェクトを同期します。

オブジェクトの形式や場所がエラスティックで常に変化する場合でも、FortiGateは、送信元 /

宛先として使用可能なアドレスオブジェクトとして識別します。適切なファイアウォールポリシーを自動的に適用するため、管理者による手作業の操作は必要ありません。

FortiManagerは、オプションのコンポーネントです。このセクションでは、ユーザーはFortiGateを直接使用して、アドレスオブジェクトとファイアウォールポリシーを設定することを前提とします。

AWSリソースの動的アドレスオブジェクトを作成するには、まず FortiGate CLI/API/GUIを使用して AWSコネクタを作成する必要があります。

次の情報を入力し、AWS VPCに接続可能なコネクタを作成します。

n AWSアクセスキー ID / シークレットアクセスキー：APIアクセスに必要な AWS認証情報

n AWSリージョン名

n AWS VPC ID

n 更新間隔：コネクタが動的なアドレスオブジェクトを更新する間隔

図 9：フォーティネットファブリックコネクタ

動的オブジェクト

ファブリックコネクタ

オブジェクトの更新

定義の伝搬

15


次に、この AWSコネクタを使用してアドレスオブジェクトを定義します。ユーザーは、インスタンス ID、インスタンスタイプ、サブネット IDなどさまざまな AWS属性に基づいてアドレスオブジェクトを定義できます。アドレスオブジェクトは、リソースに関連付けられたタグに基づいて定義することも可能です。

例：動的アドレスオブジェクトを使用したファイアウォールポリシーの作成

タイプが AWSファブリックコネクタのアドレスオブジェクトを作成したら、そのアドレスを送信元または宛先とするファイアウォールポリシーを構成できます。図 10は、ユーザーの AWSアカウントで導入した FortiGateのファイアウォールポリシーで使用されている動的アドレスオブジェクトを示しています。

この例のユーザーは、Dept=Engのタグが付いたエンジニアリングリソースを、音声 / ビデオストリーミングWebサイトにアクセスできないようにすべてブロックしようとしています。“tag.Dept=Eng”フィルタールールで作成した動的アドレスグループには、EC2インスタンスが2つ（10.0.1.9

と 10.0.1.10）含まれています。このアドレスオブジェクトを送信元アドレスとするファイアウォールポリシーが作成されます。このポリシーは、音声 / ビデオストリーミングWebサイト（netflix.comなど）を宛先とするアドレスオブジェクトからのアクセスを、すべてブロックします。したがって、エンジニアリングチームが新しい EC2インスタンスを起動すると、適切なタグ付けが行われている限り、そのインスタンスは自動的にアドレスオブジェクトに接続します。新しいインスタンスからストリーミングWebサイトへの接続は自動的にブロックされるため、管理者がファイアウォールを手動で構成する必要はありません。

単一 FortiGate-VMの AWS上での展開

FortiGateを展開することで、環境をセキュリティ保護し、送信 / 受信トラフィックで詳細なパケットインスペクションを実行できます。次のセクションでは、単一の FortiGate導入シナリオでのパケットフローを説明します。

インバウンドトラフィックのインスペクション（垂直方向）

Webアプリケーションが急増する現在、AWSとWebアプリケーションの両方を導入しているユーザーは、高度なサイバー攻撃からアプリケーションを保護する必要があります。そのためには、FortiGate-VMを VPCに導入し、インターネットから伝送されるすべてのインバウンドトラフィックのインスペクションを行います。単一の FortiGate-VMで背後の複数のサービスを保護するアプローチとして一般的なのは、各サービスの IPアドレス / Portを、FortiGate NGFWのパブリックネットワークインタフェースに関連付けられた単一の Elastic IPアドレス（EIP）にマッピングする方法です。たとえば、図 11のWebサービスは Port 8080でホストされており、FortiGate EIP / Port 8080にマッピングされています。

図 10：動的アドレスオブジェクトを使用してファイアウォールポリシーを作成

AWS用 Fortinetファブリックコネクタ

動的アドレスオブジェクト

動的アドレスオブジェクト -更新





16


Webサーバーを宛先とするすべてのトラフィックは、FortiGate-VMによって検査されます。VPCにアタッチされた IGW（インターネットゲートウェイ）は、インターネット接続を可能にし、FortiGateの ENI-0のプライベート IPアドレスとインタフェースに関連付けられた EIPをネットワークアドレス変換します。

図 11は、受信トラフィックのパケットフローとリターントラフィックのパスを示しています。

インバウンドトラフィック：IGWは、宛先 IPアドレス（FortiGateの ENI-0に関連付けられている EIP）を、FortiGateの ENI-1のプライベート IP

アドレスへと変換します。FortiGate NGFWは、宛先 NATを適用することで、宛先 IPアドレスをバックエンドWebサーバーの IPアドレスへと変更します。

リターントラフィック：Webサーバーから戻ってくるトラフィックは、プライベートサブネットのルートテーブルに従います。ここには、すべてのインターネット行きトラフィックを FortiGateへとポイントするルートエントリーが含まれています。図 11で示すように、FortiGateと IGWはいずれも送信元 NATをリターントラフィックに適用し、送信元 IPをパブリックルーティング可能な IPアドレス（FortiGate NGFWの ENI-0）に関連付けられた EIP）へと変更します。

アウトバウンドトラフィックのインスペクション（垂直方向）

Webアプリケーショントラフィックは、ほとんどの場合インターネットからの受信が中心ですが、Webアプリケーションがインターネットへリクエストを送信する場合もあります。たとえば、マネージドWebサービスやユーザーによるWebサーバー管理を行う場合、セキュリティパッチのダウンロードやライブアップデートの実行を要求する必要があります。ユーザーは、プライベートサブネットのルートテーブルにデフォルトルートを追加し、FortiGateプライベートインタフェースをネクストホップとしてポイントすることが可能です。これにより、インターネット行きトラフィックを FortiGateで検査できるようになります。図 11は、Webサーバーが生成するインターネット行きリクエストに対して送信元 NATを割り当て、宛先 NATをリターントラフィックに割り当てる方法を示しています。

前述のとおり、FortiGate-VMでトラフィック転送を行うには、送信元 / 宛先チェックフラグをネットワークインタフェースレベルで無効にする必要があります。

図 11：FortiGate-VMによるインバウンドトラフィックインスペクション




Web サーバー



17


図 12の例で示すように、OSパッチのダウンロードを行うには、プライベートサブネットのWebサーバーは、インターネット行きのリクエストを開始する必要があります。図で示すように、FortiGate-VMと IGWの両方が、送信元 NATをアウトバウンドトラフィックに適用します。また、宛先 NATを応答トラフィックに適用することで、FortiGateの ENI-0の EIPとプライベート IPアドレスを変換します。

トラフィックインスペクション（水平方向）

前述のように、AWS VPCネットワーキングでは、VPCネットワークのセグメンテーションを、VPCに割り当てられた CIDRの枠を超えて行うことはできません。したがって、VPC内のすべてのインスタンスは、サブネットに関係なく、サブネット内にある他のインスタンスへのルートを持つことになります。たとえば、CIDRが 10.100.0.0/16の VPCの場合、10.100.0.0/16以外のルートを持つルートエントリー（10.100.1.0/24など）は許可されません。その結果、FortiGate-VM NGFWなどの仮想ネットワークセキュリティアプライアンスへのトラフィックステアリングをネイティブで行う方法がないため、VPC内トラフィックインスペクション機能に制限が生じます。ただし、いくつかの回避策と代替的な設計により、AWS

にある水平方向トラフィックインスペクションの不足部分を補うことができます。

ホストルートテーブルのアップデート：AWS VPCサブネットで起動するすべての EC2インスタンスのホストルートテーブルでは、デフォルトゲートウェイは、Amazonがそのサブネットのデフォルトゲートウェイとして予約した IPアドレスに設定されています。ユーザーはこのデフォルトゲートウェイを変更し、FortiGateファイアウォールのネットワークインタフェースをポイントすることが可能です。インスタンスの数が限定される場合は、このアプローチを推奨します。数を増やす場合には、ユーザーデータやその他のツールを使ってルートテーブルのアップデートを自動化する方法があります。

マルチ VPC設計：AWSは、VPCレベルでのネットワークセグメンテーションを推奨しています。このアプローチでは、サブネットレベルではなく VPCレベルでワークロードをグループ化します。VPC間のトラフィックはすべて、個々の VPCまたは共有 VPCにおいて、ネットワークセキュリティ仮想ファイアウォールによって検査されます。これを、大規模環境で自動実行するには、Transit VPCや AWS Transit Gatewayのような設計パターンを使用できます。

FortiGateが AWSで実現する高可用性と耐障害性前述のように、クラウドには固有のセキュリティの課題があり、それに対応するには革新的なアプローチが必要になります。本番環境に NGFWセキュリティソリューションを導入するユーザーは、高可用性と耐障害性の設計を極めて重視しています。フォーティネットは、このニーズに応えるために、AWSで FortiGate NGFWを導入するうえで耐障害性にすぐれたさまざまなアーキテクチャをサポートしています。

図 12：FortiGate-VMによるアウトバウンドトラフィックインスペクション




Web サーバー



18


オンプレミスネットワークへのアウトバウンド接続における耐障害性

クラウドにワークロードを移行する企業が急増する一方で、その多くはオンプレミスにも多くのワークロードを残すことを考えています。高スループット FortiGate NGFWを、AWS VPC内の VPNゲートウェイとして導入し、VPNトンネルを確立することで、クラウドワークロードを物理的なデータセンターへと戻すことができます。図 13で示すように、ペアで導入することで物理データセンターへのアウトバウンド接続の耐障害性を実現できます。

AWS VPC内での VPNトンネルの終端には、AWS仮想プライベートゲートウェイを使用することが可能ですが、サポートできる帯域幅が格段に大きい点で、FortiGate NGFWを使用することを強く推奨します。

図 13は、2つのアベイラビリティゾーンに FortiGate VMを 2つ導入することで、耐障害性を実現する構成例です。各プライベートサブネットのルートテーブルでは、それぞれのアベイラビリティゾーンにある FortiGateの ENI-1をポイントするルートが含まれています。1つのアベイラビリティゾーンでダウンタイムが発生しても、他のアベイラビリティゾーン内のワークロードのアウトバウンド接続は維持されます。

FortiGate NGFWは BGPをサポートするため、ユーザーのゲートウェイも BGPをサポートする場合には、オンプレミスネットワークからルートを動的に学習します。さらに、それぞれの FortiGateは、インターネット行きの全トラフィックのデフォルトゲートウェイとして機能します。

ユニキャスト HAを使ったアクティブ / パッシブ構成

これまで、ユーザーはデータセンター内で FortiGate NGFWの高可用性構成を行うことで、FortiGate Clustering Protocol（FGCP）によるセッション同期と耐障害性を実現してきました。このプロトコルで使用するハートビートトラフィックはマルチキャストパケットを使用しますが、AWS

VPCネットワーキングでは、マルチキャスト / ブロードキャストパケットは使用できません。

FortiGateインスタンスのペアがセッションを同期できる AWS環境をサポートするために、フォーティネットはユニキャスト HAを提供しています。これは、AWS向けのアクティブ / パッシブクラスタリングソリューションです。このソリューションは、マスターとスレーブとして構成した 2つの FortiGateインスタンスと連携します。この 2つのインスタンスは、単一 VPC内にある同じアベイラビリティゾーン内の同じサブセットに導入する必要があります。この 2つの FortiGateインスタンスは、論理的な単一のインスタンスとして動作し、同じインタフェース IPアドレスを共有します。構成を同期することで、スタンドアロンの FortiGateと同じ方法でクラスタを構成することが可能になります。フェイルオーバーが発生すると、クラスタは素早く自動的に復旧します。管理者に通知が送信されるため、障害の原因となった問題を修正し、ダウンしたリソースのリストアを行うことができます。

図 13：物理データセンターのアウトバウンド接続で耐障害性を実現

Web

サーバー

Web

サーバー





ルートテーブルプライベートサブネット

― Availability Zone 1

データセンター / 支社


ルートテーブルプライベートサブネット

― Availability Zone 2

宛先

宛先

ターゲット

ターゲット

AWS Cloud

Availability Zone 1

Availability Zone 2

19


インバウンドフェイルオーバーでは、ENI0\port1のセカンダリ IPアドレスを、FortiGate 1のパブリックインタフェースから FortiGate 2のパブリックインタフェースへと再割り当てします。さらに、ENI0\port1のセカンダリ IPアドレスに関連付けられている EIPを、FortiGate 1

のパブリックインタフェースから FortiGate 2のパブリックインタフェースへと再割り当てします。

アウトバウンドフェイルオーバーでは、ENI 1\port2のセカンダリ IPアドレスを、FortiGate 1

のプライベートインタフェースから FortiGate 2のプライベートインタフェースへと再割り当てします。また、FortiGate 1のプライゲートインタフェースを参照するルートターゲットは更新され、FortiGate 2のプライベートインタフェースを参照します。図 14と図 15は、AWS

VPCにおける FGCPのフェイルオーバープロセスを示しています。

アクティブ / パッシブ環境の耐障害性 - 2つのアベイラビリティゾーン

従来の物理的なデータセンターのように、完全なセッション同期機能を備えた HAソリューションを求める AWSユーザーがいる一方で、多くのユーザーは、耐障害性（複数の AZ）を備えた環境の整備により、可用性に優れたセキュリティサービスを実現しようとしています。フォーティネットは、Lambdaベース、デュアル AZ、アクティブ / パッシブフェイルオーバーを特徴とするソリューションを提供しています（詳細はこちら 2をご覧ください）。このソリューションは、TCPヘルスチェックによって AWS EIPとルートテーブルを自動更新し、2つの異なるアベイラビリティゾーンにある 2つの異なる FortiGateインスタンスで送受信トラフィックの

AWSでの FGCPコンポーネント

n 2つの FortiGate NGFW。それぞれが4つのネットワークインタフェースを持つ

n 2つの専用 ENI。1つはパブリックインタフェース用（ENI0\port1）、もう 1つはプライベートインタフェース用（ENI1\port2）です。この ENIは、セカンダリ IPアドレスを使用します。これによって、両方の FortiGateインスタンスが、実際の FortiOS構成 / 同期セッション内で、同じ IPアドレスをネイティブに共有することが可能になります。AWSでは ENIのプライマリ IP

を変更できないため、セカンダリIPアドレスを使用する必要がある点に注意してください。

n クラスタ EIPは、現在のマスターFortiGateインスタンスのパブリックインタフェース（ENI0\port1）のセカンダリ IPに関連付けられ、新しくマスターとなった FortiGate

インスタンスへの関連付けが再度行われます。

n FGCP HA通信専用の ENI（ENI2\

port3）。ハートビートチェック、構成の同期、セッションの同期といったタスクを実行

n 各インスタンスへの管理アクセスを行う専用 ENI（ENI3\ port4）。また、これによって各インスタンスは、パブリック AWS EC2 APIとの独立した直接通信を実行

n AWS IAMロール。このロールを引き継ぐことで、FortiOSは AWS

EC2 APIへのアクセスを承認され、ルートテーブルの更新やクラスタ EIPの再割り当てといったアクションを実行できるようになります。

図 14：AWSでの FortiGate FGCPの導入

パブリックサブネット（データ）パブリックサブネット（管理）

セカンダリ IP:

セカンダリ IP:

プライベートサブネット（データ）プライベートサブネット（ハートビート）セカンダリ IP:

セカンダリ IP:


AWS Cloud

Availability Zone 1

図 15：AWSでの FortiGate FGCPのフェイルオーバープロセス

パブリックサブネット（データ）パブリックサブネット（管理）

セカンダリ IP:

セカンダリ IP:

プライベートサブネット（データ）プライベートサブネット（ハートビート）セカンダリ IP:

セカンダリ IP:


AWS Cloud

Availability Zone 1

2 「AWS-CloudFormationTemplates/Templates/LambdaAP-EIP+RouteFailover/6.0/」GitHub（英語）： https://github.com/fortinet/aws-cloudformation-templates/tree/master/LambdaAP-EIP%2BRouteFailover/6.0

https://github.com/fortinet/aws-cloudformation-templates/tree/master/LambdaAP-EIP%2BRouteFailover/6.0



20


フェイルオーバーを行います。このソリューションは、主に 2つのコンポーネントで構成されます。1つ目のコンポーネントは、インスタンスのパブリックインタフェース（ENI0\port1）です。これには、プライマリ / セカンダリ IPアドレスが割り当てられています。いずれのインスタンスでも、専用 EIPがパブリックインタフェースのプライマリ IPに関連付けられています。さらに、アクティブインスタンスでは、パブリックインタフェースのセカンダリ IPに Floating EIPが割り当てられています。2つ目のコンポーネントは、インスタンスのプライベートインタフェース（ENI1\

port2）です。これには、プライマリ IPアドレスのみが割り当てられています。

Lambda Function：TCPヘルスチェックと AWS VPCネットワーキングの更新には、1つの Lambda Functionが使用されます。この Lambda

Functionは、両方のインスタンスについて、ENI1のプライマリ IPの TCPヘルスチェックを、アクティブインスタンスから実行します。

CloudWatchイベントルール：単一の CloudWatchイベントルールを使用して、Lambda Functionをスケジュールに従って（毎分）トリガーします。

API Gateway：FortiOSスティッチアクションで Lambda Functionをアドホックベースでトリガーする操作には、APIゲートウェイが使用されます。FortiGate NGFWの動的なブートストラップが行われ、リンクモニターを使用してプライベートインタフェース（ENI1\port2）を介した相互監視（ping）を実行します。また、スティッチが構成され、リンクモニターのステータスが変化した場合に APIゲートウェイを介して Lambda

Functionをトリガーできるようになります。

VPCエンドポイント：EC2の VPCインタフェースエンドポイントが作成されます。これによって Lambda Functionは、ユーザーの VPC内からプライベート IPで AWS EC2 APIと FortiGateインスタンスの両方にアクセスできるようになります。

ヘルスチェックでアクティブインスタンスが不合格、パッシブインスタンスが合格となった場合、Lambda Functionは、ENI0または ENI1をポイントしているアクティブインスタンスのルートを、パッシブインスタンスへと更新します。EIPの中に、アクティブインスタンスの ENI0のセカンダリ IPに関連付けられているものがある場合には、パッシブインスタンスへと変更されます。次に、「ha:status」タグの値が入れ替わり、現在のアクティブインスタンスとパッシブインスタンスが正しく参照されます。図 17は、現在アクティブなインスタンス（FGT-1）から現在パッシブなインスタンス（FGT-2）へとフェイルオーバーする状態を示しています。導入方法の詳細についてはこちら 3の「Lambdaベース、デュアル AZ、アクティブ / パッシブフェイルオーバー」の項目をご覧ください。

図 16：FortiGateデュアル AZによるアクティブ / パッシブ HA

パブリックサブネットパブリックサブネット

プライベートサブネットプライベートサブネット

セカンダリ IP: セカンダリ IP:

プライマリ IP: プライマリ IP:


宛先宛先ターゲットターゲット

Region

3 「AWS-CloudFormationTemplates/Templates/LambdaAP-EIP+RouteFailover/6.0/」GitHub（英語）： https://github.com/fortinet/aws-cloudformation-templates/tree/master/LambdaAP-EIP%2BRouteFailover/6.0




21


アウトバウンドトラフィックの耐障害性 - アクティブ / アクティブフェイルオーバー

アクティブ / パッシブ構成は耐障害性に優れたアーキテクチャではありますが、稼働できるFortiGateインスタンスは 1つに限定されます。アクティブ / アクティブ FortiGateフェイルオーバー（図 18）では、AWSルートテーブルを自動更新することで、異なるアベイラビリティゾーンにある 2つの独立した FortiGateインスタンスで送信トラフィックフローを処理します。いずれの FortiGateインスタンスも同時に稼働し、トラフィックを処理します。ただし、このソリューションで実現できるのは、VPCから出て行くアウトバウンドトラフィックの耐障害性のみです。インバウンドトラフィックの耐障害性を実現するには、AWS ELBや Route 53サービスといった外部リソースを利用できます。インバウンドトラフィックを対象にしたファイアウォールの耐障害性については、本書の「設計パターン」のセクションをご覧ください。

図 18のソリューションは、前のセクションで説明した Lambdaベースのアクティブ / パッシブ構成に非常に類似しており、同じコンポーネントで構成されています。

アクティブ / アクティブな

アウトバウンドトラフィックの

コンポーネント

n FortiGateインスタンス

n Lambda Function

n CloudWatchイベントルール

n API Gateway

n VPCエンドポイント

図 17：FortiGateデュアル AZのアクティブ / パッシブ HAによるフェイルオーバープロセス



セカンダリ IP: セカンダリ IP:




Region

図 18：FortiGateアクティブ / アクティブ構成でアウトバウンドトラフィックの耐障害性を実現






Region

22


大きな違いは、2つのアベイラビリティゾーンにあるルートテーブルに、異なる FortiGateプライベートインタフェースをポイントするルートエントリーが含まれているという点です。これにより、トラフィックの発生元となる送信元のアベイラビリティゾーンに基づいて、両方の FortiGateインスタンスが利用可能になります。図 19は、この設計のフェイルオーバープロセスを示しています。現在ポイントしている FortiGate 1のプライベートインタフェースを、FortiGate 2のプライベートインタフェース（ENI1）へと更新することで、アウトバウンドフェイルオーバーが実現されます。

FortiGate 1がオンラインに復帰し、ヘルスチェックに合格した時点で、AZ1のルートリストが更新されて FortiGate 1がポイントされ、AZのローカルインスタンスになります。

AWS SDNとタグの更新は、VPCエンドポイントインタフェースを介して、Lambda Functionが APIコールを起動することで行われます（VPC内で Lambdaが自動生成した ENIから実行）。導入方法の詳細についてはこちら 4をご覧ください。

図 19：FortiGateアクティブ / アクティブ耐障害性構成によるアウトバウンドトラフィックのフェイルオーバープロセス






Region

4 「AWS-CloudFormationTemplates/Templates/LambdaAA-RouteFailover/6.0/」GitHub（英語）： https://github.com/fortinet/aws-cloudformation-templates/tree/master/LambdaAA-RouteFailover/6.0

https://github.com/fortinet/aws-cloudformation-templates/tree/master/LambdaAA-RouteFailover/6.0



23


設計パターン本書の前のセクションでは、AWSの主な概念と FortiGateの導入モデルについて詳しく説明しました。このセクションでは、さまざまな AWSサービスと設計パターンを使用して、物理的なデータセンターの一部または全部を AWS環境へと移行するユーザーを対象に、拡張性に優れた自動セキュリティソリューションを提供する方法を説明します。インフラストラクチャのセキュリティ設計では、次の内容を検討する必要があります。

拡張性：Transit VPCなどの設計パターン、Transit Gateway、単一 VPCの設計のどれが最適なのかは、ユーザー環境に存在する VPCの数に応じて決まります。また、ルーティング要件も設計に影響を及ぼします。

自動化：AWS などのクラウドには分散 / 動的という特性があるため、Terraform やCloudFormationの IaaC（コードとしてのインフラストラクチャ）ツールも極めて重要です。さらに、AWS Auto Scalingなどの AWSネイティブサービスも、AWSの柔軟性を効率化かつ自動化する上で役立ちます。

高可用性と耐障害性：本番環境でワークロードを処理するユーザーにとって、優れた耐障害性と可用性を備えたセキュリティソリューションは、データとアプリケーションの保護に理想的です。FortiGateの耐障害性オプションと AWSのマネージドサービスは、このニーズに応えることができます。

FortiGateオートスケーリングによる柔軟なロードバランシングのサンドイッチ構成

AWS ELB（Elastic Load Balancing）は、AWS環境向けのロードバランシングサービスです。ELBは受信アプリケーショントラフィックを分散し、トラフィックのニーズに合わせてリソースを拡張します。高スループット NGFWを求めるユーザーは、FortiGateインスタンスを AWS

ELB / AWS Auto Scalingと統合することで、トラフィックの変動に対応できます。FortiGate

NGFWインスタンスは、オートスケーリンググループ内にあり、AWSの外部向け NLB（Network

Load Balancer）の前に置かれます。内部向け NLBをもう 1つオプションで使用し、プライベートサブネット内にあるバックエンドサーバーへとトラフィックを分散することも可能です。この構成は、FortiGateインスタンスが 2つの NLBに挟まれているため、ELBサンドイッチと呼ばれます。

この設計の主なコンポーネント

n AWSベストプラクティスに従って、パブリック / プライベートサブネットで構成された VPC。この環境では、2つのアベイラビリティゾーンで耐障害性を高めます。

n パブリックサブネット内の FortiGate

ホスト。自動スケーリンググループ内にあり、AWSセキュリティグループを補完します。これにより、レイヤー 7のセキュリティ機能（侵入検知、Webフィルタリング、脅威検知など）が提供されます。

n パブリックサブネット内の FortiGate

NGFW。NAT ゲートウェイとして機能し、プライベートサブネット内のリソースのアウトバウンドインターネットアクセスを可能にします。また、FortiGate NGFWインスタンスによるアウトバウンドトラフィックインスペクションも実行されます。

n 外部向けの NLB。内部向けの NLB

はオプションです。

n Amazon API ゲートウェイ。

FortiGateオートスケーリンググループのコールバック URLを提供することで、フロントドアとして機能します。

n Lambda Function。スケーリング、フェイルオーバー管理、その他の関連コンポーネントの構成を行います。

n Amazon DynamoDBデータベース。フォーティネットが提供するスクリプトを使用して、自動スケーリングの条件ステートに関する情報を格納します。

図 20：ELBサンドイッチ構成での FortiGateオートスケーリング

AWS Cloud

Region

Availability Zone 1 Availability Zone 2

オートスケーリンググループ

外部向け

内部向け

ネットワークロードバランサー

ネットワークロードバランサー



FortiGate ゲートウェイ

FortiGate ゲートウェイ

保護された Webサーバー

保護された Webサーバー

24


FortiGateは、APIゲートウェイを使用して APIコールを送信します。そして、FortiGate Config-

Syncタスクを処理し、オートスケーリングイベントの実行時に、複数の FortiGateインスタンス全体でオペレーティングシステム構成を同期します。現在、これは VPCの内部使用に限定されており、パブリックアクセスはできません。

既存の VPC内にあるプライベートサブネット内のWebサーバーへの受信リクエストは、インターネットゲートウェイ、ネットワークロードバランサー、FortiGateオートスケーリンググループを介して送られ、Webサーバーへと到達します。Webサーバーは、同じ接続を使って応答を返します。

Webサーバーからの送信リクエストは、個々の FortiGate NATゲートウェイとインターネットゲートウェイを介して、外部ネットワークへと送られます。外部ネットワークは、同じパスを使って応答を返します。

このソリューションは完全に自動化され、既存の VPCと新しい VPCのいずれにも導入可能です。この構成は、AWSクイックスタートガイドとして提供されています。

Transit VPC

ほとんどの AWS環境は、単一の VPCから始まり、複数のリージョンにまたがる複数の VPCへと拡張していきます。ただし、複数の VPCで構成される環境の場合、VPC間接続には VPCピアリングを使用した明示的なピアリングが必要であり、非常に複雑になります。また、VPCピアリングでは、VPC間のトラフィックフローをユーザーが制御することはできません。もう 1

つのアプローチとして、オンプレミスデータセンター内でホストするファイアウォールなどの物理ゲートウェイにトラフィックをバックホールし、VPC間通信を行う方法もあります。ただしこのアプローチでは、クラウドトラフィックをオンプレミスへとバックホールするため、トラフィックが宛先に到達するまでに遅延が生じます。この問題は、Transit VPCでハブ &スポークトポロジを構成することによって解決できます。ハブ VPCで仮想ファイアウォールをホストし、スポークVPCをハブファイアウォールで相互接続します。この構成では、クラウドトラフィックがユーザーの AWS環境外に出ることはありません。

多彩なルーティング機能と強力なアプリケーションセキュリティ機能を備えた AWS上のFortiGate-VMは、優れたセキュリティ、高スループット、自動化を特徴とする Transit VPC環境を実現します。VPC間通信とオンプレミスデータセンターへの接続に対応します。

Fortinet Transit VPCの

主なコンポーネント

n Transit VPCでアクティブ / アクティブモードで構成された 2つのFortiGateインスタンス

n Transit VPC（ハブ）とアプリケーション VPC（スポーク）

n 各スポーク VPCで構成された AWS

VPNゲートウェイ

n 2つの Lambda Function（仮想プライベートゲートウェイポーラーとフォーティネットVPNコンフィギュレーター）

n AWS CloudWatchイベントルール

n オプションの物理データセンター（カスタマーゲートウェイ）

図 21：Transit VPC


25


Fortinet Transit VPCの導入には、AWS CloudFormationテンプレートを使用できます。Transit VPCの作成が完了すると、Lambda自動化インフラストラクチャがスポーク VPCを Transit VPCに接続します。Lambda Function（仮想ゲートウェイポーラーと Fortinet Configurator）が連携し、仮想プライベートゲートウェイの検出と、FortiGateへの VPN接続の構成を行います。

仮想プライベートゲートウェイポーラーが仮想プライベートゲートウェイをチェックする処理では、CloudFormationテンプレートで指定されたタグを検索し、Transit VPCアカウント内の仮想プライベートゲートウェイをチェックします。“transitvpc:spoke=true”タグのペアを持つ VGWが見つかると、Fortinet Configuratorの Lambda Functionは VPN接続を定義し、FortiGate構成をプッシュして IPsecトンネルを作成します。Lambda

Poller Functionは CloudFormationで指定された S3バケットにファイルを作成し、構成すべき内容をコンフィギュレーターに通知します。VPN接続に関連付けられたパラメータと構成は、すべて S3バケットに保存されます。PUT S3バケットイベントは、もう 1つの Lambda Function（Fortinet

Configurator）をトリガーします。図 22は、Fortinet Transit VPCアーキテクチャを示しています。

BGPピアリングセッションは、スポーク VPC仮想プライベートゲートウェイと Transit VPC FortiGate間で確立されます。BGPセッションは、Transit VPC自動化フレームワークで生成された VPN IPsecトンネルを介して確立されます。

Fortinet Transit VPCは、複数のアカウントと複数のリージョンをまたいでスポーク VPCを接続することができます。

詳しくは、フォーティネットの「AWS TRANSIT VPC WITH FORTIGATE NEXT-GENERATION FIREWALL」5（英語）をご覧ください。

耐障害性 FortiGate構成と AWS Transit Gatewayの統合

Fortinet Transit VPCのような Transit VPCの導入は、VPC間接続とセキュリティ要件に対応できるアプローチです。一方で、AWS仮想プライベートゲートウェイは、各 VPCスポークに導入され、VPN接続を終端しますが、帯域幅に深刻な制限があり、ネットワークパフォーマンスが低下します。

この問題を解決するために、AWS Transit Gatewayは、大規模な接続にも対応できる拡張性を備えた分散サービスを新たに提供しています。このサービスは ECMP（等価コストマルチパス）ルーティングをサポートし、トラフィックは、同じ IPプレフィックスを伝搬する複数の VPN接続に対して均等に配分されます。その結果、ネットワークの柔軟性が大幅に向上します。AWSスイートの一部であるため、CloudFormationや CloudWatch

といったネイティブサービスや VPCフローログを使用して、AWS Transit Gatewayの管理と監視を実行できます。

AWS Transit Gatewayは、垂直と水平を含むあらゆる方向のトラフィックのルーティングを実行できます。フォーティネットのクラウドサービスハブは、AWS Transit Gatewayサービスを活用することで、複数の重要なユースケースを実現し改善します。

図 22：Fortinet Transit VPCアーキテクチャ


オンプレミスの

企業 DC

Spoke VPC 2 – プライベートサブネットルートテーブル

宛先アクティブターゲット伝搬


キー：

値：

5 「AWS TRANSIT VPC WITH FORTIGATE NEXT-GENERATION FIREWALL」フォーティネット（英語）： https://www.fortinet.com/content/dam/fortinet/assets/deployment-guides/dg-fortigate-transit-vpc.pdf

https://www.fortinet.com/content/dam/fortinet/assets/deployment-guides/dg-fortigate-transit-vpc.pdf



26


ハイブリッドクラウド：一般的なハイブリッドクラウド環境では、複数のリモート支社、企業データセンター、アプリケーション VPC間を、大量のデータが常に移動しています。フォーティネットのクラウドサービスハブは、クラウド内に中央のハブ VPCを作成することで、相互接続性とトラフィックインスペクションを容易にします。クラウドサービスハブでは、ECMPを拡張性に優れた方法で使用します。アプリケーション VPC

は Transit Gatewayに直接アタッチできますが、物理データセンターやリモート支社は、クラウドサービスハブ内の FortiGate NGFWに接続することが可能です。

インバウンドアプリケーショントラフィックでファイアウォール耐障害性を実現：VPC内のプライベートサブネットにアプリケーションを導入する方法は、パブリック IPアドレスを必要としないという点で、多くのユーザーに好まれる方法です。ただし、外部からの攻撃からアプリケーションを保護する必要があります。フォーティネットのクラウドサービスハブは、AWS Transit Gatewayと統合することで、プライベート VPCにWeb

アプリケーションを導入できる利便性があり、耐障害性に優れた FortiGate NGFWをパブリック VPCで実装することによってアプリケーションを保護できます。図 23では、2つの FortiGate NGFWの前面に、インターネットに面している AWS Load Balancerがあります。バックエンドサービスが、Transit Gatewayに接続された 2つのスポーク VPCに実装されています。

水平方向のトラフィックインスペクション：ゼロトラストのセキュリティ導入戦略は小規模から大規模な企業に採用されていますが、この戦略では、すべてのトラフィックを検査することが極めて重要になります。最近の調査によると、クラウドトラフィックの大半が環境内を水平方向に移動します。

フォーティネットのクラウドサービスハブは、すべてのトラフィックを調査することで、脅威の水平移動を阻止します。その 1つの方法が、Transit Gatewayサービスを使用して AWS Transit Gatewayにルートテーブルを複数作成する方法です。このアプローチでは、FortiGateの高度なセキュリティ機能で、VPC間トラフィックの一部またはすべてを調査できます（さらに、セキュリティファブリック全体に導入されているその他のセキュリティソリューションを使用）。インスペクションの対象となるトラフィックはすべて、フォーティネットのクラウドサービスハブに導入されている FortiGateソリューションに送信されます。

図 24で示すように、この環境では、2つの Transit Gatewayルートドメインが使用されます。1つは、すべてのスポーク VPCにアタッチしているルートテーブル、もう 1つはクラウドサービスハブ VPCにアタッチしているルートテーブルです。フローのアフィニティを保証するために、送信元NATを各 FortiGate NGFWで適用する必要があります。さらに、各スポーク VPCルートテーブルには、クラウドサービスハブに戻るルートも必要です。

図 24の構成は、アクティブ / アクティブ FortiGate構成を前提とします。または、FortiGateをアクティブ / パッシブで実装する Transit Gateway

とクラウドサービスハブ間で、Transit Gatewayアタッチメントを作成することもできます。この構成では送信元の NAT指定が不要であるため、水平トラフィックインスペクションで送信元 IPアドレスを維持したい場合に適しています。

図 23：インバウンドトラフィックのファイアウォール耐障害性を実現する Transit Gateway

AWS Cloud

Availability Zone 2Availability Zone 1



Transit Gateway アタッチメント


27


まとめクラウドを導入する組織が増加する今、クラウドジャーニーの早い段階で要件に適したセキュリティアーキテクチャを設計することが極めて重要になっています。AWSにおけるフォーティネット FortiGate-VMは、さまざまな構成と設計モデルをサポートし、AWSユーザーが求める拡張性、可用性、耐障害性の要件を満たします。さらに、ネイティブ AWSサービスや自動化フレームワークとの統合により、FortiGate NGFWは動的な拡張性を自動的に実現し、トラフィックの変動にも対応します。フォーティネットのセキュリティファブリックコネクタは AWSとネイティブに統合することで、FortiGateインスタンス全体の管理やファイアウォールポリシーの適用を自動化します。

図 24：FortiGate NGFWと AWS Transit Gatewayによる VPC / VPCトラフィックインスペクション

企業のデータセンター /

支社

FortiGateに戻るルート – NATプール

SNATを適用してフローアフィニティを保証

クラウドサービスハブ

Cloud Services Hub ルートドメインVPCルートドメイン

Spoke（VPC-B）ルートテーブル

宛先

VPNアタッチメント

ターゲット


Copyright© 2020 Fortinet, Inc. All rights reserved. この文書のいかなる部分も、いかなる方法によっても複製、または電子媒体に複写することを禁じます。この文書に記載されている仕様は、予告なしに変更されることがあります。この文書に含まれている情報の正確性および信頼性には万全を期しておりますが、Fortinet, Inc. は、いかなる利用についても一切の責任を負わないものとします。Fortinet®、FortiGate®、FortiCare®、および FortiGuard® は Fortinet, Inc. の登録商標です。その他記載されているフォーティネット製品はフォーティネットの商標です。その他の製品または社名は各社の商標です。

〒106-0032東京都港区六本木 7-7-7　　Tri-Seven Roppongi 9 階www.fortinet.com/jp/contact

WP-AWS-Reference-Architecture-202001-R1

Documents

Amazon Web Services（AWS）リファレンスアーキ …...本書の主な目的は、AWSのセキュアなアーキテクチャの設計原則とガイドラインを説明するこ