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

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

不正なトラフィックを避ける

バックエンド サービスのモニタリングとアラートを設定する

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

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

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

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

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

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

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

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

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

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

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

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

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

API キーを理解する

Firebase サービスの API キーはシークレットではありません

Firebase は、アプリの Firebase プロジェクトを Firebase サービスに対して識別するためにのみ API キーを使用し、 Firebase Security Rulesを使用して行われるデータベースまたは Cloud Storage データへのアクセスを制御するためには使用しません。このため、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 FirestoreとRealtime Databaseについては、これらのガイドを参照してください。

認証

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

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

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

マネージド認証: OAuth 2.0 プロバイダーは最も安全です

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

電子メール パスワード認証: サインイン エンドポイントに厳しいクォータを設定して、ブルート フォース攻撃を防ぎます

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

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

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

匿名認証

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

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

電話を紛失したときにデータが必要な場合は、ユーザーを別のサインイン方法に変換します

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

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

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

例えば：

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を使用すると、ライブラリの更新によって引き起こされる動作など、異常な動作を監視してアラートを受け取ることができます。

クラウド機能の安全性

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

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

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

機密情報を暗号化する

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

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

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

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