組み込みアナリティクスプロバイダーを選定する際のセキュリティ上の考慮事項

組み込みアナリティクスプロバイダーを選定する際のセキュリティ上の考慮事項

2025年10月、パリ。建設作業員に扮した窃盗犯がルーヴル美術館に侵入し、約8,800万ユーロ相当とされるフランス王冠宝飾品8点を盗み出しました。

犯行は白昼堂々と行われ、所要時間はわずか8分未満でした。執筆時点で回収された宝飾品は1点のみで、逃走中に路上に落とされた、ナポレオン3世の妻ウジェニー皇后の王冠でした。

このルーヴル美術館での盗難事件の捜査により、同館における深刻なサイバーセキュリティ上の脆弱性が明らかになりました。複数のセキュリティレポートによると、フランス国家サイバーセキュリティ庁 ( ANSSI ) が2014年に実施した監査で、デジタル基盤に重大な欠陥があることが指摘されていました。具体的には、中核となる監視システムを保護するパスワードが単に「Louvre」であったことや、複数の監視デバイスが古い、もしくはサポートが終了したソフトウェア上で稼働していた点などが含まれていました。

 

アプリにアナリティクスを組み込む際に留意すべきセキュリティ機能

ルーヴル美術館の盗難事件で、犯人たちは力ずくで侵入したわけではありません。建設作業員になりすまし、「正当な存在」であるかのように振る舞うことで侵入しました。

あなたのデータは、ルーヴル美術館における王冠宝飾品と同じくらい価値のあるものです。アプリケーションに組み込むアナリティクスソリューションは、誰がアクセスや変更を行えるのか、誰が閲覧のみ可能なのか、そして誰が一切アクセスできないのかを、明確に制御できる必要があります。セーフティファーストの思想で設計された組み込みアナリティクスは、ビジネス要件に沿った柔軟なアクセス制御を実現しながら、データの安全性を確保します。

美術館が館内に入る「作業員」を適切に検証しなかったのと同様に、ソフトウェアベンダーもサードパーティ連携のセキュリティ対策を十分に行えていないケースが少なくありません。このため、NIS2指令では、組織に対して「サプライチェーンおよびサプライヤーや下請け業者のサプライチェーンにおけるサイバーセキュリティリスクを厳格に評価すること」が義務付けられています。

組み込みアナリティクスは「特権的な参加者」として扱うべきです。アプリケーション内で動作し、機密データに影響を与え、エンドユーザーに公開される以上、他の重要なサプライヤーと同様に厳格なガバナンスが求められます。

 

なぜ監査 ( Auditing ) がこれほど重要なのか

犯人たちが宝石を持ち去った後、警察が直面した最初の課題は、盗犯が館内にいたわずか8分間に何が起きたのか、その時系列を再構築することでした。

ソフトウェア業界では、このようなフォレンジック能力は規制上の要件です。たとえば Google Docs では、ドキュメント作成時のすべての変更がバージョン履歴として記録されます。

DORA の下では、金融業界の組織およびそのソフトウェアプロバイダーは、「インシデント発生前および発生中に何が起きたのかを正確に再構築できること」が求められています。罰金やランサム被害を防ぐためにも、過去の攻撃から学ぶことが重要です。

レジリエンスの重要性

盗まれた8点のうち回収されたのは、ウジェニー皇后の王冠1点のみでした。それも、犯人たちの不手際があったからにすぎません。

デジタルの世界では、データ復旧を運に任せることは許されません。法的にも同様です。たとえば EU の法令である Digital Operational Resilience Act ( DORA ) では、ソフトウェアは「復旧可能」であることが求められ、デジタルシステムが障害を起こしたり攻撃を受けたりした場合でも、「業務を継続できること」を証明する必要があります。

言い換えれば、真のレジリエンスは二重の意味を持ちます。セキュリティ侵害を防ぐことだけでなく、万一発生した場合に完全かつ迅速に復旧できることも含まれます。アプリケーションに組み込まれたアナリティクスは、そのレジリエンスの一部にすぎません。もう一つの重要な要素が、アナリティクスツールがクエリーを実行するデータベースです。このため InterBase のようなデータベースは、ポイントインタイムリカバリー、暗号化、ジャーナリングといったセキュリティ機能に重点を置いています。

 

マルチテナンシー

顧客向け、または組み込みアナリティクスにおいて、マルチテナンシーは極めて重要です。

安全なプラットフォームでは、組織ごとに論理的に分離され、同じ基盤インフラを共有しながらも、各テナントが独自のユーザー、コンテンツ、ブランディングを持てるようになっています。

このアプローチにより、顧客間のデータ漏えいを防ぎつつ、スケーラブルな運用が可能になります。Yellowfin のようなプラットフォームはこのモデルを採用しており、環境を複製することなく、各組織が独立して運用できます。

 

Yellowfin のセキュリティに対する考え方

Yellowfin は、組み込みを前提としたアナリティクスプラットフォームとして設計されています。つまり、別のアプリケーション ( 貴社の製品 ) の内部で動作することを前提に、摩擦や脆弱性を生まないセキュリティモデルが構築されています。

 

ガバナンスとロールベースのアクセス制御

Yellowfin は、コンテンツセキュリティと機能セキュリティを分離した、きめ細かな権限モデルを採用しています。

  • 機能セキュリティ:ユーザーが「何をできるか」を制御します。 ( 例: レポートを作成できるか、データをエクスポートできるか、ユーザー管理ができるか )
  • コンテンツセキュリティ:ユーザーが「何を見られるか」を制御します。 ( 例: 特定のダッシュボード、フォルダ、データカテゴリへのアクセス )

これは非常に重要なポイントです。カスタム開発では、権限がコードにハードコーディングされがちですが、Yellowfin では非エンジニアの管理者でも UI からロール管理が可能です。その結果、エンジニアリングのボトルネックを大幅に減らせます。

 

ネイティブなマルチテナンシー

これは Yellowfin における最も強力なセキュリティ資産のひとつです。単一のソフトウェアインスタンスで複数の異なる顧客 ( テナント ) にサービスを提供しながら、データを確実に分離できます。

各テナントは、それぞれ専用の物理データベースを持つこともでき、Yellowfin はログインユーザーに応じて接続先を動的に切り替えます。

さらに、同じレポートを見ている 2 人のユーザーでも、権限に応じて表示されるデータは異なります。たとえば、営業マネージャーは全地域の売上を確認できる一方、営業担当者は自分の担当分のみを閲覧できます。

 

Yellowfin を始める

ルーブル美術館の教訓は非常に厳しいものです。油断、時代遅れのシステムや運用、そして「自分たちには起こらない」という思い込みが、かけがえのない国宝の喪失につながりました。

こうしたギャップを自社のシステムで防ぐにはどうすればよいでしょうか。すべての操作を記録し、障害発生時にも適切に復旧し、一度被害に遭った博物館が二度と同じ過ちを繰り返さないのと同じ厳格さで権限を管理するソリューションを選ぶことです。

Yellowfin は、データ漏えい、コンプライアンス違反、そして安全なデータアクセスを維持し続けるための継続的なコストから守るセキュリティアーキテクチャを備えた BI ディシジョンエンジンです。

 

 

Thanks for trying Yellowfin

Please complete the form below to request your copy of Yellowfin today.