クラウド環境でのセキュリティ監査自動化【DeNA TechCon 2020 ライブ配信】
•Télécharger en tant que PPTX, PDF•
3 j'aime•999 vues
このセッションでは、クラウド環境で多数のアカウントを利用した際に発生するセキュリティ的な問題と、それを解決するために作成した危険な設定を自動的にチェックするシステムを紹介します。 今回作成したシステムと既製品との違いや具体的なチェック内容、システムを作った後にどのようにして社内の運用に乗せていったのかも解説します。
Recommandé
Contenu connexe
Tendances
Tendances (20)
Similaire à クラウド環境でのセキュリティ監査自動化【DeNA TechCon 2020 ライブ配信】
Similaire à クラウド環境でのセキュリティ監査自動化【DeNA TechCon 2020 ライブ配信】 (20)
Plus de DeNA
Plus de DeNA (20)
Dernier
Dernier (10)
クラウド環境でのセキュリティ監査自動化【DeNA TechCon 2020 ライブ配信】
- 2. アジェンダ • 大規模なクラウド利用とセキュリティ • セキュリティ監査の理想の運用フローは？ • 自動化はどうやったらできるか、 どのくらいの実装量・期間が必要か？ • 実際に運用するとどうなるか？
- 4. DeNA Audit AWS Config ルールの追加 アカウントビュー 集約ビュー 理由付き NG通知抑制 GCP対応
- 5. 自己紹介 : 森 槙悟（MORI Shingo） 所属 • システム本部 セキュリティ部 セキュリティ技術グループ 経歴 • DeNA新卒 7年目、セキュリティエンジニア 7年目 • ICFPC 2019 世界8位（Rust） セキュリティ技術グループの業務内容 • 脆弱性診断 • セキュリティ相談対応 • NW診断 • ログ管理 • セキュリティツール作成、チート対策ライブラリ開発など
- 6. 自己紹介 : 森 槙悟（MORI Shingo） 所属 • システム本部 セキュリティ部 セキュリティ技術グループ 経歴 • DeNA新卒 7年目、セキュリティエンジニア 7年目 • ICFPC 2019 世界8位（Rust） セキュリティ技術グループの業務内容 • 脆弱性診断 • セキュリティ相談対応 • NW診断 • ログ管理 • セキュリティツール作成、チート対策ライブラリ開発など
- 7. 目次 背景・課題 • DeNAのクラウド利用状況の説明 • セキュリティ監査自動化が必要になった訳 要件 • 理想の運用フローと必要な機能 • どのような製品を使えば良いか？自作するか？ 実装 • クラウド周りの構成と具体的な監査の実装の説明 運用 • 全アカウントに対応してもらうにはどうすべき？ 今後の展望・まとめ
- 8. DeNAのクラウド利用状況 - 全体管理 主にAWS・GCPを利用 • AWSだけでも250アカウント以上、GCPは600プロジェクト以上 • 月に10個のペースで増加中 • 利用部門数は約60 アカウント作成・キッティングはインフラ部門担当 • アカウント名・利用部門・連絡先などを一元管理 • rootユーザの管理 • 管理用ロールの設定 • フェデレーションを利用したSSO設定の導入 • 監査ログの設定の導入 • コストアラートの導入
- 9. DeNAのクラウド利用状況 - アカウント内 アカウント内は開発者が管理者権限を持つ • 用途がバラバラなのでインフラで全部対応するのが難しい • 素早く柔軟な設定を行うのに必要 • 規模が大きいものはインフラ管理の場合も 利用者によってセキュリティレベルに差異が出る • 専門のエンジニアが居ない部署もある • 相談・調査を個別にするのは工数やスピードに問題あり
- 10. DeNAのクラウド利用状況 - アカウント内 アカウント内は開発者が管理者権限を持つ • 用途がバラバラなのでインフラで全部対応するのが難しい • 素早く柔軟な設定を行うのに必要 • 規模が大きいものはインフラ管理の場合も 利用者によってセキュリティレベルに差異が出る • 専門のエンジニアが居ない部署もある • 相談・調査を個別にするのは工数やスピードに問題あり セキュリティガイドを作成 • ガイド通りにやれば社内ポリシーに準拠できる • スピードを保ったまま必要なセキュリティ設定を確認可能
- 12. DeNAのクラウド利用状況 - アカウント内 全部読んで理解するのがまだ難しい • 全121項目… • EC2・S3などサービスを分けても20項目ほどある • 設定ミスでガイド通りにならない セキュリティ監査も工数がかかる • セキュリティガイドとの突き合わせに時間がかかる
- 13. DeNAのクラウド利用状況 - アカウント内 全部読んで理解するのがまだ難しい • 全121項目… • EC2・S3などサービスを分けても20項目ほどある • 設定ミスでガイド通りにならない セキュリティ監査も工数がかかる • セキュリティガイドとの突き合わせに時間がかかる 工数削減のために自動的にチェックするべき • APIから取得できる情報が対象
- 14. 具体的にチェックしたい項目例 • ルートユーザの二要素認証が有効か？ • ルートユーザのアクセスキーが無効化されているか？ • システム用ユーザに利用してない権限が付いてないか？ • システム用ユーザにリソース制限がかかっているか？ • IAMユーザの管理方法は社内規定にしたがっているか？ • IAMユーザに二要素認証・IP制限があるか？ • 利用してないアクセスキーが残ってないか？ • サービスアカウントキーはローテーションされているか？ • 内部用バケットが公開されてないか？ • オブジェクト単位でアクセス権をつけない設定が有効か？ • 公開バケット（S3・GCS）のアクセスログが有効か？ • バケットのデフォルト暗号化が有効か？ • 読み込み・書き込み専用のユーザに過剰な権限が付与されてないか？ • ライフサイクルの設定が短すぎないか？ • ネットワーク設定で不要なポートを開けてないか？ • 本番環境のSSH接続元が踏み台サーバに限定されているか？ • GKEが限定公開クラスタになっているか？ • ELBのアクセスログが有効か？ • ELBの暗号強度は十分か？ • ……
- 15. 目次 背景・課題 • DeNAのクラウド利用状況の説明 • セキュリティ監査自動化が必要になった訳 要件 • 理想の運用フローと必要な機能 • どのような製品を使えば良いか？自作するか？ 実装 • クラウド周りの構成と具体的な監査の実装の説明 運用 • 全アカウントに対応してもらうにはどうすべき？ 今後の展望・まとめ
- 20. 重要な要件 一次対応者はアカウントの管理者 • セキュリティ部にはそもそも修正する権限が無い • アカウントが数百あるのでセキュリティ部では見切れない 理由・期限を書いてNGを抑制したい • 人力で判断が必要な監査項目がある • 本番環境をすぐに直すのは大抵難しい • セキュリティ監査の際に聞かなくても理由を確認できる 対応状況を監査担当者も確認できる • UIの権限管理が必要 ランニングコストは抑える
- 21. 製品選定 AWS Config アカウント別のビュー・集約ビューの両方がある 理由を書いてNGを抑制するのが難しい やや高い（年額500万円*〜） 3rd partyの製品 集約ビューしか無い（一次対応がセキュリティ部） 高い（年額2000万円〜） DeNA Audit（自作） 作れば全部できる、特にNGの抑制機能 安い（年額10万） WebUIの作成・機能追加の工数がかかる * 2018/11に100アカウント1リージョン40ルールで試算した料金 2019/8に料金体系が改定され安くなっています（DeNAの環境では1/5未満）
- 22. 製品選定 AWS Config アカウント別のビュー・集約ビューの両方がある 理由を書いてNGを抑制するのが難しい やや高い（年額500万円*〜） 3rd partyの製品 集約ビューしか無い（一次対応がセキュリティ部） 高い（年額2000万円〜） DeNA Audit（自作） 作れば全部できる、特にNGの抑制機能 安い（年額10万） WebUIの作成・機能追加の工数がかかる * 2018/11に100アカウント1リージョン40ルールで試算した料金 2019/8に料金体系が改定され安くなっています（DeNAの環境では1/5未満）
- 23. 製品選定 AWS Config アカウント別のビュー・集約ビューの両方がある 理由を書いてNGを抑制するのが難しい やや高い（年額500万円*〜） 3rd partyの製品 集約ビューしか無い（一次対応がセキュリティ部） 高い（年額2000万円〜） DeNA Audit（自作） 作れば全部できる、特にNGの抑制機能 安い（年額10万） WebUIの作成・機能追加の工数がかかる * 2018/11に100アカウント1リージョン40ルールで試算した料金 2019/8に料金体系が改定され安くなっています（DeNAの環境では1/5未満）
- 24. デモ S3の公開されているバケットに対する監査のデモ • 1つのバケットはWebUIからAWSの設定を修正 • もう1つのバケットは公開用なのでNGを抑制 https://youtu.be/67PDgJKDUCE * デモ用に一部の文字を大きくするなどの変更を行なっています
- 25. 目次 背景・課題 • DeNAのクラウド利用状況の説明 • セキュリティ監査自動化が必要になった訳 要件 • 理想の運用フローと必要な機能 • どのような製品を使えば良いか？自作するか？ 実装 • クラウド周りの構成と具体的な監査の実装の説明 運用 • 全アカウントに対応してもらうにはどうすべき？ 今後の展望・まとめ
- 26. *正式名称は以下の通りです EC2 : Amazon EC2 ALB : Application Load Balancer S3 : Amazon Simple Storage Service CloudWatch : Amazon CloudWatch SES : Amazon Simple Email Service
- 27. クラウドの構成 - 権限 AWS • 監査対象アカウントに監査用ロールを作成 • SecurityAudit のポリシーで必要な権限が大体つく • 監査元のEC2からクロスアカウントでAssumeRoleする GCP • 監査元プロジェクトにサービスアカウントを作成 • 監査対象プロジェクト（または組織レベル） でそのサービスア カウントに役割をつける • Security Reviewer の役割で必要な権限が大体つく • 必要なら各プロジェクトでAPIを有効化する
- 28. 監査ルール実装 - 例1 AWS IAM ルール • 使われてないアクセスキーは無効化・削除する事 コマンド 判定 • StatusがActiveかつ、LastUsedDateが一定期間より前だとNG • 一度も利用してないとLastUsedDateがnullになるので CreateDateも見る必要がある aws iam list-users aws iam list-access-keys --user-name ${ユーザ名} aws iam get-access-key-last-used --access-key-id ${キーID}
- 29. 監査ルール実装 - 例2 AWS ALB ルール • ALBのアクセスログを有効化する事（CLBは別実装） • 設定ミス防止のためファイルが実在するかも確認する コマンド 判定 • アクセスログが有効で直近のログが存在すればOK aws elbv2 describe-load-balancers aws elbv2 describe-load-balancer-attributes --load-balancer-arn ${arn} aws s3api list-objects-v2 --bucket ${バケット名} --max-items 1 --prefix ${prefix}AWSLogs/${account_id}/elasticloadbalancing/ ${region}/${year}/${month}/${date}/
- 30. 監査ルール実装 - 例3 GCP GCS ルール • 公開用のバケット以外はallUsers・allAuthenticatedUsersに権 限を付与しない事 コマンド 判定 • IAM・ACLにallUsers・allAuthenticatedUsersがあるとNG • そもそも公開用のバケットは理由を書いてNGを抑制する gsutil ls gsutil iam get gs://${バケット名}/ gsutil acl get gs://${バケット名}/ gsutil defacl get gs://${バケット名}/
- 31. 監査ルール実装 - 注意点の例 アカウント内で完結しない場合 • ログ出力先が別アカウントなど • 先に全アカウントのリソース情報を取得し表を作る 複雑なルールは実装が大変 • ファイアウォールやAWSのポリシーなどは頑張る • 多分しない設定はログだけ出して後で実装 本番データで遅い・エラーになる • アカウント数が多いので高速化・並列化が必要 • GCPはリソースが無い場合、REST APIが404やnilを返す • 新機能の利用などで既存のAPIがエラーになる事も稀にある
- 32. AWS自動監査実装のタイムライン 実装量 • 監査ルール(ruby)：5,300行 • 単体テスト：5,300行 • WebUI(rails)：1,700行 監査ルール実装 - タイムライン・実装量 18/12 19/01 19/03 19/04 19/05 19/06 要件確認 監査ルール約40項目の実装 WebUI作成・環境整備 試験運用・FAQ整備 本番運用
- 33. 目次 背景・課題 • DeNAのクラウド利用状況の説明 • セキュリティ監査自動化が必要になった訳 要件 • 理想の運用フローと必要な機能 • どのような製品を使えば良いか？自作するか？ 実装 • クラウド周りの構成と具体的な監査の実装の説明 運用 • 全アカウントに対応してもらうにはどうすべき？ 今後の展望・まとめ
- 34. 運用 - AWS自動監査 開始 AWS側は全社導入した！ • マニュアル・FAQも準備した！ • 全社に連絡した！
- 35. 運用 - AWS自動監査 開始 AWS側は全社導入した！ • マニュアル・FAQも準備した！ • 全社に連絡した！ あんまり対応してくれない… • 対応してくれている人もいるが全体から見ると足りない • 運用歴が長いと1アカウントで数百個NGが出る… • 一度綺麗にすれば楽だがそこまでが大変
- 36. 運用 - 結局セキュリティ部が見る 危険度が高い項目を集計 • バケットがパブリックになっている • DBのポートがインターネットに公開されている • ルートユーザのアクセスキーが有効 • …… NGを目視確認 • 合計で400件程度 • 明らかに問題ないものは除外していく • システムの権限で設定を見れるので早い • 数時間で見終わるのでやる
- 37. 運用 - 残りの対応 トップダウンで対応依頼 • 実際に危ないのが見つかっているのでスムーズ • 3ヶ月に一回、各マネージャー陣に対応状況を共有 • 8割のアカウントが対応済みに 残りのアカウント管理者にpush • 数が減ったので人力で一人ずつ連絡 • 現在進行中
- 38. 運用 - セキュリティ監査 ヒアリング項目数が大幅減 • AWS：62%自動化（51/82項目） • GCP：25%自動化（20/79項目） 情報の正確性・速度が上がった • アカウント管理者にヒアリングするよりも正確 • 年次のセキュリティ監査を待たずに危険な箇所を把握できる セキュリティ監査担当者も大喜び
- 39. 目次 背景・課題 • DeNAのクラウド利用状況の説明 • セキュリティ監査自動化が必要になった訳 要件 • 理想の運用フローと必要な機能 • どのような製品を使えば良いか？自作するか？ 実装 • クラウド周りの構成と具体的な監査の実装の説明 運用 • 全アカウントに対応してもらうにはどうすべき？ 今後の展望・まとめ
- 40. 今後 - 残課題 全AWSアカウントの対応完了 GCPの自動監査の運用開始 • ルールは実装済み（約20項目） • 一部プロジェクトで先行導入中 • こちらも全プロジェクト対応済みにする クラウドセキュリティに関する啓蒙活動 • E-learningなど 別レイヤでのセキュリティの強化 • 今回対象外としたレイヤの監査の自動化 • クラウド環境に対するSOC • 不正アクセス検知、脅威検出など
- 41. 今後 - 新機能への追従も必要 新機能のチェック • 公式の発表・ブログ・リリースノート・週刊AWSなどを定期的 に確認する • 発表会の内容をチェックする • AWS re:Invent, Google Cloud Nextなど セキュリティガイド・自動監査の更新 • 公式ドキュメントの確認・動作検証を行ない追加が必要か検討 • 必要ならセキュリティガイドの更新と監査を実装 • 全社に連絡して順次対応してもらう
- 42. まとめ クラウド環境のセキュリティに課題 • 利用者によってレベルがバラバラ • 数が多すぎて設定確認・セキュリティ監査に時間がかかる 要件に合うシステムを自作 • 日毎に監査、NGの項目はアカウント管理者に通知 • 理由・期限を書いてNGを抑制可能、棚卸しにも利用可能 • 実装は頑張る、工数が足りない時は重要なルールのみに絞る 全て対応してもらうのは大変 • 危険度が高いものは待たずに直接確認するべき • トップダウンで対応を依頼して、最後は個別に連絡 • 対応してもらってセキュリティ監査の工数を大幅に削減