Security

클라우드 생태계의 ‘책임 공유 모델’은 이미 현실이다

JustAnotherEditor

06 Aug 2025 — 12 min read

💡

Editor's Pick
- 클라우드 보안 책임은 업체와 사용자가 상호 부담
- 사실 업체들은 대부분 잘 하고 있음
- 사용자가 낸 설정 오류가 대부분 사고의 원인

말의 힘은 대단하다. 말에 따라 있는 것이 없는 것처럼 여겨지고, 어떤 단어를 쓰느냐에 따라 큰 문제가 작게 혹은 작은 문제가 크게 번지기도 한다. 현상은 거기에 현상 자체로 남아 있는데, 그걸 어떤 언어의 그릇으로 담아내느냐에 따라 그 현상이라는 것은 전혀 다른 무언가로 변한다. 이를 드러내는 사례가 보안 업계에도 있는데, 바로 ‘설정 오류’와 ‘취약점’이다. 이 둘이 마치 동의어처럼 사용될 때가 많은데, 그러면서 문제의 본질이 가려진다.

보안 업체 앱옴니(AppOmni)는 최근 보고서(The State of SaaS Security 2025 Report)를 통해 이 문제를 지적했다. 이 두 용어를 같은 것으로 치부하는 언어 습관 때문에 많은 SaaS 인프라가 위험에 노출된다는 것이다. SaaS 생태계가 아직 성숙하지 않은 상태이고, 사용자와 공급 업체 간 책임을 공유한다는 개념이 아직 자리를 잡지 못한 상황에서 이런 용어 혼용은 특히나 치명적이라고 앱옴니는 지적했다.

구분하자면

앱옴니는 취약점과 설정 오류에 대해 각각 다음과 같이 정의를 내린다. “취약점은 코드베이스 자체에 존재하는 결함입니다. 따라서 공급 업체만 고칠 수 있죠. 설정 오류는 반대로 사용자가 어떤 권한을 어떤 식으로 분배하고, 어떤 기능이나 정책을 어떻게 적용할 것인지 세밀하게 결정하는 것과 관련이 있는 것이므로 사용자가 책임져야 하는 문제입니다. 너무 높은 권한을 너무 많은 사람들에게 주었다든지, 정책적으로 인터넷에 노출되면 안 될 문제를 노출시켰다든지 하는 게 설정 오류입니다.”

그런데 ‘설정 오류’와 ‘취약점’을 동의어처럼 사용하면 어떻게 될까? 문제가 발생했을 때 책임을 엉뚱한 곳에 묻게 된다. 그러면서 SaaS 환경 자체에 대한 신뢰도가 낮아지게 되고, 개선되어야 할 것들이 개선되지 않게 된다. 보안성이 낮아지고, 결국 문제는 더 커진다. “클라우드와 SaaS는 공급 업체와 사용자가 보안 책임을 공유해야만 안전해집니다. 설정 오류와 취약점을 하나로 보면, 이런 책임 공유 모델은 정착할 수 없게 됩니다.”

보안 책임을 공유한다고 했을 때, 업체와 사용자 측이 맡는 부분은 현격히 달라진다고 앱옴니는 강조한다. “공급 업체는 인프라를 항상 보호해야 하고, 서비스가 약속된 시간에 반드시 가동되도록 해야 합니다. 호스팅 인프라와 관련 시스템들을 관리하는 것 역시 공급 업체의 할 일입니다. 사용자는 애플리케이션 설정, 접근 권한, 데이터 공유 방식 등을 결정하고 관리해야 합니다. 신원 관리, 권한 설정, 데이터 공유 정책 등이 포함되죠. 이런 양측의 할 일이 잘 구분될수록 보안 책임은 원활히 공유되며, 그럴수록 SaaS 생태계는 안전해집니다.”

하지만 현실은 어떨까? 아직 사용자 중 다수는 모든 보안 책임을 공급 업체가 지고 있는 것으로 알고 있다. “사용자 기업/기관의 53%가 SaaS 보안에 강력한 자신감을 드러냈는데, 그 이유는 ‘SaaS 업체를 믿고 있기 때문’이었습니다. 즉 공급 업체가 보안에 강력할 거라고 믿고, 모든 것을 전적으로 그 업체에 맡기고 있다는 의미도 됩니다. 파트너사를 신뢰한다는 건 좋은 일이지만, 보안을 다 맡긴다는 건 불길한 징조입니다. 이런 맹목적 신뢰, 특히 자기가 해야 할 일을 하지 않고서 하는 신뢰는 보안 사각지대가 됩니다.”

책임이 공유되지 않을 때 손해보는 건 사용자

흥미로운 건 ‘상대가 잘 할 거야’라고 믿는 건 사용자들 뿐이라는 것이다. 공급 업체 측에서 ‘우리 사용자가 안전하게 사용할 거야’라고 믿는 경우는 거의 없다. 그래서인지 SaaS 환경에서 일어나는 보안 사고 중 절대 다수는 ‘사용자 잘못’에서 비롯되는 것으로 조사됐다. “전체 보안 사고 중 41%가 권한 설정이 잘못 돼 일어났습니다. 그 외 설정 오류로 인해 일어나는 사고가 29%였고요. 합하면 무려 70%입니다. 실제 SaaS에서 사고가 났을 때 인프라 자체가 뚫리는 경우는 거의 없지요.”

사용자가 설정을 잘못하는 바람에 시작되는 공격은, 인프라가 뚫려서 발생하는 경우보다 더 위험할 수 있다. 설정 실수는 기존 보안 탐지 도구들로는 잡아낼 수 없기 때문이다. 설정 오류란 것이 기술적 취약점이 아니기 때문에 도구들로서는 ‘결함’으로서 간주할 수 없다. “따라서 설정 오류라는 것을 자동으로 탐지해 수정하는 도구들에는 한계가 있을 수밖에 없습니다. 그러니 경보도 울리지 않죠. 구성, 권한, 통합 설정을 사용자가 직접 분석해야만 찾아낼 수 있습니다. 수작업이 많이 필요하다는 소리입니다.”

또한 설정 오류로 인한 사고에 대해 공급 업체가 보상해 줄 것도 없다. 사용자가 실수한 것이기 때문이기도 하고, 최근 공급 업체들은 책임 소재에 대해 계약서와 약관에 잘 명시해두는 편이기 때문이기도 하다. 사용자 측에서 계약을 할 때 이런 문제를 다 짚고 넘어가지 않거나 꼼꼼하게 읽지 않는 경우가 많은데, 그런 부주의로 손해를 보는 건 결국 사용자다.

그래서 현재 ‘책임 공유 모델’은 사용자에게만 불리하게 작용하고 있다. 공급 업체들은 법적으로, 기술적으로, 심지어 윤리적으로도 대응할 준비를 갖추고 있다. 사용자가 아무리 ‘우리 공급 업체를 믿어. 그들이 다 해 줄 거야’라고 믿고 있어도, 실제 사고는 얼마든지 일어날 수 있으며, 그 책임은 스스로가 져야 할 가능성이 높은 게 현실이다. ‘책임 공유 모델’을 받아들인다는 건 맹목적 믿음에서 벗어나 현실을 직시하는 것이다.

현실 직시, 어디서부터 해야 하나

공급 업체가 보안의 50%를 책임지고 나머지를 사용자가 직접 맡아야 한다는 현실을 직시한다는 건 무슨 뜻일까? 설정 오류들을 하나하나 찾아내 최소화 한다는 의미다. 앱옴니는 이 과정이 꽤나 힘들고 지난하다고 경고한다. “설정 오류는 탐지 기술만으로 해결할 수 없습니다. 탐지 기술이라는 건, 기술적 결함을 찾아내는 데 특화돼 있지 설정 오류와 같은 인적 요소까지 잡아내지는 못합니다. 설정 오류는 기술이 아니라 관리와 운영의 문제입니다.”

앱옴니는 각종 설정 오류들, 특히 보안 사고로 이어졌던 과거 예시들을 수집하고, 그것들을 기준으로 문제를 해결해 나가는 것을 추천한다. “설정 오류로 인해 터지는 사고들은 얼마든지 예방할 수 있으며, 후속 조치로서 대응하는 건 그리 큰 효과를 거두지 못합니다. 현재 권한이 어떻게 설정돼 있는지, 서드파티의 접근 현황은 어떻게 돼 있는지, 네트워크 내 은둔의 IT(Shadow IT)는 없는지 등부터 확인하는 게 좋습니다. 한 마디로 조직 전체의 가시성을 확보해야 한다는 겁니다.”

한 번에 모든 것을 다 알아내려고 하면 오히려 쉽게 포기하게 된다고 앱옴니는 조언한다. “실제 지금 상황에서 통제할 수 있는 부분부터 만져가기 시작해야 합니다. 전사적인 가시성이라는 게 하루 이틀 만에 뚝딱 확보되지 않습니다. 꾸준히 넓혀가야 하는 것이고, 따라서 매일 조금씩 향상시켜야 합니다. 어떻게 보면 매우 느린 과정일 수 있습니다. 하지만 그런 노력이 그 무엇보다 선제적인 방어의 태도이기도 합니다. 사건이 터지고 나서 움직이는 것만큼 느린 건 없습니다.”