基本から分かる！AWSセキュリティ運用の考え方と任せ方

「属人化からの解放！継続的に回るAWSセキュリティ運用のつくり方」というイベントの登壇資料です。
解説はこちら
https://dev.classmethod.jp/articles/aws-security-operations-basics/

Transcript

1. 1 基本から分かる！ AWSセキュリティ運用の考え方と任せ方 臼田 佳祐 2026/10/30
2. こんにちは、臼田です。 2 みなさん、 AWSのセキュリティ運用してますか？(挨拶
3. 3 自己紹介 臼田佳祐(うすだけいすけ) ・クラスメソッド株式会社 / クラウド事業統括本部 シニアソリューションアーキテクト セキュリティチームリーダー 2021 APN Ambassador 2025 APN AWS Top Engineers (Security) AWS Security Hero (2023~) AWS Samurai 2025 ・CISSP ・Security-JAWS運営 ・好きなサービス: Amazon GuardDuty AWS Security Hub Amazon Detective Amazon GuardDuty AWS Security Hub Amazon Detective ブログ本数 800+ みんなのAWS (技術評論社)
4. セッション概要 「セキュリティ対策を しっかりやりたい！ でもどこからやればいいの？」 にお答えします 4
5. 5 2つの「どこからやればいいの？」 ① 何から進める？ • 「GuardDuty・Security Hub CSPMを 有効化すればいい？」 • 「Organizations／Control Towerで 統制はやる？」 • 「ガイドラインも整備したい…」 やりたいことはあるけど 優先度の付け方がわからない ② どう運用する？ • 「GuardDuty・Security Hub CSPMは 有効化済み」 • 「でもアラートがたくさん出てくる…」 • 「対処しきれず、後回し・放置ぎみ」 アラートに対処しきれない どう運用したらいいの？ まずは基礎から説明し、快適な運用までの持っていき方を説明します！
6. 6 AWSセキュリティの基礎
7. AWSセキュリティ幅が広すぎる… 何から対応していけばいいの？ そもそも今どこまでできてるの？ 7
8. こんな指標があるといいよね 8
9. 足りないところがよく分かる 9 すぐ強化する ポイント
10. AWSセキュリティ成熟度モデルとは AWSから提供されている (AWS Security Maturity Model) 10のセキュリティカテゴリと 4段階のフェーズに区切って セキュリティ対策をマッピン グしたフレームワーク 現在はv2で日本語対応 https://maturitymodel.security. aws.dev/en/model/ 10
11. 11 CAF9つ+1のセキュリティカテゴリ セキュリティ ガバナンス インフラ保護 セキュリティ 保証 アイデンティティ とアクセス管理 データ保護 アプリケーション セキュリティ 脅威検出 インシデント対応 脆弱性管理 New! レジリエンス AWS クラウド導入フレームワーク(CAF)セキュリティ: https://docs.aws.amazon.com/ja_jp/whitepapers/latest/overview-awscloud-adoption-framework/security-perspective.html
12. 12 4段階のフェーズ Phase1: クイック ウィン Phase2: 基礎 Phase3: 効率化 Phase4: 最適化 Phase1: クイックウィンは文字通りすぐに実施できる 設定やサービスの有効化がメイン まずはこれをすぐ完了させましょう Phase2: 基礎のレベルまでできていれば 一通り最低限はできているとしてOK(臼田の感覚)
13. AWSセキュリティ成熟度モデルのいいところ • マトリクス表で俯瞰して確認しやすい • AWSに最適化されている • Phase1はクラウドらしくすぐできる効果の高いもの • 幅広いセキュリティのカテゴリを扱っている • セキュリティガバナンス・IAM・アプリケーションも • 4段階と現実的に使いやすい • アセスメント用のExcelなどが公開されている 13
14. 14 具体的な項目(推奨事項) 取り組むべき推奨事項は例えばこんなものがある アイデンティティと アクセス管理 Phase1: 多要素認証 セキュリティガバナンス Phase 2: Cloud Securityの トレーニングプラン 脆弱性管理 Phase 3: アプリケーションの 脆弱性管理 データ保護 Phase1: Amazon S3の パブリックアクセスの 禁止 アプリケーション セキュリティ Phase 2: コードに シークレットを 埋め込まない インシデント対応 Phase 4: プレイブックの 自動化
15. AWSセキュリティ成熟度モデルとの付き合い方 15 • AWSセキュリティ成熟度モデルはあくまで指標 • 組織単位の作りだがプロジェクト単位でも使える • Phase3,4は必ずしも満たす必要はない • 「一般的な目指すべき理想の状態の1つ」と考える • 各推奨事項を詳細まで理解しようとするとある程度 AWSセキュリティの専門性が必要 • • 社内にいるAWS Certified Security - Specialty有資格者 などが支援するといい 有資格者がいなければ取得する(重要)
16. 16 Phase1,2の内容と 強化ポイント
17. 17 Phase1の内容(一部) • GuardDutyによる脅威検知 • Security Hub CSPMによるチ • ェック • Amazon Inspectorの有効化 • S3のブロックパブリックアクセ ス • • rootアカウントを利用しない • 多要素認証 • IAM Access Analyzerによる • 権限管理 • セキュリティ連絡先の割り当て • Trusted Advisorの項目を修正 する 課金アラームの設定 セキュリティグループの制限 WAFの導入
18. IAMベストプラクティス抜粋要約 18 • 必ずMFA(多要素認証)を設定する • アクセスキーを極力利用しない • IAM Roleを活用し一時的な認証情報を使用する • IAMリソースを定期的に棚卸しする • IAM Access Analyzerで不要な公開を検出する • 最小権限の原則を意識する まずはMFAの設定とIAM Access Analyzerの有効化とチェッ クはすぐにできるのでやろう！ https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/best-practices.html
19. ガバナンス機能 展開する機能は以下の内容 • AWS CloudTrail • AWS Config • Amazon GuardDuty • AWS Security Hub CSPM • IAM Access Analyzer 19
20. IAM Access Analyzer IAM Access Analyzerは 外部公開しているリソース を検出できる機能 IAM以外の公開設定や外部 共有設定も検出できる 検出されたすべての項目の 「OK/NG」を判断してい けば良い 20
21. Amazon GuardDuty Amazon GuardDutyはポ チッと有効化するだけで AWS上の様々な脅威を検出 できるサービス 攻撃者は普段使っていない リージョンを悪用するため すべてのリージョンで有効 化する 21
22. 合わせて読みたい Amazon GuardDutyを どう使っていくか解説し た記事 初動対応や抑制方法まで 一連の運用を学べます https://dev.classmethod.jp/artic les/aws-security-operationwith-guardduty-2021/ 22
23. AWS Security Hub CSPM AWS Security Hub CSPMはAWS Configを利 用してAWS上の各種設定 がセキュアであるかチェッ クするサービス 「AWS基礎セキュリティ のベストプラクティス」を 設定して100%セキュリテ ィを維持しましょう 23
24. 合わせて読みたい AWS Security Hub CSPMの運用についてまと まっている 検出した設定ミスや危険な 設定をどう是正していくか 解説してあります https://dev.classmethod.jp/article s/aws-security-operation-withsecurityhub-2021/ 24
25. Phase2の内容(一部) • Cloud Security のトレーニングプラン • セキュリティおよび規制要件を特定する • ユーザーリポジトリの一元管理 • 組織ポリシーとしてのSCP • VPC内の Public /Private ネットワーク分離 • AWS Control Tower によるマルチアカウント管理 • データバックアップ • 開発時にセキュリティチームも参画する • インシデント対応手順を作成し、テストする 25
26. 統制の話 26 AWSセキュリティ成熟度モデルのPhase2: 基礎には組 織における統制の項目がある • AWS Control Tower によるマルチアカウント管理 • ユーザーリポジトリの一元管理 • セキュリティおよび規制要件を特定する 基礎の段階から、つまりAWSを利用しているすべての 組織はこれを実施するべき
27. 統制の話 27 AWS環境の統制を意識する場合 • AWSアカウントが複数ある • プロダクトが複数ある • 開発チームが複数ある 規模が大きくなくてもマルチアカウントの管理と統制を 最初からやる方が良い 全体を同じ仕組みで最適化できるし、あとからまとめよ うとすると労力が乗算で増える
28. ガバナンス機能 AWS Organizations やAWS Control Towerを利用するか、 これらが利用できなく ても CloudFormation StackSetsなどを駆使 する 28
29. Cloud Security のトレーニングプラン AWS認定試験やトレーニングを活用する 合わせて内部の役割でどこまで必要か定義する 29
30. アセスメント用Excel入手方法 クリックして ダウンロード https://maturitymodel.security.aws.dev/ja/assessment-tools/ 30
31. アセスメントツールの使い方 コメントは できてない部分の 状況を記述して 改善時にわかる ようにする 31
32. アセスメントのやり方 32 • 最初にどのようなスコープを対象にして評価するか を定義する • • 組織全体 or プロジェクトどちらか 対象のAWSアカウントはどれか • Phase順に並んでいるので上から順に進めて、 「Phase 2: 基礎」まで一通り入力できればそこで 止めても問題ない • だいたいここまでで問題があれば、それに対応していく ことを優先する
33. アセスメント結果の確認 入力するとリザルトシートでこんな感じに見れる このままでもいいけどアレンジすると分かりやすい 33
34. アセスメントが終わったらどうする 34 • 分かりやすいグラフが出力できて、どこが強くどこ が弱いか、セキュリティ対策の現在地を確認できた • 基本は弱い部分をまず補うところから • Phase 2までは一通り上げることを推奨 • その後は自由 • • • • Phase 3や4を目指してもいい 組織やプロジェクトの特性を考え伸ばしたいところに取 り組む考えもある 別プロジェクトに横展開したり、全体の仕組整備もあり 一回取り組めば全体感を理解し、色々改善に取り組める
35. 35 AWSセキュリティの ステップアップ方法
36. 36 Phase1で最低限の対策できたら 環境を整備していこう
37. 37 少人数で回すなら「仕組み」で守る 人が頑張る運用 仕組みで守る運用 • 設定のたびに担当者が 確認する • 質問に毎回、個別に答 える • 担当者が変わると止ま る • 危ない設定は、そもそ もできない • ルールを見れば判断で きる • 誰が何をするか決まっ ている → 人数と時間がボトルネックになる → 人数が少なくても回る 「セキュリティ担当が全部見る」から 「全員が守れる状態を作る」へ
38. 38 仕組みづくりは3つの柱で ガードレール ガイドライン 役割分担 止める 揃える 任せる 危ない操作をできなくする 全員が同じ基準で判断できる 誰が何をするか決める 設計: マルチアカウント設計 設計: ガバナンス設計 設計: 運用・プロセス設計 成熟度モデル Phase 2 • • 成熟度モデル Phase 2 2.3.1 組織のアクセス許可ガ ードレール 2.6.4 マルチアカウント管理 • • • 2.1.1 コンプライアンスと規 制要件の特定 2.1.2 セキュリティ研修計画 2.8.1 セキュリティチームの 関与 成熟度モデル Phase 2 • 2.9.1 インシデント対応プレ イブック Phase 2「基礎」の多くは、実はこの仕組みづくり
39. 39 ガードレールで「起きない」ようにする • 何でも禁止するゲートだと、ビジネス の速さが落ちる • 危ないところだけガードレールを立て て、その中は自由に使ってもらう • クラウドの事故の多くは設定ミス → ミスできない状態にする SCP RCP 宣言型ポリシー 操作を止める リソースを守る 設定を固定する • 組織外からのアクセスを 一括で制限 • AMI・EBSスナップショ ットの公開をブロック • IMDSv2 を既定にする • 使わないリージョンを使 用禁止 • CloudTrail・ GuardDutyの停止不可 AWSセキュリティ成熟度モデル 2.3.1 組織のアクセス許可ガードレール（SCP / RCP / 宣言型ポリシー）
40. マルチアカウント管理でガードレールを整備する Organizations Control Tower 管理機能 最小限 ID・ログ集約、ガ ードレール等 自由度 自由 ある程度決まった 構成 おまかせ度 全部自前 ベストプラクティ スに沿って構築 アカウントが複数あるなら、規模が小さくても最 初からマルチアカウント管理が適切 マルチアカウント管理でガードレール・ログ集約・GuardDuty / Security Hub CSPM の一括管理がまとめて効く → 後の運用（集約した検知の確認・対応）の前提になる 40
41. ガイドラインで「迷わない」ようにする ガイドラインに書くこと 41 教育 利用者は IAM の基本、管理者は Security Specialty 相当の知識を（2.1.2） • アカウントの払い出しルール • 適用されているガードレール ナレッジ共有 • 必須の設定（ベースライン） • 禁止事項 一度決めたことを、毎回説明しなくていい • 例外の申請方法 • リファレンスアーキテクチャ ビジネスに集中 判断や確認の時間が減り、本業に使える 全体を見るチーム（CCoE）が作って育てる。ひな形は公開されている資料も活用できる AWSセキュリティ成熟度モデル 2.1.1 コンプライアンスと規制要件の特定 / 2.1.2 セキュリティ研修計画 / 2.8.1 セキュリティチームの関与
42. 42 役割分担で「放置しない」ようにする アラートが放置される一番の原因は「誰が見るか決まっていない」こと 全体管理 事業部門 外部パートナー CCoE・セキュリティ担当 プロダクトチーム 運用・監視の委託先 ガードレールの維持 • ◦ ◦ 検出の一次対応（確認） ◦ ◦ • 是正（設定の修正） ◦ • ◦ 例外の承認 • インシデント対応 • • ◦ • 主担当 ◦ 協力（例。組織の体制に合わせて決める） 外に任せる部分も、ここで決めておく AWSセキュリティ成熟度モデル 2.9.1 インシデント対応プレイブック（その先に 4.1.1 セキュリティタスクの責任分担）
43. 仕組みを整備したら運用が楽になる 43 • 仕組みがあれば対応時の意思決定にかける時間が減 り、対応品質が上がり、楽になる • 逆に言うと仕組みを整備していかないと判断に時間 がかかって、対応にむらが出て、しんどい • 仕組みを整備するのは大変だが積み上げていこう
44. 44 AWSセキュリティの運用
45. 45 AWSセキュリティ運用の全体像 一口にAWSセキュリティ運用と言っても幅が広い AWSレイヤー インフラレイヤー アプリレイヤー CSPM運用 脆弱性管理(CVE) 脆弱性診断(CWE) 例: AWS Security Hub CSPM 例: Amazon Inspector 例: AWS Security Agent 脅威検出対応 OS脅威保護 (EDR) アプリ保護 (WAF) 例: Amazon GuardDuty 例: TrendAI Vision One 例: AWS WAF 予防的統制 問題を未然に検出し 修正して防ぐ運用 発見的統制 インシデントに気づき 保護対応する運用
46. 46 AWS Security Hub CSPMの 運用の進め方
47. AWS Security Hub CSPM使い始めの時 めちゃくちゃたくさん検出されてスコアも低い… なにからやればいいの…？ 47
48. 組織で Security Hub CSPM が回らない理由 よくある状態 その背景 誰も対応しない（担当者が 決まっていない） 知識の壁 責任を持つ人がいない 直していく方針が立てられ ない 48 チェック項目が多く、AWS とセ キュリティの知識がないと判断 できない 方針の壁 対応の方針と、責任・役割分担が 決まっていない → チェック項目を整理して、方針と役割を決めれば回り 始める
49. AWS Security Hub CSPM運用のコツは？ AWS Security Hub CSPMの チェック項目を カテゴライズしよう 49
50. どうしてカテゴライズするの？ 50 AWS Security Hub CSPMのコントロール数は300以 上と非常に多いが、カテゴライズしてあげると10種類 程度と対応方針を検討するのに支障ないレベルになる 組織としてカテゴリごと対応方針を決めれば、迷いなく AWS Security Hub CSPMの運用ができる
51. 51 具体的なカテゴライズ AWS Security Hub CSPMのチェック項目は、こんなカテ ゴリに分けられる 通信の 暗号化 アクセス 制御 保管時の 暗号化 ログ取得 可用性 バック アップ 保護 脆弱性 管理 設定 チェック コスト 最適化 認証情報 管理 • このカテゴライズは臼田が独自に作ったもの • 他のカテゴリも検討できるが、だいたい似たような分類になるはず なので真似していい
52. カテゴリにコントロールを合わせてみる 通信の暗号化 CloudFront.3 CloudFront のディストリビューシ ョンでは、トランジット時に暗号化 が必要です S3.5 S3 汎用バケットでは、SSL を使用 するリクエストが必要です 52 可用性 AutoScaling.2 EC2 Auto Scaling グループは複数 のアベイラビリティーゾーンにまた がって配置される必要があります RDS.5 RDS DB インスタンスは複数のアベ イラビリティーゾーンで設定する必 要があります → 300 以上のコントロールも、カテゴリだとわかりやすい
53. カテゴリの分布 アクセス 制御系が 多い ログ取得 もそこそ こある 53
54. 実はAWSもカテゴライズしている AWS Security Hub CSPM のユーザーガイドの各コン トロールのリファレンスガ イドにカテゴリがある NISTのCSF(サイバーセキ ュリティフレームワーク)に も近いような大項目のカテ ゴライズと、階層構造で詳 細に分類している でもたくさんの種類がある ため方針を大枠で決めてい くための使い方はできない 54
55. カテゴライズしたら対応方針を決める • カテゴリごとに対応方針を決めていく • 大事なのは、環境の種類を定義してそれに合わせること • 例えば大きく「本番環境」と「それ以外」の2種類に分けられる 本番環境 • 外部に公開する本番 • 守るべきデータがある • システム重要度が高い 本番以外の環境 • 内部向けの開発・検証 • 本番データはない • 止まってもビジネス影響が 少ない 55
56. 56 環境ごとの大まかな対応方針 可用性・ログ取得・バックアップは本番環境のみ必須 本番以外の環境では任意の項目と位置づける 本番環境の必須 通信の 暗号化 本番以外の環境の必須 保管時の 暗号化 認証情報 管理 通信の 暗号化 保管時の 暗号化 認証情報 管理 アクセス 制御 保護 脆弱性 管理 アクセス 制御 保護 脆弱性 管理 ログ取得 可用性 バック アップ ログ取得・可用性・バックアップは 任意
57. 対応方針例 - 通信の暗号化 通信の暗号化 57 基本方針 • TLS利用のチェック項目で、すべての環境で基本必須 • VPCの内部だけの通信でも簡単にTLS利用できることがほとんどのため必須 コントロール例 CloudFront.3 必須 CloudFront のディストリビューションでは、トランジット時に暗号 化が必要です S3.5 必須 S3 汎用バケットでは、SSL を使用するリクエストが必要です APIGateway.2 任意 API Gateway REST API ステージでは、バックエンド認証に SSL 証 明書を使用するように設定する必要があります → クライアント証明書が必要となり、設定のためのコストが高いため任意で よい
58. 対応方針例 - ログ取得 ログ取得 58 基本方針 • 本番環境では必須。開発環境などでも活用したいものも多いが任意とする • 他のログで代替できるものは任意とする コントロール例 CloudTrail.1 本番必須 CloudTrail を有効にして、少なくとも 1 つのマルチリージョンの追 跡で、読み取りと書き込みの管理イベントを含めた設定をする必要が あります ELB.5 本番必須 Application/Classic Load Balancer のロギングを有効にする必要が あります CloudTrail.5 任意 CloudTrail のトレイルは、Amazon CloudWatch Logs と統合される べきです → やらなくてよい。S3 に保存できてさえいればコスパよく使える
59. 対応方針例 - アクセス制御 アクセス制御 59 基本方針 • すべての環境で必須 • パブリックからのアクセスの制限や、認証が必要な操作に関する制限 コントロール例 EC2.19 必須 セキュリティグループは、リスクの高いポートへの無制限のアクセス を許可してはならない RDS.1 必須 RDS スナップショットはプライベートにする必要があります EC2.21 任意 ネットワーク ACL は 0.0.0.0/0 からポート 22 または 3389 へのイ ンバウンド許可ルールを追加してはいけない → 煩雑な運用になるため任意
60. 合わせて読みたい 60 カテゴリ全体と一通り のコントロールの解説 あります https://dev.classm ethod.jp/articles/a ws-security-hubcontrol-categorize/
61. 61 Amazon GuardDutyの 運用の進め方
62. 初期の有効化で検出が沢山出る場合 62 最初から沢山検出が出るのは大きく2パターン • 設定が緩く定常的に攻撃を受けている • 例: Security GroupのSSHが開放されていれ常時スキャ ンされている • DX/VPNなどでアウトバウンド通信の経路が異なる • 例: EC2のIAM Roleによる操作がオンプレミスから Internetを経由し実行される
63. GuardDuty運用の心構え 63 GuardDutyのユー ザーガイドに検出 結果毎の対応方法 がわかりやすく記 載されているので 検出されたらすぐ これを見る https://docs.aws.amazon.co m/ja_jp/guardduty/latest/u g/guardduty_finding-typesactive.html
64. 初動対応計画を立てる • 検出結果毎ざっくり3種類準備しておく • IAMタイプ • 認証情報を無効化する • EC2タイプ • • EC2を隔離、保全、調査する 調査は得意な会社に依頼できる準備でもいい • S3タイプ • アクセス権限を絞る 64
65. IAMタイプの初動対応例 • IAM Userならアクセスキーを無効化・削除 • IAM Roleならセッションの無効化をポチ • CloudTrailで何をされたか調査 65
66. EC2タイプの初動対応例 66 Security Groupを 変更して隔離 (in/out無し) AMIバックアップ取 得 サーバーやストレー ジ調査(できれば、 プロに任せたほうが いい)
67. S3タイプの初動対応例 パブリックアクセスブロックする 67
68. 合わせて読みたい(再掲) Amazon GuardDutyを どう使っていくか解説し た記事 初動対応や抑制方法まで 一連の運用を学べます https://dev.classmethod.jp/artic les/aws-security-operationwith-guardduty-2021/ 68
69. 更に脆弱性管理や診断の運用も 69 • Amazon InspectorではEC2/ECS/Lambdaの脆 弱性管理が可能 • 定常的にアップデートして最新に保とう • AWS Security AgentはアプリへのDASTやコード へのSASTなどが可能 • 高速化する開発のライフサイクルに合わせて診断も実施 しよう
70. 70 まとめ
71. AWSセキュリティ運用の考え方と任せ方 71 • 自社AWS環境の現在地を把握し、AWSセキュリテ ィ成熟度モデルに従って優先度を付けてステップア ップしていこう • ルールや仕組みを整備して効率よくセキュリティ対 策していこう • 便利なAWSのセキュリティサービスの使い方を理解 して運用を任せていこう
72. 72 それでも大変だと感じるところは 頼ってください