가히 클라우드로의 과도기다. 우리는 앞으로 수년에 걸쳐 온프레미스에 대한 의존도를 낮추고 클라우드에 더 크게 의존하게 될 것이다. 그랬을 때의 장점은 숱하게 설파되어 오고 있는데, 사실 현실에서는 그 약속들이 다 지켜지지 않고 있는 것처럼 보이기도 한다. 뭐가 잘못되고 있는 걸까?
[보안뉴스 문가용 기자] 현재 운영되고 있는 컨테이너의 75%가 고위험군 내지 치명적 위험도의 취약점을 보유하고 있는 것으로 나타났다. 심지어 이 취약점들 대부분 패치가 있는 것으로 조사됐다. 즉 고쳐질 수 있는 문제인데 고쳐지지 않은 채로 사용되고 있다는 것이다. 이는 보안에 오랜 시간 종사해 온 전문가들에게 있어 그리 새로울 것이 없는 소식이다. 하지만 그건 온프레미스 환경일 때 얘기고, 클라우드에서는 이러한 상황이 개선될 것이라고 하지 않았던가?
물론 앞으로 클라우드 환경은 더 나아질 것이 분명하다. 그리고 이미 그 나아진 환경을 누리는 사람들도 적지 않다. 수준이 높은 팀들은 컨테이너 취약점의 수를 5% 이하로 낮춘 채로 유지하고 있기도 하다. 개발자들과 보안 담당자들이 쉽게 협엽할 수 있는 워크플로우를 갖춘 팀들이 바로 이런 ‘안전 혜택’을 누리고 있다. 아무리 찬란하게 빛나는 신기술이라고 하더라도 안전하고 효과적인 프로세스 안에서 운영되지 않는 이상 불안하기는 매한가지라는 사실이 보다 분명하게 입증되고 있다. 기술 자체도 중요하지만 그 기술의 구축과 활용도 마찬가지로 중요하다.
온프레미스에서 새는 바가지, 클라우드에서도 샌다
클라우드라는 신기술은 많은 약속을 사용자들에게 제공한다. 그런데 여기에는 함정이 있다. 체제를 클라우드로 변환한다고 해서 곧바로 모든 것이 마법처럼 바뀌지는 않는다는 것이다. 클라우드에 맞게 업무 프로세스와 규정과 데이터 관리 체제 등도 다 바뀌어야 한다. 보안도 그 중 하나다. 그래야 클라우드 체제에서 약속된 유연성과 확장성 등을 누릴 수 있게 된다. 하지만 클라우드로의 이전이 한창 이뤄져 바쁠 때, 우리는 보안을 잠시 뒤로 제쳐두곤 한다.
다중 인증 시스템을 예로 들어 보자. 지금쯤이면 누구나 한 번쯤 다중 인증 시스템의 중요성에 대해 한 번 이상 들어봤을 것이다. 권한이 높고 민감한 정보를 자주 다루는 계정들에 다중 인증을 적용함으로써 침해 가능성을 낮출 수 있다는 권고 사항은 우리 주변에서 매우 흔하게 접할 수 있다. 하지만 사용자 개개인들이 자발적으로 자신의 이메일 계정이나 은행 계좌를 보호하기 위해 이중 인증 옵션을 선택하는가? 대부분은 다중 인증의 중요성에 대해 익히 들었지만 개인 계정들을 여전히 한 개의 암호로만 보호하고 있다. 로그인 한 번 할 때마다 발생하는 ‘추가 정보 입력’ 단계를 우리는 도무지 견디지 못하는 것처럼 보인다.
비슷한 상황이 클라우드 환경에서도 벌어지고 있다. 아무리 다중 인증이 좋다고 해도 클라우드 관리 계정에 다중 인증을 적용하는 기업은 그리 많지 않다. 한 조사에 의하면 다중 인증을 활성화하고 있는 기업들이 52% 정도에 그친다고 한다. 절반을 가까스로 넘긴 조직들만이 가장 중요한 계정과, 그 계정에 연결된 데이터를 보호하기 위해 자신들이 아는 것을 실천하고 있는 것이다. 나머지는 기본적인 보안 권고 사항을 무시하고 있고 말이다.
클라우드 보안에 있어 가장 중요한 요소 중 하나는 아이덴티티 및 접근 관리(IAM)이다. 그러므로 새로운 클라우드 네이티브 인증 및 접근 프로세스를 도입하는 것이 중요하다. 그렇지 않으면 클라우드라는 새로운 체제를 구축한다고 해서 특별히 더 나을 것이 없다. 클라우드 담당 팀들은 업무나 역할에 따라 권한을 부여하는 방식의 IAM을 구축해야 하고, 그러므로 최소한의 권한을 부여한다는 원칙을 엄격하게 고수해야 한다. 온프레미스에서 하듯, 누구나 관리자 계정 비밀번호를 알고 사용하면 클라우드 보안은 없는 것이나 마찬가지가 된다.
‘설계 단계에서부터 보안’은 아직 보편화되지 않았다
신기술에 맞게 업무 프로세스들부터 바뀌어야 한다고 말하긴 했지만, 뭔가가 새롭게 바뀌는 데에는 긴 시간이 필요하다. 그리고 대부분의 경우 변화는 점진적으로 일어나게 되어 있다. 위에서 언급된 조사에는 또 다른 재미있는 내용이 포함되어 있었다. 48%의 이미지들에서 취약점 스캐닝이 최초로 실행되는 때는 CI/CD 파이프라인이나 컨테이너 레지스트리에서라고 한다. 즉 런타임에 구축되기 전이라는 소리다.
무슨 의미일까? 많은 조직들이 시작 단계에서부터 보안을 도입하고 있다는 의미가 될 수 있다. 반대로 나머지 52%는 런타임이 되어서야 비로소 처음 스캔이 된다는 것이다. 그렇기 때문에 취약점이 발견되는 시점이 상당히 늦어질 수 있다. 왜 이런 것일까? 첫 번째로, 우리에게 보안을 시작부터 고려하는 습관이 아직 충분히 배지 않았기 때문이다. 기획과 설계 단계에서부터 보안을 이야기하는 것이 시간 낭비처럼 여겨지는 경향이 우리에게 남아 있다. 두 번째, 아직 ‘설계부터 보안’이라는 개념이 적용되는 업무의 종류가 한정되어 있다고 볼 수 있다. ‘이 정도는 하던 대로 해도 된다’고 생각되는 것들이 많다는 것이다.
리스크에 대한 개념 역시 변화해야 한다
‘그 정도 리스크는 받아들여야 한다’고 했을 때 우리는 보통 ‘갈 곳이 더는 없는 막다른 골목’과 같은 상황을 떠올린다. ‘더 보완할 방법이 없으니 아무 일 없기를 바라며 기록을 남긴다’는 말과 거의 같은 말이다.
하지만 리스크 요인이라는 것을 최대한 빨리 알게 되면 될수록 대처를 하는 것도 쉬워지고, 선택지도 늘어난다. 설사 75%의 컨테이너에 한 개 이상의 고위험군 취약점이 있다고 하더라도 미리 해당 취약점으로 야기될 수 있는 리스크와, 그 리스크로 인해 일어날 수 있는 일들을 고려하고 방비책을 마련한 것이라면 보안 상태가 나쁘다고 말할 수는 없다. 같은 75%라도 취약점이 있는지 없는지도 모르고 있는 것과는 전혀 다른 수치가 된다.
현대의 보안 담당자들은 소프트웨어 취약점 관리라는 것에 대해 많은 고민을 하고 살아간다. 우리가 직접 만들지도 않은 서드파티 소프트웨어의 런타임 오류들까지도 고려해야 한다. 여기에 더해 네트워크 어딘가에, 지금은 사용되지도 않아 잊힌 채로 남아 있는, 그런 소프트웨어들의 취약점들까지도 알아내야 한다. 이런 상황에서 소프트웨어 공급망의 초기 단계로까지 거슬러 올라가 초기 디펜던시들의 취약점을 파악할 수 있다면 어떻겠는가? 많은 시간을 아낄 수 있게 된다. 리스크 역시 크게 줄어든다.
모든 오류들을 발견 즉시 죄다 패치하고 해결하라는 게 아니다. 물론 그러면 좋겠지만 그럴 여건이 도무지 되지 않은 경우들도 많다. 그럴 때는 취약점을 ‘리스크 관리’의 요인으로 다루면 도움이 된다. 사실 모든 취약점을 남김없이 패치하고, 그 상태를 계속해서 유지하는 건 불가능에 가까울 정도로 어려운 일이다. 이는 마치 모든 사이버 공격을 예방하는 것만이(복구가 아니라) 진정한 사이버 보안이라고 주장하는 것과 비슷하다. 관리의 차원에서 위기 요인들과 취약점을 다룰 필요가 있다. 대신 그런 관리를 위해 가시성을 확보하는 건 대단히 중요한 일이다.
희망은 있는가?
현재 클라우드 생태계에서 돌아가는 컨테이너의 수는 수십 억 개를 넘는다. 그리고 이 수는 빠르게, 정말 빠르게 늘어날 전망이다. 공격의 통로와 잠재적 위험이 계속해서 증가한다는 뜻이다. 이는 비단 클라우드나 컨테이너만의 문제는 아니다. 앞으로 출현할 모든 신기술들에서 나타날 공통의 현상이다. 그렇다고 지금의 ‘취약점 많은 컨테이너’의 상황이 괜찮다는 건 아니다. 이 상황을 해결하지 못한다면 클라우드나 컨테이너 모두 ‘잠깐 반짝했다가 위험해서 폐기처분 되는 기술’의 운명을 맞거나, 기술 부채로 남을 수 있게 된다.
다시 말해 클라우드나 컨테이너라는 기술과, 그 기술을 활용하는 지금의 초기 단계에서 발견된 문제들은, 우리가 인프라를 새롭고 단단하게 구성할 수 있는 기회가 될 수 있다. 온프레미스에서 길러온 나쁜 습관들을 고치고, 마치 아무 일 없었던 것처럼 새로운 인프라의 시대를 맞이할 수 있다. 새로운 희망이 있는가,가 아니라 클라우드로 넘어가는 지금의 상황 자체가 희망이다.
글 : 안나 벨락(Anna Belak), 국장, Sysdig
[국제부 문가용 기자(globoan@boannews.com)]
[보안뉴스 문가용 기자] 현재 운영되고 있는 컨테이너의 75%가 고위험군 내지 치명적 위험도의 취약점을 보유하고 있는 것으로 나타났다. 심지어 이 취약점들 대부분 패치가 있는 것으로 조사됐다. 즉 고쳐질 수 있는 문제인데 고쳐지지 않은 채로 사용되고 있다는 것이다. 이는 보안에 오랜 시간 종사해 온 전문가들에게 있어 그리 새로울 것이 없는 소식이다. 하지만 그건 온프레미스 환경일 때 얘기고, 클라우드에서는 이러한 상황이 개선될 것이라고 하지 않았던가?
[이미지 = utoimage]
물론 앞으로 클라우드 환경은 더 나아질 것이 분명하다. 그리고 이미 그 나아진 환경을 누리는 사람들도 적지 않다. 수준이 높은 팀들은 컨테이너 취약점의 수를 5% 이하로 낮춘 채로 유지하고 있기도 하다. 개발자들과 보안 담당자들이 쉽게 협엽할 수 있는 워크플로우를 갖춘 팀들이 바로 이런 ‘안전 혜택’을 누리고 있다. 아무리 찬란하게 빛나는 신기술이라고 하더라도 안전하고 효과적인 프로세스 안에서 운영되지 않는 이상 불안하기는 매한가지라는 사실이 보다 분명하게 입증되고 있다. 기술 자체도 중요하지만 그 기술의 구축과 활용도 마찬가지로 중요하다.
온프레미스에서 새는 바가지, 클라우드에서도 샌다
클라우드라는 신기술은 많은 약속을 사용자들에게 제공한다. 그런데 여기에는 함정이 있다. 체제를 클라우드로 변환한다고 해서 곧바로 모든 것이 마법처럼 바뀌지는 않는다는 것이다. 클라우드에 맞게 업무 프로세스와 규정과 데이터 관리 체제 등도 다 바뀌어야 한다. 보안도 그 중 하나다. 그래야 클라우드 체제에서 약속된 유연성과 확장성 등을 누릴 수 있게 된다. 하지만 클라우드로의 이전이 한창 이뤄져 바쁠 때, 우리는 보안을 잠시 뒤로 제쳐두곤 한다.
다중 인증 시스템을 예로 들어 보자. 지금쯤이면 누구나 한 번쯤 다중 인증 시스템의 중요성에 대해 한 번 이상 들어봤을 것이다. 권한이 높고 민감한 정보를 자주 다루는 계정들에 다중 인증을 적용함으로써 침해 가능성을 낮출 수 있다는 권고 사항은 우리 주변에서 매우 흔하게 접할 수 있다. 하지만 사용자 개개인들이 자발적으로 자신의 이메일 계정이나 은행 계좌를 보호하기 위해 이중 인증 옵션을 선택하는가? 대부분은 다중 인증의 중요성에 대해 익히 들었지만 개인 계정들을 여전히 한 개의 암호로만 보호하고 있다. 로그인 한 번 할 때마다 발생하는 ‘추가 정보 입력’ 단계를 우리는 도무지 견디지 못하는 것처럼 보인다.
비슷한 상황이 클라우드 환경에서도 벌어지고 있다. 아무리 다중 인증이 좋다고 해도 클라우드 관리 계정에 다중 인증을 적용하는 기업은 그리 많지 않다. 한 조사에 의하면 다중 인증을 활성화하고 있는 기업들이 52% 정도에 그친다고 한다. 절반을 가까스로 넘긴 조직들만이 가장 중요한 계정과, 그 계정에 연결된 데이터를 보호하기 위해 자신들이 아는 것을 실천하고 있는 것이다. 나머지는 기본적인 보안 권고 사항을 무시하고 있고 말이다.
클라우드 보안에 있어 가장 중요한 요소 중 하나는 아이덴티티 및 접근 관리(IAM)이다. 그러므로 새로운 클라우드 네이티브 인증 및 접근 프로세스를 도입하는 것이 중요하다. 그렇지 않으면 클라우드라는 새로운 체제를 구축한다고 해서 특별히 더 나을 것이 없다. 클라우드 담당 팀들은 업무나 역할에 따라 권한을 부여하는 방식의 IAM을 구축해야 하고, 그러므로 최소한의 권한을 부여한다는 원칙을 엄격하게 고수해야 한다. 온프레미스에서 하듯, 누구나 관리자 계정 비밀번호를 알고 사용하면 클라우드 보안은 없는 것이나 마찬가지가 된다.
‘설계 단계에서부터 보안’은 아직 보편화되지 않았다
신기술에 맞게 업무 프로세스들부터 바뀌어야 한다고 말하긴 했지만, 뭔가가 새롭게 바뀌는 데에는 긴 시간이 필요하다. 그리고 대부분의 경우 변화는 점진적으로 일어나게 되어 있다. 위에서 언급된 조사에는 또 다른 재미있는 내용이 포함되어 있었다. 48%의 이미지들에서 취약점 스캐닝이 최초로 실행되는 때는 CI/CD 파이프라인이나 컨테이너 레지스트리에서라고 한다. 즉 런타임에 구축되기 전이라는 소리다.
무슨 의미일까? 많은 조직들이 시작 단계에서부터 보안을 도입하고 있다는 의미가 될 수 있다. 반대로 나머지 52%는 런타임이 되어서야 비로소 처음 스캔이 된다는 것이다. 그렇기 때문에 취약점이 발견되는 시점이 상당히 늦어질 수 있다. 왜 이런 것일까? 첫 번째로, 우리에게 보안을 시작부터 고려하는 습관이 아직 충분히 배지 않았기 때문이다. 기획과 설계 단계에서부터 보안을 이야기하는 것이 시간 낭비처럼 여겨지는 경향이 우리에게 남아 있다. 두 번째, 아직 ‘설계부터 보안’이라는 개념이 적용되는 업무의 종류가 한정되어 있다고 볼 수 있다. ‘이 정도는 하던 대로 해도 된다’고 생각되는 것들이 많다는 것이다.
리스크에 대한 개념 역시 변화해야 한다
‘그 정도 리스크는 받아들여야 한다’고 했을 때 우리는 보통 ‘갈 곳이 더는 없는 막다른 골목’과 같은 상황을 떠올린다. ‘더 보완할 방법이 없으니 아무 일 없기를 바라며 기록을 남긴다’는 말과 거의 같은 말이다.
하지만 리스크 요인이라는 것을 최대한 빨리 알게 되면 될수록 대처를 하는 것도 쉬워지고, 선택지도 늘어난다. 설사 75%의 컨테이너에 한 개 이상의 고위험군 취약점이 있다고 하더라도 미리 해당 취약점으로 야기될 수 있는 리스크와, 그 리스크로 인해 일어날 수 있는 일들을 고려하고 방비책을 마련한 것이라면 보안 상태가 나쁘다고 말할 수는 없다. 같은 75%라도 취약점이 있는지 없는지도 모르고 있는 것과는 전혀 다른 수치가 된다.
현대의 보안 담당자들은 소프트웨어 취약점 관리라는 것에 대해 많은 고민을 하고 살아간다. 우리가 직접 만들지도 않은 서드파티 소프트웨어의 런타임 오류들까지도 고려해야 한다. 여기에 더해 네트워크 어딘가에, 지금은 사용되지도 않아 잊힌 채로 남아 있는, 그런 소프트웨어들의 취약점들까지도 알아내야 한다. 이런 상황에서 소프트웨어 공급망의 초기 단계로까지 거슬러 올라가 초기 디펜던시들의 취약점을 파악할 수 있다면 어떻겠는가? 많은 시간을 아낄 수 있게 된다. 리스크 역시 크게 줄어든다.
모든 오류들을 발견 즉시 죄다 패치하고 해결하라는 게 아니다. 물론 그러면 좋겠지만 그럴 여건이 도무지 되지 않은 경우들도 많다. 그럴 때는 취약점을 ‘리스크 관리’의 요인으로 다루면 도움이 된다. 사실 모든 취약점을 남김없이 패치하고, 그 상태를 계속해서 유지하는 건 불가능에 가까울 정도로 어려운 일이다. 이는 마치 모든 사이버 공격을 예방하는 것만이(복구가 아니라) 진정한 사이버 보안이라고 주장하는 것과 비슷하다. 관리의 차원에서 위기 요인들과 취약점을 다룰 필요가 있다. 대신 그런 관리를 위해 가시성을 확보하는 건 대단히 중요한 일이다.
희망은 있는가?
현재 클라우드 생태계에서 돌아가는 컨테이너의 수는 수십 억 개를 넘는다. 그리고 이 수는 빠르게, 정말 빠르게 늘어날 전망이다. 공격의 통로와 잠재적 위험이 계속해서 증가한다는 뜻이다. 이는 비단 클라우드나 컨테이너만의 문제는 아니다. 앞으로 출현할 모든 신기술들에서 나타날 공통의 현상이다. 그렇다고 지금의 ‘취약점 많은 컨테이너’의 상황이 괜찮다는 건 아니다. 이 상황을 해결하지 못한다면 클라우드나 컨테이너 모두 ‘잠깐 반짝했다가 위험해서 폐기처분 되는 기술’의 운명을 맞거나, 기술 부채로 남을 수 있게 된다.
다시 말해 클라우드나 컨테이너라는 기술과, 그 기술을 활용하는 지금의 초기 단계에서 발견된 문제들은, 우리가 인프라를 새롭고 단단하게 구성할 수 있는 기회가 될 수 있다. 온프레미스에서 길러온 나쁜 습관들을 고치고, 마치 아무 일 없었던 것처럼 새로운 인프라의 시대를 맞이할 수 있다. 새로운 희망이 있는가,가 아니라 클라우드로 넘어가는 지금의 상황 자체가 희망이다.
글 : 안나 벨락(Anna Belak), 국장, Sysdig
[국제부 문가용 기자(globoan@boannews.com)]
<저작권자: 보안뉴스(www.boannews.com) 무단전재-재배포금지>
문가용기자 기사보기
[2024-05-02] 
