Firestore with Security - Firebase Summit 2018 Report Day

Firebase Japan User GroupのFirebase Summit報告会のスライドです。
https://firebase-community.connpass.com/event/103193/

Transcript

1. FirestoreとSecurityまわり Firebase Summit 2018 報告会 @k2wanko
2. コキチーズ @k2wanko
3. Local Emulator
4. FirestoreとRealtime DBのLocal Emulatorが公開
5. Local Emulatorのメリット - テスト用のプロジェクトを用意しなくても大丈夫 - 同時にテストを走らせることができる - セキュリティルールの問題を詳細に見ることができる。
6. 詳しくはブログ記事で - 試したブログ書いたので気になる人はチェックしてください https://link.medium.com/X0nsVA36OR
7. Five tips to secure your app https://www.youtube.com/watch?v=pvLkkLjHdkw
8. 一般的なサーバーのあるアプリケーションの場合 - 認証 - セキュリティパッチ - OS、言語のアップデート - 監査、アビューズ、などなど アプリケーション以外にも気をつけることが多い Firebaseを使えばアプリケーションに集中することができる
9. Tip #0 Don’t trust your client - クライアントを信用しないでください - Webでは簡単にapiKeyなどデータベースにアクセスする情報が取得できる モバイルでも変わらない
10. Tip #1: Okay, you can trust auth - 認証情報を信用してください - クライアントからのリクエストを単純に信じてはいけない - Firebase Authの仕組みを利用して認証する - プロバイダー認証の場合、名前、メールアドレスなど取得できるが 信じるべきはアクセストークン - アクセストークンを正しく検証した内容は信じることができる - アクセストークンはJWTが使われている https://jwt.io
11. Tips #2-5: Use Security Rules - セキュリティルールを使いましょう - セキュリティルールはデータベースとストレージのためのものです。 - アクセスコントロールを提供できる - Attribute Based Access Control (ABAC) - Role Based Access Control (RBAC)
12. Tip #2: Authorize your users - ABACでのアクセスコントロール - 例ではプロジェクトが公開されている非公開かで閲覧を制限したり - メンバーかそうでないかで書き込み権限があったりなかったりといった内容 - RBACでのアクセスコントロール - ユーザーのロールに応じてできる操作をコントロールする - https://firebase.google.com/docs/firestore/solutions/role-based-access - FirestoreとStorageのセキュリティルールでは関数を作って ルールをまとめることができる
13. Tip #3: Validate your schema - データのスキーマーの検証をしよう - 必須のフィールドやオプショナルなフィールド - データの型チェック - データサイズなど - セキュリティルールで検証できる - https://github.com/FirebaseExtended/protobuf-rules-gen - protocol bufferのスキーマーからセキュリティルールのスキーマーを生成するツール
14. Tip #4: Implement business logic checks - ビジネスロジックの実装をチェックしよう - 例では誰が編集できるかの検証について - 動画でより詳しい解説がある https://www.youtube.com/watch?v=oFlHzF5U-HA
15. Tip #5: But watch out for gotchas! - だけど、ちょっとしたことに気をつけて！ - セキュリティルールはフィルターではない - データではなくクエリーを検証する - 複数の属性を持つコレクションがあったとき全てを取得しようとしても 非公開属性のドキュメントがあると全ての取得に失敗する - 公開されたデータだけを取得されるように クライアント側でクエリーを書く必要がある
16. Tip #6: Custom Auth Claims are Useful! - カスタム認証のクレームは便利 - カスタム認証のクレームに変数をセットすることでそれを セキュリティルールで利用できる。 - セキュリティルールの記述が簡単になる - https://firebase.google.com/docs/auth/admin/create-custom-tokens - カスタム認証は便利で全てそれでやればいいとというわけではない - 1000bytesのサイズ制限 - トークンがアップデートされるまで権限の更新を待つ必要がある。 - https://www.youtube.com/watch?v=3hj_r_N0qMs
17. Tip #7: Test Your Rules - セキュリティルールをテストしよう - ルールが正しいかどうかのテストは大事 - ルールをテストするには２つの方法がある
18. Simulator
19. Local Emulator
20. Tip #8: Consider Cloud Functions - Cloud Function を使うことを検討する - 複雑すぎるゲームのロジックなどのセキュリティルールを書くのは大変 - そういった場合はFirestoreに操作をQueueとして保存して チェックはCloud Functionsで行うようにする。 - Admin SDKからの書き込みはセキュリティルールをバイパスできる - JavaScriptなどプログラミング言語でチェックできるので書きやすい
21. Tip #9: Listen to the warnings - 警告を聞きましょう - 開発のためにセキュリティルールが安全ではない状態でそのまま リリースされることがある - Firebaseで検知した場合は様々な場所で警告が見える - コンソールのルール - アラート - メール - かなりのトラフィックが来るとメールが送られる、一旦アプリを停止し Firebaseのチームに問い合わせるといいらしい
22. Tip #10: Keep your employees on a short leash - いい訳がわからなかった - Firestoreコンソールでうっかりデータを削除してしまわないように アクセス権限を適切に設定しようということ
23. Five tips to secure your app のまとめ - Firebaseを利用すれば見るべきセキュリティの関心事を限定できる - アクセスコントロールの概念は大まかに２つ - Attribute Based Access Control (ABAC) - Role Based Access Control (RBAC) - 「権限」→「スキーマーチェック」→「ビジネスロジック」で検証 - セキュリティルールを書くのは大変だから便利なツールを使っていこう - Firebase的には https://github.com/FirebaseExtended/protobuf-rules-gen - 個人的には最高のソリューションはわからないけど protobufからの生成は筋がよさそう - セキュリティルールで表現が難しいことはサーバーサイドでやろう - FirestoreをQueueとして活用する - 適切なアクセス権で管理しよう - うっかり事故が起きて大変になったらFirebaseに相談しよう
24. How to go serverless in post-GDPR world https://www.youtube.com/watch?v=nhgWEXkbn4A
25. GDPRの施行 - 2018年5月25日 - EUの個人情報保護のためのルール - 位置情報やIPアドレスも個人情報に当たるという内容 - 罰則金は日本円で約２６億円もしくは連結決算額の４％のどちらか高い方 - FirebaseとしてはEUに限らず世界中のユーザーのプライバシーを尊重すべき と考えている、デベロッパーもユーザーデータの保護を念頭に置いて欲しい
26. データを保存しない - プライバシーを守る上で一番簡単なのはデータを保存しないこと - 必要なデータだけを保存するようにする - 完全な誕生日を保存するのではなく、ユーザーが大人であるかどうかだけ - 住所も詳細なデータではなく国だけにするなど
27. https://friendly-pix.com/
29. Friendly Pix - https://github.com/firebase/friendlypix-web - GDPRに対応したサービスのサンプル - データの削除はCloud Functionsで管理されている - 写真を削除したらコメントも削除される - ３０日後に自動的にデータを削除する - ユーザーが削除されたら自動的に関連するデータを削除するようにしている -
30. セキュリティルールを書こう - シミュレーターを使って手動でテストも可能 - エミュレーターを使ってテストを書くこともできる
31. Storage Retention Policies - ユーザーのデータがどう管理されるかをユーザーに伝える - Firebaseではどうやって管理しているかを公開している https://firebase.google.com/support/privacy/ - 不明な点はサポートに問い合わせることができる - GCPのデータ削除についてのポリシー https://cloud.google.com/security/deletion/
32. Firebase Instance IDs - アプリに個別に割り当てられるID - Cloud Messagingではこれを使って端末を特定してメッセージを送れる - Instance IDは潜在的に個人を特定する - 必要ないものであればInstance IDを生成しないということもできる - Admin SDKからInstance IDを削除することもできるようになった https://firebase.google.com/support/privacy/manage-iids - 削除をリクエストしてもすぐに削除されるわけではなく クライアントでは１週間 サーバーでは２週間掛かる（バックアップやキャッシュのため） なのでユーザーに説明する必要がある
33. Storing Privacy Settings - ユーザーが公開したくないデータを選択できるようにする方法 - セキュリティルールで一ユーザーの専用スペースを作ることができる - プライバシー設定を変更できるようにする （ユーザーの気分が変わって保存したくなくなったときに プライバシーの設定を変更できるようにするのも大事）
34. Keeping an Activity Log - ユーザーのプライバシー関連の変更を記録する - 場合によってはユーザーのプライバシー設定の変更を記録する場合がある - Cloud Functionsを使ってLogを記録することができる - 細々した話はドキュメントを見るとよい https://firebase.google.com/support/privacy/storing-privacy-settings
35. How to go serverless in post-GDPR world のまとめ - GDPRの施行が始まったのが2018年5月25日 - 必要なデータだけ保存する - データを溜めるだけではなくデータの削除も設計する - 削除にはCloud Functionsを使って確実に削除を実行するのがよさそう （とくにユーザー削除の場合は） - セキュリティルールを書こう（←当たり前） - Firestore Emulatorの話もここであった。 - 今まで以上にユーザーのプライバシーを考える時代になった - Firebaseのチームとは弁護士のように相談はできない
36. Thank you @k2wanko