안전하지 않은 시스템 구성이란 무엇인가요?
안전하지 않은 시스템 구성은 OWASP 상위 10가지 CI/CD 보안 위험입니다. CI/CD 시스템이 차선책 또는 기본 구성으로 구축될 때 발생합니다. 여기에는 불필요하게 열려 있는 포트, 기본 자격증명, 패치되지 않은 시스템, 제대로 분리되지 않은 네트워크 또는 비활성화된 보안 기능이 포함될 수 있습니다. 이러한 취약점은 시스템을 무단 액세스에 노출시키고 멀웨어의 전파 및 구축 프로세스에 악성 코드가 삽입될 가능성을 높여 궁극적으로 데이터 유출 및 비즈니스 운영 중단으로 이어질 수 있습니다. 안전하지 않은 구성은 또한 공격자가 워크플로우를 조작하고 프로덕션 환경에 액세스할 수 있도록 합법적인 CI/CD 프로세스를 오용하는 결과를 초래할 수 있습니다.
CICD-SEC-7: 안전하지 않은 시스템 구성 설명
안전하지 않은 시스템 구성은 심각한 보안 위험을 초래합니다. 이는 소스 코드 관리(SCM), CI 시스템, 아티팩트 리포지토리 등 파이프라인 전반의 다양한 시스템의 보안 설정, 구성 및 강화에 결함이 있는 경우 발생합니다. 이러한 취약점은 환경 내에서 영향력을 확대하려는 공격자에게 쉬운 표적이 되는 경우가 많습니다.
다양한 공급업체의 여러 시스템이 CI/CD 환경을 구성합니다. CI/CD 보안을강화하려면 파이프라인을 통해 흐르는 코드와 아티팩트뿐만 아니라 각 개별 시스템의 상태와 복원력에도 집중해야 합니다.
데이터 저장 및 처리 시스템과 마찬가지로 CI/CD 시스템도 애플리케이션, 네트워크 및 인프라 수준에서 수많은 보안 설정 및 구성이 필요합니다. 이러한 설정은 CI/CD 환경의 보안 상태와 잠재적인 침해에 대한 취약성을 결정하는 데 중요한 역할을 합니다.
공격자는 CI/CD 취약점과 잘못된 구성을 찾아 악용합니다. 잠재적인 경화 결함에는 다음이 포함됩니다:
- 오래된 버전을 실행하는 시스템
- 지나치게 허용적인 네트워크 액세스 제어가 있는 시스템
- 기본 OS에 대한 관리 권한이 있는 자체 호스팅 시스템
- 자격 증명 위생 상태 불량
시스템 구성 정의
시스템 구성은 시스템과 서비스를 설정하고, 상호 작용 방식을 정의하고, 운영을 관리하는 규칙을 설정하는 프로세스를 말합니다. 여기에는 하드웨어 설정, 소프트웨어 설치 및 구성, 네트워크 연결 설정이 포함됩니다. 구성 프로세스는 시스템의 기능, 성능 및 보안에 큰 영향을 미칠 수 있으므로 이를 올바르게 설정하고 최적의 상태를 유지하는 것이 매우 중요합니다.
보안 시스템 구성의 구성 요소
보안 구성에는 시스템 매개변수를 올바르게 설정하고, 액세스 제어를 관리하며, CI/CD 파이프라인을뒷받침하는 시스템에 대한 보안 조치를 구현하는 것이 포함됩니다. 이러한 구성은 무단 액세스의 위험을 완화하고 개발 환경의 중추를 형성하는 시스템의 취약점 악용을 방지합니다.
시스템 구성이 개별 시스템을 넘어 파이프라인에 사용되는 도구, 서비스 및 플랫폼 간의 상호 연결까지 확장된다는 점에서 CI/CD 환경의 복잡성은 CI/CD 환경에서 비롯됩니다. 당연히 효과적이고 안전한 시스템 구성의 주요 구성 요소는 엄격한 구성 관리입니다.
CICD-SEC-7의 작동 방식
안전하지 않은 시스템 구성의 근본 원인은 인적 오류, 적절한 절차의 부재 또는 보안 요구 사항에 대한 이해 부족으로 지적되는 경우가 많습니다. 기본 설정을 변경하지 않고 그대로 두거나 과도한 권한을 허용하거나 시스템 업데이트 및 패치를 소홀히 하는 등의 간단한 원인으로 인해 발생할 수 있습니다.
가상의 상황
공격자는 인공지능 전문 기술 회사인 표적 네트워크를 스캔하여 기본 설정으로 구성된 노출된 Jenkins 서버를 발견합니다. 쉽게 사용할 수 있는 도구와 API 호출을 사용하여 기본 시스템에 대한 잠재적 정보를 찾기 위해 Jenkins 서버 메타데이터를 마이닝합니다. 플러그인, 작업, 시스템 구성 등에 관한 데이터 등 정보의 금광이 화면에 넘쳐납니다. 이 많은 세부 정보 중에서 눈에 띄는 한 가지 정보가 있습니다. AWS 키. Jenkins가 AWS에 애플리케이션을 구축하는 데 사용하고 있었지만 보안이 적절하지 않았습니다. 이 키는 관리자 계정용이며, 회사의 AWS 환경에 대한 잠재적인 무제한 액세스 권한을 부여합니다.
공격자는 키를 사용하여 회사의 AWS 인프라에 침투한 후 조직의 시스템 핵심부에 침투합니다. 이들은 독점 AI 모델을 보관하는 S3 버킷을 찾아내고, 탈취한 AWS 키에서 관리자 수준의 액세스 권한으로 신속하게 모델을 다운로드한 후 경보 없이 종료합니다.
그런 다음 공격자는 이 시스템을 더 악용하기로 결정합니다. Jenkins 서버가 GitHub 리포지토리에 대한 쓰기 권한을 가지고 있다는 것을 알고, 애플리케이션에 백도어를 생성하는 악성 코드 스니펫을 메인 애플리케이션 소스 코드에 심습니다. 다음 구축 주기에서 회사는 자신도 모르게 애플리케이션을 프로덕션 환경으로 밀어 넣습니다. 이제 공격자는 지속적인 백도어로 무장하여 데이터를 훔치고, 시스템 제어를 조작하고, 추가 멀웨어를 심을 수 있으며, 이 모든 것이 회사의 보안 시스템의 레이더망을 피할 수 있습니다.
CI/CD에서 보안 시스템 구성의 중요성
엔지니어링 환경의 어느 한 지점에서 잘못된 구성이 발생하면 전체 파이프라인이 잠재적인 위협에 노출될 수 있습니다. 잘못된 구성을 이용하는 공격자는 CI/CD 시스템에 무단으로 액세스하거나 시스템을 손상시키고 기본 OS에 액세스할 수 있습니다. 공격자는 합법적인 CI/CD 흐름을 조작하고, 민감한 토큰을 획득하고, 프로덕션 환경에 액세스할 수 있습니다. 일부 시나리오에서는 구성 결함으로 인해 공격자가 환경 내부와 CI/CD 시스템의 컨텍스트 외부로 측면 이동이 가능할 수 있습니다.
안전하지 않은 시스템 구성과 관련된 위험
안전하지 않은 시스템 구성과 관련된 위험을 이해하는 DevOps 팀은 덜 취약한 시스템을 설계하고, 설계한 시스템의 보안에 대한 책임을 지며, 위험 발생 시 이를 완화할 수 있습니다.
사례 연구 1: 보안 사고 및 잠재적 사용자 데이터베이스 유출에 따른 PHP의 GitHub 전환
2021년 4월, PHP 커뮤니티는 git.php.net과 관련된 보안 사고에 직면했습니다. 처음에는 서버 침해로 의심되었지만, 조사 결과 HTTPS와 암호 기반 인증을 사용하여 Gitolite 인프라를 우회하여 악의적인 커밋이 이루어진 것으로 밝혀졌습니다. master.php.net 사용자 데이터베이스가 유출되었을 수 있으며, 이로 인해 모든 php.net 사용자에 대해 main.php.net으로 시스템을 마이그레이션하고 비밀번호를 재설정하라는 메시지가 표시됩니다. Git.php.net과 svn.php.net은 읽기 전용으로 바뀌었고, PHP의 기본 저장소가 GitHub로 이전되어 보안이 강화되고 개발 워크플로우가 간소화되었습니다.
사례 연구 2: 악성 코드 삽입 사고 이후 보안 조치를 점검한 Webmin
2019년 8월, 웹 기반 시스템 구성 도구인 Webmin은 소스 코드에 악성 코드가 삽입되어 보안 침해 사고를 겪었습니다. 우발적인 버그가 아닌 이 침해로 인해 원격 명령 실행이 가능했습니다. 이 악성 코드는 손상된 개발 빌드 서버를 통해 유입되었습니다. 이 취약점을 발견하자마자 Webmin은 GitHub에서 체크인한 코드만 사용하도록 빌드 프로세스를 업데이트하고, 접근 가능한 모든 비밀을 순환하고, 지난 1년간 모든 GitHub 커밋에 유사한 취약점이 있는지 감사하는 방식으로 대응했습니다.
사례 연구 3: 잘못된 구성의 Git 서버로 인해 온라인에 노출된 닛산 북미의 소스 코드
닛산 북미의 모바일 앱과 내부 도구의 소스 코드가 잘못된 구성의 Git 서버로 인해 온라인으로 유출되는 심각한 보안 결함이 발생했습니다. 기본 사용자 이름과 암호 'admin/admin'으로 노출된 이 서버는 스위스에 거주하는 소프트웨어 엔지니어인 틸리 코트만이 발견했습니다. 이 리포지토리에는 다양한 닛산 앱, 진단 도구, 딜러 포털, 마케팅 도구 등을 위한 코드가 포함되어 있었습니다. 닛산은 사고를 확인하고 영향을 받은 시스템을 보호했으며 개인 데이터에 액세스할 수 있는 권한은 없다고 주장했습니다.
사례 연구 4: 뉴욕주 IT 부서, 내부 코드 리포지토리 온라인 공개
뉴욕주의 IT 부서에서 사용하는 내부 코드 리포지토리가 실수로 온라인에 노출되어 누구나 액세스할 수 있게 되었습니다. 사이버 보안 회사 SpiderSilk가 발견한 GitLab 서버에는 주 정부 시스템의 비밀 키와 암호가 포함된 프로젝트가 포함되어 있었습니다. 이 서버는 누구나 사용자 계정을 생성하고 로그인할 수 있도록 구성되어 있었습니다. 이 서버는 3월 18일에 온라인에서 처음 발견되었으며, 노출이 보고된 후 오프라인 상태로 전환되었습니다. 해당 서버는 공급업체가 설치한 테스트용 박스였으며 이후 폐기된 것으로 알려졌습니다.
CI/CD에서 안전하지 않은 시스템 구성 방지
잘못된 구성은 공격자에게 진입 지점을 제공하여 심각한 보안 침해로 이어질 수 있지만, 많은 개발 프로세스에서 안전한 시스템 구성은 여전히 간과되고 있습니다. OWASP 상위 10대 CI/CD 보안 위험 목록 작성자의 내부자 추천을 통해 시스템을 안전하게 보호할 수 있습니다:
- 사용 중인 시스템 및 버전의 인벤토리를 유지하여 각 시스템을 지정된 소유자에게 매핑하세요. 이러한 구성 요소에 알려진 취약점이 있는지 정기적으로 확인하세요. 보안 패치가 제공되면 취약한 구성 요소를 업데이트하세요. 취약한 구성 요소에 대한 패치를 사용할 수 없는 경우 해당 구성 요소 또는 시스템을 제거하는 것이 좋습니다. 또는 시스템의 액세스 또는 민감한 작업 수행 기능을 제한하여 취약점 악용으로 인한 잠재적 영향을 최소화하세요.
- 시스템에 대한 네트워크 액세스가 최소 권한 액세스 원칙에부합하는지 확인합니다.
- 모든 시스템 구성을 주기적으로 검토하는 프로세스를 설정하세요. 시스템의 보안 태세에 영향을 줄 수 있는 설정에 중점을 두고 검토하세요. 최적의 설정을 보장합니다.
- 최소 권한 원칙에 따라 파이프라인 실행 노드에 권한을 부여합니다. 이 맥락에서 흔히 발생하는 잘못된 구성은 실행 노드에 대한 디버그 권한을 엔지니어에게 부여하는 것입니다. 많은 조직에서 이를 허용하지만 디버그 모드에서 실행 노드에 액세스할 수 있는 모든 사용자가 메모리에 로드되는 동안 모든 비밀을 노출할 수 있다는 점을 고려해야 합니다. 또한 노드의 ID를 사용하여 이 권한을 가진 모든 엔지니어에게 높은 수준의 권한을 부여할 수도 있습니다.
시스템 구성 보안을 위한 업계 표준
여러 업계 표준에서 시스템 구성 보안에 대한 모범 사례를 설명합니다. 인터넷 보안 센터(CIS)에서는 보안 구성을 위한 포괄적인 벤치마크를 제공하며, 미국 국립표준기술연구소(NIST)에서도 보안을 위한 시스템 구성 가이드라인을 발표하고 있습니다.
비밀 암호화
암호, API 키, 데이터베이스 자격 증명과 같은 비밀은 미사용 및 전송 시 암호화해야 합니다. 코드나 설정 파일에 비밀을 저장하지 마세요. 해시코프 볼트나 AWS 시크릿 매니저와 같은 비밀 관리 도구를 사용하세요. 이러한 도구는 비밀을 암호화하고 이에 대한 액세스를 제어하여 조직의 자격 증명이 잘못된 사람에게 넘어가는 것을 방지합니다.
시스템 로깅 및 모니터링
안전한 시스템 구성을 유지하는 데 있어 핵심적인 부분은 명확한 정책을 수립하고 규정 준수 여부를 정기적으로 모니터링하는 것입니다. 의심스러운 활동을 감지하고 보안 사고에 신속하게 대응할 수 있도록 모든 활동을 기록하는 것이 중요합니다. 또한 비정상적인 트래픽 패턴이나 로그인 시도 실패 등 공격의 징후가 있는지 시스템을 모니터링해야 합니다.
취약점 패치 적용
포괄적인 취약점 식별 및 패치 시스템을 갖추고 있는지 확인하세요. 취약점을 체계적으로 파악하고 해결 우선순위를 정하세요. 취약점을 패치할 수 없는 경우에는 관리자 권한 제거와 같은 대체 완화 방법을 사용하세요. 시스템을 최신 상태로 유지한다는 것은 서버, 애플리케이션, CI/CD 도구에 정기적으로 패치와 업데이트를 적용하는 것을 의미합니다.
불필요한 계정 및 권한 제거하기
고아 계정, 사용하지 않는 계정 등 불필요한 계정을 삭제하여 최소 권한을 적용하세요. 이는 공격 표면을 줄이기 위한 가장 강력한 보안 방법 중 하나입니다. 사용자, 프로세스, 서비스 등 시스템의 모든 구성요소가 기능을 수행하는 데 필요한 최소한의 권한만 갖도록 하세요. 이렇게 하면 손상된 구성 요소가 발생했을 때 피해를 줄일 수 있습니다.
네트워크 로드블록 세우기
네트워크를 더 작고 격리된 세그먼트로 나누면 공격자가 네트워크에 액세스하는 경우 측면 이동을 제한할 수 있습니다. 방화벽과 ACL(액세스 제어 목록)을 사용하여 세그먼트 간 트래픽을 제어하세요. 트래픽을 암호화하고, 사용하지 않거나 불필요하게 열려 있는 네트워크 포트를 차단하고, 불필요한 프로토콜과 서비스를 비활성화하거나 제거하세요. 방화벽 규칙을 정기적으로 감사하세요.
빌드 서버 보안 유지
빌드 서버는 코드를 컴파일하고 패키징하는 역할을 하므로 공격자의 주요 타깃이 됩니다. 빌드 서버가 최신 보안 패치와 강력한 암호로 적절히 강화되었는지 확인하세요. 빌드 환경을 보호한다는 것은 프로덕션 환경과 분리한다는 것을 의미합니다.
기존 시스템 감사
정기적인 감사 및 검토를 통해 시간이 지나도 시스템 구성이 안전하게 유지되도록 할 수 있습니다. 기존 기술에 대한 종합적인 감사를 수행합니다. 침투 테스트, 취약성 검사, 구성 관리 및 기타 보안 감사 도구를 사용하여 시스템의 결함을 찾고 수정의 우선순위를 정하세요. NIST, Microsoft, CIS, DISA 등의 업계 표준을 사용하여 리소스에 대한 시스템 평가를 수행합니다.
보안 시스템 구성을 지원하는 도구 사용
시스템 구성을 관리하고 보안을 유지하는 데 도움이 되는 많은 도구가 있습니다. Ansible, Chef 또는 Puppet과 같은 구성 관리 도구를 사용하면 환경 전반에서 자동화된 구성과 일관된 적용을 할 수 있습니다. 클라우드 기반 시스템의 경우 AWS Config, Azure Policy, Google Cloud Security Command Center와 같은 클라우드 네이티브 서비스가 보안 구성을 유지하는 데 도움이 될 수 있습니다.
안전하지 않은 시스템 구성 FAQ
강화 표준의 예로는 조직이 보안을 평가하고 개선하는 데 도움이 되는 잘 정의되고 편견 없는 합의 기반의 업계 모범 사례를 제공하는 인터넷 보안 센터(CIS) 벤치마크가 있습니다.
다른 표준으로는 미국 국방정보시스템국(DISA)의 보안 기술 구현 가이드(STIG)와 미국 국립표준기술연구소(NIST)의 강화 지침이 있습니다. 이러한 표준은 운영 체제, 네트워크 장치, 클라우드 환경을 포함한 광범위한 시스템을 다루며 새로운 위협과 취약성을 해결하기 위해 정기적으로 업데이트됩니다.