他社データと混ざらない構造とは？フォーム管理SaaS「inqbox」の安全性へのアプローチ

Web サイトに置くお問い合わせフォームやアンケートフォームには、氏名や連絡先などの個人情報に加え、具体的な要望や相談といった機密性の高い情報が集まります。こうしたデータを扱う外部 SaaS を導入するとき、企業のセキュリティ担当者や事業責任者が確かめるのが「自社のデータが他社のデータからきちんと隔離されているか」です。自社宛ての問い合わせを他社が見られたり、他社のデータと混ざったりする事故は許されません。そのため SaaS を選ぶ際は、通信の暗号化に加えて、システムの内部でテナント（契約企業）ごとのデータをどう分けているか、その設計が妥当かどうかも評価の対象になります。

問い合わせデータに求められるセキュリティ要件

SaaS 型のフォーム管理システムでは、送信された問い合わせ本文や顧客の連絡先がサービス側のデータベースにたまっていきます。一般的な SaaS では、複数の企業のデータを 1 つのデータベースに同居させる構成がよく取られます。この構成で事業者が心配するのは、ソフトウェアの不具合や設定ミスでテナントの境界が破られ、他社のデータが混ざったり外に漏れたりすることです。安全性を確かめる立場からは、「他社のデータから切り離されている」と言える具体的な根拠が求められます。

「組織」と「フォーム」の関係

パーティーハード株式会社が開発・提供するフォーム管理 SaaS「inqbox」では、データを「組織」と「フォーム」の 2 階層で管理しています。組織とフォームは 1 対多の関係で、契約企業ごとに組織を 1 つ作り、その下に用途別のフォームを必要な数だけ作れます。

この構造なら、部署やプロジェクトごとにフォームを分けつつ、全体をまとめて管理できます。たとえば採用窓口のフォームと営業問い合わせのフォームを別々に運用しながら、メンバーの管理は組織単位で一括して行えます。設定や契約プランも組織に集約されるので、フォームごとに管理者がばらばらになって統制が取れなくなる事態を防げます。

組織ごとに独立したデータベース

inqbox では、データを分ける境界をフォームではなく組織に置いています。

フォームを境界にすると、フォームを追加するたびに分離の設定が必要になり、設定漏れから意図しない公開や漏洩が起きるおそれが増えます。組織を境界に固定しておけば、新しく作ったフォームとそこに届く問い合わせは、自動的に親の組織の内側に入ります。運用の手間を増やさずに安全性を保てます。

分け方には、1 つのデータベースを全組織で共有してレコードごとに組織 ID で区別する「論理分離」もあります。inqbox はそれより一歩進めて、組織ごとに専用のデータベースを用意しています。問い合わせの本文、自動判定の結果、社内コメントといった業務データは、その組織専用のデータベースにだけ保存されます。

接続の面でも分離しています。各組織のデータベースには、そのデータベースへの読み書き権限だけを持つ個別の接続資格情報を割り当てています。アプリケーション全体ですべての組織のデータを横断して参照できる共通のアカウントは保持していません。1 回の接続で参照できるのは該当組織のデータベースに限られるため、クエリの不具合でテーブル結合などを誤ったとしても、同一のクエリ結果に他社の問い合わせデータが混入することはありません。

一方で、組織やフォームの設定、メンバー情報は、全社的なユーザー認証やルーティング処理を効率よく行うため、サービス全体の管理用データベースで一元管理しています。この管理用データベースでは、フレームワークのグローバルスコープ機能を用いて、組織 ID による絞り込み条件をすべてのクエリへ自動的に適用することで、他組織のメタデータへの意図しないアクセスを防いでいます。

組織内の権限とテナント分離の違い

区別しておきたいのが、組織内でメンバーの操作を制限する「権限管理」と、他の組織のデータへのアクセスを遮る「テナント分離」です。inqbox では、組織の設定やフォームの追加といった操作をオーナーに限定しています。

この権限管理は、接続先のデータベースを決定するテナント分離ロジックとは独立した層で判定されます。そのため、ロールや権限の割り当て設定を誤った場合でも、影響はその組織の操作範囲内にとどまり、他の組織へデータが漏洩するリスクを低減できます。

組織の誤判定を防ぐサーバー側の実装ルール

データベース自体を物理的に分けていても、リクエストを処理する際に「いまどの組織として操作しているのか」の判定を誤れば、別の組織のデータベースへ接続してしまう危険があります。そこで inqbox では、接続先を特定する処理において次のルールをサーバー側の設計で徹底しています。

• 操作対象の組織は、ログイン中のセッションとメンバー登録から毎回サーバー側で判定します。組織 ID をリクエストの値から受け取ることはしません。
• 組織を判定できない場合は、別の組織に切り替えて処理を続けず、エラーにします。
• フォームの指定は、その組織に属するフォームの中からだけ探します。他の組織のフォーム ID を指定しても、存在しないフォームと同じ扱いになります。
• メンバーから外されたユーザーは、次の操作から即座にアクセスできなくなります。

こうした堅牢なセッション検証や境界設計の背景には、受託開発で培った経験があります。パーティーハード株式会社は、PHP の Laravel や Symfony を使ったバックエンド開発、Nextjs や Vue によるフロントエンド開発を数多く手がけてきました。受託開発の現場で求められるセキュリティ要件や、Web API での認証・セッション検証の知見は、inqbox の設計にもそのまま生かしています。

安全なデータ基盤で日々の問い合わせ対応を支える

組織を単位にデータを分ける設計は、複数のフォームを柔軟に運用できる拡張性と、厳格なデータ保護を両立させる土台になります。組織内の権限管理とテナント分離の役割を分けたうえで、問い合わせデータそのものを組織ごとのデータベースに分けることで、実装ミスがあっても他社のデータと混ざりにくい構造にしています。パーティーハード株式会社は、こうした設計と運用の知見を生かし、企業が安心して問い合わせ対応を任せられる環境を提供していきます。