Security-JAWS 第27回レポート #secjaws #secjaws27 #jawsug

こんにちは、臼田です。

Security JAWS 第27回が開催されましたのでレポート致します。

Security-JAWS【第27回】 勉強会 2022年11月21日(月) - Security-JAWS | Doorkeeper

動画

レポート

Session1:「AWSセキュリティのベストプラクティスに関する利用実態調査」の報告 Security-JAWS運営メンバー

• 先日取らせていただいたアンケートのレポート
• 調査概要
  • AWSセキュリティに関するベストプラクティスが色々公開されているが、正しく利用できているか？
  • 不安とかないか？
  • 気になったので調査してみた
• 回答数162件
  • 少なすぎることは無いが多くはない
  • 会社規模、業種、回答者の役割などにある程度偏りがあることは注意して見てほしい

設問の回答と考察

• 参照しているAWS公式ドキュメントを教えて下さい
  • 選択肢のドキュメント
    • Security Hubのベストプラクティス
    • AWSセキュリティのベストプラクティス(アーカイブ)
    • AWS Well-Architectedフレームワーク
    • IAMでのセキュリティのベストプラクティス
    • AWSクラウド導入フレームワーク(CAF)
    • AWSでバックアップを保護するためのセキュリティベストプラクティスTop10
  • 経験年数をカットに分析
    • AWS Well-Architectedフレームワークの参照率は10年以上AWSの経験がある人は100%の利用率だった(母数は少ないが)
    • AWSセキュリティのベストプラクティスはアーカイブされているが、検索で一番上に出てくるからか全体の参照率が高い
  • 考察
    • 今やるならAWS Well-Architectedフレームワークからがいいのではないか
    • 個別のユースケースはソリューションアーキテクトに相談するといいのでは
• 組織内の役割として、ベストプラクティスをキャッチアップしている人は誰ですか？
  • 業種別で分析
    • いろんな業種の方から回答をもらったが、ほとんどコンピュータエレクトロニクス、ソフトウェアインターネット、金融及び関連サービスの3業種で109回答あった
    • そのため、この3つで分析
    • 金融は他業種よりいろんな部門でキャッチアップできていた
      • きちんとできているイメージ
• AWS環境を用いたシステムを構成したあとで継続的なリスク評価は行っていますか？
  • 会社規模で分析
    • 小規模は行っていないところが多い
    • 少なくとも特定のAWS環境ではやっている割合は高い
    • すべての本番やすべてのAWS環境では2割以下と少ない
• コロナ禍の対応で、自宅から本番環境を操作できるようにしましたか？
  • 会社規模で分析
    • 101〜300人の規模では7割以上が元からできるようにしていた
    • 1001〜5000人規模ではこの切替をしている割合が2割と低い
      • この状況でも出社等を必要としているところが多いことになる
• 自宅から本番環境を操作するために特別にやっていることや利用しているものがあれば教えて下さい
  • 会社規模で分析
    • IPアドレス制限や踏み台サーバーはどの規模でも多い
    • 特に中規模周辺はIPアドレス制限が多い
    • 操作証跡は中規模以上では割合高い
    • ただ人とデータを分離する、というセキュリティのベストプラクティスについては殆どできていなかった
• 技術者や運用担当者がAWS環境を操作するためにどのような方法でアクセスしていますか？
  • 会社規模で分析
    • IAMユーザーとMFAが5割以上
      • これがスタンダードと言ってもいい
    • しかし5001人以上の企業だけIAMユーザーのID/パスワードのみが2割近くありダブルスコア
      • 大規模な会社は気をつけてほしい
    • 中規模だとIAMユーザー + MFA + スイッチロールが7割を超えていて高い
      • 非常にいい
• 発見的統制として使っているAWSサービスなどを教えて下さい
  • 会社規模で分析
    • CloudTrailやGuardDutyは高い
      • 特に301〜500人規模では86%超え
    • IAM Access Analyzerの利用率は2割と低かった
      • すごくいいからちゃんと使って
      • 無料だよ
• CloudTrailを分析する上で、度のサービスを使いますか？
  • 経験年数で分析
    • 経験年数が浅いとコンソールのみ
    • 経験が増えるとコンソール、Athena、GuardDutyに任せるが高い
• ここまでの感想
  • ドキュメントは検索で出やすいものは認知されているが活用できているかは規模によって異なる
  • データから人を離す、すべてのAWS環境に対して確認するなどハードルが高いものは総じて低い
  • 中規模の企業の方が新機能などはフットワーク軽くできている
• おまけ
  • 回答いただいた方へのフィードバックはもう少し後正式レポートをまとめた後共有します

Session2: 高校生が学校でAWSを導入した話 ～その軌跡と学習プロセス～ 西大和学園高等学校 技術統括局 栗栖 幸久さん(生徒)、伊藤 凌太朗さん(生徒)、情報科 光永 文彦さん

• 軌跡と学習プロセスについて
• 西大和学園とは
  • 奈良県の法隆寺の近く
  • 中高合わせて約1,800名
• 課題活動
  • SSH(Super Science High school)
    • 1年間かけて植物〜情報系の研究
    • AIを使った研究などもやっている
  • 西大和学園技術統括局
    • 「好きで西大和を創る」のコンセプトを元に設立された部活でも生徒会でもない組織
    • 活動内容は音響や撮影やシステム開発、3DCGなど多種多様な生徒が集まっている
  • 文化祭
    • 生徒主体の面が強い
    • 予算も生徒会で決定する
    • 今年は花火を実行したがクラウドファンディングや許可取りなども生徒がやっていた
• 技術統括局がどのようにAWSを活用したかの話
  • 昨年10月の文化祭終わり
    • オンライン文化祭をコロナの年から3回やっている
    • 有志で動画公開を行っていた
  • 3つの方法
    • YouTubeで通常公開
    • YouTubeで限定公開
    • Google Driveの共有機能で組織内のみ
  • 問題点
    • 通常公開
      • コメントを開放できない
      • ダンス音源でBan可能性あり
    • 限定公開
      • リンクされ知っていたら見れるのであまり意味がない
    • 共有機能
      • プレビュー回数に制限があり見れない人が出てくる
  • 解決方法
    • 他のプラットフォームに移行
      • いいものがなかった
    • 自作する(半分ネタ)
      • IVS(AWS)と出会う
• ここで初めてAWSに出会った
• IVS(Amazon Interactive Video Services)
  • AWSのライブ配信サービス
  • 特徴
    • 超低遅延(2s〜)
    • FHDまでの入出力
    • 拡張性がすごい
    • アーカイブをS3に保存できる
• 使ってみよう
  • 当時は知識が全然なかったが試してみた
  • GitHubの公式サンプルをつかう
    • 家でテストしてすごさを確認
  • S3静的ウェブホスティングで試験運用
• 超低遅延が生み出した良い点
  • いままでは先生が話したら20秒後ぐらいに笑いが起きるぐらいの遅延だった
  • これがほぼ無くなった
  • インタラクティブな体験につながった
• 当時の知識
  • AWS = なんかいっぱいサービスあるやつ
  • サーバー = なんかすごい止まったらやばい高スペックなやつ
  • 頑張って勉強した
    • すごそう、楽しそう、いろいろできると変わっていった
• ただコードが書けなかった
  • プログラムに強い生徒が入局してくれて夢物語が企画案となった
• AWS活用実績
  • 文化祭HP(LightSail)
  • 動画配信
  • などなど8つぐらい
  • 体育祭選手エントリー管理システム
    • いままで手打ちだった
    • Textractで読み取り、csvで書き込み
  • NYGstreaming(動画配信プラットフォーム)
    • IVSによる超低遅延配信 + CloudFrontを用いたコンテンツ配信
    • CM機能つき
    • CORSなどやった
  • チケット管理システム
  • 入退場管理システム
    • 端末配布など必要なくなった
  • 3DCGバーチャル校舎
    • 背景
      • 2020年度に文化祭の縮小とオンライン化によって3Dモデル化+オンライン化を進めた
      • clusterを用いて公開したが製作作業が複雑でありユーザーはインストールやログインが必要であった
      • 次年度から異なるプラットフォームを使用することにした
    • 2021年度
      • UnityからUnreal Engineに変更
      • パッケージ無しでログインなしで参加できるように
      • しかしPCのみとなって逆に参加しづらくなった
      • 技術力やスペック不足が浮き彫りに
    • 2022年度
      • GameLiftを用いてオンライン化を企画したが失敗した
      • 代わりにDOORを知り、Hubsを知った
      • Hubsを活用することにした
        • 3Dモデル以外にも画像・音声・動画・サイトのリンクなどを掲載することが可能
        • 導入メリット
          • Blenderから.glbファイルでインポート可能
          • ログイン・インストール不要
          • スマホからでも参加可能
        • ランダムで部屋を割り当てる形式にした
• どうやって企画を先生に認めてもらったか
  • 苦労したところ
    • 資料作りとプレゼンの繰り返し
    • インターネットとはなんぞやから話した
    • 生徒と先生の思う利点がギャップになっていた
  • 良かったところ
    • 生徒主体の風潮があったので寛容ではあった
    • ITが比較的浸透している
    • 予算も予測できた
• 学習方法
  • 期間が短すぎたので体系的に学習できていない
    • サーバーの勉強
  • やりたいことからベースで検索して学習した
  • いろんなドキュメントのお世話になった
• セキュリティ対策
  • 構築で手一杯になってしまった
  • EC2をうっかり終了してしまう事件が起きたので管理者の人数を削減した
  • WAFでCAPTCHAを実装した

感想

すごいなぁ…(圧巻)

高校生の段階で色々できていてすごいですね！(語彙力喪失

日本の未来は明るいですね！

Session3: スタートアップ企業で始めるAWSセキュリティ対策　～内部統制の観点から～ ニューリジェンセキュリティ株式会社 大島 悠司さん

• 自己紹介
  • クラウドセキュリティアーキテクト/基盤リーダー
  • これまではデジタル・フォレンジックやマルウェア解析など
• 会社概要
  • nuage + intelligenceの造語
• Cloudscortというサービスを提供している
  • クラウドネイティブ機能を強化するサービス
  • SaaS型で機能を提供
• 今回はスタートアップとして企業内で取り組んだことの話
• 内部統制の重要性
  • 細かい話はしない
  • 業務の適性を確保する
  • 権限に回すための取り組み
  • 基本要素にITへの対応があるので今回はこれに着目
  • 最近は内部不正による情報漏えいも後をたたない
  • 健全なシステム運用、アクセス権限管理など気をつける
• スタートアップこそ内部統制に気を使うべき理由
  • スタートアップの爆速的な速さ
    • とにかくリリース頻度が早くセキュリティが二の次になりやすい
    • ルールがない中でどんどんプロダクトが増加
    • 急にアカウントが追加
  • 急に求められるセキュリティ水準向上
    • セキュリティ監査や認証取得
    • ステークホルダーからの要求
  • 遅かれ早かれ時間を掛ける必要がある
  • 初期段階で統制の取れた運用にすべき
• どうしているか
  • シングルアカウントの課題
    • セキュリティやガバナンスの確保が困難
      • タグベースの権限管理は複雑
    • 課金の分離が困難
      • コスト配分タグも複雑
    • 運用が困難
      • オペミスによる本番ワークロード削除のリスク
      • サービスクォータ値に引っかかる
  • 最初からマルチアカウントにしましょう
    • セキュリティやガバナンスが向上
    • 課金の分離できる
    • 運用効率化
      • 変更の影響を最小限にできる
    • アカウント分割は開発ステージング本番などで分ける
• 構成例
  • ユーザー管理アカウントから他のアカウントに入れるようにする
  • ログアーカイブや監査アカウントなどを分ける
  • 請求管理も分ける
• マルチアカウント構成を手軽に実現する方法
  • AWS Organizations
  • AWS Control Tower
• Jumpアカウント方式
  • ユーザーの集約方式のひとつ
  • ユーザーはJumpアカウントにIAMユーザーとしてログインしてからSwitch Roleする
• IAM設計のコツ
  • 役割ごとにグループを分ける
  • グループに対してスイッチできるアカウントトロールを固定
  • 読み取り専用権限のロールもあると安心
• 本番環境へのアクセス統制どうする？
  • 変更管理
    • 誰が、いつ、変更作業のために本番環境にログインしたか追える？
  • 本番アクセス統制
    • 本番環境にいつでもアクセスできるようになっていないか
• Change Managerでアクセス管理
  • アプリやインフラの変更管理を提供承認フローを組める
  • 本番アクセス用グループを作成
  • このグループからのみ本番環境の作業ロールにスイッチ可能
  • Change Managerの承認でこのグループに追加
  • TTLタグをつける
  • 関連資料は後ほど紹介
  • ざっくりイメージ紹介
    • 指定したグループに参加するリクエストを出す
    • パラメータとしてIAMユーザー名、グループ名、TTLを入力
    • 承認者がコメント付きで承認
    • タスクが実行される
    • タイムラインで誰が承認したかなどもみれる
• ユーザーの手間を最小限に本番アクセス統制を実現
• ブログはこちら
• 気をつけるポイント
  • 請求情報の閲覧禁止
    • 金銭事情を把握される
    • ホワイトリスト方式だとうっかり閲覧を与えてしまうこともあるので明示的に拒否することを推奨
    • IAMユーザーが請求情報にアクセスできるようになる設定がONだと注意
  • S3オブジェクトのダウンロード禁止
    • 本番はS3に機微な情報が多い
    • ReadOnlyAcceessでもダウンロードは可能
    • 明示的に拒否
  • S3オブジェクト削除禁止
    • ログなど
    • 明示的に拒否
    • オブジェクトロックも検討
  • ネットワーク作成禁止
    • 不要なネットワークを作成させない
    • 管理者が把握していない出口経路の作成を禁止
    • スタートアップの場合には知らない内に増える
    • VPC削除はハードル高いのと、勝手に外に出れる方が怖いので
  • IAM操作禁止
    • 高権限のポリシー作成、既存ポリシーの削除を禁止
    • PowerUserAccessを使う手もある
      • PassRole必要
    • CloudFormation用のロールを用意し、指定させる
    • 証跡としても活用でき不都合が生じたらStack削除
  • アカウントごとのIAM操作権限と運用例
    • 開発を阻害しすぎないことも重要
    • 開発環境はある程度許容する
    • ステージングに持っていく段階でCloudFormationのテンプレートにしてもらう
• まとめ
  • スタートアップこそ早期に内部統制の観点でセキュリティ対策をする
  • マルチアカウント設計をしてセキュリティ機能やログ保存は別アカウントに集約
  • IAM設計は本番環境へのアクセス権限が過剰でないかも確認
  • Change Managerを使うことで変更管理とアクセス統制の死喰いを実現
  • 使いやすさとセキュリティのバランスを考えることが必要

感想

大事ですね！大事なポイントはまとまっているのでぜひ検討してみてください。

Session4: 本当に必要？AWSのネイティブなセキュリティ機能とPrismaCloudを比較してみた SB C&S株式会社 ICT事業本部 ﾈｯﾄﾜｰｸ&ｾｷｭﾘﾃｨ推進本部 N&Sｿﾘｭｰｼｮﾝ販売推進統括部 販売推進1部 3課 鈴木 孝崇さん

• 自己紹介
  • SESでいろんなプロジェクトを経由した後現職でセキュリティ製品の販売推進
• 会社紹介
  • ソフトバンクグループの流通
  • 取り扱いメーカーは4,000社、商材は400,000点
• 前提
  • Prisma Cloudの機能を軸にAWSのネイティブなセキュリティ機能と比較
  • Prisma Cloudをどんなときに使うのが良いかの考察
• Prisma Cloudの機能
  • Palo Alto Networksの製品
  • CNAPPの幅広い領域をカバーしている
• 結論
  • シングルクラウドであればAWSのセキュリティ機能を使う
  • マルチアカウントの環境であればPrisma Cloud検討あり
  • クラウドネイティブな環境であればPrisma Cloudを使ったほうが良い！
• なぜこう考えたのか
• シングルクラウドであればAWSのセキュリティ機能を使う
  • まずAWSのセキュリティ機能でどこまでできるかを知る
  • CSPM関連の機能としてネイティブのものがある
  • AWS Config
    • AWSリソースの設定を評価、監査する
  • GuardDuty
    • 悪意のあるアクティビティを検出
  • Inspector
    • 脆弱性のスキャン
    • EC2/ECRに対応している
  • Security Hub
    • ベストプラクティスのチェック
    • 手軽に始められる
  • Audit Manager
    • 証跡の自動収集をしてコンプライアンス対応できる
  • Prisma CloudのCSPM
    • クラウドベンダーが提供するAPI経由で安全に情報を収集して自動診断
    • 多くのパブリッククラウドをカバーしている
    • EC2 / ECR / ECSをカバー
    • アカウント連携するだけで手軽に見れる
    • 設定ミスの検知
      • 設定ミスの詳細も追いやすい
      • SQLライクな検索言語で柔軟な検索が可能
    • コンプライアンス準拠の状況をグラフでひと目でわかる
• マルチアカウントの環境であればPrisma Cloud検討あり
  • 他にもAzure / GCP / Alibaba / OCIをカバー
• クラウドネイティブな環境であればPrisma Cloudを使ったほうが良い！
  • ここでのクラウドネイティブとは
    • CNCFの定義
    • コンテナ化
    • CI/CD
    • オーケストレーション & アプリケーション定義
    • 拡張性、柔軟性に優れたアプリケーションを活用してセキュリティを適用する
  • デプロイまでの流れでのポイント
    • コードを信頼しない
    • ベースイメージ、パッケージ、設定を信頼しない
    • ランタイムを信頼しない
  • Prisma Cloud
    • IaCスキャン
    • CI/CD連携
      • ルールを満たさないとデプロイさせないなど
    • 脆弱性スキャン
      • EKS、ECS、ECR、EC2、サーバレス、オンプレミス
      • エージェントレスも可能

感想

Prisma Cloudは1つの画面でいろんな機能をまとめてみれるのはメリットですね。

費用や工数を検討して使い分けていただくと良いと思います！

Session5: AWS Security Hubの導入から運用を回すためにやってきたこと 株式会社Gunosy 技術戦略室 SRE 山口 隆史さん

• 自己紹介
  • Pure SREとして活動
• 会社紹介
  • 情報を世界中の人に最適に届ける
  • グノシーを提供
• Security Hub導入の背景
  • セキュリティ対策に対する優先度が上がった
  • きっかけはLog4j問題
    • 調査が人力総力戦だったのでやりたくない
  • 定期的・自動的にスキャンして継続的に潰していくサイクルにしたい
    • セキュリティの設計への組み込みは個人に依存していた
  • ぐるぐるまわしたい
• AWS環境の全体像
  • OU構成
    • プロダクション
      • 本番
      • 非本番
    • サンドボックス
    • Security
  • Control Towerの標準実装に近い
• 開発組織体制と担当
  • 開発チームがインフラの構築・運用・オンコールを担当して自律的にやっている
  • SREは開発チームがプロダクトの価値創造に集中できる状態を創る
  • インフラはIaC/Terraform
• Security Hub導入の流れ
  • 事前調査
  • PoC
  • 運用検討
  • 導入・運用
• 導入方針
  • Control Towerを導入してConfigも自動有効
  • Security Hubは委任
• 机上調査
  • 既存アカウントに導入した際の影響確認
  • SCPの確認
    • Control Tower配下のOUに参加させない限り問題なさそう
    • CloudTrailやCoinfigの制約は強い
  • Trailまわり
    • 専用の集約先になるので変更が必要
  • コントロール、事例の調査
    • AWSの公式ドキュメントを調査
    • トラブル事例や導入事例
      • 有効にしたほうが良いコントロール、無効にしていいコントロール
        • まとまった情報ない
      • 運用の知見
      • トラブル
• PoC
  • Control Tower有効化
  • Security Hubを有効化して委任
  • 検証
    • 指摘事項がどう見えるのか
    • 自動修復
  • 課題
    • 点数が当てにならない
      • 重要度に関係ない点数になる
      • 点数は気にしないようにした
    • 無駄な指摘、解決不能な指摘がある
      • 自社では問題ない指摘が多い
      • 対応すると料金がかかることを指摘される
      • IAM.6やS3.9など
      • 有効化無効化を検討して設定に反映
      • 自分で頑張る必要がある
    • 基準・コントロールの有効化・無効化がメンバーアカウントへ伝搬しない
      • 委任アカウントでコントロールを無効化してもメンバーアカウント側では有効のまま
      • aws-samplesのソリューションを導入した
      • 下記参考
    • 自動で修復できるところは修復したいが悩ましい
      • IaCで管理していないリソースとしているものがある
      • 修復するタイミングが選べない
      • 管理しているリソースはもとに戻る
      • 使わずにIaCで修正する方針
• 運用方法の検討
  • 指摘の対応どうするか
    • 開発チームに負担を書けたくない
    • 今のSREの体制で運用が回るか
    • セキュリティは担保したい
  • CRITICAL、HIGHを対応
    • MEDIUM以下は放置
    • 設計でセキュリティが確保できていれば即座に問題になる指摘ではないと判断
    • CRITICALはSREが最速で対応
  • 抑制にする基準
    • リスクが許容できることが大前提
    • JIRAで起票
    • 開発チームに依頼するスプレッドシートにまとめる
    • 新しい指摘はSREが定期的にチェック
  • 運用フロー
    • 定例の振り返り準備
      • 起票など
    • 定例振り返り
      • やるやらない競技してその場で起票
• 本番へ導入
  • Control Tower有効化ずみ
  • お膳立て
    • StackSetsを3つ作る
  • メンバー環境を新OUに移動
  • 手動で対応
• 本番移行後出てきた問題
  • 委任アカウントのSecurity Hub画面だと絞りにくくてトリアージに時間がかかる
    • 各アカウントで確認
  • 料金爆発した
    • Configの料金が爆発
    • immutableにリソースを使い捨てしていたアカウントで発生
      • ECS TaskDefinition
      • EC2 NetworkInterface
    • 事前に調査はしていたので対応はすぐできた
      • SCPでConfigを直接いじれない
      • StackSetsのパラメータを変更
      • AWSControlTowerBP-BASELINE-CONFIGのパラメータ変更
      • シェルで対応策作った
  • 指摘どおりに対応したら障害発生
    • EC2.22とEC2.18
    • EKSのクラスターセキュリティグループが対象になる
    • EKSのクラスター再作成するしかなかった
• まとめ
  • AWS Security Hubとうまく付き合いましょう
  • 導入よりもその後の運用が大事
  • うまくトリアージしましょう
  • アクセス権限不備、不正アクセスなどは他のサービスでチェックしましょう

感想

わかりみがふかい…

ひたすら使ってレポートしてフィードバックをしていきたいですね

Session6: [クラウドZoom相談] 当日のslido & ドアキで受付けた質問に回答する枠 Security-JAWS運営メンバー

CSPMって必要？

• あったほうが良い
• 自分たちで全部チェックするのか？と比較検討
• 機能との付き合い方は大事

プロダクトセキュリティ(SaaS)についてどうやって指針を作ったら良いか。どこまでやってればOKとかの感覚がない。

• どんな情報を持っているのかを洗い出してリスクを考えると感覚つかめるかも
• CISやSecurity HubなどCSPMの仕組みを使って出てくる状態を見てみると、どこまでやっていくか考えられるかも

正直なところ、ebsを暗号化はどのような目的で実施するといいでしょうか？組織のルールに準拠する、以外でお願いしたいです。ebsを部外者がアタッチすることを避ける以外だと、ストレージに直接接触できる人間への対策くらいしかないような気がしていて、前者はいいとして、後者目的だとそこの責任範囲はAWSなのでわざわざ暗号化する必要性を感じません。

• これは逆で、責任は顧客であり、その手段をAWSが提示しています
  • 暗号化することがベストプラクティスであり説明責任を果たす手段なので、それをしない場合はどういう場合なのか？という逆の手順で考えるほうが適切です
• こちらもどうぞ
• クラウドにおける安全なデータの廃棄

AWS Config の運用をどうやっているか。Standards の選定と各コントロールの対応要否、個別のfindingsのアラート通知と対応までのフローなど。またproduction, testなどの環境差異によるポリシーの分け方も気になっています。

• こちらの最後の方が本番とそれ以外のポリシー分けの参考になるかも
• 検証環境だからConfigを使わない、ということは無い

AWSのセキュリティ対応を行う上で、AWS自体の機能で実施するべき領域と、外部ツールで実施するべき領域について、見解をお聞かせいただきたいです。質問背景としてはAWSの監視機能を持つ製品の提案を担当しており、AWSを利用しているユーザーから見て、どの領域を外部ツールに外出しできるとありがたいのか、JAWS運営の皆さんの見解をお聞きしたいと思いました。

• SB C＆Sさんの発表のように広くカバーしたり一括管理できるところが魅力だと思うのでそのあたりを押して行って欲しい
• ワークロード保護などカバレッジが広いところをアピールしてほしい

SecurityHubのAWSべスプラのコントロール、皆さんいくつまで 有効化＆対応してますか？絞っている方はどういった指針で整理 されていますか？

• MEDIUM / LOWは絞っていってもいいかも
• 私(臼田)は検証環境では下記を絞っている
  • IAM.6
  • EC2.8
  • CloudTrail.5
• 他にも10項目前後をよく無効化します
• あとは新しい項目が結構追加されていくので、都度判断していく必要はあります

さいごに

いい話がいっぱいありましたね。実運用のツラミはいろいろあるのでみなさんの事例を糧に頑張っていきましょう。

そしてまたアウトプットしてください！