클라우드 보안이란 무엇인가? 2026년을 위한 중요성과 조언

이 블로그 글의 AI 요약으로 바로 가기

주요 내용

클라우드 보안이란 클라우드 환경 내의 데이터, 애플리케이션 및 인프라를 보호하기 위한 통제 수단, 정책 및 도구를 말합니다.
공동 책임 방식은 보안 업무를 귀사와 서비스 제공업체 간에 분담하며, 이러한 분담 비율은 서비스 모델에 따라 달라집니다.
IaaS에서는 게스트 운영 체제와 해당 운영 체제의 패치 관리가 제공업체가 아닌 귀하에게 귀속됩니다.

클라우드 제공업체들은 데이터센터, 하드웨어, 그리고 워크로드가 구동되는 가상화 계층을 운영합니다. 그 이상의 부분은 서비스 모델에 따라 달라집니다. IaaS의 경우 게스트 운영 체제, 사용자 계정, 저장된 데이터는 모두 고객 측에 속하며, 관리형 플랫폼이나 SaaS로 전환할수록 이 경계선은 점차 이동하게 됩니다.

바로 그 변화하는 경계에서 보안 취약점이 발생하기 쉽습니다. 서비스 제공업체가 패치 이나 구성 작업을 처리해 줄 것이라고 생각하기 쉽지만, 사실 그건 여러분이 직접 해야 할 일입니다.

클라우드 보안이란 무엇인가요?

클라우드 보안이란 클라우드 환경에서 실행되는 데이터, 애플리케이션 및 인프라를 보호하기 위한 통제 수단, 정책 및 도구의 조합을 말합니다. 클라우드 환경. 이는 신원, 네트워크, 워크로드 및 데이터 계층에 걸쳐 적용되며, 가상 머신, 관리형 플랫폼 또는 공급업체가 제공하는 소프트웨어를 실행하는 경우 모두에 적용됩니다.

클라우드에서 직접 제공되는 보안 도구를 지칭할 때 “클라우드 기반 보안”이라는 표현을 종종 볼 수 있습니다. 여기서 이 용어는 클라우드에서 실행되는 모든 것을 보호하는 더 광범위한 역할을 포괄하며, 심지어 이러한 워크로드를 다수 처리하는 까지 포함하는 더 광범위한 역할을 포괄합니다.

이는 설정 하나만 잘못되거나, 권한이 과도하게 부여된 계정이 있거나, 패치가 적용되지 않은 서버가 있을 경우 데이터가 유출되거나 서비스가 중단될 수 있기 때문입니다. 아래 표에서 볼 수 있듯이, 이러한 위험 중 일부는 어떤 서비스 모델을 선택하든 상관없이 항상 존재합니다.

클라우드 보안에서 ‘공동 책임 모델’이란 무엇인가?

공동 책임 모델은 어떤 보안 업무가 클라우드 제공업체의 책임이고, 어떤 업무가 사용자의 책임인지 명확히 규정합니다. 흔히 제공업체가 호스팅하는 모든 것을 보안한다고 오해하는 경우가 있습니다. 실제로는 서비스 모델에 따라 책임의 경계가 달라지며, 서비스마다 다시 달라질 수도 있습니다.

AWS, 마이크로소프트, 구글은 각각 이를 약간 다른 방식으로 정의합니다. 마이크로소프트는 서비스 모델별로 매트릭스를 공개합니다. AWS는 클라우드 ‘자체’의 보안, 즉 공급자의 인프라를, 클라우드 ‘내부’의 보안, 즉 사용자가 클라우드에 배치한 모든 것과 구분합니다. 구글은 ‘공유된 운명(shared fate)’이라 부르는 개념을 통해 한 걸음 더 나아가, 제공업체가 고객이 안전한 환경을 구축할 수 있도록 더 적극적인 역할을 수행합니다. 마이크로소프트는 자사의 매트릭스를 계약 조건을 변경하지 않는 참고용 지침으로 설명하고 있으므로, 이러한 모델들은 모두 참고용으로만 활용하고, 실제 운영 중인 특정 서비스에 대해서는 계약서와 관련 문서를 확인하시기 바랍니다.

IaaS, PaaS, SaaS 간에 책임이 어떻게 전환되는가

클라우드 서비스는 인프라 서비스(IaaS), 플랫폼 서비스(PaaS), 소프트웨어 서비스(SaaS)라는 세 가지 서비스 모델로 나뉩니다. 서비스 제공업체가 관리하는 스택의 범위가 넓을수록 사용자가 직접 처리해야 할 부분은 줄어들지만, 세 가지 모델 모두에서 사용자가 담당해야 할 몇 가지 책임은 여전히 남아 있습니다. 아래에 정리된 마이크로소프트의 현재 매트릭스는 업무 분담 방식을 보여줍니다.

담당 분야	IaaS	PaaS	SaaS
고객 데이터	당신	당신	당신
구성 및 설정	당신	당신	당신
신원 및 사용자	당신	당신	당신
클라이언트 기기	당신	당신	공유됨
응용 분야	당신	공유됨	공유됨
네트워크 제어	당신	공유됨	제공자
운영 체제	당신	제공자	제공자
물리적 호스트, 네트워크 및 데이터센터	제공자	제공자	제공자

출처: Microsoft Learn, “클라우드에서의 공동 책임.” 수정 사항: “고객”과 “Microsoft”는 “귀하”와 “제공업체”로 표기되었으며, 온프레미스 열은 생략되었고, 물리적 호스트, 네트워크 및 데이터센터 행은 하나로 통합되었습니다.

마이크로소프트는 또한 서비스 모델에 관계없이 사용자가 계속 책임져야 할 네 가지 사항, 즉 데이터, 엔드포인트, 계정 및 액세스 관리를 제시하고 있습니다. SaaS의 경우 마이크로소프트가 클라이언트 장치 관리를 지원할 수 있기 때문에 해당 장치들이 “공유”로 표시되지만, 이러한 엔드포인트를 보호하는 것은 여전히 사용자의 몫입니다.

서비스형 인프라(IaaS)

IaaS를 이용하면 Amazon EC2, Azure Virtual Machines, Google Compute Engine과 같은 컴퓨팅, 스토리지, 네트워킹 리소스를 임대하게 됩니다. 서비스 제공업체는 물리적 인프라와 가상화 계층을 관리합니다. 사용자는 게스트 운영 체제(게스트 OS), 설치된 소프트웨어, 네트워크 구성을 직접 관리합니다.

AWS는 이를 명확히 밝히고 있습니다. EC2 인스턴스를 배포하는 고객은 “게스트 운영 체제 관리(업데이트 및 보안 패치 포함)”는 물론, 직접 설치한 모든 소프트웨어와 각 인스턴스의 보안 그룹 구성에 대한 책임이 있습니다. 또한 AWS는 패치 관리를 공동 통제 사항으로 명시하고 있습니다. 즉, AWS는 인프라에 대한 패치를 적용하고, 고객은 게스트 OS와 애플리케이션에 대한 패치를 적용합니다. 마이크로소프트의 매트릭스도 IaaS의 경우 이와 같은 입장을 취하며, 운영 체제 관리 책임을 고객에게 부여하고 있습니다.

서비스형 플랫폼(PaaS)

마이크로소프트가 PaaS로 분류하는 Azure App Service, Azure Functions, Azure SQL Database와 같은 관리형 플랫폼은 작업의 상당 부분을 서비스 제공업체 측으로 이전합니다. 서비스 제공업체는 운영 체제, 런타임, 미들웨어를 담당합니다. 애플리케이션과 네트워크 제어 기능은 공유됩니다. 사용자는 애플리케이션 구성, 코드 보안, 액세스 제어, 그리고 배포에 포함하는 라이브러리를 직접 관리합니다.

런타임 버전도 미리 공지된 일정에 따라 지원이 종료되며, 그럴 경우 마이그레이션 작업은 다시 여러분에게 돌아오게 됩니다.

서비스형 소프트웨어(SaaS)

Microsoft 365이나 Dynamics 365와 같은 SaaS는 스택의 거의 모든 부분을 공급자가 담당합니다. 구글은 이를 다음과 같이 설명합니다. SaaS에서는 공급자가 보안 책임의 대부분을 지며, 사용자는 자신의 액세스 제어와 저장하기로 선택한 데이터에 대한 책임을 계속 지게 됩니다. 마이크로소프트는 이 경우 클라이언트 장치를 공유 영역으로 간주합니다. 마이크로소프트는 일부 장치 관리 기능을 제공할 수 있지만, 엔드포인트 보호 및 규정 준수에 대한 책임은 여전히 사용자에게 있습니다.

클라우드 제공업체의 책임 범위

프로바이더는 하드웨어에 가장 가까운 계층을 처리합니다. 마이크로소프트의 문서는 해당 부분을 몇 가지 영역으로 나누고 있으며, AWS도 비슷한 구분을 하고 있습니다.

물리적 인프라

데이터센터 보안은 서비스 제공업체의 책임입니다. 여기에는 시설, 물리적 접근 통제, 환경 관리뿐만 아니라 사용자의 워크로드를 호스팅하는 물리적 서버도 포함됩니다.

네트워크 기초

데이터센터 내부의 라우터, 스위치 및 케이블링은 서비스 제공업체가 관리합니다. PaaS에서 Microsoft는 네트워크 보안를 제공하며, SaaS에서는 네트워크 보안을 직접 관리합니다. 방화벽 규칙 및 세분화 설정은 IaaS 환경에서 사용자가 직접 관리합니다.

가상화 및 호스트 계층

The 하이퍼바이저 와 호스트 운영 체제도 제공업체의 관리 범위에 속합니다. AWS는 자사가 담당하는 영역을 호스트 운영 체제와 가상화 계층에서 시설의 물리적 보안에 이르기까지로 설명하며, 이로 인해 게스트 OS는 해당 관리 범위를 벗어나게 됩니다.

규정 준수 관련 문서

AWS, 마이크로소프트, 구글 클라우드는 각각 규정 준수 문서를 공개하고 있습니다. AWS는 고객이 자체적인 통제 평가 및 검증을 위해 자사의 통제 및 규정 준수 문서를 활용할 수 있다고 밝히고 있습니다. 또한 고객이 어떤 통제 조치를 이미 적용받고 있는지, 어떤 조치를 아직 구현해야 하는지 파악할 수 있도록 제3자 감사 확인 문서를 안내하고 있습니다. 마이크로소프트는 자사의 서비스 트러스트 포털를 통해 감사 보고서를 공개하며, 구글 클라우드는 Compliance Reports Manager를 통해 감사 보고서와 인증서를 제공합니다. 일부 마이크로소프트 및 구글 리소스는 로그인이 필요하며, 특정 자료는 기밀 유지 조건 하에 공유됩니다.

어떤 조직이 책임을 지는가

IaaS에서는 스택의 대부분을 사용자가 직접 관리해야 합니다. 이는 오래된 이미지에서 실행된 인스턴스를 포함해 모든 인스턴스의 게스트 OS와 커널에 패치를 적용하는 것부터 시작하여, 사용자가 직접 선택한 적이 없는 것까지 포함하여 실행 중인 애플리케이션과 해당 애플리케이션이 불러오는 라이브러리까지 그 범위가 미칩니다.

또한 네트워크도 직접 구성해야 합니다. IaaS의 경우, 이는 보안 그룹, 방화벽 규칙, 세그멘테이션을 의미합니다. PaaS의 경우, 애플리케이션 수준의 네트워크 제어 기능을 의미합니다. 로깅 및 모니터링도 직접 설정해야 합니다. 예를 들어, Google Cloud에서는 BigQuery의 일부 서비스를 제외한 모든 서비스에서 데이터 액세스 감사 로그가 기본적으로 비활성화되어 있으므로, 대부분의 서비스에서는 직접 활성화하기 전까지는 해당 로그를 확인할 수 없습니다.

백업 및 복구 방식은 서비스마다 다릅니다. Amazon EC2의 경우, AWS Backup이나 Amazon Data Lifecycle Manager와 같은 도구를 통해 볼륨에 대한 스냅샷이나 백업 정책을 직접 설정해야 합니다. Amazon RDS는 기본적으로 자동 백업이 활성화되어 있지만, 백업 데이터를 얼마나 오래 보관할지는 사용자가 결정합니다.

안전한 개발 및 배포 관행에 대해서는 당사의 소프트웨어 보안 모범 사례를 참조하십시오.

클라우드 보안 조치의 유형

클라우드 보안 프레임워크 일반적으로 아래의 다섯 가지 영역을 다룹니다.

신원 및 접근 관리

역할, 정책, 서비스 계정 및 연동 방식에 따라 해킹당한 인증 정보로 접근할 수 있는 범위가 결정되는 경우가 많습니다. 최소 권한 원칙, 다단계 인증 , 그리고 정적 키의 정기적인 교체(또는 완전한 삭제)는 모두 접근 범위를 좁혀줍니다. 일회성 작업을 위해 생성된 서비스 계정은 주기적으로 검토해야 하며, 더 이상 필요하지 않은 계정은 삭제해야 합니다.

데이터 보호 및 암호화

먼저 데이터의 기밀성 수준에 따라 분류한 다음, 키를 누가 관리할지 결정하십시오. 서비스 제공자가 관리하는 키는 운영이 더 간편한 반면, 고객이 관리하는 키는 키 교체 및 해지에 대해 더 많은 제어권을 제공합니다. 어떤 방식을 선택하든, 어떤 데이터 세트에 어떤 방식을 적용하는지 기록해 두십시오.

네트워크 제어 및 세그멘테이션

보안 그룹, 네트워크 ACL, 사설 엔드포인트 및 서비스 경계는 어떤 시스템들이 서로 통신할 수 있는지를 제어합니다. 세그멘테이션은 한 번 침해된 워크로드가 영향을 미칠 수 있는 범위를 제한하며, 아웃바운드 트래픽 필터링은 해당 워크로드가 외부로 접속할 수 있는 대상을 제한합니다.

작업 부하 및 게스트 OS 패치 적용

IaaS 환경에서 패치 적용은 수행해야 할 주요 반복 작업 중 하나입니다. 클라우드 및 호스팅 서버에서는 리눅스가 널리 사용되며, 커널 업데이트 시에는 전통적으로 인스턴스를 재부팅해야 했습니다. 대규모 서버 군의 경우, 각 재부팅을 위한 유지보수 시간을 확보하는 데 어려움을 겪을 수 있어 패치 적용이 지연될 수 있습니다.

서비스 제공업체들은 이에 대한 도구를 제공하고 있습니다. AWS Systems Manager Patch Manager, Azure의 자동 VM 게스트 패치 적용 기능, Google Cloud VM Manager Patch는 모두 인스턴스의 게스트 OS 패치 적용을 자동화할 수 있습니다. 각 도구는 프로세스의 일환으로 인스턴스를 재부팅할 수 있으며, 적용 범위도 각각 다릅니다. 예를 들어, Azure의 자동 패치 적용 기능은 ‘Critical’ 또는 ‘Security’ 등급으로 분류된 패치만 다룹니다. 어느 쪽이든, IaaS 환경에서는 게스트 OS 자체는 여전히 고객 측에 속합니다.

라이브 패치 은 다른 방식을 취하여 실행 중인 시스템에 커널 보안 수정 사항을 적용합니다. 일부 배포판 및 공급업체는 특정 플랫폼을 위해 자체 라이브 패치 기능을 제공하므로, 여러 배포판이 혼합된 시스템 환경에서는 여러 도구를 번갈아 사용해야 할 수 있습니다. KernelCare 는 70개 이상의 리눅스 배포판 버전에 대한 라이브 리눅스 커널 패치 기능을 제공하므로, 재부팅을 예약할 필요 없이 실행 중인 클라우드 및 호스팅 서버의 커널 취약점을 해결할 수 있습니다.

로깅 및 모니터링

AWS CloudTrail, Azure Monitor, Google Cloud Audit Logs와 같은 서비스는 환경 내의 활동을 기록합니다. 로그를 별도의 계정이나 프로젝트로 전송하면, 특히 전송 대상에 대한 접근이 엄격하게 제한되어 있는 경우, 한 환경이 침해당하더라도 해당 환경의 감사 추적을 지우기 어렵게 됩니다. 정기적인 보안 감사 를 실시하면 로그가 필요한 내용을 모두 포함하고 있는지 확인하는 데 도움이 됩니다.

일반적인 클라우드 위협이 귀하의 책임과 어떻게 연관되는지

클라우드 위협은 대개 ‘공동 책임’ 원칙을 따르는 경향이 있어, 어떤 위협에 대해 조치를 취할 수 있는지 파악하기가 더 쉽습니다. 마이크로소프트의 매트릭스에 따르면에 따르면, 잘못된 설정과 유출된 신원 정보는 세 가지 서비스 모델 모두에서 사용자의 책임에 속합니다. 운영 체제 취약점은 IaaS에서는 사용자의 책임이지만, PaaS와 SaaS에서는 제공업체의 책임으로 넘어갑니다. 자체적으로 컨테이너 이미지와 종속성을 빌드하여 배포하는 경우, 이를 실행하는 플랫폼에 관계없이 해당 이미지와 종속성은 사용자의 책임으로 남습니다. 클라우드 보안 위협 에서는 각 범주를 심도 있게 다루고 있습니다.

IaaS 환경에서는 패치가 적용되지 않았거나 지원 종료된 시스템도 동일한 규칙을 따르며, 이 경우 운영 체제 유지 관리는 고객이 직접 담당합니다. 클라우드 인스턴스는 오래전에 구축된 이미지를 기반으로 수년 동안 계속 실행될 수 있습니다. 해당 인스턴스의 리눅스 배포판, 런타임 또는 프레임워크의 지원이 종료되면 공급업체는 보안 업데이트 제공을 중단하지만, 마이그레이션 계획이 수립되는 동안에도 워크로드는 종종 트래픽 처리를 계속합니다. TuxCare의 Endless Lifecycle Support(ELS) 는 공급업체의 표준 지원이 종료된 후에도 지원 종료된 리눅스 배포판, 런타임, 프레임워크 및 애플리케이션에 대한 보안 패치를 제공하므로, 고객은 자체 일정에 맞춰 마이그레이션을 진행할 수 있는 여유를 갖게 됩니다.

공동 책임과 관련된 일반적인 과제

서비스마다 대열이 이동합니다

관리형 쿠버네티스 서비스에서는 제공업체가 컨트롤 플레인을 운영하며, 워커 노드에 어떤 처리가 이루어지는지는 사용자가 선택한 옵션에 따라 달라집니다. Amazon EKS의 경우, 자체 관리 노드에서 관리형 노드 그룹, 그리고 Fargate로 이동할수록 AWS가 담당하는 범위가 넓어집니다. 관리형 노드 그룹을 사용하는 경우에도 새로운 AMI 릴리스로 업데이트를 시작해야 하며, 이후 EKS가 해당 업데이트를 노드 전체에 적용합니다. 한 서비스를 기준으로 한 모델이 다른 서비스에 대해 오해를 불러일으킬 수 있으므로, 각 서비스의 책임 범위에 대한 문서를 확인하시기 바랍니다.

패치 작업이 팀 간에 소홀히 다뤄질 수 있다

플랫폼 엔지니어링 팀이 계정 구조를 관리하고, 애플리케이션 팀이 배포를 담당하며, 보안 팀이 정책을 관리한다면, 게스트 OS 패치 작업은 이 세 영역의 경계에 위치할 수 있습니다. 책임 주체를 한 곳만 지정해 보세요. 다음 검토 회의에서 물어볼 만한 유용한 질문은, 가장 오래된 운영 환경 인스턴스의 커널 패치를 누가, 언제 적용했는지입니다.

간과되기 쉬운 사례들은 놓치기 쉽다

자산 목록에 포함되지 않은 인스턴스는 패치 보고서에도 표시되지 않습니다. 해당 목록을 클라우드 리소스 목록 및 청구 내역과 비교하면, 어느 팀도 소유권을 주장하지 않는 시스템을 찾아낼 수 있습니다.

2026년을 위한 클라우드 보안 조언

새로운 서비스를 배포하기 전에, 배포한 뒤가 아니라 미리 해당 서비스의 책임 관련 문서를 읽어보십시오. 게스트 OS 및 커널 패치 담당자를 지정하십시오. 최소 권한 원칙, 다단계 인증, 정적 인증 정보의 정기적인 교체를 통해 신원 보안을 강화하고, 각 데이터 세트의 암호화 키를 누가 보유할지 결정한 후 이를 문서화하십시오.

운영 측면에서는 로그를 별도의 계정이나 프로젝트로 전송하고, 알림이 담당자에게 제대로 전달되는지 테스트하십시오. 런타임 및 기본 이미지를 포함하여, 공급업체의 지원 기간이 끝난 후에도 계속 사용할 수 있는 시스템을 계획하십시오. 그리고 사고 대응 워크플로우를 를 미리 작성해 두십시오. 인시던트가 발생한 도중에 시작하는 것은 좋지 않기 때문입니다.

TuxCare로 안전한 환경을 운영하세요

IaaS에서는 공급자가 인프라를 관리하며, 각 인스턴스의 게스트 OS는 귀사 팀이 직접 관리합니다. 또한, 귀사의 소프트웨어에 포함된 오픈 소스 종속성 역시 어디서 실행되든 귀사의 소유입니다. 무제한 라이프사이클 지원 지원 기간이 만료된 리눅스 배포판, 런타임, 프레임워크 및 애플리케이션에 대한 보안 패치를 제공하므로, 공급업체의 마감 기한에 얽매이지 않고 귀사의 일정에 맞춰 마이그레이션을 진행할 수 있습니다. SecureChain 는 JavaScript, Python, Java, Go, Rust 및 PHP용 빌드에 대해 검증되고, 악성코드 검사를 거쳤으며, 지속적으로 패치가 적용된 오픈 소스 패키지를 제공합니다. 또한 KernelCare 는 재부팅 없이 실행 중인 리눅스 서버에 커널 보안 패치를 적용하므로, 유지보수 시간을 기다릴 필요 없이 커널 문제를 즉시 해결할 수 있습니다.

패치 관리가 더 광범위한 클라우드 운영 프로세스 내에서 어떤 역할을 하는지 알아보려면, 당사의 클라우드 패치 관리가이드를 확인해 보세요.

요약