클라우드 보안 기업 고를 때 비용과 책임 확인하는 방법

얼마 전 작은 쇼핑몰의 접속 장애를 확인했는데, 공격보다 보안 규칙의 오탐이 먼저 눈에 들어왔다. 결제 요청이 막히고 있었지만 운영자는 차단 기록을 볼 권한이 없었다. 클라우드 보안 기업을 고를 때 기능 목록보다 먼저 확인할 것은 이런 상황에서 누가 기록을 보고, 누가 규칙을 바꾸며, 몇 분 안에 대응할 수 있는지다.

먼저 서버에서 지켜야 할 것을 적는다

같은 클라우드 서버를 써도 위험은 다르다. 회사 소개 사이트라면 관리자 계정과 백업이 우선일 수 있다. 회원 정보와 결제를 다루는 쇼핑몰이라면 관리자 로그인, 데이터베이스 접근, 결제 과정의 차단 오류까지 봐야 한다. 서버가 한 대인지, 외부에 공개된 관리 화면이 있는지, 장애가 나면 몇 시간까지 버틸 수 있는지도 적어두면 필요한 서비스의 범위가 좁아진다.

호스팅 업체가 데이터센터와 가상화 계층을 관리해도 고객 계정, 운영체제 설정, 애플리케이션과 데이터의 책임까지 모두 가져가는 것은 아니다. 책임 범위는 서비스 형태와 계약에 따라 달라진다. 클라우드 보안 연합의 통제 항목도 공급자와 이용자 사이의 담당 영역을 구분해 확인하도록 안내한다. 계약서에서는 ‘보안 제공’이라는 문구보다 계정 탈취, 잘못 열린 저장 공간, 백업 실패를 각각 누가 처리하는지 찾는 편이 낫다.

보안 기업의 역할을 구분한다

클라우드 보안 기업이라는 이름 아래 파는 서비스는 꽤 다르다. 웹 방화벽은 웹 요청을 검사하고 차단한다. 설정 점검 서비스는 과도한 권한이나 공개된 저장 공간을 찾아낸다. 관제 서비스는 경보를 확인하고 대응을 돕는다. 백업 서비스는 데이터를 복구할 수 있도록 보관한다. 한 업체가 여러 기능을 묶어 팔더라도 각 기능이 실제로 포함됐는지 확인해야 한다.

작은 사이트에서 가장 흔한 빈틈은 화려한 탐지 기능이 없는 것이 아니라 관리자 계정에 추가 인증이 없거나, 복구해 본 적 없는 백업만 쌓이는 것이다. 그런 상태라면 별도 보안 상품을 사기 전에 기본 계정 보호와 백업부터 고치는 게 순서다. 반대로 공개 서비스가 여러 개이고 배포가 잦다면 설정 변경을 계속 추적하는 도구가 운영 시간을 줄일 수 있다.

관제를 맡길 때는 ‘24시간 감시’의 뜻도 물어봐야 한다. 경보를 사람에게 전달하는 데서 끝나는지, 차단 규칙 변경까지 하는지, 야간 긴급 연락은 누구에게 가는지에 따라 서비스가 달라진다. 서버 운영자가 승인할 때까지 기다리는 구조라면 연락이 닿지 않는 밤의 대응 시간도 계산에 넣어야 한다.

요금은 방문자 수보다 과금 단위로 계산한다

방문자가 하루 1만 명이라고 해서 월 비용을 바로 추정할 수는 없다. 방문자 한 명이 만드는 요청 수, 자동 수집 프로그램의 접근량, 로그 보관 기간에 따라 청구액이 달라진다. 예를 들어 하루 페이지 조회 1만 회에 보안 서비스가 세는 요청이 조회당 평균 4건이라면 30일 기준 약 120만 건이다. 여기에 이미지 요청이나 봇 요청이 포함되는지는 업체의 과금 기준을 봐야 한다. 이 숫자는 견적을 읽기 위한 예시이지, 모든 사이트의 요청량은 아니다.

견적서에서는 기본료 다음 줄을 본다. 보호 대상 서버 수, 요청 초과분, 로그 저장량, 데이터 전송량, 관리 규칙 수, 긴급 대응 비용이 각각 붙을 수 있다. 처음에는 저렴해 보여도 공격으로 요청이 급증한 달에 초과 요금이 커질 수 있다. 요청량이 갑자기 늘 때 요금 상한을 둘 수 있는지, 차단된 요청도 과금되는지 확인하면 예산을 잡기 쉽다.

무료 기능이나 호스팅 기본 보안으로 충분한 구간도 있다. 서버 한 대에 공개 페이지가 대부분이고 운영자가 계정과 백업을 직접 관리할 수 있다면 유료 관제부터 붙일 이유는 약하다. 다만 비용이 낮다는 판단은 복구에 걸리는 시간까지 포함해야 한다. 하루치 주문 데이터가 사라지면 손실이 큰 곳은 같은 방문자 수라도 백업에 더 써야 한다.

계약 전에는 장애와 복구를 직접 확인한다

데모 화면보다 시험 상황이 빠르다. 정상적인 로그인과 결제 요청을 일부러 차단해 보고, 누가 차단 사유를 찾고 언제 해제하는지 기록한다. 탐지 알림에는 요청 시각, 대상, 적용된 규칙이 보여야 원인을 좁힐 수 있다. 미국 사이버보안·인프라보안국의 클라우드 보안 지침도 접근 기록과 서비스 기록의 수집, 중앙 보관을 강조한다. 기록을 볼 수 없다면 장애 때 보안 제품 자체를 의심하기가 어렵다.

백업은 ‘매일 수행’이라는 설명만으로 판단하지 않는다. 별도 위치에 사본이 있는지, 삭제나 랜섬웨어 피해 뒤에도 남는지, 실제 복원에 얼마나 걸리는지 시험한다. 마지막 백업 시점까지 잃어도 되는 데이터의 양과 서비스를 다시 열 때까지 허용할 시간을 적어 업체에 전달하면 답이 구체적으로 나온다. 예를 들어 주문 데이터는 1시간까지만 잃을 수 있고 서비스는 4시간 안에 재개해야 한다면, 백업 주기와 복원 절차가 그 조건을 만족해야 한다.

계약이 끝날 때 로그와 설정을 어떤 형식으로 받을 수 있는지 확인한다. 규칙을 다른 서비스로 옮길 수 없거나 보관된 기록을 내려받을 수 없다면 이전 비용이 생긴다. 저는 보안 기업을 비교할 때 탐지 항목의 개수보다 운영자가 장애를 설명하고 복구할 수 있는 자료를 주는지 오래 본다. 평소에는 차이가 작아 보여도 사고가 난 날에는 그 차이가 시간을 결정한다.