공공기관에서의 디지털 기술 활용기술이 이제는 거의 모든 업무 영역에서 적용되고 있다. 그러나 최신 기술을 도입하거나 사용자의 불편 사항, 그리고 개선 사항들이 반영되는 주기는 크게 줄어들지 못하고 있다. 왜 그럴까?
첫째, 공공기관 업무 특성상 엄격한 보안 및 컴플라이언스 이슈들을 충족시키기 위한 절차가 까다롭기 때문이다. 둘째, 새로운 서비스를 구매하는 절차, 즉, 기존 조달 방식이 신규 서비스 도입 시 걸림돌이 될 수 있기 때문이다. 공공기관에서 발주하는 과업을 규모에 따라 공개 입찰하고 이를 수주하는 전통적 조달 방식으로는 급격히 변화하는 기술 트렌드나 사용자의 요구사항을 충족시키기 어렵다. SI(System Integration)를 통한 구축 방식, 또는 패키지를 라이선스를 도입하는 방식으로만은 디지털 기술 발전 속도를 따라가기 어렵다는 의미다.
대표적으로 클라우드컴퓨팅서비스 활용을 들 수 있다. 민간 기업에서는 이미 워크로드(workload) 상당 부분을 클라우드로 전환하고 있기 때문에 공공기관에서의 클라우드컴퓨팅 활용이 당연히 화두가 될 수밖에 없다. 이에 우리나라에서도 관련 법령을 제정하여 공공기관에서 클라우드컴퓨팅서비스를 활용할 수 있는 조달 기준을 마련했다.
기존 일괄구매 혹은 구축 방식뿐만 아니라 사용한 만큼 비용을 정기적으로 지불하는 방식이 가능해졌다는 것에서 이런 변화는 매우 환영할 만하다. 물론 아직도 진입장벽이 충분히 낮아지지는 않았다. 복잡하고 까다로운 서비스 ‘납품 조건’을 충족하기 위한 제안서를 작성하고, 이에 따른 회사의 관련 시스템을 정비하는 데에 너무 큰 노력이 필요하다. 효율을 추구하는 기업의 입장에서 아직은 진입하기 어려운 시장임은 틀림없다.
정부에서는 공공기관의 클라우드컴퓨팅서비스 활용 수준을 민간 기업 수준까지 끌어올리기 위한 노력의 일환으로 디지털서비스 전문계약제도 도입을 위한 시행령을 개정, 2020년 10월1일부터 시행하기로 하였다. 여기에는 클라우드컴퓨팅법 시행령, 국가계약법 시행령, 조달사업법 시행령이 포함된다.
디지털서비스에 관한 정의를 신설하고, 계약대상 선정을 신속하게 진행하기 위한 디지털서비스 심사위원회 신설, 그리고, 디지털서비스에 대한 수의 계약 또는 카탈로그 계약이 신설된 것이 주요 골자다. 디지털서비스는 클라우드컴퓨팅서비스 및 이를 지원하는 서비스, 그리고 다른 기술서비스와 클라우드컴퓨팅 기술을 융합한 서비스로 구성된다.
시행령을 통해 클라우드컴퓨팅 도입에 필요한 조달절차의 유연성이 확보된 것은 긍정적인 시그널이라고 판단된다. 심사위원회는 아직 실시 전이기 때문에 얼마나 효율적으로 운영될지는 좀 더 두고 보아야 할 부분이다. 결국, 디지털서비스 정의의 핵심인 클라우드컴퓨팅서비스 분야에 민간 기업이 얼마나 많이 적극적으로 참여할지 여부가 이번 시행령을 통한 성과를 좌우하게 될 것으로 보인다.
공공 부문 클라우드의 첫 관문 – 보안인증
한국인터넷진흥원에서는 클라우드컴퓨팅 발전 및 이용자 보호에 관한 법률(클라우드컴퓨팅법)2) 제 23조 제2항에 의거 클라우드컴퓨팅서비스의 정보보호 기준의 준수 여부를 평가/인증하는 “클라우드서비스 보안인증(CSAP: Cloud Security Assurance Program)” 사업을 진행하고 있다. 공공기관의 특수성을 고려하면, 클라우드컴퓨팅 사용 시 예견될 수 있는 보안 위협으로부터 최대한 사용자와 기관을 보호한다는 측면에서 매우 중요한 활동이라고 볼 수 있다.
평가/인증 기준은, IaaS(Infra as a Service), SaaS(Software as a Service), PaaS(Platform as a Service)를 대상으로 각각 구분하고 있다. 클라우드컴퓨팅 발전 및 이용자 보호에 관한 법률 시행령(클라우드컴퓨팅법 시행령) 3조의 1항, 2항, 3항이 각각 IaaS, SaaS, PaaS에 해당한다.
SaaS는 다시 “표준등급”과 “간편등급”으로 나누어져 있는데, 표준등급은 전자결재, 인사 및 회계관리, 보안서비스 등 “중요 데이터”를 다루는 서비스를 대상으로 하며, 간편등급은 그 외 모든 서비스를 대상으로 한다고 명시되어 있다. IaaS의 경우 총 14개 분야에서 117개의 통제항목을 기준으로 삼고 있으며, SaaS 표준등급에서는 “물리적 보안”을 제외한 총 13개 분야에서 78개의 통제항목, SaaS 간편등급에서는 표준등급에서 “자산관리”, “서비스 공급망관리”를 제외한 11개 분야의 30개 통제항목을 각각 제시하고 있다. PaaS의 경우 현재 SaaS 표준등급과 동일한 기준으로 평가/인증을 시행하고 있다.
현재까지 발급된 총 CSAP 인증서는 25건이다. 이중 IaaS 10건, SaaS 표준등급 6건, SaaS 간편등급 9건이다. PaaS 인증 건은 아직 없다. 한 회사에서 여러 건의 인증을 받은 케이스들이 있기 때문에 실제 인증을 받은 기업의 숫자는 총 건수보다 훨씬 적다. 인증 첫해인 2016년 KT가 IaaS 인증 받은 것을 필두로 2018년까지는 대부분 IaaS 인증이 주류를 이루다가, 이후 점차 SaaS 인증이 늘기 시작한다. 특이할 만한 사항으로는 SaaS 인증도 초기에는 표준등급만 주로 발급되었으나 2019년 하반기 이후에는 간편등급이 표준등급을 훨씬 상회하기 시작한다. 이는 SaaS 간편등급 기준이 뒤늦게 제정된 결과이겠으나, 앞으로는 특정 도메인에 특화된 서비스에서 SaaS 간편등급 인증 발급 신청이 더 많아질 것으로 예측해 볼 수도 있다. 또한 PaaS와 관련된 기준도 곧 제정될 것으로 전망한다.
기업에서 클라우드컴퓨팅을 도입하는 데 있어 가장 공을 들여 점검하는 부분, 반대의 시각으로 표현하면, 도입에 가장 걸림돌이 되는 부분이 보안이라는 사실에 아무도 이견을 달지 않는다. 공공기관의 경우에는 더욱더 보안 관련 이슈에 민감할 수밖에 없다. CSAP와 같은 인증 서비스가 어떻게 운영되는가에 따라 공공기관의 클라우드컴퓨팅 전환에 윤활유가 될 수도 있고, 반대로 장애요소가 될 수도 있다. 합리적인 기준 설정과 효율적인 운영이 바탕이 되어야 공공기관에서의 클라우드 활용도가 높아질 수 있다.
CSAP 인증 해설서에 의하면 평가에 소요되는 기간은 IaaS의 경우 업무일 기준 총 25일, SaaS 표준등급의 경우 총 25일, SaaS 간편등급의 경우 총 17일이라고 한다. 인증서 유효기간은 IaaS와 SaaS 표준등급의 경우 5년, SaaS 간편등급의 경우 3년이다. 그리고 매년 최소 1회 이상 사후평가가 진행된다고 하니 평가 횟수는 서비스 구분과 관계없이 1년에 최소 1회 이상이라고 보면 된다. 여기에 서비스 수정이 있을 때마다 별도 평가가 이루어지고 이에 따른 인증서 갱신이 필요할 수도 있다. 따라서 실제 평가 회수는 연 1회를 대체로 상회할 것으로 예상된다. 효율적인 인증평가가 담보되지 않는 한 공공 부문에서의 클라우드컴퓨팅서비스 활성화가 쉽지 않아 보인다.
공동 책임 모델에 기반한 클라우드 보안인증
클라우드컴퓨팅에서의 보안 이슈를 살펴보기 위해서는 보안과 관련된 카테고리별로 과연 누가 통제권을 행사하고 책임을 져야 하는가를 구분하는 것이 우선 필요하다. 여기서 “누가”라고 하는 것은 크게 서비스 제공자 혹은 사용자로 구분이 될 수 있다. 클라우드컴퓨팅서비스에서는 보안이 적용되는 대상을 여러 계층으로 분류할 수 있다.
클라우드컴퓨팅서비스 벤더들은 이를 ‘공동 책임 모델'(Shared Responsibility Model)이라 부르며 서비스 벤더와 사용자간의 책임소재를 명확히 구분 짓고 있다. 클라우드서비스 1위 기업인 아마존의 경우 매우 보수적인 벤더 관점의 책임 모델을 제시하고 있다. 전형적인 IaaS 관점에서 사용자와 AWS와의 책임을 구분하고 있다. 사용자는 클라우드 “안”에서의 보안에 대한 책임이 있고, AWS는 클라우드“의” 보안을 책임진다는 표현이 짧지만 강하게 그 차이를 명확하게 정의하고 있다.
AWS에 이어 세계 2위의 클라우드 서비스인 마이크로서비스 애저의 경우 클라우드서비스 유형별로의 공동 책임 모델을 제시하고 있다.
AWS나 애저의 경우 공히 클라우드컴퓨팅서비스를 구성하거나 혹은 사용되는 자산(asset)별로 구분하여 보안대상을 정의하고 있다. 애저의 경우는 보안대상을 계층별로 좀 더 상세하게 구분하여 SaaS와 PaaS, IaaS에서 책임소재를 별도로 정의하고 있다. IaaS의 경우 인프라 구조와 이러한 인프라 구조에 필요한 기본적인 소프트웨어에 대해 클라우드서비스 벤더의 보안책임을 적시하고 있다.
SaaS에 대해서는 클라우드서비스 벤더가 책임지는 항목이 사용자보다 확연히 많아짐을 알 수 있다. PaaS에 대해서는 다소 모호하게 책임소재가 구분되어 있는데 이는 개별 PaaS 기능마다 다루는 자산의 범위가 각각 다를 수 있고, 또 관련 보안 정책도 이에 따라 유연하게 적용되어야 하기 때문이다. AWS와 애저의 예에서 공통으로 빠진 대상이 있다면 최상위 레벨의 “사람과 조직”이다. 아마도 특별히 언급하지 않은 이유는 데이터와 함께 당연히 사용자가 책임져야 할 부분이기 때문일 것이다.
이러한 공동 책임 모델은 합리적인 보안 인증 기준을 만드는 기초가 될 수 있다. 만일 내가 특정 벤더의 IaaS를 활용한다면 과연 보안인증 대상을 어디까지 잡아야 할까? 좀 더 간단히 정리된 애저의 경우를 예를 들면 물리적 호스트, 네트워크, 데이터센터가 보안 인증 대상이다. 한국인터넷진흥원에서 명시한 통제 분야에서는 “물리적 보안”, “가상화 보안”, “네트워크 보안”이 IaaS 벤더가 책임져야할 보안 대상이다. 그 외 11개의 통제 분야는 자산(Asset)관점에서의 보안 대상이라기보다는 일반적인 보안 프로세스상의 체크리스트로 볼 수 있다. 물론 안전한 서비스 제공을 위해 벤더가 반드시 지켜야 할 주요 항목들이 상당히 많이 포함되어 있기는 하나, 이 중에는 IaaS 벤더가 “왜” 여기까지 확인을 받아야 하는지 의문을 제기할 부분들도 꽤 있다.
대표적으로 데이터 보호 디지털서비스 이슈 와 관련된 부분을 들 수 있다. 보안인증 기준 해설서에 의하면 12.1 데이터 보호 항목의 통제 내용에 “데이터 유형, 법적 요구사항, 민감도 및 중요도에 따라 데이터를 분류하고 관리하여야 한다.”라는 항목이 있다. 이는 분명 IaaS 제공자가 다룰 영역이 아니라 IaaS 사용자가 다루어야 할 영역이다. AWS나 애저 서비스의 경우 데이터는 공동 책임 모델에서도 사용자에게 있음을 명시하고 있다.
이 기준 하나만으로도 이미 AWS와 애저는 IaaS 제공자로 인증 불가 대상이 된다. 더욱더 흥미로운 것으로 2.1.5에 있는 직원 상벌 기준도 있다. IaaS 제공 기업 내에서의 인사 규정까지 인증 조건으로 내세우는 것이 과연 얼마나 의미가 있을지 의구심이 든다. 물론 인증을 신청하는 기업은 이미 존재하는 사내 규정을 복사해 붙이면 되니 별로 어려운 일은 아닐 것이다. 그만큼 무의미한 것일 수 있다는 뜻이다.
SaaS의 경우 물리적 보안인증 기준에 대해서는 설명서에서 아예 생략하고 있다. “물리적 보안은 SaaS 평가 기준에는 적용하지 않는다.”라고 간단하게 한 줄만 들어가 있는데, 과연 이것으로 충분한지도 의문이다. 만일 AWS를 기반으로 SaaS 서비스가 제공된다면 이를 어떻게 판단할 것인가? 문맥상 AWS가 인증을 받지 못했기 때문에 이 위에서 실행되는 SaaS 서비스도 인증을 받지 못하는 것으로 이해되나 보안인증 항목에서 아무런 조건을 달지 않고 예외적용하는 것 또한 이해하기 어렵다.
가상자원에 대한 예를 하나 더 살펴보면, “IaaS 사업자로부터 할당받은 가상자원(가상 머신, 가상 스토리지, 가상 소프트웨어 등)의 생성, 변경, 회수 등에 대한 관리방안을 수립 및 이행하고 있는가?”이다. 이는 사실 워크로드 관리에 대한 기준으로 설명되는 것이 더 합리적이다. 갑자기 부하가 많이 걸리거나 아니면 상대적으로 부하가 적게 걸렸을 때 불필요한 자원을 활용하지 않으면서도 안정적인 서비스를 제공하기 위한 방안을 명시하도록 하는 것이다. 그러나 이 역시 컨테이너 기반의 클라우드 네이티브 환경에서 제공되는 서비스에 적용되기에는 충분해 보이지 않는다.
보안 인증을 좀 더 효율적으로 수행하기 위해서는 다음과 같은 단계별 진행도 고려해 볼 만하다.
- 첫째, 보안에 필요하다고 여겨지는 프로세스들을 열거하고 각각에 대한 인증기준(항목)을 정의한다.
- 둘째, 공동 책임 모델을 참고하여 보안대상을 정의한다.
- 셋째, 각각의 보안대상별로 앞서 정의한 보안 프로세스(인증항목)들을 연결(mapping)한다.
이렇게 하면 보안대상과 프로세스가 섞여 있어 인증기준 적용 여부가 모호한 부분이 좀 더 명확하게 정리될 것이다. 그리고 보안대상별로 인증항목들과 연결할 때 어떤 인증항목을 포함하는가에 따라 인증 수준도 차별화 할 수 있을 것이다. 한편 이미 인증된 IaaS 상에서 제공되는 SaaS 서비스의 경우 IaaS에 해당하는 인증 대상을 제외함으로써 인증 절차를 좀 더 간소화 할 수도 있다.
디지털서비스 마켓플레이스 활성화를 위해선
공공기관 사용자를 대상으로 하는 클라우드서비스 보안은 아무리 강조해도 지나치지 않는다. 한편 안전한 서비스의 중요성 못지않게 다양하고 정말 “괜찮은” 서비스들이 많이 제공되는 것도 마켓플레이스 활성화를 위해 매우 중요하다. 좋은 서비스를 가진 민간기업의 적극적인 참여가 필요하며 이를 위한 진입장벽을 적절한 수준으로 유지하는 것도 중요하다.
기업 입장에서는 관리해야 할 마켓플레이스가 늘어나는 것에 비례하여 비용이 증가하게 되며, 이로 인해 신생 소규모 서비스 기업에서는 새로운 마켓플레이스 진입이 사실상 큰 부담이 될 수밖에 없다. 이를 해소하기 위한 지원책도 함께 마련될 것으로 기대되나, 단기 지원책보다는 지속해서 성장 가능한 마켓플레이스를 위해 지금 이 점에서 좀 더 깊이 검토해야 할 사안이 무엇인가에 대한 논의가 절실하다. 나는 다음 두 가지를 꼽고자 한다.
- 서비스 수준 계약(SLA) vs. 인증
- 디지털서비스 심사위원회의 역할과 심사기준/범위
디지털서비스 마켓플레이스에 입점하는 서비스는 SLA(SLA: Service-Level Agreement: 서비스 수준 협약서; 서비스를 제공함에 있어서 공급자와 사용자간에 서비스에 대하여 측정지표와 목표 등에 대한 협약서)에 대한 제안을 반드시 하여야 한다. 이중 클라우드 보안 인증과 사실상 목적이 중복되는 것이 상당히 많을 것으로 예상된다.
만일 인증으로 커버하는 항목이라면 굳이 기업에서 해당 항목에 대한 SLA를 제시할 필요는 없다. SLA와 인증은 목적은 같지만, 이를 달성하기 위해 제시하는 요건이 다른 것이다. SLA 방식에서는 KPI(Key Performance Indicator) 달성 여부에 따라 인센티브 제공 혹은 페널티가 부과됨으로써 서비스(보안) 품질을 보장하도록 하는 반면, 인증 방식에서는 KPI보다는 정확하게 약속된 “프로세스”를 지키느냐의 여부로 서비스 품질 달성을 유도한다.
중학교 1학년 자녀에게 “다음 기말시험에서 5등 안에 들면 닌텐도 스위치를 사줄게”(‘SLA’)라고 제시하는 것과, “앞으로 기말고사까지 일요일을 제외하고 매일 3시간씩 책상에 앉아서 한 시간에 5분씩만 휴식을 취하고 국·영·수를 하루씩 번갈아 가며 공부하면 기말고사 끝나고 닌텐도 스위치를 사줄게”(‘프로세스 인증’)라고 약속하는 것에 비유할 수 있다. 앞에 있는 것이 SLA, 두 번째 제안이 일종의 “프로세스 인증”에 해당한다. 후자, 즉 인증에 기반을 둔 서비스 제공 방식은 진입장벽을 높이게 되고, 따라서 기업 입장에서도 더 큰 비용을 수반한다. 클라우드 보안 인증도 물론 필요하나 과감하게 SLA로 비중을 높이는 것에 대한 검토가 필요하다.
디지털서비스 심사위원회 활동이 초기 마켓플레이스 활성화 여부에 매우 큰 영향을 줄 것으로 생각한다. 처음부터 너무 많은 것을 위원회에서 다루려 하지 말고 마켓플레이스의 핵심가치와 공공기관에서의 디지털 기술 활용 관점에서의 목표설정을 가능한 단순하고 명확하게 하는 것이 중요하다. “제대로” 된 KPI 설정이 핵심이다. 단순 정량실적 열거를 지양하는 대신 좀 더 큰 그림 속에서 서비스 출시 후 서비스 성장 단계별 차별화된 KPI 정의가 필요하다.
다시 말해서 단기 성과지표와 함께 중장기 관점에서의 목표를 명확하게 나타낼 수 있는 성과지표 정의에 큰 노력을 기울여야 한다. KPI는 전략을 가장 단순 명료하게 표현하는 수단이기 때문이다. 클라우드 보안요건을 포함하여 서비스 진입을 방해하는 요소가 가능한 한 많이 해소될 수 있도록 심사위원회의 개방적 활동을 기대한다.
[divide style=”2″]
[box type=”note”]
본 글은 한국정보화진흥원의 지원을 받아 작성되었으며, 클라우드스토어 씨앗 이슈리포트에 동시 게재합니다.
[/box]
