株式会社Relic 保 龍児（エイミ/amixedcolor） SRE×AIOpsを始めよう！ GuardDutyによるお手軽脅威検出

2 保 龍児（エイミ/amixedcolor） 業務内容 : プラットフォームエンジニアリング、 エンジニアイネーブルメントなど 好きなトピック : アジャイル、スクラム、新規事業開発 よくいるコミュニティ : アジャイルコミュニティ、 AWSコミュニティ（AWS歴半年超えた ） 自己紹介 @amixedcolor

3 脅威検出サービスGuardDutyを 導入し運用することが自分でできる 本日のゴール

4 脅威検出サービスGuardDutyを 導入し運用することが自分でできる 本日のゴール

5 本題に入る前に

6 • 本日様々な発表がありました • AIOpsとLLMOpsってどう違うの？？ ついでにLLMOpsに入門しよ う！ • SREが投資するAIOps ~ペアーズにおけるLLM for Developerへの取り 組み~ • LLMによるLLMアプリ評価パイプライン構築 • Petite SRE：GenAI Eraにおけるインフラのあり方観察 • もちろんこの後も！（当日時点でタイトル未定だったのでタイトル掲載できませんでした ） • 「SREでもAI活用がしたい!」と改めて思ったのでは？ 今日を振り返る

7 どこから始めればいいんだろう…？ 「SREでもAI活用がしたい!」けど・・・

8 • Amazon DevOps Guru • Amazon GuardDuty • Amazon Forecast • Amazon Macie SRE×AIOpsといっても様々なAWSサービスがある

9 1. Amazon DevOps Guru • SREの基本理念である「信頼性」に直接的に貢献 • 運用効率の即時的な改善が見込め、設定も容易 2. Amazon GuardDuty • DevOps Guruでは補えないリアルタイムの脅威検出などができる • セキュリティインシデントによる可用性低下の防止につながる 3. Amazon Forecast • 需要予測の精度が重要な場合に検討（ただし専門知識が必要） 4. Amazon Macie • S3に保存するデータの規制要件がある場合に導入を検討 どこから始めれば良いのか

10 まずはDevOps Guru

11 次にGuardDuty

12 • 弊社で活用した実績がある • 運用しやすい体験もあり、便利な印象が強い • DevOps Guruではカバーしきれないセキュリティ領域をカバー • ただし、全ての領域をGuardDutyでカバーできるわけではなく、これ ら2つは相互補完的にカバーする • DevOps Guruとの併用を推奨 本日紹介するのはGuardDuty

13 ここから本題！

14 脅威検出サービスGuardDutyを 導入し運用することが自分でできる 本日のゴール

15 フルマネージド型脅威検出サービス • 人による作業やサードパーティーのツールを必要とすることなく脅威 検出ができる • 初期導入をするだけ 多数の検出カテゴリに基づき、重大度と共に検出してくれる • 主な検出カテゴリ • 偵察・インスタンスの侵害・アカウントの侵害・バケットの侵害・マルウェア・ コンテナの侵害 • 重大度 • 低：リソースが侵害される前にブロックされた • 中：疑わしいアクティビティ（通常観察される動作から逸脱したものなど） • 高：リソースが侵害され、不正な目的で活発に使用されている GuardDutyとは

16 みているもの • 基本のもの • CloudTrail管理イベント・VPCフローログ・DNSクエリログ • 各種保護プランを有効にした場合 • CloudTrail S3 データイベント・EKS監査ログ・[EKS/ECS/EC2]ランタイムイベ ント・RDSログインアクティビティ・Lambdaネットワークアクティビティログ 判断の方法 • > GuardDuty は、AWS と業界をリードするサードパーティーの両方 のソースを使用して、機械学習、異常検知、ネットワークモニタリン グ、悪意のあるファイルの検出を組み合わせて、AWS 上のワークロー ドとデータの保護を支援します。 • https://aws.amazon.com/jp/guardduty/features/ 何をみてどうやって判断しているのか？

17 特徴 • デフォルトで必須の「基本価格」と「保護プラン価格」の2種類ある • 状況に応じて検出容量を自動で調整することで、費用対効果が高い • 30日間の無料トライアルがあり、その最中にコストが見積もられる 基本価格（詳細: https://aws.amazon.com/jp/guardduty/pricing/ ） • CloudTrail管理イベント分析 • 100万イベント/月ごとに、$4.00/100万イベント • VPCフローログとDNSクエリログの分析 • 最初の500GB/月では、$1.00/GB • 次の2,000GB/月では、$0.50/GB • 次の7,500GB/月では、$0.25/GB • 10,000/月以上は、$0.15/GB いくらかかるのか？(1/2)

18 保護プラン価格は割愛 • https://aws.amazon.com/jp/guardduty/pricing/ 肌感 • AWSリソースを作成・使用していないリージョンはほぼかからない • $0.1ぐらい • 使っているところはログの数に比例してかかる • おおよその比率 • CloudTrail利用価格の、おおよそ3分の1から半額 • ログ量が比較的多いアカウントで、利用総額のおおよそ1-2% • Organization全体で見た際には、利用総額のおおよそ0.5% • 実測値 • 弊社でそれなりに動いているサービスで、ホームリージョン$90、合計$130 いくらかかるのか(2/2)

19 脅威検出サービスGuardDutyを 導入し運用することが自分でできる 本日のゴール

20 • ケース１：単一アカウントで運用している • GuardDuty コンソールを開き、「開始方法」を選択し、「GuardDuty を有効」にし、30 日間無料トライアルを始めるだけ • →シンプルなので説明は割愛します • ケース２：Organizationを利用している • それなりにシンプルな方法もあるが、留意事項がある • →続くスライドで導入ステップを説明します • ケース３：Organizationに加え、ControlTowerも利用している • ケース２とほぼ同じステップを辿るが、少し異なる点がある • →ケース２の説明の最中に注釈して説明します 想定環境ごとの概要

21 導入する

22 1. GuardDuty管理アカウントを作成する • 「ケース３： Organizationに加え、ControlTowerも利用している」の 場合は、作成せずにAuditアカウントを流用しても良い 2. 「委任された管理者」を設定する 3. 委任された管理アカウントで通知設定を行う 4. 自動有効化できるかを判断し、可能なら自動有効化する • 自動有効化できる場合が「シンプルな方法」 • できるならこのステップで完了 5. 事情があるなどで不可能なら、手動で有効化する 導入ステップ（ケース２：Organizationを利用している）

23 専用の管理アカウントを作る目的 • アカウントを分けることでアクセスできる人の権限を絞る • IAMで管理すると権限の設定漏れリスクが高くなるが、アカウント自 体を分けることでリスクを低くできる • Well-Architectedフレームワークでも強く推奨されています • https://docs.aws.amazon.com/ja_jp/wellarchitected/latest/security- pillar/sec_securely_operate_multi_accounts.html 作り方 • 各組織のそれぞれのやり方でOK 導入ステップ1: GuardDuty管理アカウントを作成する

24 Organizationの管理アカウントで、GuardDuty管理アカウント を「委任された管理者」に設定する • GuardDuty > 設定 に移動 • https://ap-northeast-1.console.aws.amazon.com/guardduty/home#?region=ap-northeast- 1/settings • 「委任された管理者」セクションから設定 注意 • GuardDutyを設定したい全てのリージョンで操作を行うこと • セキュリティを担保するために全リージョンで適用することを推奨 • 以降は全リージョンで適用することを前提とする • ※リンクは東京リージョンなので注意 導入ステップ2: 「委任された管理者」を設定する

25 導入ステップ3: 委任された管理アカウントで通知設定を行う • 実装する方法は自由 • コンソール・CLI・CDK・CloudFormation(StackSets（比較的楽）) • 全リージョンで行うことを忘れずに！

26 自動有効化とは • Organizationに所属すると同時に自動でGuardDutyによる検出をメン バーアカウントでオンにすること 自動有効化できない例 • アカウントごとに個別の設定を適用したい • 自動有効化をオンにすると、GuardDuty管理アカウントにおけるGuardDutyの設 定が優先され、たとえOrganizationに入る前にアカウントごとに設定していたと しても上書きされる • 一度上書きされた後は、Organizationを抜けても上書きされた設定のままになる • Organizationに入って管理されている間は、設定の変更はできない • Organizationの中にGuardDutyをオフにしたいアカウントがある • 個別のオフ設定は現状できない（マルチOrganizationでOrganizationごとわける ことは可能） 導入ステップ4: 自動有効化できるかを判断し、可能なら自動有効化する

27 1. 各メンバーアカウントのGuardDutyの設定を取得・記録する • その設定を引き継いだ設定を行うため コンソールから行う方法 • GuardDutyに移動 • https://ap-northeast-1.console.aws.amazon.com/guardduty/home?region=ap-northeast-1 • 各保護プランを選択して有効化されているかを確認し、記録 • 全リージョンで行うことを忘れずに！ シェルスクリプトなどCLIで行う方法（比較的楽） • ec2 describe-regions コマンドなどで全リージョンを取得 • リージョンごとに list-detectors コマンドでGuardDutyのDetectorIdを取得 • DetectorIdがあれば get-detector コマンドで設定を取得 導入ステップ5: 事情があるなどで不可能なら、手動で有効化する(1/3)

28 2. GuardDuty管理アカウントで各メンバーアカウントを追加する コンソールから行う方法 • GuardDuty > アカウント に移動 • https://us-east-1.console.aws.amazon.com/guardduty/home?region=ap-northeast-1#/linked-accounts • 「招待によるアカウントの追加」から追加 • AWSアカウントID・ルートユーザーのEメールアドレスを入力するだけ • ※「次へ」を押すと即座に追加される（誤った値を入力したらエラーになる） • 全リージョンで行うことを忘れずに！ シェルスクリプトなどCLIで行う方法（比較的楽） • AWSアカウントID・ルートユーザーのEメールアドレスを引数にとる • 全リージョンでリージョンごとにDetectorIdを取得するか、 create-detector コマ ンドで有効化してレスポンスのDetectorIdを保持する • DetectorIdごとに create-members コマンドでメンバーに追加する 導入ステップ5: 事情があるなどで不可能なら、手動で有効化する(2/3)

29 3. 引き続きGuardDuty管理アカウントにおいて、1で既存の設定 があったアカウントの保護プランを設定する コンソールから行う方法 • GuardDuty > アカウント • https://us-east-1.console.aws.amazon.com/guardduty/home?region=us-east-1#/linked-accounts • 対象のアカウントにチェックをつけ、右上の「保護プランを編集」から設定 • 全リージョンで行うことを忘れずに！ • リージョン間で共通する設定が多いならシェルスクリプトでやっても 便利かも • あまり共通していない場合はむしろ二度手間になるかも 導入ステップ5: 事情があるなどで不可能なら、手動で有効化する(3/3)

30 運用する

31 • 通知が来たらすぐさま確認する • 例えば「Finding type: Discovery:IAMUser/AnomalousBehavior」が あったら • ユーザー名などを確認し、本人にIPアドレスやAPI操作の心当たりがあるか聞く • 心当たりあれば良いが、なければ不正アクセスの可能性を調査する • SeverityがLOW（重大度が低）でも油断しない • API操作がある中、調査しても心当たりなければ、アクセスキーの漏洩は確実 • 検出された脅威以外でも、アクセスキーが不正利用された結果バックドアを仕込 まれる可能性すらある • GuardDutyの新着情報をサブスクライブする • https://docs.aws.amazon.com/ja_jp/guardduty/latest/ug/guardduty_sns.html 導入した後は？

32 脅威検出サービスGuardDutyを 導入し運用することが自分でできる 本日のゴール

大志ある挑戦を創造し、日本から世界へ 想いを持った挑戦者と共に走り、共に創る