Cloud Storage セキュリティルールを使ってみる

一般的なアプリでは、デベロッパーは多くのサーバーを構築して維持し、認証、承認、データ検証を行い、デベロッパーのビジネスロジックを実施する必要があります。Cloud Storage for Firebase を使用するアプリは、Firebase Authentication と Cloud Storage 用の Firebase Security Rules を使用して、サーバーレス認証、承認、データ検証を処理します。

Cloud Storage と Cloud Storage Security Rules を使用すると、インフラストラクチャを管理したり、サーバーサイドの複雑な認証や認証コードを作成したりする必要がなくなるため、優れたユーザーエクスペリエンスを構築することだけに集中できます。

概要

Cloud Storage Security Rules は、Cloud Storage に格納されているファイルに対する読み取り権限と書き込み権限を持つユーザーを決定します。また、ファイルパスの構造やファイルに含まれるメタデータの評価も行います。基本のルールは allow ルールです。これは、オプションで指定されている条件を満たす場合に read オペレーションと write オペレーションを許可します。次に、ルールの例をいくつか示します。

// Rules can optionally specify a condition
allow write: if <condition>;

match を使用したルールは、Cloud Storage 参照で表すファイルパスと照合されます。ルールは、match を使用して 1 つ以上のファイルパスと照合できます。match を使用した複数のルールが特定の request 内のファイルパスと一致することもあります。

// Rules match specific paths
match /images/profilePhoto.png {
  allow write: if <condition>;
}

match /images/croppedProfilePhoto.png {
  allow write: if <other_condition>;
}

ルール評価のコンテキストも request オブジェクトと resource オブジェクトを使って示されます。これらのオブジェクトは、認証コンテキスト（request.auth）や既存のオブジェクトサイズ（resource.size）などの情報を提供します。

// Rules can specify conditions that consider the request context
match /images/profilePhoto.png {
  allow write: if request.auth != null && request.resource.size < 5 * 1024 * 1024;
}

Cloud Storage Security Rules について詳しくは、ファイルを保護するセクションをご覧ください。

サンプルルール

Cloud Storage Security Rules では、まず service（この例では firebase.storage）と、ルールの評価対象となる Cloud Storage バケット（match /b/{bucket}/o 経由）を指定する必要があります。デフォルトのルールには Firebase Authentication が必要ですが、ここでは別のアクセス制御を持つ他の一般的なルールの例を示します。

デフォルト

// Only authenticated users can read or write to the folder
service firebase.storage {
  match /b/{bucket}/o {
    match /someFolder/{fileName} {
      allow read, write: if request.auth != null;
    }
  }
}

公開

// Anyone can read or write to the folder, even non-users of your app.
// Because it is shared with App Engine, this will also make
// files uploaded via App Engine public.
service firebase.storage {
  match /b/{bucket}/o {
    match /someFolder/{fileName} {
      allow read, write;
    }
  }
}

ユーザー

// Grants a user access to a node matching their user ID
service firebase.storage {
  match /b/{bucket}/o {
    // Files look like: "user/<UID>/file.txt"
    match /user/{userId}/{fileName} {
      allow read, write: if request.auth != null && request.auth.uid == userId;
    }
  }
}

非公開

// Access to files through Cloud Storage for Firebase is completely disallowed.
// Files may still be accessible through App Engine or Google Cloud Storage APIs.
service firebase.storage {
  match /b/{bucket}/o {
    match /{allPaths=**} {
      allow read, write: if false;
    }
  }
}

開発期間は、デフォルトの代わりに公開ルールを使用して、ファイルを公開して読み取りと書き込みができるように設定できます。こうすると、Firebase Authentication を設定せずに使い始めることができるので、プロトタイプの場合は非常に便利です。ただし、Cloud Storage はデフォルトの App Engine アプリとバケットを共有するため、このルールによってアプリが使用するすべてのデータも公開されることになります。

ユーザールールでは、認証済みのユーザーにそれぞれ個人用ファイルストレージを提供することができます。非公開ルールを使用してファイルを完全にロックすることもできますが、その場合はユーザーが Cloud Storage でファイルの読み取りも書き込みもできなくなることにご注意ください。App Engine アプリまたは Google Cloud Storage API からファイルにアクセスするユーザーは、引き続きアクセスできます。

ルールの編集

Cloud Storage では、Firebase コンソールの [Storage] セクションにある [ルール] タブから Cloud Storage Security Rules を簡単に編集できます。[ルール] タブでは、現在のルールをすばやく簡単に表示して編集することができます。ルールは [公開] ボタンをクリックするか、ファイルに保存（ctrl/cmd + s）することによってデプロイします。ルールは即座に Cloud Storage サーバーにアップロードされますが、有効になるまでに最長 5 分程度かかることがあります。

Firebase CLI でもルールをデプロイできます。firebase init を実行するときに Storage を選択すると、デフォルトルールのコピーを含む storage.rules ファイルがプロジェクトディレクトリに作成されます。これらのルールは firebase deploy コマンドでデプロイできます。プロジェクトに複数のバケットがある場合、デプロイターゲットを使用すると、同じプロジェクトフォルダからすべてのバケットにルールを同時にデプロイできます。

ファイルベースのセキュリティの仕組みについては、ファイルを保護するのセクションをご覧ください。ユーザーベースのセキュリティについては、ユーザーベースのセキュリティのセクションをご覧ください。