Offcanvas
Some text as placeholder. In real life you can have the elements you have chosen. Like, text, images, lists, etc.
Offcanvas
1111Some text as placeholder. In real life you can have the elements you have chosen. Like, text, images, lists, etc.
보안

소프트웨어 공급망을 보호하는 ‘시큐어 소프트웨어 팩토리’의 핵심 개념

Chris Hughes | CSO 2022.06.28
팩토리(Factory)와 소프트웨어는 서로 어울리지 않는 단어로 보인다. 보통 팩토리라고 하면 철강, 자동차, 가전제품같이 눈에 보이는 제품을 제조하고 조립하는 과정이 떠오르기 마련이다. 하지만 소프트웨어도 여러 공정을 반복해 거친다고 해서 공장에서 생산된다고 표현한다. 아예 ‘소프트웨어 팩토리(Software factory)’라는 용어가 존재하는데, 이는 소프트웨어를 효율적이면서 반복적이고 안전한 방식으로 생산하는 데 필요한 툴, 자산, 프로세스의 집합 전체를 가리킨다. 
 
ⓒ Getty Images Bank

소프트웨어 팩토리 개념은 마이터(MITRE)와 VM웨어 같은 업체에서 도입하는 걸로 유명해지면서, 지금은 민간 및 공공 모든 분야에서 널리 퍼져 있다. 미국 국방부는 최소 29개로 구성된 소프트웨어 팩토리 생태계를 보유하고 있는데, 그중에서 가장 유명한 것이 ‘케셀 런(Kessel Run)’과 ‘플랫폼 원(Platform One)’이다. 소프트웨어 공급망에서 취약점이 많아지고 있는 상황을 고려할 때, 소프트웨어 팩토리 접근법을 안전하게 실행하는 것은 매우 중요해지고 있다.

마침 리눅스 재단 산하의 클라우드 네이티브 컴퓨팅 재단(Cloud Native Computing Foundation, CNCF)은 지난달 ‘시큐어 소프트웨어 팩토리 참조 아키텍처(Secure Software Factory Reference Architecture)’라는 도움될 만한 가이드라인을 배포했다. 

시큐어 소프트웨어 팩토리 참조 아키텍처의 정의

CNCF가 정의한 내용에 따르면, 소프트웨어 공급망은 애플리케이션 소프트웨어를 쓰고 테스트하고 패키징하고 최종 소비자에게 배포할 때 수행되는 일련의 단계다. 소프트웨어 팩토리는 소프트웨어의 전달을 더 효율적으로 도와주는 종합적이면서 논리적인 구조다. 소프트웨어가 정확히 전달되는 과정에서 보안은 핵심 컴포넌트로 작동한다.

CNCF의 시큐어 소프트웨어 팩토리(SSF) 가이드는 클라우드 네이티브 베스트 프랙티스(Cloud-native Security Best Practices), 소프트웨어 공급망 베스트 프랙티스(Software Supply Chain Best Practices)같은 이전 간행물을 기반으로 제작됐다. 이번 참조 아키텍처 가이드라인은 보안에 중점을 두면서 오픈 소스 툴 활용 내용을 주로 담았다. 

또한 소프트웨어 공급망 백서(Software Supply Chain whitepaper)에 나왔던 4가지 주요 원칙인 ▲심층적 방어(Defense in depth) ▲서명 및 검증(Signing and verification) ▲아티팩트 메타데이터 분석(Artifact metadata analytics) ▲자동화(Automation)도 가이드에서 소개하고 있다. 각 원리는 소프트웨어의 코드 작성부터 배포 과정에 이르기까지 안전한 소프트웨어 전달하기 위해 알아야할 필수적인 개념이다. 

SSF 참조 아키텍처는 코드 스캔 및 서명 영역보다는 코드 프로브넌스(code provenance) 및 빌드 활동에 더 집중한다. 이는 SAST/DAST 같은 다운스트림 활동은 무언가를 보내는 당사자의 아이덴티티과 프로브넌스를 검증하는 데 의존하기 때문이다. 아이덴티티는 사용자 혹은 기계를 가리킬 수 있다. 서명과 서명 출처에 대한 검증은 프로브넌스를 확보하는 데 핵심적이다. 

SSF 안의 각 개체는 의존성을 갖는다. 즉 조직 IAM 시스템, 소스 코드 관리, 다운스트림의 연계 여부와 무관하게, SSF는 다운스트림 영역 소비자가 사용 중인 아티팩트의 증명(attestations) 및 서명(signatures)에 의존한다. 

SSF 컴포넌트 살펴보기

SSF 레퍼런스 아키텍처 안의 컴포넌트는 크게 핵심, 관리, 배포로 구분된다. 핵심 컴포넌트의 역할은 입력을 받아 이를 출력 아티팩트를 생성하는 것이다. 관리 컴포넌트는 SSF가 정책을 잘 지키면서 실행되도록 도와준다. 배포 컴포넌트는 팩토리 제품을 다운스트림 소비 단계를 위해 안전하게 옮겨주는 기능을 수행한다.

핵심 컴포넌트 : 핵심 컴포넌트는 스케줄링 및 오케스트레이션 플랫폼, 파이프라인 프레임워크 및 툴, 그리고 빌드 환경을 포함한다. 모든 SSF 컴포넌트는 활동을 수행하기 위해 플랫폼과 그와 관련 오케스트레이션을 이용한다. 

파이프라인 및 그와 연관된 툴은 소프트웨어 아티팩트 제작 워크플로우를 원활하게 만든다. CNCF의 가이드는 파이프라인이 워크로드와 동일한 요건에 영향을 받는다는 점을 강조한다. 이는 파이프라인 자체가 공격 표면의 일부이고 다운스트림 소비자에게 영향을 주기 위해 악용될 수 있다는 점을 지적한다. 솔라윈드도 이런 방식으로 해킹당했다. 이런 상황으로 SLSA(Supply Chain Levels for Software Artifacts) 같은 프레임워크가 점점 중요해지고 있다. 

마지막으로 빌드 환경에서는 소스 코드가 기계가 읽을 수 있는 소프트웨어, 즉 아티팩트(artifacts)로 변환된다. 성숙한 빌드 환경은 빌드 중에 쓰이는 입력, 액션, 툴과 관련해 자동화된 증명을 제공한다. 이는 빌드 프로세스와 연관 결과물/아티팩트의 무결성을 검증하기 위한 기술이다. 테스티파이섹(TestifySec) 같은 업체는 프로세스 변경이나 빌드 과정의 문제점을 감지하는 기술을 제공하고 있다.

관리 컴포넌트 : 관리 컴포넌트(Management component)는 정책 관리 프레임워크와 어테스터 및 옵저버(Attesters and observers)를 포함한다. 정책 관리 프레임워크는 조직 및 보안 요건을 명문화하는 데 기여한다. 그 과정에서 IAM, 할당된 워커 노드, 승인된 컨테이너 이미지 등을 활용한다. 이런 정책 내용은 위험을 받아들일 수 있는 범위와 규제 수준에 따라 기업마다 다를 수 있다. 

정책 관리 프레임워크는 제로 트러스트 정책을 추진하는 데 중요하다. 누가 무엇을 어떤 맥락 하에서 이용할 수 있는지를 결정하는 일은 접근 권한을 최소한으로 주는 일명 제로 트러스트 방식을 시행하는 데 핵심적이기 때문이다. 관리자 입장에선 권한 없는 개인이 추가하거나 신뢰하지 않은 출처에서 나온 컨테이너, 혹은 신뢰할 만한 출처에서 왔지만 서명이 없는 컨테이너를 배포하고 싶지는 않을 것이다. 

클라우드 네이티브 맥락에서 컨테이너와 쿠버네티스 같은 오케스트레이터는 종종 함께 사용되고, 이 과정에서 노드 어테스터(Node Attestors), 워크로드 어테스터(Workload attesters), 파이프라인 옵저버(Pipeline observers)를 다루게 된다. 이들은 노드 및 워크로드 ID의 유효성을 검증하고, 파이프라인 프로세스와 연관되어 검증할 수 있는 메타데이터를 확인한다.

배포 컴포넌트 : 배포 컴포넌트는 아티팩트 리포지터리(Artifact repository)와 어드미션 컨트롤러(Admission controller)를 포함한다. 파이프라인 프로세스의 출력물은 아티팩트를 생성하고, 그 아티팩트는 전용 리포지터리에 저장된다. 여기서 컨테이너 이미지, 쿠버네티스 매니페스트, 소프트웨어 자료 명세(SBOM), 서명 등이 포함된다. 코드 이외에도 SBOM와 어테스테이션(Attestations)에 서명하는 데는 시그스토어(Sigstrore) 같은 솔루션이 사용된다. 이와 관련된 기술은 오픈SSF의 OSS 보안 모빌라이제이션 플랜(OSS Security Mobilization Plan)에서도 다뤄진 바 있다.  

어드미션 컨트롤러(Admission controllers)는 허가된 워크로드만 스케줄링하고 워크로드 컴포넌트에 의해 실행되도록 지원한다. 이들 컨트롤러는 여러 정책을 시행할 수 있는데, 가령 어떤 출처가 빌드에서 허용되는지, 어떤 컴포넌트가 노드 호스트 상에서 허용되는지, 컴포넌트가 신뢰성 있고 검증 가능한지 등을 시행한다. 

SSF 레퍼런스 아키텍처 변수 및 기능 

SSF 가이드는 SSF 안에 입력 및 출력이 다양한 상황을 고려해 만들어졌다. 여기서 말하는 입력은 소스 코드, 소프트웨어 의존성, 사용자 인증 정보, 암호 자료, 파이프라인 정의 등의 항목을 포함한다. 출력은 소프트웨어 아티팩트, 공개 서명 키, 메타데이터 문서 등의 항목을 포함한다. 

SSF 참조 아키텍처는 복잡하다. 현대 클라우드 네이티브 환경에서 소프트웨어를 배포하는 과정에서는 많은 부분이 변하면서 그와 관련된 복잡한 프로세스를 수반한다. 그래야만 내부 환경에서 받아들일 수 있는 수준으로 소프트웨어 소비와 생산을 보장할 수 있다. 

이런 복잡성은 이들을 전부 통합하는 것이 얼마나 어려운지, 시스템이 실수나 오류에 빠질 가능성이 얼마나 높은지를 반증한다. 소프트웨어 관련 생태계 속에서 이런 요소는 다운스트림 과정에 있는 소비자에게 연쇄적으로 영향을 줄 수 있다.

흔히 방어자는 항상 옳아야 하고 악의적 공격자는 한 번만 옳으면 된다고 한다. CNCF 같은 곳에서 나온 베스트 프랙티스와 가이드를 잘 참고한다면, 기업에서 필요한 속도로 안전하게 소프트웨어를 전달할 수 있을 것이다. 
editor@itworld.co.kr
 Tags 소프트웨어팩토리 CNCF 리눅스재단
Sponsored

회사명 : 한국IDG | 제호: ITWorld | 주소 : 서울시 중구 세종대로 23, 4층 우)04512
| 등록번호 : 서울 아00743 등록일자 : 2009년 01월 19일

발행인 : 박형미 | 편집인 : 박재곤 | 청소년보호책임자 : 한정규
| 사업자 등록번호 : 214-87-22467 Tel : 02-558-6950

Copyright © 2022 International Data Group. All rights reserved.