とある診断員とAWS

とある診断員とAWS

1. 1. 2016/05/17 @tigerszk Amazon  Web  Services
2. 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. 3. 脆弱性診断とは ＦＷ サーバ機器 診断環境 診断対象環境 Ｗｅｂアプリ NW機器 l  システムやアプリケーションの脆弱性を 洗い出し、安全性について調査するサービス scanning! × 脆弱性診断⼠士 × Internet ※図は疑似攻撃試⾏行行するブラックボックステストを⽰示しています 他にも設計書、仕様書、コンフィグファイル、ソースコードなどを分析して、 脆弱性を洗い出すホワイトボックステストなどがあります
4. 4. 診断の種類 OS ミドルウェア Webコンテンツ Webアプリケーション診断 ネットワーク診断 （プラットフォーム診断） Webシステム l  対象とする領領域によって実施する 診断の種類が異異なる
5. 5. 診断するシステムは？ l 様々なシステムが診断対象となる l 近年年ではクラウド環境の診断対象が増加   当然AWSも診断対象として登場
6. 6. たまにある質問 Q.AWSを診断する意味あるの？ A.もちろんあります!
7. 7. AWSは責任共有モデル 「責任共有モデル  –  アマゾン  ウェブ  サービス  (AWS)」より引⽤用  https:// aws.amazon.com/jp/compliance/shared-‐‑‒responsibility-‐‑‒model/
8. 8. EC２などは、OSやアプリケーション のセキュリティを担保する責任は ユーザー側にあります
9. 9. AWSを利利⽤用していても •  ACLの設定が適切切ではない •  ミドルウェアの設定に不不備がある •  パッチマネジメントできていない •  Webアプリケーションの作りこみが⽢甘い 脆弱性が存在
10. 10. 「AWS  セキュリティのベストプラクティス」 にも  テストについて書いてある 「AWS  セキュリティのベストプラクティス」より引⽤用 http://media.amazonwebservices.com/jp/wp/AWS_̲Security_̲Best_̲Practices.pdf
11. 11. AWSでも脆弱性検査で 安全性をチェックをしよう！
12. 12. 脆弱性診断するなら l セキュリティベンダに依頼する l コストや時間がかけられないなら⾃自分で チェックするのもOK！ ※以下ご参考に 「フリーでやろうぜ！セキュリティチェック！」  http:// www.slideshare.net/zaki4649/free-‐‑‒securitycheck
13. 13. よし！ じゃあ早速診断するか！
14. 14. ちょっと待て
15. 15. 実はAWSでの脆弱性診断では、 いくつか抑えておくべきポイントがある
16. 16. １．診断前に許可申請が必要 「侵入テスト -­‐  AWS  クラウドセキュリティ 」より引用   h'ps://aws.amazon.com/jp/security/penetra;on-­‐tes;ng/
17. 17. ちなみにAWSだけではない 基本的にホスティング環境、クラウドサービスを 利利⽤用している場合には、診断事前にあらかじめ 事業者側に診断実施の許可を得ることが必要 事業者側のポリシーによっては診断⾃自体不不可な 場合もある
18. 18. ２．全部診断できるわけじゃない •  EC2とRDSのインスタンスのみ診断可能 •  以下のインスタンスタイプは診断不不可 RDS:スモールRDSインスタンス、マイクロRDSインスタンス EC2:m1.small、t1.micro EC2 RDS
19. 19. 「侵入テスト -­‐  AWS  クラウドセキュリティ 」より引用   h'ps://aws.amazon.com/jp/security/penetra;on-­‐tes;ng/
20. 20. 許可申請は専⽤用のフォームから AWS  脆弱性/侵⼊入テストリクエストフォーム https://portal.aws.amazon.com/gp/aws/html-‐‑‒forms-‐‑‒controller /contactus/AWSSecurityPenTestRequest
21. 21. Contact  Information フォーム項⽬目 記載する内容 Your  Name:* 担当者の⽒氏名 Company  Name* 会社名 Email  Address AWSアカウントのメールアドレス Additional  Email   Address CCに追加するメールアドレス Third  Party  Contact   Information 診断を第三者の会社に委託する場合に記⼊入する 第三者の連絡先 ※は必須⼊入⼒力力項⽬目
22. 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. 23. その他 •  以下に同意が必要（規約とかポリシー） –  Terms  and  Conditions –  AWSʼ’s  Policy  Regarding  the  Use  of  Security   Assessment  Tools  and  Services •  他注意点 –  フォームリスクエストにはroot認証が必要 –  指定できる診断期間は3ヵ⽉月以内 –  2  営業⽇日以内に、申請受理理が届く –  ⼿手続き完了了には数⽇日かかる可能性がある –  侵⼊入テスト申請の終了了時間は、延⻑⾧長を考えて余裕を もっておいた⽅方がいいでしょう
24. 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. 25. みんなが幸せになるために ルールをちゃんと守ってね！
26. 26. でも実際に現場でよくある話 l 申請フォーム？なにそれ？おいしいの？ l 明⽇日から診断だけど許可申請するの忘れちゃった！ てへぺろ(・ω<) l 地雷雷（S3とか診断できないものが）がしれっと 診断対象リストに混⼊入 l CloudFront経由で診断4649ね！ ・・・etc
27. 27. 円滑滑に進めるための対策 l ⼤大切切なことを事前に丁寧に説明 l AWSの構成などを事前にヒアリング l 申請許可のメールをエビデンスとして、 必ず確認してから診断を実施
28. 28. ちょっとした⼩小ネタ
29. 29. AWSを診断する時の 厄介な相⼿手それは…
30. 30. Elastic  Load  Balancing  
31. 31. ELBとは   l ロードバランサーのクラウドサービス l トラフィックを複数のインスタンスに分 散するヘルスチェック機能を持っている l ELB⾃自体がトラフィックに応じてスケール l 暗号化・復復号（SSL）機能を利利⽤用できる
32. 32. l グローバルIPがコロコロ変化する l 固定IPを設定することはできない l いつIPが変更更されるかわからない この仕様が問題
33. 33. この仕様、実は診断⼠士にはツラい… l そもそもNW診断とかはIPベースで診断を 実施するのが⼀一般的 l ドメイン指定での診断も可能だが、検査 ツールはポートスキャン都度度などに毎回 正引きなどはしない
34. 34. ていうかヤバい… l もし診断の最中にIPが切切り替わって、 診断パケットが別の環境に⾶飛んでいく 可能性が  ((((；ﾟДﾟ))))ｶﾞｸｶﾞｸﾌﾞﾙﾌﾞﾙ l もしかして関係ない⼈人宛に診断(＝攻撃)しちゃう んじゃない？それはマジでヤバい！！ ※勉強会の質疑の時に、中の⽅方より、「ELBで引い たIPは、仕様として最低60分は他のIPに紐紐付け られることがない」というお話を伺いました！ すぐに別の環境にパケットが流流れることはない ようです。ちょっと安⼼心しました。
35. 35. 参考サイト l ozumaの⽇日記  ：AWSのELB(Elastic  Load   Balancing)は、セキュリティ的に問題ないのか   http://srad.jp/~∼ozuma/journal/591374/
36. 36. というわけで現場でやってる対策 l 診断中には、常に⼀一定間隔にて正引きを ⾏行行いIPが切切り替わらないか常に監視 l IPが切切り替わったタイミングで、診断を 中断     もっとスマートな⽅方法があれば 是⾮非教えてください！
37. 37. まとめ l ポイントを押さえて、適切切に脆弱性診断を 実施し、セキュリティ向上に役⽴立立てよう！ l もちろん診断やるだけじゃなくて 検出した脆弱性に対する対策も必要です。