aws blackbelt aws上でのddos対策
TRANSCRIPT
【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
DDoS攻撃について
DDoS対策の考え方
AWS上でDDoS対策を行う際のベストプラクティス
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
DDoS攻撃について
DDoS対策の考え方
AWS上でDDoS対策を行う際のベストプラクティス
DDoS対策の考え方
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サービスリソース枯渇
正規ユーザー
DDoS対策の考え方
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攻撃
ユーザー
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層攻撃緩和
✓ ✓ ✓ ✓ ✓
DDoS対策の考え方
24
3つの軸で考える 対策層「高さ」
「幅」 「深さ」対策場所
「幅」:対策の種類には幅がある
25
地理的分離分散
攻撃対象隠ぺい攻撃吸収・緩和 計画・監視
設計 技術 運用
ベストプラクティス対応表 (対策種類 x 対策場所)
26
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)
地理的分離分散
✓ ✓ ✓
攻撃対象隠ぺい
✓ ✓ ✓ ✓ ✓
攻撃吸収・緩和
✓ ✓ ✓ ✓ ✓ ✓
計画・監視 ✓ ✓ ✓ ✓ ✓ ✓
DDoS対策の考え方
27
3つの軸で考える 対策層「高さ」
「幅」対策種類
「深さ」対策場所
アジェンダ
28
DDoS攻撃について
DDoS対策の考え方
AWS上でDDoS対策を行う際のベストプラクティス
DDoS対策参照アーキテクチャ―
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
ベストプラクティス対応表 (対策種類 x 対策場所)
30
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)
地理的分離分散
✓ ✓ ✓
攻撃対象隠ぺい
✓ ✓ ✓ ✓ ✓
攻撃吸収・緩和
✓ ✓ ✓ ✓ ✓ ✓
計画・監視 ✓ ✓ ✓ ✓ ✓ ✓
エッジでの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エッジロケーション
ベストプラクティス対応表 (対策種類 x 対策場所)
33
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)
地理的分離分散
✓ ✓ ✓
攻撃対象隠ぺい
✓ ✓ ✓ ✓ ✓
攻撃吸収・緩和
✓ ✓ ✓ ✓ ✓ ✓
計画・監視 ✓ ✓ ✓ ✓ ✓ ✓
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
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セキュリティグループ
ベストプラクティス対応表 (対策種類 x 対策場所)
40
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)
地理的分離分散
✓ ✓ ✓
攻撃対象隠ぺい
✓ ✓ ✓ ✓ ✓
攻撃吸収・緩和
✓ ✓ ✓ ✓ ✓ ✓
計画・監視 ✓ ✓ ✓ ✓ ✓ ✓
不正な通信の検知とブロック(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
[参考] 拡張ネットワーキング
• 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)が非常に大きく、ネットワーク遅延が小さくなるオプション
回復力を考慮したリージョンの選択(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/
ベストプラクティス対応表 (対策種類 x 対策場所)
53
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)
地理的分離分散
✓ ✓ ✓
攻撃対象隠ぺい
✓ ✓ ✓ ✓ ✓
攻撃吸収・緩和
✓ ✓ ✓ ✓ ✓ ✓
計画・監視 ✓ ✓ ✓ ✓ ✓ ✓
運用による対策:攻撃の可視化
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
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層攻撃緩和
✓ ✓ ✓ ✓ ✓
Shield Standard対応表 (対策種類 x 対策場所)
63
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)
地理的分離分散
✓ ✓ ✓
攻撃対象隠ぺい
✓ ✓ ✓ ✓ ✓
攻撃吸収・緩和
✓ ✓ ✓ ✓ ✓ ✓
計画・監視 ✓ ✓ ✓ ✓ ✓ ✓
Shield Advanced対応表 (対策種類 x 対策場所)
64
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)
地理的分離分散
✓ ✓ ✓
攻撃対象隠ぺい
✓ ✓ ✓ ✓ ✓
攻撃吸収・緩和
✓ ✓ ✓ ✓ ✓ ✓
計画・監視 ✓ ✓ ✓ ✓ ✓ ✓
より高度な検知能力
設計レビューによる支援
ランブックによる支援
まとめ
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
Q&A
67
オンラインセミナー資料の配置場所
• AWS クラウドサービス活用資料集– http://aws.amazon.com/jp/aws-jp-introduction/
• AWS Solutions Architect ブログ– 最新の情報、セミナー中のQ&A等が掲載されています
– http://aws.typepad.com/sajp/
68
公式Twitter/FacebookAWSの最新情報をお届けします
69
@awscloud_jp
検索
最新技術情報、イベント情報、お役立ち情報、お得なキャンペーン情報などを日々更新しています!
もしくはhttp://on.fb.me/1vR8yWm
AWSの導入、お問い合わせのご相談
AWSクラウド導入に関するご質問、お見積り、資料請求をご希望のお客様は以下のリンクよりお気軽にご相談くださいhttps://aws.amazon.com/jp/contact-us/aws-sales/
※「AWS 問い合わせ」で検索してください
71