こんにちは！インフラや開発の現場に飛び込んだばかりの頃は、覚えることが山積みで本当に大変ですよね。「セキュリティをしっかりやろう」と言われても、専門用語ばかりで頭がクラクラしてしまうこともあると思います。
でも、安心してください。今回は、Linuxサーバーの守りを何段階も強固にする「SELinux / AppArmorによる強制アクセス制御（MAC）」について、難しい理論は少し横に置いて、身近な防犯の仕組みに例えながら、一歩ずつ優しく紐解いていきます。
現場の第一線で戦うエンジニアが「これだけは知っておいてほしい！」というポイントをギュッと詰め込みましたので、ぜひコーヒーでも飲みながらリラックスして読んでいってくださいね。
—
1. 家の鍵で例える「自主的アクセス制御（DAC）」と「強制アクセス制御（MAC）」
サーバーのセキュリティを考えるとき、まず思い浮かべるのがファイルのアクセス権（オーナー、グループ、その他に対して、読み取りや書き込みを許可する権限）ですよね。Linuxの世界ではこれをchmodやchownなどで設定します。
これは、防犯に例えるなら「家の中の各部屋に鍵をかける仕組み」です。
- 自主的アクセス制御（DAC: Discretionary Access Control）
- あなた（ファイルの所有者）が、「この部屋の鍵はあの人にあげよう」「この部屋は誰でも入れるようにしよう」と、自分の判断で自由にあちこちの鍵を配る状態です。
- 非常に柔軟で便利なのですが、もし「あなた（所有者）」がうっかり不審者に合鍵を渡してしまったり、重要な部屋の鍵を開けっぱなしにしたりすると、家全体が危険にさらされてしまいます。
では、今回の主役である強制アクセス制御（MAC: Mandatory Access Control）はどうでしょうか？
- 強制アクセス制御（MAC: SELinux / AppArmor）
- これは、家のオーナーの気まぐれやミスに関係なく、「警察官（OSのセキュリティ機構）が常駐し、すべての人の行動を厳しく監視・制限する仕組み」です。
- たとえリビングの鍵が開いていようとも、警察官が「あなたにその部屋に入る権限はありません！」と強制的に立ち入りを禁止してくれます。
つまり、万が一Webサーバーなどのプロセス（プログラム）がサイバー攻撃によって乗っ取られてしまったとしても、「そのプロセスは外に出られない」「他の大事な設定ファイルは見られない」という強力な足止めをしてくれるのがMACの正体です。
—
2. なぜ「プロセスが乗っ取られた後」を想定するのか？
セキュリティの鉄則として、「100%の侵入防止は不可能である」という前提に立つ必要があります。どんなに頑丈なWebアプリケーションを作っても、未知の脆弱性（ゼロデイ攻撃）や、設定のわずかなミスから侵入されるリスクはゼロにはなりません。
従来のLinuxセキュリティ（DAC）のままだと、例えばWebサーバーのプロセス（www-dataユーザーなど）がハッカーに乗っ取られた場合、そのプロセスが持っている権限の範囲内のファイル（例えば、Webサイトの公開ディレクトリや設定ファイルなど）がすべて書き換えられたり、盗み見られたりしてしまいます。
ここでSELinuxやAppArmorといったMACが有効になっていると、たとえハッカーにWebサーバーのプロセスを乗っ取られても、「Webサーバーのプロセスは、決められたディレクトリ以外にアクセスしてはならない」「他のシステムファイルを読み込んではならない」という厳しいルール（ポリシー）によって、被害がその場所にピタッと封じ込められます。
まさに、船の防水区画（バルクヘッド）のようなもので、どこかに穴が開いても、船全体が沈むのを防いでくれる頼もしい盾なのです。
—
3. 代表的な2つの仕組み：SELinuxとAppArmorの違い
Linuxディストリビューション（OSの種類）によって、標準で使われるMACの仕組みが異なります。それぞれの特徴をざっくりと見ておきましょう。
- SELinux（Security-Enhanced Linux）
- 主な採用OS：Red Hat Enterprise Linux (RHEL)、CentOS、Fedora、Amazon Linuxなど
- 特徴：非常にきめ細やかで強力な制御ができますが、そのぶん設定やルールの記述が複雑で、初心者のうちは「あれ？ なぜか動かない？」と悩まされがちです（通称：SELinuxに嫌われる現象）。
- AppArmor
- 主な採用OS：Ubuntu、Debian、openSUSEなど
- 特徴：SELinuxよりもファイルパスベースで直感的にルールを記述しやすく、比較的ライトに導入・管理できるのが魅力です。
どちらを使う場合でも基本的な考え方は同じです。「プロセスごとに専用の身分証（コンテキストやプロファイル）を渡し、行動範囲をガチガチに制限する」ことになります。
—
4. 実践！AppArmorのシンプルな設定例を見てみよう
今回は、初心者の方でも比較的直感的に理解しやすい AppArmor を例に取って、実際にどのようにポリシーが動いているのかを覗いてみましょう。
AppArmorのポリシーファイルは、通常 /etc/apparmor.d/ というディレクトリに保存されています。例えば、特定のWebアプリケーション（ここでは架空のプログラム /usr/bin/my-webapp とします）に対する設定ファイルの中身をイメージしてみましょう。
# /etc/apparmor.d/usr.bin.my-webapp
# 尖った設定をする前の、基本的なAppArmorプロファイルのサンプルです
# このプロファイルが適用されるプログラムのフルパスを指定します
#include <tunables/global>
/usr/bin/my-webapp {
#include <abstractions/base>
# 1. ログの書き込みは許可するディレクトリを指定
/var/log/my-webapp/ r,
/var/log/my-webapp/w,
# 2. アプリケーションがデータを保存するワークディレクトリへの読み書きを許可
/var/lib/my-webapp/ rw,
/var/lib/my-webapp/** rwk,
# 3. システムの重要な設定ファイルや機密ファイルへのアクセスは一切禁止（暗黙の拒否）
# /etc/shadow や /etc/passwd などへのアクセスはここでブロックされます
}このように、「このプログラムは、ここからここまでしか触ってはいけない」というルールを明文化しておきます。
AppArmorの現在の状態を確認するコマンド
お使いのUbuntuなどのサーバーで、現在どのプログラムがどのように守られているかを確認するには、以下のコマンドをターミナルで実行してみましょう。
# 現在稼働しているAppArmorのプロファイルのステータスを確認する
sudo aa-statusもし新しく作ったアプリケーションに対して監視を始めたい場合（エンフォースモード＝違反を厳しくブロックするモードへの切り替え）は、以下のようにコマンドを叩きます。
# 特定のプロファイルを「強制（Enforce）」モードにする
sudo aa-enforce /etc/apparmor.d/usr.bin.my-webapp※もし設定で躓いたときは、慌てて機能をオフにするのではなく、ログ（/var/log/syslog や journalctl）を確認して「どのルールに引っかかったのか」を調べるのがトラブルシューティングの近道です。
—
5. SELinuxの基本と「寛容モード（Permissive）」という逃げ道
Red Hat系（RHELやAlmaLinuxなど）でよく使われるSELinuxについても、実務で絶対に知っておくべきポイントを一つだけご紹介します。
SELinuxには、主に次の3つのモードがあります。
1. Enforcing（強制モード）
- ポリシーに違反するアクセスを完全にブロックし、ログに記録する（本番環境のデフォルト）。
2. Permissive（寛容モード）
- ポリシーに違反するアクセスがあっても、ブロックはせずに「警告」としてログに記録だけする。
3. Disabled（無効化）
- SELinux機能を完全にオフにする。
実務で新しいミドルウェアや独自のアプリケーションを導入するとき、いきなり Enforcing モードで動かすと、必要なファイルにアクセスできずにアプリが起動しなくなることがよくあります。
そんなときの鉄則のワークフローは以下の通りです。
# 1. まず現在のモードを確認する
getenforce
# 2. トラブルシューティングや初期構築時は「寛容モード」に一時的に切り替える
sudo setenforce 0
# 3. アプリを動かしてみて、SELinuxがどんな文句（拒否ログ）を言っているか確認する
sudo grep avc: /var/log/audit/audit.log
# 4. ログを元にポリシーを調整したら、再び「強制モード」に戻す！
sudo setenforce 1「動かないからといって、すぐにSELinuxを Disabled にして投げ出さない」これが、プロのインフラエンジニアとしての腕の見せ所であり、セキュリティレベルを保つ秘訣です。
—
まとめ：一歩ずつ、確実な守りを身につけよう
今回は、SELinuxやAppArmorによる強制アクセス制御（MAC）について、家の防犯や実務の現場を交えて解説しました。
- 自主的アクセス制御（DAC）だけでは、オーナーのミスや乗っ取りに弱い。
- 強制アクセス制御（MAC）を入れることで、万が一プロセスが乗っ取られても、被害を最小限に食い止められる（被害の局所化）。
- 導入時はログをしっかり確認しながら、焦らずモードを調整していく。
最初は難しく感じるかもしれませんが、「プロセスごとに専用の行動制限ルールを持たせる」というコンセプトが分かっていれば、エラーに遭遇しても怖くありません。
インフラやセキュリティの世界は、こうした地道な積み重ねが自分やチームのシステムを救う大きな盾になります。ぜひ今日の学びを、ご自身の開発環境や検証サーバーでも試してみてくださいね。一歩ずつ、確実にスキルアップしていきましょう！
コメント