Amazon Web Services ブログ
【寄稿】SIEMからデータ基盤へ – 三井物産デジタルアセットマネジメントのAWS Security Lake活用事例
こんにちは。ソリューションアーキテクトの松本 敢大です。三井物産デジタル・アセットマネジメント株式会社（以下、MDM）では、デジタル証券や資産運用のビジネスを展開しており、金融機関として高いセキュリティ要件を満たすことが求められています。本ブログは、MDM が Amazon Security Lake を活用して SIEM の限界を超え、セキュリティデータ基盤を構築した事例について、Chief Information Security Officer 鈴木様から寄稿していただいたものです。
背景
AWS： Security Lake の導入に至った背景を教えてください。
鈴木様： 当社は証券会社として、昨今の証券会社に対する監査要件の強化を受け、セキュリティ対策の強化が必要でした。特に不正アクセス対策や本人確認などの要件に対応するため、セキュリティログの一元管理と高度な分析が必要になりました。 従来は主に 3rd party の SEIM を利用していましたが、以下のような課題を感じていました。
- 監査ログ以外にも、ユーザーやデバイスの資産情報、権限情報、ネットワークトラフィックなど多様なデータを相関分析する必要があった
- VPC Flow Log や Route53 Query Log などの大容量データを長期間保存するコストが高額になりがち
- データの種別に応じてサービスを使い分けると、データ連携やクエリ言語の習熟に工数がかかる
- SIEM ではデータの自由度が限定的で、独自のユースケースに対応するカスタマイズが困難
こうした課題から、「メンテナンスや運用、対応策にかかるコストと工数に比して、自社の持てるコントロールや自由度が限定的」という課題を既存の SIEM に感じていました。そこで次世代のセキュリティ管理を行うため、Amazon Security Lake を活用したデータ基盤の構築に着手しました。
ソリューション
鈴木様： Amazon Security Lake を中心とした構成は下図の通りです。複数のソースシステムからログを取り込み、Archive 専用の S3 に保存後、Object Replication により分析アカウントにレプリケートしています。続いて Lambda がデータを OCSF（Open CyberSecurity Schema Framework）に変換し、Security Lake に投入します。そして、Lambda が日次でセキュリティ監査用のジョブを実行する仕組みになっています。
ソースシステムは当初からあまり変わっていませんが、AppFabric と DataDog の使い分けについては、基本的に DataDog を優先しています。AppFabric は DataDog に連携できないソースシステムにのみ利用しています。
現在実装しているユースケースとしては以下があります。
長期間活動のないアカウントの検出と集計
サインインイベントから認証の検出と、対象ユーザーおよび認証先アプリケーションの集計
これらの分析は Athena または日次の Lambda から実行し、レポートやアラートを生成しています。このような可視化により、アカセス権限の見直しや多要素認証の強制適用などの適切なセキュリティ対策を講じることができます。
また、Security Lake が採用している Apache Iceberg テーブルフォーマットに関する理解を深めるため、メタデータ構造の分析や最適化にも取り組んでいます。
Apache Iceberg のメタデータ構造
Apache Iceberg は以下の層構造でデータを管理します。
- Metadata File: スナップショットの一覧など全体情報を管理
- Manifest List: スナップショット単位で複数のManifest Fileを追跡
- Manifest File: 実データファイルの詳細情報・統計情報を列挙
{
"snapshots" : [ {
"sequence-number" : 111111,
"snapshot-id" : 1111111111111111111,
"parent-snapshot-id" : 1111111111111111110,
"timestamp-ms" : 1738086192629,
"summary" : {
"operation" : "append",
"added-data-files" : "7",
"added-records" : "1719",
"added-files-size" : "421902",
"total-records" : "780945471"
},
"manifest-list" : "s3://aws-security-data-lake-ap-northeast-1-xxx/aws/CLOUD_TRAIL_MGMT/2.0/metadata/snap-xxx.avro",
"schema-id" : 0
} ]
}
このようなメタデータを用い、運用改善を図っています。
Why AWS?
AWS： なぜ Security Lake を選択されたのでしょうか？
鈴木様： 大きな理由は、コストパフォーマンスと自由度のバランスです。3rd party の SIEM も優れたサービスですが、特にVPC Flow Log や Route53 Query Log といった大容量データを考慮すると、Security Lake の方が財布に優しいです。 また、AWS 上でのデータエンジニアリングのアプローチを取ることで、セキュリティデータの取り込み・変換・提供のライフサイクル全体を AWS で完結させることができます。これにより、さまざまなデータソースを統合し、高度な分析と柔軟なカスタマイズが可能になります。 Security Lake が OCSF を採用していることも選定理由の一つです。標準化されたスキーマにより、異なるソースからのセキュリティデータを統合的に扱うことができます。また、Apache Iceberg を使用したParquet形式でのデータ保存により、効率的なクエリと分析が可能になりました。
導入効果
AWS： Security Lake 導入の効果と今後の展望について教えてください。
鈴木様： まず、コスト面での大きな効果がありました。Security Lake の月額コストは他社 SIEM よりも大幅に低く抑えられています。特に VPC Flow Log や Route53 Query Log などの大容量データを取り込む場合の差は顕著です。 運用面では、AWS 上でのデータエンジニアリングのアプローチにより、データの取り込み・変換・分析の各フェーズでの柔軟性が向上しました。例えば、特定の監査ニーズに応じたカスタム分析ジョブを追加したり、新しいデータソースを統合したりすることが容易になっています。
今後の展望
鈴木様： 将来的には、フルマネージドサービスと AWS 上でのカスタム開発を組み合わせることで、セキュリティデータを中心とした本格的なデータレイクハウスの構築を目指しています。これにより、リアルタイム性の要求されるセキュリティ監視とバッチ処理による詳細分析の両立、過去データの機械学習モデルへの適用による異常検知の高度化などを実現したいと考えています。 また、今後 S3 Tables など新しいサービスの利用も視野に入れながら、より効率的なデータ管理と分析基盤の構築を進めていく予定です。
著者について
三井物産デジタル・アセットマネジメント株式会社
鈴木 研吾 三井物産デジタル・アセットマネジメント株式会社にて、サイバーセキュリティ・インフラ・社内基盤担当などを担当。前職では SOC での経験もあり、ユーザー企業でのセキュリティ運用に造詣が深い。セキュリティ基盤の構築に取り組んでいる。 経歴
- NRIセキュアにて証券会社むけMSSに勤務（2010～2014)
- Fintech企業（2014～2018）、証券会社（2018～2020）にてモバイルアプリ開発やSREをしつつセキュリティ関連に従事
- LayerX株式会社及び出向先の三井物産デジタル・アセットマネジメント株式会社でセキュリティエンジニア（2020～）
- デジタル庁にも勤務（2021～)
- 個人活動: Secure旅団というセキュリティ系サークルで同人誌、週刊ニュースまとめ、Podcast、監訳・翻訳
- セキュリティ・キャンプ全国大会講師（2019, 2023）
アマゾンウェブサービスジャパン合同会社
松本 敢大 (Kanta Matsumoto)
ソリューションアーキテクトとして、商社業界のお客様を中心に技術支援を行っています。様々な領域を扱う商社という業界で沢山の刺激を受けております。