メインコンテンツまでスキップ

clmBot 実行権限の要件

clmBot は証明書の自動更新時に、対象の証明書ファイルに対して読み書きを行い、更新後に該当するミドルウェアサービスをリロードまたは再起動する必要があります。本記事では、各ミドルウェアシナリオにおける推奨される最小権限構成について説明します。

説明

ミドルウェアの reload / restart コマンドは config.yaml の servers[].after_script フィールドで定義されており、ユーザーは実際の環境に応じて調整できます。clmBot は root や Administrator などの高権限アカウントで長期実行する必要はありません。

最小権限の原則​

専用のシステムアカウント（例：clmbot）で clmBot を実行することを推奨し、以下の原則に従います：

  • そのアカウントには、clmBot 設定、ログディレクトリ、および対象の証明書インストールポイントを読み取るために必要な権限のみを付与します。
  • clmBot が管理する証明書ファイル、秘密鍵ファイル、およびそれらの所在ディレクトリにのみ書き込み権限を付与します。
  • 確認済みのミドルウェア reload / restart コマンドのみ実行を許可し、NOPASSWD: ALL や完全な root 権限は付与しません。
  • before_script、after_script は必ず人による監査を受け、スクリプトに必要な権限は個別に付与します。

推奨しない方法：

  • clmBot を長期にわたって root または Administrator の身分で実行させる。
  • ミドルウェア構成ディレクトリ、証明書ディレクトリ、またはシステムサービスの制御権限を clmBot に全面的に開放する。
  • bash、powershell.exe、systemctl に無制限の実行権限を付与する。

各ミドルウェアの権限要件​

nginx​

clmBot には以下の権限が必要です：

  1. 証明書ディレクトリの読み書き権限：ターゲット証明書ファイル（.crt）、CA チェインファイル（任意）、および秘密鍵ファイル（.key）が存在するディレクトリに対して読み書き権限を持ち、新しい証明書を書き込み、.bak バックアップを作成できる必要があります。
  2. reload コマンドを実行する：after_script はデフォルトで以下のスクリプトを生成し、証明書更新後に nginx をリロードします：
nginx -t && nginx -s reload

最小権限の推奨：

  • 対象の証明書ディレクトリのみを開放し、/etc/nginx 全体への読み書き権限は付与しない。
  • sudoers を使用して nginx -t と nginx -s reload を精密に許可し、完全な root シェルは付与しない。

Apache HTTP Server​

clmBot には以下の権限が必要です：

  1. 証明書ディレクトリの読み書き権限：SSLCertificateFile、SSLCertificateChainFile、SSLCertificateKeyFile が存在するディレクトリに対する読み書き権限を持つこと。
  2. サービス再起動コマンドの実行：after_script はデフォルトで以下のスクリプトのいずれかを生成します（ディストリビューションによって異なります）：
systemctl restart httpd.service
systemctl restart apache2.service

最小権限の推奨事項：

  • 対象の証明書ディレクトリのみを開放し、Apache 設定ディレクトリ全体には権限を付与しない。
  • sudoers を使用して、現在のシステムで実際に使用されている Apache サービス名に対してのみ restart の権限を付与する。

Tomcat​

clmBot には以下の権限が必要です：

  1. 証明書ディレクトリの読み書き権限：PEM 証明書/秘密鍵ファイル、または JKS keystore ファイルが存在するディレクトリに対する読み書き権限。
  2. 停止および起動スクリプトの実行：after_script はデフォルトで以下のスクリプトを生成します：
export JAVA_HOME="<java_home>" && "<catalina_base>/bin/shutdown.sh" && "<catalina_base>/bin/startup.sh"

最小権限の推奨事項：

  • 可能な限り、clmBot と Tomcat を同じ業務グループに配置し、対象の keystore または証明書ディレクトリに対する読み書き権限のみを付与します。
  • 対応する Tomcat インスタンスの shutdown.sh と startup.sh のみ実行を許可し、/opt ディレクトリ全体に対する権限は付与しません。
  • マルチインスタンスの Tomcat 環境では、インスタンスごとに権限を分割して付与する必要があります。

IIS​

IIS シナリオでは、Windows PowerShell スクリプトを使用して PFX をインポートし、HTTPS バインディングを更新します。管理者権限が必要です。

clmBot には以下の権限が必要です：

  1. 管理者アカウントで実行：powershell.exe -NoProfile -ExecutionPolicy Bypass を実行して一時 PFX をインポートし、IIS サイトのバインディングを更新します。
  2. 証明書ディレクトリの読み書き権限：一時 PFX ファイルの作成とクリーンアップ。

最小権限の推奨事項：

  • 専用の Windows サービスアカウントを使用し、対象の IIS サイトバインディング管理に必要な権限のみを付与します。
  • PowerShell の実行ポリシーとモジュール権限は、ホストのセキュリティベースラインに従って個別に監査してください。

Linux sudoers 設定例​

以下の例は権限付与の粒度を示すものであり、実際のパスはターゲットホストに応じて調整してください。

nginx：

clmbot ALL=(root) NOPASSWD: /usr/sbin/nginx -t
clmbot ALL=(root) NOPASSWD: /usr/sbin/nginx -s reload

Apache：

clmbot ALL=(root) NOPASSWD: /bin/systemctl restart apache2.service

Tomcat：

clmbot ALL=(tomcat) NOPASSWD: /opt/apache-tomcat/bin/shutdown.sh
clmbot ALL=(tomcat) NOPASSWD: /opt/apache-tomcat/bin/startup.sh

証明書ディレクトリ権限の例：

chown -R root:clmbot /etc/ssl/example
chmod 0750 /etc/ssl/example
chmod 0640 /etc/ssl/example/site.crt /etc/ssl/example/ca.crt
chmod 0640 /etc/ssl/example/site.key

clmBot に上記ファイルへの書き込みとバックアップを許可する必要がある場合は、ACLで精密に権限を付与できます。

setfacl -m u:clmbot:rwx /etc/ssl/example
setfacl -m u:clmbot:rw- /etc/ssl/example/site.crt
setfacl -m u:clmbot:rw- /etc/ssl/example/ca.crt
setfacl -m u:clmbot:rw- /etc/ssl/example/site.key

リリース前の権限確認チェックリスト​

ヒント

clmBot をデプロイする前に、以下の権限設定を項目ごとに確認することをお勧めします。

  • clmBot が専用アカウントで実行されているかどうか（root や管理者ではないこと）。
  • config.yaml が、必要なアカウントのみに読み取り・書き込み権限を許可しているかどうか。
  • 各 servers[].format が指す証明書ファイルに、必要な読み取り・書き込み権限のみが設定されているかどうか。
  • 証明書ファイルが置かれているディレクトリで、.bak バックアップファイルの作成とクリーンアップが許可されているかどうか。
  • before_script、after_script がすでに手動で監査されているかどうか。
  • sudoers には、ALL、bash、または完全な systemctl ではなく、正確なコマンドのみが含まれているか。
  • nginx / Apache / Tomcat の reload または restart 権限が、対象インスタンスのみに限定されているか。
  • サービスモード（clm-bot server）の待受アドレスとポートが、ホストファイアウォールのポリシーに適合しているか。
に最終更新