ログインの先にある「認可」を見直す

認証を強化しても残る課題 ―「認可」が問われる背景

認証は「本人の確認」、認可は「許可する範囲の判定」

業務システムのセキュリティでは、「認証（Authentication）」と「認可（Authorization）」を分けて考えるのが一般的です。認証は、利用者が本人であることを確認する仕組みで、パスワードや2要素認証、パスキーなどがこれにあたります。認可は、認証された利用者に対して、どのデータや機能を、どの範囲まで使わせるかを判定する仕組みです。

オフィスにたとえると、認証は入館ゲートでの本人確認、認可は部屋やキャビネットごとの鍵の受け渡しにあたります。入館ゲートを厳格にしても、全員にすべての鍵を渡していれば、1枚の入館証が不正に使われたときや、誰かが誤って書類を持ち出したときの影響は大きくなります。認可を適切に設計しておくことは、認証を補い、万一の際の影響範囲を抑えるための対策といえます。

公的機関の注意喚起でも、アクセス制御と認可が取り上げられている

個人情報保護委員会は2026年10月7日、外部からの不正アクセスによって大量の個人データが漏えいし、またはそのおそれが生じた事案を踏まえ、個人情報取扱事業者向けの注意喚起を公表しました。この中では、ガイドライン（通則編）の技術的安全管理措置について、2027年4月の確定を予定している見直しの内容が先取りして示されており、「アクセス制御」の手法の例示として、次のような項目が挙げられています。

• ユーザーIDに付与するアクセス権限を最小化し、個人データを取り扱う情報システムを使用できる従業者を限定する
• 特権アカウントを割り当てる従業者、利用する端末、利用する場面等を最小限に限定する
• 人事異動や従業者の退職等、組織体制に変更が生じた場合に、アクセス権限の変更を適切に行う
• アクセス権限について定期的に監査するなど、アクセス権限の棚卸しを行う

なお、同注意喚起では、「手法の例示」は必ずしもその全てを講じなければ法違反と判断されるものではなく、適切な手法は例示の内容に限られないとされています。

同日に改訂された同委員会の「WARNING～不正アクセスによる個人データ漏えい防止のための注意喚起～」でも、業務上の利便性からグループ会社間で相互にアクセスできる状態にしていた事例や、APIの設計・設定不備により、パラメータの書き換えで他のユーザーの情報を取得できた事例が紹介されています。対策例としては、業務上必要最小限の範囲でのアクセス制御や、認証（本人確認）に加えて認可（そのユーザーが当該データにアクセスする権限を有するかの確認）を都度行う仕組みの実装が挙げられています。

アプリケーションのリスクとしても、アクセス制御の不備は上位に

Webアプリケーションの代表的なセキュリティリスクをまとめた「OWASP Top 10:2025」では、アクセス制御の不備（Broken Access Control）が2021年版に続いて1位に位置付けられています（認証の不備は7位）。よくある不備として最初に挙げられているのが、特定の役割や利用者にのみ許可すべき機能が誰にでも使える状態になっている「最小権限の原則（既定で拒否）への違反」です。また、アクセス制御は、攻撃者が改変できない信頼されたサーバー側のコードで実装されてはじめて有効である、とされています。

IPA（情報処理推進機構）の「情報セキュリティ10大脅威 2026」［組織］では、「サプライチェーンや委託先を狙った攻撃」が2位、「内部不正による情報漏えい等」が7位に選ばれています（内部不正は11年連続の選出）。社外の協力会社や委託先にどこまで見せるか、従業者の権限が業務に対して過剰になっていないか、という観点からも、認可の設計を確認しておきたいところです。

権限設計の基本 ― 最小権限とロールベースアクセス制御（RBAC）

必要な権限だけを付与する「最小権限の原則」

権限設計の出発点となるのが、業務に必要な権限だけを付与する「最小権限の原則」です。新しいメンバーやシステム連携用のアカウントには、権限のない状態から必要なものだけを追加していく「既定で拒否」の考え方をとると、権限が過剰になりにくくなります。閲覧で足りる業務には閲覧権限を付与し、設定変更や削除のように影響の大きい操作は、担当者を限定して付与するのが基本です。

個人ではなく「役割」に権限をひも付けるRBAC

利用者が増えると、一人ひとりに権限を設定する方法では、設定の数が「人数×データや機能の数」で増え、異動や退職のたびに変更漏れが生じやすくなります。そこで広く用いられているのが、ロールベースアクセス制御（RBAC：Role-Based Access Control）です。米国国立標準技術研究所（NIST）は、文書「SP 800-53 Rev. 5」などでRBACを「ユーザーの役割に基づくアクセス制御」と定義しています。また、1992年にNISTの研究者が定式化したモデルは、2004年に米国規格（ANSI INCITS 359-2004）として採用されています。

RBACでは、「営業担当」「経理担当」「協力会社」といった役割ごとに権限をまとめて定義し、利用者には役割を割り当てます。異動の際は割り当てる役割を変えるだけで済み、棚卸しの際も「どの役割に何を許可しているか」を確認すれば全体を把握しやすくなります。

運用の中で権限が広がりやすいポイント

権限の設計は、導入時に一度整えれば終わりではありません。次のような場面では、意図せず権限が広がったり、不要な権限が残ったりしやすいため、定期的な見直しの観点として押さえておくとよいでしょう。

• 「とりあえず」付与した管理者権限が、そのまま残っている
• 例外的な個別付与が積み重なり、役割の定義と実態がずれている
• 異動・退職・委託契約の終了時に、権限の変更や削除が漏れている
• 社外の協力会社が、担当業務に関係しないデータまで閲覧できる
• システム連携用のAPIキーが、連携に必要な範囲を超える権限を持っている

RapidTableの「認可設定（アクセスポリシー）」でできること

ここからは、上記の考え方をRapidTableでどのように実現できるかをご紹介します。

RapidTableは、エクセルやスプレッドシートを扱う感覚でデータベースを設計できる、SaaS型のノーコード・ローコードデータベースです。認可は、ワークスペース（プロジェクトやドライブなどをまとめる最上位の単位）ごとに定義する「ポリシー」で制御します。ポリシーはアクセス権限のまとまりで、RBACにおける「役割」にあたります。ポリシーの作成やメンバーへの割り当ては、ワークスペースの管理権限を持つメンバーが、ワークスペースの設定画面から行います。

リソースごとに「読込・書込・管理」を表形式で設定

ポリシーの編集画面では、ワークスペース、ドライブ、タググループ、API、プロジェクトの5種類のリソースについて、「読込」「書込」「管理」の3段階の権限を表形式で設定します。表のセルをクリックするごとに権限の付与と解除が切り替わり、上位の権限を付与すると下位の権限もあわせて付与されるため、「書込はできるが読込はできない」といった不整合な組み合わせになりにくい設計です。

※ ワークスペースの「読込」は、ポリシーの編集画面では常に付与された状態となり、変更できません。（表は横にスクロールできます）

プロジェクトは全体と個別指定を組み合わせ、「部分参照のみ」も選択可能

プロジェクトについては、ワークスペース内の全プロジェクトに共通する権限を「All」の行で設定したうえで、［＋］から個別のプロジェクトを追加し、プロジェクトごとに異なる権限を設定できます。たとえば協力会社向けのポリシーでは、「All」には権限を付与せず、担当案件のプロジェクトにのみ読込権限を付与する、といった設定が可能です。

また、プロジェクトの読込欄では、「読込」のほかに「部分参照のみ」を選択できます。部分参照のみは、プロジェクト画面へのアクセスを禁止し、データの部分的な参照だけを許可する設定です。他のプロジェクトからのルックアップ参照には使いたいが、プロジェクト自体は開かせたくない、といったマスタデータなどの扱いに適しています。

プリセットポリシーと、組織に合わせたカスタムポリシー

ワークスペースには、あらかじめ6種類のプリセットポリシーが用意されています。プリセットポリシーは内容を変更・削除できないため、標準的な役割の基準として利用できます。

※「管理」は書込・読込を、「書込」は読込を含みます。「―」は権限なしを表します。（表は横にスクロールできます）

部門や業務、社外の協力会社など、組織の実態に合わせた役割が必要な場合は、カスタムポリシーを作成できます（1ワークスペースあたり最大999個）。プロジェクトの個別指定もカスタムポリシーで行います。メンバーに割り当て中のポリシーは削除できないため、割り当てが残ったまま役割の定義だけが失われることはありません。

運用と安全性を支える仕組み

メンバーとユーザーグループにポリシーを割り当てる

ポリシーは、ワークスペースのメンバー（ユーザー）またはユーザーグループに割り当てます。ユーザーグループに割り当てておけば、所属するユーザーにまとめて権限が適用されるため、部門単位の権限管理や、異動に伴う所属グループの変更による権限の切り替えに対応しやすくなります。ユーザー個人に割り当てたポリシーと、所属するユーザーグループに割り当てたポリシーは、組み合わせて評価されます。

ポリシーはワークスペースごとに定義・割り当てるため、同じ利用者でも、自部門のワークスペースでは書込、他部門と共有するワークスペースでは読込のみ、といった使い分けが可能です。ワークスペースの設定画面では、メンバーやユーザーグループごとに割り当てられたポリシー名と権限の内容を一覧で確認できるため、権限の棚卸しにも活用できます。

※ ユーザーグループの作成・管理は、エンタープライズ専有環境の企業管理コンソールで行います。

画面の表示だけでなく、サーバー側でリクエストごとに権限を検証

RapidTableでは、権限に応じて画面のメニューやボタンを切り替えるだけでなく、データの取得・登録・更新・削除や設定の変更といった操作のたびに、サーバー側で利用者のポリシーを確認しています。たとえばプロジェクトでは、データの編集には書込以上、プロジェクトの設定変更や削除には管理の権限が必要です。画面を経由せずにリクエストを直接送信した場合でも、権限のない操作はサーバー側で拒否されます。前述のOWASP Top 10が示す「信頼されたサーバー側で実装する」という考え方に沿った設計です。

API連携にも同じポリシーを適用し、APIキーでさらに範囲を絞る

外部システムとのAPI連携も、認可の対象です。RapidTableのREST APIは、APIキーを発行したアカウントに割り当てられたポリシーの範囲内でのみ動作し、ポリシーのAPIの権限と、操作対象のリソースの権限の両方が確認されます。たとえば、API経由でプロジェクトにデータを登録するには、APIの書込権限と、対象プロジェクトの書込権限の両方が必要です。

さらに、APIキー（v2）ごとに、読取専用か書込可能か、接続を許可するワークスペース、接続を許可するIPアドレスを設定できます（ワークスペースとIPアドレスはそれぞれ最大10件）。連携の用途に合わせてキーごとに範囲を絞ることで、ポリシーとあわせて二重に権限を限定できます。なお、APIキーは2要素認証を有効にしている場合にご利用いただけます。

まとめ

認証の強化によって不正ログインのリスクを下げることと、認可の設計によって「ログインした利用者が何をできるか」を適切に保つことは、互いに補い合う関係にあります。最小権限の原則に沿って必要な権限だけを付与し、権限を個人ではなく役割（ロール）にひも付けて管理する、という考え方は、ツールの選定にかかわらず権限設計の出発点になります。

見直しにあたっては、まず現在の利用者と権限を一覧にし、役割の定義と実態のずれ、管理者権限の付与範囲、社外のアカウントやAPIキーの権限を確認するところから始めるのが現実的です。そのうえで、異動・退職・委託終了のタイミングや定期的な棚卸しの機会に、見直しを繰り返していくことが大切です。

RapidTableの認可設定は、こうした役割ベースの権限設計を、リソースごとの表形式の画面で表現できるように設計しています。業務部門や情報システム部門が自ら権限を見直しやすくなるため、運用の内製化や、組織変更への迅速な対応にもつながることが期待できます。パスキー認証をはじめとする認証機能や、ドライブのアクセス履歴などと組み合わせて、業務データを安心して活用するための基盤としてご活用ください。

※ 記載の内容は、本記事公開時点の製品仕様に基づいています。利用可能な機能は、提供形態（SaaS／専有環境）およびご契約の内容によって異なります。機能の詳細は製品マニュアルをご確認ください。