안전한 소프트웨어 배포
오늘날의 조직은 소프트웨어 및 애플리케이션의 속도와 TTM(time to market)을 중요하게 보고 있습니다. 그러나 기존의 보안 관행이 이러한 속도를 따라잡지 못해 개발 지연, 위험을 감수하는 절충, 위협 요소 취약점이 발생하게 됩니다.
이 보고서에서는 다음을 통해 소프트웨어 공급망의 보안 문제를 해결하는 방법을 알아봅니다.
- 업계 전반의 표준 및 프레임워크 채택
- 제로 트러스트 아키텍처에서 최소 권한의 원칙을 사용하는 관리형 서비스로 이러한 표준 구현
안전한 기반 위에서 코드를 빌드, 패키징, 배포, 소프트웨어 실행까지 빠르게 진행하는 방법을 알아보세요.
소프트웨어 공급망 이해
현재의 보안 지형
소프트웨어 및 애플리케이션을 개발하는 수많은 조직에서 고객의 니즈에 대응하기 위한 최우선 사항으로 속도와 TTM(time to market)을 꼽습니다. 이러한 전략적 요구사항으로 인해 플랫폼 선택 시 컨테이너의 채택률이 엄청나게 증가하고 있습니다. 이러한 조직들은 지난 1년 동안 TTM(time to market) 단축, 가용성 향상, 보안 강화, 확장성 개선, 비용 절감과 같은 컨테이너의 이점을 누리면서 서버리스 접근 방식에 대해서도 고민하기 시작했습니다.
소프트웨어 솔루션은 새로운 기능이나 신규 제품을 출시하는 데 소요되는 시간을 단축했지만, 기존의 여러 보안 관행이 속도 증가를 따라잡지 못해 다음과 같은 세 가지 문제점 중 하나가 발생하고 있습니다.
- 기존 프로세스로 인해 개발자의 작업 속도가 느려져 지연 발생
- 보안팀과 운영팀의 절충으로 인해 조직이 위협에 노출됨
- 개발팀이 기한 준수를 위해 기존 보안 프로세스를 우회하여 취약점 발생
지난 몇 년 동안 '소프트웨어 공급망' 공격으로 분류된 많은 보안 침해가 발생했습니다.
Log4Shell은 2021년 12월에 발견된 Apache Log4j 소프트웨어의 위험한 취약점입니다. 최대 CVSS 점수 10으로 신고된 이 취약점은 자바 기반 로깅 프레임워크인 Log4j의 인기로 인해 특히 치명적이었습니다. 두 가지 사항이 심각도에 영향을 주었습니다. 첫 번째로, 악용하기가 매우 쉽고 원격 코드 실행이 완전히 허용되었으며 두 번째로, 종속 항목 트리에서 매우 깊이 위치한 경우가 많아 간과되기 쉬웠습니다.
IT 관리 소프트웨어 기업인 Solarwinds는 회사에서 사용하는 오픈소스 소프트웨어의 공식 빌드에 악성 코드를 삽입한 국가 행위자들의 공격을 받았습니다. 이 악성 업데이트는 미국 재무부와 상무부를 포함한 18,000명의 고객에게 푸시되었습니다.
또 다른 IT 관리 소프트웨어 제공업체인 Kaseya는 제로데이 취약점을 통한 공격을 받은 결과 Kaseya VSA 서버에 침투를 허용하여 감염된 시스템의 모든 파일을 암호화하는 랜섬웨어를 배포하는 악성 스크립트를 전송했습니다.
이러한 종류의 사건에 긴급히 대처할 필요성을 절감한 백악관은 2021년 5월에 연방 정부와 거래하는 조직들이 특정한 소프트웨어 보안 표준을 지키도록 의무화하는 행정 명령을 발표했습니다.
소프트웨어 공급망
'소프트웨어 공급망'은 여러 가지 의미에서 알맞은 용어입니다. 소프트웨어 공급망을 만드는 프로세스는 자동차 생산에 들어가는 프로세스와 매우 유사합니다.
자동차 제조업체는 다양한 상용 부속품을 조달하고, 독점적인 자체 부품을 제조하고, 고도로 자동화된 프로세스를 사용하여 모든 구성품을 하나로 조립합니다. 제조업체는 타사에서 조달하는 각 부품이 신뢰할 만한 출처로부터 공급되는지를 검증하여 운영상의 보안을 보장합니다. 자체 생산 부품은 집중적인 시험을 거쳐 보안 문제가 없음을 확인합니다. 마지막으로, 신뢰할 수 있는 공정을 통해 조립을 수행하여 자동차를 완성합니다.
소프트웨어 공급망은 여러 면에서 이와 유사합니다. 소프트웨어 제조업체는 특정 기능을 수행하는 타사 구성요소(일반적으로 오픈소스)를 확보하고 자체 소프트웨어를 개발하며, 소프트웨어는 회사의 핵심적인 지적 재산입니다. 그런 다음 코드의 빌드 프로세스를 진행하여 이러한 구성요소를 배포 가능한 아티팩트로 결합한 후 프로덕션으로 배포합니다.
체인의 약한 고리
안전하지 않은 고리가 단 하나만 있어도 소프트웨어 공급망의 보안이 침해를 받습니다.
작년에 부각된 공격의 사례에서 보듯이, 프로세스의 각 단계가 공격자가 악용하는 취약점으로 이어질 수 있습니다.
예를 들어 평균적인 npm 패키지에는 12개의 직접 종속 항목과 약 300개의 간접 종속 항목이 있습니다. 뿐만 아니라, 게시된 모든 npm 패키지 중 거의 40%가 취약점이 알려진 코드에 의존한다는 사실이 알려져 있습니다.
이러한 취약점이 실제로 코드를 위험하게 만들지 않을 수도 있습니다. 예를 들어 취약점을 갖는 라이브러리가 실제로는 사용되지 않는 경우도 있습니다. 그러나 이러한 취약점도 점검되어야 합니다.
이 문제는 엄청난 파급 효과를 가져올 수 있습니다. 이러한 취약점 중 단 하나만 패치되지 못하더라도 악의적인 행위자가 소프트웨어 공급망에 침입할 수 있습니다.
다음은 위의 다이어그램에서 보여주는 각 단계의 취약점을 활용한 공격의 몇 가지 사례입니다.
| 위협 | 알려진 사례 | |
| A | 소스 저장소에 악성 코드 제출 | Linux 위장 커밋: 연구원이 메일링 리스트로 패치를 배포하여 Linux 커널에 의도적으로 취약점을 심으려고 했습니다. |
| B | 소스 제어 플랫폼 침투 | PHP: 공격자가 PHP의 자체 호스팅 git 서버에 침투하여 2개의 악성 커밋을 삽입했습니다. |
| C | 공식 프로세스를 따른 빌드에 소스 제어와 일치하지 않는 코드가 사용됨 | Webmin: 공격자가 소스 제어와 일치하지 않는 소스 파일을 사용하도록 빌드 인프라를 수정했습니다. |
| D | 빌드 플랫폼 침투 | SolarWinds: 공격자가 빌드 플랫폼에 침투하여 각 빌드 중에 악의적인 동작을 삽입하는 악성 코드를 심었습니다. |
| E | 악성 종속 항목(즉, A-H 반복) | event-stream: 공격자는 무해한 종속 항목을 추가한 다음 종속 항목을 업데이트하여 악의적인 동작을 추가했습니다. 업데이트가 GitHub에 제출된 코드(예: 공격 F)와 일치하지 않습니다. |
| F | CI/CD 시스템으로 빌드되지 않은 아티팩트 업로드 | Codecov: 공격자가 유출된 사용자 인증 정보를 사용하여 직접 사용자가 다운로드하는 Google Cloud Storage 버킷에 악성 아티팩트를 업로드했습니다. |
| G | 패키지 저장소 침투 | 패키지 미러에 대한 공격: 연구원이 널리 사용되는 여러 패키지 저장소에 대해 악성 패키지를 제공했을 가능성이 있는 미러를 실행했습니다. |
| H | 소비자가 악성 패키지를 사용하도록 기만 | Browserify typosquatting: 공격자가 진짜 이름과 비슷한 이름으로 악성 패키지를 업로드했습니다. |
체인을 튼튼하게: Google Cloud의 오픈소스 사고 리더십
Google은 수십 년간 글로벌 규모의 애플리케이션을 개발해 왔습니다. 이 과정에서 수많은 내부 프로젝트를 오픈소스로 제공하여 개발자의 작업 속도를 높이는 데 기여했습니다. 이와 동시에 소프트웨어 경험의 보안 강화에 도움이 되는 다양한 내부 프로세스를 수립했습니다.
소프트웨어 공급망의 모든 요소를 튼튼하게 만들려는 Google의 노력은 다음과 같습니다.
- 투자 확대 – 2020년 8월 Google은 향후 5년 동안 제로 트러스트 프로그램 확장, 소프트웨어 공급망 보안 지원, 오픈소스 보안성 향상 등 사이버 보안 강화에 100억 달러를 투자할 계획이라고 발표했습니다.
- SLSA(Supply-chain Levels for Software Artifacts) – SLSA는 공급망의 무결성을 위한 엔드 투 엔드 프레임워크입니다. 이는 Google에서 내부적으로 시행 중인 여러 프로세스의 오픈소스 버전입니다. SLSA는 빌드 결과물과 방식에 대해 감사 가능한 출처를 제공합니다.
- DORA(DevOps Research and Assessment) – DORA팀은 7년에 걸친 연구 프로그램을 통해 소프트웨어 배포 및 조직 운영의 성과를 높이는 다양한 기술, 프로세스, 측정, 문화적 역량을 검증했습니다.
- Open Source Security Foundation – 2019년 Google은 공급망 보안에 관한 산업 간 포럼인 Open Source Security Foundation을 공동으로 설립했습니다.
- Allstar – Allstar는 조직 또는 저장소에 설치하여 보안 정책을 설정하고 적용하는 GitHub 앱입니다. 이 앱으로 GitHub 프로젝트에 보안 권장사항을 지속적으로 적용할 수 있습니다.
- 오픈소스 스코어카드 – 스코어카드는 잘 정의된 보안 정책, 코드 검토 프로세스, 퍼징을 사용한 지속적 테스트 범위, 정적 코드 분석 도구 등의 평가 측정항목을 사용하여 오픈소스 프로젝트의 위험 점수를 제공합니다.
Google은 소프트웨어 공급망의 보안 문제를 해결하려면 다음 두 가지가 필요하다고 생각합니다.
- 업계 전반의 표준 및 프레임워크
- 최소 권한의 원칙을 사용하여 이러한 표준을 구현하는 관리형 서비스, 일명 제로 트러스트 아키텍처. 제로 트러스트 아키텍처란 어떠한 사람, 기기, 네트워크에도 내재적인 신뢰를 두지 않는 아키텍처로서, 모든 상황에서 신뢰를 획득해야 정보 액세스가 허용됩니다.
내용을 하나씩 살펴보겠습니다.
업계 전반의 표준 및 프레임워크
소프트웨어 공급망 보안에 적용되는 원칙을 이해하기 위해 SLSA부터 설명하겠습니다.
SLSA의 현재 모습은 업계 전반의 합의에 따라 수립된 보안 가이드라인 모음으로서 점진적인 채택이 가능합니다. 최종적으로 완성된 후의 SLSA는 단순한 권장사항 목록과 달리 적용 편의성이 높을 것이며, 감사 가능한 메타데이터가 자동으로 생성되어 정책 엔진에 입력되고 특정 패키지 또는 빌드 플랫폼에 'SLSA 인증'이 부여될 것입니다.
SLSA는 점진적이고 실행성을 가지며 모든 단계에서 보안 이점을 제공하도록 설계되었습니다. 소비자는 최고 등급을 통과한 아티팩트에 대해 변조되지 않았고 출처를 안전하게 역추적할 수 있다는 신뢰를 가질 수 있으며, 현재 대다수의 소프트웨어에 대해서는 이러한 신뢰가 불가능하지는 않더라도 매우 어렵습니다.
SLSA는 4등급으로 구성되며 이상적인 최종 상태는 SLSA 4입니다. 하위 등급은 해당 수준까지만 점진적으로 무결성이 보장된다는 의미입니다. 현재 정의된 요구사항은 다음과 같습니다.
SLSA 1은 빌드 프로세스가 완전히 스크립트화/자동화되고 출처를 생성하도록 규정합니다. 출처란 빌드 프로세스, 최상위 소스, 종속 항목을 비롯하여 아티팩트가 빌드되는 방식에 관한 메타데이터입니다. 출처가 제공되면 소프트웨어 소비자가 위험을 고려하여 보안과 관련한 결정을 내릴 수 있습니다. SLSA 1에서 규정하는 출처는 변조로부터 보호되지 않지만 기본적인 수준의 코드 소스 식별을 제공하며 취약점 관리에 도움이 될 수 있습니다.
SLSA 2는 버전 제어 및 인증된 출처를 생성하는 호스팅된 빌드 서비스를 사용하도록 규정합니다. 이러한 추가 요구사항은 소비자에게 소프트웨어의 출처에 대한 신뢰를 높여줍니다. 이 등급에서는 빌드 서비스를 신뢰할 수 있다는 전제 하에 출처 변조가 방지됩니다. 또한 SLSA 2는 SLSA 3으로 쉽게 업그레이드할 수 있습니다.
SLSA 3은 소스 및 빌드 플랫폼이 소스의 감사 가능성과 출처의 무결성을 각각 보장하는 특정 기준을 충족하도록 규정합니다. SLSA 3은 교차 빌드 오염과 같은 특정 유형의 위협을 차단하여 하위 등급보다 훨씬 더 철저하게 변조를 방지합니다.
현행 최고 수준인 SLSA 4는 모든 변경사항의 2인 검토 및 빌드 프로세스의 밀폐성과 재현성을 규정합니다. 2인 검토는 실수를 포착하고 악성 동작을 방지하기 위한 업계 권장사항입니다. 빌드의 밀폐성은 출처의 종속 항목 목록이 완전함을 보장합니다. 빌드의 재현성은 엄격히 요구되지는 않지만 감사 가능성과 신뢰성 면에서 많은 이점을 제공합니다. 전반적으로 SLSA 4는 소비자에게 소프트웨어가 변조되지 않았다는 높은 수준의 확신을 줍니다. 이러한 등급 제안에 대한 자세한 내용 및 해당 소스와 빌드/출처 요구사항은 GitHub 저장소를 참조하세요.
소프트웨어 공급망은 코드, 빌드, 패키지, 배포, 실행이라는 5가지 단계로 나눌 수 있습니다. Google은 보안 접근방식에 따라 이러한 각 단계를 처리합니다.
단계별 관리형 서비스
Google Cloud는 코드 및 빌드부터 배포 및 실행까지 위와 같은 기준과 권장사항을 기본적으로 구현하는 완전 관리형 도구를 제공합니다.
소프트웨어 공급망을 보호하려면 코드의 출처를 식별하고 프로덕션에서 실행되는 코드가 의도한 것과 일치함을 보장하는 신뢰 체인을 확립하고, 검증하고, 유지해야 합니다. Google은 소프트웨어 개발 및 배포 프로세스 전반에 걸쳐 생성되고 검사되는 증명을 통해 이를 달성하면서 코드 검토, 코드 출처 검증, 정책 시행을 통해 전반적인 보안 수준을 높입니다. 이러한 프로세스는 개발자의 생산성을 높이는 동시에 소프트웨어 공급망 위험을 최소화하는 데 기여합니다.
ID 및 액세스 관리, 감사 로깅 등의 공통적인 보안 인프라 서비스가 기반을 이룹니다. 그 위에서 소프트웨어 수명 주기 전반에 걸쳐 증명을 정의, 확인, 시행하는 방식으로 소프트웨어 공급망을 보호합니다.
Google Cloud에서 정책 및 출처를 통해 개발 프로세스의 전반적인 보안을 달성하는 방법을 자세히 알아보겠습니다.
1단계: 코드
소프트웨어 공급망 보호는 개발자가 애플리케이션 설계 및 코드 작성을 개시하는 순간부터 시작됩니다. 여기에는 자사 소프트웨어와 오픈소스 구성요소가 모두 포함되며, 이들에는 각기 다른 과제가 따릅니다.
오픈소스 소프트웨어 및 종속 항목
오픈소스는 개발자의 개발 속도를 높이므로 조직의 민첩성과 생산성 향상에 기여합니다. 그러나 오픈소스 소프트웨어는 완벽성이 보장되지 않을 뿐 아니라, 업계에서 여기에 의존함에도 불구하고 그 안에 어떠한 종속 항목이 있으며 어느 정도의 위험이 따르는지를 파악하기가 매우 어렵습니다. 대부분의 기업들이 겪는 위험의 주 원인은 취약점 또는 라이선스입니다.
개발자가 의존하는 오픈소스 소프트웨어, 패키지, 기본 이미지 및 기타 아티팩트가 '신뢰 체인'의 기반을 형성합니다.
예를 들어 조직에서 'a'라는 소프트웨어를 개발할 때의 신뢰 체인, 즉 프로젝트의 암시적 종속 항목의 개수는 위 다이어그램과 같습니다. 다이어그램에서 'b'부터 'h'까지는 직접 종속 항목, 'i'부터 'm'까지는 간접 종속 항목입니다.
종속 항목 트리 심층부에 취약점이 있다고 가정해 보겠습니다. 이 경우 많은 구성요소에서 빠르게 문제가 발생할 수 있습니다. 게다가 종속 항목은 매우 빈번하게 변경됩니다. 하루 평균 40,000개의 npm 패키지가 종속 항목 변경을 경험합니다.
Google Cloud에서 개발한 도구인 Open Source Insights가 제공하는 전환적 종속 항목 그래프를 사용하면 종속 항목 트리를 끝까지 파고들면서 계층적으로 종속성을 파악할 수 있습니다. Open Source Insights는 여러 언어를 하나로 망라하는 보안 권고사항, 라이선스 정보, 기타 보안 데이터로 계속 업데이트됩니다. 개발자는 오픈소스 프로젝트에 대한 위험 점수를 제공하는 오픈소스 스코어카드와 Open Source Insights를 함께 사용하여 수백만 개의 오픈소스 패키지에 대해 더 합리적인 의사 결정을 내릴 수 있습니다.
이 문제에 대처하려면 종속 항목을 코드의 관점에서 바라볼 필요가 있습니다. 공급망에서 끝으로 이동할수록 종속 항목을 조사하기가 어려워집니다. 종속 항목의 보안을 강화하려면 공급망 초기부터 시작하는 것이 좋습니다.
- Open Source Insights 및 OSS 스코어카드와 같은 도구를 사용하여 종속 항목을 철저히 파악하세요.
- 워크플로의 핵심을 이루는 자동화 프로세스를 통해 모든 코드, 패키지, 기본 이미지를 스캔하고 검증하세요.
- 이러한 종속 항목에 대한 개발자의 접근을 통제하세요. 자사 코드와 오픈소스 코드의 저장소를 긴밀하게 통제하고 철저한 코드 검토 및 감사 요구사항을 강제하는 것이 매우 중요합니다.
뒷부분에서 빌드 및 배포 프로세스를 더 자세히 살펴보겠지만 빌드의 출처 확인, 보안 빌드 환경 활용, 이미지 서명 확인, 배포 시 후속 검증도 중요합니다.
또한 개발자는 다음과 같은 안전한 코딩 관행을 채택할 수 있습니다.
- 테스트 자동화
- 메모리 안전성을 갖는 소프트웨어 언어 사용
- 코드 검토 의무화
- 커밋 신뢰성 보장
- 악성 코드를 조기에 식별
- 민감한 정보 노출 방지
- 로깅 및 빌드 출력 필수화
- 라이선스 관리 활용
2단계: 빌드
소프트웨어 공급망의 보안을 강화하는 다음 단계는 대규모 보안 빌드 환경을 구축하는 것입니다. 빌드 프로세스는 본질적으로 저장소에서 여러 언어 중 하나로 소스 코드를 가져오고 구성 파일에 명시된 사양을 충족하도록 빌드를 실행할 때 시작됩니다.
Google과 같은 클라우드 제공업체는 사용자가 원하는 규모로 이미지를 빌드할 수 있는 최신 관리형 빌드 환경을 제공합니다.
빌드 프로세스를 진행하면서 다음과 같은 몇 가지 사항을 고려해야 합니다.
- 빌드 프로세스 중이나 그 이후에 보안 비밀이 안전하게 보호되는가?
- 빌드 환경에 누가 액세스할 수 있는가?
- 비교적 새로운 공격 벡터 또는 유출 위험은 어떠한가?
안전한 빌드 환경을 구축하려면 보안 비밀부터 시작해야 합니다. 이는 매우 중요하면서도 비교적 쉽게 보호할 수 있습니다. 가장 먼저, 보안 비밀이 일반 텍스트가 아니고 빌드에 가급적 포함되지 않도록 합니다. 보안 비밀을 암호화하고 빌드를 매개변수화하여 필요에 따라 외부 보안 비밀을 참조해야 합니다. 이렇게 하면 보안 비밀의 주기적 순환이 간소화되고 유출의 영향이 최소화되는 효과도 있습니다.
다음 단계는 빌드에 대한 권한을 설정하는 것입니다. 빌드 프로세스에는 다양한 사용자와 서비스 계정이 관여됩니다. 예를 들어 어떤 사용자는 보안 비밀을 관리할 수 있어야 하고, 다른 사용자는 단계를 추가하거나 수정하여 빌드 프로세스를 관리해야 하고, 또 다른 사용자는 로그만 보면 됩니다.
이 과정에서 다음과 같은 권장사항을 따르는 것이 중요합니다.
- 가장 중요한 것은 최소 권한의 원칙입니다. 세분화된 권한을 구현하여 사용자와 서비스 계정에 작업을 효과적으로 수행하는 데 필요한 정확한 권한을 부여합니다.
- 사용자와 서비스 계정이 상호작용하는 방식을 이해하고 빌드 설정부터 빌드 실행, 빌드의 다운스트림 효과에 이르기까지 책임 소재가 어떻게 연결되는지를 명확히 파악해야 합니다.
다음으로, 이 프로세스를 확장하면서 빌드 주위에 최대한의 경계를 설정하고 자동화를 사용하여 코드 및 매개변수화를 사용한 구성을 통해 확장하세요. 이렇게 하면 빌드 프로세스의 변경사항을 효과적으로 감사할 수 있습니다. 또한 민감한 빌드와 배포에 대한 승인 통제, 인프라 변경에 대한 pull 요청, 사람에 의한 정기적 감사 로그 검토를 통해 규정 준수 요구사항에 대응해야 합니다.
마지막으로, 네트워크가 요구사항에 맞는지 확인하세요. 대부분의 경우 자체 소스 코드를 방화벽으로 보호되는 비공개 네트워크에 호스팅하는 것이 가장 좋습니다. Google Cloud가 제공하는 자체 비공개 네트워크 경계 내부의 폐쇄형 서버리스 빌드 환경인 Cloud Build 비공개 풀 및 VPC 서비스 제어와 같은 기능을 통해 지적 재산의 유출을 방지할 수 있습니다.
Binary Authorization
IAM은 필수적이면서 논리적으로 합당한 출발점이지만 결코 만능이 아닙니다. 사용자 인증 정보가 유출되면 심각한 보안 위험으로 이어지므로, IAM에 대한 의존도를 낮추기 위해 실수의 가능성이 비교적 낮은 증명 기반 시스템으로 전환할 수 있습니다. Google은 신뢰할 수 있는 워크로드만 배포를 허용하는 Binary Authorization이라는 시스템을 사용합니다.
Binary Authorization 서비스는 프로세스 전반에서 증명 및 정책 검사를 수행하여 신뢰 체인을 확립하고 검증하고 유지합니다. 기본적으로 Binary Authorization은 코드 및 기타 아티팩트가 프로덕션으로 진행될 때 증명이라는 암호화 서명을 생성하고, 배포 전에 정책을 기반으로 해당 증명을 검사합니다.
Google Cloud Build를 사용하면 증명 모음이 캡처되어 신뢰 체인 전반에 추가됩니다. 예를 들어 실행된 작업, 사용된 빌드 도구 및 프로세스 등에 대한 증명이 생성됩니다. 특히 Cloud Build는 빌드가 스크립트화되었음을 검증하는 데 사용할 수 있는 빌드 구성 소스를 캡처하므로 SLSA 1등급을 달성하는 데 도움이 됩니다. 스크립트화된 빌드는 수동 빌드보다 안전하며 SLSA 1등급에 필수적입니다. 또한 이미지의 고유 시그니처를 생성하는 컨테이너 이미지 다이제스트를 사용하여 빌드의 출처와 기타 증명을 조회할 수 있으며, 이 기능도 SLSA 1등급에 필수적입니다.
3단계: 패키지
빌드가 완료되면 프로덕션 준비가 거의 완료된 컨테이너 이미지가 생성됩니다. 기존 이미지 조작 및 무단 이미지 업로드를 방지할 수 있는 안전한 이미지 저장 위치를 확보하는 것이 중요합니다. 패키지 관리자는 애플리케이션에 사용하는 언어 패키지뿐만 아니라 자사 및 오픈소스 빌드 모두에 대한 이미지가 필요할 수 있습니다.
Google Cloud의 Artifact Registry는 이러한 저장소를 제공합니다. Artifact Registry는 조직이 컨테이너 이미지와 언어 패키지(예: Maven 및 npm)를 모두 한곳에서 관리할 수 있는 장소입니다. Google Cloud의 도구 및 런타임과 완벽하게 통합되며 아티팩트 프로토콜을 기본적으로 지원합니다. 따라서 자동 파이프라인을 설정하는 과정에서 CI/CD 도구와 간편하게 통합할 수 있습니다.
빌드 단계와 마찬가지로, Artifact Registry에 대한 액세스 권한을 신중하게 설계하고 최소 권한의 원칙을 따르는 것이 중요합니다. Package Repository는 무단 액세스 제한 외에도 많은 가치를 제공할 수 있습니다. 예를 들어 Artifact Registry에는 이미지를 스캔하여 배포 안전성을 확인하는 취약점 스캔 기능이 포함되어 있습니다. 이 서비스는 최신 정보로 끊임없이 갱신되는 취약점 데이터베이스를 기준으로 이미지를 스캔하여 새로운 위협을 평가하고 취약점이 발견될 때 알림을 보낼 수 있습니다.
이 단계에서는 아티팩트의 취약점 결과가 특정한 보안 기준점을 충족하는지 여부에 대한 증명을 비롯한 추가 메타데이터를 생성합니다. 이 정보는 Binary Authorization에서 바로 액세스할 수 있도록 아티팩트의 메타데이터를 구조화하고 정리하는 Google의 분석 서비스에 저장됩니다. 이를 통해 Google Kubernetes Engine(GKE)에 위험한 이미지가 배포되는 상황을 자동으로 방지할 수 있습니다.
4, 5단계: 배포 및 실행
소프트웨어 보안 공급망의 마지막 두 단계는 배포 및 실행입니다. 이 두 단계는 별개의 단계이지만 승인된 빌드만 프로덕션에 적용할 수 있도록 하는 방법으로 간주하는 것이 좋습니다.
Google은 어떤 종류의 빌드를 승인할지 결정하는 기준이 되는 권장사항을 수립했습니다. 우선, 신뢰할 수 있는 아티팩트만 생성되도록 공급망의 무결성을 보장해야 합니다. 다음으로, 소프트웨어 배포 수명 주기에 취약점 관리를 포함해야 합니다. 마지막으로, 이러한 두 요소를 결합하여 무결성 및 취약점 스캔을 위한 정책 기반 워크플로를 적용해야 합니다.
이 단계까지 왔으면 코드, 빌드, 패키지 단계는 이미 완료되었으므로 Binary Authorization에서 공급망을 따라 캡처된 증명을 검증하여 신뢰성을 판단할 수 있습니다. 시행 모드에서는 증명이 조직의 정책에 맞을 때만 이미지가 배포되고, 감사 모드에서는 정책 위반이 로깅되고 알림이 트리거됩니다. Binary Authorization을 사용하면 허가된 Cloud Build 프로세스를 사용하여 빌드한 결과물만 실행이 가능하도록 제한할 수도 있습니다. Binary Authorization은 적절한 검토와 승인을 거친 코드만 배포되도록 보장합니다.
신뢰할 수 있는 런타임 환경에 이미지를 배포하는 것이 중요합니다. Google의 관리형 Kubernetes 플랫폼인 GKE는 컨테이너에 대한 보안 우선 접근 방식을 사용합니다.
GKE는 클러스터 보안과 관련된 개발자의 부담을 크게 덜어줍니다. 자동 클러스터 업그레이드를 사용하면 출시 채널을 통해 자동으로 Kubernetes를 패치하고 최신 상태로 유지할 수 있습니다. 보안 부팅, 보안 노드, 무결성 검사는 노드의 커널 및 클러스터 구성요소가 수정되지 않았고 의도대로 실행되고 있으며 악성 노드가 클러스터에 조인할 수 없음을 보장합니다. 마지막으로, 컨피덴셜 컴퓨팅을 통해 메모리가 암호화된 노드에서 클러스터를 실행하면 데이터 처리 중에도 기밀성을 유지할 수 있습니다. GKE는 여기에 저장 데이터 및 네트워크 전송 데이터의 암호화를 결합하여 컨테이너화된 워크로드를 실행하는 매우 안전한 비공개 기밀 환경을 제공합니다.
뿐만 아니라 GKE는 부하 분산기의 인증서 관리, 워크로드 아이덴티티, 클러스터의 인그레스를 구성하고 보호하는 강력한 고급 네트워크 기능을 통해 애플리케이션 보안을 강화합니다. 또한 GKE는 신뢰할 수 없는 애플리케이션을 실행하면서 나머지 워크로드를 보호하는 샌드박스 환경을 제공합니다.
GKE Autopilot을 사용하면 GKE의 보안 권장사항과 기능이 자동으로 구현되어 공격에 노출되는 영역이 더 축소되고 보안 문제로 이어질 수 있는 구성 오류가 최소화됩니다.
당연하지만, 배포 시에만 검증이 필요하지는 않습니다. Binary Authorization은 지속적 검증을 지원하므로 정의된 정책을 배포 후에도 계속 준수할 수 있습니다. 애플리케이션 실행 중에 기존 정책이나 새로 추가된 정책이 위반되면 알림이 생성 및 로깅되므로 프로덕션 환경이 정확히 의도한 대로 실행된다는 확신을 가질 수 있습니다.
취약점 관리
무결성 보장과 더불어 공급망 보안의 또 다른 측면은 모든 취약점을 신속하게 발견하여 패치하는 것입니다. 취약점을 업스트림 프로젝트에 능동적으로 삽입하는 방식으로 공격 수법이 진화하고 있습니다. 소프트웨어 배포 수명 주기의 모든 단계에 취약점 관리와 결함 감지가 통합되어야 합니다.
코드를 배포할 준비가 되면 CI/CD 파이프라인을 사용하고 소스 코드와 생성된 아티팩트를 포괄적으로 스캔할 수 있는 다양한 도구를 활용합니다. 이러한 도구에는 정적 분석기, 퍼징 도구, 다양한 유형의 취약점 스캐너가 포함됩니다.
워크로드를 프로덕션에 배포한 후, 프로덕션 실행 및 사용자 서비스 제공 중에 새로운 위협을 모니터링하고 즉각적인 해결 조치를 취할 계획을 세워야 합니다.
결론
요약하면, 소프트웨어 공급망 보호의 관건은 SLSA와 같은 권장사항을 따르고 이러한 권장사항을 구현하는 데 도움이 되는 신뢰할 수 있는 관리형 서비스를 사용하는 것입니다.
다음 사항을 명심하시기 바랍니다.
- 가장 먼저 코드 및 종속 항목의 신뢰성을 확인하세요.
- 빌드 시스템을 보호하고 증명을 사용하여 필요한 빌드 단계를 모두 따랐는지 확인하세요.
- 모든 패키지와 아티팩트를 신뢰할 수 있고 변조가 불가능한지 확인하세요.
- 누가 무엇을 배포할 수 있는지를 통제하고 감사 추적을 유지하세요. Binary Authorization을 사용하여 배포할 모든 아티팩트의 증명을 검증하세요.
- 신뢰할 수 있는 환경에서 애플리케이션을 실행하고 실행 중에 누구도 애플리케이션을 변조할 수 없도록 조치하세요. 새로 발견되는 모든 취약점을 점검하여 배포를 보호하세요.
Google은 개발 작업에 신뢰할 수 있는 토대를 마련해 드리기 위해 각 단계를 진행하면서 따라야 할 권장사항을 제품 포트폴리오에 적용하고 있습니다.
시작하기
소프트웨어 공급망을 보호할 준비가 되셨나요? 주목할 부분은 시작 위치는 대체로 임의적입니다. 전체 공급망을 보호할 단일 조치는 없으며 전체 공급망 보안과 관련하여 다른 조치보다 더 중요한 조치는 없습니다. 그렇긴 하지만 시작하기 위한 4가지 권장사항을 소개합니다.
1. 소프트웨어 패치하기
취약점이 알려진 코드를 프로덕션 환경에 배포했다면 공격자를 도와준 것과 다름이 없습니다. 그 시점부터는 공격자의 침입 경로가 이미 열려 있으므로 소프트웨어 공급망을 아무리 잘 보호해도 소용이 없습니다. 따라서 패치가 매우 중요합니다.
2. 환경에서 무엇이 실행되는지 통제하기
패치가 철저히 이루어졌다면 이제 소프트웨어 공급망 자체를 제어할 수 있어야 합니다. 가장 먼저, 실행 중인 항목의 실제 출처가 빌드 도구 또는 신뢰할 수 있는 저장소인지 확인할 수 있어야 합니다. 이러한 수준의 제어를 구현하면 의도적인 공격과 의도치 않은 실수, 예를 들어 개발자가 위험성을 인지하지 못하고 실수로 배포하는 경우를 함께 방지하는 데 도움이 됩니다. 이와 같이 튼튼한 기반 위에 클릭 테스트, Binary Authorization 등의 도구를 추가해 나갈 수 있습니다.
3. 타사 공급업체 패키지가 안전한지 확인하기
공급망 보안에서 새롭게 부각되는 문제로서, 공급업체의 소프트웨어가 침투를 받아 랜섬웨어의 매개체가 되거나 대상 고객 배포에 대한 무단 액세스가 가능해지는 사고가 빈번합니다. 개발자 환경에서 실행되는 시스템 관리 제품, 네트워크 관리 제품, 보안 제품을 비롯한 타사 공급업체 패키지는 높은 수준의 권한을 갖는 경우가 많습니다. 사용 중인 패키지에 대해 상투적인 보안 안내문에 그치지 않고 일정 수준의 보증을 제공하도록 공급업체에 요청하는 것이 좋습니다. 업체의 SLSA 준수 등급이 무엇인지 또는 최근의 행정 명령에서 요구하는 수준에 부합하는지 여부를 문의할 수 있습니다.
4. 소스 코드의 비공개 사본 유지하기
오픈소스 소프트웨어를 사용하여 빌드하는 경우 인터넷에서 바로 가져온 버전을 사용하지 마세요. 대신 비공개 사본을 유지하면서 지속적으로 패치하면 모든 빌드를 시작할 청정 환경을 마련하고 소스 코드의 출처를 100% 확신할 수 있습니다.
추가 자료
DevOps 권장사항
- 6년간의 State of DevOps Report, 소프트웨어 배포 실적 예측 기능에 대한 자세한 정보가 담긴 문서 모음, 현황 및 개선 방법 파악을 위한 빠른 점검을 이용할 수 있습니다.
- Google Cloud 2021 Accelerate State of DevOps Report
- Google Cloud 백서: 클라우드 기반으로 재설계: 대규모의 개발자 생산성 향상을 위한 혁신적 접근 방식
소프트웨어 공급망 보호
- Google Cloud 블로그: 제로 트러스트 ID 보안이란?
- Google 보안 블로그: 공급망의 무결성을 위한 엔드 투 엔드 프레임워크인 SLSA 소개
- Google Cloud 백서: 개발 초기부터 보안 문제 반영: 소프트웨어 공급망 보호