컨테이너 레지스트리 보안이란 무엇인가요?

Azure 컨테이너 레지스트리, Amazon Elastic 컨테이너 레지스트리, Google 컨테이너 레지스트리와 같은 프라이빗 컨테이너 레지스트리는 독점 이미지 및 관련 아티팩트를 저장하고 관리하기 위한 안전하고 제어된 환경을 제공합니다. 이러한 레지스트리는 조직 내에서 권한이 부여된 사용자만 액세스할 수 있으므로 민감한 정보와 사용자 지정 이미지를 안전하게 보호할 수 있습니다.

조직은 공개 및 비공개 레지스트리를 함께 사용하여 오픈 소스 이미지의 이점을 활용하면서 독점 소프트웨어에 대한 통제권을 유지할 수 있습니다. 이러한 이중 접근 방식을 통해 조직은 컨테이너 관리 워크플로우를 최적화하고 구축 프로세스를 간소화할 수 있습니다.

컨테이너 레지스트리 보안의 구성 요소

레지스트리는 컨테이너화된 환경이 운영되는 방식의 핵심이며 조직에서 수만 개의 이미지를 쉽게 저장할 수 있다는 점을 고려하면 레지스트리를 보호하는 것은 소프트웨어 개발 수명 주기의 무결성에필수적인 요소입니다.

취약점은 애플리케이션 그 이상을 손상시킬 수 있습니다. 잘못된 구성을 이용하는 공격자는 CI/CD 시스템에 무단으로 액세스하고 측면으로 이동하여 기본 OS에 액세스할 수 있습니다. 이들은 잠재적으로 합법적인 CI/CD 흐름을 조작하고, 민감한 토큰을 획득하고, 노출된 자격 증명을 식별하여 조직의 네트워크에 침입할 수 있는 프로덕션 환경으로 이동할 수 있습니다.

관련 문서: 클라우드 공급 파이프라인 공격의 해부학

레지스트리 보안은 신뢰할 수 있는 레지스트리와 라이브러리만 사용하는 것에서 시작됩니다. 호스팅 서버를 보호하고 실질적인 액세스 정책을 구현하는 것과 함께 취약점 변경에 대한 지속적인 모니터링이 기본입니다. 적절한 레지스트리 보안은 안전하지 않은 연결을 거부하고, 오래된 이미지에 플래그를 지정하거나 제거하고, 엄격한 인증 및 권한 부여 제한을 적용해야 합니다.

이러한 측정값을 더 자세히 살펴보겠습니다.

CI/CD에서 이미지 및 아티팩트 무결성 증진하기

이미지 및 아티팩트와 관련된 위험을 이해하면 이미지의 무결성을 보장하기 위해 철저한 검사를 구현하는 것이 얼마나 중요한지 알 수 있습니다. 다음 전략을 구현해 보세요.

안전하지 않은 연결 거부

공개 레지스트리를 사용하면 컨테이너 이미지에 익명으로 액세스할 수 있지만 중간자 공격, 무단 변조, 민감한 정보에 대한 무단 액세스를 방지하려면 보안 연결을 유지해야 합니다.

안전하지 않은 연결을 거부하려면 HTTPS 또는 TLS 암호화 연결과 같은 보안 프로토콜만 허용하도록 시스템을 구성하세요. 먼저 도메인에 대해 신뢰할 수 있는 CA(인증 기관)에서 유효한 SSL/TLS 인증서를 발급받아 설치합니다. 그런 다음 서버 또는 서비스 구성을 업데이트하여 HTTP와 같은 안전하지 않은 프로토콜을 비활성화하고 HTTPS 또는 TLS를 사용하도록 강제합니다. 설정에 따라 웹 서버(예: Nginx, Apache), 로드 밸런서 또는 애플리케이션의 설정을 조정해야 할 수도 있습니다. 또한, 사이트나 서비스에 액세스할 때 항상 보안 연결을 사용하도록 브라우저에 지시하는 HSTS(HTTP 엄격한 전송 보안)와 같은 보안 기능을 사용하는 것도 고려해 보세요.

오래된 이미지 제거

오래된 이미지(특정 기간보다 오래되었거나 일정 기간 동안 사용하지 않은 이미지)를 정의하는 정책을 수립하고 레지스트리 도구 또는 API를 사용하여 정책에 따라 이미지를 나열하고 필터링하세요. 예를 들어, Docker 레지스트리에서 Docker 레지스트리 API를 사용하여 이미지 메타데이터를 검색하고 마지막으로 푸시한 날짜 또는 태그를 기준으로 필터링할 수 있습니다. 다른 레지스트리에서는 유사한 API 또는 CLI 도구를 사용할 수 있습니다. 오래된 이미지를 식별한 후에는 레지스트리의 가비지 수집 모범 사례를 따라 적절한 명령어 또는 API를 사용하여 삭제하세요.

타사 레지스트리의 IAM 문제 방지

ID 및 액세스 관리(IAM) 는 조직, 특히 중요한 코드와 자산을 저장하는 리포지토리가 있는 GitHub와 같은 소스 제어 관리 시스템(SCM)에서 매우 중요합니다. 부적절한 IAM은 CI/CD 파이프라인에서 보안 위험을 초래할 수 있습니다. 조직은 리포지토리에 대한 보안 및 거버넌스를 최적화하기 위해 싱글사인온(SSO)과 SCIM(도메인 간 ID 관리 시스템)을 사용하여 액세스 제어를 관리할 수 있습니다. 하지만 SSO는 GitHub Enterprise에서만 사용할 수 있으므로 다른 라이선스는 위험에 노출되어 있습니다.

GitHub 계정의 개인 이메일 주소, 유령 GitHub 계정, 불완전한 오프보딩과 관련된 문제를 완화하려면 이중 인증(2FA)을 적용하고, 전용 기업 계정으로 온보딩 프로토콜을 설정하고, 사용자 계정의 인벤토리를 유지하세요. SSO를 사용하는 조직의 경우 SCIM을 구현하면 사용자의 자동 프로비저닝을 보장하고 오래된 자격 증명을 통한 액세스를 제거할 수 있습니다. IAM 리스크를 해결하면 리포지토리와 CI/CD 에코시스템을 보호하고 모든 시스템에서 높은 보안 수준을 유지하는 데 도움이 됩니다.

관련 문서: GitHub 조직의 3대 IAM 리스크

충분한 인증 및 권한 제한 사용

리포지토리에 필요한 것보다 많은 권한을 부여받은 ID는 권한 상승의 기회를 열어주며, 무단 코드 변경, 빌드 프로세스 변조, 민감한 데이터에 대한 액세스를 초래할 수 있습니다. 자동화를 통해 액세스 제어를 검증하고, 사용자 권한을 확인하고, 잠재적인 취약성을 식별하여 조직에서 다음과 같은 일상적인 사전 예방 조치를 시행할 수 있습니다:

• 엔지니어링 에코시스템 전반의 모든 ID를 분석하고 매핑합니다. 각 ID에 대해 ID 공급자, 부여된 권한 및 사용된 권한을 지속적으로 매핑합니다. 분석이 모든 프로그래매틱 액세스 방법을 포괄하는지 확인합니다.
• 환경의 다양한 시스템에서 각 ID에 대한 불필요한 권한을 제거합니다.
• 휴면 계정을 비활성화하거나 삭제할 수 있는 허용 기간을 설정합니다. 이 비활성 기간을 초과하는 아이디는 비활성화하고 삭제합니다.
• 모든 외부 협력자를 매핑하고 최소 권한 원칙에 따라 이들의 신원을 조정합니다. 가능하면 인간 계정과 프로그래매틱 계정에 만료일이 있는 권한을 부여하세요.
• 직원이 개인 이메일 주소 또는 조직이 소유하지 않은 도메인의 주소를 사용하여 SCM, CI 또는 기타 CI/CD 플랫폼에 액세스하는 것을 금지합니다. 여러 시스템에서 비도메인 주소를 모니터링하고 규정을 준수하지 않는 사용자를 제거하세요.
• 사용자가 시스템에 직접 등록하는 것을 허용하지 않고 필요에 따라 권한을 부여합니다.
• 시스템에서 모든 사용자 및 자동으로 사용자 계정이 할당된 대규모 그룹에 기본 권한을 부여하지 않도록 합니다.
• 공유 계정을 사용하는 대신 각 특정 상황에 맞는 전용 계정을 만들고 해당 상황에 필요한 정확한 권한 세트를 부여하세요.

보안 스토리지 구현

아티팩트를 저장할 안전한 변조 방지 리포지토리를 구축하세요. 버전 관리를 활성화하여 아티팩트 변경 내역에 대한 기록을 유지하고 실시간 모니터링을 구현하여 의심스러운 활동을 추적하고 경고하세요. 손상된 아티팩트가 있는 경우 이전 정상 버전으로 쉽게 롤백할 수 있도록 시스템을 구성하세요.

개발부터 생산까지 무결성 검증 검사 수행

소프트웨어 제공 체인 전반에서 리소스 무결성을 검증하는 프로세스와 기술을 구현하세요. 개발자는 리소스를 생성할 때 외부 리소스 서명 인프라를 사용하여 서명해야 합니다. 후속 파이프라인 단계에서 리소스를 사용하기 전에 서명 권한에 대해 무결성을 교차 확인합니다.

코드 서명

SCM 솔루션은 각 기여자에 대한 고유 키로 커밋에 서명하는 기능을 제공하여 서명되지 않은 커밋이 파이프라인을 통해 진행되지 않도록 방지합니다.

아티팩트 검증 소프트웨어

리눅스 재단의 시그스토어와 같이 코드와 아티팩트에 서명하고 검증하도록 설계된 도구는 검증되지 않은 소프트웨어가 파이프라인을 따라 진행되지 못하도록 막을 수 있습니다.

구성 드리프트 감지

서명된 코드형 인프라 템플릿을 사용하여 관리되지 않는 클라우드 환경의 리소스와 같은 구성 편차를 감지하는 조치를 구현하세요. 이러한 드리프트는 신뢰할 수 없는 소스 또는 프로세스로부터 구축되었음을 나타낼 수 있습니다.

암호화 서명 사용

공개 키 인프라(PKI)를 사용하여 CI/CD 파이프라인의 각 단계에서 아티팩트를 암호화하여 서명하세요. 이 관행은 서명을 사용하기 전에 신뢰할 수 있는 인증 기관에 대해 서명의 유효성을 검사합니다. 유효하지 않거나 누락된 서명이 있는 아티팩트를 거부하도록 CI/CD 파이프라인을 구성하여 변조된 리소스나 무단 변경으로 인한 구축 위험을 줄이세요.

보안 컨테이너 이미지만 사용

컨테이너 이미지에는 공격자가 컨테이너와 호스트에 무단으로 액세스하기 위해 악용할 수 있는 취약점이 포함될 수 있습니다. 이를 방지하려면 평판이 좋은 출처의 안전하고 신뢰할 수 있는 컨테이너 이미지를 사용하고 정기적으로 스캔하세요. 공용 레지스트리에서 컨테이너를 구축할 때는 먼저 컨테이너에 멀웨어와 취약점이 있는지 검사하는 것이 특히 중요합니다.

다중 소스 유효성 검사 적용

신뢰할 수 있는 리포지토리뿐만 아니라 체크섬, 디지털 서명, 보안 해시 알고리즘 등 다양한 소스를 사용하여 아티팩트의 무결성을 검증하는 멀티소스 유효성 검사 전략을 채택하세요. 암호화 알고리즘과 키를 최신 상태로 유지하여 효율성을 유지하세요.

타사 리소스 유효성 검사

빌드 프로세스 중에 실행되는 스크립트처럼 빌드 및 구축 파이프라인에 통합된 타사 리소스는 엄격한 검증을 거쳐야 합니다. 이러한 리소스를 사용하기 전에 해당 리소스의 해시를 계산하고 리소스 제공자가 제공한 공식 해시값과 비교하세요.

보안 스캐닝 통합

CI/CD 파이프라인은 이미지를 만들 때 검증된 코드(프로덕션 승인)만 사용해야 합니다. 취약성 스캔 도구와 소프트웨어 구성 분석(SCA) 및 정적 애플리케이션 보안 테스트(SAST) 를 CI/CD 파이프라인에 통합하여 프로덕션 구축에서 이미지를 가져올 레지스트리에 이미지를 푸시하기 전에 이미지 무결성을 보장하세요. 또한 모범 사례를 따르는 것도 잊지 마세요. 예를 들어 불필요한 소프트웨어 구성 요소, 라이브러리, 구성 파일, 비밀 번호 등을 모두 제거하기 전에는 이미지를 빌드하지 마세요.

보수적이고 신중한 접근 방식을 취하면 보안 팀은 개발 프로세스 초기에 취약점을 해결하고 높은 수준의 코드 품질을 유지하면서 보안 사고의 위험을 줄일 수 있습니다. 모든 레지스트리 유형과 통합할 수 있는 컨테이너 이미지 스캔 솔루션을 선택하세요. Prisma Cloud와 같은 플랫폼은 관리자에게 유연한 원스톱 이미지 스캔 솔루션을 제공합니다.

이미지 분석 샌드박스

이미지 분석 샌드박스를 사용하면 컨테이너화된 애플리케이션을 개발하고 구축하는 동안 컨테이너 보안 전략을 강화하여 외부 저장소에서 오래되고 취약한 패키지 및 임베디드 멀웨어를 포함할 가능성이 있는 컨테이너 이미지를 안전하게 가져와 실행할 수 있습니다.

샌드박스의 기능을 사용하면 통제된 환경에서 암호화폐 채굴, 포트 스캔, 수정된 바이너리, 커널 모듈 수정과 같은 의심스러운 비정상적인 컨테이너 동작을 검사할 수 있습니다. 정적 분석으로는 놓칠 수 있는 위험을 노출하고 소프트웨어 공급망에 숨어 있는 의심스러운 종속성을 식별할 수 있습니다.

• 컨테이너의상세한 런타임 프로필캡처
• 이미지의 위험도 평가
• 워크플로우에 동적 분석 통합

유효성 검사 정책 및 감사 일정 수립

적절한 이미지 및 아티팩트 무결성 검증을 보장하기 위해 조직은 검증 프로세스를 정의하는 명확한 정책을 수립해야 합니다. 규정이 수립되면 정기적으로 내부 규정 준수 여부를 감사하여 취약점과 미준수 영역을 파악하고 해결합니다. 지속적인 모니터링과 분석을 통해 이상 징후와 무단 활동을 감지할 수 있습니다.

한눈에 보는 컨테이너 레지스트리 보안 체크리스트

• 신뢰할 수 있는 레지스트리 및 라이브러리 사용
• 호스팅 서버 보안 및 강력한 액세스 정책 구현
• 충분한 인증 및 권한 제한 구현
• 아티팩트를 위한 안전한 스토리지 구축
• CI/CD 전반에 걸쳐 무결성 유효성 검사 수행
• 암호화 서명 사용
• 멀티소스 유효성 검사 적용
• 타사 리소스 유효성 검사
• CI/CD 파이프라인에 보안 스캔 통합
• 유효성 검사 정책 및 정기 감사 일정 수립

컨테이너 레지스트리 FAQ