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に ■ 最 大 同時実 行 数を５に ○ 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 

ご清聴ありがとうございました ！