Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
Amazon Security Lakeを活用したセキュリティログの集約とAIによる可視化の最前線
Search
adachi.ryo
June 30, 2025
Programming
0
2
Amazon Security Lakeを活用したセキュリティログの集約とAIによる可視化の最前線
AWS Summit Japan 2025の登壇スライドになります。
adachi.ryo
June 30, 2025
Tweet
Share
More Decks by adachi.ryo
See All by adachi.ryo
技術的負債で信頼性が限界だったWordPress運用をShifterで完全復活させた話
rvirus0817
0
160
TechBull Membersの開発進捗どうですか!?
rvirus0817
0
1.2k
クラウド脆弱性の傾向とShisho Cloudの活用
rvirus0817
0
190
TechBullエンジニアコミュニティの取り組みについて
rvirus0817
0
1k
横断SREの立ち上げと、AWSセキュリティへの取り組みの軌跡
rvirus0817
3
11k
ゼロから創る横断SREチーム ~挑戦と進化~
rvirus0817
3
5.1k
入社1ヶ月でここまでやった!Findy Toolsインフラ支援の最適化
rvirus0817
11
13k
メンティー同士で輪読会を始めたら学びしかなかった
rvirus0817
1
1.1k
Lancersをコンテナへ本番移行する取り組み
rvirus0817
1
3.3k
Other Decks in Programming
See All in Programming
GitHub Copilotの全体像と活用のヒント AI駆動開発の最初の一歩
74th
6
1.8k
[Codecon - 2025] Como não odiar seus testes
camilacampos
0
100
TypeScriptでDXを上げろ! Hono編
yusukebe
4
930
LLMは麻雀を知らなすぎるから俺が教育してやる
po3rin
3
1.9k
202507_ADKで始めるエージェント開発の基本 〜デモを通じて紹介〜(奥田りさ)The Basics of Agent Development with ADK — A Demo-Focused Introduction
risatube
PRO
6
1.4k
それ CLI フレームワークがなくてもできるよ / Building CLI Tools Without Frameworks
orgachem
PRO
17
3.7k
MCP連携で加速するAI駆動開発/mcp integration accelerates ai-driven-development
bpstudy
0
260
SQLアンチパターン第2版 データベースプログラミングで陥りがちな失敗とその対策 / Intro to SQL Antipatterns 2nd
twada
PRO
36
11k
Vibe Codingの幻想を超えて-生成AIを現場で使えるようにするまでの泥臭い話.ai
fumiyakume
21
10k
実践!App Intents対応
yuukiw00w
0
120
Claude Code と OpenAI o3 で メタデータ情報を作る
laket
0
110
#QiitaBash TDDで(自分の)開発がどう変わったか
ryosukedtomita
1
350
Featured
See All Featured
StorybookのUI Testing Handbookを読んだ
zakiyama
30
6k
Reflections from 52 weeks, 52 projects
jeffersonlam
351
21k
Practical Orchestrator
shlominoach
190
11k
Fashionably flexible responsive web design (full day workshop)
malarkey
407
66k
Documentation Writing (for coders)
carmenintech
73
5k
How to Create Impact in a Changing Tech Landscape [PerfNow 2023]
tammyeverts
53
2.9k
A Tale of Four Properties
chriscoyier
160
23k
Building Better People: How to give real-time feedback that sticks.
wjessup
367
19k
Thoughts on Productivity
jonyablonski
69
4.8k
Large-scale JavaScript Application Architecture
addyosmani
512
110k
For a Future-Friendly Web
brad_frost
179
9.9k
Build your cross-platform service in a week with App Engine
jlugia
231
18k
Transcript
Amazon Security Lake を活 用 した セキュリティログの集約とAIによる可視化の最前線 AWS Summit Japan
| 2025/06/26 ファインディ株式会社 CTO室/SRE 安達 涼(@adachin0817)
2 ࣗݾհ 安達 涼(@adachin0817) ・ファインディ(株) / CTO室/Senior SRE ・Blog: blog.adachin.me/wiki.adachin.me
・TechBull(エンジニアコミュニティ) techbull.cloud もうすぐ100名! ・SRE/ジュニアエンジニアのメンタリング 累計300名↑ ・コミュニティ創業/主催 ・LT企画、Members 会員管理画 面 の開発をリード ・かつてはOSS版Vulsのコントリビュートやイベント主催など ・89年 生 まれ、東京都 足立 区出 身 で埼 玉 県春 日 部市が地元 ・フレンチブルドッグの飼い主でもある
3
4
5
アジェンダ • Findyを 支 える技術 • Platform SREチームの位置づけとミッション • AWSセキュリティログを管理する必要性について
• Amazon Security Lakeとは • アーキテクチャと導 入 構成 • 活 用 Tipsと可視化による活 用 • 運 用 とベストプラクティス • Amazon BedrockによるAI分析 • まとめ 6
Findyを 支 える技術
技術スタック 8 • 開発 言 語・フレームワーク • インフラ・ミドルウェア・DB
Findy Team+ 簡易構成図 9
Findy Team+ 国際セキュリティ認証「SOC2 Type2」を取得 10
Platform SREチームの位置づけとミッション
Platform SREチームの位置づけとミッション • 短期ミッション ◦ 「ファインディの事業成 長 を 支 えるために、SRE組織のあり
方 の確 立 」 • 中期ミッション ◦ 「社員全員が事業成 長 に集中できるような仕組みを構築し、安全に提供」 12
AWSセキュリティログを管理する必要性とは ?
AWSセキュリティログを管理する必要性とは ? • セキュリティインシデント検知と対応の証拠となる ◦ 誰が・いつ・何をしたのかを確認するための情報源がログとなる ◦ 起きたことを証明できず、原因も対処も曖昧になってしまう • 事後対応・監査の観点から必須
◦ SOC2などの監査で必要 ◦ 分析可能な状態で保管しているかがポイント • セキュリティ 文 化の浸透と信頼性の担保 ◦ SRE/開発チームがログベースでセキュリティを意識できるようになる ◦ 組織全体のセキュリティ透明性と信頼性の 土 台となる 14
対象となるAWSセキュリティログ 15 AWS Security Hub AWS WAF Logs AWS CloudTrail
Amazon Route 53 Resolver Query Logs Amazon Virtual Private Cloud Flow Logs ・セキュリティ評価結果 ・アクセスログ ・IPアドレス ・管理イベント ・データイベント ・DNSクエリログ ・ネットワーク通信ログ (例) ・Amazon EC2作成 ・Amazon S3データ 読み取り (例) ・不審なアクセス ・通信異常を検知 (例) ・ドメイン問い合わせ履歴 ・マルウェアのC2通信などを検知 (例) ・DDoS攻撃 ・SQLインジェクション ・クロスサイトスクリプティング XSS ・検知/分析 (例) ・AWS環境のセキュリティリスク ・設定ミスの検知
この分析環境を 一 から実装するには 時間がかかってしまう しかし…
Amazon Security Lake ! そこで
Amazon Security Lakeとは • フルマネージド型のセキュリティデータレイクサービス ◦ AWSから収集したセキュリティデータを 自 動で 一
元管理ができる ◦ Open Cybersecurity Schema Framework (OCSF)に正規化 ◦ 内部監査のニーズにも対応しやすくなる ◦ Apache Parquetに基づいてデータを標準化 ◦ Amazon Athenaを利 用 して効率的な分析を可能 ◦ AWS OrganizationsとTerraformに対応 18
アーキテクチャと導 入 構成
アーキテクチャと導 入 構成 20 • 全てTerraform化 • Amazon Security Lakeを有効すると以下のサービスが
作られる • Amazon S3、AWS Lambda、Amazon Simple Queue Service、Amazon Athena、AWS Lake Formation • もちろんAmazon Security Lakeを無効にすると上記全 て削除される • Amazon Managed Grafanaを導 入 ◦ 閲覧者であれば$5 ◦ Amazon Athenaへ参照するためにはAWS Lake Formationで権限周り管理する必要あり
アーキテクチャと導 入 構成(Terraform/Amazon Security Lake) 21 コスト削減(半額) ・ストレージクラス
・31 日 後にSTANDARD_IA ・80 日 後にONEZONE_IA ・300 日 後に削除
22 アーキテクチャと導 入 構成(Terraform/Amazon Security Lake)
アーキテクチャと導 入 構成(Terraform/Amazon Managed Grafana) 23 ・権限付与 ・Amazon Athena
・AWS Glue ・Amazon S3
アーキテクチャと導 入 構成(Terraform/Amazon Managed Grafana) 24 ・AWS SSOログイン ・Amazon Athena,Amazon
CloudWatchをデータソースに ・ap-northeast-1 ・us-east-1 を明 示 的に許可
活 用 Tipsと可視化による活 用
AWS WAF Dashboard
AWS WAF テーブル構造 • 送信元情報 : アクセス元IPや国 ◦ src_endpoint •
リクエスト内容 : URL、HTTPメソッド、ヘッダー、ユーザーエージ ェントなど ◦ http_request • WAFルール : 適 用 されたファイアウォールルールの情報 ◦ firewall_rule • イベントの分類や深刻度 : カテゴリ、アクション、深刻度など ◦ match_details • 判定結果 : Allowed / Blockedなど ◦ disposition • クラウド環境 : アカウントID、リージョン ◦ accountid,region • 時刻情報 : タイムスタンプと 日 付 ◦ time, time_dt 27
AWS WAFの解析とSQL • いきなりブロックするとサービスに影響がある • まずは「COUNTモード」で分析していく • どのUser-Agentに対して何回ヒットしているかを可視 化する •
AWSManagedRulesBotControlRuleSet ◦ Bot(例 : Googlebot、curl、悪意あるスキャナー など)の傾向を確認できる ◦ 最近ではAI関連のBotが増えているため、BLOCK する必要がある 28
AWS WAF COUNTモードのカラムが 見 当たらない • Amazon CloudWatch Logsによる 生
ログ ◦ notTerminatingMatchingRulesカラムに保存 • Amazon Security Lakeの場合 ◦ マッピングされていないデータとして扱われる ◦ Unmappedカラムに格納される • 参考 ◦ https://schema.ocsf.io/classes/security_finding?extensions= ◦ https://docs.aws.amazon.com/ja_jp/security-lake/latest/userguide/open-cybersecurity- schema-framework.html 29
AWS WAF Dashboard 30 • AWS WAF(Web ACL) ◦ Request
by Country(ࠃผͷϦΫΤετ) ▪ Heat map ▪ Bar graph ◦ Total Request(શϦΫΤετͷूܭ) ◦ WAF Rule Request(WAFϧʔϧ͝ͱͷϦΫΤετ) ◦ Block IP(Blockͨ͠IPϦετ) ◦ Count Rule ID(Count͝ͱͷϧʔϧ໊ͱϢʔβʔΤʔδΣϯτ) ◦ Access Ranking(IPΞυϨεURL͝ͱͷϦΫΤετ) ◦ WAF Analytics Logs(ੳ༻ͷϩά/ϒϩοΫใͳͲ)
AWS CloudTrail Dashboard
AWS CloudTrail テーブル構造 • 送信元情報 : アクセス元IPやドメイン ◦ src_endpoint •
リクエスト内容 : API、サービス名、エラー情報、リクエストデータ ◦ api • ユーザー情報: 実 行 ユーザー、ロール、など ◦ actor • クライアント情報 : User-Agentなど ◦ クライアント情報 : User-Agentなど • 操作対象リソース : 操作されたリソース(ARNなど) ◦ resources • イベントの分類や深刻度 : カテゴリ、アクション名、深刻度など ◦ class_name, category_name, severity, activity_name • 判定結果 : イベントステータスやエラー判定(成功/失敗など) ◦ status, api.response.error • クラウド環境 : アカウントID、リージョン ◦ accountid, region, cloud.provider • 時刻情報 : UNIXタイムとタイムスタンプ形式 ◦ time, time_dt 32
AWS CloudTrailの解析とSQL • 不審な操作やアクティビティの検出 ◦ 管理者権限を持つユーザーによる Delete, Update, Put* 系APIの可視化
• ユーザー・ロール別アクティビティの集計 ◦ IAMユーザーやAssumed RoleごとのAPI実 行 回数グラフ • アクセス元IPの分析(地理・ASN) ◦ アクセス元IP(src_endpoint.ip)の地理的分布マップ • セキュリティイベントの可視化 ◦ AccessDenied や UnauthorizedOperation の件数と発 生 傾向 • 操作タイムラインの可視化 ◦ イベント発 生 数の急増などの異常値検出 • 特定サービスに絞った可視化 ◦ Amazon S3, Amazon EC2, IAM, Amazon VPC,Security groupなど対象を絞る 33
AWS CloudTrail Dashboard 34 • AWS CloudTrail ◦ Total Event
Count(全イベント数) ◦ Total Errors(全エラー数) ◦ Event History(イベント履歴) ◦ Top Event Names(イベント名) ◦ Total Event Source(イベント発 生 元) ◦ Top Users(ユーザーランキング) ◦ Total Source IP(操作元のIPアドレス) ◦ Amazon S3 Access Denied(S3でアクセス拒否された回数) ◦ Amazon EC2 Change Event Count(EC2の設定変更回数) ◦ Amazon VPC Change Event Count(VPCの設定変更回数) ◦ Security Group Change Event Count(SGの設定変更回数) ◦ Error Event(分析 用 エラーイベント)
Amazon Route 53 (Resolver Query Logs) Dashboard
Amazon Route 53(Resolver Query Logs) テーブル構造 • DNSクエリ情報 ◦ query.hostname:
クエリ対象のドメイン名(例: api.example.com) ◦ query.type: クエリタイプ(例: A, AAAA, MX など) ◦ query.class: クエリクラス(通常 IN) • 応答情報 ◦ answers: DNS応答の詳細(タイプ、IPアドレスなど) • 通信情報 ◦ src_endpoint.ip: クエリ送信元のIPアドレス ◦ src_endpoint.vpc_uid: 発信元のVPC ID ◦ src_endpoint.port: 発信元ポート番号 ◦ dst_endpoint.instance_uid: クエリ先のEC2インスタンスID(あれば) • 接続情報 ◦ connection_info.protocol_name: 通信プロトコル(例: UDP, TCP) ◦ connection_info.direction: 通信 方 向(例: INBOUND, OUTBOUND) • イベント情報 ◦ severity: 深刻度(Low, Medium, High など) • DNS応答コードと判定 ◦ rcode: 応答コード(例: NoError, NXDOMAIN) 36
Amazon Route 53(Resolver Query Logs)の解析とSQL • 不審な操作やアクティビティの検出 ◦ NXDOMAIN(存在しないドメイン)発 生
件数の推移 ◦ .xyz や .cn など怪しいTLDへのクエリ件数 ◦ 不明なVPCやIPアドレスからの異常なクエリ数 • アクセス傾向の把握 ◦ 時間帯別のクエリ件数の推移(ピーク時間帯分析) ◦ クエリが多い上位ドメインランキング ◦ 多くクエリを送っている送信元VPC / IPのランキング • 名前解決成功/失敗率 ◦ Ԡίʔυʢrcodeʣผͷ݅άϥϑ ◦ NoError / NXDOMAIN / SERVFAIL などの割合 ◦ 成功率 = NoError件数 ÷ 総件数 を 日 次/週次でトレンド化 • 判定結果・アクション別の可視化 ◦ disposition(Allowed / Blocked)の割合と推移 ◦ action(Allow / Monitor / Block)の件数 比 較 • セキュリティインシデントのヒント ◦ ௨ৗݟΒΕͳ͍υϝΠϯͷٸܹͳΞΫηε૿Ճ 37
Amazon Route 53(Resolver Query Logs) Dashboard 38 • Amazon Route
53(Resolver Query Logs) ◦ Total Request / Changes in Query Failure Rate (૯ϦΫΤετͱΫΤϦࣦഊͷมԽ) ◦ Changes in Query Success Rate (ΫΤϦޭͷਪҠʢ࣌ؒଳผʣ) ◦ Trend of NXDOMAIN Query Counts (NXDOMAINʢଘࡏ͠ͳ͍υϝΠϯʣΫΤϦͷτϨϯυ) ◦ Query Distribution by Region (ϦʔδϣϯผͷDNSΫΤϦ) ◦ Query Success/Failure Rate (NXDOMAIN, SERVFAIL, etc.) (ΫΤϦͷޭʗࣦഊʢNXDOMAINɺSERVFAIL ͳͲʣ) ◦ Top Source IPs for NXDOMAIN Queries ( NXDOMAINΫΤϦΛଟ͘ૹ৴ͨ͠ૹ৴ݩIPͷϥϯΩϯά) ◦ Slowest DNS Queries ( Ԡ͕࠷͔ͬͨDNSΫΤϦͷҰཡ) ◦ Top Queried Domains/IPs (Ranking) (࠷ଟ͍͘߹Θͤ͞ΕͨυϝΠϯIPͷϥϯΩϯά)
Amazon VPC Flow Logs Dashboard
Amazon VPC Flow Logs テーブル構造 • 通信元(送信元) ◦ src_endpoint.ip :
送信元IPアドレス ◦ src_endpoint.port : 送信元ポート番号 ◦ src_endpoint.vpc_uid / instance_uid : VPC・インスタンスID • 通信先(宛先) ◦ dst_endpoint.ipɿѼઌIPΞυϨε ◦ dst_endpoint.port : 宛先ポート番号 ◦ dst_endpoint.vpc_uid / instance_uid : VPC・インスタンスID • 接続情報 ◦ connection_info.protocol_verɿϓϩτίϧʢྫɿIPv4ʣ ◦ connection_info.direction : 通信 方 向(Inbound / Outbound) ◦ connection_info.tcp_flags : TCPフラグ(例 : SYN, ACK) • 通信量 ◦ traffic.packetsɿύέοτ ◦ traffic.bytes : バイト数(通信量) • イベント分類と判定 ◦ action : Allow / Reject(許可 or 拒否) ◦ disposition : 判定(Allowed / Blocked) ◦ severity : 深刻度 ◦ class_name / category_name / activity_name : イベント分類情報 40
Amazon VPC Flow Logsの解析とSQL • 通信の許可・拒否の状況 ◦ 通信件数グラフ(Allow / Reject)
◦ 拒否された通信の送信元IPランキング • トラフィック量の可視化 ◦ パケット数 / バイト数(traffic.bytes)の時間推移グラフ ◦ 通信量の多いインスタンスランキング(src_endpoint.instance_uid) ◦ ѼઌϙʔτผτϥϑΟοΫྔʢྫɿ443, 80, 22, 3306 ͳͲ) • 通信先・送信元の可視化 ◦ 宛先IPごとの通信件数(dst_endpoint.ip) ◦ 内部VPC内通信 vs 外部インターネット通信の割合 • セキュリティ監視(異常検知) ◦ 拒否された通信ポートのランキング ◦ 1つのIPからの 大 量通信検出(DDoS、内部スキャン) ◦ 未使 用 ポートへのアクセス傾向の可視化 • 時間ベースの傾向分析 ◦ ࣌ؒଳผτϥϑΟοΫͷϐʔΫ࣌ؒଳάϥϑ ◦ 日 次トラフィック量の 比 較(平均 / 最 大 ) 41
Amazon VPC Flow Logs Dashboard 42 • Amazon VPC Flow
Logs ◦ VPC Total Request (VPC૯ϦΫΤετ) ◦ Total in/out Request (VPCͷૹ৴/ड৴ϦΫΤετ݅(In/Out)) ◦ WAF/SG Allow Blocked (WAF / ηΩϡϦςΟάϧʔϓͰͷڐՄɾϒϩοΫ݅) ◦ Source IP Ranking (ૹ৴ݩIPΞυϨεͷϥϯΩϯά) ◦ Destination IP Ranking (ѼઌIPΞυϨεͷϥϯΩϯά) ◦ Traffic by Protocol (ϓϩτίϧผͷτϥϑΟοΫྔ) ◦ TCP Flag Distribution / Anomalous Pattern Detection (SYN, ACK, FINͳͲͷΈ߹Θͤҟৗͳ௨৴ͷੳ) ◦ Traific Port (༻ϙʔτผͷτϥϑΟοΫྔ) ◦ WAF/SG Blocked (WAF / ηΩϡϦςΟάϧʔϓͰϒϩοΫ͞Εͨ௨৴Ұཡ) ◦ Access Alert list (ΞΫηεΞϥʔτҰཡ(ཁҙ௨৴Ϧετ))
運 用 とベストプラクティス
運 用 とベストプラクティス • Amazon Managed Grafanaの管理 方 法 ◦
Terraform化 ▪ SSOユーザー管理 ▪ Grafana Alert ◦ Dashboardは 手 動管理 ▪ 7000 行 のJSONファイルを管理することはほぼ不可能に近い ▪ CDで隔週バックアップを取得し、差分チェックを 行 うことにした ▪ grafana-dashboard-backup • Goで開発 https://github.com/RVIRUS0817/grafana-dashboard-backup 44
• トラブルシューティング ◦ グラフが表 示 されず、AWS Glueのパーティションが突然最新に更新されない事象が発 生 ◦ AWS
Lambda側で 生 データの抽出、変換、ロード (ETL) ジョブをサポートしている ◦ トラフィック量が増加してしまうとタイムアウトが 生 じる ◦ AWS Lambda ▪ タイムアウトを5分から10分に変更 ▪ バッチウィンドウを300に ▪ 最 大 同時実 行 数を5に ◦ Amazon SQS ▪ Poll for messagesを再実 行 ◦ この対応により、グラフが最新になった 45 運 用 とベストプラクティス
疑問点 • Amazon VPC Flow LogやAWS WAFのログを個別に有効化 していないにもかかわらず、なぜ取得できているのか ? ◦
AWS内部でログを取得するためのストリームがあり、データを取り込んで いる • これらのログを個別に有効化した場合に料 金 が 二 重に発 生 す るのではないのか ? ◦ そのようなことは基本ないとのこと • Terraformとの相性について ◦ Amazon Security Lakeが内部的に多くのリソースを 自 動的に作成するた め、AWSの管理に任せるのがベスト • Amazon Athenaのコストについて(パーティション) ◦ パーティションの設定が適切でないと不要なコストがかかるのではないか と 心 配したが、 日 付ごとに管理されたParquetファイルを参照しているた め、問題なし 46
Amazon BedrockによるAI分析
• Slack、Amazon Bedrock(Claude)、Amazon Athena • 自 然 言 語データ分析応答フローを2週間で実装 •
Findy SRE-AIと名付けた • Terraform化とAWS LambdaはGoで実装 • 対象サービスに対するWAF経由のアクセス数やCountアクション を元に統計を出 力 • 日 々の定常チェックをSlack上で完結にし、 工 数を削減 48 Amazon BedrockによるAI分析
まとめ
まとめ • AWSのセキュリティログを 自 動で集約してくれる • Amazon Athenaで簡単に検索・分析できる • マルチリージョン・マルチアカウント管理が楽になる
• 監視・分析・監査がこれひとつでできる • ログ形式が統 一 されていてクエリしやすいが、テーブル 構造は把握する必要あり • コストは 比 較的安いがAWS Lambdaが 高 くなりがち • 最初の設定は少し 手 間だが、運 用 はシンプル • 今後はさらなるAI解析とコスト削減をしていく 50
ご清聴ありがとうございました !