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

by cm-usuda-keisuke

Embed

Start on current slide

Slide 1

Slide 1 text

1 基本から分かる！ AWSセキュリティ運用の考え方と任せ方臼田佳祐 2026/10/30

Slide 2

Slide 2 text

こんにちは、臼田です。 2 みなさん、 AWSのセキュリティ運用してますか？(挨拶

Slide 3

Slide 3 text

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 (技術評論社)

Slide 4

Slide 4 text

セッション概要「セキュリティ対策をしっかりやりたい！でもどこからやればいいの？」にお答えします 4

Slide 5

Slide 5 text

5 2つの「どこからやればいいの？」 ① 何から進める？ • 「GuardDuty・Security Hub CSPMを有効化すればいい？」 • 「Organizations／Control Towerで統制はやる？」 • 「ガイドラインも整備したい…」やりたいことはあるけど優先度の付け方がわからない ② どう運用する？ • 「GuardDuty・Security Hub CSPMは有効化済み」 • 「でもアラートがたくさん出てくる…」 • 「対処しきれず、後回し・放置ぎみ」アラートに対処しきれないどう運用したらいいの？まずは基礎から説明し、快適な運用までの持っていき方を説明します！

Slide 6

Slide 6 text

6 AWSセキュリティの基礎

Slide 7

Slide 7 text

AWSセキュリティ幅が広すぎる… 何から対応していけばいいの？そもそも今どこまでできてるの？ 7

Slide 8

Slide 8 text

こんな指標があるといいよね 8

Slide 9

Slide 9 text

足りないところがよく分かる 9 すぐ強化するポイント

Slide 10

Slide 10 text

AWSセキュリティ成熟度モデルとは AWSから提供されている (AWS Security Maturity Model) 10のセキュリティカテゴリと 4段階のフェーズに区切ってセキュリティ対策をマッピングしたフレームワーク現在はv2で日本語対応 https://maturitymodel.security. aws.dev/en/model/ 10

Slide 11

Slide 11 text

11 CAF9つ+1のセキュリティカテゴリセキュリティガバナンスインフラ保護セキュリティ保証アイデンティティとアクセス管理データ保護アプリケーションセキュリティ脅威検出インシデント対応脆弱性管理 New! レジリエンス AWS クラウド導入フレームワーク(CAF)セキュリティ: https://docs.aws.amazon.com/ja_jp/whitepapers/latest/overview-awscloud-adoption-framework/security-perspective.html

Slide 12

Slide 12 text

12 4段階のフェーズ Phase1: クイックウィン Phase2: 基礎 Phase3: 効率化 Phase4: 最適化 Phase1: クイックウィンは文字通りすぐに実施できる設定やサービスの有効化がメインまずはこれをすぐ完了させましょう Phase2: 基礎のレベルまでできていれば一通り最低限はできているとしてOK(臼田の感覚)

Slide 13

Slide 13 text

AWSセキュリティ成熟度モデルのいいところ • マトリクス表で俯瞰して確認しやすい • AWSに最適化されている • Phase1はクラウドらしくすぐできる効果の高いもの • 幅広いセキュリティのカテゴリを扱っている • セキュリティガバナンス・IAM・アプリケーションも • 4段階と現実的に使いやすい • アセスメント用のExcelなどが公開されている 13

Slide 14

Slide 14 text

14 具体的な項目(推奨事項) 取り組むべき推奨事項は例えばこんなものがあるアイデンティティとアクセス管理 Phase1: 多要素認証セキュリティガバナンス Phase 2: Cloud Securityのトレーニングプラン脆弱性管理 Phase 3: アプリケーションの脆弱性管理データ保護 Phase1: Amazon S3のパブリックアクセスの禁止アプリケーションセキュリティ Phase 2: コードにシークレットを埋め込まないインシデント対応 Phase 4: プレイブックの自動化

Slide 15

Slide 15 text

AWSセキュリティ成熟度モデルとの付き合い方 15 • AWSセキュリティ成熟度モデルはあくまで指標 • 組織単位の作りだがプロジェクト単位でも使える • Phase3,4は必ずしも満たす必要はない • 「一般的な目指すべき理想の状態の1つ」と考える • 各推奨事項を詳細まで理解しようとするとある程度 AWSセキュリティの専門性が必要 • • 社内にいるAWS Certified Security - Specialty有資格者などが支援するといい有資格者がいなければ取得する(重要)

Slide 16

Slide 16 text

16 Phase1,2の内容と強化ポイント

Slide 17

Slide 17 text

17 Phase1の内容(一部) • GuardDutyによる脅威検知 • Security Hub CSPMによるチ • ェック • Amazon Inspectorの有効化 • S3のブロックパブリックアクセス • • rootアカウントを利用しない • 多要素認証 • IAM Access Analyzerによる • 権限管理 • セキュリティ連絡先の割り当て • Trusted Advisorの項目を修正する課金アラームの設定セキュリティグループの制限 WAFの導入

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

ガバナンス機能展開する機能は以下の内容 • AWS CloudTrail • AWS Config • Amazon GuardDuty • AWS Security Hub CSPM • IAM Access Analyzer 19

Slide 20

Slide 20 text

IAM Access Analyzer IAM Access Analyzerは外部公開しているリソースを検出できる機能 IAM以外の公開設定や外部共有設定も検出できる検出されたすべての項目の「OK/NG」を判断していけば良い 20

Slide 21

Slide 21 text

Amazon GuardDuty Amazon GuardDutyはポチッと有効化するだけで AWS上の様々な脅威を検出できるサービス攻撃者は普段使っていないリージョンを悪用するためすべてのリージョンで有効化する 21

Slide 22

Slide 22 text

合わせて読みたい Amazon GuardDutyをどう使っていくか解説した記事初動対応や抑制方法まで一連の運用を学べます https://dev.classmethod.jp/artic les/aws-security-operationwith-guardduty-2021/ 22

Slide 23

Slide 23 text

AWS Security Hub CSPM AWS Security Hub CSPMはAWS Configを利用してAWS上の各種設定がセキュアであるかチェックするサービス「AWS基礎セキュリティのベストプラクティス」を設定して100%セキュリティを維持しましょう 23

Slide 24

Slide 24 text

合わせて読みたい AWS Security Hub CSPMの運用についてまとまっている検出した設定ミスや危険な設定をどう是正していくか解説してあります https://dev.classmethod.jp/article s/aws-security-operation-withsecurityhub-2021/ 24

Slide 25

Slide 25 text

Phase2の内容(一部) • Cloud Security のトレーニングプラン • セキュリティおよび規制要件を特定する • ユーザーリポジトリの一元管理 • 組織ポリシーとしてのSCP • VPC内の Public /Private ネットワーク分離 • AWS Control Tower によるマルチアカウント管理 • データバックアップ • 開発時にセキュリティチームも参画する • インシデント対応手順を作成し、テストする 25

Slide 26

Slide 26 text

統制の話 26 AWSセキュリティ成熟度モデルのPhase2: 基礎には組織における統制の項目がある • AWS Control Tower によるマルチアカウント管理 • ユーザーリポジトリの一元管理 • セキュリティおよび規制要件を特定する基礎の段階から、つまりAWSを利用しているすべての組織はこれを実施するべき

Slide 27

Slide 27 text

統制の話 27 AWS環境の統制を意識する場合 • AWSアカウントが複数ある • プロダクトが複数ある • 開発チームが複数ある規模が大きくなくてもマルチアカウントの管理と統制を最初からやる方が良い全体を同じ仕組みで最適化できるし、あとからまとめようとすると労力が乗算で増える

Slide 28

Slide 28 text

ガバナンス機能 AWS Organizations やAWS Control Towerを利用するか、これらが利用できなくても CloudFormation StackSetsなどを駆使する 28

Slide 29

Slide 29 text

Cloud Security のトレーニングプラン AWS認定試験やトレーニングを活用する合わせて内部の役割でどこまで必要か定義する 29

Slide 30

Slide 30 text

アセスメント用Excel入手方法クリックしてダウンロード https://maturitymodel.security.aws.dev/ja/assessment-tools/ 30

Slide 31

Slide 31 text

アセスメントツールの使い方コメントはできてない部分の状況を記述して改善時にわかるようにする 31

Slide 32

Slide 32 text

アセスメントのやり方 32 • 最初にどのようなスコープを対象にして評価するかを定義する • • 組織全体 or プロジェクトどちらか対象のAWSアカウントはどれか • Phase順に並んでいるので上から順に進めて、「Phase 2: 基礎」まで一通り入力できればそこで止めても問題ない • だいたいここまでで問題があれば、それに対応していくことを優先する

Slide 33

Slide 33 text

アセスメント結果の確認入力するとリザルトシートでこんな感じに見れるこのままでもいいけどアレンジすると分かりやすい 33

Slide 34

Slide 34 text

アセスメントが終わったらどうする 34 • 分かりやすいグラフが出力できて、どこが強くどこが弱いか、セキュリティ対策の現在地を確認できた • 基本は弱い部分をまず補うところから • Phase 2までは一通り上げることを推奨 • その後は自由 • • • • Phase 3や4を目指してもいい組織やプロジェクトの特性を考え伸ばしたいところに取り組む考えもある別プロジェクトに横展開したり、全体の仕組整備もあり一回取り組めば全体感を理解し、色々改善に取り組める

Slide 35

Slide 35 text

35 AWSセキュリティのステップアップ方法

Slide 36

Slide 36 text

36 Phase1で最低限の対策できたら環境を整備していこう

Slide 37

Slide 37 text

37 少人数で回すなら「仕組み」で守る人が頑張る運用仕組みで守る運用 • 設定のたびに担当者が確認する • 質問に毎回、個別に答える • 担当者が変わると止まる • 危ない設定は、そもそもできない • ルールを見れば判断できる • 誰が何をするか決まっている → 人数と時間がボトルネックになる → 人数が少なくても回る「セキュリティ担当が全部見る」から「全員が守れる状態を作る」へ

Slide 38

Slide 38 text

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「基礎」の多くは、実はこの仕組みづくり

Slide 39

Slide 39 text

39 ガードレールで「起きない」ようにする • 何でも禁止するゲートだと、ビジネスの速さが落ちる • 危ないところだけガードレールを立てて、その中は自由に使ってもらう • クラウドの事故の多くは設定ミス → ミスできない状態にする SCP RCP 宣言型ポリシー操作を止めるリソースを守る設定を固定する • 組織外からのアクセスを一括で制限 • AMI・EBSスナップショットの公開をブロック • IMDSv2 を既定にする • 使わないリージョンを使用禁止 • CloudTrail・ GuardDutyの停止不可 AWSセキュリティ成熟度モデル 2.3.1 組織のアクセス許可ガードレール（SCP / RCP / 宣言型ポリシー）

Slide 40

Slide 40 text

マルチアカウント管理でガードレールを整備する Organizations Control Tower 管理機能最小限 ID・ログ集約、ガードレール等自由度自由ある程度決まった構成おまかせ度全部自前ベストプラクティスに沿って構築アカウントが複数あるなら、規模が小さくても最初からマルチアカウント管理が適切マルチアカウント管理でガードレール・ログ集約・GuardDuty / Security Hub CSPM の一括管理がまとめて効く → 後の運用（集約した検知の確認・対応）の前提になる 40

Slide 41

Slide 41 text

ガイドラインで「迷わない」ようにするガイドラインに書くこと 41 教育利用者は IAM の基本、管理者は Security Specialty 相当の知識を（2.1.2） • アカウントの払い出しルール • 適用されているガードレールナレッジ共有 • 必須の設定（ベースライン） • 禁止事項一度決めたことを、毎回説明しなくていい • 例外の申請方法 • リファレンスアーキテクチャビジネスに集中判断や確認の時間が減り、本業に使える全体を見るチーム（CCoE）が作って育てる。ひな形は公開されている資料も活用できる AWSセキュリティ成熟度モデル 2.1.1 コンプライアンスと規制要件の特定 / 2.1.2 セキュリティ研修計画 / 2.8.1 セキュリティチームの関与

Slide 42

Slide 42 text

42 役割分担で「放置しない」ようにするアラートが放置される一番の原因は「誰が見るか決まっていない」こと全体管理事業部門外部パートナー CCoE・セキュリティ担当プロダクトチーム運用・監視の委託先ガードレールの維持 ● ○ ○ 検出の一次対応（確認） ○ ○ ● 是正（設定の修正） ○ ● ○ 例外の承認 ● インシデント対応 ● ● ○ ● 主担当 ○ 協力（例。組織の体制に合わせて決める）外に任せる部分も、ここで決めておく AWSセキュリティ成熟度モデル 2.9.1 インシデント対応プレイブック（その先に 4.1.1 セキュリティタスクの責任分担）

Slide 43

Slide 43 text

仕組みを整備したら運用が楽になる 43 • 仕組みがあれば対応時の意思決定にかける時間が減り、対応品質が上がり、楽になる • 逆に言うと仕組みを整備していかないと判断に時間がかかって、対応にむらが出て、しんどい • 仕組みを整備するのは大変だが積み上げていこう

Slide 44

Slide 44 text

44 AWSセキュリティの運用

Slide 45

Slide 45 text

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 予防的統制問題を未然に検出し修正して防ぐ運用発見的統制インシデントに気づき保護対応する運用

Slide 46

Slide 46 text

46 AWS Security Hub CSPMの運用の進め方

Slide 47

Slide 47 text

AWS Security Hub CSPM使い始めの時めちゃくちゃたくさん検出されてスコアも低い… なにからやればいいの…？ 47

Slide 48

Slide 48 text

組織で Security Hub CSPM が回らない理由よくある状態その背景誰も対応しない（担当者が決まっていない）知識の壁責任を持つ人がいない直していく方針が立てられない 48 チェック項目が多く、AWS とセキュリティの知識がないと判断できない方針の壁対応の方針と、責任・役割分担が決まっていない → チェック項目を整理して、方針と役割を決めれば回り始める

Slide 49

Slide 49 text

AWS Security Hub CSPM運用のコツは？ AWS Security Hub CSPMのチェック項目をカテゴライズしよう 49

Slide 50

Slide 50 text

どうしてカテゴライズするの？ 50 AWS Security Hub CSPMのコントロール数は300以上と非常に多いが、カテゴライズしてあげると10種類程度と対応方針を検討するのに支障ないレベルになる組織としてカテゴリごと対応方針を決めれば、迷いなく AWS Security Hub CSPMの運用ができる

Slide 51

Slide 51 text

51 具体的なカテゴライズ AWS Security Hub CSPMのチェック項目は、こんなカテゴリに分けられる通信の暗号化アクセス制御保管時の暗号化ログ取得可用性バックアップ保護脆弱性管理設定チェックコスト最適化認証情報管理 • このカテゴライズは臼田が独自に作ったもの • 他のカテゴリも検討できるが、だいたい似たような分類になるはずなので真似していい

Slide 52

Slide 52 text

カテゴリにコントロールを合わせてみる通信の暗号化 CloudFront.3 CloudFront のディストリビューションでは、トランジット時に暗号化が必要です S3.5 S3 汎用バケットでは、SSL を使用するリクエストが必要です 52 可用性 AutoScaling.2 EC2 Auto Scaling グループは複数のアベイラビリティーゾーンにまたがって配置される必要があります RDS.5 RDS DB インスタンスは複数のアベイラビリティーゾーンで設定する必要があります → 300 以上のコントロールも、カテゴリだとわかりやすい

Slide 53

Slide 53 text

カテゴリの分布アクセス制御系が多いログ取得もそこそこある 53

Slide 54

Slide 54 text

実はAWSもカテゴライズしている AWS Security Hub CSPM のユーザーガイドの各コントロールのリファレンスガイドにカテゴリがある NISTのCSF(サイバーセキュリティフレームワーク)にも近いような大項目のカテゴライズと、階層構造で詳細に分類しているでもたくさんの種類があるため方針を大枠で決めていくための使い方はできない 54

Slide 55

Slide 55 text

カテゴライズしたら対応方針を決める • カテゴリごとに対応方針を決めていく • 大事なのは、環境の種類を定義してそれに合わせること • 例えば大きく「本番環境」と「それ以外」の2種類に分けられる本番環境 • 外部に公開する本番 • 守るべきデータがある • システム重要度が高い本番以外の環境 • 内部向けの開発・検証 • 本番データはない • 止まってもビジネス影響が少ない 55

Slide 56

Slide 56 text

56 環境ごとの大まかな対応方針可用性・ログ取得・バックアップは本番環境のみ必須本番以外の環境では任意の項目と位置づける本番環境の必須通信の暗号化本番以外の環境の必須保管時の暗号化認証情報管理通信の暗号化保管時の暗号化認証情報管理アクセス制御保護脆弱性管理アクセス制御保護脆弱性管理ログ取得可用性バックアップログ取得・可用性・バックアップは任意

Slide 57

Slide 57 text

対応方針例 - 通信の暗号化通信の暗号化 57 基本方針 • TLS利用のチェック項目で、すべての環境で基本必須 • VPCの内部だけの通信でも簡単にTLS利用できることがほとんどのため必須コントロール例 CloudFront.3 必須 CloudFront のディストリビューションでは、トランジット時に暗号化が必要です S3.5 必須 S3 汎用バケットでは、SSL を使用するリクエストが必要です APIGateway.2 任意 API Gateway REST API ステージでは、バックエンド認証に SSL 証明書を使用するように設定する必要があります → クライアント証明書が必要となり、設定のためのコストが高いため任意でよい

Slide 58

Slide 58 text

対応方針例 - ログ取得ログ取得 58 基本方針 • 本番環境では必須。開発環境などでも活用したいものも多いが任意とする • 他のログで代替できるものは任意とするコントロール例 CloudTrail.1 本番必須 CloudTrail を有効にして、少なくとも 1 つのマルチリージョンの追跡で、読み取りと書き込みの管理イベントを含めた設定をする必要があります ELB.5 本番必須 Application/Classic Load Balancer のロギングを有効にする必要があります CloudTrail.5 任意 CloudTrail のトレイルは、Amazon CloudWatch Logs と統合されるべきです → やらなくてよい。S3 に保存できてさえいればコスパよく使える

Slide 59

Slide 59 text

対応方針例 - アクセス制御アクセス制御 59 基本方針 • すべての環境で必須 • パブリックからのアクセスの制限や、認証が必要な操作に関する制限コントロール例 EC2.19 必須セキュリティグループは、リスクの高いポートへの無制限のアクセスを許可してはならない RDS.1 必須 RDS スナップショットはプライベートにする必要があります EC2.21 任意ネットワーク ACL は 0.0.0.0/0 からポート 22 または 3389 へのインバウンド許可ルールを追加してはいけない → 煩雑な運用になるため任意

Slide 60

Slide 60 text

合わせて読みたい 60 カテゴリ全体と一通りのコントロールの解説あります https://dev.classm ethod.jp/articles/a ws-security-hubcontrol-categorize/

Slide 61

Slide 61 text

61 Amazon GuardDutyの運用の進め方

Slide 62

Slide 62 text

初期の有効化で検出が沢山出る場合 62 最初から沢山検出が出るのは大きく2パターン • 設定が緩く定常的に攻撃を受けている • 例: Security GroupのSSHが開放されていれ常時スキャンされている • DX/VPNなどでアウトバウンド通信の経路が異なる • 例: EC2のIAM Roleによる操作がオンプレミスから Internetを経由し実行される

Slide 63

Slide 63 text

GuardDuty運用の心構え 63 GuardDutyのユーザーガイドに検出結果毎の対応方法がわかりやすく記載されているので検出されたらすぐこれを見る https://docs.aws.amazon.co m/ja_jp/guardduty/latest/u g/guardduty_finding-typesactive.html

Slide 64

Slide 64 text

初動対応計画を立てる • 検出結果毎ざっくり3種類準備しておく • IAMタイプ • 認証情報を無効化する • EC2タイプ • • EC2を隔離、保全、調査する調査は得意な会社に依頼できる準備でもいい • S3タイプ • アクセス権限を絞る 64

Slide 65

Slide 65 text

IAMタイプの初動対応例 • IAM Userならアクセスキーを無効化・削除 • IAM Roleならセッションの無効化をポチ • CloudTrailで何をされたか調査 65

Slide 66

Slide 66 text

EC2タイプの初動対応例 66 Security Groupを変更して隔離 (in/out無し) AMIバックアップ取得サーバーやストレージ調査(できれば、プロに任せたほうがいい)

Slide 67

Slide 67 text

S3タイプの初動対応例パブリックアクセスブロックする 67

Slide 68

Slide 68 text

合わせて読みたい(再掲) Amazon GuardDutyをどう使っていくか解説した記事初動対応や抑制方法まで一連の運用を学べます https://dev.classmethod.jp/artic les/aws-security-operationwith-guardduty-2021/ 68

Slide 69

Slide 69 text

更に脆弱性管理や診断の運用も 69 • Amazon InspectorではEC2/ECS/Lambdaの脆弱性管理が可能 • 定常的にアップデートして最新に保とう • AWS Security AgentはアプリへのDASTやコードへのSASTなどが可能 • 高速化する開発のライフサイクルに合わせて診断も実施しよう

Slide 70

Slide 70 text

70 まとめ

Slide 71

Slide 71 text

AWSセキュリティ運用の考え方と任せ方 71 • 自社AWS環境の現在地を把握し、AWSセキュリティ成熟度モデルに従って優先度を付けてステップアップしていこう • ルールや仕組みを整備して効率よくセキュリティ対策していこう • 便利なAWSのセキュリティサービスの使い方を理解して運用を任せていこう