“ユーザーやロールだけで決めない”アクセス制御を、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 を含めてどう使い分けるか まで見ていきます。 まずは検証用ユーザーを作る...

CA を学ぶとき、OpenSSL だけでは少し見えにくいものがあります。たとえば、管理者は誰なのか、どの利用者にどのプロファイルで証明書を出すのか、発行後の監査や権限分離をどう考えるのか、といった運用の側面です。そうした“ちゃんとした PKI”の空気を自宅 lab に持ち込みやすいのが EJBCA Community です。公式には Community コンテナを使った quick start が用意されており、Docker で短時間に試せます。 EJBCA の良さは、単に証明書を一枚作るだけで終わらないことです。CA、エンドエンティティ、管理者証明書、プロファイルといった要素が UI 上で見え、PKI を“運用する仕組み”として理解しやすい構造になっています。自宅環境でも、企業や組織で使う CA 製品の手触りをかなり具体的に確認できます。 (docs.keyfactor.com) この記事で扱う内容 今回は Ubuntu VM 上で Docker を使って EJBCA Community を起動し、以下を確認します。 Docker 環境の準備

証明書を自宅で試そうとすると、多くの人はまず OpenSSL を思い浮かべるはずです。秘密鍵を作り、CSR を作り、署名し、必要なら失効や配布を考える。PKI を学ぶ入り口としては王道ですが、運用の現場では証明書のライフサイクル全体を管理できるような仕組みが利用されています。 HashiCorpのVaultは、OpenSSLよりも何段階もステップアップした証明書管理が行えるツールの一つです。また、証明書管理の自動化を前提にした仕組みを味わえるのがVaultの特徴でもあります。誰が、どんな条件で、どんな寿命の証明書を受け取れるかをAPIとポリシーにより制御するという思想で作られています。HashiCorp 公式でも、通常の手動フローを経ずに動的な X.509 証明書を発行できる仕組みとして説明されています。 (HashiCorp Developer) 今回は、このVaultによる証明書管理サーバーを実際に構築し証明書管理の基本やVaultについて学んでいきたいと思います。 この記事で扱う内容 今回は Ubuntu VM 上に検証用の Vault サ

Hi, there. 本日は、過去に投稿した「Splunkを使用した監査環境の構築」のWazuh版です。 Splunkの環境構築時に作成した監査対象サーバーを流用し、Splunkとの見え方の違いを見ていきたいと思います。 Wazuhには、中央コンポーネントを同一ホストにまとめた all-in-one 構成が案内されています。そのため、Splunk や Elastic と比べると最初から 監査項目の型をかなり持っており、ログを見るだけではなく、ファイル改ざん、設定不備、脆弱性まで含めて「そのホストが今どういう状態か」を見せるのが得意です。 今回の構成 今回の構成もシンプルです。 Wazuhサーバー Ubuntu Server 24.04 LTS Wazuh all-in-one 構成 名前：wazuh タイプ：Linux バージョン：Ubuntu (64-bit) メモリ：4096MB CPU：2 仮想ディスク：20GB 監査対象サーバー 前回の Splunk 編で作成した Ubuntu Server 24.04 LTS ネットワークの構成.

Hi, there. 本日は、以前投稿したOpenSCAPの記事について深堀し、具体的な手順をお伝えします。 OpenSCAPで“まず安全側のベースラインを一気に作る”手順 Linux のハードニングで最初に消耗しやすいのは、設定の難しさそのものより、項目数の多さです。SSH、パスワード、ファイル権限、不要サービス、監査設定、カーネルパラメータを一つずつ手で詰めるやり方は、どうしても時間がかかり、設定漏れや設定ゆれも起きやすい。そこで発想を変えて、最初から ベンチマーク準拠のベースラインへまとめて寄せる ために使いたいのが OpenSCAP です。Red Hat は OpenSCAP を、設定コンプライアンススキャン、脆弱性評価、レポート生成、remediation に使う仕組みとして案内しています。 この記事の主題は「監査して学ぶこと」ではありません。最短で、安全寄りの標準形を作ることです。手順としては、WSL の Ubuntu を整える → OpenSCAP を入れる → 利用可能なプロファイルを確認する → ベースラインとの差分を評価する