【レポート】CUS-77: 6000 個のセキュリティポリシーを自動監査！アカツキ流、AWS セキュリティの取り組み紹介 #AWSSummit

いやー実際の対応内容が詳細に説明されていていいセッションでした。AWS Summit Onlineのオンデマンドセッションである「6000 個のセキュリティポリシーを自動監査！アカツキ流、AWS セキュリティの取り組み紹介」のレポートです

AWS Summit Online Japan 2020

#レポート

#セキュリティ

#CloudFormation StackSets

#AWS CloudFormation

#Config Rules

臼田佳祐

2020.09.08

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

こんにちは、臼田です。

皆さん、AWS Summit Online Japanを楽しんでいますか？(挨拶

今回は『CUS-77: 6000 個のセキュリティポリシーを自動監査！アカツキ流、AWS セキュリティの取り組み紹介』というセッションを聞いたのでそのレポートをします。

大規模なAWSアカウントのセキュリティ監査をいかに効率化・自動化していったかというお話でした！ぜひレポートや本編をご確認ください！

セッション概要

株式会社アカツキモバイルゲーム事業部テクニカルエヴァンジェリスト駒井祐人氏

AWS アカウントを一定数運用していると、組織のセキュリティポリシーから外れた運用をしていないか監査する工数が大きくなります。本セッションでは - AWS Config をマルチアカウント運用し、6000 個のポリシーチェックを自動監査 - CloudFormation StackSet により、組織の全 AWS アカウントに監査設定を一括更新 - AWS CIS Benchmark Tool のサーバレス運用といった話をします。これらのキーワードにご興味ある方はぜひご覧ください

セッション動画と資料

動画と資料はこちら

レポート

自己紹介
- 駒井祐人氏
- アカツキでサーバーエンジニアやクラウドセキュリティ管理者をしている
- 昨年のAWS Summit Tokyo 2019に登壇
  - 大規模ECS & Docker運用の話をした
会社紹介
- 「”A Heart Driven World.” ハートドリブンな世界へ」をビジョンに掲げる
- 様々なゲームタイトルを世界中に展開している
昨今のセキュリティインシデントや脅威の事例
- S3バケットの設定ミスによる1億2000万世帯以上の個人情報流出
- 脆弱な部分があればあっという間に狙われる脅威がある
クラウドセキュリティの課題感
- 2つの観点で分けて考えている
  - 可視化と統制
  - 脅威に対する検出と対応
- 今回は可視化と統制の話
今日お届けすること
- 40個以上のAWSアカウントの全リージョンに対して6000個以上セキュリティポリシー監査を自動化し自動監査設定を継続的にデプロイしつづけられる仕組み
- それを実現してきたストーリー

全体像

アカツキのAWS規模(2020/06時点)
- 40個以上のAWSアカウント
  - 昔はもっとあったが整理した
- 130個以上のカスタムVPC
- 運用しているEC2インスタンスは1000以上
クラウドセキュリティ取り組みの全体像
- 色々あるが、今回はAWS Configについて
AWS Config
- AWSの各種設定がルール通りに設定されているかを評価できるサービス
AWS Config マネージドルールの例
- AWSから提供されるルール
  - 例えばaccess-keys-rotatedはIAMアクセスキーが指定した日数以内にローテーションされているかをチェックできるルール
- 有効にすればアカウント内でどのリソースが準拠できているか、できていないかがわかる

AWS Configを使ったマルチアカウント自動監査

AWS Config導入前の監査
- セキュリティポリシーの項目に対してチェックリストを作り監査する運用だった
- 課題
  - 工数
  - チェックの確からしさ
    - 人がチェックしているので
  - 抜け漏れ
課題を解決するためにAWS Configを利用するようにした
AWS Configを使った監査の流れ
- Configのルールで変更があるリソースをほぼリアルタイムでチェックしてくれる
  - 例えばセキュリティグループでIP制限がかけられていないポートが開放されている場合、Configルールでチェックしてくれる
  - 準拠から非準拠に変わったら通知できる
- マネージドルールだけだとチェック項目に限界があるのでLambdaでカスタムルールを作成している
  - 例えばiam-ip-restrictionというルールを作っているが、マネージドルールと同じようにConfigで検知して通知できる
実装したカスタムルールの例
- IAMユーザーのAccess KeyにIP制限がかかっているか
  - アカツキではなるべくIAMユーザーを作成しないようにしている
  - もし作成する場合にはIP制限を義務化している
  - それを自動でチェックできる
  - awslabs/aws-config-rules/python/IAM_IP_RESTRICTIONにPull Requestを送ってマージされているので誰でも利用可能
- セキュリティグループに公開IPが存在しないか
  - vpc-sg-open-only-to-authorized-portsというマネージドルールがあるが、例外設定が行いづらいので改良している
  - 元のルールはタグをつけることが必須だったので逆にしている
- AWSアカウントが利用されているか
  - IAM Roleの最終利用日をチェックしている
様々なチェックを自動化できた
- ただしここまではシングルアカウントでの話
マルチアカウントでの運用のポイントは2つ
- Aggregator View
  - Configの準拠状況をまとめて一覧化できる
  - どれぐらいのルールが準拠できているかなどを表示
- Lambdaカスタムルールの一元管理
  - カスタムルールのLambdaを全リージョンに展開するとコードが重複する
  - 一元管理するために管理アカウントのLambdaから子アカウントに利用できるようにする
  - 子アカウントのカスタムルールから管理アカウントのLambdaを参照
  - 管理アカウントのLambdaから子アカウントのマネージドルールがチェックできるように設定している
  - 実際に設定する際のパーミッションの設定のTipsも紹介しているので詳しくは動画で！
- 他にも変更イベント、通知先の一元管理をしている
  - 子アカウントで検知した内容を管理アカウントを経由してSlack通知する
  - 通知する担当者とSlackIDを管理アカウントのSecretsManagerで一元管理している
  - あるアカウントで違反があったらそのアカウントの管理者に通知される
- AWS configで監視できているルール数は6000以上
  - 全アカウント全リージョン合計
AWS Configで実現できたこと
- 40以上のAWSアカウントの全リージョンに対して6000以上のセキュリティポリシーの監査を自動化
- カスタムルール作成によりマネージドルールに存在しない項目も監査
  - awslabsにも貢献
- カスタムルールや変更イベントの一元管理により管理負荷を軽減
これでうまくいきそう？
- まだ課題があります
- 次の章で説明

AWSマルチアカウントへの自動デプロイ

課題
- AWS Configルールを含むセキュリティ統制の運用管理が膨大
  - CloudFormationでAWS Configを管理していたが当時は各アカウントに個別で適用していた
  - 1つのオペレーションで40アカウント * 15リージョン = 600stackの修正が必要だった
CloudFormation StackSetsを利用して解決
- マルチアカウント、マルチリージョンのStackを一括管理できる
- 適用するとどのアカウントのどのリージョンがどうなっているか確認できる
というわけで移行を開始
- なにか設定を入れればいいわけではないのでStackを作り直した
- S3バケットは中身があると削除できないので頑張って移行した
(旧)StackSetsの仕組みに問題があった
- AWSCloudFormationStackSetExecutionRoleというロールを子アカウントに作成する必要があったが、この権限がAdmin権限レベルであった
- そのため管理アカウントからほぼなんでもできてしまうのでセキュリティ的に良くない
- 課題
  - 権限が強すぎるIAM Role
  - 自動化が中途半端
    - 事前に子アカウントにRoleを作成しておく必要がある
2020/02にStackSetsとOrganizationsが連携する機能がリリース
- Organizationsでは組織をOU単位で分割してツリー状に構成できる
- IAM Roleを作成する方法も引き続き利用できるが、現状ではOrganizaionsの利用がオススメ
- この機能により課題がまとめて解決された
  - 強力なIAM Roleが不要
  - 組織単位のデプロイ
  - 自動デプロイ機能
- 自動デプロイでは組織にAWSアカウントを追加されたら自動でデプロイできる
このリリースを受けてOrganizations連携に移行
- また全て作り直しをした
- しかし自動デプロイがこのままだと失敗した
  - IAM作成とConfig作成を別Stackにしていたが、順序や依存関係を持たせることができなかった
対処
- まずはStackを統合した
- 全リージョンに展開するとIAMが重複してしまうので、バージニア北部でのみIAMを作成するようにした
- StackSetsの実行順序性を利用して、バージニアから実行するようにした
  - テンプレート例は資料を参照！
これで無事簡単にできるようになった
- テンプレートを少し追加してポチっとするだけ
CloudFormation StackSetsとOrganizationsで実現できたこと
- 1オペレーションですべての組織アカウントに対して更新でき、各アカウントへのログインも不要になった
- 自動デプロイ機能により新規AWSアカウント作成時のセキュリティ設定を自動化

おまけ

AWS OrganizationsでのOU変更は簡単にできる
- 自動デプロイが有効になっていると、移動するたびにStackSetsが実行されるためカオスになるので気をつけよう
停止したAWSアカウントがある場合
- 90日くらいはOrganizationsから外れないのでStackSetsの変更を行うと失敗する
- 停止アカウント数 * リージョン分失敗して処理がロールバックする
- 障害耐性オプションを使って回避する必要がある

その他の取り組み紹介

セキュリティ設定が削除されない仕組み
- サービスコントロールポリシー(SCP)で初期統制の削除を禁止
  - CloudTrailやGuardDutyなどの削除を禁止
AWS Config以外で利用している監査サービス
- Trusted Advisor
  - Lambdaで全アカウントチェックするようにしている
- Prowler
  - オープンソースのツール
  - CIS Amazon Web Services Foundations Benchmark等がチェックできる
  - これをサーバーレスに全アカウント一括チェックしている話もどこかでしたいです(編集注: 期待上げ！)
選定していないAWSサービス
- Amazon Inspector
  - 脆弱性診断のサービス
  - 使いづらいところがあるのでFutureVulsを利用している
- ECRスキャン
  - コンテナレジストリのスキャン
  - 有効化はしているが結果が微妙なのでこちらもFutureVulsを使っている
- AWS Security Hub
  - 統合UIのみなので使っていない
- AWS Control Tower
  - 選定時はControl Towerを有効化する前に作られたアカウントへの統制ができなかった
- Amazon Macie / Amazon Detective
  - Macieは安くなったがそれでも安くないので使っていない

全体まとめ

AWS Configのマルチアカウント運用により6000個以上のセキュリティポリシー監査を自動化
CloudFormation StackSetsにより全AWSアカウントのセキュリティ設定更新を自動化
- さらに自動デプロイ機能により、新規AWSアカウント作成時のセキュリティ設定も自動化
SCPによりこれらの初期統制が削除されない仕組みを導入
しかしながら設定を導入する大前提としてセキュリティポリシーが大事
- セキュリティポリシーの見直しや助言にAWSプロフェッショナルサービスを活用した
- AWSプロフェッショナルサービスに感謝している