클라우드 환경이 한 차례 더 발전하고 있다. 그러면서 클라우드 네이티브 환경이라는 것이 서서히 자리를 잡아가는 중이다. 그에 따라 보안도 진화해야 하는 단계에 들어섰다. 클라우드 보안과 클라우드 네이티브 보안의 차이점을 간략하게 짚어 보았다.
[보안뉴스 문정후 기자] 클라우드 보안을 지탱하는 두 개의 기둥이 있다. 하나는 가시성이고, 다른 하나는 대응력이다. 이상적으로 이 두 가지가 안정적으로 발휘되면 위협이나 공격이 시작되기도 전에 막아 피해를 0으로 만드는 게 가능하다. 클라우드가 처음 개발된 이래로 이 두 가지의 중요성은 한 번도 변한 적이 없다.
하지만 최근 몇 년 동안 이 두 가지 - 즉, 클라우드 보안 - 를 강화해주는 도구와 프로세스들은 크게 바뀌었다. 기업들이 꾸준히 단순한 클라우드에서 보다 복잡하고 분산화 된 클라우드 환경으로 옮겨가면서 클라우드 보안을 강화하려는 전략도 진화하는 중이다. 5~10년 전에 통용됐던 보안 전략은 현대화 된 클라우드 구조에서는 효과적이지 않다.
지금은 클라우드 운영 전략과 아키텍처를 구성할 때 클라우드 보안을 생각하는 게 필수다. 필자는 이번 글을 통해 클라우드 보안을 도입한다는 게 어떤 의미인지를 구체적으로 풀어보고자 하며, 그 과정을 통해 현 시점 베스트 프랙티스가 무엇인지 짚으려 한다.
클라우드 보안에서 클라우드 네이티브 보안
기존의 클라우드 컴퓨팅 환경과 클라우드 네이티브 컴퓨팅 환경에는 어마어마한 차이가 존재한다. 그렇기 때문에 기존 클라우드 보안과 클라우드 네이티브 보안도 대단히 다를 수밖에 없다.
기존 클라우드 환경에서는 클라우드 방화벽을 설정하고 보안 그룹을 정의하는 것으로 워크로드를 보호했다. 또한 에이전트를 가상기계에 심고, 이 에이전트가 로그와 각종 메트릭스를 수집하는 것으로 가시성을 확보했다. 클라우드 서비스 업체가 제공하는 보안 도구들을 통해 이러한 데이터를 해석하고 위협을 물리칠 수 있었다. 여기에 더해 주기적인 클라우드 설정 점검 및 감사 활동을 추가해 구멍을 보다 완벽히 막았다.
이러한 방법론이나 도구 모두 지금도 중요하고 활용성이 높다. 클라우드 네이티브 환경에서도 마찬가지다. 하지만 이런 것들만으로는 충분하지가 않다. 클라우드에서 발생하는 새로운 보안 위협들을 전부 다루려면 새로운 방법과 도구들이 나타나야 한다. 클라우드 환경에서는 됐는데, 클라우드 네이티브 환경에서 되지 않는 것들을 예로 들면 다음과 같다.
1) IaaS 너머의 위험 요인 파악하기 : 클라우드 네이티브 공격은 전통적 의미의 인프라나 애플리케이션만을 통해서만 들어오지 않는다. 예를 들어 큐버네티스 RBAC 설정에서 사용자의 실수가 있을 때 보안 위협이 되는 건 당연하다. 하지만 가상기계나 애플리케이션만을 모니터링 한다고 해서 모든 위험 시나리오가 다 방어되지는 않는다.
2) 항상 변하는 설정 내용 관리하기 : 현대화 된 클라우드 네이티브 환경에는 수많은 사용자와 워크로드들이 존재한다. 때문에 접근 제어와 관련된 규칙들이 수만 가지이고, 여기에 따라 어떤 사용자가 어떤 워크로드로 어떤 일을 할 수 있는지가 결정된다. 문제는 이러한 규칙이 한 번 정해지면 일정 기간 지속되는 게 아니라, 계속해서 변한다는 것이다. 아무리 주기적으로 감사를 한다고 해도 이렇게까지 ‘항시’ 변하는 건 기존 보안 도구로 다 막을 수가 없다.
3) 멀티클라우드 보안 : 클라우드 업체들이 제공하는 기존 보안 도구들로는 다른 업체의 클라우드 환경을 보호할 수 없다. 기업들이 대다수 차용하는 클라우드 운영 전략이 ‘멀티클라우드’라는 걸 감안하면 이는 치명적인 결함이 된다.
4) 근본적인 문제의 해결 : 리스크가 존재한다는 걸 아는 것만으로는 빠르고 정확하게 해결할 수 없다. 즉 안다는 것과 해결한다는 건 상호관련성이 대단히 낮을 수 있다는 것이다. 이는 특히 클라우드 네이티브 아키텍처에서는 더 그렇다. 그래서 한 애플리케이션에서 코드 주입 취약점을 찾아냈다고 하더라도, 이 취약점의 근원이 되는 마이크로서비스나 코드 커밋을 곧바로 파악해내지 못할 수도 있다.
그 외에도 여러 가지 이유로 기존 클라우드 보안 도구나 전략들로는 현대의 클라우드 네이티브 환경을 온전히 보호할 수가 없게 된다. 클라우드 네이티브 워크로드를 온전히 보호하려면 보안 도구들과 프로세스들을 확장시켜야만 한다. 몇 가지 베스트 프랙티스를 소개하자면 다음과 같다.
클라우드 네이티브 보안 베스트 프랙티스
1) 보안을 개발 파이프라인 안에 포함시켜야 한다 : 클라우드 네이티브 환경에서는 일단 애플리케이션을 출시부터 하고 리스크를 나중에 찾는 게 그리 효율적인 프로세스가 되지 못한다. 오히려 CI/CD 파이프라인에 보안 점검 프로세스를 고정적으로 포함시키는 등의 방법을 통해 보안을 시작 단계에서부터 넣는 것이 좋다. 최초의 소스코드부터, 생산의 각 단계마다 보안 점검을 실시하는 게 가장 이상적이다.
2) 에이전트만으로는 불충분하다 : 에이전트 기반의 보안은 간단한 클라우드 워크로드를 보호하는 데에 있어 충분하다. 하지만 보안을 위한 가시성을 확보하는 데에 있어서 에이전트는 그리 좋은 해결책이 되지 않는다. 보안을 위한 가시성은 코드 자체에 이미 내재되어 있어야 한다. 즉 애플리케이션들이 필요한 데이터를 알아서 담당자들에게 노출하도록 만들어져야 한다는 것이다. 에이전트라는 중간자를 둘 이유가 없도록 하는 게 효율적이며 안전하며 온전하다.
3) 다계층 보안을 도입하라 : 클라우드 네이티브 환경은 인프라, 애플리케이션, 오케스트레이션, 물리 네트워크, 가상 네트워크 등 많은 층위로 구성되어 있다. 그리고 이것을 다 통합해 보호하는 방법이 아니라 그 층위 하나하나를 보호하는 방안을 마련해야 한다. 그러니 큐버네티스 컨테이너를 안전하게 설정하기 위한 도구도 필요하고, 컨테이너 이미지 내부를 보호할 도구도 필요하며, 동시에 아이덴티티 보호 장치와 클라우드 보호 장치도 필요하다는 것이다. 다양한 층위에서 공격이 시작되는 걸 염두에 두자.
4) 지속적인 감사, 실시간 감사가 중요하다 : 클라우드 환경 설정에 대한 주기적인 평가와 감사는 아무리 부지런히 진행해도 실시간으로 진행하는 것보다 효과적일 수 없다. 지속적으로 모든 설정 내용을 모니터링할 수 있는 도구들이 클라우드 네이티브 환경에서는 필요하다. 당연한 이야기지만 이런 도구들은 리스크 요인들이 나타날 때 곧바로 사용자/관리자/담당자에게 알려줄 수 있어야 한다.
5) 어느 정도의 복구는 자동화로 해결된다 : 위협 요소가 발견되었을 때 해당 네트워크 영역이나 시스템을 단숨에 분리 및 고립시켜야 하는데, 이 때 가능하다면 자동화 도구를 사용하는 것을 추천한다. 아무리 사람이 빠르게 대응을 한다고 해도, 자동으로 설정된 도구처럼 빠릿하게 움직일 수는 없다. 피해에 대한 대처가 빠르면 빠를수록 피해가 줄어든다. 클라우드 네이티브 환경에서 피해의 확산을 재빠르게 막는 건 필수 덕목이다.
글 : 제프 콜린스(Jeff Collins), 솔루션 매니저, 2nd Watch
[국제부 문정후 기자(globoan@boannews.com)]
[보안뉴스 문정후 기자] 클라우드 보안을 지탱하는 두 개의 기둥이 있다. 하나는 가시성이고, 다른 하나는 대응력이다. 이상적으로 이 두 가지가 안정적으로 발휘되면 위협이나 공격이 시작되기도 전에 막아 피해를 0으로 만드는 게 가능하다. 클라우드가 처음 개발된 이래로 이 두 가지의 중요성은 한 번도 변한 적이 없다.
[이미지 = utoimage]
하지만 최근 몇 년 동안 이 두 가지 - 즉, 클라우드 보안 - 를 강화해주는 도구와 프로세스들은 크게 바뀌었다. 기업들이 꾸준히 단순한 클라우드에서 보다 복잡하고 분산화 된 클라우드 환경으로 옮겨가면서 클라우드 보안을 강화하려는 전략도 진화하는 중이다. 5~10년 전에 통용됐던 보안 전략은 현대화 된 클라우드 구조에서는 효과적이지 않다.
지금은 클라우드 운영 전략과 아키텍처를 구성할 때 클라우드 보안을 생각하는 게 필수다. 필자는 이번 글을 통해 클라우드 보안을 도입한다는 게 어떤 의미인지를 구체적으로 풀어보고자 하며, 그 과정을 통해 현 시점 베스트 프랙티스가 무엇인지 짚으려 한다.
클라우드 보안에서 클라우드 네이티브 보안
기존의 클라우드 컴퓨팅 환경과 클라우드 네이티브 컴퓨팅 환경에는 어마어마한 차이가 존재한다. 그렇기 때문에 기존 클라우드 보안과 클라우드 네이티브 보안도 대단히 다를 수밖에 없다.
기존 클라우드 환경에서는 클라우드 방화벽을 설정하고 보안 그룹을 정의하는 것으로 워크로드를 보호했다. 또한 에이전트를 가상기계에 심고, 이 에이전트가 로그와 각종 메트릭스를 수집하는 것으로 가시성을 확보했다. 클라우드 서비스 업체가 제공하는 보안 도구들을 통해 이러한 데이터를 해석하고 위협을 물리칠 수 있었다. 여기에 더해 주기적인 클라우드 설정 점검 및 감사 활동을 추가해 구멍을 보다 완벽히 막았다.
이러한 방법론이나 도구 모두 지금도 중요하고 활용성이 높다. 클라우드 네이티브 환경에서도 마찬가지다. 하지만 이런 것들만으로는 충분하지가 않다. 클라우드에서 발생하는 새로운 보안 위협들을 전부 다루려면 새로운 방법과 도구들이 나타나야 한다. 클라우드 환경에서는 됐는데, 클라우드 네이티브 환경에서 되지 않는 것들을 예로 들면 다음과 같다.
1) IaaS 너머의 위험 요인 파악하기 : 클라우드 네이티브 공격은 전통적 의미의 인프라나 애플리케이션만을 통해서만 들어오지 않는다. 예를 들어 큐버네티스 RBAC 설정에서 사용자의 실수가 있을 때 보안 위협이 되는 건 당연하다. 하지만 가상기계나 애플리케이션만을 모니터링 한다고 해서 모든 위험 시나리오가 다 방어되지는 않는다.
2) 항상 변하는 설정 내용 관리하기 : 현대화 된 클라우드 네이티브 환경에는 수많은 사용자와 워크로드들이 존재한다. 때문에 접근 제어와 관련된 규칙들이 수만 가지이고, 여기에 따라 어떤 사용자가 어떤 워크로드로 어떤 일을 할 수 있는지가 결정된다. 문제는 이러한 규칙이 한 번 정해지면 일정 기간 지속되는 게 아니라, 계속해서 변한다는 것이다. 아무리 주기적으로 감사를 한다고 해도 이렇게까지 ‘항시’ 변하는 건 기존 보안 도구로 다 막을 수가 없다.
3) 멀티클라우드 보안 : 클라우드 업체들이 제공하는 기존 보안 도구들로는 다른 업체의 클라우드 환경을 보호할 수 없다. 기업들이 대다수 차용하는 클라우드 운영 전략이 ‘멀티클라우드’라는 걸 감안하면 이는 치명적인 결함이 된다.
4) 근본적인 문제의 해결 : 리스크가 존재한다는 걸 아는 것만으로는 빠르고 정확하게 해결할 수 없다. 즉 안다는 것과 해결한다는 건 상호관련성이 대단히 낮을 수 있다는 것이다. 이는 특히 클라우드 네이티브 아키텍처에서는 더 그렇다. 그래서 한 애플리케이션에서 코드 주입 취약점을 찾아냈다고 하더라도, 이 취약점의 근원이 되는 마이크로서비스나 코드 커밋을 곧바로 파악해내지 못할 수도 있다.
그 외에도 여러 가지 이유로 기존 클라우드 보안 도구나 전략들로는 현대의 클라우드 네이티브 환경을 온전히 보호할 수가 없게 된다. 클라우드 네이티브 워크로드를 온전히 보호하려면 보안 도구들과 프로세스들을 확장시켜야만 한다. 몇 가지 베스트 프랙티스를 소개하자면 다음과 같다.
클라우드 네이티브 보안 베스트 프랙티스
1) 보안을 개발 파이프라인 안에 포함시켜야 한다 : 클라우드 네이티브 환경에서는 일단 애플리케이션을 출시부터 하고 리스크를 나중에 찾는 게 그리 효율적인 프로세스가 되지 못한다. 오히려 CI/CD 파이프라인에 보안 점검 프로세스를 고정적으로 포함시키는 등의 방법을 통해 보안을 시작 단계에서부터 넣는 것이 좋다. 최초의 소스코드부터, 생산의 각 단계마다 보안 점검을 실시하는 게 가장 이상적이다.
2) 에이전트만으로는 불충분하다 : 에이전트 기반의 보안은 간단한 클라우드 워크로드를 보호하는 데에 있어 충분하다. 하지만 보안을 위한 가시성을 확보하는 데에 있어서 에이전트는 그리 좋은 해결책이 되지 않는다. 보안을 위한 가시성은 코드 자체에 이미 내재되어 있어야 한다. 즉 애플리케이션들이 필요한 데이터를 알아서 담당자들에게 노출하도록 만들어져야 한다는 것이다. 에이전트라는 중간자를 둘 이유가 없도록 하는 게 효율적이며 안전하며 온전하다.
3) 다계층 보안을 도입하라 : 클라우드 네이티브 환경은 인프라, 애플리케이션, 오케스트레이션, 물리 네트워크, 가상 네트워크 등 많은 층위로 구성되어 있다. 그리고 이것을 다 통합해 보호하는 방법이 아니라 그 층위 하나하나를 보호하는 방안을 마련해야 한다. 그러니 큐버네티스 컨테이너를 안전하게 설정하기 위한 도구도 필요하고, 컨테이너 이미지 내부를 보호할 도구도 필요하며, 동시에 아이덴티티 보호 장치와 클라우드 보호 장치도 필요하다는 것이다. 다양한 층위에서 공격이 시작되는 걸 염두에 두자.
4) 지속적인 감사, 실시간 감사가 중요하다 : 클라우드 환경 설정에 대한 주기적인 평가와 감사는 아무리 부지런히 진행해도 실시간으로 진행하는 것보다 효과적일 수 없다. 지속적으로 모든 설정 내용을 모니터링할 수 있는 도구들이 클라우드 네이티브 환경에서는 필요하다. 당연한 이야기지만 이런 도구들은 리스크 요인들이 나타날 때 곧바로 사용자/관리자/담당자에게 알려줄 수 있어야 한다.
5) 어느 정도의 복구는 자동화로 해결된다 : 위협 요소가 발견되었을 때 해당 네트워크 영역이나 시스템을 단숨에 분리 및 고립시켜야 하는데, 이 때 가능하다면 자동화 도구를 사용하는 것을 추천한다. 아무리 사람이 빠르게 대응을 한다고 해도, 자동으로 설정된 도구처럼 빠릿하게 움직일 수는 없다. 피해에 대한 대처가 빠르면 빠를수록 피해가 줄어든다. 클라우드 네이티브 환경에서 피해의 확산을 재빠르게 막는 건 필수 덕목이다.
글 : 제프 콜린스(Jeff Collins), 솔루션 매니저, 2nd Watch
[국제부 문정후 기자(globoan@boannews.com)]
<저작권자: 보안뉴스(www.boannews.com) 무단전재-재배포금지>
문가용기자 기사보기
[2024-04-18] 
.jpg)
.jpg)
