“ユーザーやロールだけで決めない”アクセス制御を、polkitで手を動かして理解する アクセス制御の説明では、RBAC まで来ると話がだいぶ整理しやすくなります。「運用担当だからこの操作を許可する」「監査担当だから閲覧だけ許可する」といった形で、役割ごとに権限をまとめられるからです。 ただ、実務ではそれだけで収まらない場面が増えています。同じ管理者でも、社内ネットワークからの操作と私物端末からの操作では扱いを変えたい。同じ医師でも、自分の担当患者に対する閲覧と、他科の患者記録へのアクセスを同じにしたくない。こういう条件が入ってくると、ロールだけで押し切る設計はすぐに苦しくなります。 ここで出てくるのが ABAC です。ABAC は Attribute-Based Access Control、属性ベースアクセス制御です。RBAC が「役割」でアクセスを決めるモデルだとすれば、ABAC はもう一段細かく考えます。アクセスの可否を、利用者の属性、資源の属性、操作の種類、時間帯、場所、端末状態など、複数の条件で判断する考え方です。Ubuntu で標準

sudoersで“人に権限を配る”運用から卒業す る Linux サーバー運用でありがちなのが、必要になるたびに sudo 権限を人へ足していくやり方です。最初は早いのですが、人数が増え、作業内容が増え、監査が入るころにはだいたい破綻します。 誰が何をできるのかが見えにくい。不要な権限が残る。退職や異動のたびに見直し漏れが出る。このあたりは、現場でよくある事故です。この問題に対して効く考え方が、**ロールベースアクセス制御（RBAC）**です。個人ごとに権限をばらまくのではなく、 役割ごとに権限を束ねて与える 。Ubuntu の日常運用では、その入り口として sudoers が非常に使いやすいです。 この記事では、Ubuntu VM 上で sudoers を使って、RBAC 的な運用へどう寄せていくかを具体的に見ていきます。 RBAC は“人”ではなく“役割”に権限を持たせる RBAC の考え方自体は単純です。 たとえば、次のように分けます。 監査担当: ログ閲覧だけ 運用担当: サービス再起動と状態確認だけ バックアップ担当: バックアップコマ

AppArmorで「そのユーザーなら読める」を「そのプロセスには読ませない」に変える Linux の権限管理に少し慣れてくると、こんな場面にぶつかります。 「ファイル権限としては読めてしまう。だが、そのアプリケーションには読ませたくない。」 この時点で、chmod や ACL だけでは少し苦しくなります。なぜなら、それらは基本的に「ユーザーやグループに対する権限設定」だからです。一方、実際に縛りたい対象はユーザーそのものではなく、 その権限で動くプロセス であることが多いからです。 ここで必要になるのが強制アクセス制御（MAC: Mandatory Access Control）です。Ubuntu では、この MAC を担う代表的な仕組みが AppArmor です。 この記事では、Ubuntu VM を使って AppArmor を触りながら、DAC では足りない部分をどう補うのかを具体的に見ていきます。 AppArmor は“プログラム単位の制限” AppArmor の見方は難しくありません。一言で言えば、 実行ファイルごとに許可された操作を定

chmodだけで終わらせない、DACとACLの実践的な使い分け Linux を触っていると、最初に覚えるアクセス制御はたいてい chmod と chown です。実際、それだけでもかなり多くのことはできます。ですが、少し運用らしいことを始めると、すぐに足りなくなります。 たとえば、あるディレクトリは基本的に開発者グループだけが触れるようにしたい。ただし監査担当の1人だけは読み取りだけ許可したい。こうした要件は珍しくありません。むしろ日常的です。 この種の制御を理解するうえで、最初に押さえるべきなのが任意アクセス制御（DAC: Discretionary Access Control）です。Linux の通常の所有者・グループ・その他の権限は、まさにこの DAC にあたります。さらに POSIX ACL も、この DAC を実務向けに拡張した仕組みです。 この記事では、Ubuntu VM 上で DAC を実際に触りながら、chmod の基本だけでなく、 ACL を含めてどう使い分けるか まで見ていきます。 まずは検証用ユーザーを作る...

“もう一つの署名”が持つ意味 PQC の署名方式を考えるとき、まず中心になるのは ML-DSA です。一方で、実運用を前提にすると、それだけで整理を終えるのはやや危うい見方でもあります。政府、金融、重要インフラのように移行期間が長く、影響範囲も広い領域では、単一の数学的前提に依存しすぎない設計にも意味があります。NIST は ML-DSA に加えて SLH-DSA も標準化しており、署名のPQC移行は「どの方式を主に使うか」だけでなく、「別系統の方式をどう持つか」まで含めて考えるべき段階に入っています。 SLH-DSA の重要性は、単に“別の署名方式がある”という話ではありません。ML-DSA とは異なる基盤を持つ標準方式が用意されていること自体が、長期運用や高価値資産を扱う設計において意味を持ちます。PQC を実務として捉えるなら、SLH-DSA は予備知識ではなく、暗号アジリティを考えるうえで押さえておくべき要素です。 SLH-DSA は何をするアルゴリズムか SLH-DSA は、NIST が FIPS 205 で定めた stateless

Hyper-VでLinux系のVMを構築していると、Hyper-Vマネージャー上ではVMが「実行中」になっているのに、VMConnectの画面が黒いまま、ログイン画面が出ない、あるいはGUIの起動途中で止まったように見えることがあります。 この状態になると、VMが壊れた、インストールに失敗した、ネットワークやディスク設定を間違えた、と考えてしまいがちです。 しかし、実際にはVMそのものは正常に起動していて、GUIの表示やログインマネージャだけがうまく出ていないという場合があります。 そのときに試したいのが、仮想コンソールの切り替えです。 VMConnect画面でCtrl + Alt + F2 / F3 / F4を試す VMConnectの画面を開いた状態で、以下のキーを押します。 Ctrl + Alt + F2 これで反応がなければ、続けて以下も試します。 Ctrl + Alt + F3 Ctrl + Alt + F4 Linuxでは、GUIの画面とは別に、CUIでログインできる仮想コンソールが用意されていることがあります。 そのため、GUI側の