Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

「これ危ない設定じゃないでしょうか」とヒアリングするための仕組み @AWS Summit Tokyo 2018

5,352 views

Published on

「これ危ない設定じゃないでしょうか」とヒアリングするための仕組み @AWS Summit Tokyo 2018

Published in: Engineering

「これ危ない設定じゃないでしょうか」とヒアリングするための仕組み @AWS Summit Tokyo 2018

  1. 1. 「これ危ない設定 じゃないでしょうか」 とヒアリングする ための仕組み 株式会社サイバーエージェント 柿島 大貴、東 和宏
  2. 2. 柿島 大貴 カキシマ ヒロタカ 2 インフラエンジニア 共著 HBase徹底入門(翔泳社) AbemaTV負荷対策プロマネ(2017) 好きなAWSサービス Amazon S3
  3. 3. 東 和宏 アズマ カズヒロ 3 インフラエンジニア 好きなAWSサービス プライベートクラウド立ち上げ AbemaTV コンテンツ基盤構築中 AWS CloudFormation
  4. 4. アジェンダ 4 ① ③ ④ ② 統制する仕組み 新しい取り組み 組織について 悩んでいること
  5. 5. 株式会社サイバーエージェント 5
  6. 6. 技術本部 メディア事業の横断組織でパブリッククラウドの管理をしています 技術本部 メディア事業 プライベート クラウド 提供 インフラ SRE パブリック クラウド サポート セキュリティ 分析 機械学習 開発環境 購買など 他にも多数 のサービス 6
  7. 7. AWSアカウント発行から解約までサポート 7 アカウント発行 運用中の問題 アカウント解約
  8. 8. 管理業務の例 8 請求や契約 with 経理/法務 依頼処理 トラブル対応 セキュリティ対応 with セキュリティチーム ① ② ③ ④
  9. 9. 9 AWS担当者とのやりとり Solutions Architect 成田様 Account Manager 辻本様 Technical Account Manager 新井様 ⑤ 管理業務の例 いつもありがとうございます!
  10. 10. 規模感 10
  11. 11. AWS利用の規模感 11 •AWSアカウント • プロジェクト、機能、環境(本番、開発)などで分離 • 累積 約 250 アカウント • 現在 約 160 アカウントがアクティブ
  12. 12. メディア管轄でAWSを利用するエンジニア 12 約400名弱 約20~30名数名 300名~ セキュリティエンジニア インフラエンジニア SRE/ネットワーク等 サーバサイドエンジニア等
  13. 13. クラウドの管理者 13 2名
  14. 14. アジェンダ 14 ① ③ ④ ② 統制する仕組み 新しい取り組み 組織について 悩んでいること
  15. 15. 管理業務の中でも特にセキュリティの話 15 請求や契約 with 経理/法務 依頼処理 トラブル対応 セキュリティ対応 with セキュリティチーム ① ② ③ ④
  16. 16. 会社横断のセキュリティチームと連携 16https://www.wantedly.com/projects/203471
  17. 17. ログイン関連 17
  18. 18. 18 サーバー AWSマネージメントコンソール
  19. 19. 権限の管理 19 •LDAPを利用 • 人事データベースと同期 • 権限管理用のポータルがある • AWSアカウントごとに権限が存在 • 役割ごとの権限も設定可能
  20. 20. サーバーへのログイン •LDAPを使った公開鍵認証、踏み台やVPNも提供 20 LDAP サーバー 各AWSアカウント 監査、共通基盤の AWSアカウント Elastic Load Balancing VPC peering EC2 EC2
  21. 21. 制限から複数のVPCを作成 21 LDAP サーバー 各AWSアカウント 監査、共通基盤の AWSアカウント Elastic Load Balancing VPC peering EC2 EC2 • VPC 当たりのアクティブな VPC ピアリング接続(最大125) • ルートテーブル当たりのルートの数(最大100) ×2 AWS PrivateLinkを検証中
  22. 22. マネージメントコンソールへのログイン •LDAPと連携した SAMLベースのフェデレーション •OpenAMからセキュリティチーム内製のものへ移行中 22 2FA
  23. 23. その他の取りくみ 23
  24. 24. すべてのアカウントで有効化 24 AWS CloudTrail Amazon GuardDuty
  25. 25. 監査用のアカウントにデータを集約 25 AWS CloudTrail Amazon S3 ログ 各AWSアカウント 共通の保管用 バケット Amazon GuardDuty メンバーアカウント Amazon GuardDuty マスターアカウント 各AWSアカウント
  26. 26. 面倒な設定は自動化 •GuardDutyの設定が特に大変 • アカウント、リージョンごとに招待、有効化、承認が必要 • その他の設定も含めてJenkins化 26
  27. 27. AWS Organizations •元々、一括請求機能を使用 •最近、すべての機能を有効化 • SCPも一部導入 • ブラックリスト方式 27
  28. 28. 管理用 AWSアカウントの構成 Organizationsのマスターアカウント • 請求 / Organizations /リザーブドインスタンスの管理 28 監査、共通基盤のアカウント • CloudTrailのログ集約、LDAPサーバーなど
  29. 29. ツリーの構成やポリシーは試行錯誤中 29 Organizationsの マスターアカウント 監査、共通基盤の アカウント 多くのプロジェクトの アカウント 一部のクリティカルな プロジェクトのOU Organization検証用の プロジェクトのOU Root
  30. 30. SCP(サービスコントロールポリシー) 嬉しいこと • DenyしたアクションはIAM, ルートアカウントともに対象 • iam:Create* , iam:Put*, iam:Attach*の権限があっても制限可 注意点 • Resourceは*で固定 • アクションのワイルドカード指定は後ろだけ • ボディの長さは5120 bytes(複数に分割して対応) 30
  31. 31. 他にも様々な取り組み • SAによるレビュー • 弊社のSREとAWS Well- Architected Frameworkを推進 • 日々の様々な相談 31 • ルートアカウントの管理 • MFAの管理 • 脆弱性診断の申請のサポート • エンタープライズサポート加入 • e-learning • 新卒研修 など AWSとの取り組み 基本的な取り組み
  32. 32. アジェンダ 32 ① ③ ④ ② 統制する仕組み 新しい取り組み 組織について 悩んでいること
  33. 33. 33 自由 責任 組織の文化
  34. 34. 組織の文化 サイバーエージェントは2006年から本格的にエンジニ ア組織を強化しました。その間、100はゆうに超える新 規サービスを立ち上げてきました。 その間「自由と自己責任」というものを掲げ、担当す るエンジニアがその時に最もベストな技術を選定し挑 戦をしてきました。(略) エンジニアに裁量を与える代わりに説明責任を求めま す。 34 https://www.wantedly.com/companies/abema/post_articles/33695
  35. 35. AWS製品の選択の裁量はプロジェクトにある 35
  36. 36. チャレンジの結果、事例になることも 36
  37. 37. カオスになりやすい環境 37 自由と自己責任の文化 エンジニアの数も多い 新卒も多い 新規事業も多い 異動もそれなりに
  38. 38. 責任共有モデルにより、AWSの顧客は クラウド”における”セキュリティの責任を負う 38 Infrastructure servicesの責任共有モデルの図
  39. 39. 守るところは守る 39 管理上守りたい部分 最小権限の原則 を促す フールプルーフを用意 AWS CloudTrail AWS Config Amazon GuardDuty IAM 厳格なポリシーに従う 必要のあるデータや プロジェクト 事故が起こりやすい部分 IAM IAMやOrganizationsで制限 (前半の説明部分など)
  40. 40. 制限と自由のバランスは難しい 40 自由すぎると問題が起こりやすい 制限をしすぎると開発スピード低下
  41. 41. どのアクションが危ないか…は難しい 41 危ないアクション安全なアクション 許可 禁止 セキュリティチームと議論して基本ポリシーは決定 例 s3:PutBucketPolicy 使い方次第
  42. 42. アジェンダ 42 ① ③ ④ ② 統制する仕組み 新しい取り組み 組織について 悩んでいること
  43. 43. 43 「これ危ない設定 じゃないでしょうか」 とヒアリングする ための仕組み
  44. 44. なぜヒアリングなのか 44 •プロジェクトに裁量を与える •問題がある場合には利用者に修正を依頼 •意図を確認しないと判断が難しいものが存在する
  45. 45. 仕組みは大きく2つ 45 スケジュールベースイベントベース
  46. 46. イベントベース 46
  47. 47. (再掲)監査用のアカウントにデータを集約 47 AWS CloudTrail Amazon S3 ログ 各AWSアカウント 共通の保管用 バケット Amazon GuardDuty メンバーアカウント Amazon GuardDuty マスターアカウント 各AWSアカウント
  48. 48. システム構成(イベントベース) 48 AWS CloudTrail Amazon S3 CloudTrailのログ メディア事業部 の各アカウント 共通の保管用 バケット イベントで SNS通知 Amazon SNS AWS Lambda Amazon SNS イベントの メッセージ ログ取得 イベントごとに メッセージ送信 (チェック項目ごと) AWS Lambda Amazon S3 ホワイトリストの取得 Amazon CloudWatch Events イベント Amazon GuardDuty メンバーアカウント Amazon GuardDuty マスターアカウント 通知 イベントデータの収集 判定と通知
  49. 49. 通知の例(S3 Bucket ACLの変更) 49
  50. 50. 通知の例(Security Groupの変更) 50
  51. 51. 通知の例(GuardDutyの検知) 51
  52. 52. スケジュールベース 52
  53. 53. 53 Amazon S3 チェック対象の アカウント AWS Lambda Amazon SNS 結果の保存 (JSON) (チェック項目ごと) Amazon CloudWatch Events AWS Lambda スケジュール 呼び出し アカウントIDを含んだ メッセージを送信 チェック対象の アカウントIDのリストを取得 Amazon S3 Amazon CloudWatch Events AWS Lambda スケジュール呼び出し レポートの生成 Assume Role リソースの情報取得 JSON HTML レポートの閲覧 AWS Organizations AWSアカウントと LDAPのマッピング情報 Amazon S3 ホワイトリストの取得 通知 LDAPサーバー ユーザー一覧の取得 Amazon SNS 通知タイミングごとの SNSメッセージ システム構成(スケジュールベース) スケジュール生成 アカウント一覧生成 チェックと通知とレポート生成
  54. 54. 通知の例(IAMユーザーの棚卸し) 54
  55. 55. 通知の例(SESのバウンス率、苦情率) 55
  56. 56. 通知の例(LDAPユーザーの定期棚卸し) 56
  57. 57. 通知の例(SSL/TLS証明書の期限) 57
  58. 58. 診断レポート 58 • Trusted Advisorの結果 • 独自チェックの結果 • CIS AWS Foundations Benchmark • ベンチマークに沿ったチェック結果 • コマンドベースでチェック方法記載 • 通知のしきい値の参考にもしている • セキュリティグループの一覧
  59. 59. なぜAWS Config Rulesではないの? 59 •アクティブなルール1つごとに2 USD/月 • リージョンごと、アカウントごとに費用増 •なるべく監査側のアカウントに設定を作りたい
  60. 60. 2016年にブログで公開、でも一度は失敗 •すべてのアラートを管理者だけで受け取った •プロジェクトとの連絡手段が確立できていなかった 60
  61. 61. 今回は、利用者と一緒に受け取る方式に 61 • AWSアカウント毎に通知先を用意 • LDAPの権限を元に招待 AWSアカウントごと のチャンネル 利用者&管理者 検知 システム アラート
  62. 62. 起こった変化 62 自主的に対応して くれる人が現れた アドバイスをくれる人 が現れた 実際に棚卸しが進んだ 早期検知が出来た
  63. 63. 利用者の声 63 検知が自動化されることはもち ろん、無駄な通知を減らしたい がために後回しになりがちな棚 卸しをするきっかけを生んでく れて助かっています! サービスリライアビリティグループ マネージャー / エンジニア 須藤 涼介
  64. 64. 今後について • 今回の方法がベストだとは思っていない • 情報収集と定期的な見直し • ポリシー • 検査項目 • 道具(コスト、便利さ、柔軟性) • 別レイヤーのチェック • 例: Amazon InspectorやVulsの利用普及 • 一部環境では導入済 64
  65. 65. まとめ •増え続けるAWSアカウントの”責任”をどう果たすか •制限と自由のバランスは常に悩んでいる •ぜひ情報交換をさせてください 65
  66. 66. 宣伝 •一緒に働いてくれる方を募集! • https://www.cyberagent.co.jp/careers/ •CyberAgent Developers Blog • https://developers.cyberagent.co.jp/blog/ • 各サービスのエンジニアやクリエイターの技術をお届けします 66
  67. 67. 素材利用、参考資料 •ヒューマンピクトグラム2.0 • http://pictogram2.com •Material icons • https://material.io/tools/icons/ • This slide includes the work that is distributed in the Apache License 2.0. •AWSでのセキュリティ運用 ~ IAM,VPCその他 • リクルートテクノロジーズ様 の資料 • https://www.slideshare.net/recruitcojp/20160517-security-jaws-miyazakisachie • 非常に参考にさせていただいています 67

×