클라우드에서도 보안관제가 필요할까?

대답에 앞서 다른 질문을 던져보겠습니다.

클라우드에서 모니터링은 얼마나 중요할까요?

클라우드를 잘 구축해서 운영하는 게 중요한만큼 모니터링도 중요합니다.

사실 클라우드를 잘 구축해서 운영한다는 말과 모니터링을 잘 한다는 말은 같은 의미라고 해도 무방하겠죠.

이제 첫 질문으로 돌아가보겠습니다.

클라우드에서도 보안관제가 필요할까요?

앞서 모니터링이 중요하다는 대답을 기억한다면 이런 말도 맞는 말이라는 걸 어렵지 않게 알 수 있습니다.

'보안' 모니터링도 중요하죠.

보안 모니터링에 대응 프로세스가 더해지면 이게 곧 클라우드 보안관제가 됩니다.

그렇습니다.

클라우드에서도 보안관제는 필요하며 매우 중요한 모니터링 요소입니다.

그렇다면 정말 궁금한 질문에 대한 답을 찾아봅시다.

1. 기존 IDC 보안관제처럼 클라우드 보안관제를 할 수 있을까요?

할 수 있습니다.

이 질문을 스스로에게 먼저 해보신 분이리면 SECaaS라는 단어를 접해봤을 것입니다.

현재 몇몇 보안전문업체를 필두로 SECaaS를 통해 클라우드 보안관제 서비스는 제공되고 있죠.

2. 그렇다면 기존 IDC 보안관제에 클라우드 보안을 추가하는 게 맞는 방법을까요?

이 질문에 대한 답은 이 글을 읽는 여러분 스스로가 찾길 바랍니다.

굳이 저의 답을 말씀드리자면 '아니다'입니다.

이유는 다음과 같습니다.

1) On-Prem에 적용된 보안모델과 Cloud에 적용된 보안모델은 같지 않습니다.

정확히는 다르다고 해야겠네요.

보안에 대한 사상은 On-Prem이나 Cloud나 사실 크게 다르지 않습니다.

접근통제, 취약점 점검, 침해사고 대응 등

하지만 적용하는 방식에는 차이가 있습니다.

바로 이 차이때문에 On-Prem 보안관제와 Cloud 보안관제에 차이를 만듭니다.

① 물리적인 환경을 기반으로 IPS, DDoS, F/W, DLP, KMS 등의 시스템을 보안관제 하는 것과

② 가상의 환경을 기반으로 구성된 보안시스템 혹은 솔루션을 보안관제 하는 게 같을 수가 없습니다.

AWS를 예로 들자면 F/W의 역할을 하는 서비스는 NACL과 Security Group이 있습니다.

F/W은 장비가 제공한 형태의 로그를 분석하면 됩니다.

F/W 제조사에 따라 비슷하지만 조금씩 다른 로그를 생성하죠.

NACL과 Security Group은 Cloud Trail 내지는 Flow Logs를 분석해야 합니다.

1차적으로 분석 대상이 다르다는 것을 알 수 있습니다.

이건 분석의 관점이 달라진다는 것을 의미합니다.

같은 목적으로 보아야 하지만 형태소가 다른 것이죠.

조금 더 확장해서 얘기하자면 기존의 보안솔루션 로그와 AWS Service 로그는 다르게 취급되어야 한다는 뜻입니다.

2) 아직까지는 클라우드 보안관제 업체의 역량이 높지 않습니다.

보안관제 서비스를 받는 목적은 사용자 입장에서 리스크를 회피하기 위한 좋은 방법이기 때문입니다.

물론 보안에 대한 전문성과 인력, 인프라를 활용한다는 측면도 있을 것입니다.

그래서 계약 혹은 SLA 등에 협의된 만큼의 권한을 보안관제 업체에 위임하게 되죠.

클라우드에서 보안관제는 어떨까?

물론 기존 보안관제 모델로도 가능할 겁니다.

하지만 위에 언급했던 것처럼 고객이 사용하는 AWS 서비스를 직접 통제할 수 있어야 합니다.

단순히 F/W 정책변경하는 것과 같은 수준으로 볼 수 없습니다.

여기서 또다른 문제가 발생합니다.

고객의 비즈니스를 제대로 이해하지 못한 관제업체가 AWS에 대한 이해도 역시 높지 않은 상태에서 이런 업무를 해야 한다는 것입니다.

개인적으로 보안관제 서비스를 제공하는 업체와 이야기를 해봐도 AWS에 대한 수준이 낮다는 것을 스스로도 인지하고 있으며 이미 서비스를 사용하고 있는 고객들의 입장도 크게 다르지 않다는 것을 직접 확인할 수 있었습니다.

이는 보안업체들에게는 미안하지만 고객의 입장에서는 클라우드 보안관제가 또 다른 리스크로 작용할 수 있다는 뜻이기도 합니다.

3) 클라우드는 사용자 스스로 자생할 수 있어야 합니다.

이전 포스팅에서 정리했던 Shared Responsibility를 생각해보세요.

이론적으로는 매우 좋은 모델이지만 실무적으로는 미묘한 교집합이 발생할 수 있음을 언급했습니다.

SECaaS를 사용하면 고객과 서비스 제공업체는 또 다른 Shared Responsibility를 형성합니다.

결국 고객은 클라우드 제공자와 클라우드 보안업체 두 곳과의 Shared Responsibility를 가져야 하죠.

굳이 그럴 필요가 있을까요?

클라우드 서비스 고객은 필연적으로 DevOps를 고민합니다.

DevOps의 핵심은 자동화죠.

이 부분은 누군가의 도움을 받을 수 있겠지만 결국은 사용자의 것이며 사용자 스스로가 운영/관리해야합니다.

DevOps가 하나의 개발방법론이 아닌 전사의 문화라는 것을 이해하시다면 아마 납득이 가실 겁니다.

클라우드 보안관제 역시 크게 다르지 않습니다.

구축하는 과정에 도움을 받을 수는 있지만 보안 모니터링과 사고대응은 사용자가 해야 합니다.

클라우드 보안관제에 대해 정답은 없습니다.

여러분의 결정이 곧 정답이겠지요.

저는 기존 보안모델과 다른 방향으로 접근한 것 뿐입니다.

의견 있으시면 언제든지 댓글달아주세요.