データアクセス制御とは？認可と権限管理で業務効率とセキュリティを両立

2023年12月5日2025年7月30日

クラウドサービスを利用するにあたって、セキュリティ面での不安をお持ちの方もいるかもしれません。
この記事では、データのアクセス制御という側面から、データセキュリティの考え方と具体的なサービスを例にとって実現方法を解説します。

アクセス制御とは | 3つの役割

業務アプリケーションなどのシステムにおいて、アクセス制御はセキュリティと業務効率を両立させるために欠かせない要素です。アクセス制御とは、データ等のシステムリソースについて、アクセスできるユーザーを制限・管理することで、アクセスコントロールとも呼ばれます。アクセス制御は大きく分けて「認証（Authentication）」「認可（Authorization）」「監査（Auditing）」の3つの要素で構成されます。それぞれの意味と役割を整理しておきましょう。

認証とは

認証とは、アクセスしようとしているユーザーが「誰であるか」を確認するプロセスです。たとえば、IDとパスワードの組み合わせ、2要素認証（SMSコードや認証アプリ）、顔認証などが該当します。ログイン等によって本人確認を行い、そもそもデータ自体に対してアクセス可能なユーザーかどうかを切り分けます。

ポイント	本人確認の「入り口」
例	営業部の田中さんが、自分のパスワードを使ってログインできるか

正確な認証を行うことで、「なりすまし」や「第三者による不正アクセス」を防ぐことができます。

認可とは

認可とは、認証済みのユーザーが、どの範囲までアクセスできるのかを制御するプロセスです。たとえば、「営業部のメンバーは自部署のデータのみ閲覧可能」「管理者は全データを編集可能」などの設定が該当します。

こうしたアクセス制御は一義的にはセキュリティを目的として、適切なユーザーのみが適切なデータにアクセスできるようにして、データを保護する意味あいがあります。
加えて、業務上の要件のために、認可の考え方を活用することもできます。つまり、ユーザーが割り当てられた役割（ロール）に応じて、適切なタイミングで適切なデータのみがアクセス可能となることで、円滑に業務を受け渡すことができるようになる、といった使い方です。

ポイント	「何ができるか」を決める権限設計
例	田中さんは見積もりの入力はできるが、承認はできない

業務アプリケーションでは、この認可の粒度を柔軟に設計できるかが運用性・セキュリティの両面で重要なカギとなります。

監査とは

監査とは、誰が・いつ・どのような操作を行ったかを記録・追跡する仕組みです。アクセスログや変更履歴を保存することで、不正行為の兆候を検知したり、トラブル時の原因特定に役立てたりできます。

ポイント	ログで「見える化」し、証跡を残す
例	田中さんは見積もりの入力はできるが、承認はできない

監査の仕組みはセキュリティ対策だけでなく、内部統制やコンプライアンス対応にもつながるため、特に組織利用において重要です。

主なアクセス制御モデル | 4つの代表的な方式

アクセス制御には、組織の規模やシステムの目的に応じていくつかの代表的なモデルがあります。それぞれに特徴があり、考え方の違いを理解した上で、目的に合致した方式を活用することでセキュリティと運用のしやすさのバランスを取ることが可能です。

ここでは、よく使われる4つのアクセス制御モデルを紹介します。

DAC（Discretionary Access Control）任意アクセス制御

リソースの所有者がアクセス権限を管理するモデルです。ファイルやデータベースの所有者が、他のユーザーに対して「読み取り可」「編集可」といった許可を任意に設定できます。

特徴	・柔軟性が高い・所有者主導の設定が可能
注意点	不適切な権限付与のリスクがある（特に規模が大きい組織では管理が煩雑）
例	自分が作成した顧客リストを、同じチームのメンバーにも編集権限を与える

MAC（Mandatory Access Control）強制アクセス制御

セキュリティポリシーに基づいて、システムが一括してアクセス制御を行うモデルです。ユーザー自身でアクセス権限を変更することはできず、あらかじめ定められたルール（セキュリティラベルなど）に従って制限されます

特徴	・セキュリティ性が非常に高い・軍事機関や機密性の高い業務で採用される
注意点	柔軟性が低く、導入・運用のコストが高め
例	「極秘」レベルのデータは、特定の権限グループのみアクセス可能

RBAC（Role-Based Access Control）ロールベースアクセス制御

ユーザーに「役割（ロール）」を割り当て、ロールに基づいてアクセス権限を管理するモデルです。最も一般的に使われており、組織の階層構造と親和性があります。

特徴	・管理しやすく、現実の組織構造に合っている・ロール単位で権限設計できるため運用が容易
注意点	複雑な条件付きアクセスにはやや対応しづらい
例	営業部マネージャーは「承認」「編集」ができるが、一般メンバーは「閲覧」のみ

ABAC（Attribute-Based Access Control）属性ベースアクセス制御

ユーザーやリソース、環境の「属性」に基づいてアクセス制御を行う柔軟なモデルです。条件を細かく指定でき、動的なアクセス制御が可能です。

特徴	・柔軟性が非常に高く、きめ細かい制御が可能・ロールに依存しないため動的対応がしやすい
注意点	設計・運用の難易度が高め（ルールが複雑になりやすい）
例	「営業部のメンバーが、平日9時～18時に、自部署のデータだけにアクセスできる」

実際の業務アプリケーション等では、RBACやABACの考え方をベースにしたアクセス制御が採用されていることが多いです。

クラウドサービスでの認可の実現方法

「認証」については、一般的に知られている通りログインによってシステムそのものを使えるかどうかを判断するものです。ここでは、「認可」について、アクセスできるデータの範囲等を制限するという考え方が、具体的にクラウドサービス上ではどのように実現されているか解説していきます。

この記事では、ノーコード開発ツールであるNuAppを例により説明します。NuAppでは、様々なアクセス制限により、セキュリティ・業務要件を満たしたシステムを開発できるように作られているため、そうした機能をベースに解説します。

データレベルでのアクセス制限

１つ目は、データの種類ごとに設定するアクセス権です。基本的にこれは組織に基づいた制限をかけるものです。具体的には、次の図のように、自分が所属する部署の下位組織のユーザーが所有者となっているデータについてはアクセスできる一方、それ以外の部署の所有データについては、アクセスできないようにするという形で実現しています。
これにより、部署レベルでデータの制限をかける場合の一般的なシナリオに対応できます。
この機能は、ユーザーの所属部署という属性をベースに権限を制御するため、ABAC（属性ベースアクセス制御）に分類できます。

役割に応じた業務プロセス上でのアクセス制限

役割に応じた制限を行う方法としては、プロセス図で設定した「担当」によるものがあります。
NuAppではワークフローのような形で業務を受け渡していく機能をプロセス図で描画することで実現できますが、その際に、その業務プロセスで登場する役割を「担当」として設定します。
このプロセスと担当は、次のように機能します。プロセス図の中には「タスク」というものがありますが、これは「担当者が該当業務を実施し、それに応じたデータ登録を行う」という意味合いのものです。プロセスは、現在の処理や業務（ノード）が終わると、順番に次の箇所に進んでいきますが、タスクに到着すると、担当者による操作待ちの状態となります。そのため、データ毎にそのタイミングでアクセスが求められているユーザーのみが担当として編集を行うことができ、それ以外のユーザーが誤って操作することを防ぐことができます。このように、担当に基づいた制御は、更新権限に関するものであり、閲覧を制限するものではありません。

こうした機能は、まさにユーザーの役割（ロール）によって制御を行うという点で、RBAC（ロールベースアクセス制御）にあたります。

アプリの機能レベルでの表示範囲の制限

最初に紹介したアクセス制限ほど厳密に機能するののではありませんが、アプリに配置するリストの条件設定において、ユーザーに応じて表示するデータの範囲をきめ細かく制限することも可能です。例えば、ログインユーザーが特定のタスクの担当になっている、かつ進捗ステータスが自分が実施すべき段階まで進んでいる、という条件でリスト表示することで、更新権限だけでなく閲覧の面でも不要なデータを非表示とすることが可能です。