複数企業で使うSaaSのデータ分離｜組織IDの確認をどこに入れるか

1. 組織IDはリクエストのどこで確定するか

認証は利用者が誰かを確認する処理であり、認可はその利用者が対象に何をしてよいかを判断する処理です。たとえば同じ担当者が複数の組織に所属する場合、ログインできた事実だけでは今回操作する組織は決まりません。画面から送られた組織IDを選択値として受け取り、サーバー側で所属と必要な権限を照合してから、処理に使う組織情報を確定します。ヘッダーやURLに組織IDがあること自体は、認可の根拠にはなりません。[1][2]

本稿では、組織単位のリクエストを受ける共通処理で、利用者、選択組織、許可された操作をまとめて扱う設計を提案します。所属が確認できない場合や、組織の指定が必要なのに欠けている場合は、後続処理へ進めない方針です。たとえば組織切り替え後の画面が古いIDを送っても、直前の画面状態を信用せず再判定します。共通処理で確定した組織情報を、後段が未検証の入力で置き換えられない構造にすることも確認対象です。[1]

• 組織の選択値と、サーバーが認可した組織情報を区別しているか。
• 所属不明・権限不足・組織指定欠落の場合に処理を止めるか。

2. 一覧の取得条件をどこに集約するか

一覧画面では、検索条件に組織の絞り込みを入れ忘れる経路を減らすことが課題です。本稿では、組織所有のデータを扱う取得処理に、検証済みの組織情報を必須の入力として渡す案を提案します。たとえば問い合わせ一覧で状態や担当者を指定するときも、利用者が変更できる検索条件とは別に組織範囲を適用します。通常の組織向け処理から無条件の全件取得へ進めないことを、コードの呼び出し関係まで含めて確認します。[1]

一覧に付随する件数、集計、候補表示にも同じ取得範囲を適用する設計とします。本文が見えなくても、別組織の案件名が入力候補に出たり、絞り込み件数から登録状況が分かったりすれば、意図しない情報の露出になります。架空の組織甲と組織乙に異なる確認用データを置き、一覧だけでなくページ送り、並べ替え、空の検索条件でも確認する方法を提案します。組織IDという列の有無だけでなく、採用構成で境界が強制されるかを判断します。[1][2]

3. 詳細表示と更新で何を照合するか

詳細画面は、一覧から到達した場合だけでなく、URLやAPIに対象IDを直接指定した場合を考えます。対象IDを推測しにくくしても、それだけではアクセス権限の確認にはなりません。たとえば組織甲の利用者が組織乙の申請IDを送ったとき、対象の組織と許可された操作を照合して拒否する必要があります。表示ボタンを隠すだけではサーバー側の制御を置き換えられないため、直接呼び出す経路も確認対象にします。[1][2]

本稿では、参照、編集、削除、承認を別の操作として扱う案を提案します。同じ組織のデータでも、閲覧担当者に承認まで許可するとは限らないためです。また、本文の対象IDだけでなく、添付先や関連レコードのIDにも組織の整合性を確認します。拒否した際は、相手組織の名称やレコード内容をエラーに含めない方針とします。認可処理で例外が起きた場合も更新が実行されないことを確かめ、正常に拒否した場合と処理異常を記録上で区別します。[2]

• 他組織の対象IDを指定した参照・更新・削除を確認する。
• 同一組織内でも、役割に応じて操作の可否を分ける。

4. RAGでは生成前のどこに境界を置くか

本稿では、RAGの検索対象を、検証済みの組織と文書の閲覧権限に基づいて制限してから、生成に渡す案を提案します。「他社情報を回答しないで」とAIに指示するだけを分離の手段にはしません。たとえば社内規程への質問では、検索で取得した本文、候補の文書名、引用元の表示をそれぞれ対象に含めます。これは認可とテナント分離の原則をAI業務アプリへ適用する設計案であり、特定の検索製品がその制御を備えるという断定ではありません。[1][2]

取り込み時には、原本から分割した文章と検索用データの間で、所有組織や公開範囲の対応を維持する設計を提案します。全組織向け資料が必要なら、組織情報の欠落を共有扱いにせず、共有対象として明示します。確認では、別組織だけに置いた架空の語句を質問し、生成回答だけでなく検索候補と引用にも現れないかを見ます。文書の公開範囲を変更した場合には、古い検索用データや回答キャッシュが残る経路を洗い出し、更新方法を決めます。

5. 出力ファイルとキャッシュをどう扱うか

CSVや帳票の出力は、画面表示とは異なる処理を通ることがあります。本稿では、出力要求の受付、データ抽出、完成ファイルの受け渡しを別々の確認点にする案を提案します。たとえば個人情報を含む相談履歴を出力する場合、受付時に権限があっても、完成後に誰でも取得できる保存先では目的を満たしません。保存先の名前に組織IDを含めるだけでなく、ダウンロードする対象と操作を認可し、署名付きURLを使う場合も発行前に確認します。[1]

共有キャッシュを使う場合は、同じ検索条件でも組織が違えば結果を分ける必要があるかを点検します。本稿では、回答履歴、一覧の件数、出力の進捗など、保存する値ごとに利用範囲を分類する案を提案します。たとえば「未処理」という条件だけをキーにせず、組織や必要な権限差を識別できる構成を検討します。出力ファイルの保管期限、削除対象、バックアップや複製側の扱いも決め、現行ファイルの削除だけで全て消えたとは判断しない運用にします。[1]

6. API・Webhook・再実行に組織情報をどう渡すか

APIでは、人のログインとは別に、呼び出すサービスの資格情報がどの組織で何を実行できるかを確認します。Webhookの本文に組織IDが書かれていても、それだけで処理先を決めません。送信元の検証結果と、事前に許可した連携範囲を照合する必要があります。たとえば組織甲向けの連携資格情報で組織乙の案件更新を要求した場合、本文の指定に従わず拒否する設計とします。内部サービスからの呼び出しも、認可を省く理由にはしません。[1]

非同期処理では、検証した組織情報を信頼できる経路でジョブへ引き継ぎ、実行側でも対象と操作を確認します。受付から実行まで時間が空き、所属や権限の変更が影響する場合には、実行時の再確認が必要です。再実行については、失敗した処理の組織範囲を保つことに加え、重複防止キーや再試行状態を組織ごとに区別すべきかを検討します。全組織向け処理が必要なら、通常の組織処理に混ぜず、明示的な実行主体と範囲を定めます。[1]

7. 公開前に使うデータ分離の確認表

本稿では、架空の組織甲・組織乙と、役割の異なる確認用アカウントを用意し、許可される操作と拒否される操作を対にして確認する方法を提案します。片方の組織でしか見つからない確認用データを使うと、混在を判別しやすくなります。表は実施結果ではなく確認項目のひな型です。各項目に実施日、実行した版、結果、証跡の保存先を追記し、未実施や結果不明を合格として扱わない運用にします。単体テストと結合テストを組み合わせる考え方は資料にも示されています。[2]

• 実在する顧客情報や個人情報ではなく、識別可能な架空データを使う。
• 期待結果と実測結果を分け、不具合修正後は関連する経路も再確認する。

8. 公開後に境界を維持するために何を残すか

公開後に検索方式や連携先が増える場合、既存画面が正しく動くことだけでは、新しい経路の分離を確認したことにはなりません。本稿では、追加した機能が扱うデータ、実行主体、組織範囲、保存先を変更レビューの項目にする案を提案します。たとえば生成履歴を集計する管理機能では、組織内の管理者向けか、明示的に許可した横断運用向けかを先に決めます。通常経路の絞り込みを外して代用せず、横断経路の権限と監査を独立させます。[1]

保守への引継ぎでは、認可ルールの所在、拒否時の挙動、確認用データの作り方、再確認が必要な変更を残します。記録には実行主体、組織、操作、判定結果など調査に必要な情報を検討し、質問本文や個人情報を無条件に保存しない方針とします。拒否が増えた場合も、操作ミスと不具合を切り分ける材料として扱い、記録だけから原因を断定しません。ログ自体の閲覧権限も決め、確認表と自動テストを更新して次のリリース判断につなげます。[1][2]

よくある質問

認可の設計担当者が不在なら、実装担当者だけで公開を決めてよいですか。

本稿では、誰が対象範囲と例外を承認するかが決まるまで、影響する機能の公開を保留する案を提案します。代行者を置く場合は、承認できる範囲と判断記録を明確にします。画面が動くという確認を、組織間アクセスの要件承認の代わりにはしません。

複数組織を作れる確認環境がまだない場合はどうしますか。

一組織だけの確認では、組織間の混在がないとは判断できません。本稿では、本番の個人情報をコピーせず、架空の複数組織を用意できる環境を先に整える案を提案します。準備できない経路は未確認として残し、その経路を公開対象から外すかを判断します。

期間限定で、別組織の資料を共同利用したい場合はどう設計しますか。

本稿では、通常の所属を偽装したり組織条件を外したりせず、共有する資料、利用者、操作、期限を明示した例外として扱う案を提案します。期限後の取得可否と、既に作られた出力や回答履歴の扱いも決めます。例外終了の責任者を置き、恒久化を防ぎます。

一時休職中の利用者のデータを、別の担当者へ渡してよいですか。

休職という状態だけで、別組織への共有を許可する設計にはしません。本稿では、業務を引き継ぐ対象と必要な操作を確定し、承認された範囲で権限を設定する案を提案します。本人の資格情報を共用する方法ではなく、引継ぎ先自身の実行主体を記録できる方法を選びます。

参考・関連資料

• [1] Multi Tenant Security - OWASP Cheat Sheet Series ↗
• [2] Authorization - OWASP Cheat Sheet Series ↗

公式資料の確認日：2026-10-20。業務例は説明用で、顧客の実績ではありません。編集：株式会社N2i。執筆にAI支援を使用し、別のAIによる出典・品質確認に合格した記事を公開する方針です。