Google は、黒人コミュニティのための人種的公平の促進に取り組んでいます。詳細をご覧ください。

Firebase セキュリティ チェックリスト

Firebase リソースとユーザー データを安全に保つには、次のガイドラインに従ってください。すべての項目が必ずしも要件に当てはまるとは限りませんが、アプリを開発する際にはこれらの点に留意してください。

乱用的なトラフィックを避ける

バックエンドサービスの監視とアラートを設定する

サービス拒否 (DOS) 攻撃などの不正なトラフィックを検出するには、 Cloud FirestoreRealtime DatabaseCloud Storage 、およびHosting のモニタリングとアラートを設定します。

アプリケーションへの攻撃が疑われる場合は、できるだけ早くサポート連絡して、何が起こっているのかを知らせてください。

アプリチェックを有効にする

アプリのみがバックエンドサービスにアクセスできるようにするには、アプリをサポートするすべてのサービスでアプリチェックを有効にします。

通常のトラフィックに合わせてスケーリングするようにCloudFunctionsを構成します

Cloud Functions はアプリの要求に合わせて自動的にスケーリングしますが、攻撃が発生した場合、これは高額な費用を意味する可能性があります。これを防ぐために、アプリの通常のトラフィックに基づいて、関数の同時インスタンス数を制限できます。

制限に近づいたときに通知されるようにアラートを設定します

サービスにリクエストの急増がある場合、多くの場合、クォータが発生し、アプリケーションへのトラフィックが自動的に抑制されます。使用量と請求ダッシュボードを必ず監視してください。ただし、プロジェクトに予算アラート設定して、リソースの使用量が予想を超えたときに通知を受け取ることもできます。

自己DOSの防止:エミュレーターを使用してローカルで機能をテストします

たとえば、無限のトリガー書き込みループを作成するなどして、Cloud Functions の開発中に誤って自分自身で DOS を実行してしまう可能性があります。 Firebaseエミュレータスイートを使用して開発を行うことで、これらの間違いがライブサービスに影響を与えるのを防ぐことができます

(そして、自分で誤って DOS を実行してしまった場合は、 index.jsから削除して関数をアンデプロイしてから、 firebase deploy --only functions実行してください。)

リアルタイムの応答性がそれほど重要でない場合、構造は防御的に機能します

関数の結果をリアルタイムで表示する必要がない場合は、結果をバッチで処理することで、不正なトラフィックを軽減できます。結果をPub / Subトピックにパブリッシュし、スケジュールされた関数を使用して定期的に結果を処理します。

API キーを理解する

FirebaseサービスのAPIキーは秘密ではありません

FirebaseはAPIキーを使用して、Firebaseサービスに対するアプリのFirebaseプロジェクトを識別し、 Firebaseセキュリティルールを使用して行われるデータベースやクラウドストレージデータへのアクセスを制御しません。このため、FirebaseサービスのAPIキーをシークレットとして扱う必要はなく、クライアントコードに安全に埋め込むことができます。 Firebase の API キーの詳細をご覧ください。

APIキースコープを設定する

APIキーを使用してリクエストをスプーフィングしようとする攻撃者に対する追加の抑止力として、アプリクライアントを対象とするAPIキーを作成できます

FCMサーバーのキーを秘密にしておく

Firebase サービスの API キーとは異なり、FCM サーバー キー (従来の FCM HTTP API で使用)機密性高く、秘密にしておく必要があります。

サービス アカウント キーを秘密にする

また、Firebase サービスの API キーとは異なり、サービス アカウントの秘密鍵 ( Admin SDK で使用)機密性高く、秘密にしておく必要があります。

セキュリティルール

本番モードまたはロックモードでルールを初期化します

Cloud Firestore、Realtime Database、およびCloud Storageをセットアップするときは、セキュリティルールを初期化してデフォルトですべてのアクセスを拒否し、アプリの開発時に特定のリソースへのアクセスを許可するルールを追加します。

これは、Cloud Firestore (本番モード) と Realtime Database (ロック モード) の新しいインスタンスのデフォルト設定の 1 つです。新しいデータベース インスタンスを設定する場合は、このオプションを選択してください。

Cloud Storageの場合、次のようなセキュリティルールの構成から始めます。

rules_version = '2';
service firebase.storage {
  match /b/{bucket}/o {
    match /{allPaths=**} {
      allow read, write: if false;
    }
  }
}

セキュリティ ルールはスキーマです。ドキュメントを追加するときにルールを追加する

一種の起動前のタスクとして、アプリを作成した後にセキュリティ ルールを作成しないでください。代わりに、アプリを作成するときにセキュリティ ルールを作成し、データベース スキーマのように扱います。新しいドキュメント タイプまたはパス構造を使用する必要がある場合は、そのセキュリティ ルールを最初に作成します。

Emulator Suite を使用した単体テスト セキュリティ ルール。 CIに追加

セキュリティルールがアプリの開発に対応していることを確認するには、 Firebaseエミュレータスイートを使用してルールを単体テストし、これらのテストをCIパイプラインに追加します。 Cloud FirestoreRealtime Databaseについては、これらのガイドをご覧ください。

認証

カスタム認証:信頼できる(サーバー側の)環境からのミントJWT

カスタムシステムであろうとサードパーティサービスであろうと、安全なサインインシステムがすでにある場合は、既存のシステムを使用してFirebaseサービスで認証できます。信頼できる環境からカスタムJWT作成し、トークンをクライアントに渡します。クライアントはトークンを使用して認証します( iOSAndroidWebUnityC ++ )。

サードパーティ プロバイダーでカスタム認証を使用する例については、ブログ投稿「 Okta を使用して Firebase認証する」を参照してください。

管理された認証:OAuth2.0プロバイダーが最も安全です

Firebaseのマネージド認証機能を使用する場合、OAuth 2.0 / OpenID Connectプロバイダーオプション(Google、Facebookなど)が最も安全です。可能であれば、これらのプロバイダーの1つ以上をサポートする必要があります(ユーザーベースによって異なります)。

電子メール-パスワード認証:ブルートフォース攻撃を防ぐために、サインインエンドポイントに厳しい割り当てを設定します

Firebase のマネージド メール パスワード認証サービスを使用する場合は、 identitytoolkit.googleapis.comエンドポイントのデフォルト クォータを厳しくして、ブルート フォース攻撃を防ぎます。これは、Google CloudConsoleのAPIのページから行うことができます。

多要素認証のための Cloud Identity Platform へのアップグレード

サインイン時のセキュリティを強化するために、 Cloud Identity Platform にアップグレードすることで多要素認証のサポートを追加できます。既存の Firebase Authentication コードは、アップグレード後も引き続き機能します。

匿名認証

ウォーム オンボーディングには匿名認証のみを使用する

ユーザーが実際にサインインする前に、匿名認証のみを使用してユーザーの基本状態を保存します。匿名認証は、ユーザーサインインの代わりにはなりません。

スマートフォンを紛失したときにデータが必要な場合は、ユーザーを別のログイン方法に変換します

ユーザーがローカルストレージをクリアするか、デバイスを切り替えると、匿名認証データは保持されません。単一のデバイスでアプリを再起動した後もデータを保持する必要がある場合は、ユーザーを永続アカウントに変換します

ユーザーがサインイン プロバイダーに変換するか、メールを確認する必要があるセキュリティ ルールを使用する

誰でもプロジェクトに匿名アカウントを作成できます。そのことを念頭に置いて、特定のログイン方法または確認済みのメール アドレスを必要とするセキュリティ ルールを使用して、すべての非公開データを保護してください。

例えば:

allow write: if request.auth.token.firebase.sign_in_provider != "anonymous";
allow write: if request.auth.token.email_verified = true;

環境管理

開発およびステージングプロジェクトを設定する

開発、ステージング、本番用に個別の Firebase プロジェクトを設定します。ステージングプロジェクトに対してテストされるまで、クライアントコードを本番環境にマージしないでください。

チームの本番データへのアクセスを制限する

大規模なチームで作業する場合は、事前定義されたロールまたはカスタム IAM ロールのいずれかを使用して本番データへのアクセスを制限することで、ミスや違反の結果を軽減できます。

チームが開発にエミュレータスイートを使用している場合は、本番プロジェクトへのより広いアクセスを許可する必要がない場合があります。

図書館管理

ライブラリのスペルミスや新しいメンテナーに注意してください

プロジェクトにライブラリを追加するときは、ライブラリの名前とそのメンテナに細心の注意を払ってください。インストールしようとしているライブラリと同じ名前のライブラリに、悪意のあるコードが含まれている可能性があります。

変更を理解せずにライブラリを更新しないでください

アップグレードする前に、使用するライブラリの変更ログを調べてください。アップグレードが付加価値をもたらすことを確認し、メンテナがまだ信頼できる当事者であることを確認してください。

開発またはテストの依存関係としてウォッチドッグ ライブラリをインストールする

Snykなどのライブラリを使用して、プロジェクトの安全でない依存関係をスキャンします。

関数の監視を設定します。ライブラリの更新後に確認してください

Cloud Functions ロガー SDKを使用すると、ライブラリの更新によって引き起こされる動作など、異常な動作を監視してアラートを受け取ることができます。

クラウド機能の安全性

CloudFunctionの環境変数に機密情報を入れないでください

多くの場合、自己ホスト型のNode.jsアプリでは、環境変数を使用して秘密鍵などの機密情報を含めます。 Cloud Functions ではこれを行わないでください。 Cloud Functionsは関数の呼び出し間で環境を再利用するため、機密情報を環境に保存しないでください。

  • 秘密ではないFirebaseAPIキーを保存するには、コードに埋め込むだけです。
  • Cloud Function で Firebase Admin SDK を使用している場合、SDK は初期化中にサービス アカウントの認証情報を自動的に取得できるため、明示的にサービス アカウントの認証情報を提供する必要はありません。
  • サービス アカウントの資格情報を必要とする Google および Google Cloud API を呼び出す場合、Node.js の Google 認証ライブラリは、Cloud Functions に自動的に入力される アプリケーションのデフォルトの資格情報からこれらの資格情報を取得できます。
  • Google 以外のサービスの秘密鍵と認証情報を Cloud Functions で使用できるようにするには、 Cloud Secret Manager を使用します。

機密情報を暗号化する

機密情報をCloudFunctionに渡すことを避けられない場合は、情報を暗号化するための独自のカスタムソリューションを考え出す必要があります。

単純な関数の方が安全です。複雑さが必要な場合は、CloudRunを検討してください

Cloud Functions はできるだけシンプルで理解しやすいものにしてください。関数の複雑さは、多くの場合、見つけにくいバグや予期しない動作につながる可能性があります。

複雑なロジックまたは環境構成が必要な場合は、Cloud Functions の代わりに Cloud Run の使用を検討してください。