概要
http://media.amazonwebservices.com/jp/DDoS%20White%20Paper_Revised.pdf
awsでwebinarがあったので、昼飯がてら見ました。
メモ
途中からなのをお知らせします。
責任共有モデル
- 客側とAWS側で責任を分割共有する
的を絞る
- IPやポートを絞るなど
- NAT Gateway
- 別にAWS使わなくてもDMZとかつかえばいいんじゃない？っていうツッコミ
スケーリングする
DDos対策
- 適切なインスタンス
- コスト < ネットワーク接続
- 拡張ネットワーキング
- ELB
- 特定インスタンスの過負荷を防ぐ
- インターネットの公開はELBだけ
- ACLとかセキュリティグループを利用して、有効なTCPリクエスストだけをサポートするのでDDoS攻撃を絞れる
- AutoScaling
- EC2インスタンスを負荷やスケジュールで自動削減
- 注意 サーバ起動と設定に時間がかかるので設定をチューニングすること
- 注意 監視しつつ、メトリックスを特定すること
- 注意 キャパシティをもったリソースを確保すること
- 注意 Availability Zoneは2つ以上を推奨
- 注意 断続的なDDoSもあり得るので、スケールアップ/スケールダウンをやるタイミングを考えること
- 注意 Auto ScalingグループでのEC2インスタンスの最大数 コストが増えるのでインスタンスの最大数を考える事
- EC2インスタンスを負荷やスケジュールで自動削減
- CloudFront
- トラフィックの効率的な分散配信
- プラス、トラフィックのフィルタリングもできる
- Route53
- 攻撃側はSPOFを狙いやすく、DNSはSPOFとして狙われやすい(リフレクター攻撃など)
- DNSサービスとしてのRoute53 高いトラフィックに対してもサービスを継続できる
- シャッフルシャーディング
- リクエストの分散
- Anycastルーティング
- 冗長性を上げる
- ヘルスチェックとDNSフェイルオーバー
- 正常なリソースだけをつかう
公開されたリソースを保護
- アプリケーションのエンドポイントを減らせない
CF/WAFなど
CloudFront
- 固有のIDをもたせている
- DDoSのトラフィックを学習してフィードバック
- 他と隔離して影響を与えない仕組み
- DDoS攻撃排除例
- 2時間近く大規模な攻撃が行われた
- アプリケーションのレスポンスはほとんど変わらず
- セキュア配信のために
- GEOリストリクション(攻撃側の地域/アプリケーションの顧客の地域が自明であるばあいは、他国からのアクセスを排除するように出来る)
- オリジンサーバの保護(オリジン側のアドレスを公開しない、CloudFrontが許可したIPだけを許可)
- CloudFrontとAWS WAFの連携
- Route53による保護 ALIASレコード(Route53固有の仮想リソースレコード)
- Route53によるプライベートDNS
- Web Application Firewall(WAF)
- HTTPレート制限 HTTPリクエストのしきい値を確立
- HTTPリクエスト検査 通常のパターンに準拠しない奴を検査
- AWS WAFとMarketplaceを併用したりする
WAFサンドイッチ
- WAFでサンドイッチさせて処理する ELBとELBのあいだにWAFを挟む
DDoSにも様々なパターンがある(アプリケーション層/トランスポート層/ネットワーク層)
通常時の動作を学習
- 攻撃を受けていることを検知
- 請求を指標 など
- CloudWatch logsでログ監視
- DDoSだけじゃなく、アプリケーションリソースの監視
攻撃に対する計画を作成
- 攻撃をされているときに対応を立てても意味が無い
アーキの検証してインフラにとって有効な手法を選択
攻撃/課金の問題
- 利用コストがかかる
- コストやサービス継続に対する許容度は政治
- 対応/対策の規模
- 組織のセキュリティのリスクアセスメント
DDoSだけが攻撃ではない
- アクセスコントロール、アラートやログで「何が起きているか」を判定
サービスを一時停止する判断も必要
エンタープライズのサポートも使える(15分以内のエンジニアアサイン テクニカルサポートなど 緊急度の高いインシデントに対応できる)
まとめ
責任共有モデル
- AWSが共有出来るサービス
- 場合によってはサードパーティを利用したソリューションも
