AWS와 고객의 보안 기준 강화

Clarke(10:27):
저는 AWS 보안에서 일하는 모든 개발자들이 반드시 탄탄한 보안 엔지니어링 배경을 가지고 시작하지는 않을 거라고 생각합니다. AWS 보안을 위해 설정하신 기준에 이런 개발자들이 도달하도록 하기 위해 어떤 메커니즘을 가지고 계신가요? 특히 빌더 도구나 고객 상대 보안 제품에서 말이죠.

Eric(10:50):
이 질문에 대해 생각해 볼 수 있는 몇 가지 방법이 있습니다. 한편으로 Amazon에서 보안은 빌더의 기본 원칙입니다. 우리는 해야 하는 일 모두를 할 수는 없습니다. 팀에 엔지니어를 추가하는 것 만으로 비즈니스를 확장할 수는 없어요. 그래서, 우리가 하는 일의 대부분은 도구를 만드는 것입니다. 보안 도구를 구축하는 일을 제외하고는, Amazon 내 다른 팀에서 당신이 하는 것과 마찬가지로 소프트웨어 개발이 그것입니다. 그래서 우리 엔지니어의 대다수는 보안 엔지니어가 아닙니다. 보안 배경을 가지고 있지 않아요. 이들은 팀에 합류하기 위해 특별한 보안 전문 지식을 가질 필요가 없습니다. 이 엔지니어들 중 일부는 보안에 열정을 가지고 있고, 일부는 다니고 있는 직장과 팀을 좋아하고, 하고 있는 일을 즐깁니다. 하지만 보안에는 특별한 관심이 없죠. 그래도 괜찮습니다.

Eric(11:37):
보안의 모든 영역은 어떤 빌더가 어떤 가정을 했는지 알아내고, 시스템을 예상치 못한 상태로 만들기 위해 이러한 가정을 위반하는 방법을 찾아내는 것에 있습니다. 하드 드라이브 전체만큼의 데이터를 이 필드에 넣으면 어떻게 될까? 다이얼을 11까지 돌리면 어떻게 될까? 이 필드에 음수를 입력하면 어떻게 될까? 그리고 제 경험상, 이런 생각을 하는 사람들은 선천적으로 그렇게 생각하는 경향이 있습니다. 이런 사고 방식을 가르치는 건 무척 어렵죠.

Eric(12:18):
따라서 우리가 이런 사고 방식을 가진 사람을 찾아내기만 하면, 모든 특정 보안 지식과 일상적인 기술은 우리가 가르칠 수 있습니다. 이 사람들에게서 지식은 아주 쉽게 늘릴 수 있습니다. 제가 지금 매일 하는 일들은 제가 대학에 다닐 때는 존재하지 않았습니다. 그래서 대학에서 배운 기초적인 것들은 여전히 적용되지만, 특정한 기술은 어떤 것도 적용되지 않습니다. 그래서 우리는 실제로 그 특정한 보안 기술을 가진 사람들을 늘리기 위한 강력한 프로그램을 가지고 있습니다.

Eric(12:46):
따라서 그 질문에 대한 답은 두 가지입니다. 보안 지식을 늘릴 필요가 없는 사람들이 있습니다. 일반적인 개발 작업입니다. 일반적인 빌더 역할입니다. 엑셀을 사용해서 일하는 사람들이죠. 그리고 이 사람들 중 일부는 보안에 관심을 보입니다. 그건 좋은 일입니다. 이를 장려하고 있고요. 하지만 필수적인 건 아닙니다. 다른 한편에서는, 망가뜨리는 방법을 알아내고 싶어하는 사람들을 찾습니다. “어떻게 하면 망가뜨릴까?”라는 질문은 자연스럽게 “그럼 다시 망가지지 않도록 하려면 어떻게 고쳐야 할까?”로 이어집니다. 거기에 따르는 모든 업무 관련 기술은 우리가 가르칠 수 있습니다.

Clarke(14:03):
그래서 그 관점에서, 혹은 반대의 관점에서, 많은 고객이 자체 개발 커뮤니티를 통해 보안 전문 지식을 구축하려고 할 때 따라야 할 방법 중 하나는 보안 전문가를 데려와 ‘정규 개발 팀’에 배치하여 팀 내 보안 기준을 구축하는 것과 기본적으로 보안 챔피언의 사고 방식을 갖도록 지원하는 것입니다. 즉, 보안 전문가의 수는 한정되어 있기 때문에 우리는 개발 팀을 통해 이들을 분산시키려 노력하고, 결국에는 모두가 이득을 얻습니다. 이는 AWS와 Amazon에서 우리가 사물을 보는 방식이 비슷하다거나, 또는 보안이 우리 정신에 내재되어 있기 때문에 모든 사람이 “나는 내 애플리케이션의 보안에 어느 정도 책임이 있으니, 프로세스를 따를 거야.”라고 깨닫는 것과 비슷한 것인가요? 이게 어떻게 작동하는지 얘기해 주실 수 있을까요?

Eric(14:58):
예. 보안은 최우선 순위입니다. 우리는 기본적으로 확장성, 가용성, 낮은 지연 시간, 낮은 지터와 마찬가지로 보안이 고객 경험의 일부라고 생각합니다. 우리가 구축하는 모든 것의 일부죠. 즉, 보안 전문 지식은 흔치 않습니다. 보안 엔지니어는 우리가 원하는 만큼 많지 않습니다. 제 말은, 우리가 가진 모든 개발자가 보안 전문가이기도 하다면 정말 좋을 것입니다. 기대하고 있다는 건 아닙니다. 보안 챔피언이라는 용어를 사용한 것은 흥미롭다고 생각하는데, 우리 내부에서 진행하는 프로그램의 이름과 똑같기 때문입니다. 이 프로그램에서 우리는 서비스 팀 내의 보안 사고 방식을 지닌 사람들을 찾고, 이들에게 교육을 제공하며, 보안 기술을 향상시킬 수 있도록 지원하여 이들이 서비스 팀 전체에 영향을 줄 수 있도록 합니다.

Eric(16:38):
그리고 중요한 결정이 내려졌을 때, 그들이 고독한 입장을 취하며 “저는 여기 유일한 보안 챔피언으로서 이것이 출시될 준비가 되지 않았거나, 이러한 추가 작업을 해야 한다고 느낍니다.”라고 말할 필요가 없습니다. 그들에겐 의지할 수 있는 이러한 전체 보안 조직이 있으며, 우리는 고객에게 무엇이 적합한지 알아내기 위해 고객 중심주의의 입장에서 협력할 수 있습니다. 안전하지 않은 서비스를 배포하면 고객에게 좋지 않은 결과가 생기지만, 만약 서비스를 배포하지 않는다면... 존재하지 않는 서비스에 기뻐하는 고객은 없는 것처럼, 우리는 적절한 균형을 맞춰야 합니다. 그리고 보안 전문 지식을 서비스 팀 내에 투입함으로써 서비스 팀에 깊이 공감하고, 그리고는 AWS 보안 팀의 보안 전문 지식이 서비스 팀에 대한 공감과 동시에 좀 더 감사자 역할에 가깝게 작용하여 더 나은 결정을 더 신속하게 내릴 수 있습니다.

Clarke(17:28):
그게 상황을 완화시킬 것 같네요... 다시 돌아가서, 저와 이야기했던 여러 고객들에 의하면 보안 부서는 ‘반대’를 주로 하는 부서로 간주되거나, 애플리케이션을 출시하려면 피해야 하는 부서라는 것입니다. 방금 말씀하신 이 모델을 통해서 신뢰의 다리가 확장되고 모든 사람이 “보안은 업무의 일부고 이게 우리가 Amazon에서 일하는 방식이지.”라고 깨달은 것처럼 보입니다. 결과적으로는 더욱 안전한 제품이 출시되는 것이죠.
 
Eric(18:00):
그래서 우리는 이전에 강령을 만들려고 했습니다. 예를 들어, AWS 보안은 무슨 일을 하나요? 같은 것이죠. 우리가 생각해낸 가장 좋은 대답은 ‘안전하게 배포’하는 것입니다. 이것은 두 단어이고, 우리의 존재 이유를 표현하는 데 적절한 말이라고 생각합니다. 회사는 보안을 위해 존재하지 않습니다. 회사 이름은 Amazon Web Services지, Amazon Security가 아닙니다. 우리는 이 웹 서비스를 고객에게 배포하기 위해 있습니다. 배포하지 않으면, 일하지 않는 것입니다. 우리가 비즈니스에 필요한 일을 하고 있지 않는 것입니다. 따라서 우리는 비즈니스를 가능하게 하기 위해 여기 있습니다. 우리는 비즈니스의 존재 이유가 아닙니다. 그리고 바람직한 보안이 없다면 이런 비즈니스를 가질 수 없습니다. 우리는 그저 비즈니스의 한 측면일 뿐이죠.
 
Eric(18:44):
그리고 우리에게 가장 중요한 것은 경영진의 후원입니다. 분명히 보안은 정말 중요한 일이고, 이는 위에서부터 아래로 내려옵니다. 그래서 “우리는 보안 팀입니다. 저희 말을 들으셔야 합니다. 제발, 제발 좀 집중해 주세요...” 이런 말을 하지는 않죠. 그런 문제는 없습니다. CEO에서부터 아래로 그런 분위기가 조성되었습니다. 보안이 중요하다는 것을 모두가 알고 있죠.
 
Clarke(20:04):
감사합니다. 그러면, 특히 AWS에서 코드를 작성하는 개발자 및 다른 사람들과 함께 보안 프로그램을 측정하는 경우, AWS의 개발 커뮤니티 전체에서 보안 프로그램의 효율성을 측정하는 데 사용되는 주요 지표는 무엇인가요?
 
Eric(20:57):
우리가 지표를 적용하는 두 곳이 있습니다.
 
Eric(21:43):
티켓을 종료하는 시간은 측정하지 않는 게 좋습니다. 티켓을 종료하는 데 걸리는 시간은 티켓 해결에 걸리는 시간에 좌우됩니다. 우리가 중요하게 측정하는 것은 우리의 반응성입니다. 그래서 처음 계약할 때 SLA가 있습니다. 예를 들어, AWS-security에 이메일을 보내는 경우 24시간 내에 담당자로부터 응답을 받을 수 있다고 공개적으로 명시해 놓았습니다. 그리고 우린 그것을 측정합니다. 실제로 우리는 ‘이메일을 보낸 사람들에게 답장하는 데 걸린 시간’을 보여주는 그래프와 차트를 매주 봅니다. 그래서 반응성은 정말로 중요합니다. 첫 번째 이유는, 반응성이 낮다면 사람들로부터 신뢰를 잃습니다. 두 번째 이유는, 반응성이 높다면 다른 좋은 일이 일어나고 있다는 것을 의미합니다.
 
Eric(22:25):
비슷한 생각이 적용되는 다른 경우는 티켓 처리가 지연되는 경우입니다.
…
모든 것이 티켓입니다. 따라서 티켓팅 시스템에 내장된 수많은 자동화 기능을 통해 티켓 처리가 지연되는지 확인할 수 있고, 서비스 팀에서 통신 간에 걸리는 시간과 보안 팀에서 통신 간에 걸리는 시간을 모두 측정하여 언제 티켓 처리가 지연되는지, 서비스 팀에 의해 보안 팀의 처리가 지연되는지, 보안 팀에 의해 서비스 팀의 처리가 지연되는지를 파악하여 매우 신속하게 즉각적인 주의가 필요한 티켓을 표시되게 할 수 있습니다. 게다가 이러한 데이터를 참고하여 어떤 프로세스가 작동하지 않는지, 인력을 교체해야 하는 곳이 어딘지, 도구 개선에 투자해야 하는 곳이 어딘지를 파악할 수 있습니다. 그리고 보안에 관한 프로세스를 측정하여 올바른 보안 결과를 실제로 도출했습니다.
 
Eric(23:20):
우리가 적극적으로 측정하는 다른 부분은 정확성에 대한 것이 아닙니다. 우리는 좋은 서비스를 설계하기 위해 애플리케이션 보안에 막대한 시간을 쓰지만, Amazon은 아무 것도 출시하지 않고 그저 내버려 둡니다. 우리는 지속적으로 기능을 추가하고 고객 피드백에 응답하며, 서비스는 해당 피드백에 따라 빠르게 변경됩니다. 따라서 우리의 목표는 안전하게 출시하는 것이 아니라, 서비스의 수명 동안 안전하게 유지하는 것입니다. 즉, 초기 애플리케이션 보안을 검토하는 동안 수행한 것들은 빠르게 노후화되고 가치를 잃게 됩니다. 따라서 애플리케이션 보안 프로세스의 일부는 우리가 서비스에 대해 항상 변치 않을 것으로 믿는 불변성 및 문장을 결정한 후 코드의 변형에서 이를 검증할 방법을 알아내는 것입니다.
 
Eric(24:10):
따라서, 서비스가 항상 이러한 형식의 요청을 거부해야 한다면, 해당 서비스를 특정 형식의 요청으로 호출하는 카나리(canary)를 프로덕션에 상주시켜 요청이 거부되게 해야 합니다. 그리고 카나리를 측정합니다. 해당 카나리가 적용되는 서비스 범위는 어느 정도인가? 얼마나 자주 실행되는가? 얼마나 자주 실패하는가? 비정상적인 결과가 얼마나 자주 발생하는가? 그리고 이러한 프로세스를 측정하여 우리의 보안 상태를 검증합니다. 제공되는 보안을 측정하는 것이 아닙니다. 그건 측정하기 어렵습니다. 하지만 이것은 우리가 이미 설정한 보안 기준에서의 회귀를 측정하는 것입니다. 또 다른 보안 문제는 항상 존재하기 때문에 이는 매우 중요합니다. 우리 팀은 혁신적이며, 이전에는 확보할 필요가 없었던 새롭고 혁신적인 서비스를 계속해서 생각해냅니다. 저를 매일 출근하게 만드는 이유 중 하나죠.
 
Clarke(26:00):
멋지군요. 그럼 이와 관련된 질문인데요, 고객의 관점에서 보면 우리 고객 중 일부는 매우 발전했고, 프로덕션에 대한 CICD 파이프라인을 통해 코드로 인프라를 구축하고 있습니다. 한편으로는 콘솔에서만 포인트 앤 클릭 활동을 하는 고객도 있습니다. 제 경험에 따르면 우리 고객의 대부분은 그 중간쯤에 위치해 있고 ‘nirvana’ 코드로 인프라를 구축하려 하고 있습니다. 인프라 실행의 포인트 앤 클릭 운영 측면보다는 엔지니어링에 더 중점을 두도록 고객 리더십에 대해 어떤 조언을 해 주시겠습니까?
 
Eric(26:42):
저는 아름다운 것을 만들어 본 적이 없습니다. 저는 AWS 서비스의 공개 marketplace나, 서비스 팀 및 다른 Amazon 직원들이 고객인 내부 marketplace에서 큰 성공을 거둔 것들을 만들었고, 이를 자랑스러워합니다. 하지만 이것들은 모두 핵심 아이디어에서 시작한 시스템이고, 우리는 고객을 만족시킬 수 있는 가장 최소한의 것을 구축하여 이를 가능한 한 빨리 반복했습니다. 그리고 이런 것들이 점점 성장했습니다. 그 반복이 훌륭한 도구를 가져다 주었습니다. 주변 사람들은 이 도구가 프랑켄슈타인의 괴물과 같다고 생각합니다. 철사와 덕트 테이프로 감은 쓰레기 조각 같죠. 맥가이버가 만든 듯합니다. 하지만 사실은 매우 훌륭한 도구입니다. 놀랍도록 효과적이죠. 그리고 이 도구들은 자신의 목적을 위해 만들어졌기 때문에 해야 할 일을 실제로 차근차근 수행합니다.
 
Eric(27:42):
따라서, 팀에 합류하든, 내부적으로 어떻게 일할지에 대해 고객과 이야기를 하든, 누군가가 들어오면 우리가 가진 일련의 도구와 우리가 구축한 이 모든 메커니즘을 보게 됩니다. 매우 압도적이죠. 복제할 수 없을 것 같아 보입니다. 첫째, 복제할 필요가 없습니다. 특정한 보안 문제를 처리하기 위한 것이기 때문입니다. 둘째, 우리가 이것들을 만든 게 아닙니다. 처음에는 모두 작은 상태로 시작했고, 시간이 지나며 우리가 성장시킨 것입니다. 이것이 점진적인 접근 방식입니다. 우리가 지표에 대해 얘기할 때, 회귀하지 않는 것에 대해 말했었죠. 즉 같은 문제를 두 번 풀 필요가 없다는 뜻입니다. 그러니 매일 매일 성장하세요. 매일 보안 기준을 점진적으로 높이면 기하급수적인 발전이 나타납니다.
 
Clarke(29:34):
그럼, 이걸 보는 고객을 위해서 정리하자면, 모든 것에 대한 접근 방식을 하루 아침에 전부 바꾸는 것보다는 엔지니어링의 작은 노력으로 시작해서 시간이 지남에 따라 점점 성장하고 개선해야 한다는 뜻인가요?
 
Eric(29:48):
물론입니다. 이러한 점진적인 사고 방식은 항상 이익으로 돌아오죠. 그리고 다른 한편에서는 비관적이지 않은 보안 전문가와 협력해야 합니다. 우리는 매일 위험에 둘러싸여 있습니다. 도로를 건너는 것, 운전하는 것, 랩톱을 네트워크에 연결하는 것 모두 위험한 일입니다. 그래서 우리는 적절한 위험을 감수하는 것에 익숙해져야 합니다. 따라서 보안은 개인적으로는 과학에 좀 더 가까웠으면 하지만, 예술이라고 생각합니다. 이러한 위험을 관리하고, 어떤 위험이 허용되는지, 어떤 위험을 완화할 수 있는지, 어떤 위험은 절대 허용될 수 없는지를 이해하는 것 모두가 말이죠. 그러므로 어떤 역할이든, 어느 곳에서든 보안 위험이 있다면 보안 전문가로서 당신은 이러한 위험이 얼마나 심각한지 말할 수 있어야만 합니다.
 
Eric(30:38):
보안 조직에서 보안에 대해 말할 때 사용하는 문구는 항상 간소하고 정확합니다. 만약 “이번 보안 취약점은 사상 최악입니다. 우리가 고칠 수 있는 게 없네요.”라고 말한다면, 신뢰도에 막대한 피해를 입을 뿐입니다. 모든 토론 영역을 닫는 것입니다. 더 이상 앞으로 나아가는 길에 대해 협상하지 않게 됩니다. 그저 끝내버린 거죠. 만약, 대신에 “정말 우려되는 문제로군요. 특정한 영향이 걱정되네요.”라고 한다면, 앞으로 나아갈 수 있는 세 가지 길이 있습니다. 개인적으로는 첫 번째를 선호하는데, 비용이 더 들지만 이런 이점이 있습니다. 우리가 여기서 해야 하는 일에 대해 이야기해 봅시다. 이는 간단하고, 정확하고, 대화의 장을 열어 줍니다. 비즈니스에 대한 대화를 할 수 있도록 내 전문 지식을 제공하겠습니다. 그리고, 이러한 보안 도구를 구축한 엔지니어는 이를 마음에 새겨야 합니다. "이런, 다 망했어. 끔찍하네."가 아니라, “어떻게 비즈니스를 더 좋게 만들 수 있을까?”라고 생각해야 합니다.