AWS BlackBelt AWS上でのDDoS対策

【AWS Black Belt Online Seminar】AWS 上での DDoS 対策

アマゾンウェブサービスジャパン株式会社

セキュリティソリューションアーキテクト

桐山隼人

2017.09.05

@hkiriyam1

氏名: 桐山隼人

役割: セキュリティソリューションアーキテクト

業務: 顧客提案、ソリューション開発、市場開拓

プロフィール:

外資系総合IT会社の開発研究所にて開発エンジニア、

セキュリティベンダーにて技術営業を経た後、現職。

MBA, PMP, CISSP, CISA, セキュリティ関連特許多数。

クラウドセキュリティに関するセミナー登壇・記事寄稿など。

自己紹介

RSA Conference 2017 APJ「Cloud Security Strategy」Session Speaker

AWS Startup Security Talks「セキュリティ意識が低いCEOはあり得ない」(ITpro)

AWS Summit Tokyo 2017「AWSで実現するセキュリティ・オートメーション」(マイナビニュース)

「IoTビジネスとセキュリティを3段階と4要素で理解する」記事寄稿

内容についての注意点

• 本資料では2017年9月5日時点のサービス内容および価格についてご説明しています。最新の情報はAWS公式ウェブサイト(http://aws.amazon.com)にてご確認ください。

• 資料作成には十分注意しておりますが、資料内の価格とAWS公式ウェブサイト記載の価格に相違があった場合、AWS公式ウェブサイトの価格を優先とさせていただきます。

• 価格は税抜表記となっています。日本居住者のお客様が東京リージョンを使用する場合、別途消費税をご請求させていただきます。

• AWS does not offer binding price quotes. AWS pricing is publicly available and is subject to change in accordance with the AWS Customer Agreement available at http://aws.amazon.com/agreement/. Any pricing information included in this document is provided only as an estimate of usage charges for AWS services based on certain information that you have provided. Monthly charges will be based on your actual use of AWS services, and may vary from the estimates provided.

3

アジェンダ

4

DDoS攻撃について

DDoS対策の考え方

AWS上でDDoS対策を行う際のベストプラクティス

アジェンダ

5




Distributed Denial of Service (DDoS) 攻撃

6

DoS攻撃 DDoS攻撃

複数の攻撃元が協調して、大量のパケットやリクエストを標的に送りサービスを停止させる攻撃

DDoS脅威の増大

7

内閣サイバーセキュリティセンター(NISC)「2020年及びその後を見据えたサイバーセキュリティの在り方について－サイバーセキュリティ戦略中間レビュー－」(2017年7月13日)より抜粋

2016年9月20日 Krebs on SecurityのWebサイトに過去最大の665GbpsのDDoS攻撃

2016年10月21日 Dyn Managed DNSがDDoS攻撃により停止。Netflix, Twitter, Spotify, GitHubなどが一時使用不能に

「IoTボットネットによるDDoS脅威は今後も増大する」と明記される

金銭目的の脅威の変化

8

入口対策出口対策

データ侵害

ランサムウェア

DDoS攻撃

企業に侵入し機密情報を不正に取得入口対策と出口対策を要突破取得した情報を売却

企業内データを暗号化し身代金要求入口対策を要突破ビットコインによる身代金受取

企業の公開サーバーをサービス停止にいつでも攻撃可能ランサムDDoSという形態の登場攻撃者が最も楽に利益を得る手段

DDoS攻撃の種類

9

# 層単位説明攻撃例

7 アプリケーションデータアプリケーション通信

HTTPフラッドDNSクエリフラッド

6 プレゼンテーションデータデータ表現と暗号 SSL不正

5 セッションデータホスト間通信 N/A

4 トランスポートセグメント End-to-end接続 SYNフラッド

3 ネットワークパケット通信経路のルーティング

UDP反射攻撃

2 データリンクフレーム物理アドレス指定 N/A

1 物理ビットメディア、信号、バイナリ転送

N/A

インフラ層への攻撃アプリ層への攻撃

アジェンダ

10





11

3つの軸で考える

「高さ」

「幅」「深さ」

「高さ」：レイヤー(層)毎に攻撃とその対策が異なる

12

ボリューム攻撃処理出来る能力を超えたトラフィックを送りつける(例：UDP 反射攻撃)

状態枯渇攻撃ファイヤウォールや、IPS,ロードバランサなどの状態を管理しなければならないプロトコルに負荷をかける(例：TCP SYN フラッド)

アプリケーション層攻撃一見、適切に構成されているが悪意のある要求を使用して、アプリケーションリソースを消費する(例： HTTP GET, DNS クエリフラッド）

攻撃例：UDP反射攻撃

13

攻撃者は発信元IPを偽装

標的に大きな応答パケットを送りつける

要求と応答のパケットのサイズ差を利用(DNSでは28～54倍の差)

攻撃例：SYNフラッド

14

クライアントから意図的にACKを返さない

サーバーは返答を待ち続けける

新しいユーザーがサーバーに接続できなくなる

攻撃例：DNSクエリフラッド

15

ボットネットと呼ばれる複数の感染ホストを利用

DNSサーバーに大量のクエリを同時に送り付ける

正規ユーザーがDNSサーバーを利用できなくなる

DNSクエリ

DNSサービスリソース枯渇

正規ユーザー


16

3つの軸で考える対策層「高さ」

「幅」「深さ」

「深さ」：対策場所はエッジからリージョンまで

17

Amazon

Route 53

Amazon

EC2ELB

Amazon

CloudFrontAWS WAF

ユーザーAWS WAF

AWSエッジロケーション

AWSリージョン

アプリの種類によって対策場所は異なる

ウェブアプリケーションの場合

18

HTTP/SによるステートレスなWebアプリケーション

対策特徴：エッジでAWS WAF, CloudFrontを利用し、オリジンへの直接攻撃を阻止

クライアント/サーバーアプリケーションの場合

19

TCPによるステートフルな処理でクライアント/サーバー間セッション維持

対策特徴：EC2の垂直スケール、拡張ネットワーキングで大量トラフィック吸収

20

ゲームアプリケーションの場合

TCP/UDPでユーザー-ホスト間接続を維持し、ニアリアルタイム処理

対策特徴：特定IPからの通信を許可するセキュリティグループ

DDoS対策参照アーキテクチャ―

21

Amazon

Route 53

ELB SG

Amazon EC2 インスタンス

Elastic Load

Balancing

Amazon

CloudFront

Public subnet

Web Application SG

Private subnet

AWS WAF

Amazon

API Gateway

DDoS攻撃

ユーザー


22

Amazon

Route 53

ELB SG

Amazon EC2

インスタンス

Elastic Load

Balancing

Amazon

CloudFront

Public subnet

Web Application SG

Private subnet

AWS WAF

Amazon

API Gateway

DDoS攻撃

ユーザー

BP2 BP1

BP3 BP4

BP5

BP6

BP7

BP: Best Practice

ベストプラクティス対応表 (対策層 x 対策場所)

23

AWSエッジロケーション AWSリージョン

Amazon CloudFrontwith AWS WAF(BP1, BP2)

Amazon Route 53(BP3)

Amazon API Gateway(BP4)

Amazon VPC(BP5)

Elastic Load Balancing(BP6)

Amazon EC2 with Auto Scaling(BP7)

第7層攻撃緩和

✓ ✓ ✓ ✓

第6層攻撃緩和

✓ N/A ✓ ✓

第4層攻撃緩和

✓ ✓ ✓ ✓

第3層攻撃緩和

✓ ✓ ✓ ✓ ✓


24


「幅」「深さ」対策場所

「幅」：対策の種類には幅がある

25

地理的分離分散

攻撃対象隠ぺい攻撃吸収・緩和計画・監視

設計技術運用

ベストプラクティス対応表 (対策種類 x 対策場所)

26





Amazon VPC(BP5)




✓ ✓ ✓

攻撃対象隠ぺい

✓ ✓ ✓ ✓ ✓

攻撃吸収・緩和

✓ ✓ ✓ ✓ ✓ ✓

計画・監視 ✓ ✓ ✓ ✓ ✓ ✓


27


「幅」対策種類

「深さ」対策場所

アジェンダ

28





29

Amazon

Route 53

ELB SG

Amazon EC2

インスタンス

Elastic Load

Balancing

Amazon

CloudFront

Public subnet

Web Application SG

Private subnet

AWS WAF

Amazon

API Gateway

DDoS攻撃

ユーザー

BP2 BP1

BP3 BP4

BP5

BP6

BP7

BP: Best Practice


30





Amazon VPC(BP5)




✓ ✓ ✓


✓ ✓ ✓ ✓ ✓


✓ ✓ ✓ ✓ ✓ ✓

計画・監視 ✓ ✓ ✓ ✓ ✓ ✓

エッジでのWebアプリケーション配信(BP1,2,3)

31

対策内容対策例

1. 遅延やスループットの最適化

2. DDoSによる可用性への影響の最小化

1. Amazon CloudFrontをCDNとして用いたコンテンツ配信

2. 地理的に離れたエッジロケーション利用

32

North America: 30 South America: 3 Europe / Middle East / Africa: 27

Ashburn, VA (3)

Atlanta, GA (3)

Chicago, IL (2)

Dallas/Fort Worth, TX (3)

Hayward, CA

Jacksonville, FL

Los Angeles, CA (2)

Miami, FL

Minneapolis, MN

Montreal, QC

Newark, NJ

New York, NY (3)

Palo Alto, CA

Philadelphia, PA

San Jose, CA

Seattle, WA (2)

South Bend, IN

St. Louis, MO

Toronto, ON

リージョン別エッジキャッシュ: 9

Oregon, N. Virginia, Frankfurt, Sao

Paulo, Mumbai, Singapore, Seoul,

Tokyo, Sydney

Edge

locationAWS Region /

Regional Edge

Cache

Regional Edge

Cache

Asia Pacific: 22

Rio de Janeiro, Brazil

São Paulo, Brazilc (2)

Amsterdam, The Netherlands (2)

Berlin, Germany

Dublin, Ireland

Frankfurt, Germany (6)

London, England (4)

Madrid, Spain

Marseille, France

Milan, Italy

Munich, Germany

Paris, France (3)

Prague, Czech Republic

Stockholm, Sweden (2)

Vienna, Austria

Warsaw, Poland

Zurich, Switzerland

Chennai, India

Hong Kong, China (3)

Kuala Lumpur, Malaysia

Manila, the Philippines

Melbourne, Australia

Mumbai, India (2)

New Delhi, India

Osaka, Japan

Seoul, Korea (3)

Singapore (2)

Sydney, Australia

Taipei, Taiwan

Tokyo, Japan (4)

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

[参考] AWSエッジロケーション

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

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


33





Amazon VPC(BP5)




✓ ✓ ✓


✓ ✓ ✓ ✓ ✓


✓ ✓ ✓ ✓ ✓ ✓

計画・監視 ✓ ✓ ✓ ✓ ✓ ✓

AWSリソースの隠ぺいオリジンの保護(BP1,2,3)

34

1. セキュリティポリシーの強制適用

2. アクセス経路の制限

1. VPCの中に配置し、セキュリティグループやネットワークACLを利用

2. Amazon CloudFrontにてエッジからオリジンへカスタムヘッダーを付加し、アクセス制限


[参考] オリジンへのアクセス制限

• オリジンがAmazon S3の場合、Origin Access Identity(OAI)を利用– S3のBucketへのアクセスをCloudFrontからのみに制限

• カスタムオリジンの場合、下記の2種類が選択可能– オリジン側のアドレスを公開せず、CloudFrontが利用するIPアドレス(*)からのみ通信を許可

させる

– カスタムヘッダーを利用し、CloudFrontで指定された任意のヘッダーをオリジン側でチェック

CloudFront Edge カスタムオリジンサーバ

S3

クライアント

OAI

IP制限/ヘッダ−制限

クライアント

ダイレクトアクセス

ヘッダー付与

35(*) 下記JSONファイルから、Serviceキーの“CLOUDFRONT”でフィルタすることで抽出可能

https://ip-ranges.amazonaws.com/ip-ranges.json

APIエンドポイントの保護(BP4)

36

1. Web APIサーバーを不必要に外部公開しない

2. 不正APIリクエストからの保護

1. Amazon API Gatewayを利用し、Web API公開サーバーを立てない

2. Amazon API GatewayにおいてAPIリクエストの標準値やバースト値の制限を設ける


[参考] Amazon API Gateway

• 特徴 (http://aws.amazon.com/jp/api-gateway/)

– OS、キャパシティ等インフラの管理不要

– バックエンドとしてLambda、既存Webシステムを利用可能

– スロットリング/キャッシュ

• 価格体系 (http://aws.amazon.com/jp/api-gateway/pricing/)

– 呼び出し回数/データ送出量/キャッシュ容量

– 100万回の呼び出しにつき$3.5

– データ送出量に応じて$0.05/GB～$0.09/GB

– キャッシュ容量に応じて$0.02/時～$3.8/時

Web APIの作成・保護・運用と公開を簡単に

Mobile Apps

Websites

Services

API

Gateway

AWS Lambda

functions

AWS

API Gateway

Cache

Endpoints on

Amazon EC2 /

Amazon Elastic

Beanstalk

Any other publicly

accessible endpoint

Amazon

CloudWatch

Monitoring

http://aws.amazon.com/jp/api-gateway

http://aws.amazon.com/jp/lambda/pricing/

AWSリソースの隠ぺい SG & NACL(BP5,6)

38

1. インスタンスを不必要に外部公開しない

2. ポリシーに基づいたリソースの保護

3. 意図しない送信元IPやプロトコルの通信の遮断

1. ELBによるEC2のインターネットからの隠ぺい

2. セキュリティグループによる保護対象毎のアクセス制限

3. ネットワークACLによるIPアドレス、ポート、プロトコルの基にしたアクセス制限


[参考] セキュリティグループの例

39

• ELBからくるリクエストのみ受け付け

• インスタンスにはVPCのサブネットのアドレスレンジからのプライベートIPアドレスしかアサインされない

• ELB SGからのTCPポート80及び443とSSH踏み台SGからのTCPポート22だけを許可

• インターネットからのTCPポート80と443のみを許可し、リクエストをウェブアプリケーションサーバーセキュリティグループのEC2インスタンスに送信可能に

Web Application セキュリティグループELBセキュリティグループ


40





Amazon VPC(BP5)




✓ ✓ ✓


✓ ✓ ✓ ✓ ✓


✓ ✓ ✓ ✓ ✓ ✓

計画・監視 ✓ ✓ ✓ ✓ ✓ ✓

不正な通信の検知とブロック(BP1,2)

41

1. インフラへの不正通信の阻止

2. アプリケーションへの攻撃の緩和

3. ポリシーに基づいた通信制御

1. AWS Shield StandardによるL3/L4防御

2. Amazon CloudFrontによるオリジンからエッジロケーションへのオフロード

3. Amazon CloudFrontによる地域指定。AWS WAFのルールによる防御


• これまでのDDoS保護経験に基づきL3 / L4自動緩和システムを開発

• CloudFront、Route53エッジロケーションの前にインラインで配置され、すべての着信パケットを検査

• DDoS攻撃の96％を自動軽減

• 追加設定や手数料なし

• 利点

– スケーラビリティと低コスト

– 常時保護

– 自動緩和

– AWSソリューション用に構築

Customer’s Origin

Infrastructure (ELB, EC2, S3,

etc).

CloudFrontRoute 53

CloudFrontRoute 53

DDoS Attack

User

自動緩和システム

Edge Location AWS Region

[参考] AWS Shield L3/L4 自動緩和システム

42

[参考] Amazon CloudFront GEOリストリクション

• 地域指定によるアクセス制御– 接続されるクライアントの地域情報を元に、エッジでアクセス判定

– BlacklistもしくはWhitelistで指定可能

– Distribution全体に対して適用される

– 制限されたアクセスには403を応答

CloudFront Edge

接続クライアントの地域情報をもとに判定

クライアント

GEO Restriction有効

オリジンサーバ

403

43

[参考] エッジでの名前解決(BP3)

44

1. DNS要求への適切な応答

2. DDoS攻撃を受けた際の冗長性と耐障害性の確保

1. Amazon Route 53のトラフィックフロー、遅延ベースルーティング、ヘルスチェック、モニタリング機能による最適な応答

2. Amazon Route 53のシャッフルシャーディングによる冗長性。Anycastルーティングのよる障害分離


• AWS上で高可用性、低レイテンシなアーキテクチャを実現するツール– ポリシーベースの柔軟なトラフィックルーティング、フェイルオーバー、トラフィックフローなど

の機能により、様々な条件に基づくルーティングが可能

– 100%の可用性のSLAを提供

• シャッフルシャーディング– 数多くのエンドポイントに DNS リクエストを分散させ、

アプリケーションの複数のパスとルートを提供

• Anycast ルーティング– 複数の PoP から同じ IP アドレスを通知することで冗長性を高める

– DDoS 攻撃が 1 つのエンドポイントを攻略した場合、シャッフルシャーディングによって障害が分離され、インフラストラクチャに追加のルートが提供される

[参考] Amazon Route 53 (マネージドDNSサービス)

45

大量トラフィックの負荷分散(BP6)

46

1. 1つのインスタンスの処理能力では処理できない大量トラフィックの分散

2. インフラへの不正通信の阻止

1. Elastic Load Balancingによるアプリケーションへの負荷の低減

2. Elastic Load Balancingによる不正TCP接続の拒否。SYNフラッドやUDP反射攻撃からの保護


[参考] ELBとAuto Scalingとの連携

Auto scaling Group

増減

• Auto Scalingによるインスタンス増減時にELBへの追加・削除が可能

• ELBのヘルスチェックの結果をAuto Scalingに反映可能

• インスタンス削減時は、Connection Drainingでの処理中の接続を待つ

• 利用例

–一定間隔でレスポンスをチェックし、遅延が増加したらインスタンスを自動追加

– ELBのヘルスチェックが成功したEC2インスタンスを常にX台以上

47

大量トラフィックを捌くインスタンスの選択(BP7)

48

1. 垂直スケール

2. 水平スケール

3. 帯域の大きいネットワークインターフェース

1. Amazon EC2のスケールアップ

2. Auto Scalingによるスケールアウト

3. より大きな帯域のネットワークインターフェース選択、拡張ネットワーキング機能有効化


[参考] Elastic Network Interfaces (ENI)

• VPC上で実現する仮想ネットワークインタフェース

• 以下をENIに紐づけて維持可能

– Private IP

– Elastic IP

– MACアドレス

– セキュリティグループ

• インスタンスによって割り当て可能な数が異なる

eth0: 192.168.1.10

eth0:172.16.3.1

eth1:10.3.5.2

利用例2:1インスタンスに複数NIC

利用例1:インスタンス障害時に待機インスタンスにNICを付け替え

http://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/using-eni.html49

http://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/using-eni.html

[参考] 拡張ネットワーキング

• Intel 82599 Virtual Function (VF) インターフェイス

– C3、C4、D2、I2、R3、M4 (m4.16xlarge を除く) インスタンスに対して最大 10 Gbps のネットワーク速度をサポート

• Elastic Network Adapter (ENA)

– F1、G3、I3、P2、R4、X1 およびm4.16xlarge インスタンスに対して最大 20 Gbps のネットワーク速度をサポート

http://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/enhanced-networking.html

VMM

NIC NIC

VF1 VF2 VF3

Switch

通常拡張ネットワーキング

50

パケット毎秒(PPS)が非常に大きく、ネットワーク遅延が小さくなるオプション

http://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/enhanced-networking.html

回復力を考慮したリージョンの選択(BP7)

51

1. 要件に基づいた配備

2. 安定した回線環境

1. パフォーマンス・コスト・データ統制要件に基づいたリージョン選択

2. 信頼度の高い通信キャリアとのInternet Exchangeが近いリージョン


[参考] AWSグローバルインフラストラクチャー

52

16のリージョン, 44のアベイラビリティーゾーンAWS GovCloud (2) ※カッコ内の数はアベイラビリティゾーン米国西部オレゴン (3)、北カリフォルニア (3)米国東部バージニア北部 (6)、オハイオ (3)カナダ中部 (2)南米サンパウロ (3)欧州アイルランド (3)、フランクフルト (3)、ロンドン (2)アジアパシフィックシンガポール (2)、シドニー (3)、東京 (3)、ソウル (2)、ムンバイ (2)中国北京 (2)

新しいリージョン (近日追加予定)パリ寧夏 (Ningxia)、香港ストックホルムAWS GovCloud (米国東部)

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


53





Amazon VPC(BP5)




✓ ✓ ✓


✓ ✓ ✓ ✓ ✓


✓ ✓ ✓ ✓ ✓ ✓

計画・監視 ✓ ✓ ✓ ✓ ✓ ✓

運用による対策：攻撃の可視化

54

1. トラフィックの通常状態の把握し、異常状態を検知できるようにする

2. DDoS攻撃に関係するメトリクスを定義し、必要に応じて担当者に通知する

1. VPC Flow Logsを用いてトラフィック可視化する

2. Amazon CloudWatchメトリクスを用いてログ記録し、事前定義した閾値を超えたらイベントを飛ばす


[参考] DDoS関連のCloudWatchメトリクス例

55

名前空間メトリクス説明名前空間メトリクス説明

CloudFront Requests HTTP/Sリクエスト数 ELB BackendConnectionErrors

失敗したコネクション数

CloudFront TotalErrorRate

全リクエスト中HTTPステータスコード4xx/5xxの割合

ELB SpilloverCount キュー飽和により拒否されたリクエスト数

Route53 HealthCheckStatus

ヘルスチェックエンドポイントのステータス

Auto Scaling

GroupMaxSize オートスケーリンググループの最大サイズ

ELB SurgeQueueLength

ロードバランサーでバックエンド応答を待っているリクエスト数

EC2 CPUUtilization CPU使用率

ELB UnHealthyHostCount

AZ中のunhealthyなインスタンス数

EC2 NetworkIn ネットワークインターフェースでの受信バイト数

ELB RequestCount

登録インスタンスに転送した処理済みリクエスト数

DDoSProtection

DDoSAttackBitsPerSecond

DDoS攻撃の秒あたりビット数(0より大はDDoS攻撃検知)

ELB Latency ロードバランサーがリクエストを転送してから応答までの経過時間(秒)

DDoSProtection

DDoSAttackRequestsPerSecond

DDoS攻撃の秒あたりリクエスト数(0より大はDDoS攻撃検知)

運用による対策：計画とレビュー

56

1. アプリケーションを配備する前に設計レビューを行う

2. 実際の攻撃が受けた場合のインシデント対応フローを確立する

3. インシデント対応後の運用レビューを行う

1. AWS Solutions Architect によるWell-Architectedレビュー

2. DDoS Response Teamの設計レビュー、インシデント対応フロー(ランブック)の共有

3. AWS Technical Account Manager による運用レビュー


[参考] AWS Shield Advanced DDoS Response Team

24x7でDDoS Response Team(DRT)へアクセス可能

57

AWSとAmazon.comを保護する知識と経験を持ったDDoSの専門家チーム

サポートケース経由でのアクセス

• 事前の構成相談対応• クリティカルで緊急の優先順位のケースはす

ぐに回答され、DRTに直接ルーティング• 複雑なケースは、DRTにエスカレーションするこ

ともできます

58

AWS ShieldA Managed DDoS Protection Service

AWS Shield

Standard Protection Advanced Protection

全てのAWSユーザに適用

無料

より大規模な、より洗練された攻撃からの防御を提供する

有料

59

AWS Shield Standard

Layer 3/4 protection

一般的な攻撃（SYN/UDP

フラッド、反射攻撃等）から防御

自動検知＆自動緩和

AWSサービスにビルトイン済

Layer 7 protection

Layer 7のDDoS攻撃への緩和は

AWS WAFで行う

セルフサービス

使った分だけの支払い

60https://aws.amazon.com/jp/shield/tiers/ http://docs.aws.amazon.com/ja_jp/waf/latest/developerguide/ddos-overview.html#types-of-ddos-attacks

AWS Shield Advanced

Shield Standardによる保護に加え、以下の機能による包括的なDDoS対策ソリューションを提供

• DDoS Response Team• L7 DDoS Protection• Cost Protection• Advanced Mitigation• Reporting

61 AWS Black Belt Online Seminar AWS Shield

https://www.slideshare.net/AmazonWebServicesJapan/aws-black-belt-online-seminar-2017-aws-shield/

*詳細は、以下AWS Shield Black Belt Online Seminar 資料をご参照ください


Shield Standard対応表 (対策層 x 対策場所)

62





Amazon VPC(BP5)



第7層攻撃緩和

✓ ✓ ✓ ✓

第6層攻撃緩和

✓ N/A ✓ ✓

第4層攻撃緩和

✓ ✓ ✓ ✓

第3層攻撃緩和

✓ ✓ ✓ ✓ ✓

Shield Standard対応表 (対策種類 x 対策場所)

63





Amazon VPC(BP5)




✓ ✓ ✓


✓ ✓ ✓ ✓ ✓


✓ ✓ ✓ ✓ ✓ ✓

計画・監視 ✓ ✓ ✓ ✓ ✓ ✓

Shield Advanced対応表 (対策種類 x 対策場所)

64





Amazon VPC(BP5)




✓ ✓ ✓


✓ ✓ ✓ ✓ ✓


✓ ✓ ✓ ✓ ✓ ✓

計画・監視 ✓ ✓ ✓ ✓ ✓ ✓

より高度な検知能力

設計レビューによる支援

ランブックによる支援

まとめ

65

全ての企業・組織にとってDDoS対策の重要性は増してきている

DDoS対策を「対策層 x 対策場所 x 対策種類」の軸で考える

AWSクラウドにおけるDDoS対策のベストプラクティスを参考にして対策を実施する

参考資料

• AWS Best Practices for DDoS Resiliency Whitepaper– https://d0.awsstatic.com/whitepapers/Security/DDoS_White_Paper.pdf/

• Denial of Service Attack Mitigation on AWS– https://aws.amazon.com/jp/answers/networking/aws-ddos-attack-

mitigation/

• AWS Black Belt Online Seminar AWS Shield– https://www.slideshare.net/AmazonWebServicesJapan/aws-black-belt-

online-seminar-2017-aws-shield/

66

http://aws.amazon.com/jp/ec2/

https://aws.amazon.com/jp/answers/networking/aws-ddos-attack-mitigation/ttp:/aws.amazon.com/jp/documentation/ec2/


Q&A

67

オンラインセミナー資料の配置場所

• AWS クラウドサービス活用資料集– http://aws.amazon.com/jp/aws-jp-introduction/

• AWS Solutions Architect ブログ– 最新の情報、セミナー中のQ&A等が掲載されています

– http://aws.typepad.com/sajp/

68

http://aws.amazon.com/jp/aws-jp-introduction/

http://aws.typepad.com/sajp/

公式Twitter/FacebookAWSの最新情報をお届けします

69

@awscloud_jp

検索

最新技術情報、イベント情報、お役立ち情報、お得なキャンペーン情報などを日々更新しています！

もしくはhttp://on.fb.me/1vR8yWm

AWSの導入、お問い合わせのご相談

AWSクラウド導入に関するご質問、お見積り、資料請求をご希望のお客様は以下のリンクよりお気軽にご相談くださいhttps://aws.amazon.com/jp/contact-us/aws-sales/

※「AWS 問い合わせ」で検索してください

https://aws.amazon.com/jp/contact-us/aws-sales/

71

Technology

AWS BlackBelt AWS上でのDDoS対策