【テクニカル・上級編】 SELinux/AppArmorによる強制アクセス制御 (MAC) の実装 – インフラ・ネットワーク & クラウドセキュリティ防御ガイド

強制アクセス制御（MAC）の真髄：SELinux/AppArmorで「侵入後の絶望」を設計する

多くのエンジニアは、OSの要塞化を「不要なポートを閉じること」や「パッチを当てること」だと勘違いしている。しかし、現実のインシデント現場では、それは単なる儀式に過ぎない。CVEの数は年間数千件を超える。未知のゼロデイ、あるいはライブラリの依存関係に潜む脆弱性によって、アプリケーションが「乗っ取られること」を前提とする設計——それが、我々が目指すべき「ゼロトラスト・ホスト」の姿だ。

今日は、Linuxの防衛線における最後の砦、MAC（強制アクセス制御）について語ろう。

1. 権限の分離は「論理的な壁」ではない、「物理的な牢獄」である

従来のDAC（任意アクセス制御）は、ユーザーIDやグループIDによる「所有権」に基づく。しかし、Webサーバーのプロセスがwww-dataユーザーで動いている場合、そのユーザーがアクセスできるファイルは、すべて攻撃者の手に落ちる可能性がある。

ここで導入するのがSELinuxやAppArmorによるMACだ。これは「プロセスが何をできるか」を、OSカーネルレベルで厳密に定義する。たとえ実行ユーザーがrootであっても、ポリシーで許可されていないファイル操作やソケット通信は、カーネルが冷徹に拒絶する。

SELinuxの深淵：ドメインとタイプの概念

SELinuxの難解さは、その「コンテキスト」にある。だが、本質はシンプルだ。

ドメイン (Domain): プロセスが動作する「場所」
タイプ (Type): ファイルやソケットが持つ「属性」

この二つを紐付けることで、「httpd_t（Webサーバー）は、web_content_t（コンテンツ）のみを読み取り可能であり、etc_t（設定ファイル）への書き込みは一切認めない」という制御が可能になる。

2. 現場で使えるAppArmorプロファイル設計（実例）

SELinuxの学習コストに腰が引けるなら、AppArmorから始めることを推奨する。Ubuntuなどのディストリビューションで標準採用されており、パスベースの制御が直感的だ。

例えば、特定のバックエンドAPIプロセスが、特定のディレクトリ以外に触れないようにするプロファイル例を挙げる。

# /etc/apparmor.d/usr.bin.myapp
# プロファイル定義の開始
profile my-secure-api /usr/bin/myapp flags=(attach_disconnected) {
  # 基本的な読み取り許可
  /usr/bin/myapp r,
  /etc/ld.so.cache r,
  
  # 特定の設定ファイルのみ読み取り許可
  /etc/myapp/config.yaml r,
  
  # ログファイルへの追記のみ許可（上書きや削除は不可）
  /var/log/myapp/app.log w,
  
  # ネットワークアクセスを制限（TCP 8080のみ）
  network inet stream,
  
  # 重要なディレクトリへのアクセスを一切拒否
  deny /etc/shadow w,
  deny /home/** w,
}

このプロファイルを aa-enforce モードで適用すれば、仮にあなたの書いたコードにRCE（リモートコード実行）の脆弱性があったとしても、攻撃者はシステム全体のファイルシステムを探索することも、/etc/shadowを盗み出すこともできない。

3. 生成AI時代のガードレイルと脅威モデル

最近、我々が直面しているのは、LLMを活用したアプリケーションのセキュリティだ。プロンプトインジェクションによって外部APIを不正に叩かれたり、意図しないライブラリがロードされるリスクがある。

ここでMACが果たす役割は、「ガードレイルの物理的固定」だ。
アプリが外部のAIサービスと通信する際、そのプロセスに「特定のIP/ドメインへの通信のみを許可するネットワーク名前空間」と、MACによる「実行可能ファイルのロード制限」を組み合わせる。

例えば、攻撃者がLLMの出力を使ってPythonの subprocess モジュールでシェルを起動しようとしても、MACポリシーで execve システムコールを禁止していれば、攻撃はそこで物理的に破綻する。

4. 監査と運用の泥臭い現実

MACの最大の敵は「複雑さ」ではなく「運用コスト」だ。厳しすぎるポリシーはシステムの更新を阻害し、開発者の生産性を殺す。

私が推奨する運用フローは以下の通りだ。

1. Complain Mode（学習モード）: 最初は違反をブロックせず、ログだけを吐かせる。
2. 監査ログの解析: ausearch や aa-logprof を使い、実際に必要なアクセスを抽出する。
3. ポリシーの最小化: 必要なアクセスのみを許可するポリシーを生成し、不要な通信経路を「デフォルト拒否」の状態へ移行する。
4. IaCによる管理: ポリシーをGitで管理し、CI/CDパイプラインの一部としてデプロイする。

最後に：防御の哲学

「完璧なソフトウェアなど存在しない」というのは、エンジニアの共通認識だ。だからこそ、我々は「バグがある前提」の多層防御を構築しなければならない。

MACの導入は、単なるOS設定ではない。それは「攻撃者の行動を制限し、彼らにコストを強いる」という、セキュリティアーキテクトとしての意思表示だ。攻撃者は常に「最も抵抗の少ない道」を選ぶ。MACであなたのホストを「最もコストの高い標的」に変えてしまえば、彼らは次の獲物を探して去っていくだろう。

防衛とは、戦うことではなく、戦う理由を奪うことにある。今日から、君のLinuxサーバーを「ただのコンピュータ」から「難攻不落の要塞」へと進化させてほしい。