본문 바로가기

etc.

[기술 스터디] 02. 클라우드의 시작과 끝, 클라우드 보안

[클라우드 도입 시 문제점]

- 50% 이상의 기업이 데이터 유출 등 보안 문제를 꼽았다. (2021. KDI 경제정보센터)

-> 이는 보안 문제만 없다면 클라우드 전환을 가속화할 수 있다는 의미

 

 

[클라우드 전환의 3단계]

1. 초창기

2. 과도기

3. 정착기

 

 

 

 

[초창기: 소규모 Workload가 시범적으로 전환되는 시기]

- 기업의 업무 시스템 중 규모가 작고 중요도가 낮은 시스템 위주로 시범적 전환되는 시기

- 대부분의 보안 위협이 Legacy와 동일

(Legacy: 과거로부터 물려 내려온 플랫폼, 기술 등을 의미. 즉, 기존 방법)

-> 따라서 초창기에는 기존 보안 솔루션과 수작업에 의한 보안 진단을 통해 대응 가능하다.

 

 

[과도기: 주요 Workload가 전환되는 시기]

- 기업의 주요 업무 시스템의 일부 또는 전체가 클라우드로 전환되는 시기

- 워크로드의 일부 또는 전체를 클라우드 특성에 맞게 재개발하게 됨.

- 따라서 개발 방법론도 DevSecOps와 CI/CD 체계로 전환된다.

(CI/CD: Cont. Integration/Cont. Delivery 즉, 지속적 통합과 지속적 제공. 통합 후 제공을 자동화하여 개발팀이 안정적으로 코드 변경하여 푸시)

-> 따라서 Legacy 환경처럼 수작업에 의한 보안 관리로는 취약점의 발견과 조치가 어려워진다.

 

 

[정착기: Workload가 클라우드에서 최초 개발/구축되는 시기]

- Legacy와는 다른 클라우드를 위한 보안이 필요

-> 따라서 CSP Native 보안 기능을 활용하거나 서드파티 클라우드 보안 솔루션을 적절하게 활용할 수 있어야 한다.

 


[클라우드 전환 초창기]

[가장 큰 보안 위협]

- 보안 정책과 진단 부재에 의한 혼란

 

 

[클라우드 시범 적용]

- Best Practice를 만들어서 이후 다른 업무 시스템 전환에 적용 가능하도록 한다.

- 보안이 누락된 상태로 만들어진 BP는 클라우드 전환의 모든 과정을 위태롭게함

-> BP에서 보안을 중요시 해야 한다.

 

[가장 먼저 착수해야 할 일]

클라우드 특성이 반영된 보안 정책을 수립/배포해야 한다.

-> 이는 이후 혼선을 방지하며,

-> 통상 기존 Legacy 보안에 기반해 일부 고유명사만 클라우드 용어로 바꾸는데 이러면 안되고,
-> 클라우드 보안은 관점의 변화를 요구하는 것이기에

-> 클라우드 인프라 특성에 맞는 보안 정책이 필요하다. (당연

 

 

[기존 Legacy와의 차이점]

1) 기존과는 달리 클라우드 인프라 생성/폐기가 상시 가능하다. 이를 고려해야 함 !

 

Legacy - 인프라 구매/설치 과정이 필요

vs.

클라우드 - 법인카드, 세금계산서만으로도 즉시 사용 가능함.

 

따라서 기업 내부 누구나 언제든 새로운 인프라를 클라우드상에 구축과 필요에 따라 클라우드 리소스 부분 폐기가 상시 발생 가능함.

-> 이 과정에서 관리 대상에서 누락되는 Shadow IT가 발생하지 않도록 구체적인 절차와 통보가 필요하다.

(Shadow IT: 기업 내 허용하지 않은 애플리케이션이나 서비스, 디바이스, SW를 파악하고 조치하지 못하는 현상)

 

2) 외부 침해 대응 및 취약점 진단 가이드 마련 시에도 클라우드 특성 고려해야 한다.

외부 공격에 의한 침해대응 외에, 내부자의 실수 또는 고의에 의해 발생하는 보안 사고 가능성이 존재하므로

-> 이를 탐지, 대응하는 절차를 마련해야 한다.

 

Legacy - 관리자가 물리적 인프라가 구축된 내부에서만 접속하도록 제한 가능

vs.

클라우드 - 인터넷이 되는 곳이라면 어디서든 관리자가 접속 가능하기에 위험.

 

3) 또한, CSP 특성에 맞는 취약점 진단 기준을 새로 수립해야 한다.

CSP 콘솔을 통해 인프라 생성/삭제와 보안 기능의 설정/해제까지 가능하므로 각 CSP 콘솔의 기능을 클릭하는 순서까지 정확히 기재된 보안 진단과 조치 가이드가 제공되어야 함.

 


[클라우드 전환 과도기]

 

DevSecOps와 컨테이너가 적극 활용되는 시기.

-> 자동화된 보안 도구와 클라우드 보안 역량을 갖추는 것이 중요하다.

 

 

[컨테이너 vs. VM vs. 물리 서버]

보안 관점에서 컨테이너가 VM, 물리 서버와 다른 가장 큰 차이점

: 배포의 용이성에 의한 짧은 LifeCycle

 

물리서버 - 5년 정도

vs.

VM - 수개월에서 수년 정도

vs.

컨테이너 - 몇 분, 몇 시간, 며칠 정도의 짧은 LifeCycle을 갖는다.

 

 

 

 

[컨테이너 이미지 취약점]

내부 개발자에 의해 이미지가 만들어지는 경우도 있지만, 이미 누군가 만들어둔 컨테이너를 다량으로 사용해야 빨라진 개발 속도를 맞출 수 있음

-> 그러나 인터넷 상에 유통되는 컨테이너 이미지에는 다수의 취약점이 발견되기도

 

Docker Hub 조사 결과 (컨테이너 이미지가 가장 많이 유통됨 / 2020. Prevasio)

- CVE 기준 9.0 이상의 Critical 취약점을 갖는 경우가 51% 이상

- 취약점이 존재하지 않는 컨테이너 이미지는 20% 

- 가상화폐 채굴기, 해킹 도구 등이 발견된 건 1%

-> 마지막의 경우, Legacy나 VM이었다면 수년 또는 수개월에 한 번 감수할만한 위험이지만, 컨테이너의 짧은 LifeCycle을 감안한다면 매일같이 직면하는 위험이 되는 것 ..... ! △

 

 

[CSPM, CWPP]

클라우드 장점: 탄력성 -> 이는 보안 관점에서 기준 정보가 유동적이라는 어려움으로 작용함.

따라서 Legacy처럼 수작업에 의한 보안 관리로는 취약점 발견/조치가 어려워진다.

-> 자동화된 클라우드 보안 솔루션이 필수

-> CSPM, CWPP와 같은 클라우드 보안 솔루션이 유용하게 활용될 수 있다.

 

 

[CSPM (Cloud Security Posture Management)]

: 클라우드의 Misconfiguration(잘못된 구성)을 탐지하기 위한 솔루션

 

 

클라우드의 모든 인프라와 보안 설정은 콘솔을 통해 이루어짐.

콘솔을 취약하게 설정하거나 디폴트 상태로 방치하는 것을 Misconfiguration이라 함.

-> 클라우드 콘솔 Misconfiguration은 클라우드 보안 사고의 가장 큰 원인

 

 

CSPM을 도입하면,

- 미리 등록해둔 보안 정책을 기준으로 상시 자동 진단함으로써 Misconfiguration을 최소화하고

- 보안 담당자 외에도 개발자, 운영자들이 상시 진단 내용을 확인할 수 있도록 진단 결과를 제공함.

- 따라서 기존보다 빠르게 취약점 조치가 가능

 

 

[CWPP (Cloud Workload Protection Platform)]

: 컨테이너 환경에 특화된 보안 솔루션

 

 

Registry에 등록되었거나 신규로 등록되는 컨테이너 이미지의 알려진 취약점을 진단하고,

체크리스트 기반으로 컨테이너가 구동되는 Docker, K8s, VM Instance 등을 Run-time 진단함.

 

 

CWPP를 도입하면,

- 기업은 CWPP에 의해 진단 및 조치되지 않은 이미지를 배포하지 못하도록 강제하는 프로세스를 수립하고,

- 내부에서 만든 컨테이너 이미지와 외부에서 반입한 컨테이너 이미지를 나누어 관리하여 클라우드 보안 강화가능

 


[클라우드 전환 정착기]

 

CSP Native 보안 기능 적용을 검토하는 단계로, 최근 클라우드 보안에서 각광을 받는 주제

비용 효율성, 가용성, 탄력성, 도입 및 전환 속도 면에서 서드파티 대비 우위에 있다.

 

 

 

 

[CSP Native 보안 기능]

- 호출 횟수당, 또는 사용할 때만 지불하는 Pay-per-use 방식으로 비용 효율적

- 별도의 계약과 구매 프로세스 없이 CSP 콘솔에서 즉시 사용 가능

- Full-Managed로 제공되기 때문에 장애에 대한 우려 낮음

 

 

하지만,

- CSP Native이므로 타 CSP를 위한 보안 기능을 제공하지 않기 때문에, (당연

- 멀티 클라우드 환경에서는 CSP마다 Native 보안 기능 요금은 물론, 인적 학습 비용을 지불해야 함. (서드파티가 낫다)

- On-Premise까지 포괄 불가능. 즉, Hybrid 클라우드 환경에서는 CSP Native와 On-Premise 보안 솔루션 양쪽을 모두 사용해야 함.

- 가장 큰 문제는 난이도. 서드파티 보안 솔루션은 제조사, 총판으로 이어지는 체계(?)를 통해 기술지원을 받을 수 있지만, CSP Native 보안 기능은 사용자가 직접 모든 문제를 해결해야 하기 때문

 

 

[CSP의 보안 기능을 사용하기 위해]

- Compute, Storage, Network, Management에 해당하는 배경 지식과 활용 역량이 요구됨. (당연함 ..

- 명시적으로 보안으로 분류되지 않더라도 보안에 필수 불가결한 기능들인 네트워크 격리 기능이나 전용선 연결, 보안 형상관리 기능 등에 대한 활용 또한 필요.

-> 결국 클라우드 보안 역량이 클라우드 자체의 역량으로 귀결된다.

 

즉, 클라우드 및 클라우드 보안과 관련된 내부 운영 인력들의 역량 강화가 중요하다.

또는 MSP(Managed Service Provider) 또는 MSSP(Managed Security Service Provider) 등을 통해 전문적인 도움을 받는 것이 좋다.

 


 

클라우드 전환은 단순 인프라 전환이 아닌 보안 정책을 포함한 모든 보안 시스템의 전환을 필요로 한다.

기존 Legacy 보안 방식으로 접근한다면 새로운 보안 위협에 노출되기 쉽다.

사용자의 자원 통제 권한 범위가 넓기에 보안 사고 발생 피해 범위도 더 클 수밖에 없다.

 


참고

https://www.samsungsds.com/kr/insights/cloud_security.html?moreCnt=0&backTypeId=&category= 

 

클라우드의 시작과 끝, 클라우드 보안

클라우드의 시작과 끝, 클라우드 보안

www.samsungsds.com

https://subicura.com/2017/01/19/docker-guide-for-beginners-1.html

 

초보를 위한 도커 안내서 - 도커란 무엇인가?

도커를 처음 접하는 시스템 관리자나 서버 개발자를 대상으로 도커 전반에 대해 얕고 넓은 지식을 담고 있습니다. 도커가 등장한 배경과 도커의 역사, 그리고 도커의 핵심 개념인 컨테이너와 이

subicura.com