클라우드 사고 대응을 위한 구급대원의 2대 조언

독특한 취미를 많이 가지면 좋은 점 중 하나는 뇌의 회로가 조금 다르게 구성된다는 것입니다. 서로 다른 영역이 머릿속에서 교차 오염되면서 문제를 다른 각도에서 바라보게 됩니다. 반쯤 현역인 구급대원으로서, 저는 살덩이 응급 상황에 대응하는 일과 비트와 바이트의 응급 상황을 관리하는 일 사이에서 수많은 공통점을 발견합니다.

저는 지난 몇 년간 클라우드 사고 대응을 많이 가르쳐 왔고, 구급대원 세계에서 쓰는 두 가지 표현을 사용하기 시작했는데 이제 막 사고 대응을 시작한 분들에게 잘 와닿는 것 같습니다. 이 기억 보조 문구들은 초점을 다듬고 프로세스를 최적화하는 데 큰 도움이 됩니다. 어떤 사고 대응에도 적용되지만, 주로 관리 플레인의 존재에서 비롯되는 본질적인 차이 때문에 클라우드 쪽에서 더 큰 역할을 한다고 봅니다.

중증인가 아닌가

구급대원은 일반인에 비하면 할 수 있는 일이 많지만, 의료의 영역에서는 상당히 제한적입니다. 저희는 의학적 문제든 외상이든 생명과 사지를 위협하는 요소를 신속하게 인지하고, 환자를 안정시켜 최종 치료 기관으로 이송하도록 정교하게 훈련받습니다. 저희에게 끊임없이 주입되는 핵심 문구 하나가 "중증인가 아닌가"입니다. 큰 그림에 집중하고 환자가 심각한 곤경에 처해 있는지 판단하도록 상기시켜 주는 기억 보조 문구입니다.

저는 정보보안 전문가가 사고의 심각도를 가늠하는 데 이 표현을 활용하는 것을 매우 좋아합니다. 클라우드의 경우, 다음 단계로 넘어가기 전에 그 자리에서 즉시 파고들어야 하는 중대한 발견 사항을 식별하도록 가르칩니다. 응급의료에서는 이를 "생명 위협"이라고 부릅니다. 클라우드 사고 대응은 기존 IR 역량을 새로운 기반 기술 위에서 활용하는 것이므로, 이 표현은 평소라면 대응자의 직감을 자극하지 않을 발견 사항의 결과를 고려하도록 상기시켜 주는 역할을 합니다. 간단한 예를 들면 다음과 같습니다.

• 공개되어서는 안 되는 데이터가 객체 스토리지(S3)에서 공개된 경우.
• 관리자 권한 또는 기타 높은 권한을 가진 IAM 엔터티가 침해되었을 가능성이 있는 경우.
• 동일한 미확인 IP 주소에서 서로 다른 IAM 사용자를 사용해 여러 건의 API 호출이 성공한 경우.
• 이미지나 스냅샷이 알 수 없는 계정과 교차 계정으로 공유된 경우.
• IAM 권한을 가진 인스턴스/VM이 침해되었을 가능성이 있는 경우.

이렇게 적어 놓으면 대부분의 대응자는 "당연한 얘기 아닌가"라고 반응합니다. 하지만 제 경험상 전통적인 대응자들은 이러한 문제를 인지하고 이것이 일반적인 침해된 가상 머신보다 훨씬 더 치명적이라는 사실을 깨닫기까지 약간의 시간이 필요합니다.

클라우드에서 "중증인가 아닌가"는 거의 언제나 "공개되었는가, 아니면 공격자가 관리 플레인(IAM)으로 넘어갔는가"로 귀결됩니다.

중증인가 아닌가. 새로운 증거, 새로운 퍼즐 조각을 발견할 때마다 이 질문을 머릿속으로 되뇌며 환자가 곧 무너질 상태인지, 아니면 그저 콧물이 나는 정도인지 판단하십시오.

출혈을 멈추라

여러분 중 다수는 아마 심폐소생술과 응급처치 교육을 받아 보셨을 것입니다. 아마도 "ABC", 즉 기도(Airway), 호흡(Breathing), 순환(Circulation)을 배우셨을 것입니다.

그런데 알고 보니 그 부분을 정말 크게 잘못 가르쳤습니다.

연구 결과에 따르면 응급 상황에서 사람들은 큰 그림을 놓친 채 ABC에만 집중하는 것으로 나타나기 시작했습니다. 심지어 구급대원조차 다리 상처로 과다 출혈 중인 환자에게 심폐소생술을 하고 있는 경우가 있었습니다. 때로는 완벽한 심폐소생술이었습니다. 환자의 혈액이 얼마나 빨리 소진되는지를 보면 알 수 있었죠. 요즘은 맨 앞에 "생명 위협 처치"를 추가하며, "출혈을 멈추라"가 최우선 순위입니다.

제가 어디로 가는지 보이시나요?

제가 가르친 모든 수업에서, 경험이 풍부한 대응자들이 눈앞에서 클라우드가 과다 출혈하는 동안 분석과 조사에만 몰두하는 모습을 봅니다. 왜일까요?

모든 것이 (잠재적으로) 인터넷에 노출되어 있는 환경에 익숙하지 않기 때문입니다. 관리 플레인 전체가 인터넷에 있으므로, 공격자가 자격 증명을 획득하면 방화벽이나 서버 접근 차단으로는 막을 수 없습니다. 무언가가 침해되고 노출되었다면, 그것은… 사실상 모든 곳의 모든 사람에게 동시에 침해되고 노출된 것입니다.

출혈을 멈추라는 원칙은 중증인가 아닌가와 짝을 이룹니다. 중증인 무언가를 발견했다면, 다음 단계로 넘어가기 전에 그 자리에서 즉시 격리해야 합니까? 잘못 판단하면 공격자가 계속 진행하는 동안 귀중한 시간을 낭비할 수 있기 때문에 섬세한 균형이 필요합니다. 출혈을 멈추라는 것은 "이건 너무 심각해서 지금 당장 해결해야 한다"는 뜻입니다. 다만 출혈을 멈춘 뒤에는 여전히 많은 악성 활동이 진행 중일 수 있으므로, 즉시 원래 지점으로 돌아가 분석과 대응 프로세스를 이어가야 합니다.

제가 꼽는 목록은 다음과 같습니다.

• 침해된 것으로 보이는, 높은 권한을 가진 모든 IAM 엔터티.
• 어떤 이유로든 공개된 민감 데이터.
• 알 수 없는 대상에 대한 교차 계정/구독/프로젝트 공유 또는 접근.

이 외에도 더 있지만, 핵심 목록은 이것입니다. 이들 각각은 진행 중인 데이터 유출 또는 침해를 의미하며 즉시 격리해야 합니다.

실제 적용 사례

다음은 한 가지 예시입니다. 스크린샷은 Slack, AWS 콘솔, FireMon Cloud Defense를 섞어 구성했습니다. 이것이 제 툴체인이며, 어떤 도구를 사용하시든 동일하게 적용됩니다. 교육 과정에서는 SIEM을 시뮬레이션하기 위해 Athena 쿼리도 사용하지만, 이 글은 (비교적) 짧게 유지하고자 합니다.

통합 CSPM/CDR 플랫폼에서 Slack으로 전달된 중간 심각도 경보부터 시작해 보겠습니다.

중증인가 아닌가? 아직 알 수 없습니다. 완전히 정상적인 활동일 수도 있습니다. 자, 조사할 시간입니다. 플랫폼과 AWS 콘솔 양쪽에서 보여 드리겠습니다. 첫 단계는 무엇이 어디에 공유되었는지 확인하는 것입니다. 경보에 AMI ID가 포함되어 있으므로 바로 해당 항목으로 이동할 수 있습니다.

자, 이것이 다른 계정과 공유되어 있음을 확인할 수 있습니다. 그 계정은 제가 소유한 계정입니까? 제가 아는 계정입니까? 제 도구는 시스템에 등록된 계정이 아니므로 신뢰할 수 없음으로 표시하지만, 실제 상황이라면 재확인을 위해 조직의 마스터 계정 목록을 점검하고 싶을 것입니다.

자, 중증인가 아닌가? 제 머릿속에서는 아직 '아마도'입니다. 잠재적으로 신뢰할 수 없는 계정에 공유된 이미지가 있습니다. 하지만 무엇이 공유되었는지는 아직 모릅니다. 이를 원본 인스턴스까지 추적해야 합니다. 전체 포렌식까지 수행하지는 않겠습니다. 상당히 빠르게 판단해야 하므로 맥락 정보에 의존하겠습니다. 이 경우에는 운이 좋았습니다.

이름에 "Prod"가 들어 있으므로… 저는 이를 "아마도 중증"으로 판단합니다. 출혈을 멈춰야 할까요? 실제 상황이라면 해당 AWS 계정의 소유자에게 먼저 연락하려 하겠지만, 오늘은 AMI를 격리하기에 충분한 정보가 있다고 봅니다. 콘솔과 Cloud Defense에서 하는 방법은 다음과 같습니다.

자, 출혈을 멈췄습니까? 출혈의… 일부를 멈췄습니다. AMI를 차단했지만, 그것이 어떻게 그곳에 이르게 되었는지는 여전히 모릅니다. 또한 그 AWS 계정의 소유자가 누구인지도 모릅니다. 알아낼 수 있을까요? 아니요. 우리 계정이 아니라면 할 수 있는 일은 AWS에 신고하고 나머지는 그들이 처리하도록 맡기는 것뿐입니다.

누가 공유했고 그 외에 무엇을 했는지 알아내기 위해 API 호출을 추적해 봅시다. 다음 단계는 플랫폼에서 진행하겠지만, 여러분은 SIEM이나 Athena에서 쿼리를 실행해 동일한 정보를 찾을 수 있습니다. 모든 쿼리에 대해서는 이후 글에서 다루겠습니다. 이 글은 중증/출혈 개념에 초점을 맞추고 있습니다.

자, ImageBuilder라는 IAM 엔터티가 원인임을 확인했습니다. 이 글이 이미 길어지고 있으므로, 제가 몇 가지를 확인한 결과는 다음과 같습니다.

• ImageBuilder는 이미지를 생성하고 그 속성을 수정할 수 있는 권한을 가진 IAM 사용자이며, 그 이상은 없습니다. 다만 정책에 리소스 제약이 없어 어떤 인스턴스의 이미지든 생성할 수 있습니다. 또한 조건 제약도 없어 어떤 계정과도 공유할 수 있습니다. 이는 중간에서 낮은 수준의 폭발 반경입니다. 과도한 권한이긴 하지만 끔찍한 정도는 아닙니다. 저는 이를 '어느 정도 중증'이라고 부릅니다.
• API 호출은 알 수 없는 IP 주소에서 발생했습니다. 의심스럽지만 여전히 '어느 정도 중증' 수준입니다.
• 이 IAM 사용자가 해당 IP 주소를 사용한 것은 처음이며, 이 사용자의 이전 활동은 배치 프로세스와 일치합니다. 자, 이제 중증 쪽으로 기울고 있습니다. 보통 이런 작업에서는 IP 주소가 계속 바뀌지 않습니다. 자격 증명 유출의 냄새가 납니다.

• 해당 IAM 사용자는 이러한 작업을 계속 수행할 수 있습니다. 누군가 의도한 작업이라고 알려 주지 않는 한, 저는 이를 중증으로 판단하고 출혈을 멈추라 해당 사용자 계정에 IAM 제한을 적용하겠습니다(중요한 프로세스가 아니라면 아마도 Deny All 정책, 중요한 프로세스라면 IP 제한을 사용할 것입니다).

요약하면 다음과 같습니다.

• 알 수 없는 계정에 공유된 AMI를 발견했습니다: 중증
• 해당 AMI는 프로덕션 자산의 것이었습니다: 중증이므로 출혈을 멈춤
• 이 작업은 AMI를 생성하고 공유할 수 있는 광범위한 권한을 가졌지만 그 외에는 권한이 없는 IAM 사용자가 수행했습니다: 중증일 수 있음, 조사 진행 중.
• 해당 IAM 사용자는 알 수 없는 새로운 IP 주소에서 그 AMI를 생성했습니다: 중증, (나머지) 출혈을 멈춤.
• 해당 IP 주소에서 탐지된 다른 활동이 없습니다: 봉쇄되었을 가능성이 높으며 더 이상 위중하지 않음
• 해당 자격 증명이 어떻게 유출되었는지 아직 알 수 없습니다: 위중하며, 네트워크 침해인지 호스트 침해인지 확인하기 위해 기존 IR 담당자들을 호출할 시점입니다.

제가 이러한 문제를 어떻게 바라보는지 보여드리기 위해 이 과정을 빠르게 살펴보았습니다. 몇 가지 차이만 있었다면 동일한 탐지 결과가 완전히 정상으로 판단되었을 수 있습니다. 우리가 관리하지만 아직 등록되지 않은 신규 계정과 공유된 것으로 확인되었다고 가정해 봅시다. 또는 해당 AMI가 민감한 정보가 전혀 없는 개발용 인스턴스의 것이었을 수도 있습니다. 또는 API 호출이 우리 네트워크에서, 예상된 시간에, 혹은 관리자 시스템에서 발생했고 의도적으로 공유한 것일 수도 있습니다. 이 사례가 극단적인 것은 아니지만, 알려진 데이터 유출 방식으로, 실제 위협 행위자들이 사용하고 있습니다. 저는 각 정보를 확인할 때마다 위중한지 위중하지 않은지, 그리고 출혈을 멈춰야 하는지를 판단합니다.

클라우드에서는 무엇이 다를까요? 모든 것이 잠재적으로 인터넷에 연결되어 있어 위험 부담이 더 크기 때문입니다. 더 빠르게 판단하고 행동해야 하며, 이 기억법이 방향을 잃지 않는 데 도움이 된다고 생각합니다.