マルチアカウント環境への発見的統制の導入

https://timeedev.connpass.com/event/314564

Transcript

1. 2024/04/16　菅原千晶 マルチアカウント環境への 発見的統制の導入 @ch11aki @ch1aki
2. 自己紹介 菅原 千晶 株式会社タイミー エンジニアリング本部 プラットフォームエンジニアリンググループ Software Engineer (Platform)
3. タイミーについて
4. タイミーの実績 スキマ バイト No.1 ※2024年2月時点　※1 [調査方法]インターネット調査 [調査期間]2021年2月9日~11日 [調査概要]スキマバイトサービスの実態調査 [調査対象]直近1年以内にスキマバイトを経験したことのある18〜69歳の男女1034名[調査実施]株式会社マクロミル 4 利用率 ・ダウンロード数 ※1 導入事業者数 98,000企業 ワーカー数 700万人
8. 募集人数の推移 8
9. 目次 • 背景 • AWS上での発見的統制の実現 • 課題 ◦ 複数アカウントのイベント集約 ◦ 全アカウントへの効率的な導入 • 運用 • その他導入時の困ったこと • まとめ
10. 背景
11. タイミーのAWS環境 • 10以上のAWSアカウント • ステージング/本番/データ分析用... 等、ワークロード別にアカウントを分離 • すべてOrganizations管理 • アカウント毎にStateを分割してTerraformで管理
12. 組織規模拡大によるセキュリティリスク増加懸念 • 組織規模の拡大で発生する変化 ◦ 管理するAWSアカウントやリソースが増加 ◦ アクセス権を持つ人が増加 • 結果、「内部統制の難易度上昇」「情報漏洩や内部不正リスク増加の懸念」 が考えられる • タイミーはリリース後のサービス成長と比例しエンジニア採用を加速、結 果、リリース当初比でエンジニアが7倍に増加した。同時に、リリース当初 から内部統制の重要性を感じていた。
13. セキュリティ面で組織・サービスの成長を支えるために • 前提として完璧なセキュリティ対策は現実的に困難 ◦ 攻撃者優位で先回りの対策が難しい ◦ 使える予算・リソースは有限 ◦ デジタル庁の「政府情報システムにおけるクラウドサービスの適切な利用に係る基本方針」 （※）においても、「セキュリティと利便性とコストでバランスをとる」、「扱う情報の機 密性等に応じたセキュリティ対策をとる」という基本方針 • 「リスクが高いものから優先的に対策を行う」考えが近年では一般的 1. 現状把握 2. 優先順位の決定 3. ロードマップ • 効果的なセキュリティ対策の戦略を立てられるよう、現状のリスクを網羅的 に把握できている状態が望ましい（=内部統制における発見的統制） ※ デジタル庁.「DS-310 政府情報システムにおけるクラウドサービスの適切な利用に係る基本方針」 . https://www.digital.go.jp/assets/contents/node/basic_page/field_ref_resources/e2a06143-ed29-4f1d-9c31-0f06fca67afc/5167e265/20230929_resources_standard_guidelines_guideline_01.pdf,（参照2024-04-09） （個人情報保護を含む法令遵守と消費者保護は大前提）
14. AWS上での発見的統制の実現
15. AWSの発見的統制に関連するサービス • CloudTrail: アクティビティ,イベントを記録 • Config: リソース構成を監査・評価 • Detective: セキュリティ問題の調査支援 • GuardDuty: 脅威検出 • Inspector: 脆弱性管理 • Security Hub: セキュリティチェックとイベント集約 方針に沿って現状を把握するため、 Security HubとGuardDutyで検知している
16. Security Hub • AWSの様々なセキュリティソ リューションと連携し、検知した イベントを集約 • セキュリティ基準に反した設定が ないかをチェック • セキュリティチェックにはAWS Configの有効化が必要 • リージョナルサービスで、利用す るリージョン全てで有効化が推奨
17. GuardDuty • CloudTrail, VPCフローログ等を継 続的にモニタリングし悪意がある と疑われる活動を見つける ◦ 例: EC2がC&Cサーバに通信している ◦ 例: 脅威リストのIPアドレスからAWSの APIが操作されている • リージョナルサービスで、利用す るリージョン全てで有効化が推奨
18. 課題1: 複数アカウントのイベント集約
19. 複数アカウント利用時の運用の手間 • SecurityHub & GuardDuty はリー ジョナルサービス。セキュリティ イベントの検出は各リージョンに 閉じる • アカウント数 ✕ リージョン数 の確 認が必要で手間がかかる
20. 委任管理者アカウントへの集約 • OrgメンバーのSecurityHub / GuardDutyを管理する委任管理者 をリージョン毎に設定可能 • 委任管理者はOrgメンバーの SecurityHub/ GuardDutyのイベ ントを集約可能 • 委任管理者の各リージョンの確認 で済むように
21. SecurityHubのクロスリージョン集約 • 設定した集約リージョンに他リー ジョンのイベントを集約可能 • 委任管理者の集約リージョン1箇所 のみの確認で済む • GuardDutyのイベントが委任管理 者のGuardDutyへ集約される経路 と、各アカウントのSecurityHub 経由で連携される経路があるが、 重複して表示・通知されることは 無い
22. 課題2: 全アカウントへの効率的な導入
23. GuardDutyは委任管理者のリージョン毎で有効化が必要 • Organizations配下のアカウントは、委任 管理者の操作で一括有効化・設定が可能 • ただしGuardDutyとSecurityHubはリー ジョナルサービスのためリージョン毎の有 効化操作が必要で手間が多い • （SecurityHubは「中央設定」を用いれば マルチリージョンのセットアップが可能）
24. AWS ConfigにOrgメンバーを有効化する機能がない • Security Hubのセキュリティチェックの バックエンドであるため有効化が必要 • 委任管理者の設定が行えるが、ルールの一 括管理やメンバーアカウントのイベントの 集約のみ • アカウント数 ✕ リージョン数 の有効化操 作が必要 • Org連携の有効化機能でないと、新たにア カウントを追加した際の手順が増えたり、 有効化を忘れる可能性がある
25. Terraformとマルチリージョンの相性の悪さ • GuardDuty, AWS Configのマルチ リージョンの設定はIaCで省力化可 能ではある • Terraformで複数リージョンを操作 するにはその分Providerを定義 し、resourceのprovider句で設定 が必要 • provider句にはfor_each等の構文 が適用不可のため、コードが冗長 になる provider "aws" { region = "primary" } provider "aws" { alias = "secondary" region = "secondary" } resource "aws_guardduty_detector" "primary" { enable = true } resource "aws_guardduty_detector" "secondary" { enable = true provider = aws.secondary } resource "aws_guardduty_organization_configuration" "primary" { auto_enable_organization_members = true detector_id = aws_guardduty_detector.primary.id } resource "aws_guardduty_organization_configuration" "secondary{ auto_enable_organization_members = true detector_id = aws_guardduty_detector.secondary.id provider = aws.secondary }
26. 課題への対応 • Terraformでリージョン毎に行う必要のある設定をmodule化 • 普段利用しないリージョンをSecurity Control Policyで利用禁止にしてリス クを最小化し発見的統制導入の対象外に • AWS ConfigはCFn StackStesで有効化 ◦ StackStes: Org管理者からメンバーアカウントの指定リージョンへCFn Stackを作成可能 ◦ AWS公式ブログ(※)でもCFn StackSetsで有効化する方法が提案されていた。 ◦ 今回はスコープ外だったAWS ControlTowerの有効化によってAWS Configが有効化される が、その実態もCFn StackSetsであった。 ※ 「AWS Config ベストプラクティス」, Amazon Web Services ブログ, https://aws.amazon.com/jp/blogs/news/aws-config-best-practices/
27. 結果 • 委任管理者の設定をmodule化＆SCPでのリージョン制限により、冗長な Terraformコードが削減 ◦ 前: resource数 ✕ デフォルト有効の17リージョン ◦ 後: 1 module ✕ 許可された2リージョン • CFn StackSetsによりOrgメンバーアカウント追加時にSCPで許可された全リージョ ンにAWS Configを自動有効化することが実現 ◦ CFn StackSetsのAWS Config有効化サンプルをカスタムして利用 ◦ Org管理者アカウントへCFn StackSetsを設定。CFn StackSets自体はTerraformで管理 • 発見的統制を有効化するリージョンが減った分、コストも最適化された
28. 運用
29. 定点観測 • 委任管理者アカウントの集約リー ジョンのSecurityHubから DataDogにログを転送 • アカウント毎の検知ボリュームや 検知数推移等をダッシュボード化 • ダッシュボードを定期的に確認&新 規イベントをDataDogアラートで 通知 • 委任管理者アカウントの集約リー ジョンのSecurityHubで対応
30. コントロールの「失敗」への対応 • Security Hubのセキュリティ基準に対する違反 = 「失敗」ステータス • 内容を確認し、是正すべきものかリスクが許容できるものであれば抑制ある いは無効化を検討して対応 ◦ 是正の例: 「rootユーザーにMFAを設定」 ◦ 抑制の例: 「Secrets Managerのシークレットは自動ローテーションをする」 ◦ 無効化の例: 「すべてのVPCでフローログを有効化」 • コントロールの無効化は以後全く検知されなくなってしまうため、リスク許 容は基本的には抑制を検討し必要に応じてコントロールの無効化を検討する ようにしている
31. その他導入時の困ったこと
32. Orgメンバーアカウントの削除 • Organizationsにメンバーアカウントが追加された場合、Security Hubと GuardDutyが有効になる設定を行った • 動作検証のため、新たにメンバーアカウントを作成 • 検証完了後に追加したアカウントを削除しようとしたがエラー... ◦ 削除するためには、スタンドアロンで動作するようになっている必要（請求や連絡先設定を する必要）がある ◦ アカウント作成後7日以上経たないと削除できない
33. Terraform AWS provider未対応リソース • Security Hubの中央設定 ◦ 当初中央設定は出たばかりの機能でproviderで対応されていなかった ◦ しばらくはドキュメントで設定を示し運用でカバー ◦ 後日対応され、import済み ▪ [New]: Add resources for SecurityHub Central Configuration · Issue #34651 · hashicorp/terraform-provider-aws · GitHub • Security Hub Findings ◦ コントロールの抑制を行う際、経緯を記録したり承認を得るのをPRで行いたかった ◦ 抑制はFindingsに対して行うが、それに対応するリソースが現状無い ▪ [Enhancement]: aws_securityhub_batch_update_findings for suppression · Issue #29164 · hashicorp/terraform-provider-aws · GitHub ◦ workflowステータスの変更をする方法を別で用意する必要がある ▪ schubergphilis/mcaf-securityhub-findings-manager ▪ GitHub - pepabo/control-controls
34. まとめ
35. まとめ • セキュリティ面で成長を支えていけるようバランスの取れたセキュリティを 目指し、脅威やリスクの検知発見的統制と是正を行っている。 • SecurityHub, GuardDutyのAWS Organization連携機能などを活用したこと でマルチアカウント環境へ漏れなく導入が実現できた • Terraformでマルチリージョンのリソース管理はDRYに書きにくいなど相性 が悪い課題があったが、CFnStacSetsの利用やmodule化で改善できた • 運用面ではダッシュボード化や通知の工夫、運用ポリシーの明確化などを行 い継続的に運用できている