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

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は必ず人手による監査を実施し、スクリプトで必要となる権限は1項目ずつ個別に付与する必要がある。

非推奨の構成：

  • 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）のリッスンアドレスとポートがホストのファイアウォールポリシーに準拠しているか。
に最終更新