Slide 1

Slide 1 text

FirestoreとSecurityまわり Firebase Summit 2018 報告会 @k2wanko

Slide 2

Slide 2 text

コキチーズ @k2wanko

Slide 3

Slide 3 text

Local Emulator

Slide 4

Slide 4 text

FirestoreとRealtime DBのLocal Emulatorが公開

Slide 5

Slide 5 text

Local Emulatorのメリット - テスト用のプロジェクトを用意しなくても大丈夫 - 同時にテストを走らせることができる - セキュリティルールの問題を詳細に見ることができる。

Slide 6

Slide 6 text

詳しくはブログ記事で - 試したブログ書いたので気になる人はチェックしてください https://link.medium.com/X0nsVA36OR

Slide 7

Slide 7 text

Five tips to secure your app https://www.youtube.com/watch?v=pvLkkLjHdkw

Slide 8

Slide 8 text

一般的なサーバーのあるアプリケーションの場合 - 認証 - セキュリティパッチ - OS、言語のアップデート - 監査、アビューズ、などなど アプリケーション以外にも気をつけることが多い Firebaseを使えばアプリケーションに集中することができる

Slide 9

Slide 9 text

Tip #0 Don’t trust your client - クライアントを信用しないでください - Webでは簡単にapiKeyなどデータベースにアクセスする情報が取得できる モバイルでも変わらない

Slide 10

Slide 10 text

Tip #1: Okay, you can trust auth - 認証情報を信用してください - クライアントからのリクエストを単純に信じてはいけない - Firebase Authの仕組みを利用して認証する - プロバイダー認証の場合、名前、メールアドレスなど取得できるが 信じるべきはアクセストークン - アクセストークンを正しく検証した内容は信じることができる - アクセストークンはJWTが使われている https://jwt.io

Slide 11

Slide 11 text

Tips #2-5: Use Security Rules - セキュリティルールを使いましょう - セキュリティルールはデータベースとストレージのためのものです。 - アクセスコントロールを提供できる - Attribute Based Access Control (ABAC) - Role Based Access Control (RBAC)

Slide 12

Slide 12 text

Tip #2: Authorize your users - ABACでのアクセスコントロール - 例ではプロジェクトが公開されている非公開かで閲覧を制限したり - メンバーかそうでないかで書き込み権限があったりなかったりといった内容 - RBACでのアクセスコントロール - ユーザーのロールに応じてできる操作をコントロールする - https://firebase.google.com/docs/firestore/solutions/role-based-access - FirestoreとStorageのセキュリティルールでは関数を作って ルールをまとめることができる

Slide 13

Slide 13 text

Tip #3: Validate your schema - データのスキーマーの検証をしよう - 必須のフィールドやオプショナルなフィールド - データの型チェック - データサイズなど - セキュリティルールで検証できる - https://github.com/FirebaseExtended/protobuf-rules-gen - protocol bufferのスキーマーからセキュリティルールのスキーマーを生成するツール

Slide 14

Slide 14 text

Tip #4: Implement business logic checks - ビジネスロジックの実装をチェックしよう - 例では誰が編集できるかの検証について - 動画でより詳しい解説がある https://www.youtube.com/watch?v=oFlHzF5U-HA

Slide 15

Slide 15 text

Tip #5: But watch out for gotchas! - だけど、ちょっとしたことに気をつけて! - セキュリティルールはフィルターではない - データではなくクエリーを検証する - 複数の属性を持つコレクションがあったとき全てを取得しようとしても 非公開属性のドキュメントがあると全ての取得に失敗する - 公開されたデータだけを取得されるように クライアント側でクエリーを書く必要がある

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

Tip #7: Test Your Rules - セキュリティルールをテストしよう - ルールが正しいかどうかのテストは大事 - ルールをテストするには2つの方法がある

Slide 18

Slide 18 text

Simulator

Slide 19

Slide 19 text

Local Emulator

Slide 20

Slide 20 text

Tip #8: Consider Cloud Functions - Cloud Function を使うことを検討する - 複雑すぎるゲームのロジックなどのセキュリティルールを書くのは大変 - そういった場合はFirestoreに操作をQueueとして保存して チェックはCloud Functionsで行うようにする。 - Admin SDKからの書き込みはセキュリティルールをバイパスできる - JavaScriptなどプログラミング言語でチェックできるので書きやすい

Slide 21

Slide 21 text

Tip #9: Listen to the warnings - 警告を聞きましょう - 開発のためにセキュリティルールが安全ではない状態でそのまま リリースされることがある - Firebaseで検知した場合は様々な場所で警告が見える - コンソールのルール - アラート - メール - かなりのトラフィックが来るとメールが送られる、一旦アプリを停止し Firebaseのチームに問い合わせるといいらしい

Slide 22

Slide 22 text

Tip #10: Keep your employees on a short leash - いい訳がわからなかった - Firestoreコンソールでうっかりデータを削除してしまわないように アクセス権限を適切に設定しようということ

Slide 23

Slide 23 text

Five tips to secure your app のまとめ - Firebaseを利用すれば見るべきセキュリティの関心事を限定できる - アクセスコントロールの概念は大まかに2つ - Attribute Based Access Control (ABAC) - Role Based Access Control (RBAC) - 「権限」→「スキーマーチェック」→「ビジネスロジック」で検証 - セキュリティルールを書くのは大変だから便利なツールを使っていこう - Firebase的には https://github.com/FirebaseExtended/protobuf-rules-gen - 個人的には最高のソリューションはわからないけど protobufからの生成は筋がよさそう - セキュリティルールで表現が難しいことはサーバーサイドでやろう - FirestoreをQueueとして活用する - 適切なアクセス権で管理しよう - うっかり事故が起きて大変になったらFirebaseに相談しよう

Slide 24

Slide 24 text

How to go serverless in post-GDPR world https://www.youtube.com/watch?v=nhgWEXkbn4A

Slide 25

Slide 25 text

GDPRの施行 - 2018年5月25日 - EUの個人情報保護のためのルール - 位置情報やIPアドレスも個人情報に当たるという内容 - 罰則金は日本円で約26億円もしくは連結決算額の4%のどちらか高い方 - FirebaseとしてはEUに限らず世界中のユーザーのプライバシーを尊重すべき と考えている、デベロッパーもユーザーデータの保護を念頭に置いて欲しい

Slide 26

Slide 26 text

データを保存しない - プライバシーを守る上で一番簡単なのはデータを保存しないこと - 必要なデータだけを保存するようにする - 完全な誕生日を保存するのではなく、ユーザーが大人であるかどうかだけ - 住所も詳細なデータではなく国だけにするなど

Slide 27

Slide 27 text

https://friendly-pix.com/

Slide 28

Slide 28 text

No content

Slide 29

Slide 29 text

Friendly Pix - https://github.com/firebase/friendlypix-web - GDPRに対応したサービスのサンプル - データの削除はCloud Functionsで管理されている - 写真を削除したらコメントも削除される - 30日後に自動的にデータを削除する - ユーザーが削除されたら自動的に関連するデータを削除するようにしている -

Slide 30

Slide 30 text

セキュリティルールを書こう - シミュレーターを使って手動でテストも可能 - エミュレーターを使ってテストを書くこともできる

Slide 31

Slide 31 text

Storage Retention Policies - ユーザーのデータがどう管理されるかをユーザーに伝える - Firebaseではどうやって管理しているかを公開している https://firebase.google.com/support/privacy/ - 不明な点はサポートに問い合わせることができる - GCPのデータ削除についてのポリシー https://cloud.google.com/security/deletion/

Slide 32

Slide 32 text

Firebase Instance IDs - アプリに個別に割り当てられるID - Cloud Messagingではこれを使って端末を特定してメッセージを送れる - Instance IDは潜在的に個人を特定する - 必要ないものであればInstance IDを生成しないということもできる - Admin SDKからInstance IDを削除することもできるようになった https://firebase.google.com/support/privacy/manage-iids - 削除をリクエストしてもすぐに削除されるわけではなく クライアントでは1週間 サーバーでは2週間掛かる(バックアップやキャッシュのため) なのでユーザーに説明する必要がある

Slide 33

Slide 33 text

Storing Privacy Settings - ユーザーが公開したくないデータを選択できるようにする方法 - セキュリティルールで一ユーザーの専用スペースを作ることができる - プライバシー設定を変更できるようにする (ユーザーの気分が変わって保存したくなくなったときに プライバシーの設定を変更できるようにするのも大事)

Slide 34

Slide 34 text

Keeping an Activity Log - ユーザーのプライバシー関連の変更を記録する - 場合によってはユーザーのプライバシー設定の変更を記録する場合がある - Cloud Functionsを使ってLogを記録することができる - 細々した話はドキュメントを見るとよい https://firebase.google.com/support/privacy/storing-privacy-settings

Slide 35

Slide 35 text

How to go serverless in post-GDPR world のまとめ - GDPRの施行が始まったのが2018年5月25日 - 必要なデータだけ保存する - データを溜めるだけではなくデータの削除も設計する - 削除にはCloud Functionsを使って確実に削除を実行するのがよさそう (とくにユーザー削除の場合は) - セキュリティルールを書こう(←当たり前) - Firestore Emulatorの話もここであった。 - 今まで以上にユーザーのプライバシーを考える時代になった - Firebaseのチームとは弁護士のように相談はできない

Slide 36

Slide 36 text

Thank you @k2wanko