SELinux 対 AppArmor：サーバーに適した MAC フレームワークは？

SELinuxとAppArmorは、どちらもLinux上で強制アクセス制御（MAC）を適用し、プロセスがroot権限を取得した場合でもその動作を制限します。両者の違いは、その実装方法にあります。SELinuxはすべてのファイルとプロセスに永続的なラベルを割り当てます。一方、AppArmorはファイルパスルールを使用します。この設計上の選択が、複雑さ、セキュリティの深度、そしてどのディストリビューションがデフォルトでどのツールを搭載するかといった、あらゆる要素を決定づけています。

SELinuxの仕組み

SELinuxはもともとNSAによって開発され、RHEL、CentOS、Fedora、Rocky Linuxにデフォルトで搭載されています。SELinuxは、ファイル、プロセス、ポート、ソケットなど、システム上のあらゆるオブジェクトに、次のような形式のセキュリティコンテキストを付与します user:role:type:levelの形式でラベル付けします。 type フィールドは、Type Enforcement（TE）と呼ばれるメカニズムを通じて、処理の大部分を担っています。

例えば、Apache Webサーバーは httpd_tとして実行されます。Webコンテンツファイルは別のタイプを持ちます。ポリシールールで明示的に httpd_t が許可されていない場合、リクエストは拒否されます。これはデフォルトで拒否するモデルです。ルールで許可されていない限り、何も許可されません。

SELinuxは、機密レベルによってデータを分類し、それに応じてアクセスを制限するマルチレベルセキュリティ（MLS）およびマルチカテゴリセキュリティ（MCS）もサポートしています。MCSこそがSELinuxに強力なコンテナ分離機能をもたらし、コンテナ同士やホストとの分離を維持します。これは、ポッドがノードを共有するKubernetesやOpenShift環境において重要です。

その代償として複雑さが伴います。SELinuxは習得が困難です。アクセス拒否のトラブルシューティングには、監査ログの確認、セキュリティコンテキストの理解、場合によっては audit2allow。専任のセキュリティ担当者がいないチームにとって、このオーバーヘッドは現実的な課題となります。

AppArmorの仕組み

AppArmorは異なるアプローチを採用しています。オブジェクトにラベルを付ける代わりに、ファイルパスに基づいてアプリケーションにセキュリティプロファイルを紐付けます。例えば、 /usr/sbin/nginx は、Nginxがどのディレクトリを読み取れるか、どのポートにバインドできるか、そしてどのような権限が必要かを定義します。プロファイルは、 /etc/apparmor.d/.

AppArmorは、Ubuntu、Debian、SUSEにおけるデフォルトのMACフレームワークです。バージョン2.6.36以降、Linuxカーネルの一部となっています。プロファイルが設定されていないアプリケーションは、標準のLinux DAC権限にフォールバックします。

AppArmorは、プロファイルごとに「Enforce」（違反をブロックしてログに記録）と「Complain」（ブロックせずに違反をログに記録）の2つのモードで動作します。これにより、新しいプロファイルを段階的に導入することが現実的になります。まずComplainモードで開始し、ログを確認してプロファイルを厳格化し、その後Enforceモードに切り替えます。

次のようなツール aa-genprof や aa-logprof などのツールは、アプリケーションの動作を監視し、その挙動からルールを生成することで、対話的にプロファイルを作成するのに役立ちます。SELinuxポリシーモジュールと比較して、構文は手作業で読みやすく、編集もはるかに簡単です。

欠点としては、パスベースのルールはファイルが移動しても追従しない点が挙げられます。理論上、ハードリンクやバインドマウントを使用すれば、パスベースの制限を回避することが可能です。また、AppArmorにはネイティブなMLS/MCSサポートがないため、SELinuxのようにホストからコンテナを隔離することはできても、コンテナ同士を相互に隔離することはできません。

並列比較

基本設定

SELinux

現在のステータスを確認します:

sestatus
getenforce

何もブロックせずに違反をログに記録するため、Permissiveモードで起動します：

setenforce 0

ほとんどのサーバーには「targeted」ポリシーを使用します。これにより、Webサーバーやデータベースなどの高リスクなサービスは制限され、それ以外のものは制限されません。これを永続化するには /etc/selinux/config:

SELINUX=enforcing
SELINUXTYPE=targeted

ファイルやプロセスのセキュリティコンテキストを確認する:

ls -Z /var/www/html
ps -eZ | grep httpd

サービスが非標準のポートを使用している場合は、ポリシーを更新します:

semanage port -a -t ssh_port_t -p tcp 9999

アクセス拒否が発生するカスタムアプリケーションについては、監査ログからポリシーモジュールを作成してください:

ausearch -m avc -ts recent | audit2allow -M my_custom_policy
semodule -i my_custom_policy.pp

AppArmor

読み込まれているプロファイルを確認します:

sudo aa-status

プロファイル管理ツールが必要な場合は、ユーティリティパッケージをインストールしてください:

sudo apt install apparmor-utils

アプリケーションの実行中に、対話形式でプロファイルを生成します:

sudo aa-genprof /path/to/binary

ログをスキャンして違反箇所を確認し、プロファイルを調整します:

sudo aa-logprof

プロファイルのモードを切り替える:

sudo aa-enforce /etc/apparmor.d/usr.sbin.nginx
sudo aa-complain /etc/apparmor.d/usr.sbin.nginx

どちらを使うべきか？

多くの管理者にとっての実用的な答えは、お使いのディストリビューションに標準搭載されているものを使用することです。RHEL、CentOS、Fedora、Rocky LinuxにはSELinuxが、Ubuntu、Debian、SUSEにはAppArmorが搭載されています。どちらのフレームワークも、それぞれのネイティブプラットフォーム向けに成熟したツールやポリシーを備えています。どのディストリビューションにおいても、デフォルト以外のオプションに切り替えることは作業の負担を増やし、コミュニティによるサポートを減少させることになります。

それ以外の場合は、要件に基づいて決定してください：

• PCI DSS、HIPAA、またはDISA-STIGへの準拠が必要な場合は、SELinuxを選択してください。KubernetesやOpenShift上でマルチテナントのコンテナワークロードを実行する場合。共有ホスト上でコンテナ間の分離が必要な場合。機密情報や機密レベルが設定されたデータを扱う環境の場合。
• UbuntuやDebianを実行しており、学習曲線が急ではないMAC保護を求めている場合は、AppArmorを選択してください。標準的なWebサービスを実行する単一サーバーまたは小規模クラスターの環境である場合。きめ細かなラベルレベルの制御よりも、迅速なデプロイメントが優先される場合。

どちらのフレームワークも、実行時のオーバーヘッドは最小限です。SELinuxはアクセス決定をAccess Vector Cacheにキャッシュします。AppArmorのポリシー読み込みは起動時にわずかな遅延を生じることがありますが、実行時には無視できる程度の影響しかありません。ほとんどのホスティングワークロードにおいて、どちらもボトルネックにはなりません。

どちらのフレームワークも設定するために完全なrootアクセス権が必要な、信頼性の高いホスティング基盤をお探しの場合は、FDCの専用サーバーまたはVPSをご利用ください。これにより、お客様の環境に合わせてSELinuxやAppArmorを自由に設定することができます。