Shiori Demo

Appearance

大雑把な「特権モード（Bypass ACL）」の誘惑と、Slack連携で起きた機密流出の危機 ​

1. 概要 ​

前回のコラムで扱った「検索スコープ迂回（Document Set Bypass）」の修正のように、セキュリティホールの修正は時として複雑な権限チェックレイヤーを増設することになる。 しかし、その防衛策がシステム全体の他の連携パス（例: Slackなどの外部チャットボット連携）に予期せぬ副作用をもたらし、さらにそれを安易に回避しようとした「大雑把なバイパスフラグ」の適用が、別の壊滅的な情報漏洩バグを生み出しそうになる事例がある。 本稿では、OnyxのSlack連携におけるセキュリティチェックの迂回漏れバグ（onyx-dot-app/onyx#10978）を事例に、システム間連携における権限の「粒度（Granularity）」の設計と、特権バイパスが孕むセキュリティリスクについて分析する。

2. インシデントの分析：セキュリティ強化が引き起こした「Slack連携の全滅」 ​

2.1. 背景：前回の「ドキュメントセット権限チェック」の余波 ​

Onyxでは、APIレイヤーでの検索フィルタ改ざんを防ぐため、リクエスト時に「ユーザー自身が、そのドキュメントセットに対して正当な閲覧権限を持っているか」をDBセッションを用いて厳密に検証するチェックゲートを前倒しで増設した。 このチェックは通常のWebチャットUIでは正しく機能したが、Slackボット経由での対話において予期せぬ衝突を引き起こした。

2.2. 現象：Slack管理者の設定とエンドユーザー権限のミスマッチ ​

Slack連携では、Slackの特定のチャンネルに対して管理者が「チャンネル専用ペルソナ（アシスタント）」を設定し、そのチャンネル内で参照可能なドキュメントセットをあらかじめ割り当てる。 しかし、Slackのチャンネル内で一般メンバーがボットに話しかけた際、裏側の処理で「そのメッセージを送った一般ユーザー自身が、チャンネル設定のドキュメントセットに対する個別権限を持っているか」のチェックが走ってしまった。

Slackのエンドユーザーはチャンネルの管理者ではなく、そのドキュメントセットの明示的な「所有者」でもないため、このチェックゲートによって処理がエラー（権限不足）となり、Slack上のボットがメッセージに対して一切応答できなくなる（全滅する） という機能障害が発生した。

2.3. 安易な「Bypass ACL」が引き起こす、ドキュメントの超法規的リーク ​

このバグを修正するために、開発者は当初、Slackからのクエリ処理において「ACL（アクセス制御）全体をバイパスする」ためのフラグ bypass_acl=True を設定してチェックをスルーさせようとした。

しかし、ここに極めて危険なセキュリティの罠が潜んでいた。 Onyxの bypass_acl フラグは非常に強力で、これを True にすると、ドキュメントセットのチェックだけでなく、検索エンジン（Vespa）が個々のファイル単位で実行する行レベルの「ユーザー個別閲覧制限（ACL）フィルタ」までもが完全に無効化（スキップ）されてしまう仕様だった。

この結果として、

  • Slack上で匿名ユーザー（または外部共有されたチャンネルの権限のないユーザー）がボットに問いかけた際、チャンネル管理者が指定したドキュメントセットの境界をはるかに越えて、システム全体にある「他の従業員の個人用ファイル」や「社外秘の極秘ドキュメント」までもが検索結果に引き出され、AIによって回答されてしまう という、壊滅的な情報漏洩が発生する寸前の状態となった。

3. 実体験：開発を急ぐ際の「とりあえず特権モード」の甘い蜜 ​

システムの特定の機能（この場合はSlack連携）が動かなくなり、ユーザーから障害報告が上がっているパニック状態において、開発者は「手っ取り早く動かすための超法規的措置（スーパーユーザー権限の適用）」の誘惑にかられやすい。

  • 実体験エピソード: あるエンタープライズ向けのSaaS開発において、外部の基幹システム（ERP）とデータ連携する連携バッチプログラムの権限エラーが本番環境で発生し、同期が数時間停止する障害が起きた。 担当エンジニアは、エラーの原因がテナント間の細かいフォルダ閲覧権限のミスマッチであることを突き止めたが、同期遅延を取り戻す焦りから、バッチがDBにアクセスする際のセキュリティコンテキストを「個別テナント権限」から「グローバル管理者権限（System Admin）」に一時的に引き上げてバッチを再起動した。 その結果、バッチは正常に動き出して同期は完了したものの、バッチ内部のバグ（他テナントへのデータ漏れロジック）によって、特定のテナントに属する顧客データが、別の全く無関係な競合他社のテナントに「管理者権限によってセキュリティチェックをすり抜けて」同期・上書きされてしまうという、大規模なコンプライアンス違反・データ破損事故を引き起こした。 「とりあえず特権（Bypass）をつけて動かす」という安易なショートカットは、後から取り返しのつかない破滅的なリークを呼び込む「トロイの木馬」である。

4. 解決策と権限バイパスの「最小特権の原則」 ​

Onyxのチームは、自動コードレビューツールやセキュリティ検証プロセス（Cubic / Greptile等）の指摘を受け、bypass_acl=True という粗い（Coarse-grained）バイパスを却下し、極めてスコープの狭い（Fine-grained）専用フラグ bypass_docset_ownership_check=True を新設して修正を適用した。

python
# 1. 粗すぎる特権バイパスを廃止し、専用のピンポイントフラグに変更
# bypass_acl=True (ドキュメント個別のアクセス制限まで無効化される最悪の指定を排除)

# 2. チャンネル管理者から委託された「ドキュメントセットの所有権チェック」のみを安全にスキップ
if not bypass_docset_ownership_check:
    # ユーザー自身のドキュメントセット権限を厳密にチェックする
    validate_document_set_ownership(db_session, user, user_selected_filters.document_set)
else:
    # Slackなどの外部連携で、システムが事前に認可したセットへのアクセスのみ検証をパスする
    # 個々のドキュメントに対する Vespa レベルの ACL フィルタ（bypass_acl=False）は維持される
    pass

この修正により、Slack連携の機能復旧を果たしつつ、一般ユーザーがSlack経由で他人の極秘ファイルを引き出すセキュリティリークを確実に防止した。

5. 結論 ​

システムが複雑化し、認証やアクセス制御のレイヤーが多重化するにつれ、「チェックが厳しすぎて他の連携が動かない」という衝突は必ず発生する。 この際、「とりあえず動かす」ために bypass_acl や root などの大雑把な特権モード（粗いバイパス）を安易に適用することは、多層防御を一撃で無効化する最も危険な手段である。 セキュリティ設計者は、バイパスが必要な理由を詳細に分解し、「その目的（この場合はドキュメントセット所有権のチェック回避）だけを満たし、個々のリソース制限（ACL）は1ミリも緩和しない」 という 「最小特権のバイパス（Fine-grained Bypass）」 を徹底的に設計しなければならない。

6. 参考文献 / 一次情報 ​

Shiori pointer-RAG automation experiment.

Copyright © 2026 masuda-masuo