解説

Mendixのようなローコード開発プラットフォームで構築された業務システムは、機密性の高いユーザーデータを取り扱っているケースが多いです。そのため、単に画面上の操作を制限するだけでなく、根幹となる認証・認可の仕組みを見直す視点が非常に重要になります。

特に注目したいのが、プラットフォームが内部的に持つSystem.Userというエンティティ(概念)に対するアクセス制御の問題点です。標準ドキュメントだけでは具体的な設定方法や挙動の説明が不足しているため、開発者が意図せず権限を広げてしまうリスクがあります。

この状況は、機密性の高いデータが匿名ユーザーや最小権限のロールから予期せぬ形で閲覧できてしまうなど、重大な情報漏洩につながる可能性があります。自社の環境では、アプリケーション全体を通してアクセスルール設定が適切に行われているかを確認しておきたいところです。

ポイント

  • Mendixのアクセスルールにおいて、System.Userエンティティに対する特殊な動作に関するドキュメント上のガイダンスが不足している。
  • これにより開発者が誤って過剰な権限(例:匿名ユーザーによる全レコード閲覧)を設定しやすく、機密データ漏洩や権限昇格のリスクがある。
  • 単なるXPath制約ではなく、アプリのセキュリティロール管理設定レベルでアクセス制限を徹底し、ルール全体を見直す必要がある。

情シスへの影響

Mendixアプリケーションを利用して構築された、機密情報を取り扱う業務システム全般に影響します。

特に以下の領域におけるレビューが必要です:

  1. データアクセス制御(BAC/ACL): System.Userエンティティやそれに紐づく他のユーザー関連データの閲覧・更新権限設定。
    2. ロール管理とアプリケーションセキュリティ: ユーザーロールごとに定義されているアクセスルール(特にXPathによる制限)の設定漏れや過剰な許可がないか。

  2. 匿名/ゲストユーザーの挙動: ログインしていない、または最小権限のユーザーが予期せず大量のデータにアクセスできないか。

影響範囲

Mendix Runtimeを利用したアプリケーション全般(特に認証・認可機能を実装しているもの)。対象バージョンは本文から特定できず、「要確認」とします。影響を受けるのは、アプリケーション内のエンティティ設計およびアクセスルール設定です。

重要度

★★★★☆

対象者

  • M365管理者
  • Entra管理者
  • AD管理者
  • セキュリティ担当者

優先度

早めに対応

優先度の理由

本件は、直接的な脆弱性指摘というより「設計上のリスク」ですが、アクセスルールに起因する権限昇格や情報漏洩のリスクを伴います。早期に全システムに対するセキュリティレビューを実施し、設定ミスを防ぐためのガイドライン策定と適用が必要です。

確認手順

  • 対象のMendixアプリケーションごとに、System.Userエンティティおよび機密データを持つエンティティのアクセスルール一覧を収集する。
  • 「匿名ユーザー」「ゲスト」など最小権限ロールが持つアクセス権限が、意図しない全レコードへのアクセス(All Records)を許可していないかを確認する。
  • 単なるXPath制約のみに依存しているアクセス制限ロジックを特定し、App Securityのより上位のロール管理設定で制御可能か検証する。
  • 開発チームに対し、Mendixのセキュリティ関連ドキュメントの最新版を参照させ、設計レビューを義務付ける。

推奨対応

  • 全社利用システム(Mendix構築)について、アプリケーションセキュリティ担当者主導でアクセスルール監査を実施する。
  • 特に権限設定において「最低限の特権(Principle of Least Privilege)」の原則を遵守しているか再検証し、過剰な許可範囲を撤廃する。
  • 開発者向けに、System.Userなどのプラットフォーム基幹エンティティに関するセキュリティベストプラクティスを共有し、設計レビュー工程に組み込む。