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에는 다음과 같은 권한이 필요합니다:
- 인증서 디렉터리 읽기/쓰기 권한: 대상 인증서 파일(
.crt), CA 체인 파일(선택 사항) 및 개인 키 파일(.key)이 위치한 디렉터리에 대한 읽기/쓰기 권한으로, 새 인증서를 쓰고.bak백업을 생성하기 위함입니다. - reload 명령 실행:
after_script은(는) 기본적으로 인증서 업데이트 후 nginx를 다시 로드하기 위해 다음 스크립트를 생성합니다:
nginx -t && nginx -s reload
최소 권한 부여 권장사항:
- 대상 인증서 디렉터리에 대해서만 권한을 개방하고, 전체
/etc/nginx에 대한 읽기/쓰기 권한을 부여하지 마세요. - sudoers를 통해
nginx -t및nginx -s reload에 정확히 권한을 부여하고, 완전한 root shell 권한을 부여하지 마세요.
Apache HTTP Server
clmBot에는 다음 권한이 필요합니다:
- 인증서 디렉터리 읽기/쓰기 권한:
SSLCertificateFile,SSLCertificateChainFile,SSLCertificateKeyFile이 위치한 디렉터리에 대한 읽기/쓰기 권한이 필요합니다. - 서비스 재시작 명령 실행 권한:
after_script은(는) 기본적으로 배포판에 따라 다음 스크립트 중 하나를 생성합니다:
systemctl restart httpd.service
systemctl restart apache2.service
최소 권한 부여 권장 사항:
- 전체 Apache 구성 디렉터리에 권한을 부여하지 말고, 대상 인증서 디렉터리에만 권한을 개방하세요.
- sudoers를 통해 현재 시스템에서 실제로 사용 중인 Apache 서비스 이름에 대해서만
restart권한을 부여하세요.
Tomcat
clmBot에는 다음 권한이 필요합니다:
- 인증서 디렉터리 읽기/쓰기 권한: PEM 인증서/개인 키 파일 또는 JKS keystore 파일이 위치한 디렉터리에 대한 읽기/쓰기 권한이 필요합니다.
- 중지 및 시작 스크립트 실행:
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에 필요한 권한은 다음과 같습니다:
- 관리자 계정으로 실행:
powershell.exe -NoProfile -ExecutionPolicy Bypass를 실행하여 임시 PFX를 가져오고 IIS 사이트 바인딩을 업데이트합니다. - 인증서 디렉터리 읽기/쓰기 권한: 임시 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)의 수신 주소와 포트가 호스트 방화벽 정책을 준수하는지 여부.