役員・情シス・監査向け技術解説
宣言的アクセス制御による
多層防御アーキテクチャ
Firestore Security Rules の設計思想と適用範囲
短い = 弱い ではない。短い = 本質だけ である。
1行ルールのインパクト
クライアントSDK経由のアクセスを制御
allow read, write: if request.auth != null;allow read, write: if request.auth.uid == resource.data.userId;適用範囲について
Security RulesはクライアントSDK（Web、iOS、Android）からのアクセスに適用されます。 Admin SDK（サーバーサイド）はルールをバイパスする設計です。 これは意図された動作であり、サーバーサイドのセキュリティは別途対策が必要です。
なぜ「短い = 弱い」ではないのか
宣言的記述の設計思想
「セキュリティコードは複雑であるべき」
- ×コード行数が多いほど安全
- ×複雑なロジックで防御力が上がる
- ×セキュリティは専門家しか理解できない
「本質だけを記述し、基盤が強制」
- ✓短いからこそレビュー・監査が容易
- ✓宣言的記述で曖昧さがない
- ✓非エンジニアでも意図を理解可能
法律の条文は短いが、国全体を拘束する。
Firestoreセキュリティルールも同様。数行の宣言が、クライアントからの全データアクセスを強制的に制御する。
クライアントアプリのバグがあっても、DBが拒否する
多層防御の一つとして機能
クライアント
│
▼
アプリサーバー ←── ここにバグがあると...
│
▼
DB (RLS未実装) ←── 素通りで不正アクセス成立
問題: アプリ層の権限チェックのみに依存
クライアント
│
▼
クライアントSDK ←── ここにバグがあっても...
│
▼
Firestore ←──────── ルールが強制拒否
[Security Rules]
効果: DB層で追加の防御ラインを確保
| 技術 | 提供元 | 特徴 |
|---|---|---|
| Firestore Security Rules | クライアントSDK直接アクセスに最適化、宣言的記述 | |
| PostgreSQL RLS | PostgreSQL | 行レベルセキュリティ、SQL内で定義 |
| SQL Server RLS | Microsoft | 行レベルセキュリティ、述語ベース |
| Cosmos DB RBAC | Microsoft Azure | Azure AD統合、きめ細かいアクセス制御 |
※ DB層でのアクセス制御はFirestore固有ではなく、エンタープライズDBでは一般的な機能です。 Firestoreの特徴は、クライアントSDKからの直接アクセスを前提とした設計にあります。
役員・監査向け説明
「クライアントアプリケーションに脆弱性があっても、
データベース層で追加の防御ラインとして機能します。
これは多層防御（Defense in Depth）の考え方に基づいています。」
宣言的ルール = 仕様そのもの
コードが仕様書、仕様書がコード
// アプリケーションコード（Java/Python等）
public Document getProject(String projectId) {
User user = getCurrentUser(); // 認証取得
if (user == null) {
throw new AuthException(); // 認証チェック
}
Project project = db.get(projectId);
if (!project.orgId.equals(user.orgId)) {
throw new ForbiddenException(); // 権限チェック
}
if (user.role != "admin" && ...) {
// 複雑な条件分岐...
}
return project;
}- ・ビジネスロジックと権限ロジックが混在
- ・全エンドポイントに重複コード
- ・実装漏れのリスク
- ・監査には全コードレビューが必要
// firestore.rules
match /projects/{projectId} {
// 認証済み かつ 同じ組織のユーザーのみ
allow read: if request.auth != null &&
getUserOrg() == resource.data.orgId;
// 削除は管理者のみ
allow delete: if getRole() == 'admin';
}- クライアントアクセスの権限ルールが1ファイルに集約
- 「誰が何をできるか」が一目瞭然
- ルール=クライアントアクセスの仕様書
- ユニットテストで検証可能
「このルールファイルがクライアントアクセスの仕様書です。
権限設計の一部を監査人に論理的に説明できます。」
クライアントSDKからはバイパス不可
ただしAdmin SDKは設計上バイパスする
SQLインジェクション相当
→ クエリ言語が異なり、構造的に防御
認証情報の偽装
→ request.auth はFirebaseが検証済み
ルールの迂回
→ 構造的に不可能
クライアントSDK経由ではSecurity Rulesを必ず通過
Security Rules
→ 設計上バイパスする（意図された動作）
使用場所
→ Cloud Functions, Cloud Run等
セキュリティ
→ サーバーサイドで別途実装が必要
Admin SDKを使う場合は追加のセキュリティ対策が必須
Admin SDK使用時の注意
多くのエンタープライズアプリケーションでは、複雑なビジネスロジックをCloud Functionsで実装します。 この場合、Security Rulesはバイパスされるため、 サーバーサイドコードで権限チェックを実装する必要があります。
クライアント → Cloud Functions → Firestore (Admin SDK)
↑
ここでの権限チェックが重要
Security Rulesは適用されない役員・監査向け説明
「クライアントアプリからの直接アクセスは、
Security Rulesで確実に制御されます。
サーバーサイド処理（Admin SDK）を使用する場合は、
別途セキュリティ対策を実装しています。」
権限データの変更は即時反映
ルール自体の変更はデプロイが必要
Firestoreに保存された権限データ
- ユーザーのロール（users/uid/role）
- 組織の所属情報（users/uid/orgId）
- アクセス許可フラグ等
効果:退職処理でroleを削除すれば、次のリクエストから即座に拒否
Security Rules自体の変更
- ・新しいコレクションのルール追加
- ・ルールロジックの変更
- ・新しい条件の追加
Custom Claims（JWTトークン）
- ・変更後、再認証まで反映されない
- ・トークンの有効期限（最大1時間）に依存
| 運用タスク | 従来（RLS未実装） | Firestore |
|---|---|---|
| クライアントアクセスの権限ルール管理 | 各エンドポイントに分散 | 1ファイルに集約 |
| ルール変更のデプロイ | サーバー再起動が必要な場合あり | firebase deploy（数秒） |
| ルールのテスト | E2Eテストが必要な場合が多い | ルール単体でユニットテスト可能 |
| 担当者の引き継ぎ | コード全体の理解が必要 | ルールファイルから理解開始可能 |
「Firestoreに保存された権限データは即座に反映されます。
ルール自体の変更はデプロイが必要ですが、数秒で完了します。」
監査で説明できる
ただし、ルールファイルだけでは不十分
Q: 「他社のデータを見られないことを証明してください」
A: クライアントSDK経由のアクセスは、resource.data.orgId == getUserOrg() のルールにより自組織のデータのみアクセス可能です。Admin SDK経由のアクセスは、サーバーサイドコードで同等のチェックを実装しています。
Q: 「このルールが確実に適用されていることをどう保証しますか？」
A: クライアントSDK経由のアクセスには、Security RulesがFirebase基盤レベルで強制されます。ルールのユニットテストをCI/CDで実行し、デプロイ前に検証しています。
Q: 「ルールを変更できるのは誰ですか？」
A: Firebaseプロジェクトの管理者権限を持つメンバーのみです。変更履歴はGitで管理され、デプロイはCI/CDパイプラインを通じて行われます。
| 資料 | 説明 | Firestoreでの対応 |
|---|---|---|
| 権限仕様書 | 誰が何にアクセスできるか | Security Rulesファイル + サーバーサイドコード |
| 変更履歴 | ルールの変更履歴 | Gitバージョン管理 |
| デプロイ権限管理 | 誰がルールを変更できるか | Firebase IAM + CI/CD設定 |
| 監査ログ | アクセスログ | Firebase / Cloud Logging |
| テスト結果 | ルールの検証証跡 | CI/CDテスト結果 |
| Admin SDK管理 | サーバーサイドのアクセス制御 | Cloud Functions/Runのコードレビュー |
監査人への説明
「クライアントアクセスの権限管理は、Security Rulesファイルに集約されています。
サーバーサイド処理の権限管理は、対応するコードと合わせてご説明します。
変更履歴、デプロイ権限、監査ログもすべて提出可能です。」
制限事項と考慮点
適切な期待値設定のために
ルールサイズ制限
Security Rulesは64KBまで。非常に複雑なルールセットでは制約になる可能性があります。
関数呼び出し制限
1リクエストあたりget() / exists()は合計20回まで。複雑な権限チェックでは設計の工夫が必要です。
パフォーマンス影響
get() / exists()を多用するルールはレイテンシに影響します。シンプルなルール設計が推奨されます。
ベンダーロックイン
Firestore Security RulesはGoogle独自仕様です。他のDBへの移行時にはルールの再実装が必要です。
これらの制限を理解した上で、適切なユースケースで活用することが重要です。
まとめ
Firestore Security Rulesの位置づけ
宣言的で簡潔
本質だけを記述。レビューが容易。
多層防御の一部
クライアントアクセスの防御ライン。
仕様としても機能
クライアントアクセスの権限仕様書。
クライアントからはバイパス不可
SDK経由では確実に適用。
データ参照は即時反映
権限データの変更は即座に反映。
Admin SDKは別対策
サーバーサイドは追加実装が必要。
Security Rulesは
「多層防御の重要な一層」です
Firestore Security Rulesは、クライアントSDKからの直接アクセスを宣言的かつ強制的に制御する仕組みです。
短いからこそレビューが容易であり、 宣言的だからこそ監査で説明しやすいです。
ただし、Admin SDKを使用するサーバーサイド処理や、その他のセキュリティ対策と組み合わせてはじめて、 包括的なセキュリティが実現します。
本システムでは、Security Rulesを多層防御の一部として活用し、
サーバーサイドセキュリティと組み合わせた設計としています。