top of page
検索

Ubuntu VMで学ぶ「ロールベースアクセス制御：RBAC」

  • 7月19日
  • 読了時間: 6分

更新日：3 日前

sudoersで“人に権限を配る”運用から卒業する


Linux サーバー運用でありがちなのが、必要になるたびに sudo 権限を人へ足していくやり方です。最初は早いのですが、人数が増え、作業内容が増え、監査が入るころにはだいたい破綻します。


誰が何をできるのかが見えにくい。不要な権限が残る。退職や異動のたびに見直し漏れが出る。このあたりは、現場でよくある事故です。この問題に対して効く考え方が、ロールベースアクセス制御（RBAC）です。個人ごとに権限をばらまくのではなく、役割ごとに権限を束ねて与える。Ubuntu の日常運用では、その入り口として sudoers が非常に使いやすいです。


この記事では、Ubuntu VM 上で sudoers を使って、RBAC 的な運用へどう寄せていくかを具体的に見ていきます。


RBAC は“人”ではなく“役割”に権限を持たせる


RBAC の考え方自体は単純です。

たとえば、次のように分けます。

  • 監査担当: ログ閲覧だけ

  • 運用担当: サービス再起動と状態確認だけ

  • バックアップ担当: バックアップコマンドだけ

  • 開発担当: 本番反映不可


これを、個人ごとに都度書かず、まず役割として定義します。そのうえで、誰がどの役割に属するかを管理する。この形にすると、権限の意味が明確になります。


Ubuntu では sudoers が最も手軽


Ubuntu VM で RBAC を試すなら、最初は sudoers が一番分かりやすいです。

編集は必ず visudo を使います。

sudo visudo

ここで、たとえば次のように定義します。

User_Alias AUDITORS = alice
User_Alias OPS = bob

Cmnd_Alias LOGVIEW = /usr/bin/journalctl, /usr/bin/less /var/log/auth.log
Cmnd_Alias SVCMGMT = /usr/bin/systemctl status ssh, /usr/bin/systemctl restart ssh

AUDITORS ALL=(root) NOPASSWD: LOGVIEW
OPS      ALL=(root) SVCMGMT

この設定の意味は明快です。

  • alice は監査担当

  • bob は運用担当

  • 監査担当はログ閲覧だけ可能

  • 運用担当は ssh サービス操作だけ可能


こうしておくと、人に権限を与えるのではなく、役割に権限を与えている状態になります。


実際に試す


ユーザーを作っていなければ先に作ります。

sudo useradd -m alice
sudo useradd -m bob
sudo passwd alice
sudo passwd bob

その後、動作確認をします。

sudo -u alice 
sudo journalctl -n 20
sudo -u alice 
sudo systemctl restart ssh
sudo -u bob 
sudo systemctl status ssh
sudo -u bob 
sudo less /var/log/auth.log

ここでは、許可された操作だけが通るはずです。alice はログ閲覧系だけ、bob は ssh 操作系だけ。この形になると、レビュー時にも「この人は何者か」が見やすくなります。


sudo権限の付与とRBACは似ているようで違う


ここでありがちな勘違いがあります。sudo が使えるなら RBAC なのでは、という見方です。これは誤りであり、単に alice ALL=(ALL:ALL) ALL を大量に並べるだけでは、それは“sudo を配っている”だけであって、本質的なRBACとは呼べません。


RBAC と呼べる状態に近づくには、少なくとも次の条件が必要になります。

  • 権限を役割単位でまとめる

  • 個人名で直接コマンド許可を書き散らさない

  • 役割ごとに責務が読める

  • 監査時に意図が説明できる


よくある実務パターン


sudoers で役割分離をしてみると、直感的に理解しやすいと思います。

たとえば次のようなロールを考えます。


  • ログ閲覧担当

journalctl、特定ログファイルの閲覧だけ許可する。調査はできるが、サービス変更はできない。

  • サービス運用担当

systemctl status と restart だけ許可する。設定ファイルの編集や任意コマンド実行は許さない。

  • バックアップ担当

決められたバックアップスクリプトだけ許可する。シェル全権限は与えない。

  • デプロイ担当

署名済みの配置スクリプトだけ許可する。直接 /bin/bash は許可しない。


この設計にしておくと、権限の追加要求が来ても、「その人に何をさせるか」ではなく「どの役割に入るべきか」で考えられます。


RBAC 的に設計するなら“危険な許可”を避ける


sudoers は便利ですが、雑に書くとすぐ崩れます。

特に気を付けたいのは次です。


  • ALL を安易に使う

  • シェル起動系コマンドを許可する

  • 任意引数付きの危険コマンドを許可する

  • エディタや pager 経由で権限昇格できる構成にする


たとえば less や vi は、使い方次第ではシェル脱出につながることがあります。つまり、許可するコマンドは“何を実現したいか”だけでなく、そのコマンドが副作用として何をできてしまうかまで見なければいけません。RBAC 的に見える設定でも、許可コマンドが危険なら意味がありません。


RBACの強み


RBAC の強みは、権限設計を読みやすく保てることです。人が増えても、まず役割を見ればよい。監査でも「この役割にはこの権限が必要」という説明がしやすい。


特に Linux サーバー運用では、RBAC は「sudo をどう整理するか」という形でかなり実務的です。個人名ベースで設定が散らかるより、役割単位でコマンド群を束ねた方が、変更も棚卸しもしやすい。sudoers が別名定義をサポートしているのも、まさにこの整理をしやすくするためです。


”ロールに何でも押し込むと破綻する。”


RBAC はきれいですが、何でもロールに押し込むと崩れます。典型的には、「院内だけ」「勤務中だけ」「MFA 済みだけ」といった条件までロール化してしまうケースです。


そうなると、

  • 運用担当

  • 運用担当_院内限定

  • 運用担当_院内限定_MFA済み

  • 運用担当_院内限定_MFA済み_夜間不可


のようにロールが増殖していきます。こうなると、RBAC の強みだった“整理のしやすさ”が消えます。つまり RBAC は万能ではなく、役割で表現しやすい部分に使うから強い、ということです。


実務での位置づけ


現代の認可基盤では ABAC が注目されがちですが、RBAC は依然としてかなり重要です。理由は単純で、大枠の権限整理にはいまでも一番向いているからです。

実務では「まず RBAC で役割を切り、その上で足りない条件を ABAC で補う」という組み合わせが多いです。Ubuntu サーバー運用でも、最初の整理はまず sudoers による RBAC 的設計から入る方が安定します。


まとめ


RBAC の要点は、利用者ごとに権限を足していくことではなく、役割ごとに必要な権限を定義し、その役割を人に割り当てることです。Ubuntu VM でこれを学ぶなら、抽象的なモデルを追うよりも、sudoers を使って「監査担当には閲覧系だけ」「運用担当にはサービス再起動だけ」「バックアップ担当には保存処理だけ」といった形で、役割単位に権限を切り分けてみるのが最も分かりやすい入口になります。


この考え方に切り替えると、Linux サーバーの権限設計はかなり整理されます。誰が何をできるかを個別対応で積み上げる運用は、例外が増えるたびに複雑になり、見直しもしづらくなります。RBAC は、その混乱を避けるために、「人」ではなく「役割」を基準に権限を設計するための方法です。


Ubuntu 上で RBAC を実感するうえで重要なのは、高度な仕組みを導入することではありません。まずは役割を定義し、その役割に必要な操作だけを許可することです。RBAC は抽象理論として理解するよりも、運用を整え、権限管理の見通しをよくする設計技法として捉えたほうが、実務の中でははるかに使いやすく見えてきます。

bottom of page