2016/05/17に開催したSecurity-JAWSにて登壇した時の資料です。

1. 2016/05/17
@tigerszk
Amazon Web Services

2. ⾃自⼰己紹介
Shun Suzaki(洲崎 俊)
ユーザ企業のセキュリティチームに所属する
セキュリティエンジニア
Twitter:
とある診断員@tigerszk
• ISOG-‐‑‒J WG1
• Burp Suite Japan User Group
• OWASP JAPAN Promotion Team
• IT勉強会「#ssmjp」運営メンバー
I‘M A CERTAIN
PENTESTER!
公開スライドなど
http://www.slideshare.net/zaki4649/

3. 脆弱性診断とは
ＦＷ サーバ機器
診断環境 診断対象環境
Ｗｅｂアプリ
NW機器
l システムやアプリケーションの脆弱性を
洗い出し、安全性について調査するサービス
scanning!
×
脆弱性診断⼠士
×
Internet
※図は疑似攻撃試⾏行行するブラックボックステストを⽰示しています
他にも設計書、仕様書、コンフィグファイル、ソースコードなどを分析して、
脆弱性を洗い出すホワイトボックステストなどがあります

4. 診断の種類
OS
ミドルウェア
Webコンテンツ Webアプリケーション診断
ネットワーク診断
（プラットフォーム診断）
Webシステム
l 対象とする領領域によって実施する
診断の種類が異異なる

5. 診断するシステムは？
l 様々なシステムが診断対象となる
l 近年年ではクラウド環境の診断対象が増加
当然AWSも診断対象として登場

6. たまにある質問
Q.AWSを診断する意味あるの？
A.もちろんあります!

7. AWSは責任共有モデル
「責任共有モデル – アマゾン ウェブ サービス (AWS)」より引⽤用 https://
aws.amazon.com/jp/compliance/shared-‐‑‒responsibility-‐‑‒model/

8. EC２などは、OSやアプリケーション
のセキュリティを担保する責任は
ユーザー側にあります

9. AWSを利利⽤用していても
• ACLの設定が適切切ではない
• ミドルウェアの設定に不不備がある
• パッチマネジメントできていない
• Webアプリケーションの作りこみが⽢甘い
脆弱性が存在

10. 「AWS セキュリティのベストプラクティス」
にも テストについて書いてある
「AWS セキュリティのベストプラクティス」より引⽤用
http://media.amazonwebservices.com/jp/wp/AWS_̲Security_̲Best_̲Practices.pdf

11. AWSでも脆弱性検査で
安全性をチェックをしよう！

12. 脆弱性診断するなら
l セキュリティベンダに依頼する
l コストや時間がかけられないなら⾃自分で
チェックするのもOK！
※以下ご参考に
「フリーでやろうぜ！セキュリティチェック！」 http://
www.slideshare.net/zaki4649/free-‐‑‒securitycheck

13. よし！
じゃあ早速診断するか！

14. ちょっと待て

15. 実はAWSでの脆弱性診断では、
いくつか抑えておくべきポイントがある

16. １．診断前に許可申請が必要
「侵入テスト -­‐
AWS
クラウドセキュリティ 」より引用
h'ps://aws.amazon.com/jp/security/penetra;on-­‐tes;ng/

17. ちなみにAWSだけではない
基本的にホスティング環境、クラウドサービスを
利利⽤用している場合には、診断事前にあらかじめ
事業者側に診断実施の許可を得ることが必要
事業者側のポリシーによっては診断⾃自体不不可な
場合もある

18. ２．全部診断できるわけじゃない
• EC2とRDSのインスタンスのみ診断可能
• 以下のインスタンスタイプは診断不不可
RDS:スモールRDSインスタンス、マイクロRDSインスタンス
EC2:m1.small、t1.micro
EC2 RDS

19. 「侵入テスト -­‐
AWS
クラウドセキュリティ 」より引用
h'ps://aws.amazon.com/jp/security/penetra;on-­‐tes;ng/

20. 許可申請は専⽤用のフォームから
AWS 脆弱性/侵⼊入テストリクエストフォーム
https://portal.aws.amazon.com/gp/aws/html-‐‑‒forms-‐‑‒controller
/contactus/AWSSecurityPenTestRequest

21. Contact Information
フォーム項⽬目 記載する内容
Your Name:* 担当者の⽒氏名
Company Name* 会社名
Email Address AWSアカウントのメールアドレス
Additional Email
Address
CCに追加するメールアドレス
Third Party Contact
Information
診断を第三者の会社に委託する場合に記⼊入する
第三者の連絡先
※は必須⼊入⼒力力項⽬目

22. Scan Information
フォーム項⽬目 記載する内容
IP Addresses to be scanned
(Destination)*
診断対象のIPアドレス（ELBも申請可能）
Are the instances the source of the
scan or the target of the scan?*
下の項⽬目で⼊入⼒力力するEC2インスタンスが診断元なのか
診断対象かを選択
Instances IDs* 上記の項⽬目に該当するEC2インスタンスIDを⼊入⼒力力
Scanning IP addresses (Source)* 診断を⾏行行う、接続元のIPアドレスを⼊入⼒力力
Total Bandwidth (Please provide
expected Gbps)*
テストで想定される秒間の転送量量（帯域幅）を⼊入⼒力力
What region are these instances in?* EC2インスタンスがあるリージョンを選択
Timezone* 時刻のタイムゾーンを選択
Start Date and Time (YYYY-‐‑‒MM-‐‑‒DD
HH:MM)*
診断開始時刻
End Date and Time (YYYY-‐‑‒MM-‐‑‒DD
HH:MM)*
診断終了了時刻
Additional Comments 脆弱性診断に関する特記事項などあればコメント
※⾚赤枠の項⽬目は割と最近追加された項⽬目

23. その他
• 以下に同意が必要（規約とかポリシー）
– Terms and Conditions
– AWSʼ’s Policy Regarding the Use of Security
Assessment Tools and Services
• 他注意点
– フォームリスクエストにはroot認証が必要
– 指定できる診断期間は3ヵ⽉月以内
– 2 営業⽇日以内に、申請受理理が届く
– ⼿手続き完了了には数⽇日かかる可能性がある
– 侵⼊入テスト申請の終了了時間は、延⻑⾧長を考えて余裕を
もっておいた⽅方がいいでしょう

24. 参考サイト
• Amazon EC2への侵⼊入テスト申請について ｜
Developers.IO : http://dev.classmethod.jp/
cloud/aws/penetration-‐‑‒testing/
• AWSでの侵⼊入テスト(Penetration Test)につい
て | cloudpack技術情報サイト : https://
blog.cloudpack.jp/2015/01/22/about-‐‑‒aws-‐‑‒
penetration-‐‑‒test/

25. みんなが幸せになるために
ルールをちゃんと守ってね！

26. でも実際に現場でよくある話
l 申請フォーム？なにそれ？おいしいの？
l 明⽇日から診断だけど許可申請するの忘れちゃった！
てへぺろ(・ω<)
l 地雷雷（S3とか診断できないものが）がしれっと
診断対象リストに混⼊入
l CloudFront経由で診断4649ね！
・・・etc

27. 円滑滑に進めるための対策
l ⼤大切切なことを事前に丁寧に説明
l AWSの構成などを事前にヒアリング
l 申請許可のメールをエビデンスとして、
必ず確認してから診断を実施

28. ちょっとした⼩小ネタ

29. AWSを診断する時の
厄介な相⼿手それは…

30. Elastic Load Balancing

31. ELBとは
l ロードバランサーのクラウドサービス
l トラフィックを複数のインスタンスに分
散するヘルスチェック機能を持っている
l ELB⾃自体がトラフィックに応じてスケール
l 暗号化・復復号（SSL）機能を利利⽤用できる

32. l グローバルIPがコロコロ変化する
l 固定IPを設定することはできない
l いつIPが変更更されるかわからない
この仕様が問題

33. この仕様、実は診断⼠士にはツラい…
l そもそもNW診断とかはIPベースで診断を
実施するのが⼀一般的
l ドメイン指定での診断も可能だが、検査
ツールはポートスキャン都度度などに毎回
正引きなどはしない

34. ていうかヤバい…
l もし診断の最中にIPが切切り替わって、
診断パケットが別の環境に⾶飛んでいく
可能性が ((((；ﾟДﾟ))))ｶﾞｸｶﾞｸﾌﾞﾙﾌﾞﾙ
l もしかして関係ない⼈人宛に診断(＝攻撃)しちゃう
んじゃない？それはマジでヤバい！！
※勉強会の質疑の時に、中の⽅方より、「ELBで引い
たIPは、仕様として最低60分は他のIPに紐紐付け
られることがない」というお話を伺いました！
すぐに別の環境にパケットが流流れることはない
ようです。ちょっと安⼼心しました。

35. 参考サイト
l ozumaの⽇日記 ：AWSのELB(Elastic Load
Balancing)は、セキュリティ的に問題ないのか
http://srad.jp/~∼ozuma/journal/591374/

36. というわけで現場でやってる対策
l 診断中には、常に⼀一定間隔にて正引きを
⾏行行いIPが切切り替わらないか常に監視
l IPが切切り替わったタイミングで、診断を
中断
もっとスマートな⽅方法があれば
是⾮非教えてください！

37. まとめ
l ポイントを押さえて、適切切に脆弱性診断を
実施し、セキュリティ向上に役⽴立立てよう！
l もちろん診断やるだけじゃなくて
検出した脆弱性に対する対策も必要です。