[자유로운설탕의 SaaS 이야기] 3rd Party 와의 유사성에 기반한 SAAS 접근법 - 2부 2편
페이지 정보

본문
앞에서는 SAAS 서비스와 서드파티의 유사점(데이터의 전달, 역학 관계, Lock-in 효과, 서로 다른 기준, 장애 시 기다림, 선택의 다양성과 제한성-레퍼런스, 비용 및 수수료 협상)들에 대해서 살펴보았다. 이번엔 이러한 부분들을 고려했을 때, SAAS 서비스를 도입 시 생각해 볼 만한 주제들에 대해서 살펴보자. 쓰다 보니 앞선 얘기의 연장선 같기도 하고, 제목과는 조금 다르게 보안에 완전히 포커스 된 얘기는 아닌 것도 같긴 하지만, 어차피 보안 활동은 대상에 대한 이해에서 출발한다는 측면에서 의미는 있어 보인다^^
2.1 가시성
서드파티와 마찬가지로 SAAS 서비스는 해당 솔루션 회사에서 노출을 허용하는 부분만을 사용하는 회사에서 관여할 수 있다(이건 사실 온프라미스 솔루션 들도 비슷하다고 볼 순 있지만, 그 쪽에서는 시스템 자체가 회사 내부의 컨트롤 가능한 영역에 있기 때문에, 해당 솔루션 OS의 CLI나 데이터베이스에 대한 직접 접근 등 여러가지 예외 가능 성이 좀더 오픈 되어 있다고 본다). 그래서 결국 SAAS에서 사용자가 접근할 수 있는 부분은 정의되어 있는 UI 옵션 화면과 솔루션이 제공하는 API 등의 확장 인터페이스라고 보면 될 듯싶다(솔루션에 따라서는 프로그래밍 가능한 스크립트나 내부 데이터를 접근하게 해주는 추가 수단을 제공해 줄 수도 있을 것은 같다).
[그림 2-8 계기판이 있는 비행기 조정석]
UI 옵션 부분은 사실 대부분의 솔루션들이 선택을 할 수 있는 고정된 옵션 값을 제공하는 경우가 많으며, AI 기반의 판단을 해주는 옵션들이 있다면 해당 부분은 내부 로직을 알 수 없는 블랙박스인 경우가 대부분일 것이다(이것은 AI 모델 특성 상 보통 개발사 조차도 명확하게 결과를 설명하기 힘들거나, 솔루션 간의 경쟁을 확보하기 위한 비밀이라 그런 경우가 있을 것 같다). 보통 기본 세팅이 된 UI가 제공되기 때문에 해당 부분에 기반해 사용할 수 밖에는 없는 것 같다. 이 부분은 서드파티 회사에 대해 우리가 해당 회사의 내부 설계를 상세히 컨트롤하지 못하면서도 공식적으로 제공되는 서비스를 신뢰하고 사용하는 것과 비슷하다고 본다.
어플리케이션 보안 테스트를 할 때의 상황과 비교하자면 서드파티 라이브리러에 의존하고 있는 경우 해당 라이브러리에 자체에 대한 상세한 검증 테스트는 보통 하지 못하고, 제공되는 인터페이스에 기반한 권한 관리 및 교환되는 데이터 측면에 집중해 살펴볼 수밖에 없는 것과 비슷하다. SAAS 가 속해 있는 환경은 어찌 보면 신뢰할 수 있는 클라우드 환경 내에서 해당 SAAS 회사의 소프트웨어적 가상 환경에서 제공하고 관리해 주는 부분이기 때문에 온프라미스 버전 보다는 아무래도 소프트웨어 그 자체에 집중을 할 수밖에는 없다.
서드파티 회사들의 경우에도 일반적으로 그 회사의 서비스에 집중하게 된다. 내부의 시스템에 대해 관심을 질 수 있는 부분은 초기 도입과 감사 시기 정도에 제한 적으로 될 것이다. SAAS 역시 해당 내부 환경에 대한 상세 감사 수행은 거의 불가능하다고 보며 특수한 경우가 아니라면(ex: 무기, 항공기 개발 등 발주자가 엄청 강력하고 특수하게 민감한 분야) 감사에 대한 협의가 어렵고, 감사자의 ROI 또한 나오지 못하지 않을까 싶다.
그런 측면 때문에 여러 회사 및 기관에서 발행한 클라우드 서비스 보안 가이드 들을 보면 대부분 권한 관리나 명확한 영역의 구분, 노출된 설정, 베스트 운영 전략 등에 집중되어 있는 게 아닐 까 싶다. 그렇게 보다 보면 온프라미스 보안 가이드와 많은 차이가 없는 듯도 싶고 말이다. 보안 담당자 들은 좀 더 클라우드 적인 요소들을 자세히 들여다볼 수 없는 부분이 답답하다고 생각할 수 있겠지만, 그건 클라우드 서비스나 SAAS 서비스를 이용하는 장점이라는 아이러니한 측면이 있다. 어찌 보면 보안적 측면에서도 “시스템 운영, 시스템 자체의 보안 체크 등의 귀찮은 건 우리가 해줄 께 너희는 서비스 자체나 권한 관리, 데이터의 검증에 집중해” 라는 스탠스 같기도 하다. 물론 해당 부분은 필자가 아는 부분이 부족해 이렇게 좁은 관점에서 생각할 수도 있을 거라는 꼬리는 남겨 본다.
다만 한가지 해당 상황에서도 예외가 안되는 것은 앞에서 강조했던 데이터(특히 고객 및 비즈니스 노하우) 부분이다. 안이 블랙 박스인 AI 영역 이든, 클라우드 밴더에서 관리해 주는 영역이든 간에 만약 우리의 중요한 데이터를 전달해 주는 상황이 된다면, 어떻게든 가시성을 확보하고 정보의 안전한 라이프사이클을 보장할 수 있어야 한다고 본다. 다만 해당 부분에 대해 아주 작은 한 고객의 입장에서 수월하게 협조를 받아 낼 수 있지는 별개의 문제이긴 하지만, 역으로 해당 부분에 대해 적절히 납득 가능한 증명을 관련 클라우드 플랫폼과 SAAS 회사들이 하려 하느냐도 중요한 선택 요소라고 봐도 될 것이다.
2.2 표준화
보통 여러 회사들에 서비스를 하는 서드파티 회사와 마찬가지로 SASS 서비스는 많은 회사들이 동시에 사용해야 하기 때문에 강한 표준화가 되어있다. 이 표준화 부분은 해당 회사의 기획 및 개발, 운영 리소스의 효율적 사용과도 밀접한 관계가 있다. 이것은 여러 기존 회사들이 자사의 쇼핑몰, 포탈 등의 서비스 들에 대해서 동일한 인터페이스 내에서 고객들이 사용을 하도록 하려는 니즈 와도 동일하다.
물론 맞춤 서비스 같은 영역들이 있지만 대부분의 경우 그건 UI 나 기능 보다는 노출되는 데이터 측면의 맞춤에 가까울 것이고, UI 나 기능의 커스터마이즈를 지원하는 부분이 있다면 특정한 템플릿 형태의 제한이 있거나, API 등을 이용해 일종의 개방적 로우 코드 측면의 서비스를 제공하는 경우가 대부분일 것이다.
[그림 2–9 규격화 되어 진열되어 있는 신발]
이런 표준화된 환경에서 베타 및 A/B 테스트 등 개발 과정에서 다양한 시도를 빠르게 할 수 있기 때문에 트렌드에 민감하게 신속히 새 기능을 제공할 수도 있겠지만, 반대로 모든 회사에게 효율적으로 동일한 서비스를 제공해야 하기 때문에 특정 회사의 특별한 요구를 제품에 반영시키기는 더 어려워질 수가 있다.
또한 선택지가 옵션으로 되어있으므로, 사실 운영자 입장에서 필요한 옵션만 생각없이 쓰는 암기식 운영이 되어버릴 수도 있고 해당 회사에는 필요 없는 광범위한 옵션들이 괜히 복잡하게 상황을 만들 수도 있다. 만약 보안 목적으로 사용하는 SAAS 솔루션이라면 해당 부분이 운영 리소스나 적용 전략 측면에서는 편할 수도 있겠지만 반대로 익숙해지면 해당 옵션이 관련 보안의 모든 측면이라고 생각하게 되는 착각을 가져올 수도 있어 보인다.
사실 앞의 가시성의 제한 또한 이러한 표준화의 결과일 수도 있을 것 같다. 보통 많은 솔루션은 이러한 제한을 벗어나기 위해서 풍부한 API 들을 제공하긴 하지만 해당 부분의 반대 급부에 대해서는 뒤에서 연결해 좀 더 자세히 얘기해 보려 한다.
2.3 자동화
AI에 특화된 SAAS 서비스들이 어필하는 부분 중 하나가, 우리는 방대한 여러 사이트나 국가의 다양한 데이터 사례를 모아서 학습하고 개선하기 때문에 효과가 검증되어 있고, 다양한 케이스에 대응이 가능해서, 고객 쪽에서는 완전한 데이터를 기반으로 잘 학습된 모델을 가져다 쓰기만 한다는 부분일 것이다.
물론 해당 부분이 룰이나 프로그래밍 적인 패턴(사실 이것도 데이터를 이해하고 판단하는 다른 관점이라고 생각은 하지만)으로 커버될 수 없는 영역을 채워주는 장점은 있지만, 반대로 우리가 이해를 못하는 자동화 판단 영역을 무조건 적으로 신뢰하며 사용하게 되는 리스크를 가져올 수도 있다.
[그림 2–10 이해하기 힘들 정도로 복잡하게 작동하는 기계]
전통적으로 자동화는 수행 가능한 수동화 프로세스를 로직으로 구현하여 전기로 구동되는 컴퓨터의 힘을 이용하여 재현하고 재사용하는 부분에 가까웠지만, AI 영역에 오면서 데이터를 모아 학습을 시켜 기존 자동화 방식과 같거나 더 향상된 효과를 지향하는 프로세스가 추가로 생기게 되었다고 본다. 물론 두가지 타입이 다 현실을 이해하여 재구성한다는 측면을 가지고 있지만, 이해하지 못한 상태에서 사람의 손이나 판단을 타지 않고 자동으로 일어나는 부분이 보안적으로 꼭 안전한가에 대한부분은 한번쯤 생각해 볼 여지가 있다.
데이터 분류나 재구성, 해석의 자동화 측면인 AI는 보통 결과를 설명하기 어렵고, 예외적인 상황이 생겼을 때 통제가 불가능 하거나 개선하기 어려운 측면이 있다고 본다. 예외적인 상황에 대해 해당 측면을 고려해 다시 학습을 시켜서 새로운 모델을 생성하기 전에는 관련 대응을 기대하기 어렵고 말이다. 물론 모든 것을 이해할 수는 없기 때문에 그러한 지식이 집약된 SAAS 솔루션 들의 효과를 신뢰를 하며 나름 내부적인 테스트를 하여 기본 검증을 해야 겠지만, 넓은 관점에서 해당 솔루션의 모델이 어떤 데이터를 수집하여 어떤 동작을 하려하는 지를 이해하는 것은 필요하다고 본다.
물론 이런 종합적인 데이터 분석 측면에서 이해할 수 있는 보안 인력은 드물 것 같고, SAAS 회사에서도 자세한 내부 부분은 결함에 대한 악용이나 경쟁적 우위를 위해서 제공하진 않을 것 같지만, 결국 보안 솔루션들은 데이터를 기준으로 동작할 수밖에 없기 때문에, 데이터와 데이터의 흐름을 이해해야 하며, 해당 부분은 AI와 같이 자동화된 프로세스 상이라도 예외가 되지는 않는다고 본다.
적어도 지금 수집하는 데이터가 룰이나 전통적인 데이터 분석이나 AI를 통해서 의미 있는 결과를 낼 수 있는 부분인지는 고민해야 한다. 뭐 필자 개인적으로 AI 쪽에 대해선 그렇게 할 수 있는 능력은 없다고 생각해서 이 정도의 당위성을 밝히고 도망을 가려 한다^^
2.4 유연성
서로 스타일이 다른 서드파티 회사에 대해서 서로 다른 평가 기준을 가져야 하듯이, 각 SAAS 솔루션 성격에 따라서도 유연한 대처가 필요하다. 솔루션의 성격에 따라 전달하는 데이터나 노출되는 영역, 스타일이 틀릴 것이고, 이에 따라 서로 다른 보안 적인 관점을 통해 검증해야 할 것이다.
[그림 2–11 유연한 체조 선수]
물론 솔루션들이 무한으로 다른 형태를 가지진 않기 때문에, 어느정도 경험을 가진다면 특정한패턴에 비추어 각 솔루션 들을 바라볼 수 있게는 될 것이다. 해당 패턴을 인지하는 상태에서 앞에서의 가시성과 표준화, 자동화 측면을 고려해서 현재 파악할 수 있고, 체크할 수 있고, 통제할 수 없는 영역이 어딘 지를 파악하고 현재 투여 가능한 리소스를 가능한 영역에 적절히 배치하여 검증해야 할 것이다.
2.5 대상의 입장에서 이해하기
서드파티 회사들 중 규모가 있는 회사들은 나름대로의 효율화 된 업계에 기반한 표준이 있다. 마찬가지로 앞의 유연성 이슈와 연관되어 특히 이름이 알려진 메이저 솔루션일 경우 나름 본인들이 추구하는 철학이 있다고 본다(이러한 철학이 컴플라이언스 준수를 위해 만들어졌다는 설명도 들었지만 개인적으로는 그 이상으로 보안은 이래야 하다는 솔루션 설계자의 고집이 보이는 것 같기도 하다). 문제는 해당 철학에 기반한 설계가 SAAS 회사마다 틀리기 때문에, 현재 솔루션을 도입하려는 회사의 현실과는 충돌이 생길 수도 있다(이 부분은 SAAS, 온프라미스 솔루션이냐에 따라 굳이 차이가 나는 부분은 아닌 것 같기도 하다).
[그림 2–12 다른 사람의 마음을 들여다보기]
반대로 얘기하면 이상하고 거추장스러워 보이는 그 솔루션이 우리 회사가 아닌 다른 회사의 환경이라면 꽤 적합한 솔루션일 수도 있다는 것이다. 이러한 관점에서 해당 솔루션을 검토할 때 “우리한테는 안 맞아” 하는 단정적인 관점으로만 본다면 해당 솔루션이 추구하고 있는 참고할 만한 관점을 놓칠 수도 있다. 선택의 여부를 떠나 해당 솔루션의 철학과 설계의 방향을 이해하고 우리 에게는 왜 안 맞는 솔루션인지를 판단하는 것도 많이 중요하다고 본다.
그렇게 해야 하는 이유는 사실 100% 우리 니즈에 맞는 솔루션을 만나기는 힘들다는 부분도 있고, 또 그 단점으로 보이는 측면이 다른 측면으로 보면 우리가 느끼지 못한 장점의 사이드 이펙일 수도 있다는 것이다. 좀 더 나아가 어쩌면 우리가 뭔가 초기에 잘못 가정된 요구사항을 수립했을 수도 있다. 이런 대상의 입장에서 이해하기가 필요한 이유는 당신이 보유한 보안적 패턴이라는 것은 사실 이해한 대상에 대해서만 적용 가능한 부분이기 때문이다.
2.6 다양성
다양성은 비용 측면에서 얘기를 해 보려고 한다. 서드파티 회사들에 대한 도입 및 운영 비용이 매년 시시각각 달라지듯이 솔루션 또한 한번 도입한다고 비용이 고정되는 것은 아니다. 이 것은 단순히 유지보수 적인 측면의 관점이라기 보다는 앞에서 얘기했듯이 SAAS 서비스를 제공하는 회사의 담당자나 우리 회사의 담당자나 항상 본인 회사의 최대 이익을 위해 일하기 때문이다.
특히나 구독이나 옵션사항들로 배치되어 복잡한 BM(Business Model) 이 설계되어 있는 메이저 SAAS 솔루션의 경우 해당 조합의 선택에 의해 최초 도입 비용이 결정 나며, 최초 도입 비용이 저렴하다고 해서 해당 수준이 향후 계속 유지되기에는 변수가 너무 많은 것 같다.
[그림 2–13 시장에서 장보기]
그 솔루션을 실제 유용하게 운영하기 위해 필요한 추가 옵션 비용이 크다거나(요즘 솔루션들은 앱 스토어의 “앱 내 추가 구매 있음” 측면과 많이 닮아 있다), 데이터 기반의 라이선스의 경우에는 차후 다루는 데이터가 커질 경우에 따른 비용 증가 등의 변수가 있을 수 있다. 또 라이선스 사용자/객체 증가로 인한 비용, 해마다 요율이 증가되는 유지보수 금액 정책, EOSL에 의한 신규 솔루션 도입 비용, 합병에 따른 솔루션들의 역학 관계의 변화, 환율 리스크, 우리 회사의 마케팅 적 레퍼런스 가치의 변화 등 많은 것이 변수가 될 수 있다. 하다 못해 전혀 상관없어 보이는 서포트 엔지니어의 숙련도 까지도, 쉽게 갈수 있는 길을 어렵게 돌아가게 만들어(그 사실을 아무도 모르기 때문에) 특정 시점에는 많은 비용이 들게 만드는 포인트가 될 수도 있다.
보안 솔루션의 경우라면 적절한 수준의 보안 서비스를 제공하기 위한 기능과 비용의 절충점 이라든가, 그 이외의 솔루션이라면 보안 관점의 모니터링을 가능하기 해주는 솔루션 옵션에 대한 고려 같은 부분이 있을 것이다(많은 솔루션이 보안 및 감사에 대한 기능을 추가 옵션으로 판매하는 경우도 있는 것 같다).
보면 볼수록 참 정답이 없고 애매한 분야이긴 하지만 이것은 앞에서 얘기했던 여러 역학관계 및 다양성, 서로의 입장에서의 이익 추가 및 성장에 대한 니즈 때문에 어쩔 수 없이 생기는 다이내믹한 부분인 것 같다. 뭐 관련 담당자 들은 그런 것들을 대응하고 패턴화 하여 해결하면서 자신의 직업 영역을 구축하여 어필하고 월급을 받고 사는 것일 터이고 말이다.
2.7 데이터와 인터페이스를 이해하기
앞 장에서 얘기했듯 일반적으로 우리는 서드파티 회사에 서비스를 받기위해 특정한 인터페이스를 통해 특정한 내부 데이터를 전달해야 하며, 그것은 SAAS 쪽도 마찬가지다. 현재의 SAAS 솔루션들은 100% 클라우드에 얹혀진 소프트웨어로 구성되어 있고, 다양한 회사들의 니즈를 해결하기 위해서 많은 옵션을 세분화해서 제공하며, 다른 SAAS 솔루션이나 온프레미스 솔루션과의 호환성 때문에 API를 포함한 외부 인터페이스를 방대하게 제공하는 측면이 있다.
[그림 2–14 요리 재료와 여러가지 주방 도구]
물론 세상에는 공짜가 없기 때문에, 이 방대한 층의 외부 인터페이스를 제공받는 것의 반대 급부는 해당 전체 노출된 설계를 이해하고, 적절한 호출 권한을 배정하고, 안전하게 사용할 수 있도록 파악하여 데이터를 안전하게 이용할 수 있도록 정리하고, 노력해야 한다는 것이다. 편리하고 시스템의 내부를 상세히 보여주는 API 나 옵션, 관리 기능 들은 반대로 공격자에게는 굳이 SAAS 솔루션을 공식적인 경로를 통해 어렵게 들어가지 않고도 원하는 목적을 이룰 수 있게 하는 우회 경로가 될 수도 있다.
또한 이러한 자동화를 위해 제공된 기능을 이용한 공격은 모니터링을 통해 인지하기도 어려울 가능성이 많고, 단편적이거나 아주 장기적인 기간에 걸쳐 모니터링 임계치를 피해 일어나게 될 가능성도 높다고 본다. 최악의 경우에서는 해당 인터페이스를 통해 원하지 않는 내부 데이터의 파괴 또한 일어날 수 있고 말이다(제공되는 인터페이스를 통한 이러한 악용은 어프리케이션 보안 쪽에서의 SQL Injection 취약점과 비슷한 상황이라고 본다). 생각보다 보안적 측면에서 공격자와 방어자가 사용하는 툴은 동일한 경우가 많기 때문에(암호화와 랜섬웨어를 생각해 보자), 운영 편의와 모니터링을 위한 이러한 기능 들을 별 생각 없이 운영하고 방치 한다면 스스로에게 독이 가능성이 높다고 본다.
2.8 결론
정신없이 글을 쓰다 뒤돌아보니 조금은 서드파티와 SAAS 를 억지로 연결해 보려는 무리한 시도를 한 것인 가도 싶다. 변명을 해보자면 단순히 SAAS 에 초점을 두고 설명하는 것보다 좀 더 실제적이고 익숙한 분야와 비교해 설명하는 것이 좀 더 낫다고 생각했기 때문이고 얼마나 공감이 되었을 지는 모르겠다. 덤으로 예전 기억을 더듬어 서드파티 보안에 대한 이야기도 한번 정리할 수 있었고 말이다.
점점 설명하면서 SAAS 와 온프라미스 솔루션을 서로 구분하게 않게 되는 경향이 있는데, 개인적으로 두 솔루션은 올라가 있는 가상화 환경이나 마케팅 적인 접근 법 때문에 많이 달라 보이긴 해도 어느 측면의 베이스 관점에서는 동일한 대상이라는 생각을 점점 가지게 된다.