클라우드·API·공급망 보안

클라우드로 옮겨도 문서의 주인은 서비스가 확인해야 한다

문서 서비스를 관리형 저장소로 옮겼다. 서버실과 저장장치 운영은 공급자가 담당하지만, 고객 A가 고객 B의 문서를 읽는 API는 여전히 잘못 만들어질 수 있다. 배포 파일에 서명이 있어도 그 파일이 승인된 소스에서 만들어졌는지, 위험한 구성요소를 포함하는지도 별개의 질문이다.

이 절은 앞 장의 문서 서비스를 클라우드에서 운영한다고 가정한다. 책임 경계, 요청별 권한과 비용, 빌드·배포의 신뢰를 연결한다. 계산·정책·시험은 자체 교육 자료이며 실제 공급자 계약이나 인증을 대신하지 않는다.

연결 인증과 객체 권한은 다른 판단이다

식별·인증·인가에서 신원 확인과 특정 객체·행위의 허용을 구분했다. 클라우드의 저장소가 비공개이고 API 호출자가 로그인했더라도 각 문서의 읽기 권한은 따로 확인해야 한다. 이번에는 그 판단에 서비스별 책임과 배포 출처를 함께 연결한다.

1. 요청부터 배포까지 신뢰의 연결을 확인한다

클라우드 보안 통합은 사용하는 서비스의 책임 경계, API의 객체·자원 통제, 소프트웨어 산출물의 출처·배포 검증을 하나의 운영 경로로 연결하는 설계다.

누가 기반 시설을 운영하는지만 보지 않고 누가 설정·데이터·계정·애플리케이션을 바꿀 수 있는지도 정한다. 문서 저장소, API 실행 환경, 빌드 시스템과 배포 계정은 서로 다른 신뢰경계다. 한곳의 서명이나 인증을 다른 경계의 허용으로 대신하지 않는다.

클라우드 책임은 사용하는 서비스에 따라 달라진다

공동책임 모델은 클라우드 공급자와 이용자가 서비스의 계층·기능에 따라 보안 운영 책임을 나누는 모델이다. AWS의 공식 설명에서는 EC2 같은 서비스의 고객이 게스트 운영체제·애플리케이션·보안그룹을 관리하는 반면, S3 같은 추상화된 서비스는 공급자가 기반 시설과 운영체제·플랫폼을 운영하고 고객은 데이터와 접근·암호화 설정 등을 책임진다.[SS-C07]

표의 AWS 예를 모든 공급자·관리형 서비스에 같은 책임표로 적용하지 않는다. 사용 서비스·구성·계약·변경 시점에 맞춰 구분한다. 관리형으로 옮겼으니 모든 패치와 권한 업무가 없어졌다고 보고하거나, 공급자의 인증서가 고객 애플리케이션의 올바른 인가를 증명한다고 쓰지 않는다.

2. 식별자를 알면 읽을 수 있는 API를 만들지 않는다

객체 수준 인가 실패(BOLA)는 요청한 객체와 행위에 대한 권한 검사가 빠지거나 잘못되어 허가되지 않은 객체에 접근할 수 있는 결함이다. OWASP API1:2023은 객체 식별자를 받아 처리하는 기능에서 그 객체에 대한 주체의 행동 권한을 검사하도록 강조한다. 무작위 식별자를 사용하거나 요청의 사용자 ID 하나만 현재 사용자와 비교하는 것은 일반적인 객체 권한 검사를 대신하지 않는다.[SS-C08]

자체 정책 SS-A1에서 U1은 ORG-A 고객이며, D1은 ORG-A 소유 문서, D2는 ORG-B 소유 문서다. 서버가 신뢰한 계정·문서 원장과 문서별 읽기 권한을 확인하며, 예제의 다른 조건은 모두 유효하다고 가정한다. 일괄 요청은 하나라도 불허이면 어떤 문서도 제공하지 않는 정책으로 정한다.

서버는 허용된 목록과 버전을 고정한 뒤 저장소에서 가져온 결과가 그 목록인지 확인한다. 검색·미리보기·파일 다운로드·일괄 처리에도 동일한 보호 의도를 집행한다. 일부 성공을 허용하는 다른 정책도 가능하지만, 그때에는 성공 범위와 오류·재시도·정보 노출 방식을 명시해야 하며 이 예제의 전체 거부와 섞지 않는다.

3. 요청 수와 실제 작업량을 함께 제한한다

OWASP API4:2023은 실행시간·메모리·요청 크기·일괄 작업 수와 유료 연동 비용 등 실제 자원 소비의 경계를 강조한다. HTTP 요청 수만 제한하면 한 요청 안에서 수많은 변환 작업을 발생시키는 경우를 놓칠 수 있다.[SS-C09]

자체 모형 SS-R1은 한 고객에게 분당 최대 120요청, 요청당 최대 5개 변환 작업을 허용한다. 두 조건을 모두 집행하면 이 두 제한만으로 계산한 이론적 상한은 분당 600작업이다. 요청당 제한을 100개로 바꾸면 같은 120요청이어도 분당 12,000작업이 된다. 인증 성공은 이 한도를 면제하지 않는다.

이 수치는 실제 처리 성능이 아니다. 파일 바이트·압축 해제 후 크기·실행시간·동시 작업·기간별 비용에 별도 한도가 필요하다. 고객별 한도 외에 전체 자원이 소진되는 경우도 고려하고, 재시도와 실패 작업의 비용을 어떻게 셀지 계약에 적는다. 파일 수만으로 모두 같은 비용이라고 가정한 모형을 실제 과금으로 바꾸지 않는다.

직접 계산: 동시 요청의 남은 한도

자체 원장 SS-R2의 남은 작업 예산은 100단위다. 작업자 둘이 각각 80단위 요청을 처리한다. 둘 다 먼저 100이 남았다는 값을 읽고 나중에 차감하면 총 160단위를 허용하여 60단위를 초과할 수 있다. 단순 조회 후 차감은 동시에 수행될 때 한도 검사가 아니다.

이 사례는 중앙 원장에서 비교와 예약을 한 번의 나뉘지 않는 연산으로 처리한다. 첫 80단위를 예약하면 잔여는 20이고 둘째 80단위는 거부한다. 승인된 합계는 80이며 잔여 20을 유지한다. 같은 요청 ID로 응답 손실 뒤 다시 요청하면 원장의 이전 예약 결과를 돌려주고 다시 차감하지 않는다.

예약 실패이면 실제 작업을 실행하지 않으며, 실행 시작 여부가 불확실한 시간초과 예약을 무조건 환불하지 않는다. 완료·취소·복구 시의 정산 규칙을 정하고 원장·실행 결과를 대조한다. 이 작은 모형은 분산 저장소 장애와 모든 과금 상황의 구현을 완성한 것이 아니라 검사와 실행의 연결을 보여 주는 사례다.

같은 원장을 읽은 두 요청을 한 번에 허용하지 않는 이유

80단위 요청 두 개가 같은 100단위 잔여를 읽었을 때, 각 요청이 따로 수행한 비교에서는 조건을 만족한다. 그러나 비교한 뒤 차감하기 전 다른 요청이 승인되면 두 번째 비교의 전제가 이미 바뀐다. 그래서 이 정책은 “읽기”를 빠르게 하는 것으로 해결하지 않고, 확인과 예약이 하나의 상태 변경으로 이루어지도록 정한다. 첫 예약 뒤의 20단위가 두 번째 판단의 입력이어야 합계 100단위 경계를 유지할 수 있다. 응답이 사라졌다는 것은 예약이 사라졌다는 뜻도 아니므로 요청 ID의 이전 결과를 먼저 확인한다.

4. 구성목록·서명·출처 증거는 서로 다른 질문에 답한다

앞의 구성명세와 생성 이력에서 SBOM은 구성품과 관계를, 프로비넌스는 산출물이 만들어진 이력을 설명한다고 배웠다. 여기서는 그 차이를 문서 서비스의 배포 허용에 적용한다.

구성목록이 있어도 취약점이 없거나 실제 배포 구성과 일치한다고 증명하지는 못한다. NIST SSDF의 구성요소·산출물·출처 관리 범위를 함께 읽는다.[SS-C10] SLSA의 검증 지침에 따라 증거의 진위·산출물 일치뿐 아니라 신뢰할 빌더와 소스·빌드 유형·매개변수 등 기대 조건을 대조한다.[SS-C11]

서명이 수학적으로 맞는지, 서명한 주체를 해당 빌드에 신뢰하는지, 실제 배포 파일의 해시와 맞는지, 승인한 소스·매개변수에서 생성됐는지는 각각 확인한다. 허용 목록에 있는 빌더가 악성 소스를 승인받아 빌드한 상황까지 출처 증거만으로 해결하지는 못한다. 소스 검토·취약점 평가·권한 제한·업무 시험이 별도로 필요하다.

직접 판정: 서명 있음과 배포 허용은 다르다

자체 정책 SS-B1은 승인 저장소 R, 커밋 C, 빌더 B, 빌드 유형 T와 허용된 매개변수만 수락한다. 실제 암호 검증은 검토된 구현이 수행했다고 가정하며, 아래 표는 그 결과와 정책 입력을 읽는 모형이다. 식별자 R·C·B·T는 교육용 기호다.

모르는 외부 매개변수를 무시하여 승인된 빌드와 같다고 취급하지 않는다. 검증을 통과한 파일을 이름이 같은 다른 파일로 교체하지 못하게 산출물 해시를 배포 대상에 고정한다. V1도 취약점이 없다는 판정이 아니므로 이후 시험과 출시 승인까지 진행해야 한다. SLSA의 특정 등급 인증을 이 표의 통과로 선언하지 않는다.

5. 실제 운영안 SS-C1

빌드 계정에게 운영 문서 저장소의 읽기 권한을 주지 않고, 배포 계정이 임의 소스로 승인 절차를 우회하지 못하게 한다. 비밀값은 소스·빌드 로그·구성목록에 넣지 않는다. 외부 의존성을 받아올 때에도 승인 버전과 식별자를 고정하고 변경을 검토한다. 소스·빌드·배포가 같은 무제한 관리자 계정을 공유하면 하나의 침해로 검증과 집행이 함께 무너질 수 있다.

역할·실패·복귀를 정한다

서비스 책임자는 사용하는 클라우드 계층과 고객 책임을 확정한다. 개발 담당은 SS-A1의 객체별 인가와 모든 다운로드 경로, 운영 담당은 비공개 저장소·권한·키·로그를 확인한다. 자원 담당은 SS-R1의 요청·작업·비용 제한과 SS-R2의 예약·정산을 운영한다. 빌드 담당은 승인된 소스와 출처 증거를 생성하고 배포 담당은 별도 검증 뒤 고정 해시만 배포한다.

시험은 다른 조직 문서, 일괄 요청의 부분 불허, 원장 조회 실패, 요청당 작업 증가, 동시 예약과 응답 손실, 서명은 유효하지만 소스·빌더·해시가 다른 산출물을 포함한다. 인가·한도·배포 검증에 실패했는데도 실제 제공·작업·배포가 진행되면 출시를 보류한다. 시험 결과를 소스 커밋·산출물 해시·정책 버전과 연결하여 관제로 보낸다.

새 취약점이 알려지면 구성목록에서 의존성과 배포 위치를 찾고 실제 포함 버전·사용 조건·노출 경로를 대조하여 우선순위를 정한다. 안전한 수정·재빌드·검증을 거쳐 교체한다. 배포 장애 때 이전 버전으로 돌아가는 선택도 알려진 취약점과 데이터·설정 호환성, 원래 수정 목적을 재검토한다. 단순히 오래된 버전이 잘 켜진다는 이유로 위험한 버전을 무조건 복구하지 않는다.

연결 중 하나가 빠지면 생기는 실패

관리형 서비스의 책임을 오해하면 고객의 공개 설정과 객체 인가가 비어 있다. 요청 수만 제한하면 한 요청의 대량 작업으로 비용이 늘어나고, 중앙 예산을 조회한 뒤 나중에 차감하면 동시 요청이 한도를 넘는다. 서명만 확인하면 잘못된 소스나 미승인 빌더의 파일도 배포될 수 있다.

각 실패를 같은 “클라우드 보안 미흡”으로 쓰지 말고 책임 주체·입력·판정·집행 위치로 구별한다. 증거가 없거나 검사할 수 없는 상태는 성공이 아니라 보류다. 기존 정상 동작과 한도 실패 때의 고객 안내를 함께 시험한다.

보안시스템을 보조하는 범위

클라우드 책임과 객체별 인가·자원 제한·빌드 출처를 문서 서비스의 실제 집행에 연결한다. 대상은 서비스 계약 범위·문서 목록·예산 원장·배포 산출물이다. 공급자 보호와 고객 책임, 요청 수와 작업량, 증거 서명과 배포 승인의 경계를 나눈다. 객체 불허·동시 한도 초과·증거 불일치에서 집행을 막으며 모든 공급자의 적합성·완전한 분산 과금·SLSA 등급 인증은 제외한다.

6. 자체 10점 문제

SS-A1의 일괄 문서 요청 판정과 SS-R1의 작업량 상한을 설명하고, SS-R2에서 동시 요청이 한도를 넘지 않도록 예약 결과를 계산하라.

객체별 권한, 요청당 작업 수와 전체 예산은 각각 다른 조건이다. 로그인 성공으로 다른 조건을 지우지 않는다.

독립 계산: 일괄 요청의 불허 객체를 표시한 뒤 120×5의 단위와 두 80단위 예약의 순서를 적는다. 로그인 성공을 생략 근거로 쓰지 않는다.

D1 허용 + D2 불허 → 이 정책은 일괄 미제공
120요청/분 × 5작업/요청 = 600작업/분
예산 100 → 예약 80 → 잔여 20 → 다음 80 거부

7. 자체 25점 문제

클라우드 문서 서비스의 책임·API·공급망 보안을 SS-C1로 설계하라. 객체 권한과 자원 제한, 빌드 증거와 배포 허용, 역할·시험·복귀 조건을 실제 결정으로 제시하라.

공급자의 보호 범위와 고객의 구현 책임을 먼저 정한다. 단순히 인증서·SBOM·서명이 있다는 목록으로 완료하지 않는다.

실제 결정으로 쓰기: 공급자·고객 책임, 객체 검사, 예산 예약, 빌드 증거, 실제 배포 해시를 다른 산출물로 제시하고 실패 때 집행이 어떻게 멈추는지 적는다. 자체 연습이다.

8. 자기교정

조건 변경

요청당 8작업으로 바꾸면? 120×8=960작업/분이라는 두 제한의 상한이 된다. 실제 처리율·비용 한도를 다시 검토한다. SS-R1의 단위를 유지한다.

첫 예약이 60단위이고 다음은 40단위라면? 원자적 예약에서 두 요청 모두 허용되고 잔여는 0이다. 같은 요청의 재시도는 추가 차감하지 않으며 다른 새 요청은 거부한다. SS-R2를 적용한다.

V1의 파일을 이름은 같지만 다른 바이트로 교체하면? 산출물 해시가 달라졌으므로 기존 검증 결과를 재사용하지 않고 거부한다. SS-B1의 판정 대상은 이름이 아니라 실제 산출물이다.

근거와 적용 한계

SS-C07은 AWS Shared Responsibility Model의 EC2·S3 예와 고객 데이터·접근 책임에 한정한다. SS-C08·09는 OWASP API Security Top 10 2023의 API1 Broken Object Level Authorization, API4 Unrestricted Resource Consumption을 독립적으로 설명한다. 이는 한국의 법적 의무나 모든 서비스의 책임 계약이 아니다.

SS-C10은 기존 보존 출처 SRC-DVO-SSDF11인 NIST SP 800-218 SSDF 1.1의 PS.2·PS.3·PW.4·RV.1을 참조하며 기존 관찰일을 바꾸지 않는다. SS-C11은 SLSA v1.2 Build track의 Verifying artifacts와 Provenance를 근거로 한다. 새 웹 문서 관찰일은 2026-09-19이며 최초 발행일·법적 효력일로 사용하지 않는다. 상세 버전·locator는 명시 출처 장부에 연결한다.

SS-A1·SS-R1·SS-R2·SS-B1·SS-C1과 표·도식·답안은 자체 작성이다. 원문 그림을 복사하거나 실제 자격증명·공격 절차를 제공하지 않았다. 완전한 클라우드 적합성, 빌드 보증 등급, 무취약성, 실제 과금 구현이나 사람에 의한 독립 승인을 주장하지 않는다.

회독의 핵심

클라우드의 기반 보호와 고객의 설정·데이터·업무 권한은 구분한다. 모든 객체를 인가하고 요청 수뿐 아니라 실제 자원과 동시 예약을 통제한다. 구성목록·증거 서명·기대 출처·실제 산출물을 각각 검증하여 배포와 운영으로 연결한다. 다음 장은 이런 통제를 요구와 위협모델·보안검증으로 체계화한다.

판단 경계 회상: U1의 인증, D1·D2의 권한, 요청 수·작업 수, 중앙 예산, 빌드 서명·기대 출처 중 하나가 통과해도 다른 검사가 남는 이유를 같은 문서 서비스로 설명한다. 표로 충분한 비교 축을 억지로 한 도식에 합치지 않고 각 객체, 원장, 배포 대상을 따로 확인한다.