マルチテナントSaaSの認可漏れの原因と防ぎ方

要点を抜き出すと、以下のようになるだろう。

1. 認証済みであれば、他者の会議情報(meetings)を横断してクエリできる状態になっていた。
2. 開催中の会議中へのリアルタイムの侵入が可能だった。
3. 影響範囲が大きい(84,312ユーザー、181,874件のメタデータ、政府・大学・企業にも影響)。
4. 認証のないAPIから従業員の氏名・社用メールが露出していた。
5. 報告から6ヶ月間、脆弱性が放置された。

この一覧は要点を一覧にしただけなので、粒度も性質もまちまちだ。詳細は、そのブログを読んで欲しい。

この中の1や2は、認証さえしてしまえば他人や他社の会議情報を取得したり、ミーティングに参加できたりしたようだ。よくよく考えると、これらはマルチテナントSaaSでは特に注意すべきことがらであり、同時に起こりそうなミスだとも言える。今回はここに注目して、何が起きて、どうすれば防げそうかを考える。

今回の問題はどうやらFirestore Security Rulesのテナント分離漏れのようだ。報告の中では、次のように述べられている。

users、chats、transcripts などのコレクションは403が返るのに、meetingsだけは読むことができた、ということのようだ。ただし、実際にどのようになっていたかについては現在知りようもない。

再現の前に、Firestoreの構造を整理しておく。Firestoreには、いわゆる自作のAPIサーバーが無い。フロントエンドがFirebase SDKを使ってFirestoreに直接クエリを投げる。

+--------------------+              +-----------------------------------+
| Frontend           |              | Firestore                         |
|                    |   任意の     |                                   |
| 如何様なクエリも   | ---クエリ--> | クエリが返そうとする              |
| 組み立てられる     |              | ドキュメント1件ごとに             |
|                    |              | Security Rules を評価             |
+--------------------+              +-----------------+-----------------+
                                                      |
                                    +-----------------+-----------------+
                                    |                                   |
                            +-------v-------+                   +-------v-------+
                            | users         |                   | meetings      |
                            | orgId の一致  |                   | 認証済みかだけ|
                            | まで確認cGRE  |                   | 確認cPNK      |
                            | -> 許可/拒否  |                   | -> 常に許可   |
                            +---------------+                   +---------------+

つまり、フロントエンドが何を送ってこようと、実際にデータが返るかどうかはFirestore側、より正確には各コレクションに設定されたSecurity Rulesが、返そうとしているドキュメント1件ごとに判定する。システムがマルチテナントを想定している場合、このSecurity Rulesこそが、「テナントの異なるデータを返さない」ための唯一の砦になる。

まず、認可のある例としてusersコレクションを考える。読み取り時に、自分が所属する組織(orgId)と、対象データの組織が一致するかを確認している。

match /users/{userId} {
  allow read: if request.auth != null
              && resource.data.orgId == getUserOrgId(request.auth.uid);
}

function getUserOrgId(uid) {
  return get(/databases/$(database)/documents/members/$(uid)).data.orgId;
}

一方、meetingsコレクションを次のように書いたとしたらどうだろうか。ログインさえしていれば読めてしまい、組織(orgId)の突き合わせが抜けている。

match /meetings/{meetingId} {
  allow read: if request.auth != null;
}

この2つの違いは、usersは「ログインしているか(認証)」に加えて「自分の組織のデータか(認可)」まで確認しているのに対し、meetingsは「ログインしているか」しか確認していない、ということだ。

このように、コレクションごとに1回だけ書くはずの認可の確認を、1箇所だけ書き忘れると、そのコレクションへの、あらゆる経路からのアクセスが無防備になる。正しく実装されていれば、フロントエンドがどんなクエリを組み立てて送ってきてもSecurity Rulesがそれを止めてくれるはずだが、認可漏れの例のような実装ではmeetingsに関してだけは止まらないことになってしまう。

それでは、さきほどの問題のあるmeetingsのルールを修正してみよう。

match /meetings/{meetingId} {
  allow read: if request.auth != null
              && resource.data.orgId == getUserOrgId(request.auth.uid);
}

当然このようになる。実際に修正するのはそれほど難しくない。ちゃんとorgIdを確認する条件を追加すればよいだけだ。

ここではunittestで認可を検証することを考えることとし、Firestore Security Rulesをテストするたのライブラリ @firebase/rules-unit-testing を使ってテストを書いてみることにした。

const { initializeTestEnvironment, assertSucceeds, assertFails } =
require('@firebase/rules-unit-testing');
const fs = require('fs');

let testEnv;

beforeAll(async () => {
  testEnv = await initializeTestEnvironment({
    projectId: 'demo-testing',
    firestore: { rules: fs.readFileSync('firestore.rules', 'utf8') },
  });
});

afterAll(async () => {
  await testEnv.cleanup();
});

test('同じ組織のusersは読める', async () => {
  await testEnv.withSecurityRulesDisabled(async (context) => {
    const db = context.firestore();
    await db.doc('members/alice').set({ orgId: 'org-a' });
    await db.doc('users/alice').set({ orgId: 'org-a' });
  });

  const alice = testEnv.authenticatedContext('alice').firestore();
  await assertSucceeds(alice.doc('users/alice').get());
});

test('他の組織のusersは読めない', async () => {
  await testEnv.withSecurityRulesDisabled(async (context) => {
    const db = context.firestore();
    await db.doc('members/alice').set({ orgId: 'org-a' });
    await db.doc('users/bob').set({ orgId: 'org-b' });
  });

  const alice = testEnv.authenticatedContext('alice').firestore();
  await assertFails(alice.doc('users/bob').get());
});

test('他の組織のmeetingsが読めてしまう(認可漏れ)', async () => {
  await testEnv.withSecurityRulesDisabled(async (context) => {
    const db = context.firestore();
    await db.doc('members/alice').set({ orgId: 'org-a' });
    await db.doc('meetings/m1').set({ orgId: 'org-b' });
  });

  const alice = testEnv.authenticatedContext('alice').firestore();
  await assertFails(alice.doc('meetings/m1').get()); // 修正前のルールではここが失敗する(=読めてしまう)
});

npm install -D firebase-tools @firebase/rules-unit-testing jest

Error: firebase-tools no longer supports Java version before 21. Please install a JDK at version 21 or above to get a compatible runtime.

curl -L -o jdk21.tar.gz "https://github.com/adoptium/temurin21-binaries/releases/download/jdk-21.0.8%2B9/OpenJDK21U-jdk_aarch64_linux_hotspot_21.0.8_9.tar.gz"
mkdir jdk21 && tar xzf jdk21.tar.gz -C jdk21 --strip-components=1
export JAVA_HOME="$(pwd)/jdk21"
export PATH="$JAVA_HOME/bin:$PATH"

{
  "firestore": {
    "rules": "firestore.rules"
  },
  "emulators": {
    "firestore": {
      "port": 8080
    }
  }
}

npx firebase emulators:exec --only firestore "npx jest rules.test.js"

FAIL ./rules.test.js
  ● 他の組織のmeetingsが読めてしまう(認可漏れ)

    Expected request to fail, but it succeeded.

      50 |
      51 |   const alice = testEnv.authenticatedContext('alice').firestore();
    > 52 |   await assertFails(alice.doc('meetings/m1').get());
         |   ^

Test Suites: 1 failed, 1 total
Tests:       1 failed, 2 passed, 3 total

Test Suites: 1 passed, 1 total
Tests:       3 passed, 3 total

次にコードレビューによって防ぐことを考えてみよう。最近はAI技術が発展したため、コードレビューは人よりもAIの方が得意かもしれない。ただ、すべてAI頼りにはならないため、AIと人、両方の立場からどのようにレビューを進めればいいかを考えることにした。

ここで言う「AIによるレビュー」とは、AIが単独で自動的に自律的にレビューを行うことを指す。一方の「人によるレビュー」とは、人間だけで行うレビューというよりも、人間が主体となり、AIを道具として補助的に使うレビューのことを指す。人だけのレビューは効率が悪すぎるので、もはや取り上げない。

match /users/{userId} {
  allow read: if request.auth != null
              && resource.data.orgId == getUserOrgId(request.auth.uid);
}

match /chats/{chatId} {
  allow read: if request.auth != null
              && resource.data.orgId == getUserOrgId(request.auth.uid);
}

match /transcripts/{transcriptId} {
  allow read: if request.auth != null
              && resource.data.orgId == getUserOrgId(request.auth.uid);
}

match /recordings/{recordingId} {
  allow read: if request.auth != null
              && resource.data.orgId == getUserOrgId(request.auth.uid);
}

match /meetings/{meetingId} {
  allow read: if request.auth != null;
}

ユニットテストでは、meetingsを1件取り出して決められた条件で読めるか読めないかを確認した。これは、個々のルールが正しいかを検証するには向いているが、実際のアプリケーションがどのように使われているかまでは検証できていない。

ここで「シナリオテスト」と呼ぶ以上、本来はルールという1つのレイヤーだけを狙い撃ちするのではなく、実際のアプリやブラウザを自動操作し、ユーザーが辿る経路そのもので動作の正しさを確認するのが通例であり、効果も高い。理由は単純で、ユーザーの目に実際に触れるのは、ルール単体の判定結果ではなく、アプリを通した最終的な画面や応答だからだ。

これには、ルールだけを見ていては拾えない問題を検出できる、という実際的な理由もある。たとえばFirestoreには、サーバー側の管理コードから使うAdmin SDKがあり、これはSecurity Rulesを一切経由しない。バックエンドのどこかで、Admin SDK経由でmeetingsを読み、その内容を別のAPIやログ、通知機能などから漏らしてしまえば、Security Rulesがどれだけ正しくても意味が無い。ルール単体のテストではこの経路を検証できないが、実際のアプリを操作するシナリオテストであれば、結果として情報が漏れていないかを、経路を問わず確認できる。

具体的には、PlaywrightやCypressのようなブラウザ自動操作のツールを使い、「org-aのユーザーとしてログインし、会議を作成し、同僚を招待する。org-bのユーザーとしてログインし直し、その会議やそこから辿れる情報が一切見えないことを確認する」というように、実際の画面操作を通じてシナリオを再現する。

こうしたシナリオは、思いつきで書くのではなく、実際に想定されるユーザーの操作(ペルソナとジャーニー)を先に洗い出し、それぞれをテストケース化していくと網羅しやすい。誰が、何をして、その後どうなるべきかを一覧にしてから、シナリオテストに落とし込む、という順序だ。

// "サーバー"側の実装(このファイルでは認可漏れバージョン: orgIdで絞り込んでいない)
function fetchMeetings(uid) {
  return MEETINGS;
}

test('bobにはorg-aの会議が見えてはいけない', async ({ page }) => {
  await page.goto(APP_URL);
  await page.selectOption('#user', 'bob');
  await page.click('#login-btn');
  await expect(page.locator('[data-testid="meeting-m1"]')).toHaveCount(0);
});

✘  bobにはorg-aの会議が見えてはいけない (5.2s)

    Error: expect(locator).toHaveCount(expected) failed
    Expected: 0
    Received: 1

  1 failed
  1 passed (6.5s)

✓  bobにはorg-aの会議が見えてはいけない (162ms)
✓  bobには自分の組織(org-b)の会議は見える (123ms)

  2 passed (845ms)

他の観点として敵対的検証(adversarial verification)が挙げられる。これは「正しい」ことを直接的に確かめるのではなく、「これは間違っているのではないか」と積極的に反証を試みることで、確からしさを検証する手法だ。

ここまでのユニットテストもシナリオテストも、「想定した条件で、想定した通りに動くか」を確認するものだった。敵対的検証はこれとは向きが逆で、想定していない角度から、意図的にルールを破ろうとする。meetingsのルールで言えば、「orgIdの型が違ったらどうなるか」「membersドキュメントがまだ無い状態で読めてしまわないか」「複数のクエリを組み合わせて、直接は読めないはずの情報を推論できないか」といった、開発者自身では思いつきにくい切り口を、別の視点から探しにいく。

ペネトレーションテストは、この敵対的検証を実際のシステムに対して行うケースの1つだと言える。もっと軽量に、AIエージェントに「このルールを反証してみてほしい」と依頼したり、複数のエージェントに独立して同じルールを攻撃させ、それでも破れなければひとまず信頼する、という形でも敵対的検証は行える。テストが「書いた分しか守らない」のだとすれば、敵対的検証は、まだ書かれていない条件を探しにいく行為だ。

match /members/{uid} {
  allow read: if request.auth != null && request.auth.uid == uid;
  allow write: if false;
}

まず基本になるのが、拒否をデフォルトにすることだ。書き忘れが起きたときに、それが「情報が漏れる」方向に転ぶか、「単に動かなくなる」方向に転ぶかは、設計で決められる。Firestoreは元々ルールを書かない限り全拒否だが、tl;dvはmeetingsに対して「認証済みなら読める」という許可ルールをわざわざ書いてしまっていた。deny by defaultを徹底するとは、拒否を初期値にするだけでなく、許可を書くときの条件を弱くしすぎないところまでを含む。

このほかにも、確認を書く場所を1コレクション/1テーブルにつき1箇所へ集約する、設定漏れを機械的に検出するCIチェックを入れる(Supabaseのdb lintなど)、個別の具体例ではなく「異なる2つの組織なら常に分離される」といった性質を検証するproperty-based testing、本番相当の環境で継続的に越境アクセスを試み、破られたら即検知するカナリア方式、テナントごとにスキーマやデータベースそのものを分離し、書き忘れが構造的に起こりえないようにする、といった手も考えられる。

さらに保証を強めたいなら、形式検証という選択肢もある。AWSはIAMやS3バケットポリシーに対して、SMTソルバーによる自動推論エンジン(Zelkova)を使っている。個別の具体例を1つずつ試すのではなく、「アカウント外からは絶対にアクセスできない」といった性質が、ポリシーの取りうるあらゆる入力について成り立つかどうかを、数学的に証明・反証する。テストが「思いついたシナリオしか守らない」のに対し、形式検証は「書いた性質については、あらゆる入力について成り立つこと」を保証できる。これは本物の進歩だ。

GoogleのZanzibarを起点とするReBAC(関係ベースアクセス制御。OSSではSpiceDBやOpenFGAなど)は、認可をあちこちに散らばったif文ではなく、1つの一貫した関係のモデルに集約するアプローチだ。「誰が、何に対して、どんな関係を持つか」を1箇所で管理することで、書き忘れという失敗の形そのものを減らそうとする。

情報フロー型システム(Denningのラティスモデルを起点とする研究分野で、Jifなどの言語がある)は、テナントAのデータがテナントBに見える場所へ流れ込まないことを、実行時ではなくコンパイル時に、型システムで静的に保証しようとする。型理論は圏論と深く結びついた分野だが、圏論そのものを使った実務的な仕組みについては、確度の高い実例を挙げられない。今のところ、この情報フロー制御が一番近い話だと思う。