「rootを取られたら終わり」という思考停止からの脱却：SELinux/AppArmorで実現する「防壁の中の防壁」
現場で数多のインシデントを見てきたが、未だに多くのエンジニアが「ファイアウォールを立てた」「OSを最新にした」だけで安全だと信じ込んでいる。だが、現実の攻撃者はそんな生ぬるい門番など鼻で笑って通り抜ける。
Webアプリの脆弱性（RCE等）を突かれ、Webサーバープロセスが乗っ取られた瞬間、そのサーバーは攻撃者の踏み台となる。この時、もし君が「DAC（任意アクセス制御）」のみ、つまり従来のパーミッション管理だけで運用しているなら、勝負はそこで決着だ。攻撃者はWebサーバー権限（www-data等）で動き回り、設定ファイルを読み取り、秘密鍵を盗み出し、あろうことか横展開の足掛かりにする。
これを防ぐための最後の砦が、MAC（強制アクセス制御）、すなわち SELinux や AppArmor だ。
—
なぜ「root権限」だけでは不十分なのか
従来のLinux権限管理では、一度プロセスが特定のユーザーIDを持てば、そのユーザーが許可された範囲内のことは何でもできてしまう。例えば、PHPの脆弱性でシェルが実行された場合、そのPHPプロセスは「Web公開ディレクトリの書き込み権限」を持っているため、バックドアを仕込むことが容易だ。
ここでMACの出番だ。MACは「ユーザーの権限」ではなく「プロセスの役割（ドメイン）」に基づいて、「そのプロセスが何にアクセスして良いか」をOSカーネルレベルで強制的に制限する。
たとえ攻撃者がPHP上でコマンド実行権限を得たとしても、SELinuxのポリシーが「Webサーバープロセスは /etc/shadow を読めない」「/tmp 以外への書き込みは許可しない」と定めていれば、攻撃者の指先はそこで止まる。これが「損害の最小化」だ。
—
実践：AppArmorによるWebサーバーの隔離
運用が複雑になりがちな SELinux も強力だが、今回は実務で即戦力となり、かつ管理コストが抑えられる AppArmor を例に解説する。
1. プロファイルの状態を確認する
まずは現在の制限を確認しよう。aa-status コマンドを叩いてみてほしい。
# 現在ロードされているプロファイルと、強制モード(enforce)になっているか確認
sudo aa-status2. 特定プロセス（PHP-FPM）をガチガチに縛る
例えば、PHP-FPMが特定のディレクトリ以外に触れないようにするプロファイル例だ。/etc/apparmor.d/php-fpm に以下の内容を作成する。
# プロファイル設定の例
profile php-fpm /usr/sbin/php-fpm7.4 {
# 基本的なライブラリへのアクセスは許可
/usr/lib/** r,
/usr/sbin/php-fpm7.4 mr,
# Webコンテンツディレクトリ：読み取りのみ許可（書き込みは禁止）
/var/www/html/** r,
# セッション保存先やログなど、必要な場所だけに限定して書き込み許可
/var/lib/php/sessions/** rw,
/var/log/php-fpm.log w,
# ネットワーク通信は必要最小限に制限（攻撃時のC2サーバー通信防止）
network inet stream,
# 上記以外の一切のアクセスを拒否（暗黙の拒否）
deny /etc/shadow r,
deny /root/** rwklx,
}3. モードを適用する
作成したら、プロファイルを有効化する。
# プロファイルをロード
sudo apparmor_parser -r /etc/apparmor.d/php-fpm
# 強制モードに変更（違反時は即座にブロックされログが残る）
sudo aa-enforce /etc/apparmor.d/php-fpm—
現場の鉄則：防御を「運用」にするための思考法
これを導入すると必ず「Webアプリの動作がおかしくなった！」とアラートが飛んでくる。だが、それは「今まで不要なアクセスが許容されていた」というリスクが顕在化した瞬間だ。
以下の手順で泥臭くチューニングするのが、プロの仕事だ。
1. complainモード（学習モード）の活用:
いきなり enforce せず、まずは sudo aa-complain /usr/sbin/php-fpm7.4 を実行する。これで「アクセス拒否」ではなく「拒否ログだけ記録」されるようになる。
2. ログの監視:
/var/log/audit/audit.log（SELinuxの場合）や dmesg を監視せよ。正常なアプリ動作で拒否されている箇所を特定し、ポリシーを修正する。
3. IAMとの合わせ技:
クラウド環境なら、OS上のMACとクラウド側のIAMを組み合わせる。例えば、サーバーが S3 にアクセスする際は、サーバーのインスタンスプロファイルに「特定のバケットへの読み込みのみ」というポリシーを付与する。OSとクラウドの二重の防壁で、攻撃者の逃げ場を完全に奪うのだ。
—
最後に：セキュリティは「設定して終わり」ではない
多くのエンジニアが「設定の複雑さ」を理由にMACを敬遠する。だが、ランサムウェアの被害に遭った後で「設定しておけばよかった」と後悔するのと、日々の運用で地道にプロファイルをメンテナンスするの、どちらがエンジニアとして価値があるか？
攻撃者は常に最短ルートで君のシステムの「隙間」を狙っている。その隙間を、MACという名の鋼鉄の網で塞ぐこと。それこそが、プロフェッショナルなインフラエンジニアの矜持だ。
まずは今すぐ、手元のテストサーバーで aa-status を叩くことから始めてほしい。それが、君のサーバーを「堅牢」へと変える最初の一歩だ。
コメント