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

一般的なアプリでは、デベロッパーは認証、承認、データ検証を行い、さらにデベロッパーのビジネス ロジックを実装する、多数のサーバーを構築して維持する必要があります。Cloud Storage for Firebase を使用するアプリであれば、Firebase Authentication、および Cloud Storage の Firebase セキュリティ ルールを利用して、サーバーレスな認証、承認、データ検証を処理できます。

Cloud Storage と Storage セキュリティ ルールを使用すると、インフラストラクチャを管理したり、サーバー側の複雑な認証コードや承認コードを作成したりする必要がなくなるため、デベロッパーは優れたユーザー エクスペリエンスを構築することだけに集中できます。

概要

Storage セキュリティ ルールは、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;
}

Storage セキュリティ ルールについて詳しくは、ファイルの保護のセクションをご覧ください。

サンプルルール

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

デフォルト

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

公開

// Anyone can read or write to the bucket, even non-users of your app.
// Because it is shared with Google App Engine, this will also make
// files uploaded via GAE public.
service firebase.storage {
  match /b/{bucket}/o {
    match /{allPaths=**} {
      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>/path/to/file.txt"
    match /user/{userId}/{allPaths=**} {
      allow read, write: if request.auth.uid == userId;
    }
  }
}

非公開

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

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

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

アプリケーションを公開する前に、ルールを評価して、アプリケーションに必要な最大レベルのセキュリティを確保できていることをご確認ください。

ルールの編集

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

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

フィードバックを送信...

ご不明な点がありましたら、Google のサポートページをご覧ください。