KIMKYUTAE.COM · ©
CSP OS 이미지 보안은 어떻게 관리될까
클라우드 콘솔에서 Ubuntu나 Windows Server를 고르면 몇 분 안에 서버가 만들어진다.
너무 자연스러워서 그 OS 이미지가 누가 만들었고, 어떤 검증을 거쳐 배포됐는지는 놓치기 쉽다.
하지만 보안담당자에게 중요한 질문은 단순히 “어떤 OS인가”가 아니다. 누가 만든 이미지인지, 무엇을 기준으로 구성했는지, 취약점과 무결성을 어떻게 확인했는지, 어떤 버전이 어느 범위에 배포됐는지를 알아야 한다.
이 글에서는 CSP가 OS 이미지를 제공하고 배포하는 과정에 대해 살펴본다.
클라우드의 OS 이미지는 한 가지가 아니다
CSP가 보여주는 OS 목록은 하나의 창구처럼 보이지만 출처와 관리 방식은 서로 다르다. 같은 Ubuntu라도 CSP가 직접 구성한 이미지, Canonical이 제공한 이미지, Marketplace의 보안 강화 이미지, 회사가 자체 제작한 Golden Image가 함께 존재할 수 있다.
| 이미지 유형 | 어떻게 제공되는가 | 보안담당자가 먼저 볼 것 |
|---|---|---|
| CSP·OS 제조사 공식 이미지 | 클라우드의 기본 카탈로그에 게시 | 게시자 ID, 지원 버전, 생성일, 릴리스 문서 |
| Marketplace·파트너 이미지 | 제3자 게시자가 유료 또는 무료로 제공 | 게시자 신원, 업데이트 정책, 계약과 지원 주체 |
| 조직의 Golden Image | 공식 이미지를 기반으로 내부 파이프라인에서 제작 | 원본 이미지, 빌드 레시피, 하드닝 기준, 승인 이력 |
| Kubernetes 노드 이미지 | EKS·AKS·GKE가 노드용 구성요소와 함께 버전별 제공 | 지원 OS, 이미지 릴리스 주기, Kubernetes 버전 호환성 |
| 관리형 서비스·CSP 인프라 이미지 | 고객에게 직접 공개하지 않고 CSP가 내부 배포 | 보안 설계 문서, 인증·감사 보고서, 변경·무결성 통제 |
여기서 가장 중요한 원칙은 이미지가 카탈로그에 있다는 사실만으로 공식 이미지라고 판단하지 않는 것이다. AWS라면 AMI 소유자, Azure라면 Publisher·Offer·SKU, Google Cloud라면 이미지 프로젝트처럼 제공자를 식별할 수 있는 값을 확인해야 한다.
안전한 이미지는 빌드 파이프라인에서 만들어진다
OS 이미지 보안은 완성된 파일 하나를 검사하는 일로 끝나지 않는다. 신뢰할 수 있는 원본을 선택하고, 같은 절차로 다시 만들 수 있게 자동화하며, 배포 전에 검증하고, 버전별로 통제하는 공급망 관리에 가깝다.
1. 원본과 게시자를 고정한다
이름이 같은 이미지를 공격자가 공개 이미지로 올릴 수 있기 때문에 이름만 비교해서는 부족하다. 원본의 소유 계정이나 프로젝트, 게시자 식별자, 이미지 ID와 버전을 승인 목록으로 관리해야 한다.
2. 빌드 과정을 코드와 레시피로 남긴다
패키지 추가·삭제, 보안 설정, 에이전트 설치를 사람이 수동으로 반복하면 결과가 달라질 수 있다. 빌드 레시피와 스크립트를 버전 관리하고, 변경 승인과 실행 기록을 남겨야 어느 이미지에 무엇이 들어갔는지 설명할 수 있다.
3. 하드닝과 취약점 검사를 구분한다
하드닝은 SSH, 계정, 파일 권한, 감사 설정처럼 안전한 구성 기준을 적용하는 일이다. 취약점 검사는 포함된 패키지와 소프트웨어에 알려진 문제가 있는지 찾는 일이다. 둘 중 하나만 통과했다고 안전한 이미지가 되는 것은 아니다.
4. 테스트를 통과한 버전만 배포한다
부팅, 네트워크, 원격 접속, 보안 에이전트, 애플리케이션 호환성을 함께 확인해야 한다. 통과한 이미지는 고유 버전으로 게시하고, 지역과 계정에 복제하며, 승인되지 않은 이미지는 배포 정책에서 막는 방식이 좋다.
5. 지원 종료와 폐기를 관리한다
새 버전을 게시하는 것만으로는 부족하다. 오래된 이미지가 신규 배포에 다시 사용되지 않도록 사용 중단 표시, 권한 제거, 카탈로그 제외 같은 절차가 필요하다. 여기까지가 이미지 공급망의 한 주기다.
따라서 “최신 보안 패치가 포함된 이미지”라는 설명은 그 이미지가 만들어진 시점의 상태를 뜻한다. 영구적인 보안 보증도, CIS 준수 인증도 아니다.
주요 CSP는 이미지를 어떻게 제공할까
세 CSP의 제품 이름은 다르지만 구조는 비슷하다. 공식·파트너 이미지를 카탈로그로 제공하고, 고객이 표준 이미지를 자동으로 만들 수 있는 빌드 서비스와 버전 배포 기능을 제공한다. Kubernetes에는 일반 VM과 별도의 노드 이미지를 제공한다.
| CSP | 고객 선택 이미지 | 조직 표준 이미지 제작·배포 | Kubernetes 노드 이미지 예 |
|---|---|---|---|
| AWS | AMI, AWS Marketplace | EC2 Image Builder로 빌드·검증·테스트·배포 자동화 | EKS 최적화 Amazon Linux AMI, Bottlerocket |
| Microsoft Azure | Azure Marketplace 이미지 | VM Image Builder로 제작, Azure Compute Gallery로 버전·복제·공유 | Ubuntu, Azure Linux, Windows Server 노드 이미지 |
| Google Cloud | Public·Partner·Community 이미지 | Custom Image와 Image Family로 버전 계열 관리 | Container-Optimized OS, Ubuntu, Windows Server |
AWS: AMI 소유자와 빌드 계보가 핵심이다
AWS는 EC2 시작 화면에서 AWS 제공 이미지와 Marketplace 이미지를 함께 보여준다. AWS 문서는 Amazon이 소유한 이미지를 찾을 때 Owner alias 또는 --owners amazon을 사용하도록 안내한다. 보안 정책에는 사람이 읽는 이미지 이름보다 AMI 소유자와 AMI ID를 넣는 편이 안전하다.
EC2 Image Builder는 원본 이미지와 구성요소를 조합해 이미지를 만들고, 검증·테스트를 통과한 결과를 계정과 리전에 배포할 수 있게 한다. 취약점 스캔 설정과 이미지 계보를 함께 관리할 수 있다는 점이 보안담당자에게 중요하다.
Kubernetes용으로는 EKS 최적화 AMI가 별도로 제공된다. 일반 Linux 이미지 위에 kubelet, containerd 등 노드에 필요한 구성요소가 미리 들어간 목적형 이미지다. 따라서 일반 EC2 이미지와 같은 승인 기준을 그대로 적용하기보다 Kubernetes 버전과 이미지 릴리스의 조합을 확인해야 한다.
Azure: 빌드와 배포 카탈로그를 분리한다
Azure VM Image Builder는 Marketplace 또는 기존 사용자 이미지를 원본으로 받아 보안 설정과 소프트웨어를 적용하고 결과 이미지를 만든다. 생성 결과는 Managed Image, VHD 또는 Azure Compute Gallery에 저장할 수 있다.
Compute Gallery는 이미지 정의와 버전을 나누고 여러 리전에 복제하며, 조직·구독·테넌트 또는 공개 범위로 공유할 수 있다. 보안담당자는 Gallery의 게시 권한, 버전 변경 이력, 복제 대상 리전과 승인 버전을 함께 확인해야 한다.
AKS도 별도 노드 이미지를 제공한다. AKS 문서에 따르면 Linux 노드 이미지는 주 단위, Windows 노드 이미지는 월 단위로 새 버전이 제공되며 보안 수정과 구성요소 업데이트가 릴리스 노트에 기록된다. 이 주기는 “현재 어떤 이미지가 배포 가능한가”를 판단하는 기준으로 사용할 수 있다.
Google Cloud: 프로젝트와 Image Family를 확인한다
Google Cloud의 Compute Engine OS 이미지는 Google, 오픈소스 커뮤니티, 제3자 제조사가 제공하는 Public Image와 조직이 소유하는 Custom Image로 나뉜다. 제공 주체가 다르므로 이미지 이름뿐 아니라 source project와 지원 주체를 확인해야 한다.
Image Family는 관련 이미지를 한 계열로 묶고, 폐기되지 않은 최신 버전을 가리킨다. 편리하지만 심사·재현이 중요한 환경에서는 family 이름만 저장하지 말고 실제 선택된 이미지 버전도 배포 증적으로 남기는 편이 좋다.
GKE는 Container-Optimized OS(COS), Ubuntu, Windows Server 노드 이미지를 제공한다. 특히 COS는 패키지 관리자를 두지 않고 루트 파일시스템을 읽기 전용으로 구성하며, 부팅 때 무결성을 확인하는 목적형 OS다. 범용 Linux와 기능이 다르므로 보안성뿐 아니라 필요한 드라이버와 패키지의 호환성도 함께 검토해야 한다.
고객에게 보이지 않는 OS는 어떻게 확인할까
관리형 데이터베이스, 서비스 제어 영역, 하이퍼바이저와 물리 호스트에도 OS 또는 이에 준하는 시스템 소프트웨어가 있다. 다만 고객이 그 이미지를 내려받거나 직접 검사할 수는 없다. 이 영역은 이미지 파일이 아니라 CSP의 이미지 제작·승인·배포 통제에 대한 증거로 평가해야 한다.
- 이미지가 승인된 원본과 자동화된 빌드 절차에서 생성되는가
- 악성코드·취약점·설정 기준과 기능 테스트를 통과해야 배포되는가
- 서명, Secure Boot, 측정 부팅, 원격 증명 등으로 의도한 소프트웨어만 부팅되는가
- 버전 배포와 롤백이 분리된 승인 절차와 감사 로그에 남는가
- 지원 종료 이미지가 카탈로그와 내부 배포 대상에서 제거되는가
- 외부 인증과 감사 보고서에서 관련 통제의 설계와 운영 효과를 확인할 수 있는가
예를 들어 Google은 인프라 보안 설계 문서에서 서버가 의도한 소프트웨어 스택으로 부팅했는지 Verified Boot와 Attestation으로 확인하고, 무결성 검사를 통과하지 못한 장비를 제거하거나 복구한다고 설명한다. 이런 자료가 고객이 볼 수 없는 OS 영역을 평가하는 근거가 된다.
CIS Hardened Image는 기본 이미지와 다르다
기본 OS 이미지가 클라우드에서 동작하도록 구성됐다고 해서 CIS Benchmark까지 적용됐다는 뜻은 아니다. CIS Hardened Images는 CIS Benchmark의 보안 설정을 미리 적용한 별도 이미지이며 AWS, Azure, Google Cloud Marketplace에서 제공된다.
사용할 때는 “CIS 적용”이라는 문구만 보지 말고 대상 OS 버전, Benchmark 버전, Level 1·Level 2 프로필, 예외 항목과 게시자를 확인해야 한다. 강한 하드닝은 기능이나 운영 도구와 충돌할 수 있으므로 조직의 Golden Image 원본으로 채택하기 전에 호환성 테스트가 필요하다.
보안담당자가 이미지 승인 전에 볼 체크리스트
- 제공자 식별: 소유 계정, Publisher, 프로젝트가 공식 문서의 값과 일치하는가
- 원본 추적: 최종 이미지가 어떤 base image와 빌드 레시피에서 나왔는가
- 버전 고정: 이미지 ID와 버전, 생성 시각, 배포 리전이 기록되는가
- 보안 기준: CIS·STIG·자체 기준 중 무엇을 적용했고 예외는 승인됐는가
- 구성 명세: 설치 패키지, 드라이버, 에이전트와 가능하다면 SBOM을 확인할 수 있는가
- 검증 결과: 취약점·악성코드·부팅·기능·호환성 테스트를 통과했는가
- 무결성: 빌드 산출물과 배포 이미지가 바뀌지 않았음을 검증할 수 있는가
- 배포 통제: 승인된 이미지와 게시자만 사용할 수 있도록 정책으로 제한했는가
- 폐기 기준: 지원 종료·취약 이미지가 신규 배포 목록에서 제거되는가
- 비공개 OS 증거: 관리형 서비스와 인프라 OS는 설계 문서·인증·감사 보고서로 통제를 확인했는가
마치며
CSP의 OS 이미지를 볼 때 “최신인가”만 묻기보다 출처, 빌드, 검증, 버전, 배포 범위, 폐기를 하나의 흐름으로 봐야 한다.
고객이 선택하는 VM 이미지와 Kubernetes 노드 이미지는 게시자와 버전을 직접 검증할 수 있다. 반면 관리형 서비스와 CSP 내부 인프라 이미지는 상세 파일 대신 CSP의 보안 설계, 무결성 통제, 변경관리와 외부 감사 증거로 확인해야 한다.
결국 안전한 OS 이미지는 특정 제품 이름이 아니라, 신뢰할 수 있는 원본에서 시작해 검증된 절차로 만들어지고 승인된 범위에만 배포되는 이미지다.
