狠狠撸

クラウド環境での
セキュリティ監査自動化
森槙悟

アジェンダ
? 大規模なクラウド利用とセキュリティ
? セキュリティ監査の理想の運用フローは？
? 自動化はどうやったらできるか、
どのくらいの実装量?期間が必要か？
? 実際に運用するとどうなるか？

AWSの監査といえば
AWS Configでは？

DeNA Audit AWS Config
ルールの追加
アカウントビュー
集約ビュー
理由付き
NG通知抑制
GCP対応

自己紹介 : 森槙悟（MORI Shingo）
所属
? システム本部セキュリティ部セキュリティ技術グループ
経歴
? DeNA新卒 7年目、セキュリティエンジニア 7年目
? ICFPC 2019 世界8位（Rust）
セキュリティ技術グループの業務内容
? 脆弱性診断
? セキュリティ相談対応
? NW診断
? ログ管理
? セキュリティツール作成、チート対策ライブラリ開発など

目次
背景?課題
? DeNAのクラウド利用状況の説明
? セキュリティ監査自動化が必要になった訳
要件
? 理想の運用フローと必要な機能
? どのような製品を使えば良いか？自作するか？
実装
? クラウド周りの構成と具体的な監査の実装の説明
運用
? 全アカウントに対応してもらうにはどうすべき？
今後の展望?まとめ

DeNAのクラウド利用状況 - 全体管理
主にAWS?GCPを利用
? AWSだけでも250アカウント以上、GCPは600プロジェクト以上
? 月に10個のペースで増加中
? 利用部門数は約60
アカウント作成?キッティングはインフラ部門担当
? アカウント名?利用部門?連絡先などを一元管理
? rootユーザの管理
? 管理用ロールの設定
? フェデレーションを利用したSSO設定の導入
? 監査ログの設定の導入
? コストアラートの導入

DeNAのクラウド利用状況 - アカウント内
アカウント内は開発者が管理者権限を持つ
? 用途がバラバラなのでインフラで全部対応するのが難しい
? 素早く柔軟な設定を行うのに必要
? 規模が大きいものはインフラ管理の場合も
利用者によってセキュリティレベルに差異が出る
? 専門のエンジニアが居ない部署もある
? 相談?調査を個別にするのは工数やスピードに問題あり

アカウント内は開発者が管理者権限を持つ
? 用途がバラバラなのでインフラで全部対応するのが難しい
? 素早く柔軟な設定を行うのに必要
? 規模が大きいものはインフラ管理の場合も
利用者によってセキュリティレベルに差異が出る
? 専門のエンジニアが居ない部署もある
? 相談?調査を個別にするのは工数やスピードに問題あり
セキュリティガイドを作成
? ガイド通りにやれば社内ポリシーに準拠できる
? スピードを保ったまま必要なセキュリティ設定を確認可能

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

全部読んで理解するのがまだ難しい
? 全121項目…
? EC2?S3などサービスを分けても20項目ほどある
? 設定ミスでガイド通りにならない
セキュリティ監査も工数がかかる
? セキュリティガイドとの突き合わせに時間がかかる

全部読んで理解するのがまだ難しい
? 全121項目…
? EC2?S3などサービスを分けても20項目ほどある
? 設定ミスでガイド通りにならない
セキュリティ監査も工数がかかる
? セキュリティガイドとの突き合わせに時間がかかる
工数削減のために自動的にチェックするべき
? APIから取得できる情報が対象

具体的にチェックしたい項目例
? ルートユーザの二要素認証が有効か？
? ルートユーザのアクセスキーが無効化されているか？
? システム用ユーザに利用してない権限が付いてないか？
? システム用ユーザにリソース制限がかかっているか？
? IAMユーザの管理方法は社内規定にしたがっているか？
? IAMユーザに二要素認証?IP制限があるか？
? 利用してないアクセスキーが残ってないか？
? サービスアカウントキーはローテーションされているか？
? 内部用バケットが公開されてないか？
? オブジェクト単位でアクセス権をつけない設定が有効か？
? 公開バケット（S3?GCS）のアクセスログが有効か？
? バケットのデフォルト暗号化が有効か？
? 読み込み?書き込み専用のユーザに過剰な権限が付与されてないか？
? ライフサイクルの設定が短すぎないか？
? ネットワーク設定で不要なポートを開けてないか？
? 本番環境のSSH接続元が踏み台サーバに限定されているか？
? GKEが限定公開クラスタになっているか？
? ELBのアクセスログが有効か？
? ELBの暗号強度は十分か？
? ……

重要な要件
一次対応者はアカウントの管理者
? セキュリティ部にはそもそも修正する権限が無い
? アカウントが数百あるのでセキュリティ部では見切れない
理由?期限を書いてNGを抑制したい
? 人力で判断が必要な監査項目がある
? 本番環境をすぐに直すのは大抵難しい
? セキュリティ監査の際に聞かなくても理由を確認できる
対応状況を監査担当者も確認できる
? UIの権限管理が必要
ランニングコストは抑える

製品選定
AWS Config
アカウント別のビュー?集約ビューの両方がある
理由を書いてNGを抑制するのが難しい
やや高い（年額500万円*?）
3rd partyの製品
集約ビューしか無い（一次対応がセキュリティ部）
高い（年額2000万円?）
DeNA Audit（自作）
作れば全部できる、特にNGの抑制機能
安い（年額10万）
WebUIの作成?機能追加の工数がかかる
* 2018/11に100アカウント1リージョン40ルールで試算した料金
2019/8に料金体系が改定され安くなっています（DeNAの環境では1/5未満）

デモ
S3の公開されているバケットに対する監査のデモ
? 1つのバケットはWebUIからAWSの設定を修正
? もう1つのバケットは公開用なのでNGを抑制
https://youtu.be/67PDgJKDUCE
* デモ用に一部の文字を大きくするなどの変更を行なっています

*正式名称は以下の通りです
EC2 : Amazon EC2
ALB : Application Load Balancer
S3 : Amazon Simple Storage Service
CloudWatch : Amazon CloudWatch
SES : Amazon Simple Email Service

クラウドの構成 - 権限
AWS
? 監査対象アカウントに監査用ロールを作成
? SecurityAudit のポリシーで必要な権限が大体つく
? 監査元のEC2からクロスアカウントでAssumeRoleする
GCP
? 監査元プロジェクトにサービスアカウントを作成
? 監査対象プロジェクト（または組織レベル）でそのサービスア
カウントに役割をつける
? Security Reviewer の役割で必要な権限が大体つく
? 必要なら各プロジェクトでAPIを有効化する

監査ルール実装 - 例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}

監査ルール実装 - 例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}/

監査ルール実装 - 例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://${バケット名}/

監査ルール実装 - 注意点の例
アカウント内で完結しない場合
? ログ出力先が別アカウントなど
? 先に全アカウントのリソース情報を取得し表を作る
複雑なルールは実装が大変
? ファイアウォールやAWSのポリシーなどは頑張る
? 多分しない設定はログだけ出して後で実装
本番データで遅い?エラーになる
? アカウント数が多いので高速化?並列化が必要
? GCPはリソースが無い場合、REST APIが404やnilを返す
? 新機能の利用などで既存のAPIがエラーになる事も稀にある

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整備本番運用

運用 - AWS自動監査開始
AWS側は全社導入した！
? マニュアル?FAQも準備した！
? 全社に連絡した！

運用 - AWS自動監査開始
AWS側は全社導入した！
? マニュアル?FAQも準備した！
? 全社に連絡した！
あんまり対応してくれない…
? 対応してくれている人もいるが全体から見ると足りない
? 運用歴が長いと1アカウントで数百個NGが出る…
? 一度綺麗にすれば楽だがそこまでが大変

運用 - 結局セキュリティ部が見る
危険度が高い項目を集計
? バケットがパブリックになっている
? DBのポートがインターネットに公開されている
? ルートユーザのアクセスキーが有効
? ……
NGを目視確認
? 合計で400件程度
? 明らかに問題ないものは除外していく
? システムの権限で設定を見れるので早い
? 数時間で見終わるのでやる

運用 - 残りの対応
トップダウンで対応依頼
? 実際に危ないのが見つかっているのでスムーズ
? 3ヶ月に一回、各マネージャー陣に対応状況を共有
? 8割のアカウントが対応済みに
残りのアカウント管理者にpush
? 数が減ったので人力で一人ずつ連絡
? 現在進行中

運用 - セキュリティ監査
ヒアリング項目数が大幅減
? AWS：62%自動化（51/82項目）
? GCP：25%自動化（20/79項目）
情報の正確性?速度が上がった
? アカウント管理者にヒアリングするよりも正確
? 年次のセキュリティ監査を待たずに危険な箇所を把握できる
セキュリティ監査担当者も大喜び

今後 - 残課題
全AWSアカウントの対応完了
GCPの自動監査の運用開始
? ルールは実装済み（約20項目）
? 一部プロジェクトで先行導入中
? こちらも全プロジェクト対応済みにする
クラウドセキュリティに関する啓蒙活動
? E-learningなど
別レイヤでのセキュリティの強化
? 今回対象外としたレイヤの監査の自動化
? クラウド環境に対するSOC
? 不正アクセス検知、脅威検出など

今後 - 新機能への追従も必要
新機能のチェック
? 公式の発表?ブログ?リリースノート?週刊AWSなどを定期的
に確認する
? 発表会の内容をチェックする
? AWS re:Invent, Google Cloud Nextなど
セキュリティガイド?自動監査の更新
? 公式ドキュメントの確認?動作検証を行ない追加が必要か検討
? 必要ならセキュリティガイドの更新と監査を実装
? 全社に連絡して順次対応してもらう

まとめ
クラウド環境のセキュリティに課題
? 利用者によってレベルがバラバラ
? 数が多すぎて設定確認?セキュリティ監査に時間がかかる
要件に合うシステムを自作
? 日毎に監査、NGの項目はアカウント管理者に通知
? 理由?期限を書いてNGを抑制可能、棚卸しにも利用可能
? 実装は頑張る、工数が足りない時は重要なルールのみに絞る
全て対応してもらうのは大変
? 危険度が高いものは待たずに直接確認するべき
? トップダウンで対応を依頼して、最後は個別に連絡
? 対応してもらってセキュリティ監査の工数を大幅に削減

狠狠撸

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

More Related Content

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