AWS의 규정 준수 및 보안 보증 확대

Clarke(00:05):
Chad 님, 오늘 함께 해 주셔서 감사합니다.

Chad(00:07):
불러 주셔서 감사합니다.

Clarke(00:09):
그럼 본인의 이력과 AWS에 입사하게 된 계기에 대해 말씀해 주실 수 있을까요?

Chad(00:14):
예. AWS에서 근무한 지 약 11년 됐고, 2010년부터 보안 및 규정 준수 업무를 맡고 있습니다. 그 전에는 EY에 있었고, 그곳에서 많은 보안 컨설팅 및 비즈니스 연속성 컨설팅 업무를 했습니다. 이러한 배경이 지금 제가 하는 일인 AWS 보안 규정 준수 업무에 정말 많은 도움을 주었습니다.

Clarke(00:43):
그럼 AWS의 보안 보증 책임자로서 주로 담당하고 계신 일이 무엇인가요?

Chad(00:49):
우리의 주요 목표와 사명은 우리의 고객이 규제되고 매우 민감한 데이터를 클라우드로 이전하는 과정과 그 과정에 따르는 다른 과제를 지원하는 것입니다. 우리 환경에서 보안을 확보했음을 내부적으로 입증할 수 있어야 합니다. 또한 AWS를 감사해야 하며, 공급업체에게 AWS가 안전함을 확인시켜 줘야 합니다. 그래서 우리가 있는 것입니다. 우리는 감사, 인증, 그리고 직접적인 감사 계약을 통해 우리가 배경에서 진행하고, 고객이 볼 수 없는 사항들에 대해 보안이 유지되고, 우리가 준수하는 모든 다양한 종류의 규제 및 인증 표준을 준수함을 입증합니다.

Clarke(01:35):
그럼 AWS 서비스가 특정 기준을 충족함을 확인하는 내부 팀과 내부 규정 준수 팀이 있다는 것이군요. 외부의 타사 감사자 및 규제 담당자와 함께 일하기도 하나요?

Chad(01:46):
예. 예. 우리 업무의 대부분은 외부 감사자, 규제 담당자, 규제 담당자의 조사관, AWS에서 감사도 수행하는 고객과의 외부 계약과 관련되어 있습니다. 그들은 우리에게 자체 실사를 수행합니다.

Clarke(02:03):
그렇군요. AWS는 현존하는 가장 큰 스타트업으로 유명합니다. 그리고 매우 빠르게 움직이며, 고객이 요청할 때나 요청한 후 가능한 한 빠르게 제품 및 기능을 출시합니다. 하고 계신 업무에는 여러 통제가 존재하고, 모든 것이 완벽해야 할 것 같은 생각이 듭니다. 우리, 특히 당신의 팀은 어떻게 계속해서 빨리 움직여야 하는 요구를 충족하며 동시에 규정 준수 및 보안 보증 목표도 충족할 수 있나요?

Chad(02:35):
좋은 질문입니다. 그리고 우리가 끊임없이 맞닥뜨리는 과제이기도 합니다. 우리는 빠르게 움직이고, 빠르게 반복하고, 고객에게 좋은 제품을 출시하는 문화를 진정으로 지켜나가고 싶습니다.

Chad(02:53):
이는 가끔 우리가 하고자 하는 일과 상충됩니다. 즉, 절차가 문서화되고, 제어가 문서화되며 FedRamp나 ISO 등과 같은 큰 포괄적인 규정 준수 프레임워크에 필요한 모든 제어를 갖추는 것입니다. 여기에는 이러한 모범 사례에 대한 업계의 기대치에 맞는 포괄적인 제어 프레임워크 및 절차가 필요합니다. 그래서 우리가 하는 일과 기존에 다른 회사들이 하는 일이 실제로 일치하지 않을 때, 이런 것들이 도전이 됩니다.

Chad(03:31):
하지만 여기서 일하는 것과 이 팀의 일부가 되는 것의 좋은 점은 보안이 최우선 순위가 되는 것이죠. 만약 보안을 제대로 유지하고, 보안에 투자할 수 있고 모두가 이것에 동의한다면, 나머지 규정 준수 업무는 꽤 간단해집니다. 쉽다고 말하려고 했는데, 실제로 꽤 간단합니다. 즉, 문서화할 수 있고, 모든 사람들이 하는 일을 따라갈 수 있고, 설명서를 공식화할 수 있고, 감사자와 규제 담당자에게 맞는 방식으로 절차를 문서화할 수 있다는 뜻입니다.

Chad(04:10): 
가끔 우리가 해야 하고 개선해야 하는 일들이 있습니다. 시간이 지남에 따라 감사자들은 우리가 하는 일을 더 깊이 조사하고, 우리는 상황을 개선하는 데에도 도움을 주고 있습니다. 하지만 주로 전술적 지점과 리더십 스폰서십 지점의 관점 모두에서 우리는 내부적으로 보안이 잘 유지되고 있기 때문에 실제로 우리 업무는 꽤 간단해집니다.

Chad(04:37):
그렇지만 우리 팀은 규정 준수 절차와 서비스 팀의 감사에 대한 부담을 덜어주기 위해 많은 일을 합니다. 할 수 있는 한 많이 하고 있죠. 그리고 이러한 일을 하고 점점 더 잘 할수록, 우리는 더욱 확장할 수 있고 더 많은 고객과 GO에 대한 이런 종류의 감사를 더 수행할 수 있습니다.

Clarke(05:00):
그런 절차를 가져와서 잘됐군요. 많은 고객들은 고군분투하고 있습니다. 아시다시피, 고객들은 그들의 고객이 사용할 수 있는 애플리케이션을 가지고 있고, 그것을 감사해야 합니다. 가끔 애플리케이션을 작성하고, 운영한 뒤 감사 팀이 이를 조사하여 어떤 표준을 충족한다는 것을 확인해야 합니다. 저는 우리가 운영하는 속도와 규모로 AWS 내 개발 절차 자체에 있어 모두를 지원하는 자동화된 아티팩트가 있을 수 있다고 생각합니다.

Chad(05:33):
예. 우리가 확장하면서 직면한 또 다른 문제는, 우리가 얼마나 많은 증거를 모을 수 있느냐는 것입니다. 개발 팀과 어떻게든 협력해야 하는 경우와는 달리, 우리는 이 증거를 스스로 얻을 수 없습니다. 상대가 우리를 위해 증거를 제공하거나 우리를 위해 감사자에게 말해 주어야 합니다.

Chad(05:58):
따라서 내부 개발자 고객에게 감사자가 보고 싶어하는 방식으로 문서화, 증거 수집, 작업 내용 정리 등의 서비스를 제공할 수 있으며, 이러한 능력이 향상될수록 우리는 더욱 확장할 수 있고, 다른 유형의 인증, 고객, 기타 GEO로 우리의 규정 준수 프레임워크를 확장할 수 있습니다.

Clarke(06:33):
그러면 당신의 팀 내에 증거를 수집하기 위한 코드를 실제로 작성하는 인재가 있나요? 그리고 그것을 하기 위해 자체 프로그램을 개발하나요?

Chad(06:40):
예, 좋은 질문이네요. 그리고 종종 고객들로부터 듣는 질문입니다. 예를 들어, 우리가 팀을 구성할 만큼 기술적 역량을 갖추고 있는가 하는 것이죠

Chad(06:50):
아시다시피, 우리는 팀을 갖추고 있습니다. 이러한 일을 하는 엔지니어링 팀을 갖추고 있죠. 일종의 제어 자동화 팀이고 증거 수집을 지원하는 등의 일을 하는 워크플로 팀과 같습니다. 이러한 팀이 있다는 것은 매우 중요합니다. 우리는 많은 개발자들과 함께 조직 내에서 그들의 언어로 말할 수 있어야 하기 때문에 이는 매우 필수적입니다. 그들의 언어를 말할 수 있어야 할 뿐만 아니라, 사용하는 도구도 알아야 합니다. 우리는 새로운 서비스를 제공하면서 그들이 어떻게 코드를 개발하는지, 어떻게 코드를 배포하는지, 어떻게 코드를 보호하는지, 출시하려면 무엇을 해야 하는지, 그들의 서비스, 업데이트 등을 운영화하려면 무엇을 해야 하는지 등을 이해해야 합니다. 우리는 이를 깊게 이해한 뒤 작동 방식에 연결하는 도구를 만들 수 있어야 합니다.

Chad(07:45):
저는 이것이 중요한 열쇠라고 생각합니다. 이렇게 하지 않으면, 아무도 이러한 지식이 없는 규정 준수 팀이나 프로그램이 결국 ‘이거 안 하면 큰 일 날 거야.’라고 말하는 듯한 규정 준수 사항 및 많은 요구 사항과 함께 다른 팀에 그 일을 넘겨 버리는 상황을 자주 볼 것입니다. 이런 식으로 확장하는 것은 좋은 방식이 아닙니다. 확장되지 않습니다. 그런 식으로는 될 수 없고, 실제로도 확장하지 않습니다. 확장하는 유일한 방법은 실제로 이들이 일하는 방식에 내장시킴으로써 규정 준수 관련 간섭과 같은 어떤 간섭도 없이 정상적으로 작업을 수행할 수 있도록 하는 것입니다. 만약 우리가 성공하면, 매우 크게 확장 가능한 규정 준수 프로그램이 될 것입니다.

Clarke(08:39):
사람들이 규정 준수 직원들을 모두 피한다는 얘기를 들은 적이 있는데 그보다 훨씬 협력적인 얘기로 들리네요. 이런 사람들과 함께라면 회사 내 카페 등에서 당신을 피하지 않을 것 같네요.

Chad(08:49):
그게 바로 좋은 점이죠. 기술 리더들이 종종 무엇이 필요한지, 저와 제 팀을 어떻게 지원할 수 있는지를 더 잘 이해하기 위해 저를 찾아올 것입니다. 왜냐하면 그들은 비즈니스의 이러한 부분, AWS의 규정 준수 관점은 우리 고객이 규제된 워크로드를 위해 우리를 이용하는 데 절대적으로 중요하다는 것을 알기 때문입니다. 그렇지 않으면 우리가 지원하지 못하는 고객층이 많을 것입니다. 이들은 이런 내용을 이해하므로, 라인을 더 잘 조정하고, 그들의 비즈니스를 지원하는 데 도움이 되는 리소스 등을 얻기 위해 저를 자주 찾습니다.

Clarke(09:34):
당신은 고객과 규제 담당자, 감사자를 많이 만납니다. 클라우드 서비스 제공업체를 어떻게 보고 그들을 어떻게 감사하는지에 관해 이러한 그룹에서 발견되는 추세가 있나요?

Chad(09:45):
5년 전만 해도, 저는 2020년이면 감사자들이 증거를 공유하여 우리가 증거를 계속해서 요구하지 않아도 되는 그런 상황이 올 것이라 생각했습니다. 아직은 전혀 실현되지 않았네요. 오히려, 감사자들은 물러서서 우리 증거는 우리의 것이고, 우리는 여러분의 환경을 주관적 및 객관적으로 살펴봐야 한다고 말하고 있죠. 우리는 우리 스스로 결론을 내릴 수 있어야 합니다. 누군가가 다른 사람에 대한 증거를 수집했더라도, 우리는 그것을 받아들이지 않을 것입니다. 우리는 자체 테스트와 자체 샘플링을 수행해야 합니다. 불행하게도 그게 그런 경우죠. 그래서 우리는 증거를 정말, 정말 잘 만들어야 하고 우리의 증거 생성 능력도 이에 맞추기 위해 발전했지만, 여전히 우리는... 말하자면, 이런 일이 쉽지 않다는 점에서 우리는 항상 더 발전할 여지가 있다는 것이죠.

Chad(10:35):
하지만 저는 전반적으로 사람들이 더 현명해지고 있다고 말하고 싶습니다. 사람들은 올바른 질문을 합니다. 더 심층적인 질문을 합니다. 우리는 이러한 모든 고객 감사자, 일반 감사자, 외부 감사자들에 대한 경험만으로도 점점 발전하는 중입니다.

Clarke(10:53): 저도 정확히 당신처럼 생각합니다. 클라우드는 더 이상 새롭지 않습니다. 그렇죠? 클라우드는 모든 곳에서 모든 사람들이 사용하고 있고, 따라서 사람들이 점점 더 많은 경험을 얻음으로써 어떤 질문을 해야 하는지 알게 되죠. 그래서 우리에겐 고객이 우리의 타사 증명을 확인할 수 있는, AWS Artifact와 같은 고객 대면 도구가 있습니다. 규제 담당자들에게 제공할 수 있는 다른 것이 있나요? 아시다시피, 이들은 고객이 될 수도 있고 아닐 수도 있죠. 이들을 만족시킬 수 있는 게 있나요?

Chad(11:23):
예.

Clarke(11:24):
우리의 제어에 관해서 말이죠.

Chad(11:26):
우선, AWS를 사용하고 있고 공급망을 검증하는 고객에게 하는 감사 방식은 매우 다릅니다. 왜냐하면 우리는 고객이 볼 수 없는 배경에서 우리가 하는 활동을 통해 이들이 어떻게 AWS를 사용하고 있는지를 맥락에 맞게 설명해야 하기 때문입니다. 그래서 이런 식으로 그들을 돕습니다. 그리고 이는 AWS를 사용하지 않는 규제 담당자일 경우보다 더 간단한 대화입니다. 그들은 우리가 어떻게 위험을 관리해야 한다고 생각하는지에 따라 질문하기 시작할 것입니다. 우리에겐 이러한 고객의 사용이 어떤 맥락에 있는지 알 수 없으므로 좀 더 어렵습니다. 그렇지 않나요?

Chad(12:10):
그래서 고객들이 우리에게 질문을 던지면 정말 도움이 됩니다. 고객들은 자신이 어떻게 AWS를 사용하고 있는지 말해 줍니다. 고객들은 사용 내용과 사용하는 공급망과 관련하여 규제 담당자에게 어떤 점을 강조할 필요가 있는지에 대해 기본적으로 설명해줍니다. 그래서 이들을 도와 올바른 방향으로 이끌 수 있습니다. 이는 매우 바람직하고 긍정적인 파트너십이죠.

Chad(12:35):
규제 담당자들은 좀 더 광범위하고 맥락 없는 질문을 하는 것 뿐입니다. 이는 또 다른 어려운 일이죠. 하지만 우리는 여전히... 예를 들어, 우리가 지난 몇 년간 했던 것 중 하나는, 우리의 감사자들, 규제 담당자들, 고객 감사자들을 진짜 파트너처럼 대하는 것이었습니다. 인터뷰 초반에 말씀하셨던 것처럼, 일반적으로 많은 고객이나 사람들은 규정 준수를 다루고 싶어하지 않습니다. 규제 담당자가 여기 왔습니다. ‘오, 이런. 문 닫자.’ ‘모두 조용히 해. 아무 것도 말하지 마.’ 이런 식이죠. 이는 정말로 두 조직 사이에 일종의 장벽을 만듭니다. 저는 이러한 장벽이 어디에서나 존재한다고 생각합니다. 특히 큰 은행과 규제 담당자, 또는 의료 서비스 회사와 규제 담당자 같은 경우에서요.

Chad(13:26):
파트너십의 수준은 다양하고, 가끔 우리는 우리 고객과 함께, 조사관 및 감사자와 진정한 파트너십을 맺는 것을 봅니다. 조사관과 감사자도 고객이기 때문에 서로 도울 수 있습니다. AWS를 사용하지 않더라도, 이해하고 달성해야 할 것이 있습니다. 또한 그들이 원하는 것을 달성하도록 적극적으로 지원하면 더욱 빨리 진행되며 더 좋은 경험을 얻을 수 있습니다. 그래서 우리는 진정한 파트너가 되는 것과 긍정적인 방식으로 관계를 맺는 것이 실제로 미래에 이 모든 것을 확장시킬 수 있는 가장 좋은 방법이고 아마 유일한 방법이라는 교훈을 배웠습니다.

Clarke(14:12): 
그럼 같은 맥락에서, 규제 담당자 및 타사 감사자들이 클라우드를 더 잘 이해하고 감사할 수 있도록 어떤 메커니즘과 교육 자료를 제공하고 있나요?

Chad(14:28):
이제 그들이 클라우드에 대해 아무것도 모르는 시대는 지났다고 생각합니다. 2012년에 S3의 GM이 감사 회의에 참석했는데, 감사자들은 S3가 무엇인지 물었습니다. 그리고 나서 그가 저를 한쪽으로 끌어당기며 말했습니다. ‘왜 이런 매우 기본적인 질문을 저에게 하는 거죠?’ 이런 시대는 이미 지났죠.

Chad(14:54):
제 말은, 저 밖에 아주 많은 자료들이 있다는 것입니다. 클라우드 아카데미와 같은 자료뿐만 아니라, 클라우드에 구애받지 않는 교육인 우리가 개발한 자료, AWS 특정 교육도 있습니다. 클라우드에 대한 더 좋은 교육, 지식, 이해는 밖에 많이 있습니다. 그래서 우리는 더 이상 출발점에 있지 않습니다. 다른 누가 들어올 때는 출발점에서 한 걸음 앞에 있거나, 심지어 두 걸음 앞에 있을 수도 있습니다.

Chad(15:21): 
우리는 이러한 조사관과 감사자의 수를 계속 늘릴 수 있도록 도와야 하며, 우리에게는 내부 자료가 있습니다. 우리는 많은 이야기와 제어 관련 이야기, 제어 기능 소유자 및 GM이 그들의 서비스를 운영하는 방법과 제어 관련 이야기를 하는 프레젠테이션 등이 있는 디지털 감사 심포지엄을 진행합니다. 우리는 이러한 많은 것들을 이용할 수 있지만 한계는 있습니다. 왜냐하면, 제가 말했듯이 감사하러 오는 사람들은 자체적인 질문을 할 것이며 더욱 깊게 파고들 것이고, 우리는 즉석에서 인터뷰 형식으로 대답해야 하기 때문입니다. 이건 일종의 업계 표준일 뿐입니다. 하지만 우리가 더 많은 내러티브를 써나가므로 상황은 더욱 나아지고 있습니다. 아주 구체적이고 심층적인 무언가에 대한 질문을 받을 때마다 그것에 대해 이야기하고, 내러티브를 쓸 것이기 때문입니다. 그래서 다음 사람이 우리에게 묻는다면, 이미 내러티브는 준비되어 있을 것이고, 이들은 더 쉽게 읽을 수 있고 이해할 수 있을 것입니다.

Clarke(16:25):
Chad 님, 오늘 함께 해 주셔서 감사합니다.

Chad(16:27): 
좋은 시간이었습니다. 감사합니다, Clarke 님.