Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
DMMにおける300アカウント67チームのAWSセキュリティを「開発者」に監視してもらうまでの道のり
Search
Wataru Nishiyama
November 04, 2021
1
1.1k
DMMにおける300アカウント67チームのAWSセキュリティを「開発者」に監視してもらうまでの道のり
Wataru Nishiyama
November 04, 2021
Tweet
Share
More Decks by Wataru Nishiyama
See All by Wataru Nishiyama
AWSセキュリティガードレールにより開発者がセキュリティ監視するようになったDMM_課題と今後.pptx.pdf
runble1
0
120
DMMでAWSセキュリティガードレールを作ったので、開発者がAWSセキュリティをチェックする文化を広げていきたい
runble1
7
7.8k
GCP無料枠を使ってデータ分析基盤を作ってみた
runble1
1
1.1k
英語できないエンジニア Google I/O にいく
runble1
0
350
Featured
See All Featured
Why You Should Never Use an ORM
jnunemaker
PRO
54
9.1k
Large-scale JavaScript Application Architecture
addyosmani
510
110k
GitHub's CSS Performance
jonrohan
1030
460k
10 Git Anti Patterns You Should be Aware of
lemiorhan
PRO
656
59k
[Rails World 2023 - Day 1 Closing Keynote] - The Magic of Rails
eileencodes
33
1.9k
Performance Is Good for Brains [We Love Speed 2024]
tammyeverts
6
520
Documentation Writing (for coders)
carmenintech
66
4.5k
JavaScript: Past, Present, and Future - NDC Porto 2020
reverentgeek
47
5.1k
ReactJS: Keep Simple. Everything can be a component!
pedronauck
665
120k
Exploring the Power of Turbo Streams & Action Cable | RailsConf2023
kevinliebholz
28
4.4k
Distributed Sagas: A Protocol for Coordinating Microservices
caitiem20
330
21k
CoffeeScript is Beautiful & I Never Want to Write Plain JavaScript Again
sstephenson
159
15k
Transcript
© DMM.com CONFIDENTIAL DMMにおける300アカウント 67チームのAWSセキュリティを 「開発者」に監視してもらうまでの 道のり 合同会社DMM.com セキュリティ部 CloudSecチーム
西山渉
© DMM.com 自己紹介 - 合同会社DMM.com - セキュリティ部 CloudSec チーム -
クラウドセキュリティの推進 - WAF 導入支援 - PCIDSS セキュリティ監視 2
© DMM.com 自己紹介 3 - 合同会社DMM.com - セキュリティ部 CloudSec チーム
- クラウドセキュリティの推進 - WAF 導入支援 - PCIDSS セキュリティ監視 - 元プラットフォーム開発部バックエンドエンジニア →伏線
© DMM.com AWS セキュリティとは 4
© DMM.com AWS セキュリティとは 5 アプリケーション AWS サービス 脆弱性診断、WAF AWS
セキュリティ
© DMM.com AWS セキュリティとは 6 アプリケーション AWS サービス 脆弱性診断、WAF AWS
セキュリティ AWS セキュリティの範囲 - 「AWS 上のサービスへの攻撃」に対するセキュリティ - 「AWS アカウントへの攻撃」に対するセキュリティ
© DMM.com DMMでも実際に事件発生 7 - S3 バケットが Write 権限でパブリック公開となっていた →悪意ある
JS が置かれ、フィッシングサイトへ誘導
© DMM.com ということでDMMも AWSセキュリティ やろうとしました 8
© DMM.com 目的 9 - ヤバイ設定を素早く見つける
© DMM.com 目的・実現方法 10 - ヤバイ設定を素早く見つける →セキュリティガードレールを敷く
© DMM.com セキュリティガードレール? 11 - セキュリティ品質の担保のため、クラウド領域を制限 または、検知できるようにすること
© DMM.com セキュリティガードレール? 12 今回は検知 - セキュリティ品質の担保のため、クラウド領域を制限 または、検知できるようにすること
© DMM.com セキュリティガードレール 実装の前に DMM の状況 13
© DMM.com 対象 ( 見込み ) 14 - チーム数 :
50 以上 - AWS アカウント : 300 以上 - リージョン : 16 ( 2020年当時 )
© DMM.com 当時の DMM の状況 15 - AWS アカウントの払い出しは別部門 -
CloudTrail は Organizations にて集中管理済み →ログ集約基盤が存在し、ログ保管済み
© DMM.com 技術選定1 16
© DMM.com 当初の方針 17 - 50 以上あるチームへの説明は時間がかかるため、 管理者だけでセキュリティ監視しよう - セキュリティ設定も開発者へ負担をかけずに
管理者だけで完結しよう
© DMM.com 監視モデル 18 管理者 開発者 AWS
© DMM.com 監視モデル 19 管理者 開発者 AWS
© DMM.com 監視モデル 20 管理者 開発者 AWS
© DMM.com AWS Config 21 - AWS リソースの設定変更履歴を保存する
© DMM.com AWS Security Hub 22 - 設定不備を検出する etc...
© DMM.com Amazon GuardDuty 23 - セキュリティ侵害を検知する
© DMM.com AWS Organizations 24 - メンバーアカウントをグルーピングする etc...
© DMM.com サービスマネージド型 CloudFormation StackSets 25 - メンバーアカウントへセキュリティ設定を適用する
© DMM.com 案1 : 監視体制 26
© DMM.com 案1 : 監視体制 27 Landing Zone
© DMM.com 承認貰いに行きました 28
© DMM.com 部長に承認もらう 29 ぼく「AWSセキュリティ設定すぐできそうです。お金とチェックは セキュリティ部で、パッとやっていいですか」
© DMM.com 部長に承認もらえない 30 ぼく「AWSセキュリティ設定すぐできそうです。お金とチェックは セキュリティ部で、パッとやっていいですか」 部長「ダメ。各チームのお金とリソースでチェックしてもらうよう、 各チームに承認をもらってください」
© DMM.com 部長に承認もらえない 31 ぼく「AWSセキュリティ設定すぐできそうです。お金とチェックは セキュリティ部で、パッとやっていいですか」 部長「ダメ。各チームのお金とリソースでチェックしてもらうよう、 各チームに承認をもらってください」 ぼく「なるほどですね〜 (
ひええええええええ ) 」
© DMM.com DMM Tech Vision 32
© DMM.com DMM が目指す開発像 33
© DMM.com セキュリティも開発者が面倒をみる 34
© DMM.com 技術選定2 35
© DMM.com 監視モデル 36 AWS 開発者 管理者
© DMM.com 監視モデル改 37 管理者 開発者 AWS 主役
© DMM.com 監視モデル改 38 管理者 開発者 AWS Push型
© DMM.com AWS Config Rules 39 - 設定不備を検知する → Security
Hub の代わり
© DMM.com AWS Config Rules を使った理由 40 - CloudFormation でルールの指定ができる
→開発者にチェックしてもらうため、過検知は少なく
© DMM.com AWS Config Rules の選定 41
© DMM.com Slack 42 - DMM のチャットコミュニケーションツール →チームごとにアラート通知用のチャンネル作成
© DMM.com Slack へ飛ばすために 43 - Amazon EventBridge - Amazon
SNS - AWS Chatbot
© DMM.com OU 構築 44 - チームごとに OU を作成
© DMM.com セキュリティ設定方法 45
© DMM.com 案2 : 監視体制 46
© DMM.com これでいけるか・・・? 47
© DMM.com 知り合いのチームに テストさせてもらう 48
© DMM.com 伏線回収 49
© DMM.com 最初の営業 50
© DMM.com いざ実践 51
© DMM.com おかげさまで、問題点を把握 52 - チェック終わったアラートがわからない ( 開発者・管理者とも に )
- 埋もれて忘れてしまう → Slack だけでアラート管理は難しい
© DMM.com アラート管理のための 技術選定 ( AWS外 ) 53
© DMM.com 方針思い出し 54 - 開発者にセキュリティ運用をやってもらう →開発者がスムーズに運用できるようなツールを利用
© DMM.com JIRA 55 - DMM で採用されているチケット管理システム
© DMM.com JIRA -選定理由- 56 - DMM で採用されているチケット管理システム - 入社時にアカウント発行
- 他部署へのタスクの依頼に利用 → DMM の人は全員使える。。。はず
© DMM.com JIRA -全てのリージョンのアラートを管理- 57
© DMM.com JIRA -アラートをカンバン方式で管理- 58
© DMM.com JIRA -チケット内には優先度や期限を記載- 59
© DMM.com Slackbot 60 - JIRA チケットの起票 - Slack のスレッドへ
JIRA チケット URL を通知 - アラートの重要度に応じたメンション発行 etc...
© DMM.com Slackbot 61 DMM のインフラ部門がシステムアラートの管理を JIRA で やっているのにインスパイア!! -
JIRA チケットの起票 - Slack のスレッドへ JIRA チケット URL を通知 - アラートの重要度に応じたメンション発行 etc...
© DMM.com slackbot ( 作った ) 62
© DMM.com 実際の例 63
© DMM.com 完成 楽しい技術検証はここまで 64
© DMM.com ここからは DMM のチームを 巡り、承認をもらう 65
© DMM.com 長い旅が始まりました DMM ジャーニー 66
© DMM.com 承認をもらう旅 67 - AWS セキュリティチェックを開発者にやってもらうため「お金」 と「運用リソース」を出してもらうよう、 承認いただく
© DMM.com 営業資料 68
© DMM.com 営業順番 69 - 重要な情報を扱っているチームから
© DMM.com 営業 70
© DMM.com コロナ禍における 他部署への協力取り付け 71
© DMM.com リモートで営業 72 - Slack で DM を送る -
「初めましてこんにちは!」 - 「AWS セキュリティについて相談したいです!」 - 「ちょっとお時間よろしいでしょうか?」
© DMM.com 営業の振り返り 73 - チームでやっていたから完走できた - 逆にコロナという環境だからこそ、営業は捗った - あらゆるツテとコネを活用した
© DMM.com 結果 74
© DMM.com 完了宣言 承認もらえたチーム : 80 → Slack チャンネルの通知先が 67
75
© DMM.com 完了宣言 76 セキュリティ設定完了したアカウント : 約300 承認もらえたチーム : 80
→ Slack チャンネルの通知先が 67
© DMM.com 完了宣言 77 棚卸しにより削除されたアカウント : 約50 セキュリティ設定完了したアカウント : 約300
承認もらえたチーム : 80 → Slack チャンネルの通知先が 67
© DMM.com 監視体制 78
© DMM.com 監視体制 79 Slack セクション機能で グルーピング
© DMM.com アラート数の推移(2021/9末時点) 80
© DMM.com アラート状況(2021/9末時点) 81 チェックした箇所 : 約4500 チェックが完了した箇所 : 約3200
© DMM.com チケット状況 82
© DMM.com 特にヤバイやつ 83 DB パブリック公開:20 S3 書き込み権限でパブリック公開:6
© DMM.com 実際に起きてた事件 84
© DMM.com 実際に起きてた事件 85 3件
© DMM.com DMM CSIRT と協力して対処 ( 画像は別件 ) 86
© DMM.com 議論が発生している 箇所 87
© DMM.com 80, 443 port パブリック公開の検知 88 Q. Web 会社なんだから
80, 443 port 公開するの当たり前 じゃん!想定内ですよ! A. お手数おかけしてます。DEV/STG 環境や Jenkins など のパブリック公開検知のため、80, 443 port の パブリック検知を実施しています。
© DMM.com セキュリティ設定するタイミング 89 Q. サービスリリースしてからでいいんじゃないの? A. クラウドセキュリティの場合、クラウドを利用し始めた タイミングからリスクが発生します。そのため、AWS アカウントが払い出されたタイミングでセキュリティ
設定を有効化します。
© DMM.com 一年運用 ( 管理者 ) 90
© DMM.com DMM の AWS セキュリティ標準策定 91
© DMM.com セキュリティプランを用意 92
© DMM.com CloudFormation StackSets 93 Organizations の OU 設計
© DMM.com 構築 94 - AWS CLI で実行
© DMM.com 構築 95 - 1 チームで 6 個の StackSet
を作成
© DMM.com 構築 96 - 1 チームで 6 個の StackSet
を作成 →80 OU あるためデプロイ先が 480
© DMM.com 構築 97 - Administrator アカウントに作成できる StackSet 数の 上限緩和申請
( 100 → 700 )
© DMM.com 構築 98 - アカウント数 × 17 リージョン分の Stack
Instance
© DMM.com 運用 99 - 難しい
© DMM.com 運用 100 - 難しい - 自動デプロイ
© DMM.com 運用 101 - 自動デプロイを有効化すると OU に AWS アカウントを
所属させたタイミングで CloudFormation が実行される
© DMM.com 運用 102 - 自動デプロイはリージョンの実行順を制御できない →自動デプロイを考慮した CloudFormation テンプレートを作 成すべきだった
© DMM.com ユースケース 103 - AWS アカウントを Root へ移動 (
アカウント停止前 ) - AWS アカウントを Root へ移動 ( アカウント停止後 ) - AWS アカウントを別の既存 OU へ移動 - AWS アカウントを別の新規 OU へ移動 - AWS アカウントを別の新規 OU へ移動 ( 現在の OU 配下 ) - etc...
© DMM.com 一年運用して ( 開発者 ) 104
© DMM.com チケット ( アラート ) 状況 105 ToDo ↓
レビュー中 ↓ 完了 のフローです
© DMM.com 開発者・管理者が一緒にがんばってる 106 - 開発者・管理者が一緒に AWS セキュリティ運用 がんばってます!
© DMM.com 開発者がセキュリティアラートをチェック! 107
© DMM.com まとめ 108
© DMM.com まとめ 109 - DMM の AWS アカウントにガードレールを敷けた →設定不備・セキュリティ侵害を発見できた
© DMM.com まとめ 110 - DMM の AWS アカウントにガードレールを敷けた →設定不備・セキュリティ侵害を発見できた
- 開発者がセキュリティアラートを自発的にチェック → AWS レイヤーのセキュリティ自給率が高まった
© DMM.com 今後の DMM 111 DMM のセキュリティ部は開発者と共に セキュリティを推進していきます!
© DMM.com おしまい 112