ライオンxG-gen情報発信コラボ企画のまとめ
当記事は、ライオン株式会社様と株式会社G-genの技術情報発信コラボレーション企画『SAPと連携するデータ分析基盤の実践とTips』で執筆されたものです。
当企画について
当記事は株式会社 G-gen 様とライオン株式会社の技術ブログ相互寄稿企画で執筆されたものです。
当企画では、ライオン側からは、Google Cloud 環境に構築を進めているデータ基盤に関連した以下の記事を公開しました。
G-gen 側からは、Google Cloud のセキュリティと統制に関わる、以下の記事を公開しました。
- VPC Service Controlsの境界の分割設計に関する考察
- Security Command Center検出結果のPub/Subエクスポートをフィルタリングする
- Security Command Center検出結果を一時的にミュートする方法
当記事では、上記の記事をそれぞれ要約してお伝えします。
ライオンによる記事
1. ライオンのデータ基盤構築とSAPデータ活用体制
ライオン株式会社では、中期経営計画「Vision 2030 2nd STAGE」の実現に向け、全社的なデータ活用を支える基盤構築を Google Cloud 上で進めています。これまではデータのサイロ化やガバナンス不足、特に SAP データの活用障壁が課題となっており、これらを解消して迅速な意思決定を可能にし、「未来予測型経営」への変革を実現することが目的です。
構築にあたり、当初は SAP データ活用テンプレートである「Cortex Framework」を用いたシンプルな構成を検討しましたが、検証の結果、大幅な方針転換を行いました。まず、ガバナンスとセキュリティ強化のため、単一プロジェクトから機能別(DL/DWH/DM)の階層構造へと構成を見直しました。また、Cortex Framework については、同社の業務独自テーブル(カスタムテーブル)への対応率が低く、標準テンプレートの適用範囲が限定的であったため、今回は導入を見送りました。
最終的に、データ連携には「Fivetran」、パイプライン管理には運用負荷が軽く安価な「Dataform」を採用し、自社要件に合ったモデリングを実装する体制を整えました。これにより、組織全体でデータを資産として活用するための強固な土台形成を実現しています。
2. ライオンのデータマネジメント
ライオン株式会社のデータサイエンスグループによる、データ基盤におけるSAP データの利活用に向けた取組み事例の紹介です。
データマネジメントにおいては「アジリティ・ガバナンス・利活用」のバランスを考慮し、現在は利用イメージの共有を優先するため「アジリティ(データ準備の速さ)」を重視しています。アーキテクチャは DataLake、DWH、Datamart の3層構造とし、Datamart は扱いやすさを優先して大福帳形式(OBT)を採用。データカタログの整備はフェーズを見極めて行う方針です。
技術面では、ELT ツールに SQL ベースで処理の依存関係管理ができる「Dataform」、BI ツールに指標定義をコード(LookML)で管理できる「Looker」を採用しました。これら Google Cloud 製品を活用し、外部に依存しすぎない、自社主導での全社的なデータ利活用の実現を目指しています。
3. ライオンのデータ基盤における分析環境
部署横断的なデータ共有とデータドリブン文化の定着を目的として、データマート層に部門単位の Google Cloud プロジェクトを整備しました。特にデータサイエンティスト向けに、Python を用いた自由な分析と、VPC Service Controls による高いセキュリティレベルを両立するため、Vertex AI Workbench を採用しました。
セキュアなネットワーク構成として、インスタンスに外部 IP アドレスを持たせず、インターネットを経由しない「限定公開の Google アクセス」と restricted.googleapis.com を利用して BigQuery 等へ接続しています。また、JupyterLab を利用するために DNS 設定を追加し、外部サービス(GitHub 等)への通信は Cloud NAT と FQDN によるフィルタリングで厳格に制御しています。
また VPC Service Controls 環境下でのバッチ実行にあたり、VPC Service Controls 配下では Vertex AI 標準のスケジュール実行機能(エグゼキュータ)が非対応であることが判明しました。解決策として、Cloud Scheduler と Cloud Run jobs、OSS の papermill を組み合わせ、Notebook をコンテナ化してバッチ実行するアーキテクチャを確立しました。
今後は生成 AI を活用し、専門知識がない一般ユーザーでも自然言語でデータ抽出やレポート作成が行える環境の整備を目指しています。
G-gen による記事
1. VPC Service Controls の境界の分割設計に関する考察
当記事は、Google Cloudのリソース保護サービス「VPC Service Controls」における「境界(Perimeter)」の設計方針について解説しています。
VPC Service Controls は、APIやデータ操作を特定 IP アドレスからのリクエストに限定するなど、指定領域内でのデータ移動を制御するセキュリティ機能です。保護範囲を定義する「境界」と、異なる境界間を接続する「境界ブリッジ」という構成要素があります。
境界は組織内で増えすぎないように、ある程度の単位にまとめることが推奨されます。境界をプロジェクト等の単位で細分化すると、境界間での API リクエスト発生時に許可ルール(ブリッジや外向き・内向きルール)の設定が複雑化し、運用負荷が肥大化するためです。 「誰がどのプロジェクトにアクセスするか」という制御は IAM の責務とし、VPC Service Controls はあくまで接続元 IP などのコンテキストに基づく多層防御の役割を持たせるのが適切です。
接続元やアクセス制御の要件が明確に異なるユースケースが複数存在する場合は、複数の境界を作成することを検討します。ただしその場合も、Terraform 等による構築自動化で運用負荷を下げる工夫が望まれます。
2. Security Command Center検出結果のPub/Subエクスポートをフィルタリングする
当記事は、Google Cloud の Security Command Center の検出結果を Pub/Sub へ通知(継続的エクスポート)する際に、特定の条件でフィルタリングする方法とクエリの記述例を紹介しています。
Security Command Center は脆弱性や異常検知を Pub/Sub 経由で外部ツールへリアルタイムに連携できますが、全件ではなく必要な情報のみを通知するために「検出結果クエリ」を利用します。このクエリは独自の文法を持ちますが、コンソール画面のフィルタ操作から自動生成することも可能です。
記事内では、以下の実用的なクエリサンプルが解説されています。
- 基本フィルタ : ミュート済みを除外し、アクティブな検出結果のみを抽出する記述
- 特定プロジェクト : project_display_name 属性(実態はプロジェクト ID)を用いた指定方法
- 特定フォルダ配下 : contains 関数を使用し、リソース階層情報(resource_path)に特定のフォルダ ID が含まれるかを判定する方法
これらを活用することで、運用監視に必要な重要度の高い通知のみを適切にエクスポートすることが可能になります。
3. Security Command Center検出結果を一時的にミュートする方法
当記事は、Google Cloud の Security Command Center における「動的ミュートルール」の活用方法と設定手順について解説しています。
Security Command Center のミュートルールは、特定の条件に合致するセキュリティ検出結果をコンソール上で非表示にする機能です。中でも「動的ミュートルール」は、指定した期日まで、あるいは構成が一致しなくなるまで一時的に検出結果をミュートできます。 これにより、計画メンテナンス、開発環境での例外的な運用、誤検知への対応、一時的なリスク受容などの場面において、許容済みの検出結果をノイズとして排除し、重要なセキュリティ通知に集中できる環境を構築できます。
記事では「特定期間中の VM インスタンスへのパブリック IP 割り当てを許容する」シナリオを例に、以下の手順で検証を行っています。
- 動作確認 : ルール設定前に、対象の VM が検出結果として表示されることを確認
- 設定 : 有効期限や検出クエリ(条件)を指定し、動的ミュートルールを作成
- 適用確認 : 該当する検出結果がデフォルト一覧から非表示になり、専用フィルタを通した場合のみ閲覧できる状態になることを確認
設定期間が終了すればルールは自動的に無効化されるため、一時的なリスク管理に有効な手段となります。
Discussion