BubbleのPrivacy Rulesは、データを誰に見せ、誰に編集させるかを決める中心的な仕組みです。画面で非表示にするだけでは十分ではないため、データ型の設計と同時に考える必要があります。
01表示を隠すだけでは守れない
Bubbleでは、画面の要素を非表示にしても、データが利用者のブラウザーへ送られる可能性があります。Privacy Rulesは、データ型ごとに検索、閲覧、特定フィールドへのアクセスを制御します。顧客情報や社内の記録など公開しないデータには、最初からルールを設けます。
02役割ごとに許可を整理する
案件データなら、担当者は自分の案件だけを見られ、管理者は全件を見られ、未ログインの人は検索できない、というように整理します。「Everyone else」に広い権限が残っていないかも確認します。添付ファイルやAPIからのアクセスは別途点検し、画面で見えないことだけを安全の証拠にしません。
03公開前と変更後に試す
未ログイン、一般利用者、管理者など複数の立場で検索・表示・編集を試します。見えてはいけない一覧が取得できないか、直接URLへ進んでも情報が出ないかを確かめます。データ型や役割を追加したときも再点検が必要です。セキュリティ設定は公開前だけの作業ではありません。
04設計時に残しておく資料
データ型ごとに「未ログイン」「本人」「同じ組織の担当者」「管理者」が検索・閲覧・変更できる範囲を表にします。例外があれば、その根拠も残しましょう。画面だけを見て権限を判断すると、別の画面やAPIから同じデータへ到達できる可能性を見落とします。
ルールを変えるときは、許可したい操作だけでなく、禁止したい操作が引き続き拒否されるか確認します。とくに新しいデータ型、添付ファイル、外部連携を追加した後は、未ログインの状態でも試験することが重要です。
05具体例：顧客ポータルの「本人だけ見える」を試す
架空の顧客ポータルで、Data type「問い合わせ」に「申請者」というUser型のFieldがあるとします。まずDataタブのPrivacyで問い合わせを選び、「Current Userがこの問い合わせの申請者であるとき」に、本人が必要とする項目と検索を許可するルールを検討します。管理者には別の条件を用意します。Everyone elseには機密項目を許可しません。実際の式と許可項目はアプリのデータ構造に合わせて設定し、公式マニュアルのPrivacy画面で確認してください。
ここで大事なのは「本人の画面に他人の行が表示されない」だけを合格にしないことです。本人A、別人B、未ログインの3状態で、一覧検索、直接詳細ページ、添付ファイル、Data APIを使っている場合はAPIからの取得を試します。Aの1件だけが返ること、Bと未ログインには本文・連絡先が返らないことを確認します。管理者が全件を見られる設計でも、その権限を一般利用者へ誤って付けていないか試してください。
注意点として、Privacy Rulesの「閲覧を許可する」は、任意のWorkflowからの書き換えをすべて止める意味ではありません。更新処理の実行条件も別に点検します。画面内の非表示や条件付き表示は使い勝手の制御であり、データ保護の代わりにはなりません。
参考資料
内容は公開時点の公式資料をもとに構成しています。仕様は変更されることがあるため、導入時は最新の公式情報をご確認ください。