概要

• systemd は多機能で堅牢なサービス管理を提供
• デフォルトでは セキュリティ最適化 は十分でない場合が多い
• systemd-analyze security で現在の設定を可視化可能
• 各サービスごとに 個別のハードニング が必要
• 本記事はsystemdサービス/Podman Quadletの セキュリティ強化手法 の解説

systemdサービスのセキュリティハードニング入門

• systemd はサービス管理や多様なOS機能の制御を担うフレームワーク
• デフォルト設定は 利便性重視 であり、セキュリティは最低限
• セキュリティ強化 は個別サービスの要件やリスクに応じて調整が必要
• 本記事は 推奨設定例 や 分析方法 のガイド

注意事項

• 本ガイドは 推奨例 であり、全ての環境に適合するものではない
• サービスごとに 必要な権限 や設定は異なるため、事前検証が必須
• 変更後は ログ確認 と 動作検証 を徹底

systemdのセキュリティ分析方法

• systemd-analyze security コマンドで全サービス、または個別サービスの セキュリティ状況 を確認
  • 例：sudo systemd-analyze security sshd.service
• 出力には 各種セキュリティ制御 の有効/無効、説明、リスクスコアが表示
• Exposure 値（リスクスコア）を参考に、優先順位を決定
• Name 欄はunitファイルで設定する際のキーワード

設定変更方法

• セキュリティキーは [Service]セクション （systemd）または [Container]セクション （Podman Quadlet）に記載
• 設定ファイルの場所
  • /etc/systemd/system/
  • /etc/containers/systemd/
• systemctl edit サービス名.service でオーバーライド設定が可能
  • 例：EDITOR=nvim sudo systemctl edit サービス名.service
• 手動で/etc/systemd/system/サービス名.service.d/override.confを作成も可
• 変更後、サービスが起動しない場合は 必要な権限を再確認

主要なセキュリティオプション一覧

• ProtectSystem ：ファイルシステム全体を読み取り専用化
• ReadWritePaths ：特定パスのみ書き込み許可
• ProtectHome ：/home, /root, /run/userへのアクセス制限
• PrivateDevices ：物理デバイスアクセス遮断、疑似デバイスのみ許可
• ProtectKernelTunables ：/proc, /sysを読み取り専用
• ProtectControlGroups ：cgroupsを読み取り専用
• ProtectKernelModules ：カーネルモジュールのロード禁止
• ProtectKernelLogs ：カーネルログバッファへのアクセス制限
• ProtectProc ：他ユーザープロセスを/procから不可視化
• ProcSubset ：/proc内でプロセス管理関連以外を不可視化
• NoNewPrivileges ：新たな権限獲得禁止
• ProtectClock ：システムクロック書き込み禁止
• SystemCallArchitectures ：ネイティブシステムコールのみ許可
• RestrictNamespaces ：namespace機能の制限
• RestrictSUIDSGID ：setuid/setgidビットの設定禁止
• LockPersonality ：実行ドメインの変更禁止
• RestrictRealtime ：リアルタイムスケジューリングの制限
• RestrictAddressFamilies ：利用可能なソケットアドレスファミリー制限
• MemoryDenyWriteExecute ：書き込み・実行可能なメモリ領域の確保禁止
• ProtectHostname ：ホスト名変更システムコールの禁止
• SystemCallFilter ：許可するシステムコールのグループ制御
  • 例：SystemCallFilter=@system-service
  • 否定：SystemCallFilter=~@chown
  • エラーコード返却：SystemCallErrorNumber=EPERM

システムコール制御のトラブルシュート

• auditd を利用し、違反発生時にsudo ausearch -i -m SECCOMP -ts recentでログ確認
• ログ中の syscall名 をSystemCallFilterに追加して再試行

優先的に検討すべきセキュリティ項目

• ProtectSystem=strict

• PrivateTmp=yes

• ProtectHome=yes または ProtectHome=tmpfs

• ProtectClock=yes

• ProtectKernelLogs=yes

• ProtectKernelModules=yes

• RestrictSUIDGUID=yes

• UMask=0077

• LockPersonality=yes

• RestrictRealtime=yes

• MemoryDenyWriteExecute=yes

• DynamicUser=yes または User=非rootユーザ

  • これらは多くのサービスで有効だが、動作要件によっては適用不可の場合もあり

適用例：Traefik Quadletユニット

• TraefikのPodman Quadlet用unitファイル例

  • [Unit]

    • Description=Traefik Reverse Proxy with Socket Activation
    • Requires=http.socket https.socket

  • [Container]

    • ContainerName=traefik
    • HostName=traefik
    • Image=docker.io/traefik:v3
    • Network=traefik.network
    • Volume=traefik-config.volume:/etc/traefik/:Z
    • Volume=/var/log/traefik:/logs/:Z
    • AutoUpdate=registry
    • Notify=true
    • HealthCmd=CMD-SHELL traefik healthcheck --ping
    • HealthInterval=10s

  • サービス用途や運用形態に応じて 柔軟な調整 が必要

まとめと運用のポイント

• systemdの セキュリティ強化 は「リスク管理」と「運用要件」のバランスが重要
• 外部公開サービス（nginx, httpd, Traefik, ssh等）から優先的に適用
• カスタムスクリプト や 自作サービス には積極的なハードニング推奨
• 設定変更後は ログ解析 と 動作検証 を徹底
• manページ （man systemd.exec(5)等）が最新情報の信頼できる情報源

---

systemdサービスのセキュリティ強化 は地道な作業だが、インフラ全体の安全性向上に直結。 適切な設定・検証・運用 を心がけ、リスク低減を目指すことが重要。