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

泥棒が家に入っても「金庫」が開かない仕組み ― SELinux/AppArmorでサーバーを守る

こんにちは！インフラやセキュリティの世界へようこそ。
初めてサーバーを触る時、「設定を間違えて動かなくなったらどうしよう」と不安になりますよね。特にLinuxのセキュリティ機能である「SELinux」や「AppArmor」は、多くのエンジニアが最初にぶつかる高い壁です。

今回は、この「強制アクセス制御（MAC）」という少し難しそうな仕組みを、皆さんの身近な「家の防犯」に例えて、なぜこれが必要なのか、そしてどう付き合っていくべきなのかを解説します。

—

1. なぜ「ファイアウォール」だけでは足りないの？

多くの人は、サーバーを守るために「ファイアウォール」という門番を立てます。これは「家の門に鍵をかける」ことと同じです。

しかし、もし泥棒が窓を割ったり、合鍵を作ったりして家の中に侵入してしまったらどうなるでしょう？従来のLinuxの権限管理（ユーザー権限）だけだと、泥棒は「家主（root）」のふりをして、家中を自由に歩き回れてしまいます。

そこで登場するのが、SELinuxやAppArmorです。
これらは、家の中に「さらに厳重な金庫」を設置するようなもの。泥棒が家に侵入できたとしても、金庫に鍵がかかっていれば、中の大事なデータ（パスワードや顧客情報）を盗むことはできません。これが「強制アクセス制御（MAC）」の正体です。

—

2. 現場で一番大切な「強制」の考え方

SELinux（RedHat系に多い）やAppArmor（Ubuntu系に多い）は、プロセス（プログラム）に対して「お前はこれ以外の場所には触るな！」という厳しい行動制限リストを突きつけます。

例えば、Webサーバー（ApacheやNginx）が、本来は「公開用の画像データ」しか触る必要がないのに、誤って「パスワードファイル」まで読み込めてしまったら大変ですよね？この制限を強制的にかけるのがポリシー設定です。

アプリを「檻」に入れる（AppArmorの例）

Ubuntuなどでよく使われるAppArmorを例にしましょう。設定は非常にシンプルです。

/etc/apparmor.d/ 以下にある設定ファイルを見ると、プログラムがどこまでアクセスできるかが書かれています。

# 例えば、Webサーバー用のプロファイル設定例
# /etc/apparmor.d/usr.sbin.apache2

profile apache2 /usr/sbin/apache2 {
  # 読み取りを許可するディレクトリ
  /var/www/html/ r,
  /var/www/html/** r,

  # 書き込みを禁止し、誤作動時の被害を防ぐ
  /etc/shadow w,  # これは絶対に禁止！
}

このように「このアプリはここだけ触っていいよ」と宣言しておくことで、万が一プログラムに脆弱性が見つかって攻撃されても、そのプログラムは「許可されていない場所」には一歩も踏み込めないのです。

—

3. 「動かない！」と焦った時のトラブルシューティング

SELinuxやAppArmorを導入して一番困るのが、「突然Webサイトが表示されなくなった！」というトラブルです。これは、セキュリティが厳しすぎて、プログラムの正当な動作まで止めてしまっている状態ですね。

そんな時は、「ログを確認する」のが鉄則です。

SELinuxでブロックされたか確認する方法

SELinuxが原因で拒否されたログは、システムログに残ります。

# 拒否されたログをピンポイントで検索するコマンド
sudo grep "denied" /var/log/audit/audit.log

もし、あなたが自分で作ったプログラムがブロックされているなら、それは「必要な権限を与え忘れている」サインです。焦って setenforce 0（無効化）で逃げたくなる気持ちは分かりますが、それは防犯カメラを壊すのと同じです。

代わりに、以下の手順を試してください。

1. ログを見て何が拒否されたか確認する
2. ポリシーを修正する（または許可を与える）

例えばファイルコンテキスト（ラベル）がずれている場合：

# 公開用ディレクトリに正しいラベルを付与する例
    sudo chcon -Rt httpd_sys_content_t /var/www/html/my-app

—

4. 一歩ずつ、確実に。今日からできること

最初から完璧なポリシーを作る必要はありません。まずは以下のステップから始めてみてください。

1. 今の状態を知る: サーバーで getenforce (SELinux) や aa-status (AppArmor) を打ち、今動いているか確認しましょう。
2. 「許可」の概念に慣れる: 開発環境でわざとポリシーを厳しくして、「どうすればエラーが出るか」を実験してみるのが一番の近道です。
3. エラーログを怖がらない: ログは「ここを直せばもっと安全になるよ」というサーバーからのメッセージです。

セキュリティは、一度設定して終わりではありません。泥棒が常に新しい道具を開発するように、私たちも運用しながら少しずつ鍵を強くしていく。その「泥臭い積み重ね」こそが、真のエンジニアを育て、強固なシステムを支えるのです。

最初は難しく感じるかもしれませんが、大丈夫。一つずつ「金庫の鍵」を増やしていけば、あなたのサーバーはどんな攻撃にも負けない要塞になりますよ！