클라우드 혁신을 통한 인터넷 보안 강화

Clarke Rodgers(00:10):
인터넷이 있기 전, 보안 문제가 더 단순하고 명확했던 시절이 있었다는 것은 믿기가 어렵습니다. 지난 40년 동안 세상은 급격하게 변했고, 온라인 연결은 이제 우리 삶과 비즈니스의 중심이 되었습니다. 이는 커다란 기회가 되기도 하지만, 그만큼 위험도 커집니다.

저는 Clark Rodgers입니다. AWS Enterprise Strategy Director이고, Executive Insights 시리즈인 AWS 보안 리더들과의 대화에서 진행을 맡고 있습니다.

오늘은 AWS Deputy CISO이자 Vice President 겸 Distinguished Engineer인 Paul Vixie와 이야기를 나눠보겠습니다. Paul은 인터넷 발전의 초창기부터 영향을 끼쳐온 분으로, AWS 보안에 대한 고유한 관점을 제시합니다. 인터넷을 더 안전한 소통의 장으로 만들기 위한 보안 리더의 역할에 대한 담화에 참여해 보세요. 즐거운 시간이 되시길 바랍니다.

Clarke Rodgers(00:57):
Paul, 오늘 함께 해 주셔서 감사합니다. 인터넷 업계에 꽤 오랫동안 몸담으셨죠. 인터넷이 어떻게 시작되었고, 어떻게 오늘날의 위치에 오르게 되었는지, 특히 보안 관점에서 말씀해 주시겠어요?

Paul Vixie(01:11):
보안은 나중에 고려한 사항이었죠. 그래서 보안은 나중에 와서야 주목을 받게 되지만, 이 이야기는 사실입니다. 인터넷은 미국 정부 네트워크에서 시작되었습니다. 적어도 초기에는 군대에서 사용된 적이 없죠. 프로토콜이 키네틱 공격 등에 대비해 강화되도록 설계되었다는 소문이 있지만, 이는 사실이 아닙니다. 인터넷은 항상 최선형 시스템이었습니다. 그리고 이것이 제대로 작동할 때는 많은 사람들에게 정말 효과적입니다. 하지만 제대로 작동하지 않는 경우, 더 강화된 네트워크에서는 발생하지 않는 치명적인 장애가 발생할 수 있습니다.

Clarke Rodgers(01:48):
어느 시점에 “이런, 보안을 고려하지 않았군”이라는 사실을 깨닫게 되셨나요? 그리고 어떤 조치가 필요하다는 것을 알게 되셨나요?

Paul Vixie(01:56):
저는 꽤 일찍부터 경종을 울리기 시작했고, 가장 먼저 우려했던 것은 스팸이었습니다. 정부 전용 네트워크에서는 원치 않는 트래픽 전송을 통해 이득을 볼 사람이 없었기 때문에 인증 기능이 없었고, 사람들이 원치 않는 트래픽을 전송하지 못하도록 막을 수 있는 방법이 없었죠.

저는 1992년 초부터 경고하기 시작했습니다. 그리고 컨설팅 등을 하며 지내던 중에 최초의 스팸 방지 프로젝트를 시작했고, 이것이 최초의 스팸 방지 회사가 되었습니다. 그리고 우리 회사의 분산형 평판 시스템은 업계 최초였습니다. 그때 특허를 출원했어야 했는데 말이죠. 제가 스팸 퇴치를 위해 시작한 회사는 소송을 당해 사라졌어요. 그 시스템은 지금도 널리 사용되고 있지만요. 그 회사는 사라지고 말았죠. 하지만 그 아이디어와 기술은 모두 살아 있고, 제가 옳았어요.

Clarke Rodgers(02:57):
최근에는 대규모 클라우드 서비스 공급자뿐만 아니라 고객사에서도 보안이 더욱 중요하게 여겨지고 있는데요. 고무적인 사항이 있다면 무엇이라고 생각하시나요? 이와 관련하여 희망적이신가요?

Paul Vixie(03:13):
저는 희망을 가지고 있지만, 지금은 우리가 하고 있는 모든 일이 너무 적고 너무 늦기도 했다는 점에서 실망스럽기도 합니다. 하지만 시장 전체가 깨어나서 문제를 인식할 때까지 기다려야 합니다. 한 곳의 회사나 한 명의 사람이 경종을 울릴 수 있는 것은 아닙니다.

저에게 희망을 주는 한 가지는 Amazon에 입사한 후 접한 여러 기술입니다. 규모가 커지면서 일부 문제는 일반화를 거친 다음 해결책을 배포해야 하며, 이는 소규모 업무만 진행하는 소규모 회사에서는 불가능한 작업입니다. 예를 들어, 다른 VM에 비해 우리 VM의 보안을 강화하기 위해 Graviton 프로세서에서 수행한 작업은 우리를 제외하고는 아무도 수행할 수 없는 작업이었습니다.

Nitro 칩셋과 Nitro 하이퍼바이저의 경우, 우리를 제외하고는 아무도 해내지 못했습니다. 예를 들어, Log4j가 등장했을 때 우리도 영향을 받지 않은 것은 아니었지만, 우리는 충분히 큰 규모를 갖추고 있고 글로벌 방식으로 신속하게 배포할 수 있었기 때문에 수십 시간 내에 모든 고객을 위한 패치를 제공할 수 있었지만, 각자 자신의 보안을 책임져야 하는 시스템, 즉 중앙 집중화되지 않은 시스템에서는 공급망이 정상화될 때까지 기다려야 했죠.

“그래서 저는 인터넷이 중요한 인프라가 되고 일종의 글로벌 디지털 신경계이자 세계 경제의 원천이 되면서 사람들이 인터넷을 더 진지하게 받아들이기 시작했다는 점에서 희망적입니다.”

그리고 트랜지스터의 가격이 개당 1달러에 불과하던 초기에 초저비용으로 수행했던 수많은 일들이 점차 단계적으로 사라지고 있습니다. 그리고 애초에 OSI 프로토콜보다 더 빨리 시장에 진입하는 데 도움이 되었던 무모한 일을 하지 않는 것 외에는 이러한 문제를 해결할 수 있는 다른 방법이 없습니다. 우리와 같은 클라우드가 아니라면 말이죠.

Clarke Rodgers(05:09):
향후 몇 년을 내다볼 때, 우리 같은 회사뿐만 아니라 고객들이 보안 및 규정 준수 워크로드의 발전을 실현하는 데 도움이 될 것으로 생각되는 특정 기술이나 방법과 관련하여 특별히 기대가 되는 것이 있으신가요?

Paul Vixie(05:31):
내부적으로 고무적인 것은 컨테이너의 성과입니다. 1만 개의 컨테이너 모두를 하나의 칩에서 작동하고 부하가 급증할 경우 초당 수천 개의 컨테이너를 시작할 수 있으면서도 소프트웨어 엔지니어링 방식을 완전히 바꾸지 않아도 된다는 점에서 매우 고무적입니다. 이 모델로 전환하면 예를 들어 패치와 같이 현재 겪고 있는 문제에서 벗어날 수 있으니까요.

패치를 수행해야 할 일이 언제든 생길 수 있습니다. 이를 전담하는 팀이 없다면 일주일에 한 번 또는 한 달에 한 번으로 미루게 될 것입니다. 그렇게 하다 보면 "이런, 이 패치를 내 시스템에 적용하려면 다른 것들도 업그레이드해야 하므로 모든 것을 테스트 랩에 넣어야 하겠군"이라는 사실을 깨닫게 될 수 있습니다. 따라서 패치가 정말 절실히 필요하다는 것을 알게 되었지만, 마침내 시스템에 패치를 적용하게 되는 시점은 그로부터 몇 달 후가 될 수 있습니다.

►  팟캐스트 듣기: Vulnerability Management in a Zero Day Security Scenario(제로데이 보안 시나리오에서의 취약성 관리)

지금처럼 계속 그렇게 해서는 스타트렉에서처럼 모든 것이 잘 작동하는 영광스러운 미래에 도달할 수 없을 것입니다. 그래서 Lambda, Kubernetes, Firecracker와 같은 컨테이너는 이른바 CICD라는 빌드 파이프라인을 통해 이미지를 빌드하고 테스트를 거쳐 통과하면 바로 서비스로 배포할 수 있는 기회를 제공합니다.

실제로 패치를 적용하는 데 사용하도록 충분한 온보드 도구와 로직을 갖춘 VM이 없어도 됩니다. 이것이 현재 우리가 하는 일이며, 이는 확장되지는 않을 것입니다. 이미 약간의 문제가 드러났고 제가 자란 환경이 그런 방식이기 때문에 여전히 그렇게 하고 있지만, 다른 사람들에게는 이러한 방식을 권하고 싶지 않습니다. 그렇게 할 이유도 없고, 우리가 "그래, 빌드한 이후에는 손을 대지 않을 거야"라는 데 합의할 수 있다면 많은 이점이 있습니다.

인적 개입이 이루어지지 않는다는 것은 또 하나의 고무적인 일입니다. 사람이 생각하고 사람이 구축한 것에 대해 이런 말을 하게 되어 유감이지만, 시간이 지나도 안전을 유지하려면 지금 당장 인적 요소를 줄여야 합니다.

사람과 고객에게 전달되는 가치의 사이에 위치하는 소프트웨어와 하드웨어의 양이 그 어느 때보다 많습니다. 그리고 우리의 이해는 상대적으로 고정되어 있어, 그 양이 늘어날 때마다 그 중 일부만 이해하게 됩니다. 이렇게 되어서는 안 됩니다. 우리는 복잡성이 바람직하지 않은 결과를 낳지 않도록 하는 방법을 찾아야 합니다. 다시 말씀드리지만, 이를 위해서는 더 많은 원칙이 적용되고 사람이 개입하지 않도록 해야 합니다.

“사람이 생각하고 사람이 구축한 것에 대해 이런 말을 하게 되어 유감이지만, 시간이 지나도 안전을 유지하려면 지금 당장 인적 요소를 줄여야 합니다.”

Clarke Rodgers(08:18):
제로 트러스트 개념은 인적 액세스와 네트워크에 대한 아이디어와 함께 수년에 걸쳐 발전해 왔습니다. AWS의 관점, 즉 내부적으로 어떻게 생각하고 구현하는지, 그리고 고객의 관점, 즉 고객이 제로 트러스트를 어떻게 바라봐야 하는지의 측면에서 제로 트러스트에 대해 어떤 생각을 가지고 계신가요?

Paul Vixie(08:39):
제로 트러스트의 핵심 요소에 대한 오해가 있습니다. 예를 들어, 사람들이 “모든 것을 온라인에 올려서 모두 접속할 수 있게 하고 서비스와 서버 자체를 보호하면 돼, 경계 없이도 네트워크를 보호할 수 있어.”라고 말하는 것을 들은 적이 있습니다. 이는 제로 트러스트의 핵심이 아니며 효과가 없습니다. 방화벽은 여전히 필요하지만, 방화벽 내부에 들어왔다고 해서 경계 내에 있기 때문에 특별한 신뢰를 얻는 것이 아닙니다.

따라서 도달 가능성이 신뢰성을 의미한다는 가정이 사라지고 있습니다. 이는 예전에는 "바삭바삭한 외부"와 "부드럽고 끈적끈적한 내부"라고 불렸습니다. 우리는 비록 겉은 바삭바삭해도 내부는 부드럽고 끈적거리는 것을 원하지 않습니다. 따라서 ID와 인증 및 권한을 대규모로 기계화하는 시스템이 필요합니다. 예를 들어, 지금 이 대화를 나누는 동안에도 Amazon Cloud에서는 초당 20억 건의 인증 이벤트가 발생하고 있습니다.

그리고 우리는 최근 결과를 캐싱하여 ‘1초 전에 권한이 있었다면 지금도 권한이 있을 것'이라는 식의 싸구려 수법을 사용하지 않았습니다. 우리는 매번 확인하고 있으며, 어느 시점에 이르러서는 "이 수준 아래로 내려가면 보안이라는 핵심 사안을 제대로 해결할 수 없다"는 결론을 내렸습니다.

하지만 다시 말씀드리지만, 대부분 시스템의 경우 사용자가 진입한 이후에는 대규모로 작동하는 세분화된 액세스 제어 기능이 없기 때문에 사용자가 원하는 것은 무엇이든 할 수 있도록 허용한다는 아이디어로 설계되었습니다. 이것이 바로 우리가 바꾸고 있는 것입니다. 그리고 다양한 인증 표준이 있습니다. 우리의 인증 표준이 가장 먼저 출시되었고 규모도 매우 크지만, 업계 표준이 되려는 의도는 없었습니다. 따라서 다른 클라우드에서도 비슷한 작업을 진행 중이며, 업계 표준이 되기 위해 노력 중인 인증 표준도 있습니다.

제가 아는 한, 우리는 서비스 팀과 상의하지 않고도 이러한 방식으로 운영하고자 하는 모든 고객이 그렇게 할 수 있도록 할 것입니다.

Clarke Rodgers(10:49):
지난 1년여 동안 생성형 AI가 뉴스에 자주 등장했고, 제 뉴스피드에도 거의 매일 보이는 것 같습니다. 보안 실무자의 관점에서 이에 대해 어떻게 생각하시나요? 보안 전문가들이 이러한 유형의 사안에 대한 보호와 조사에 생성형 AI를 어떻게 활용하고 있다고 생각하시나요?

Paul Vixie(11:10):
따라서 과장을 그만두고 "정착된 이후에는 어떻게 될까?"라는 질문을 던져야 합니다. 일부의 경우, 우리는 알지 못합니다. 이는 꽤 새로운 기술이고 이를 위해 많은 하드웨어와 소프트웨어가 개발되고 있습니다. 그리고 도구의 제작자가 아닌 다른 사람이 사용하기 전까지는 그 도구가 어떤 영향을 미칠지 알 수 없습니다. 렌치를 망치로 사용하려는 경우, 렌치 제작자가 생각한 것과는 다른 용도가 되겠지만, 어떤 상황에서는 효과가 있을 수도 있습니다.

우리는 과장의 주기가 끝나고 헤드라인을 장식할 다른 무엇인가가 등장하면 생성형 AI를 통해 실제로 무엇이 가능할 것인지에 대한 강력한 신호를 보지 못했습니다. 그렇긴 하지만 Amazon은 적어도 지난 십여 년 동안 AI 기반 솔루션을 연구, 개발, 배포해 왔습니다. 따라서 이는 우리에게 전혀 놀라운 일이 아니었습니다.

이미 생성형 AI 기술을 사용하고 있지만 헤드라인을 장식하고 있는 것과는 상황이 전혀 다른 CodeWhisperer 시스템이 그 예입니다. 모든 종류의 시스템에서 이러한 상황이 발생하고 있습니다. 예를 들어, 이상 징후 탐지를 수행할 때 시스템의 텔레메트리 흐름을 살펴보면 무엇인가 잘못되었음을 나타내는 이벤트나 누군가가 공격하고 있음을 나타내는 이벤트를 볼 수 있습니다. 이제 이 기술을 활용할 수 있으니 이들 간의 상관관계를 더 잘 찾아내는 것이 가능해질 것입니다. 다시 한 번 말씀드리지만, 아직 가능성의 1%도 보지 못한 것 같습니다.

►  동영상 보기: 생성형 AI 현황

그래서 한편으로는 과장 단계의 주기를 싫어하고 처음부터 진지하게 접근했으면 좋겠다는 생각이 들지만, 다른 한편으로는 여기에 실제로 장점이 있다는 것도 인정합니다. 저는 AWS 보안 내부의 몇몇 팀과 함께 "이 기술을 일반적으로 사용할 수 있고 일반적으로 이해되고 있는 지금, 고객에게 더 나은 서비스를 제공하기 위해 무엇을 할 수 있을까요?"라는 질문에 답하기 위해 노력하고 있습니다.

Clarke Rodgers(13:14):
생성형 AI 도구를 통해 기술적인 관점에서 수많은 고된 작업을 하고 있는 인간 보안 실무자를 도울 수 있을까요?

Paul Vixie(13:25):
그럼요. 제품 홍보를 위한 말은 아니지만, Amazon이 클라우드와 관련하여 거둔 가장 큰 성공은 항상 고객이 채택하고 구축할 수 있도록 지원하는 워크플로였습니다. 그래서 대규모 언어 모델 분야에서 가장 먼저 한 일 중 하나는 Bedrock이었습니다. 이를 만들게 된 출발점이 된 아이디어는 “대규모 언어 모델을 사용하려 한다면 훈련 비용도 지불하고 싶으신가요? 모델을 구축해야만 하나요?”입니다.

왜냐하면 이 작업을 수행하려면 수천 또는 수만의 매우 비싼 컴퓨터 시간이 소요될 수 있기 때문입니다. 미리 구축된 다양한 모델이 메뉴에 있고 원하는 모델을 선택할 수 있지만 이를 자신의 시스템으로 복사하기 위해 비용을 지불할 필요가 없다면, 자신의 VPC에 로직을 삽입하거나 이러한 구독 모델에 액세스할 수 있다는 것을 알고 있는 API에 직접 액세스할 수 있는 당사의 클라우드 환경에 수행 중인 작업을 삽입하기만 하면 됩니다.

그래서 그 당시에는 몰랐지만, Amazon에 합류한 후 알게 된 클라우드의 기본 개념, 즉 정말 필요한 만큼의 컴퓨팅을 탄력적으로 사용할 수 있고, 스토리지도 정말 필요한 만큼 탄력적으로 사용할 수 있으며, 액세스 페널티 없이 사용할 수 있는 것이 우리가 성장할 수 있었던 비결이었습니다. 이제 우리는 생성형 AI 내부에 이러한 기능을 복제하여, 해당 분야의 매우 야심 찬 사람들이 LLM을 사용하지 않고 클라우드를 통해 항상 해왔던 업무를 클라우드와 LLM을 이용해 할 수 있도록 했습니다. 우리는 이 점이 마음에 듭니다. 저는 이 기능의 진정한 힘은 고객이 수행한 작업으로 판명될 것이기에 이 점이 마음에 듭니다.

Clarke Rodgers(15:13):
그리고 고객들은 수년간 사용해 온 모든 보안 도구와 기타 측면에서 쌓아온 신뢰를 바탕으로 이제 Bedrock과 같은 도구와 앞으로 출시될 다른 모든 도구에 적용할 수 있겠네요.

Paul, 오늘 함께 해 주셔서 감사합니다.

Paul Vixie(15:26):
좋은 시간이었습니다. 초대해 주셔서 다시 한 번 감사드립니다.