翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

# アタックサーフェスリダクション
<a name="attack-surface-reduction"></a>

 AWS ソリューションを設計する際のもう 1 つの重要な考慮事項は、攻撃者がアプリケーションをターゲットにする機会を制限することです。この概念は、アタック*サーフェスリダクション *と呼ばれます。インターネットに公開されていないリソースは攻撃するのが難しく、攻撃者がアプリケーションの可用性をターゲットにするためのオプションが制限されます。

 例えば、ユーザーが特定のリソースと直接やり取りすることを期待しない場合は、それらのリソースにインターネットからアクセスできないことを確認してください。同様に、通信に必要のないポートやプロトコルで、ユーザーや外部アプリケーションからのトラフィックを受け入れないでください。

 次のセクション AWS では、攻撃対象領域を減らし、アプリケーションのインターネットへの露出を制限する際のベストプラクティスを提供します。

# 難読化 AWS リソース (BP1、BP4、BP5）
<a name="obfuscating-aws-resources-bp1-bp4-bp5"></a>

 通常、ユーザーは AWS リソースをインターネットに完全に公開することなく、迅速かつ簡単にアプリケーションを使用できます。

# セキュリティグループとネットワーク ACLs (BP5）
<a name="security-groups-and-network-acls-bp5"></a>

 Amazon Virtual Private Cloud (Amazon VPC) では、 の論理的に分離されたセクションをプロビジョニングできます。 AWS クラウド ここでは、定義した仮想ネットワークで AWS リソースを起動できます。

 セキュリティグループとネットワークACLsは、 内の AWS リソースへのアクセスを制御できる点で似ていますVPC。ただし、セキュリティグループを使用すると、インバウンドトラフィックとアウトバウンドトラフィックをインスタンスレベルで制御できますが、ネットワークACLsはVPCサブネットレベルで同様の機能を提供します。セキュリティグループまたはネットワーク の使用には追加料金はかかりませんACLs。

 インスタンスの起動時にセキュリティグループを指定するか、後でインスタンスをセキュリティグループに関連付けるかを選択できます。セキュリティグループへのすべてのインターネットトラフィックは、トラフィックを許可する*許可*ルールを作成しない限り、暗黙的に拒否されます。

 例えば、Elastic Load Balancer の背後に Amazon EC2インスタンスがある場合、インスタンス自体がパブリックにアクセス可能である必要はなく、プライベートIPsのみを持つ必要があります。代わりに、ターゲットグループサブネットのネットワークアクセスコントロールリスト () と組み合わせて 0.0.0.0/0 へのアクセスを許可するセキュリティグループルールを使用して、Elastic Load Balancing に必要なNACLターゲットリスナーポートへのアクセスを Elastic Load Balancer に提供し、Elastic Load Balancing IP 範囲のみがインスタンスと通信できるようにすることができます。 Elastic Load Balancing これにより、インターネットトラフィックが Amazon EC2インスタンスと直接通信できないため、攻撃者がアプリケーションについて学習し、アプリケーションに影響を与えることがより困難になります。

 ネットワーク を作成するときにACLs、許可ルールと拒否ルールの両方を指定できます。これは、アプリケーションへの特定のタイプのトラフィックを明示的に拒否する場合に便利です。例えば、サブネット全体へのアクセスを拒否される IP アドレス (CIDR範囲）、プロトコル、送信先ポートを定義できます。アプリケーションがTCPトラフィックにのみ使用される場合は、すべてのUDPトラフィックを拒否するルールを作成することも、その逆を行うこともできます。このオプションは、DDoSソースIPsやその他の署名がわかっている場合に攻撃を軽減するための独自のルールを作成できるため、攻撃に対応するときに便利です。

 にサブスクライブしている場合は AWS Shield Advanced、Elastic IP アドレスを保護されたリソースとして登録できます。DDoS 保護されたリソースとして登録されている Elastic IP アドレスに対する 攻撃は、より迅速に検出されるため、緩和までの時間が短縮される可能性があります。攻撃が検出されると、DDoS緩和システムはターゲットの Elastic IP アドレスACLに対応するネットワークを読み取り、サブネットレベルではなく AWS ネットワークボーダーに強制します。これにより、多くのインフラストラクチャレイヤーDDoS攻撃による影響のリスクが大幅に軽減されます。

 DDoS 回復性を最適化ACLsするようにセキュリティグループとネットワークを設定する方法の詳細については、[DDoS「攻撃対象領域を減らすことで攻撃に備える方法](https://aws.amazon.com/blogs/security/how-to-help-prepare-for-ddos-attacks-by-reducing-your-attack-surface/)」を参照してください。

 Elastic IP アドレスで Shield Advanced を保護されたリソースとして使用する方法の詳細については、「 を[サブスクライブする AWS Shield Advanced](https://docs.aws.amazon.com/waf/latest/developerguide/enable-ddos-prem.html)」の手順を参照してください。

# オリジンの保護 (BP1、BP5）
<a name="protecting-your-origin-bp1-bp5"></a>

 内のオリジン CloudFront で Amazon を使用している場合はVPC、 CloudFront ディストリビューションのみがオリジンにリクエストを転送できるようにすることをお勧めします。Edge-to-Origin リクエストヘッダーを使用すると、 がリクエストをオリジン CloudFront に転送するときに、既存のリクエストヘッダーの値を追加または上書きできます。*オリジンカスタムヘッダー *、例えば `X-Shared-Secret`ヘッダーを使用して、オリジンに対して行われたリクエストが から送信されたことを検証できます CloudFront。

 オリジン*カスタムヘッダー によるオリジンの保護の詳細については、*「オリジンリクエストへのカスタムヘッダー[の追加](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/add-origin-custom-headers.html)」および[「Application Load Balancer へのアクセスの制限](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/restrict-access-to-load-balancer.html)」を参照してください。 [https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/add-origin-custom-headers.html](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/add-origin-custom-headers.html)

 オリジンアクセス制限の*オリジンカスタムヘッダーの値を自動的にローテーションするサンプルソリューションを実装するガイドについては、*「 [AWS WAF および Secrets Manager で Amazon CloudFront オリジンセキュリティを強化する方法](https://aws.amazon.com/blogs/security/how-to-enhance-amazon-cloudfront-origin-security-with-aws-waf-and-aws-secrets-manager/)」を参照してください。

 または、 [AWS Lambda](https://aws.amazon.com/lambda/)関数を使用して、 CloudFront トラフィックのみを許可するようにセキュリティグループルールを自動的に更新することもできます。これにより、悪意のあるユーザーがウェブアプリケーションにアクセスする AWS WAF ときに CloudFront および をバイパスできないようにすることで、オリジンのセキュリティが向上します。

 セキュリティグループと `X-Shared-Secret`ヘッダーを自動的に更新してオリジンを保護する方法の詳細については、[「Amazon のセキュリティグループを自動的に更新する方法 CloudFront 」および AWS WAFAWS Lambda](https://aws.amazon.com/blogs/security/how-to-automatically-update-your-security-groups-for-amazon-cloudfront-and-aws-waf-by-using-aws-lambda/)「」を参照してください。

 ただし、このソリューションでは、Lambda 関数の実行に追加の設定とコストがかかります。これを簡素化するために、オリジン向け IP アドレスのみ CloudFrontからオリジンへのインバウンドHTTP/HTTPSトラフィックを制限する [AWSの マネージドプレフィックスリスト CloudFront](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/LocationsOfEdgeServers.html#managed-prefix-list)が導入されました。 AWSマネージドプレフィックスリストは によって作成および管理 AWS され、追加料金なしで使用できます。(Amazon VPC) セキュリティグループルール、サブネットルートテーブル、 を使用した一般的なセキュリティグループルール、およびマネージドプレフィックスリスト を使用できるその他の AWS リソース CloudFront で AWS Firewall Manager、 [のマネージドプレフィックスリスト](https://docs.aws.amazon.com/vpc/latest/userguide/working-with-aws-managed-prefix-lists.html)を参照できます。

 Amazon の AWSマネージドプレフィックスリストの使用の詳細については CloudFront、[「Amazon の AWSマネージドプレフィックスリストを使用してオリジンへのアクセスを制限する CloudFront](https://aws.amazon.com/blogs/networking-and-content-delivery/limit-access-to-your-origins-using-the-aws-managed-prefix-list-for-amazon-cloudfront/)」を参照してください。

**注記**  
 このドキュメントの他のセクションで説明したように、オリジンを保護するためにセキュリティグループに依存すると、リクエストのフラッド中に[セキュリティグループ接続の追跡](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/security-group-connection-tracking.html)が潜在的なボトルネックとして追加される可能性があります。キャッシュを有効にするキャッシュポリシー CloudFront を使用して悪意のあるリクエストをフィルタリングできる場合を除き、前述の*オリジンカスタムヘッダー *を使用して、オリジンに対して行われたリクエストがセキュリティグループを使用するのではなく CloudFront、 から送信されたことを検証することをお勧めします。Application Load Balancer リスナールールでカスタムリクエストヘッダーを使用すると、ロードバランサーへの新しい接続の確立に影響する可能性のある追跡制限によるスロットリングを防ぐことができます。これにより、Application Load Balancer は、DDoS攻撃発生時のトラフィックの増加に基づいてスケーリングできます。

# API エンドポイントの保護 (BP4）
<a name="protecting-api-endpoints-bp4"></a>

API を一般に公開する必要がある場合、APIフロントエンドがDDoS攻撃のターゲットになるリスクがあります。リスクを軽減するために、[Amazon API Gateway](https://aws.amazon.com/api-gateway/) を Amazon EC2、、 AWS Lambdaまたはその他の場所で実行されているアプリケーションへのエントリウェイとして使用できます。Amazon API Gateway を使用すると、APIフロントエンドに独自のサーバーが不要になり、アプリケーションの他のコンポーネントを難読化できます。アプリケーションのコンポーネントを検出しにくくすることで、これらの AWS リソースがDDoS攻撃のターゲットにならないようにすることができます。

 Amazon API Gateway を使用する場合、2 種類のAPIエンドポイントから選択できます。1 つ目は、Amazon CloudFront ディストリビューションを介してアクセスされるエッジ最適化APIエンドポイントのデフォルトのオプションです。ただし、ディストリビューションは API Gateway によって作成および管理されるため、ユーザーはディストリビューションを制御できません。2 番目のオプションは、 が AWS リージョン RESTAPIデプロイされているのと同じ からアクセスされるリージョンAPIエンドポイントを使用することです。 AWS では、2 番目のタイプのエンドポイントを使用し、独自の Amazon CloudFront ディストリビューションに関連付けることをお勧めします。これにより、Amazon CloudFront ディストリビューションを制御し、アプリケーションレイヤーの保護に AWS WAF を使用できるようになります。このモードでは、 AWS グローバルエッジネットワーク全体でスケーリングされたDDoS緩和性能にアクセスできます。

 Amazon Gateway AWS WAF で Amazon CloudFront および API を使用する場合は、次のオプションを設定します。
+  すべてのヘッダーを API Gateway リージョンエンドポイントに転送するようにディストリビューションのキャッシュ動作を設定します。これにより、 はコンテンツを動的として扱い、コンテンツのキャッシュをスキップ CloudFront します。
+  API Gateway で[APIキー](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-setup-api-key-with-console.html)値を設定して、オリジンカスタムヘッダー を含めるようにディストリビューションを設定することで x-api-key、APIゲートウェイを直接アクセスから保護します。
+  でメソッドごとに標準またはバーストレート制限を設定することで、過剰なトラフィックからバックエンドを保護しますRESTAPIs。

 Amazon API Gateway APIsで を作成する方法の詳細については、[「Amazon API Gateway](https://aws.amazon.com/api-gateway/getting-started/) [入門](https://aws.amazon.com/api-gateway/getting-started/)」を参照してください。