こんにちは。ファンリピートの鳴海です。
プライバシールール設計指針について説明したいと思います。
プライバシールールとは?
データの表示を設定した条件で制限できる機能になります。
データベースの役割
データベースはサーバー上でホストされ、アプリケーションのデータが保存されます。
プライバシールールでは、特定の条件が満たされた場合にのみデータをブラウザに送信するかデータベースに書き込むようにサーバーに指示するルールになります。
プライバシー ルールの定義
ルールはユーザーのアクセス権を検証してからデータを提供するため、不正アクセスを防ぎます。
たとえば、あるSNSアプリではユーザーの情報はログインしているユーザーに限るような設定を行うことができます。
セキュリティの重要性
アプリケーションのデータ保護は、ユーザーの信頼を得るために不可欠です。プライバシー ルールは、サイバー攻撃やデータ漏洩のリスクに対する予防措置として機能し、ユーザーデータの安全性を守ります。
たとえば、銀行アプリケーションでは、顧客の財務情報が外部に漏れないように、厳格なプライバシー ルールを設けることが求められます。
プライバシールールの種類
Bubble.ioは主に2種類のプライバシールールを提供しています。
- フィールドレベルのルール (Field-level Rules)
- Role-based Rules
フィールドレベルのルール (Field-level Rules)
概要
これらのルールでは、個々のデータフィールドへのアクセスレベルを細かく設定できます。各フィールドに対して、特定のユーザーが閲覧や編集を行えるかどうかを制御します。
例
ユーザーのプロフィール情報に関するデータベースがあるとします。フィールドレベルのルールを使用して、「電話番号」フィールドはユーザー本人のみが閲覧でき、「生年月日」は管理者とユーザー本人のみが閲覧できるように設定することができます。
Role-based Rules
概要
ユーザーのロールやグループに基づいてアクセス権を設定します。ユーザーの役割(例: 管理者、一般ユーザー、ゲストなど)に応じて、データへのアクセスを許可または制限します。
例
企業内の社内ネットワークに適用する場合、ロールベースのルールを使用して、「従業員」ロールのユーザーは全従業員の連絡先情報にアクセスできるが、「ゲスト」ロールのユーザーはその情報へのアクセスが制限される、といった設定が可能です。
プライバシールールの概要
名前 | 内容 |
---|---|
Define a New Rule | 「新規ルールの定義」ボタンで選択されたタイプの新しいルールを作成します。 タイプに明確な名前を付け、条件と権限を定義します。条件はこのルールが適用されるユーザーを定義し、権限は条件を満たした場合にユーザーがデータで何ができるかを定義します。 |
Name | ルールに名前を付けます。この入力で名前を変更します。 |
Delete🗑️ | このアイコンをクリックするとルールが削除されます。 この操作はデータを削除するのではなく、選択したタイプに対するルールだけを削除します。 |
When (Condition) | ユーザーがルールに含まれるかどうかをチェックする条件を定義します。 Composerを使用して、動的な式を部品ごとに作成します。 例えば、タイプ「イベント」の条件を「このイベントの作成者が現在のユーザーである」と定義した場合、そのタイプの「イベント」を作成したユーザーのみがそのルールに含まれます。 |
View All Fields | このボックスをチェックすると、条件を満たすユーザーは現在のタイプのものの全てのフィールドを見ることができます。 このボックスを非チェックにすると、このルールに含まれるユーザーに表示可能なフィールドを選択できます。 |
Find this in Searches | このボックスを非チェックにすると、このルールに含まれるユーザーはこのタイプの検索結果を表示できなくなります。 |
View Attached Files | このボックスを非チェックにすると、ユーザーはこのタイプのものに添付されたファイルを見ることができません。 例えば、「アパートメント」を作成できるワークフローを設定し、そのアパートメントに写真があるとします。 写真アップローダーを設定して、写真をデータベースの実際のアパートメントにリンクします。その後、このボックスを非チェックにすると、条件が「このアパートメントの作成者が現在のユーザー限られるようになります。 |
Allow Auto-Binding | 入力内容をもののフィールドにバインドします。ユーザーが入力内容を変更すると、ものが自動的に更新されます。 入力要素に対して「親要素のものにオートバインドを有効にする」を参照してください。フィールドを変更するための権限をユーザーに許可する必要があります。 条件を満たすユーザーにこれを許可するためには、このボックスをチェックします。チェックしたら、オートバインドを通じて変更可能な異なるフィールドを選択します。 |
Modify via API | Data APIがこのタイプに対して有効になっている場合、この権限はユーザーにこのもののフィールドを任意に変更する権利を与えます。 変更が許可されるためには、この権限を支配するルールが変更前後の両方で真である必要があります。これにより、どのフィールドを変更できるかを制限することができます。 より細かいフィールドの制限が必要な場合は、この権限を付与する代わりにWorkflow APIを使用し、具体的に何が変更されるかを制御できます。 |
Delete via API | Data APIがこのタイプに対して有効になっている場合、この権限はユーザーにAPIを介してこのものを削除する権利を与えます。 |
Create via API | Data APIがこのタイプに対して有効になっている場合、この権限はユーザーにAPIを介して新しいものを作成する権利を与えます。 この権限を付与するルールがもののフィールドを参照している場合、ルールが適用されないものを作成しようとする試みは拒否されます。 |
ルールの設定方法
こちらでは主にBubbleのプライバシールールのドキュメントに記載がある内容で説明したいなと思います。
例:タスクの共有
タスク管理アプリがあり、タスクへのアクセスが次の2つの単純なルールに従っているとします。
- タスクの作成者は自分のタスクのみアクセスでき、他の作成者のタスクはアクセスできません。
- 作成者は他のユーザーを特定のタスクに招待した場合は、アクセスを許可することができます。
ユーザーが特定のタスクに招待されているかどうかを判断する方法が必要になるため、タスクに招待されたすべてのユーザーのリストを含む新しいカスタムフィールドをタスクデータ型に追加することで解決できます。
誰かにタスクへの許可を許可したい場合は、ワークフローを使用してそのユーザーをリストに追加します。
ここで、プライバシールールを設定するには、3つのルールが必要になります。
- タスクの作成者がアクセスできる
- 現在のユーザーが招待されたユーザーのリストに含まれている
- 他の人はアクセスできない
まとめ
今回はプライバシールールの設計指針について説明しました。
Bubble.ioでは、プライバシールールはアプリのセキュリティの不可欠な部分であり、個人データを保護するために使用されるので、これらのルールは、アプリのデータベースへの不正アクセスを防ぐためのセキュアなフィルターとして機能します。