【Firebase】Firestoreを使うべきでセキュリティに注意が必要であることを学んだ話

投稿日:

プログラミング初心者の勉強ブログ #119

FirebaseのDBは2種類あるが、Firestoreを使うべきだということと、DBのreadとwriteのセキュリティには気をつけなければならない話。プラスアルファ、従量課金制のプランで使用を検討する場合はやみくもにDBとの処理を発生させないような注意が必要的な話も。しっかり理解しておかないと痛い目に合いそうだなと感じたのでそこらへんをまとめる。

 

目次

 

「Realtime Database」と「Cloud Firestore」

firebaseコンソール

上のスクショはFirebaseのコンソール画面。左のメニューよりDatabaseをクリックすると、

database画面

このように「Realtime Database」と「Cloud Firestore」という2種類のDBが存在する。この説明だけでは違いがよくわからなかったのでいろいろ調べた。

【Firebase】リアルタイム更新されるチャットアプリを作成してFirebaseを学ぶ(Aauthログインも)

前回の記事では、ちょっとしたアプリを試しに作ってみたが、そのときは「Realtime Database」を使用した。たまたま最初に参考にした検索ヒットでみた記事がRealtime Databaseの実装手順だったため、よくわからないけどとりあえずこっちを使った感じだ。

しかし、いろいろ見ていくうちに、どうやらRealtime Databaseよりも「Cloud Firestore」を使うべきだということがわかった。

Firebase Cloud Firestore

2019年1月31日、Cloud Firestoreは正式にベータ版から除外され、Firebaseラインナップの公式製品となりました。これはFirebaseのオリジナルデータベースシステムであるRealtime Databaseの後継であり、Realtime Databaseで提供されているツリービューではなく、ネストされたドキュメントとフィールドを考慮に入れています。

https://en.wikipedia.org/wiki/Firebase

「コレクション」と「ドキュメント」をネストしていくことでJSONの構造でデータを保存する仕組みであり、サブコレクション内に「フィールド」と呼ばれるデータを保存していく。サブコレクションが「テーブル」、フィールドが「カラムと値」みたいなイメージ。

2019年1月31日にベータ版から公式製品に格上げされたらしく、その点からも今後はFirestoreを使うべきだということが伺える。Realtime Databaseじゃないとリアルタイム更新ができないんじゃないかと、最初名前的に思ったが、Firestoreでもリアルタイム更新できたので、使うならFirestoreだと考える。

 

セキュリティには気をつける

知っておいて損はない、Firebaseのセキュリティルールのこと - ログミーTech

「Firebaseの脆弱性で1億件超漏洩」の真相とは? #Firebase #FJUG - Qiita

Firebase利用企業の62%が、データベースのセキュリティルールに問題があり、機密情報(ユーザートークンやメールアドレス)などが公開されていたというニュースについての記事。本家のニュースは2018年6月19日付だったので割と最近。

Firebaseのセキュリティはコンソールの「ルール」設定のところから直接設定をかける。書き方も独特でそれ自体ちゃんと理解しておかないといけない。

 

Cloud Firestore セキュリティ ルールを使ってみる | Firebase

本家のガイドを見るのが確実でわかりやすいが、企業の62%がセキュリティルールをしっかり設定していなかったとか言われたら、個人での管理に自信を持てない。62%はかなりビビる、Firebaseに魅力を感じつつあったが、少し使うのに抵抗がでた。もう少し待つべきなのかもしれない。

 

むやみにDBに対してreadやwriteの処理をしない

こんな記事も見つけた。

Firebaseの設定を間違えて72時間で300万円以上請求されてしまったウェブサービス - GIGAZINE

なんかマイナスイメージがつくものが多い。

調査の結果、クラウドファンディングでサポートされた合計金額を表示するためのコードの設計が誤っていることが判明。通常であれば、「合計金額」として保存されているドキュメントを1回読み込めば良かったのですが、今回「全ての支払いデータを読み込んでクライアント上で合計する」という実装になってしまっていたとのこと。例えば下の画像では1666人が合計24万4875ドルサポートしているのですが、244876という数字を1回アクセスして読み出すのではなく、それぞれのサポート金額を1666回アクセスして読み出し、足し合わせて合計金額を表示してしまっていました。

DBに対するreadの繰り返し処理をクライアント側でしてしまったのが原因。まじで自分がやったと思ったら笑えない。Firebaseに限らず、AWSとかの従量課金制のサービスでサーバーレスな開発環境の構築を考える場合も、必ずリクエストのチェックに注意しなきゃいけないんだなと感じた。

 

まとめ

言うても実務でFirebaseを使っている会社はたくさんあるわけで、それだけ便利だと多くの人が思っているということでもある。推奨はRDBとFirebaseを使い分けてappを作ることらしい。別にデプロイをFirebaseでする必要性は無いわけで、がっつり何かしらのフレームワークでDB設けて作成したappのプラスアルファ的な立ち位置で使うのが現状のFirebaseのベストっぽい。

 

ここからは関係ない話。結局自分が何を作りたいのかがブレていると、どれを選択したらいいのかわからなくなってくる。僕の場合、いろいろとこだわりや好みはあるもの肝心な部分がNullで何も無いんじゃないかと最近思う。僕はフロントも好きだがサーバサイドも多分結構好きだ。AIや機械学習の仕組みを聞くとそっちにも興味が湧いてしまうし、vueもreactもnodeもswiftも機械学習もどれもやってみたいと思ってしまう。イケてるWebデザインのサイトも作れるようになりたい。このブレブレの思考は手段の目的化の傾向であり、明らかな脱線ラインであるにも関わらず、迷ってしまっている現実がある。ブレる。他人の価値が自分の中でも価値に転換される。そんなこんなしていると自分がやりたいと思っていたことが本当にやりたいことなのかがどんどん不明瞭になる。ましてや自分でサービスを作りたいと言う感情はどんどん薄れてしまう。あってほしいところに自分がない。

SNSで自己顕示欲に素直な人をみて自分はそうでありたく無いと思う感情こそ、自分が承認欲求に縛られている証拠であることをアドラーの本から学んだものの、結局それってどうすれば解決するんだという状態に陥っている。自分のために生きるのは人のために生きるより、違う意味で難しいことだと感じる。この世に宗教が存在する理由に近く、宗教でないにしても、会社での過労に耐えきれず自殺が起こってしまう原因の本質なんじゃないかなと考える。自分というものを他人の評価でしか測れなくなっているということなのかもしれない。今までの自分の体感でものを言わせてもらえば、芯から自分のために生きている人なんてまじで世の中のごく少数な気がする。誰しもが他人の目を意識し、他人の評価をもとに他を評価していると思っている。よっぽどの根拠を持って論破されない限りこの考え方は変わらないと思う。それだけ自分のために生きることは難しいことなんじゃないかなと思う最近であり、「なぜあなたはそんなにもそれがしたいの?」と聞かれたときの回答を導くことが困難を極めている僕の現状の心境を的確に描写し共感を得たいがゆえの文章である。世の中に多数存在する、自信満々に自分の信念を騙る成功者たちに懐疑の目を向け、それはあくまで結果を出すことができた人の特権なだけだと、そんな信念はそもそも存在しないと口を大にして言う人が居たら、その人に1000円くらいならお布施してもいいかもなと思う。

以上ありがとうございました。

-プログラミング学習
-, ,

Copyright© s u p ? , 2019 All Rights Reserved.