← 記事一覧に戻る
テクノロジー

ロール×操作マトリクスで権限バグを防ぐ

ロール×操作マトリクスで権限バグを防ぐ

権限バグは「テストが通っているのに」出る

権限まわりのバグは厄介です。正常系のテストは全部通り、対象ユーザーとしてログインして操作すれば画面も正しく動く。それなのに本番では「閲覧者ロールなのに削除ボタンが押せた」「他社のプロジェクトのバグレポートが見えた」といった報告が上がってきます。これは機能テストの範囲では原理的に見つけにくいバグです。ある画面が「意図した通りに動くか」は確認していても、「意図しないロールから触ったらどうなるか」は誰も確認していないからです。

典型的な2つのパターン

垂直権限昇格

権限の低いロールが、本来できないはずの操作を実行できてしまうパターンです。たとえば「メンバー」ロールのユーザーが、UI上はボタンが隠れているだけで、API を直接叩けばプロジェクトの削除に成功してしまうケースがあります。フロントエンドでの表示制御しかしておらず、バックエンドの認可チェックが抜けていると起きます。

水平権限昇格

同じ権限レベルのまま、本来アクセスできないはずの他人・他組織のリソースに触れてしまうパターンです。たとえば `GET /api/v1/bug_reports/:id` の `:id` を別プロジェクトの数値に差し替えただけで、所属チェックをすり抜けてレスポンスが返ってきてしまう、というのが典型です。ログイン中のユーザー自身のロールは正しくても、「そのリソースが自分のものか」の検証が漏れているために起きます。

ロール×操作マトリクスの作り方

この2種類のバグを構造的に防ぐには、実装が始まる前の設計段階で「ロール×操作」の一覧表を作ります。

  1. 操作を洗い出す: 対象リソースに対する CRUD に加えて、招待・エクスポート・ステータス変更などの特殊操作も含める
  2. ロールを洗い出す: Owner / Admin / Member / Viewer のような社内ロールだけでなく、「未ログイン」「他組織のユーザー」も1行として加える
  3. 交点を埋める: 各セルに ◯(許可)/✕(禁止)/△(条件付き、条件も明記)を記入する
  4. チームでレビューする: 特に △ のセルは実装者の解釈が割れやすいので、設計レビューの場で合意を取る

例えば Bugoon のようなバグ報告 SaaS であれば、「Viewer がバグレポートのステータスを Closed に変更できるか」は仕様として曖昧になりがちです。マトリクスに書き出して初めて、こうした未決定事項が可視化されます。

マトリクスをテストケースに変換する

マトリクスは作って終わりではなく、そのままテストの入力にします。RSpec であればロールとリソースの組み合わせをパラメータ化し、マトリクスの ✕ のセルが確実に 403 を返すことを検証します。

%w[owner admin member viewer].each do |role|
  context "role: #{role}" do
    let(:user) { create(:user, role: role) }

    it "matrix.csv の許可設定どおりに応答する" do
      expected = permission_matrix.lookup(role: role, action: "destroy_project")
      delete api_v1_project_path(other_project), headers: auth_headers(user)
      expect(response.status).to eq(expected == :allow ? 204 : 403)
    end
  end
end

マトリクスをCSVやYAMLとして保存し、テストコードから参照する形にしておくと、ロールが増えたときにマトリクス更新漏れがテスト失敗として検出できます。

設計レビューで確認したいこと

  • 新しいロールを追加したら、既存の全マトリクスへの追記が必要になることをチームが認識しているか
  • 認可チェックはコントローラのフィルタなど1箇所に集約されているか、それとも複数箇所に分散しているか
  • 「自分のリソースか」の判定は、パラメータの ID だけでなく所属組織の一致まで見ているか
  • API のレスポンス自体に他組織のデータが混入していないか(ステータスコードだけでなくボディも確認する)

Bugoon での実践

権限マトリクスをテストで固めても、実運用では想定していなかったロールの組み合わせから抜けが見つかることがあります。そうした報告は Bugoon のウィジェットからスクリーンショット付きで送ってもらい、GitHub Issue として起票してカンバンボードで追跡すれば、水平/垂直どちらのパターンかを含めて開発チームに正確に伝わります。報告に報告者自身のロール情報が一緒に載れば、権限起因のバグかどうかの切り分けがもう少し早くなりそうです。

チームのバグ報告を、もっとスムーズに。

Bugoon は無料で始められます。サイトにタグを 1 行追加するだけで、QA と開発の往復がなくなります。

無料で始める