アクセス制御モデルとは？DAC・MAC・RBACの違いと中小企業での実装を解説

「うちのサーバー、いつ誰がどのファイルにアクセスできるか正直把握できていない」という声を、現場でよく耳にします。退職した社員のアカウントが残っていた、業務に不要なフォルダを全員が参照できていた――こういった権限の「ゆるさ」は、攻撃者が内部に侵入したときに被害を広げる温床になります。

アクセス制御（Access Control）は、情報セキュリティの三原則CIA（機密性・完全性・可用性）のうち「機密性」を守る最前線の仕組みです。そのモデルには大きく3種類あり、それぞれ特性が大きく異なります。

この記事では、DAC・MAC・RBACの違いと選び方、攻撃者がどこを突いてくるか、そして中小企業の情シスが今日から着手できる実装手順を、現場目線で解説します。

アクセス制御とは？なぜ今すぐ知る必要があるか

アクセス制御とは、「誰が（Who）、何に（What）、どんな操作を（How）行えるか」を明確に定義し、それ以外を拒否する仕組みです。ファイルの読み書き・サービスへのログイン・ネットワーク経路のすべてがアクセス制御の対象になります。

なぜ今重要かというと、攻撃の侵入口が多様化しているからです。フィッシングメールで一般ユーザーのアカウントが乗っ取られたとき、そのアカウントがアクセスできる範囲が攻撃者の「作業スペース」になります。権限が適切に絞られていれば、そこから先の横展開（ラテラルムーブメント）を封じ込められます。逆に言えば、「全員が全ファイルを読める」状態は、侵入されたときに会社ごと道を開けているのと変わりません。

3つのアクセス制御モデルを徹底比較

1. DAC（任意アクセス制御）とは

DAC（Discretionary Access Control、任意アクセス制御）は、リソースの所有者が自分でアクセス権を設定するモデルです。Linuxの chmod で設定するファイルパーミッション（rwx）や、Windowsのフォルダ共有設定が代表例です。

・特徴: 所有者が自由に権限を設定・委譲できる
・メリット: 柔軟性が高く、追加ツールなしで導入できる
・デメリット: 所有者が誤って広い権限を設定しやすい。権限が「人から人へ」伝播する仕組みなので管理が属人化する
・向いているケース: 小規模チームの共有ファイルサーバー、個人の開発環境

2. MAC（強制アクセス制御）とは

MAC（Mandatory Access Control、強制アクセス制御）は、管理者が一元的にセキュリティラベル（分類レベル）を設定し、ユーザーやプロセスがそのラベルに従ってしかアクセスできないモデルです。SELinuxやAppArmorが代表的な実装です。

・特徴: ポリシーはシステム管理者のみが定義でき、ユーザーは自分で変更できない
・メリット: 権限の意図しない拡大が起きにくい。root権限を持つプロセスも制限できる
・デメリット: 設定の複雑度が高く、運用コストがかかる
・向いているケース: 官公庁・金融・医療などの高セキュリティ環境、Webサーバーの隔離

3. RBAC（ロールベースアクセス制御）とは

RBAC（Role-Based Access Control、ロールベースアクセス制御）は、「ユーザーに直接権限を付与するのではなく、ロール（役割）に権限をまとめ、ユーザーをロールに割り当てる」モデルです。AWS IAM、Active Directory、Kubernetes RBACなどが代表例です。

・特徴: 権限の付与・剥奪がロール単位で行え、管理の一貫性が保たれる
・メリット: 退職者のアカウント削除・部署異動時のロール切り替えが容易。最小権限を実現しやすい
・デメリット: ロール設計の初期コストがかかる。ロールを増やしすぎると「ロール爆発」が起きる
・向いているケース: 中規模以上の企業、クラウド環境のIAM設計、SaaS権限管理

以下の表で3モデルを整理します。

攻撃者はアクセス制御の穴をどう突くか

アクセス制御の弱点を狙うパターンは大きく3つです。防御するには、攻撃者の視点で自分の環境を見る習慣が欠かせません。

① 過剰権限の悪用
「全員 Administrator」「共有フォルダはフルアクセス」といった設定は、侵入後の被害を最大化します。一般ユーザーのアカウントが乗っ取られた場合でも、そのアカウントに管理者権限があれば攻撃者はシステム全体を掌握します。

② 休眠アカウントの悪用
退職者や長期休暇中の従業員のアカウントが残っていると、本人が気づかないまま攻撃者に利用されます。アカウントの持ち主が離席中なので検知が遅れ、不正アクセスに気づいたときには被害が拡大しています。

③ 権限昇格（Privilege Escalation）
一般ユーザーとしてログインした後、SUID/SGIDビットが設定された実行ファイルやsudoersの設定ミスを突いて管理者権限を取得する手法です。DACの設定ミスが直接の原因になることが多いため、定期的な棚卸しが重要です。

具体的な実装手順

1. 現状の権限棚卸し

まず「誰が、何にアクセスできるか」を可視化します。Linuxサーバーでは以下のコマンドで現状確認ができます。

# SUID/SGIDビットが設定されたファイルを検出（権限昇格の踏み台になりうる）
find / -perm /6000 -type f 2>/dev/null

# sudoers の設定内容を確認
sudo cat /etc/sudoers
sudo ls /etc/sudoers.d/

# ホームディレクトリのパーミッションを一覧確認
ls -la /home/

# sudo グループのメンバー一覧を確認
getent group sudo
getent group wheel

Active DirectoryやAWS IAMを利用している場合は、管理コンソールで「90日間ログインのないアカウント」「過剰な権限が付与されたユーザー」を定期的にレポートとして出力する仕組みを作りましょう。

2. RBACポリシーの設計

中小企業でRBACを導入する際の基本ステップです。

・ステップ1: 業務ロールを定義する「一般社員」「営業リーダー」「システム管理者」「経理担当」など、業務上の役割を洗い出す
・ステップ2: ロールごとに必要な権限を定義する 最小権限の原則（Principle of Least Privilege）に従い、業務に必要な最低限の権限だけを割り当てる
・ステップ3: ユーザーをロールに割り当てる 個人に直接権限を付与するのではなく、必ずロール経由で管理する
・ステップ4: 定期的にロール割り当てをレビューする 四半期ごとに不要なロールが残っていないかを確認し、異動・退職に合わせてロールを更新する

3. Linuxでのアクセス制御実装例

チーム開発環境でグループを使ったDAC設定の例です。

# 開発チーム用グループを作成
sudo groupadd devteam

# ユーザーをグループに追加
sudo usermod -aG devteam alice
sudo usermod -aG devteam bob

# プロジェクトディレクトリをグループ所有に設定
sudo chown -R root:devteam /var/www/project

# グループに読み書き権限、その他ユーザーはアクセス不可
sudo chmod -R 750 /var/www/project

# 新規ファイルがグループ所有になるよう SGIDビットを設定
sudo chmod g+s /var/www/project

SELinuxを使う場合は、Webサーバー用のコンテキストを確認・設定します。

# SELinuxコンテキストを確認
ls -Z /var/www/html/

# Webコンテンツに正しいコンテキストを設定
sudo semanage fcontext -a -t httpd_sys_content_t "/var/www/html(/.*)?"
sudo restorecon -Rv /var/www/html/

# SELinuxの現在のモードを確認
getenforce

SELinuxの詳細な設定については、姉妹サイトLinuxMaster.JPでも実践的な解説を行っています。

中小企業でも今日からできること

セキュリティ予算が限られた環境でも、次の3点から着手できます。専門ツールの導入前に、まず「現状把握と整理」に時間を使うことが重要です。

① アカウントの棚卸し（今日からすぐ）
退職者・異動者のアカウントが残っていないか確認し、不要なアカウントを無効化または削除します。Active DirectoryのユーザーリストとSaaSの管理コンソールを横断して確認するのがポイントです。見落としが起きやすいのはSaaS側です。

② 管理者権限の最小化（今週中に）
日常業務に本当に管理者権限が必要かを見直しましょう。Windowsであれば通常のユーザーアカウントで業務を行い、管理操作が必要なときだけ昇格させる運用が基本です。Linuxではsudoersを見直し、「NOPASSWD: ALL」のような無制限設定がないかを確認してください。

③ 四半期ごとの権限レビュー（継続的に）
「業務の実態と権限設定が一致しているか」を定期的に確認する仕組みを作ります。スプレッドシートで良いので、ユーザー一覧×権限一覧の対応表を維持することが、大きなインシデントを防ぐ地道な活動になります。

よくある誤解と注意点

「ファイアウォールがあれば内部のアクセス制御は不要」は危険
ファイアウォールは外からの侵入を防ぐものですが、一度侵入された後や内部不正には対応できません。ネットワーク境界防御とアクセス制御は補完関係にあり、どちらか一方で十分ということはありません。

「RBACを入れれば管理が楽になる」は半分正解
RBACは権限管理を体系化しますが、導入後に「便利だから」とロールを増やしすぎると、かえって管理が複雑になります。ロールの命名規則と設計原則をあらかじめ文書化しておくことが重要です。

「管理者権限での日常作業への慣れ」が最大のリスク
管理者権限でのログインを常態化させると、誤操作による設定変更や、フィッシングで認証情報が盗まれた際の被害が最大化します。「日常作業は一般ユーザー、管理操作は昇格して実施」という習慣を組織として徹底することが、技術的な対策と同じかそれ以上に重要です。

本記事のまとめ

アクセス制御の整備は、「攻撃を受けたときの被害範囲を限定する」という発想で取り組むことが大切です。完全な侵入防止は難しくても、侵入後の被害を最小化できれば事業への影響を大幅に抑えられます。まずは今日、退職者アカウントの確認から始めてみましょう。