クラウド環境でのセキュリティ監査自動化【DeNA TechCon 2020 ライブ配信】

DeNA

More Related Content

1.クラウド環境でのセキュリティ監査自動化森 槙悟
2.アジェンダ• 大規模なクラウド利用とセキュリティ• セキュリティ監査の理想の運用フローは？• 自動化はどうやったらできるか、どのくらいの実装量・期間が必要か？• 実際に運用するとどうなるか？
3.AWSの監査といえばAWS Configでは？
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 EC2ALB : Application Load BalancerS3 : Amazon Simple Storage ServiceCloudWatch : Amazon CloudWatchSES : 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-usersaws iam list-access-keys --user-name ${ユーザ名}aws iam get-access-key-last-used --access-key-id ${キーID}
29.監査ルール実装 - 例2 AWS ALBルール• ALBのアクセスログを有効化する事（CLBは別実装）• 設定ミス防止のためファイルが実在するかも確認するコマンド判定• アクセスログが有効で直近のログが存在すればOKaws elbv2 describe-load-balancersaws 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 lsgsutil 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を抑制可能、棚卸しにも利用可能• 実装は頑張る、工数が足りない時は重要なルールのみに絞る全て対応してもらうのは大変• 危険度が高いものは待たずに直接確認するべき• トップダウンで対応を依頼して、最後は個別に連絡• 対応してもらってセキュリティ監査の工数を大幅に削減