젠킨스 서버 보안 강화: 필수 모범 사례

젠킨스 서버를 보호하는 것은 중요합니다. 젠킨스는 소스 코드, 배포 대상, 자격 증명 및 빌드 아티팩트에 접근할 수 있기 때문입니다. 젠킨스가 노출되거나 느슨하게 구성된 경우, 공격자가 리포지토리를 읽거나, 빌드를 변경하거나, 비밀을 탈취하거나, 빌드 에이전트를 네트워크 침투 경로로 사용할 수 있습니다.

가장 안전한 젠킨스 설정은 여러 계층을 사용합니다: 강력한 신원 확인, 최소 권한 부여, 암호화된 접근, 신중한 플러그인 관리, 안전한 파이프라인 패턴 및 유용한 감사 로그. 젠킨스를 더 넓은 팀에 노출하거나 프로덕션 시스템에 연결하기 전에 아래 제어 사항부터 시작하세요.

사용자 관리 및 접근 제어

강력한 사용자 관리는 첫 번째 방어선입니다. 젠킨스는 사용자가 보고 수행할 수 있는 작업에 대해 세밀한 제어를 제공합니다. 최소 권한 원칙을 구현하면 사용자와 서비스가 작업을 수행하는 데 필요한 권한만 가지게 되어 손상된 계정으로 인한 잠재적 피해를 최소화할 수 있습니다.

인증

젠킨스는 여러 인증 시스템과 통합할 수 있습니다. 팀 환경에서는 젠킨스 내부 사용자 데이터베이스에만 의존하지 말고 중앙 집중식 인증을 사용하세요.

LDAP 또는 Active Directory 통합: 기존 디렉터리 그룹 및 계정 수명 주기 제어를 사용하세요.
SAML 또는 OpenID Connect: 젠킨스 플러그인 세트가 지원하는 경우 ID 공급자를 통해 Single Sign-On을 사용하세요.
로컬 계정: 신중하게 보호된 비상 관리자 계정 하나를 유지하되, 공유 로컬 계정을 일반적인 접근 모델로 사용하지 마세요.

권한 부여 전략

사용자가 인증되면 권한 부여를 통해 접근 수준이 결정됩니다.

매트릭스 기반 보안: 이 내장 전략을 사용하면 사용자 또는 그룹에 권한을 할당할 수 있습니다. 소규모 설정에는 잘 작동하지만 팀이 성장함에 따라 감사가 어려워질 수 있습니다.
역할 기반 전략: 역할 기반 권한 부여 전략 플러그인을 사용하면 개발자, 운영자, 관리자와 같은 역할을 정의한 다음 사용자 또는 그룹을 해당 역할에 매핑할 수 있습니다.

예: 역할 기반 권한 부여 설정

젠킨스 플러그인 관리자에서 역할 기반 권한 부여 전략 플러그인을 설치합니다.
Jenkins 관리 > 보안으로 이동합니다.
권한 부여에서 역할 기반 전략을 선택합니다.
개발자, 릴리스 관리자, jenkins-관리자와 같은 역할을 정의합니다.
각 역할에 작업/읽기, 작업/빌드 또는 자격 증명/보기와 같이 필요한 권한만 부여합니다.
가능하면 개인 대신 디렉터리 그룹을 역할에 할당합니다.

젠킨스 통신 보안

젠킨스 서버와 주고받는 데이터가 암호화되도록 하는 것은 자격 증명 및 민감한 빌드 정보를 다룰 때 특히 중요합니다.

HTTPS 구성

젠킨스가 HTTPS를 사용하여 클라이언트와 서버 간의 모든 통신을 암호화하도록 구성하세요. 이는 도청 및 중간자 공격을 방지합니다.

가장 일반적인 프로덕션 패턴은 Nginx, Apache, HAProxy 또는 클라우드 로드 밸런서와 같은 리버스 프록시 뒤에 젠킨스를 배치하는 것입니다. 프록시에서 TLS를 종료하고 HTTP를 HTTPS로 리디렉션한 다음 Jenkins 관리 > 시스템에서 젠킨스의 공개 URL을 설정하세요.

젠킨스 내장 웹 서버를 HTTPS와 함께 직접 실행하는 경우 --httpsPort, --httpsKeyStore 및 --httpsKeyStorePassword와 같은 젠킨스 시작 옵션 또는 패키지별 서비스 구성을 통해 구성하세요. 정확한 파일은 설치 방법에 따라 다르므로 변경하기 전에 젠킨스 서비스가 어떻게 시작되는지 확인하세요.

또한 리버스 프록시가 올바른 전달 헤더를 보내는지 확인하세요. 잘못된 프록시 헤더는 잘못된 리디렉션 URL, 실패한 CSRF 검사 또는 일반 HTTP를 가리키는 링크를 유발할 수 있습니다.

젠킨스 및 플러그인 보안

플러그인을 통한 젠킨스의 확장성은 가장 큰 장점 중 하나이지만, 신중하게 관리하지 않으면 잠재적인 보안 위험을 초래할 수도 있습니다.

젠킨스 및 플러그인 업데이트 유지

오래된 버전의 젠킨스 코어 및 해당 플러그인은 일반적인 취약점 소스입니다. 알려진 보안 결함을 패치하기 위해 정기적으로 업데이트하세요.

젠킨스 코어 업데이트: 젠킨스 보안 권고를 따르고 정기적인 유지 관리 기간을 계획하세요.
플러그인 업데이트: 업데이트 알림을 자주 검토하세요. 가능하면 프로덕션이 아닌 컨트롤러에서 중요한 플러그인 업데이트를 테스트하세요.

플러그인 허용 목록 및 감사

모든 플러그인이 동일하게 생성되는 것은 아닙니다. 일부 플러그인에는 보안 취약점이 있거나 유지 관리되지 않을 수 있습니다.

신뢰할 수 있는 플러그인 사용: 젠킨스 업데이트 센터의 유지 관리되는 플러그인을 선호하세요.
플러그인 설치 제한: 각 플러그인은 컨트롤러 내에서 실행되는 코드를 추가합니다.
사용하지 않는 플러그인 제거: 분기별로 또는 주요 프로세스 변경 후에 플러그인을 감사하세요.

플러그인 보안 경고 관리

젠킨스는 알려진 보안 권고가 있는 설치된 플러그인에 대해 경고할 수 있습니다. Jenkins 관리 아래의 경고에 주의를 기울이고 영향을 받는 플러그인을 업데이트, 교체 또는 제거하세요.

Jenkinsfile 보안

Jenkinsfile은 빌드 파이프라인을 정의합니다. 빌드 프로세스에 악성 코드가 주입되는 것을 방지하려면 이를 보호하는 것이 중요합니다.

Jenkinsfile을 버전 관리에 저장: 애플리케이션 코드를 검토하는 것과 같은 방식으로 파이프라인 변경 사항을 검토하세요.
파이프라인 코드를 실행 가능한 코드로 취급: Jenkinsfile은 셸 명령을 실행하고, 아티팩트를 게시하고, 자격 증명을 요청할 수 있습니다.
스크립트 승인에 주의: 스크립트 보안 플러그인은 관리자가 특정 Groovy 메서드 또는 스크립트를 승인하도록 요구할 수 있습니다. 이해하는 코드만 승인하세요.
UI에서 인라인 파이프라인 스크립트 피하기: 코드 검토가 포함된 리포지토리 기반 Jenkinsfile을 선호하세요.

예: 스크립트 승인

파이프라인이 승인되지 않은 Groovy 서명에 도달하면 젠킨스는 이를 Jenkins 관리 > 프로세스 내 스크립트 승인 아래에 나열합니다. 승인하기 전에 요청된 서명과 이를 트리거한 작업을 검토하세요. 광범위한 승인은 둘 이상의 작업에 영향을 미칠 수 있습니다.

젠킨스 자격 증명 관리

젠킨스는 다른 서비스에 접근하기 위해 API 키, 비밀번호 및 SSH 키와 같은 민감한 자격 증명을 저장해야 하는 경우가 많습니다. 이를 안전하게 관리하는 것이 중요합니다.

젠킨스 자격 증명 저장소 사용: API 토큰, 비밀번호, 인증서 및 SSH 키를 작업 정의에 일반 텍스트로 저장하지 말고 자격 증명으로 저장하세요.
하드코딩된 비밀 피하기: Jenkinsfile, 셸 스크립트, 빌드 로그 또는 리포지토리 변수에 비밀을 넣지 마세요.
자격 증명 범위를 엄격하게 지정: 폴더와 권한을 사용하여 프로덕션 자격 증명이 필요하지 않은 작업에서 멀리 유지하세요.
자격 증명 순환: 직원이 퇴사하거나, 작업이 삭제되거나, 비밀이 로그에 나타날 수 있는 경우 배포 키와 서비스 토큰을 순환하세요.

예: 파이프라인에서 자격 증명 사용

pipeline {
    agent any
    stages {
        stage('Deploy') {
            steps {
                withCredentials([sshUserPrivateKey(credentialsId: 'prod-deploy-key', keyFileVariable: 'SSH_KEY', usernameVariable: 'SSH_USER')]) {
                    sh 'ssh -i "$SSH_KEY" -o IdentitiesOnly=yes "[email protected]" "deploy_command"'
                }
            }
        }
    }
}

이 예에서 prod-deploy-key는 저장된 SSH 개인 키 자격 증명의 ID입니다. 젠킨스는 단계 기간 동안 키를 임시 파일에 쓰고 지원되는 비밀 값을 로그에서 마스킹합니다.

네트워크 보안 및 접근 제어

젠킨스 내부 보안 외에도 네트워크 수준에서 서버를 보호하는 것이 필수적입니다.

방화벽 규칙: 신뢰할 수 있는 네트워크, VPN 범위 또는 ID 인식 프록시 진입점으로 젠킨스 접근을 제한하세요.
리버스 프록시 제어: TLS, HTTP-HTTPS 리디렉션, 요청 제한 및 일관된 헤더를 위해 리버스 프록시를 사용하세요.
에이전트 격리: 컨트롤러에서 신뢰할 수 없는 빌드를 실행하지 마세요. 위험한 작업 부하에는 일회용 또는 엄격하게 제어된 에이전트를 사용하세요.
네트워크 분할: 작업이 실제로 필요하지 않는 한 젠킨스를 광범위한 내부 네트워크 접근에서 멀리 유지하세요.

감사 및 모니터링

젠킨스 로그를 정기적으로 검토하고 활동을 모니터링하면 보안 사고를 감지하고 대응하는 데 도움이 될 수 있습니다.

감사 로깅 활성화: 로그인, 권한 변경, 자격 증명 변경, 작업 편집 및 관리 작업을 기록하세요. Audit Trail과 같은 플러그인이 도움이 될 수 있습니다.
젠킨스 로그 모니터링: 예상치 못한 자격 증명 사용, 새 관리자 계정, 비정상적인 작업 편집 또는 반복된 로그인 실패에 대해 컨트롤러 로그 및 빌드 로그를 검토하세요.
구성 백업: 복구 계획에 따라 젠킨스 홈, 작업 구성, 플러그인 목록 및 자격 증명 메타데이터를 백업하세요. 백업을 프로덕션 비밀처럼 보호하세요.

젠킨스를 지루하게 유지하세요

목표는 접근이 예측 가능하고, 변경 사항이 검토되며, 플러그인이 알려져 있고, 자격 증명이 작업이나 로그로 유출되지 않는 젠킨스 서버입니다. SSO, 최소 권한 역할, HTTPS, 플러그인 업데이트 및 안전한 자격 증명 사용으로 시작하세요. 그런 다음 정기적인 검토를 예약하여 어제의 임시 예외가 내일의 사고가 되지 않도록 하세요.