サービス実行ユーザ命名規約の指針

by

構築・運用時に困らないLinux系OSのサービス実行ユーザ名の基本ルールについての考察

1. はじめに

自作アプリケーションをサービスとして実行するユーザの命名って結構悩みませんか。

Linuxで自作アプリケーションを運用する際には、「アプリケーションをサービスとして実行するユーザ（サービス実行ユーザ）」を用意することが一般的かと思います。全てのアプリケーションをrootで動かすことはセキュリティ面・運用面で大きなリスクにつながるためです。サービス実行ユーザの命名は軽視されがちですが、最初にルールを決めておくことで、後からの混乱を防ぐことができます。

なお、RockyLinux9(RHEL系)を基準に記事を作成しています。Ubuntu(Debian系)など別の系列のディストリビューションをお使いの場合は、各ディストリビューションの流儀に読み替えてご覧ください。

2. サービス実行ユーザを分ける理由

  • セキュリティ原則（最小権限の徹底）
  • サービスごとに権限を分離し、障害切り分けを容易にする
  • ログの出所(ログの出力元となったサービス実行ユーザ)を明確にできる

3. 命名規則の基本方針

筆者の環境ではサービス実行ユーザは以下の基本方針に従って命名しています。
「絶対にこうでなくてはならない」というものではないのですが、実際に長年運用しながら調整をしてきた結果、この方針に落ち着きました。

  • 小文字・半角英数字で統一する
  • OSやパッケージ、OSSが用意したユーザ名はそのまま使用する。
  • メーカや外部業者が作成したアプリやシステムのサービス実行ユーザ名は<vendor>-<app>形式を基本とする。
  • 自作・社内システムの場合は<vendor>部分に社名やプロジェクト名に置き換える。
  • 15文字以内を目安にして長すぎる名前を避ける。

4. よく使うパターン

OSSアプリケーション

OSSの実行ユーザはOSSの慣習に従います。たとえば、nginx、postgres、apacheなどです。自分で作成しなくてもパッケージ導入時にサービス実行ユーザが自動生成されるケースが多いです。

自作アプリ・社内システム

自作アプリや社内システムでは、社名略称などをプリフィクスにしておくと衝突を避けられます。たとえば、xcorp-crmやxcorp-sfaのように統一すれば、複数アプリを並行して運用しても混乱がありません。

避けるべき例

  • 全てのサービスを同じサービス実行ユーザ(例：appuser)でまとめてしまう
    • セキュリティ的に望ましくないことに加え、ログの見分けが困難になることで障害発生時の切り分けが難しくなることがあります。
  • 個人の名前やイニシャルをそのまま使う
    • 例えばtanakaやyamadaといった個人名や、id123456のような法則性のない値をサービス実行ユーザ名に使うと作業のパターン化や障害発生時の調査などで非常に困ることがあります。
  • 日本語や大文字混じりのユーザ名
    • Windowsだとたまに見かけますが日本語ユーザ名は誤動作・不具合の温床になりかねません。また大文字混じりですと運用作業でのキーボード操作で打鍵ミスを誘発します。

5. 権限と補助ルール

筆者の環境では自作アプリ・社内システムのサービス実行ユーザは命名規則に加え、以下の補助ルールを適用しています。

  • ログインシェルスクリプトを無効に設定する。(/usr/sbin/nologinを指定する。)
      • 通常、サービス実行ユーザはOSに対話的にログインする必要はありません。ログインシェルスクリプトを無効に設定することで潜在的なリスクを低減することができます。
    • ユーザIDをサービス実行ユーザID領域に設定する。
      • 一般ユーザのユーザID(例：1000～)ではなく、OSデフォルトまたは慣例的にサービス実行ユーザに付与されるユーザIDの範囲(例：1～999)にすることで「このユーザはサービス実行用ユーザである」ということが分かるようにしています。
    • ホームディレクトリが必要な場合は/opt/<vendor>/<app>とする。
          • /home/配下を避けて /opt/<vendor>/<app>に置くことで、一般ユーザではないと区別できるようにしています。
        • sudo権限付与は原則禁止する。
          • 適切にセキュリティ設定が行われていれば、自作アプリ・社内システムのサービス実行ユーザがsudoの実行が必要になる場面は無いか、あったとしても限られた条件と考えられるため、原則sudo権限を付与していません。

        6. まとめ

        サービス実行ユーザは「当該サービス専用」で作成し、<vendor>-<app>形式で命名すると長期運用にも耐えられると考えています。

        Linux標準の流儀に従いつつ、自社アプリ命名規則を定義しておくと運用効率が意外と変わります。小さな工夫ですが、長期運用でのコスト削減につながります。