アプリケーションのセキュリティ向上のための edge service …aws cliを使って...

© 2016, Amazon Web Services, Inc. or its Affiliates. All rights reserved.

Prasad Kalyanaraman, VP Edge Services

June 2016

アプリケーションのセキュリティ向上のためのEdge Serviceの戦略とベスト・プラクティス

このセッションの目的

• なぜセキュリティが重要か

• セキュリティの３つの重要な側面

• どのようにAWSのEdgeのインフラを活用できるか

• アプリケーションのセキュリティ向上のため何ができるか

概要: なぜセキュリティが重要か

• 顧客の信頼

• 企業コンプライアンス

• データ・プライバシー

• 保護

プレゼンテーションの目的は不安を煽ることではありません

むしろご安心下さい :1) AWS側で実施されるセキュリティ対策がたくさんあります2) 簡単なベスト・プラクティスを守るだけでも結果が得られます

一例として、2015年のDDoS攻撃の下位90%は30Gbps以下でアタックの平均サイズは15.8Gbpsでした

DDoS攻撃の大半は、シンプルなテクニックを幾つか守ることで簡単に緩和できます

DDoS攻撃の測定データ

• インフラへの攻撃 (Layer 3 / 4)– 攻撃の平均サイズは 900Mbps (50% は、500Mbps以下)

– 攻撃の78% は、インフラが対象 (実行が簡単なため)

– この種類の攻撃はAWSが緩和します

• アプリケーションへの攻撃 (Layer 7)– 攻撃の22% は、ポート80と443が対象 (攻撃が複雑)

• マルチベクター –同時に複数種類の攻撃

• 増幅型(Amp) (NTP, SSDP, DNS, Chargen, SNMP)

• Hit and Run DDoS (91% が1時間以内) 、煙幕型 (16-18%)

セキュリティの３つの側面

クラウドのセキュリティは責任共有モデルがベースhttps://aws.amazon.com/compliance/shared-responsibility-model/

Encrypt data in transit

Encrypt data at rest

Protect your AWS Credentials

Rotate your keys

Secure your application, OS,

Stack and AMIs

Enforce IAM policies

Use MFA, VPC, Leverage

S3 bucket policies

EC2 Security groups

EFS in EC2, ACM, etc.

SOC 1,2,3

ISO 27001/2 Certification

PCI DSS 2.0 Level 1-5

HIPAA/SOX Compliance

FedRAMP, FISMA &

DIACAP ITAR

AWSが提供するインフラをどのように守っているか

どのようにアプリケーションを守るか

AWSのお客様が利用可能なセキュリティのオプションや機能

インフラストラクチャセキュリティ

アプリケーションセキュリティ

サービスセキュリティ

インフラストラクチャのセキュリティ

AWSは、どのようにインフラを保護しているか

インフラストラクチャ

セキュリティアプリケーション

セキュリティ

サービス

セキュリティ


施設・設備

物理セキュリティ

キャッシュインフラ

ネットワークインフラ

Layer 3&4 DDoS対策

+ =

AWSユーザの責任は?

セキュアなアプリケーション


• メンテナンス用の踏み台(bastion)サーバ

• 二要素認証

• 暗号化

• 隔離をより有効にするための分離

• テストや指標の監視

x


ISO 9001/27001/27017/27018

AWSインフラのDDoS緩和

AWS global infrastructure

DDoS 攻撃

ユーザ

AWS

DDoS 緩和

AWS

DDoS 緩和

DDoS 緩和のテクニック

基本的な確認

• IP チェックサム

• 有効なTCPフラグ

• UDP ペイロードの長さ

• DNSリクエストの認証

トラフィックの優先順位付け

• ソースIP

• ソースASN

• トラフィック量

• 認証済みの送信元

Distributionのシグネチャー

• 個別のDistributionを区別する

高度なトラフィックエンジニアリング

• 自動的に攻撃のトラフィックを検知

• 攻撃と通常トラフィックのルーティングを別ける

AWS API GatewayCloudFrontは、自社製のDDoS対策のインフラでAPI Gatewayを守りTLSの終端をプロキシー側で行うことによりレスポンスタイムを短縮

Amazon

EC2

Amazon API

Gateway

グローバル 55箇所のEdge Location

DDoS 攻撃

健全なリクエスト

ユーザに近い場所でTLSの終端

悪意のあるリクエスト

通常のリクエスト

健全なリクエスト

サービスのセキュリティ

エッジサービスで利用可能なセキュリティのオプションと機能(CloudFront & Route53)


セキュリティ

アプリケーション

セキュリティ

サービス

セキュリティ

サービスのセキュリティ

強度の高い暗号化

PFS

OCSP Stapling

セッションチケット

DDoS 対策

SSL/TLSオプション

プライベートコンテンツ

信頼された署名者

Web Application Firewall

AWS CloudTrail

AWS Certificate Manager

+ =


セキュアなアプリケーション

CloudFrontは‘転送中のデータ’を保護できる

CloudFrontによる転送データの保護

Origin

Edge

Location

User Request A

• 転送中のデータを保護するためにコンテンツはHTTPSで配信

• HTTPSでユーザはCloudFrontを認証する

• HTTPSはCloudFrontはオリジンを認証する

CloudFrontは、高度なSSLの機能を自動的に有効化

高度なSSL/TLS機能

セキュリティの向上

• High security ciphers

• Perfect Forward Secrecy

SSL パフォーマンス

• Online Certificate Status Protocol

(OSCP Stapling)

• Session Tickets

ですが、やるべき事がいくつかあります

HTTPSを使ったコンテンツ配信

• CloudFrontで簡単に実現

• 一つのdistribution設定でHTTP/HTTPSの両方のコンテンツを配信

• 以下の選択肢もあります

• Strict HTTPS

• HTTP を HTTPSへリダイレクト

CloudFront TLS Options

デフォルトのCloudFront SSL

CloudFront の共有証明書

どのようなケース?

例: dxxx.cloudfront.net

SNI 独自SSL

自前でSSL証明書を用意

または、 AWS Certificate Managerで発行

TLSのSNI extensionを利用


例: www.mysite.com

SNI extensionに非対応の古いブラウザー/OSが一部あります

専用 IP独自SSL自前でSSL証明書を用意

または、 AWS Certificate Managerで発行

CloudFrontでSSLコンテンツの配

信用に専用のIPを割り当てます


例: www.mysite.com

すべてのブラウザー/OSが対応

ACM導入前 (複雑で時間がかかる)

第三者の認証局(CA)

3-5 日

AWS CLIを使ってIAMにアップロード

AWS CLIを使ってCloudFrontに接続

ACM導入後 (簡潔で素早く、自動化)

AWS

Certificate

Manager

数分ですべてのプロセスが完了

管理コンソール上で数クリックで実行

AWS Certificate Managerとの連携

MapBox

MapBox： SNI Custom SSLを利用

• 専用ドメインでの配信を希望

xxxxx.mapbox.com

• クライアントはすべて TLSに対応

• 経済的な選択肢を検討

HTTPS の利用パターン

• ハーフブリッジ型TLS 終端

• フルブリッジ型TLS 終端

フルブリッジ型TLS終端

Amazon

CloudFrontHTTPS

• オリジンまでのコネクションをすべてHTTPS化

• CloudFront設定の[Match Viewer] を選択

MapBoxはオリジンを複数利用

• 複数のAPIのオリジンを使用

• １つ目はハーフブリッジ型: Edge・オリジン間はHTTP

• ２つ目はフルブリッジ型: Edge・オリジン間もHTTPS

まだ終わっていません…

次は、アプリケーションの保護が必要です

アクセス制御

もし以下のことをしたい場合…

• 一部の限られたお客様にだけコンテンツを配信

• 決められた時間までにだけコンテンツを公開したい

• 特定のIPのみコンテンツへのアクセスを許可

アクセス制御: プライベートコンテンツ

署名付きURL

• URLのクエリストリングに署名を追加

• URLが署名の箇所で変わる

どのよな時に使うべきか?

• 個別のファイルへのアクセスを制限する

• Cookieに対応しないクライアントがある

• RTMP ディストリビューションを使いたい

署名付きCookies

• Cookieに署名を追加

• URL は変わらない

どのような時に使うべきか?

• 複数のファイルへのアクセスを同時に制限したい

• URLを変更したくない

アクセス制御: プライベートコンテンツ

アプリケーションはまだ開発中ですか?

CloudFront へのアクセスを“InternalのIP アドレス”のみに制限してください

まだ終わっていません…

リクエストのパラメータをもとにアクセスを制限したい場合はどうすべきでしょうか？

不必要なリクエストへの応答はお金がかかります

スクレイパー・ボット

Host: www.internetkitties.com

User-Agent: badbot

Accept: image/png,image/*;q=0.8,*/*;q=0.5

Accept-Language: en-US,en;q=0.5

Accept-Encoding: gzip, deflate

Referer: http://www.InTeRnEkItTiEs.com/

Connection: keep-alive

AWS WAFHost: www.internetkitties.com

User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64)…..




Referer: http://www.mysite.com/


アクセス制御: Web Application Firewall

スクレイパー・ボット

Host: www.internetkitties.com

User-Agent: badbot




Referer: http://www.InTeRnEkItTiEs.com/


AWS WAFHost: www.internetkitties.com

User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64)…..




Referer: http://www.mysite.com/


MapBox WAFをBotをブロックしています

一般ユーザ

悪意のあるユーザ

サーバ

ログ

分析

ルール・アップデータ

防御に自動化が必要な攻撃

HTTP floods Scans & probesIP reputation lists Bots & scrapers

Attackers

AWS CloudTrail

CloudFront API コールの履歴を記録:

• セキュリティ分析

• リソースの変更管理

• コンプライアンスの監査

アプリケーションのセキュリティ

どのようにアプリケーションとオリジンを守るか


セキュリティ

アプリケーション

セキュリティ

サービス

セキュリティ

Application Security

IAM ポリシー

Origin Protection

OAI

鍵のロテーション

証明書のロテーション

+ =


セキュアなコンテンツ配信

ハッカーはCloudFrontを迂回して直接オリジンにアクセスできます…

アクセス制御: オリジンのAccess制限

Amazon S3

Origin Access Identify (OAI)

• Amazon S3バケットへの直接のアクセスを防ぐ

• すべてのお客様にとってパフォーマンス面での利点がある

カスタム Origin

IPアドレスのブロック

Pre-shared Secret Header

• CloudFrontだけをホワイトリストに追加

• オリジンをオーバーロードから保護

• すべてのお客様にとってパフォーマンス面での利点がある

オリジンのベスト・プラクティス

1. Match Viewer

Origin Protocol ポリシー

• オリジンではTLS 1.1

か1.2 のみを許可

• オリジンへのコネクションはHTTPSを強制

• フルブリッジの

HTTPSを必ず利用

2. セキュリティグループや Shared Secretをつかってアクセスを制限

3. SHA256の証明書を利用

オリジンのベスト・プラクティス

4. ELBで独自証明書を利用する

5. ELB 事前定義ポリシーを利用 6. HSTS ヘッダーを送る

*Strict-Transport-Security: max-age=15552000;

*X-Frame-Options: SAMEORIGIN

*X-XSS-Protection: 1; mode=block Options

AWS Certificate Managerから証明書を発行できます

現在の設定内容を検証する方法

セキュリティの設定を検証する方法

https://www.ssllabs.com

アプリケーションのセキュリティ向上のための edge service …aws cliを使って...

Documents