본문으로 건너뛰기

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)의 수신 주소와 포트가 호스트 방화벽 정책에 부합하는지 확인합니다.
최종 수정: 에