인그레스에 SSL/TLS 암호화 설정
외부에서 웹으로 파드에 접속시키는 인그레스에 SSL/TLS 암호화를 설정하면 파드에서 접속하는 브라우저에 HTTPS를 요청하게 할 수 있다. 하지만 파드에는 SSL/TLS를 설정하지 않아도 된다. 그러나 이 방법은 인그레스 컨트롤러에 부하가 집중되기 때문에 정식 운영 서비스에 적용할 때에는 성능의 병목현상이 발생하지 않게 주의해야 한다.
오토 스케일(Auto-Scale)
오토 스케일은 CPU와 RAM 사용률에 따라서 파드의 수를 자동으로 가감하는 기능이다. 여기서 필요하면 노드도 가감할 수 있다. 특히 온 디멘드(On-Demand)에서는 노드의 개수, 이용 시간에 따라서 비용이 달라지므로 비용 최소화와도 연결된다. 온 프레미스(On-Premise)에서는 제한된 서버의 자원을 최대한 사용하는 것이 좋은데 업무 시간대에는 사용자의 요청을 처리하는 파드의 비중을 늘리고, 심야 시간대에는 데이터 백업과 같은 배치를 수행하는 파드의 비중을 늘리는 식이다.
쿠버네티스에서는 오토 스케일을 수행하는 몇 가지 기법이 있는데
￭ 수평 파드 오토스케일러(Horizontal Pod Autoscaler, HPA)
￭ 클러스터 오토스케일러(Cluster Autoscaler, CA)이다.
HPA는 파드의 CPU 사용율을 감시하면서 파드의 리플리카 수를 늘리거나 줄이지만 CA는 필요할 때 노드를 자동으로 추가한다. HPA는 개수를 조정하지만 새로운 노드를 추가하지는 않는다. 클라우드에서는 부하에 반응해서 노드의 개수를 조절하는 것이 좋지만 HPA는 별로 이런 요구 사항을 만족시키지 못한다. CA를 사용하면 클라우드의 API와 연계해서 노드를 가감할 수 있다.
HPA는 루프를 돌면서 대상이 되는 파드의 CPU 사용률을 정기적으로 수집해서 파드의 CPU 사용률의 평균을 목표 값이 되게 리플리카 수를 조절한다. 이때
￭ 조절 범위 : MinReplicas <= replicas >= MaxRelicas 이고,
￭ 파드 수 : 파드 수 = 반올림한_정수(파드들의_CPU_사용율_총합 / 목표_CPU_사용율) 이다.
Secret과 ConfigMap
어플의 설정 정보나 패스워드와 같은 인증정보를 컨테이너에 담지 않고 분리해서 네임 스페이스에 저장시키고 컨테이너가 읽게하는 것이 보안상 좋기도 하고 테스트 환경과 프로덕션 환경별로 컨테이너를 별도로 빌드할 필요가 없어진다. 이미지의 빌드 횟수를 줄이면 예상치 못한 버그를 사전에 방지하는 효과가 있게 된다. 테스트가 끝난 상태에서 다시 빌드하면 의도하지 않은 변경이 이미지에 포함될 수 있기 때문에 Container Immutable이 유지되지 못할 수 있다.
컨피크맵은 네임스페이스에 저장된 설정 정보를 말하고 시크릿은 네임스페이스에 저장된 보안이 필요한 정보를 말한다. 컨테이너에서는 이 객체들을 시스템으로 마운트해서 파일로 읽거나 환경 변수로 참조시킬 수 있다.
- Secret 사용하기
테스트 환경에서 테스트를 통과한 어플 이미지는 가능하면 다시 빌드하지 않고 운영환경에 바로 배포하는 것이 좋다. 그러나 컨테이너 이미지에 테스트용 데이터베이스에 대한 ID와 PW 정보가 담겨있으면 운영환경에 배포하기 전에 값을 변경하고 다시 빌드해야 컨테이너 불변성을 유지하게 되므로, 이런 경우 테스트 환경과 운영환경에서 각각 네임스페이스에 시크릿을 만들어 두고 ID와 PW를 별도로 저장시킨 뒤 나중에 컨테이너에서 이들을 환경변수로 읽어들이게 하면 응용 어플의 이미지를 다시 빌드할 필요가 없어진다.
=>$DB_USERNAME과 $DB_PASSWORD를 환경변수로 해서 데이터베이스에 외부에서 적용하듯이 Nginx에서 HTTPS를 사용한다면 SSL/TLS 암호를 설정한 뒤, 이를 외부에서 환경변수로 넣어서 HTTPS 웹을 실행시킬 수 있다.
ConfigMap
컨피그맵은 시크릿과 비슷하게 사용된다. 환경에 따라 변하는 정보를 컨테이너에서 분리하여 컨테이너의 불변성과 재 사용성을 높여준다. 시크릿은 보안이 필요한 정보를 저장해서 참조를 제한하지만, 컨피그맵은 네임스페이스에서 설정 정보를 저장하고 공유시키는 것이 목적이다. 따라서 네임스페이스에 저장된 nginx의 환경변수(설정파일)을 파드에서 읽을 때에는 ConfigMap을 사용해야 한다.
컨피그맵은 다음의 특징이 있다.
￭ 컨피그맵을 등록할 때에는 시크릿처럼 값을 Base64로 인코드하지 않아도 된다.
￭ kubectl describe secret에서는 등록된 내용이 표시되지 않지만 컨피그맵에서는 kubectl describe configmap 하면 내용이 보인다.
￭ 시크릿과 컴피그 맵은 정기적으로 갱신이 체크된다. 환경변수 설정파일이 파드내에 볼륨으로 마운트 된 경우에도 kubelet의 갱신주기에 따른 지연이 있기도 하지만 자동으로 갱신된다.
￭ 클러스터 롤 view의 대상 리소스에 시크릿은 포함되지 않지만 컴피그맵은 포함된다. 따라서 참조 권한만 있으면 컨피그맵의 내용을 볼 수 있다.
클라우드 보안 개요
클라우드는 기존의 산업(의료, 물류, 제조 등)이 IT 기술과 결합하면서 산업 간의 경계가 흐려지고 서비스가 융합되는 4차 산업혁명의 시대에서 주목받고 있는 기술이다. 기존 비즈니스가 IT와 결합하면서 이동 통신사가 없는 전화 서비스(WeChat), 숙소가 없는 숙박 서비스(AirBnB), 택시가 없는 운송 서비스(Uber), 자체 컨텐츠가 없는 SNS(Facebook), 극장이 없는 콘텐츠 서비스(NETFLEX), 재고가 없는 판매 서비스(Alibaba) 등이 새로운 서비스가 생겨났다. 4차 산업에서 클로벌 리더가 되기 위해서는 ICBMA(IoT, Cloud, BlockChain, Mobile, Artificial Intelligence)가 필수 기술이 되었다. 클라우드를 통해서 빅데이터의 수집, 저장, 분석과 인공지능 개발을 위한 대규모 컴퓨팅(계산 능력) 자원을 저렴하게 활용할 수 있다.
기존에는 기업이 직접 데이터 센터(서버실)에 서버, 네트워크 스토리지 등 인프라를 구축해서 운영하는 로컬 클라우드(On-Premise) 환경이었지만, 이제는 직접적으로 데이터 센터를 보유하지 않고도 자원을 활용할 수 있는 환경을 구축해주는 상용 클라우드(On-Demand) 환경을 이용해서 서버, 스토리지, 네트워크와 같은 하드웨어 인프라와 데이터베이스, 웹 어플 등 소프트웨어 영역까지 구매하거나 소유하지 않고도 이용할 수 있게 되었다. 기술적인 측면에서 클라우드 컴퓨팅은 물리적인 하드웨어 장비에서 독립적인 별도의 서버, 네트워크, 스토리지 영역을 생성할 수 있는 가상화 기술을 토대로 자원의 확대와 축소를 가능하게 해서 사용자가 요구하는 특정 자원만 제공할 수 있는 IT 환경으로 볼 수 있다.
2003년 Amazon이 클라우드를 통한 저장 공간과 연산 자원을 제공하는 S3, EC2를 시작하면서 Amazon AWS, Microsoft Azure, Google GCP(Goolge Cloud Platform), Alibaba Cloud, Tencent Cloud 등이 서비스를 제공하고 있다. 국내에서는 KT의 Ucloud, Naver의 Naver Cloud, SK의 CloudZ가 있다.
클라우드의 특징
▪ 접속 용이성 : 사용자는 시간과 장소와 무관하게 인터넷으로 표준화된 API 호출을 통해서 클라우드에 접속할 수 있다.
=>API(Application Programming Interface)는 서비스나 특정 응용 프로그램의 기능을 원격에서 호출해서 사용할 수 있게 해주는 인터페이스 프로그램을 말한다.
▪ 유연성 : 갑작스런 이용자 수의 변화에 신속하고 유연하게 대응할 수 있다.
▪ 주문형 : 클라우드 관리포털(CMP: Cloud Management Portal)을 통해서 직접 자원을 생성, 삭제 등을 손쉽게 처리할 수 있다. CI/CD가 용이해졌다.
▪ 사용량 기반 과금 : 서비스 사용량에 대해서만 비용을 지불하는 체제이다.
클라우드의 장단점
▪ 장점 : 비용절감, 완성형 서비스 활용으로 인한 시간절약, 생산성 향상, 자원의 유연성 확보 등이 있고
▪ 단점 : 보안상 취약, 가상화 인프라의 취약, 자원 공유로 인한 취약, 자원 집중화로 인한 취약, 장애발생에 대한 BlackBox(클라우드 서비스 제공자가 책임지는 부분) 문제 등이 있다.
클라우드의 유형
클라우드에는 다양한 유형이 있다.
배치 모델
자원(서버, 스토리지, 네트워크 등)이 어디에 위치하고, 클라우드 자원을 누가 사용하는지에 따른 분류로 배치모델에는
▪ 퍼블릭 클라우드 : 클라우드 제공자가 소유한 자원에 누구나 언제 어디서나 접속 가능한 형태, 보안 수준이 낮음, 대부분 상용 AWS, Zaure, GCP 등
▪ 프라이빗 클라우드 : 개별적이고 독립적인 기업이나 단체가 소유하는 자원을 허가된 사용자만이 언제 어디서나 접속 가능한 형태, 기업이나 공공기관, 온 프레미스와 퍼블릭의 중간 형태, 조직별 보안 설정가능, G-Cloud(정부)
▪ 하이브리드 클라우드 : 퍼블릭과 프라이빗을 결합해서 표준화된 인터페이스로 상호 서비스를 제공하는 형태, 핵심은 프라이빗으로 두고, 비핵심은 퍼블릭으로 두는 형태 가 있다.
▪ 멀티 클라우드 : 다수의 퍼블릭 클라우드를 기반으로 각 서비스의 특징을 이용해서 구축하는 형태이다.
서비스 모델
사용자에 제공되는 클라우드 서비스 종류에 따라서 단순 인프라 사용인지 복합 미들웨어나 소프트웨어 사용인지에 따른 분류로 기본적인 서비스에는
▪ IaaS : 인프라만 사용하는 서비스로 클라우드를 이용해서 네크워크와 서버에 미들웨어, 소프트웨어를 설치해서 사용, AWS의 EC2, EBS 등
▪ PaaS : 클라우드의 미들웨어를 이용해서 소프트웨어 개발 환경을 구축해서 개발에 집중, WEB(정적인 컨텐츠 제공), WAS(Web Application Server: 동적인 컨텐츠 제공), AWS의 RDS(Relational Database Server)),
▪ SaaS : 클라우드에 구성된 소프트웨어 이용, MS의 Office 365가 있다.
모델에 다른 비용, 관리 등으로
▶ IaaS > PaaS > SaaS로 갈수록 사용자 관리가 줄고, 보안이 좋아지고, 비용은 증가
▶ SaaS > PaaS > IaaS로 갈수록 사용자 관리가 늘고, 사용자 의도대로 보안 설정, 비용 감소
클라우드 보안
기업에서는 클라우드 도입으로 비용절감과 민첩성 등으로 호기심은 있지만 기업이 직접 관리하는 수준의 보안을 클라우드에도 적용할 수 있는지에 대한 고민으로 도입을 망설이고 있다. 클라우드 서비스는 가상화 기술을 이용해서 IT 인프라를 공유하는 기술을 사용하지만 그 위에서 동작되는 미들웨어(WEB, WAS)나 어플(홈 페이지, 모바일 앱 등)들은 기존의 환경과 동일해서 클라우드에서의 보안은 온 프레미스 환경에서의 보안 위협과 취약영역이 동일하다.
=>일반적으로 온 프레미스를 단독주택, 클라우드를 호텔로 비유한다.
▪ 관리적 보안영역 : 클라우드 제공자가 배포하는 서비스와 기능이 기업의 상황과 다를 수 있어서 완전히 그대로 적용하기에는 무리가 있다.
▪ 기술적 보안영역 : 인터넷 환경을 통해서 기본적인 인프라가 제공되기 때문에 정보유출과 해킹 공격의 위험이 있을 수 있다. 클라우드 환경을 모니터링하는 기법과 최대한 통제권을 기업이 가지기 위한 투자가 필요할 수 있다.
▪ 물리적 보안영역 : 이는 전적으로 클라우드 서비스 제공자가 가지고 있다. 사용자와 클라우드 제공자는 SLA(Service Level Agreement)를 통해서 서비스 제공자가 제공하는 데이터센터의 물리적인 보안과 서비스의 가용성을 보장받는다.
클라우드 보안의 특징
다음처럼 클라우드만의 보안적 특징을 알아보자.
▪ 클라우드에서의 자원 : MultiTenancy(여러 사용자들이 함께 공유하는 형태)이기 때문에 가상화 기술에 대한 취약점, 물리적인 인프라 설정, 다른 사용자와의 논리적인 분리에서 취약점이 있을 때 보안 위협이 생기게 된다. 국제 클라우드 보안협회 CSA(Cloud Security Alliance)가 자율적으로 구성되어서 클라우드 보안 위협을 공유하고 있다. 여기서의 내용을 보면 데이터 유출, 불충분한 ID, 자격증명 및 접근관리, 안전하지 않는 인터페이스와 API, 시스템 취약점, 계정 도용, 악의적인 내부자, APT(Advanced Persistent Threats), 데이터 손실, 불충분한 실사, 클라우드 서비스 남용과 악의적인 사용, DoS 공격, 공유기술의 취약점 등이 존재한다고 밝혔다. 최근에는 CSA STAR와 같이 보안 인증 제도를 취득한 CSP(Cloud Service Provider)에 대해서 클라우드 서비스 제공을 제도적으로 허용하고 있다
▪ 클라우드 보안 사고 : 클라우드 서비스 제공자의 관리 실수, 시스템 자체 오류, 천재지변 등으로 사고가 발생할 수 있다.
▪ 클라우드에서의 해킹 : 가상화 기술과 사용자가 호출하는 API에서 해킹이 발생될 수 있는 데 클라우드는 여러 사용자가 공유하는 가상공간이기 때문에 자원의 공유를 위해서 각각을 가상영역으로 분리해주는 가상화 기술이 핵심인데 가상서버에서 벗어남, 호핑(hopping), 운영체제/소프트웨어의 이미지 변조, 하이퍼바이저 기반 루트킷 등의 취약점이 있다고 보고되고 있다. 만일 하이퍼바이저(하나의 물리적 서버에 여러 개의 가상 서버를 구동하는 가상화 엔진으로 Linux KVM, MS Hyper-V, VMware vSphere /ESXi 등)에 대한 접근제어나 네트워크 접근 허용으로 인해서 해킹이 성공되면 해당 하이퍼바이저가 관리하는 모든 서버와 이를 이용하는 모든 사용자가 해킹당할 수 있다.
보통 온 프레미스에서는 홈페이지와 같은 웹 서버만 외부에서 접속하게 하고 중요한 정보를 저장하는 데이터베이스나 스토리지는 내부에 두고 접근제어 설정이나 방화벽으로 막아 두지만 클라우드에서는 설정이 수평적이어서 외부에서 인터넷으로 모두 접근할 수 있기 때문에 부적절한 권한 설정이나 구성으로 민감한 정보가 유출될 수 있다. 미국의 Gartner에 따르면 클라우드 환경에서 발생하는 보안사고의 95%는 클라우드 사용자의 보안설정 오류나 관리부족으로 인해 발생된다고 보고한다.
하지만 클라우드의 보안 사고에서는 서비스 제공자의 과실인지 사용자의 과실인지를 증명하는 책임증명의 어려움이 있고, 또한 서비스 제공자의 물리적인 서비스 중단에 따른 문제도 있을 수 있다. 이를 위해서 핵심을 오프라인에 백업해두거나 자체적인 보안 솔루션을 통한 모니터링 체계가 있어야 한다. 기업이 전적으로 클라우드 사업자를 신뢰해서는 안 된다는 의미이기도 하다.
클라우드 보안 관리 기준
미국에서는 보안성 인증단계로 NIST 800-53 보안통제 기본 항목을 기반으로 FISMA (Federal Information Security Management Act)에 따라 표준 요구사항에 접합 여부를 심사하고 인증제품/서비스 도입 단계에서는 인간 클라우드 제품과 서비스 도입에 따른 보안성 검토를 수행해서 FedRAMP 인증이 있는 경우만 인증심사를 받게 한다.
유럽에서는 ENISA(European Network and Information Security Agency)라는 조직에서 클라우드 컴퓨팅의 위협요소 4가지를 35개 항목으로 만들어서 평가하고 있다.
일본은 ASPIC이 있고, 중국에서도 작업이 이뤄지고 있다. 국내에서도 클라우드 컴퓨팅법이 2015년에 발표되었고 2016년에는 한국 인터넷 진흥원(KISA) 주도로 클라우드 보안 인증제도를 만들었다.
클라우드 보안에 대한 비 영리단체인 CSA(Cloud Security Alliance)에서는 2010년 보안 가이드 라인과 클라우드 고객이 CSP의 전반적인 보안 위협을 평가할 수 있는 도구로 CSA- CCM(Could Controls Matrix)를 정기적으로 배포하고 있다.
=>CSA STAR는 CSA GRC 스택의 두 가지 구성요소를 가지고 있는데
▪ CCM(Cloud Controls Matrix) : 클라우드 고객이 CSP 의 전반적인 보안 위협을 평가하는데 활용하는 16개 영역의 보안 프레임
▪ CIAQ(Consensus Assessments Initiative Questionnaire) : 고객 또는 클라우드 감사자가 CSA 모범 사례를 준수하는지 평가하기 위해 CSP에 질문할 수 있는 CCM 기반의 140개 질문서이다.
=>CSA STAR는 수준1(CSP의 STAR 자체평가), 수준2(제3의 독립 기관평가 인증), 그리고 수준3(지속적인 모니터링을 기반)으로 인증하는 체계이다.
클라우드 보안 설계
기존의 시스템과 다른 클라우드 환경에서의 기존의 보안 원칙을 유지, 적용하고자 할 때 사전에 클라우드 보안 설계를 신중히 해두어야 한다. 클라우드의 보안 설계는 일관된 보안 정책의 수립과 운영, 책임 공유모델의 이해와 통제력 회복, 그리고 보안 수준에 맞는 업무 서비스 클라우드화가 필요하다.
클라우드 보안은 말 그대로 사용자가 클라우드 환경에서 생성한 자원이 안전하도록 정보 시스템을 구축하고, IT 서비스의 지속적 활용을 제공하기 위한 방법으로 외부의 악의적인 위협과 내부의 중요 정보 유출로부터 시스템을 지키기 위해서, 보안 대상과 보안 기술, 보안 서비스 등을 검토하는 일이다.
클라우드에서의 보안은 온 프레미스에서의 보안과 다르기 때문에 전혀 예상하지 않았던 설계를 해야 하는 곳, 집중해서 설계하지 못했던 곳, 설계를 신경 쓰지 않아도 되는 곳 등이 있을 수 있다. 클라우드 환경의 주요 속성은 특정 자원에 대해서 다양한 공유자가 존재하는 멀티테넌시(multi-tenancy), 인터넷으로의 손쉬운 공유 자원에 대한 접근이 가능한 접근성(accessibility), 그리고 자원의 변동과 빠른 생성/삭제 등에 대응하는 유연한 탄력성(elasticity)으로 말할 수 있다. 이것들을 위해서는 지속적인 모니터링과 자동화 기반의 보안 설계와 보안 점검이 필요하다.
기타 클라우드에서의 특징으로
식별 : 클라우드에 접속을 요청하는 주체(사용자나 서버)가 스스로를 증명하기 위해서 누구인지 식별 가능(사용자 ID, 로그인 ID, 계정 번호, 이메일 주소 등)한 입력활동을 말하고
인증 : 식별을 통한 사용자 정보 외에 본인을 증명할 수 있는 정보(계정 비번, PIN, Token, Smart Card, 생체인식 등)를 입력해서 허가된 사용자인지를 확인하는 활동을 말하며
인가 : 인증된 사용자에게 필요한 행위를 수행할 수 있도록 권한을 부여하는 활동으로 주체는 리소소, 자원에 접근 및 필요한 행위를 할 수 있다.
로깅 : 어플에 접속/행위 로그, 데이터 액세스 로그, 네트워크 통신 로그, 시스템 이벤트 로그, 관리자 활동 로그 등 기록을 전자문서로 기록하는 행위를 말한다.
모니터링 : 시스템, 네트워크, 데이터, 사용자 등이 시스템에서 수행한 행위에 대해서 이상 징후 분석을 수행하고 실시간으로 수집된 자원의 변경이나 현황정보 등을 대시보드로 관리하는 활동이다.
감사(audit) : 감사로그, 사용자접속 로그 등 로그파일이나 활동 정보를 검토해서 보안 기준에 따라 계정과 권한 관리 여부를 확인하고 위험요소(데이터 유출, 외부 해킹 시도 등)을 관리하는 활동이다.
책임 추적성 : 클라우드 보안에서의 특수한 경우로 클라우드에서는 외부에서의 악의적인 자원 변경, 내부의 중요 데이터 유출, 허가되지 않은 사용자 접속 등으로 보안 위험이 커졌는데 이를 위해서 클라우드 자원 사용 전에 식별(identification), 인증(authentication), 인가(authorization)가 필요하고, 자원을 사용하는 도중에는 로깅(logging), 모니터링(monitoring)이 필요하며, 자원 사용 이후 에는 활동 이력에 대한 감사(auditing)가 있어야 책임 추적성을 만족시킬 수 있다.
참고로 클라우드 자원에 대한 다음 용어를 알아두자.
Scale up : 자원 사양을 증설
Scale down : 자원 사양을 감축
Scale out : 다수의 자원에서 자원 수를 감소함
Scale in : 기존 자원과 동일한 자원을 추가가 있다.
일반보안과 클라우드의 보안 차이
기존의 온 프레미스 환경이 사용자가 직접 소유한 단독주택(모든 초기 설계부터 색상, 배치, 위치 잡기, 가전 등을 모두 직접 결정하고 구매하는 상황)이라면 클라우드 환경은 호텔(이미 구축된 시설을 이용하면서 출입카드만 잘 관리하면 되는 상황)이 비유할 수 있다.
온 프레미스 보안 : 여기서는 정보 시스템에서의 설계는 보안 3요소인 기밀성, 무결성, 가용성 측면에서 검토하는데 일반적으로 데이터 암호화 기술을 사용한다. 기밀성에 대해서는 데이터 자체에 대해서는 파일 암호화, 데이터베이스 암호화 등을 이용하고 네트 워크에서는 통신 구간은 암호화 장비나 VPN, 전용선 등을 이용한다. 무결성은 데이터의 정확성과 일관성을 유지시키고 보증하는 것으로 접근성과 사용자 인증 등을 통한 접근통제와 단방향 암호화/복호화 등을 이용한다. 그리고 가용성은 재난, 화재 등의 외부 환경으로 인한 피해나 DDoS 공격, 해킹 등에 대응해서 핵심 서비스에 피해가 있을 때 빠르고 안전하게 복구하기 위해서 재난대응(DR: Disaster Recovery) 센터나 업무연속성(BCP: Business Continuity Planning)을 수립해서 운영하고 해킹 공격에 대비한 분산처리, 복제 등을 이용한다.
클라우드 보안 : 여기에서는 클라우드 서비스 제공자가 구축한 것을 이용하는 입장이기 때문에 기존의 보안 3요소만으로 보안을 충족시킬 수 없다. 사용자가 접근할 수 없는 클라우드의 블랙박스 영역(시스템이 어떤 물리적인 특성의 하드웨어이고, 어디에 위치하고 있는 지 등)이 있기 때문에다. 따라서 클라우드 보안에서는 기본 보안 3요소 외에 책임추적성이 포함되어 보안 4요소를 고려해 두어야 한다.
=>Grafana, Kibana 오픈소스를 이용한 PaaS에서 상위레벨에 대한 트래픽 정보를 실시간으로 확인하는 모니터링 도구 등을 추가하는 등의 작업이 있을 수 있다.
- 책임 공유원칙(shared responsibility)
클라우드에서는 책임 공유 원칙을 고려해 두어야 하는데 클라우드에서 발생되는 사고가 인프라 제공자와 사용자가 공유하는 자원에서 발생되기 때문이다. 어느 부분에서 책임을 져야하는지 판단하기 어려운 부분이어서 책임 추적성이 있어야 한다.
사용자는 어플 영역의 데이터, 사용자 인증 등의 보안 관리에 대해서만 책임지면 된다. 이들은 데이터 암호화와 같은 보안기술로 처리하면 된다.
=>IaaS에서는 데이터와 어플, OS 영역, PaaS에서는 데이터, 어플 영역, SaaS에서는 Data 영역을 담당하면 된다.
제공자는 어플 영역의 하위 플랫폼과 인프라 영역에 대한 전반적인 보안 관리를 책임지는데 서비스 모니터링, 어플 보안 패키, 시스켐 보안관리, 데이터 가시성 확보를 위한 인터페이스 등을 모두 책임져야 한다.
=>물리적인 데이터센터와 하드웨어 등에 대한 보안 책임, 가상화 기술을 이용한 인프라 관리 영역을 모두 담당해야 한다.
따라서 사용자는 클라우드 서비스 제공자의 보안수준을 점검하고 서비스 유형별로 책임 추적성 계획을 마련해야 하는데 '식별+인가+인증+로깅+모니터링+감사(책임 추적성)'를 필수적으로 설계해둘 필요가 있다.
- 온 프레미스와 클라우드 보안 모델
온 프레미스에서의 보안모델은 경계형/성벽형 보안 모델로써 외부에서의 침입을 막기 위해서 방화벽을 두고, 네트워크망을 분리해서 통신을 통제하는 모델로 진행된다.
=>보안이 여러 계층의 단계에 보안이 적용되는 수직적 개념이다.
하지만 클라우드에서의 보안모델은 공항형 보안 모델로써 물리적인 경계가 더 이상 의미가 없고, 여러 사용자가 멀티테넌시한 상태이므로 여기에 경계형 보안 모델을 구축하려면 비용이 많이 들고 제공자와 협의가 많을 수 있다. 그러므로 사용자 인증을 강화하고 클라우드에서 전송하는 데이터들에 대해서 책임 추적성을 위한 보안 강화 기능을 고려하는 모델이 되면 좋은데, 클라우드 환경의 접점에서는 인바운드와 아웃 바운드 양방향 검사를 수행하고 로킹과 모니터링으로 책임 추적성을 확보해두는 식으로 진행하면 된다.
=>클라우드에서의 보안은 입구와 출구에서만 외부 위협과 정보 유출을 통제하고 내부에서는 자유롭게 사용되게 하는 수평적 개념이다. 이런 면에서 직원들이 IT 부서를 통하지 않고 자유롭게 클라우드 서버나 스토리지에 접근해서 데이터를 조작할 수도 있기 때문에 IT 부서 직원들이 클라우드 어플이나 서비스에 대한 통제를 잃어가는 Shadow IT라는 용어도 생겨나고 있다.
최근에는 클라우드에 '제로 트러스트 보안' 모델이 적용되고 있는데 신규 서비스를 클라우드로 런칭하거나, 기존 시스템을 클라우드로 이전할 때 적용되는 모델로 시스템 보안, 데이터 보안, 어플 보안 등에서의 보안 사고가 일어날 수 있으므로 기존의 보안 설정을 신뢰하지 않고 내부와 외부에 모든 보안을 새롭게 인식하고 적용하는 모델이다.
=>항상 불신을 전제로 신원을 확인하고 모든 트래픽의 로깅과 감사, 모니터링을 통해서 관리하는 체계이다.
=>1차는 네트워크를 통한 접속 차단, 2차는 접근자를 양방향 식별, 3차는 접속하는 주체가 허락된 주체인지, 입력정보가 맞는지 확인하는 인증, 4차는 클라우드 리소스에 대한 객체 권한이 있는지 확인해서 접근을 허용하는 인가, 그리고 5차는 1~4차를 통과한 사용자는 자유롭게 클라우드 리소스를 사용하게 하는 접근으로 볼 수 있다.
IDG(Integration Data Group)의 클라우드 컴퓨팅에 따르면 기업별로 IT 과제와 항목 수가 다르기 때문에 클라우드 선택의 목적이 서로 상이할 수 있어서
SaaS는 ERP, CRM, 협업, 비즈니스 라인, 모바일 앱 분야로 일상적인 유지보수 업무를 축소 하고 생산성을 개선하기 위한 용도로 선택하고
PaaS는 개발과 테스트환경, 시스템 관리와 DevOps, business Intelligence, Data Analysis 분야에서 선택되어 자체 유지보수(업데이트나 취약점 관리 등)에 드는 시간과 비용을 줄이고 빠른 개발환경을 위한 용도로 선택되며
IaaS는 재난복구, 개발과 테스트, 테이터베이스, 스토리지, 백업, 파일 서버 등의 업무활용을 위해서 클라우드의 특징인 확장서과 유연성을 최대로 활용하는 용도로 선택된다고 보고 있다.
- 네트워크 보안 서비스
외부 인터넷 환경과 직접적으로 맞닿아 있는 클라우드에서 네트워크 영역은 보안에서 가장 중요한 부분이다. 불특정 다수에 의해 직접적으로 접근 또는 악의적인 공격이 가능한 진입점이기 때문이다. 더구나 물리적인 네트워크 장비가 가상화 기반으로 서비스하므로 일반 사용자가 더 쉽고 빠르게 보안 네트워크를 설정하고 적용 범위를 늘리거나 줄이기 쉬운 Shadow IT가 될 수 있기 때문이다. 따라서 오비ㅜ의 데이터 센터, 서버 자원, 모바일 기기, 개인용 컴퓨터, 허가되지 않은 사용자와 다른 클라우드 제공업체의 컴퓨팅 자원으로부터 조직의 클라우드 자원까지 전 영역에 걸쳐서 네트워크 구간의 보안을 고려해 두어야 한다.
가상 사설 클라우드(VPC: Virtual Private Cloud)
VPC는 클라우드 사용자가 직접 정의하는 가상의 사설 네트워크이다. 다른 가상 사설 네트워크와 논리적으로 구분되어 있기 때문에 상호 간에 호출이 불가한 독립된 네트워크이다. 먼저 VPC를 구축한 뒤 비즈니스 특성에 맞는 사설 IP_주소 범위를 설정해서 점차 커다란 네트워크로 확장해 나아갈 수 있다. VPC를 별도로 생성하지 않아도 가상 노드 하나를 생성하면 즉시 자동 VPC가 생성된다. 클라우드 자원들을 격리없이 하나의 네트워크로 구축하면 개발, 테스트, 배포 등이 하나의 네트워크에 있게 되므로 목적에 따라서 별도로 격리된 네트워크 환경인 다수의 VPC를 생성하면 서로 보안성을 높이고 네트워크별 특성에 따른 서버를 구축할 수도 있다. 예를 들어서 첫 번째 VPC로 10.10.0.0/16으로 운영환경으로 사용하고, 두 번째 VPC로 10.20.0.0/16으로 사전 운영환경으로 사용하고, 세 번째 VPC로 10.30.0.0/16으로 테스트 환경으로 사용하고, 마지막 네 번째 VPC로 10.40.0.0/24으로 개발환경으로 구축해둘 수 있다. 개발환경은 다른 환경에 비해서 적은 IP 대역을 사용했다. 이런 경우 운영, 사전 운영, 테스트, 개발환경이 서로에 대해서 독립적인 VPC로 구성되므로 완전한 격리환경으로 보안이 높아질 수 있다.
서브넷(subnet)
서브넷은 VPC에서 IP 주소 설정으로 원하는 자원이 사용하게 하는 작은 네트워크 망이다. 클라우드에서는 자원이 존재하는 지역(Region)에서 사용할 수 있는 영역(Available Zone)을 선택하여 CIDR(Classless Inter Domain Routing) 표기법으로 분할한다. 서울 리전의 특정 가용영역을 선택해서 서대문과 마포로 분할해서 클라우드를 배치하는 것과 유사한 개념이다. 클라우드 서비스에서 자원을 생성하려면 자원이 위치하는 가상 사설 클라우드(VPC)와 가용영역이 고정된 서브넷 선택이 필수이다. 서브넷을 설정하면 온프레미스에서처럼 기본적으로 같은 IP 주소 대역에서만 네트워크 통신이 가능하고 그 외의 대역과는 통신이 불가하다. 서브넷으로 분리하면 VPC 분리 때처럼 하나의 네트워크 망이 세분되어 분리된다. 자원의 Auto Scaling 등과 같이 사전에 계획된 노드들이 들어가게 설계하면 된다. 그리고 사설 네트워크는 사설 IP를 사용하고 인터넷이 불가하고 공개 네트워크는 공인 IP를 사용하고 도메인이 설정되며 인터넷이 가능하다.
서브넷 재배치라는 개념도 유용한데 공개 네트워크에 존재하는 자원은 인터넷으로 들어가므로 방화벽으로 보안설정을 할 수 있지만 위험하다고 생각되면 중요 데이터나 어플 소스는 사설 네트워크로 이동시켜 두면 외부에서 접근할 수 없기 때문에 보안이 좋아지게 된다. 이런 것을 서브넷 재배치로 부른다. 공개 서브넷에서는 로드밸런서를 통해서 허용된 트래픽만 사설 서브넷으로 가게 할 수 있다.
접근제어목록(ACL: Access Control List)
ACL은 외부 네트워크에서 사용자의 네트워클르 통과하는 경우 IP 주소와 포트번호, 프로토콜 등을 확인해서 네트워크 패킷의 통과를 허가/거부하는 목록인데 사용자 네트워크의 서브넷으로 향햐는 패킷에 대한 일종의 방화벽 역할을 한다. 여기에는 외부에서 클라우드 내부로 전달되는 인바운드(Inbound) 규칙과 클라우드 내에서 외부로 전달되는 아웃바운드(Outbound) 규칙 두 개가 있을 수 있다. 그리고 접근목록에는 거부목록(Black List)와 허용목록(White List) 두 개가 있는데 거부목록은 패킷의 출발 소스를 기준으로 거부되는 IP 대역이고, 허용목록은 소스 IP를 기준으로 허용되는 대상 IP 대역이다. Allow나 Deny 키워드로 조절한다.
위에서와 같이 공통된 자원에 ACL을 설정한다면 하위 사설 네트워크에 ACL을 적용하면 된다.
방화벽(Firewall)
방화벽은 VPC 내에서 허용된 IP와 포트만 통과시키는 보안 서비스이다. 기본적으로 클라우드 자원을 생성하기 전에 클라우드 자원을 보호하기 위해서 반화벽부터 생성해두어야 한다. 물론 나중에 클라우드 자원을 생성하면서 자동으로 방화벽이 생성되지만 수천-수만개의 자원을 관리하기 위해서는 클라우드 자원별로 적용할 것인지 클라우드 자원의 목적별 그룹으로 적용할 것인지 등 방화벽에 대한 사전 계획이 있어야 한다. 방화벽에도 외부에서 내부로 들어오는 인바운드 규칙과 내부에서 외부로 나가는 아웃바운드 규칙이 있다. 방화벽은 트래픽의 상태정보를 저장할 수 있는 Statfeul 속성을 가지므로 인바운드 규칙과 반대되게 아웃바운드 규칙을 만들 필요는 없다. 방화벽은 공개 서브넷과 사설 서브넷 하위에 존재한다. 가상머신 자원에 도달하는 패킷을 IP와 포트로 필터링하고자 하는 공개와 사설로 구분해서 생성하는 것이 좋다. 다수의 가상머신과 로드 밸런서, 컨테이너등의 자원을 원하는 대로 그룹짓거나, 자원을 모두 개별적으로 분리해서 방화벽을 적용할 수 있다. 보통 소스 IP, 목적지 IP, 포트는 사용하는 정보로만 주고, CIDR은 최소한으로 주며, Any IP, Any Port, Any Protocol 설정은 최소화 하고 적절한지 정기적으로 검토해야 한다. 즉, 방화벽은 서비스 단위로 축소하고 서비스별로 필요한 포트만 개방하는 것이 좋다.
가상 사설 네트워크(VPN: Virtual Private Network)
클라우드 환경과 외부 인터넷 환경의 자원 간에 데이터가 전송되거나 API 호출이 발생하면 인터페이스가 생기는데, 이런 경우 양쪽 네트워크 구간에 가상의 논리 적 네트워크 사설망을 구축하여 구간 암호화 통신과 외부에서 임의적 침입을 방지하는 가상의 전용 네트워크 망을 구성할 수 있는데 이를 VPN이라고 한다. 개별 네트워크 통신 초입 지점에 VPN G/W(게이트웨이)를 두고 상대방의 네트워크를 추가하여 고정된 네트워크 구간에서 안전한 사설망을 구축하면 된다.
온프레미스에서는 VPN을 위해서 물리적 장비와 케이블로 구축하지만 클라우드에서는 소프트웨어로 구성된 논리적인 네트워크 서비스와 준비된 3rd party 어플로 쉽게 구축할 수 있다. VPN 서비스로 통신을 수행할 때 양단 끝에 VPN Gateway를 적용하고 각 VPN G/W를 연결하는 VPN Connection 설정으로 해주면 된다. AWS에서는 VPN Connection 서비스를 통해서 중간에 중계 포인트를 추가적으로 설정하게 하고 사용자 네트워크의 대역폭과 트래픽 모니터링, 가용성 등을 추가해서 보안을 증진할 수도 있다.
IDS(Intrusion Detection System)/IPS(Intrusion Prevention System) 침입 탐지/예방
외부 인터넷 환경에서 클라우드까지 악의적인 목적으로 침입을 시도한다면 이에 대응하는 실시간 모니터링이 있어야 한다. 기존 온 프레미스에서는 IDS/IPS 장비를 구매해서 침입 탐지를 수행했지만 클라우드에서는 마켓 플레이스에서 소프트웨어 룰 기반, 이상 패턴, 지능혁 학습모델을 적용할 수 있는 서비스를 선택하게 해준다.
IDS/IPS는 정상 트래픽을 발견하면 백 엔드로 전송하고 비정상 트래픽이라고 판단되면 관리자에게 알람을 보낸다. 최근에는 디 러닝 알고리즘과 데이터 마이닝 기술이 발전함에 따라 위협 패킷의 패턴과 유추가 가능하여 지능적인 위협탐지를 수행하기도 한다.
DDoS(Distributed Denial of Service) 방지 서비스
악의적인 목적으로 공격자원을 분산 배치해서 특정 타겟으로 동시에 서비스 요청을 수행해서 서비스 불능인 상태로 만드는 DDoS에 대비해서 DDoS 방지 서비스를 통해서 상시 탐지를 수행시켜 둔다.
중계 서버(Bastion-host)
보안 향상을 위해서 클라우드 서비스에서 활용하는 자원 중에서 인터넷에 공개할 필요가 없는 외부에 공개되지 않은 서버 자원, 데이터베이스, 그리고 컨테이너 자원 등을 내부 사설 서브넷에 배치하는 것이 일반적이지만 내부 클라우드 자원을 대상으로 서비스 이관, 소프트웨어 설치, 어플 배포 등을 위한 서비스 설정이 필요하면 외부 접속이 불가피하다. 이런 경우 배스천 호스트(중계 서버)를 두면 해결될 수 있다. 즉, 네트워크 내부와 외부 사이의 연결을 중계해주는 서버나 호스트를 구성해주는 것이다. 내부의 보호할 서버 자원은 접근 가능한 경로를 최소화 해주는 방식으로 중계서버를 구성하는데 이를 ‘Jump Host로 자원에 접근한다’고 표현한다. 물론 외부망에 있는 중계서버에는 지정된 접속만 허용하는 명확한 출발지 IP(10.10.10.0 /24 대신 10.10.10.20/24식)로 설정해서 공개 서브넷에 위치한 중계 서버의 보안도 향상시키는 인바운드 규칙을 설정해주고, 중계서버에서 내부망으로는 터널링으로 연결해주는 방식이다. 사용자는 HTTP 프로토콜로 서비스를 제공하고, 관리자는 중계 서버로 터널링 된 웹/어플과 데이터베이스 서버에 모두 접속하게 된다.
중계 서버는 클라우드 서버 자원과 컨테이너 자원, 관리형 서비스 자원에도 동일하게 적용 가능한 자체적인 보안 기술이다. 중계서버의 접속이 필요한 경우에만 자원을 가동시키고 그 외 시간에는 자원을 중지해서 자원에 접속할 수 있는 범위를 최소화 해둔다. 이 중계서버는 별도의 보안 서비스가 아니라 중계서버의 역할을 하는 컴퓨팅 자원을 하나 추가하는 식으로 설정한다.
클라우드 서비스 자원 간의 내부 게이트웨이(Inner Gateway) 구성
클라우드 환경에서 대중 서비스나 멀티 클라우드 전략으로 특정 자원을 내/외부에 개방해서 공용으로 사용하는 경우가 있을 수 있는데 공용 IP을 가지고 있는 스토리지와 데이터베이스 자원은 외부로 노출되어 있고, 해당 저장소에 저장 작업을 수행하는 컴퓨팅 자원이 있다. 공요 IP를 호출해서 데이터를 저장 장소로 가는 것은 평문장 노출이나 위/변조가 있을 수 있어서 보안상 위험할 수 있기 때문에 클라우드 자원 간에 내부 게이트웨이를 설정해서 구간 암호화 통신을 구축하면 외부 노출에서 안전을 기할 수 있다. 내부 게이트웨이를 Private Link로도 부른다. IAM 서비스로 외부 사용자는 변경 없이 조회 가능하도록 접근권한을 제한하고 특정한 컴퓨팅 자원에만 스토리지와 데이터베이스로 데이터를 저장하게 조절해두면 더욱 보안이 좋아질 수 있다.
애플리케이션 보안 서비스
클라우드 환경에 구현하는 어플은 주로 웹 환경 서비스를 제공하지만 온 프레미스의 어플과 다른 특성을 가지고 있다. 클라우드의 SaaS 서비스를 이용해서 서비스를 제공하거나 기존의 웹 서버 없이 스토리지에 저장된 웸 페이지들을 함수로 호출하는 방식으로 구현될 수 있다. 어플 보안을 위해서는 외부에서 사용자가 접속하는 영역과 내부적으로 함수가 호출되는 영역, 소스 코드의 취약점 영역에 대한 보안 설정이 필요할 수 있다.
웹 방화벽(WAF: Web Application Firewall)
웹 방화벽은 어플로 전송되는 사용자 요청이 정상인지 판단해서 어플의 취약점 공격을 차단하는 기능을 하는데 기존 방화벽은 OSI L3 네트워크와 L4 전송층에서 작동되어 출발지 IP와 포트로만 제어하므로 응용층을 커버하지 못하기 때문에 WAF는 L7 응용층에서 작동된다. WAF는 외부로부터 전달된 사용자 요청 정보를 분석해서 악의적인 의도를 판단해준다. WAF 를 구성하는 경우 DDoS 방어나 Auto Scale과 같은 가용성 보장 방안도 함께 마련해 두는 것이 좋다. WAF에서 필터링 규칙, 보안 정책의 설정이 중요하지만 오류강 lt을 수 있기 때문에 테스트 기간이 필요하다. 보통 6개월 정도의 가용성 분석을 위한 학습 모드에서 공격 모니터링과 서비스 영향을 분석한 뒤 이후에 안정적으로 되면 운영 모드로 가게 된다.
기존 온 프레미스에서 WAF는 네트워크기반(NID)과 호스트기반(HID) 솔루션으로 나뉘지만 클라우드 환경에서는 빠르게 변경되는 가상 서버에 에이전트 프로그램을 설치하고 관리하기 어렵기 때문에 호스트 기반보다 네트워크 기반 WAF를 주로 사용한다.
간단히 말하면 WAF 서비스로 L7 레벨까지 필터링을 설정해서 VPC 외부에서 공격하는 트래픽을 분석해서 차단할 수 있다. 구성은 사용자단에서 공격을 파악하게 하는 방식과 클라우드의 로드 밸런서에 구성하는 두 가지 방법이 있다.
콘텐츠 보안 서비스
클라우드 환경에서 보관된 파일, 영상, 데이터 등을 아우르는 콘텐츠를 안전하게 보관하려면 기본적으로 암호화 키와 복호화 키가 필요하다. 기존에는 서버에서 직접 콘텐츠를 암/복호화 하거나 클라이언트에서 암호화 라이브러리를 사용해서 클라이언트를 대상으로 암/복호화를 수행했었지만 클라우드에서는 키를 쉽게 생성하고 관리하고 적용할 수 있다.
키관리 서비스(KMS: Key Management Service)
클라우드 환경에서 서버나 디스크의 내부 데이터를 암호화 하려는 경우 암/복호화 키가 필요한데 온 프레미스에서는 사용자가 수동으로 키 쌍(pair)을 만들었지만 클라우드 환경에서는 키 발급, 관리, 보안 위협에 대한 방어까지 키 관리 서비스를 제공한다. 키 관리 서비스를 이용하면 사용자는 암호화 키를 별도로 보관하지 않고 클라우드 내부 서비스로 키를 발급받아서 지속적인 데이터 암/복호화 수행에 사용할 수 있다. 데이터를 암호화할 때 키 관리 서비스에서 암호화 키를 제공받아서 암호화한 뒤 스토리지에 저장했다가, 다시 키 관리 서비스에서 복화화 키를 제공받아서 원하는 데이터를 복호화 한다. 키 관리 서비스는 암호화에 사용한 암호화 키를 보관하고 암호 모듈과 통신해서 암호화 키를 새롭게 변경하는 등의 암호화 키의 라이프사이클을 관리한다. 암호 모듈은 암호 알고리즘과 키 생성 함수로 구성된 하드웨어나 소프트웨어를 말한다. 키 관리 서비스는 암호화 키 정책(알고리즘, 키 길이, 사용 기간 등)에 따라 암호 모듈에 신규 암호화 키 생성을 요청하고 암호 모듈은 생성한 암호화 키를 다시 키 관리 서비스에 전달한다.
클라우드 키 관리 보안 모듈(HSM: Hardware Security Module)
KMS가 암호화 키의 라이프사이클을 관리하는 서비스라면 클라우드의 HSM은 암호화 키가 필요할 때, 별도의 전용장치로 암호화 키를 생성하고 저장하며 백업이나 복구를 제공하는 서비스로써 보안과 성능 향상, 그리고 관리의 효율성을 가져다 준다. 클라우드의 HSM은 미국의 FIPS(Federal Information Processing Standardization) 140-2를 취득한 모듈로써 암호화 키를 보관해주는 전용장비이다. 여기에 들어 있는 암호화 된 키를 공격자가 유출하려고 하면 스스로 암호화 키를 삭제한다. 이 FIPS에서 level1은 소프트웨어, level2는 암호화 모듈과 하드웨어 보안 적합성, level3은 제품의 무단 접근 시 중요 보안 변수 삭제, 그리고 level4는 물리적 보호가 어려운 경우를 고려한 모듈 평가 레벨이 있다. 대부분 클라우드 제공자는 FIPS 140-2 level3 인증을 받은 HSM을 제공하고 있다.
HSM은 자체적으로 암호화 키를 생성해서 사용하게 하므로 어플을 통해서 키를 관리하는 소프트웨어적인 방식보다 효율도 뛰어나다. 그리고 사용자를 위해서 하드웨어 브로비저닝, 소프트웨어 패키, 고가용성, 백업 등의 관리 작업을 자동화 하고 클라우드 HSM의 사용자를 생성해주고, 정책을 설정해서 접근제어를 수행해주기도 한다.
또한 어플 등이 데이터의 암호화를 요청하면 자동으로 부하를 분산시켜서 클라우드 HSM에 저장된 키를 클러스터 기능으로 다은 HSM으로 안전하게 복제시켜준다. 어플 대신 키 생성과 처리를 수행하기 때문에 전반적인 부하를 줄여준다.
그리고 KMS는 여러 클라우드 사용자들의 암호화 키를 사용하는 멀티테넌시 서비스라면, HSM은 중앙 집중식 키 관리를 해서 사용자는 자신의 클라우드 가상 네트워크에서 클라우드 HSM을 구축해서 독자적으로 사용하는 서비스이다.
글로벌 3사에서는 AWS의 AWS CloudHSM, Azure의 Dedicated HSM, GCP의 Cloud HSM 이름으로 서비스하고 있다.
클라우드 보안 서비스(SECaaS)
SECaaS는 보안 서비스를 제공하는 SaaS 형태의 클라우드로 볼 수 있다. 클라우드 환경과 솔루션을 투자하기 어려운 환경에서 서비스 형태로 조직에서 이용할 수 있게 해준다. SECaaS가 주목받는 이유는 가상화 기술을 사용하는 클라우드 환경에서는 클라우드 제공자가 관리하는 물리적인 환경에 장비를 추가하는 것이 불가능하고, 온 프레미스와의 연동 또한 제공자가 지원하는 범위로 국한되기 때문에 별도의 소프트웨어, 하드웨어 장비 등을 접목시키기에는 너무 많은 비용 투자와 제약이 있어서 비즈니스 요건에 맞는 보안 솔루션을 적용시키기 쉽지 않기 때문이다.
SECaaS는 클라우드 서비스의 장점처럼 사용한 만큼만 비용을 지불하며, 필요할 때 적용되는 On-Demand 방식으로 보안 수준을 큭대화하고 비용을 절감시키는 방법이다. 또한 서버의 보안 위협 요소와 법/정책 등에 대한 내용도 실시간으로 업데이트 되어서 전문 보안 인력 없이도 자동으로 보안 수준을 향상시킬 수 있다.
SECaaS와 CASB는 유사한 보안 기능을 제공하지만 개념, 목적, 장점에서 다른 곳이 있다. CASB는 클라우드 서비스와 사용자가 증가함에 따라서 다양해진 클라우드 서비스에 통합된 보안정책을 적용하는 것이고, SECaaS는 클라우드 서비스에서 제공하지 않는 추가적인 보안 기능을 서비스 형태로 이용하게 하는 방식이다.
보안 운영 아웃소싱(MSSP: Management Security Source Provider)
MSSP는 보안운영, 모니터링, 문제 해결 등 효율적인 보안관리를 수행하는 아웃소싱 서비스이다. MSSP는 클라우드 이전부터 전통적인 네트워크 보안 영역에 대한 서비스를 제공했고 점차 발전되고 있다. 주로 보안 컨설팅, 보안관제 기업에서 보안 운영 분야를 주도하고 있으면 최근에는 클라우드 보안 운영 서비스를 제공하는 형태로 확장되고 있다. 클라우드 보안 구성이 어렵거나 전문인력이 부족할 경우 MSSP에게 보안 관리를 아웃소싱 할 수 있다. 해킹 시굴이 고도화됨에 따라서 위험 관리와 어플의 취약점 모니터링, 컴플라이언스 준수를 위한 컨설팅 기능도 제공하고 있다.
클라우드 보안관제 서비스도 SECaaS처럼 클라우드 환경에서 보안관제 센터를 구성해서 멀티 클라우드와 기업의 온 사이트 시스템에 대한 관제를 엮어서 수행할 수도 있다. 특히 SECaaS에서 제공하는 보안 솔루션을 통합해서 운영서비스를 하기도 한다.