정책 리스크를 파악하십시오. 정책에 대한 질문을 일상 언어로 하십시오. 데모 신청하기 →

Published:

슈뢰딩거의 잘못된 구성

by FireMon

목요일 오후, 조금 일찍 퇴근할 준비를 하고 있습니다. 그럴 수 있으니까요. 그런데 그 성가신 알림 배달부(Slack이라고도 합니다)가 보안 경고 채널에 새 메시지를 띄웁니다.

스토리지 볼륨 스냅샷이 퍼블릭으로 설정되었다는 알림.

이런. 누군가 방금 스토리지 볼륨의 스냅샷을 퍼블릭으로 설정했습니다. 공격일까요? 실수일까요? 아니면 정책이 무엇인지 모르는 사람일까요?

잘못된 구성에는 세 가지 상태가 있습니다

저는 이것을 슈뢰딩거의 잘못된 구성 이라고 부르기 시작했습니다. 양자역학의 원리를 빌려 정보보안을 설명하는 나쁜 버릇이 있기 때문입니다. 슈뢰딩거의 고양이, 즉 에르빈 슈뢰딩거가 양자 중첩의 역설을 알베르트 아인슈타인에게 설명하기 위해 사용한 저 유명한 사고 실험을 모르신다면 오히려 놀랄 것입니다. 아주 간단히 말하면, 방사성 붕괴로 작동하는 독극물과 함께 고양이를 상자에 넣어두면 그 고양이는 살아 있지도 죽어 있지도 않으며, 따라서 상자를 열어 확인하기 전까지는 살아 있으면서 동시에 죽어 있는 상태에 있다는 것입니다.

네, 터무니없습니다. 바로 그게 요점이었습니다. 특히 상자에 갇히는 것을 절대 좋아하지 않는 고양이를 키우는 사람들에게는 더욱 그렇습니다. 고양이가 스스로는 상자에 기어 들어가면서도 사람이 상자에 넣으면 몹시 화를 내는 것에 대해 블로그 시리즈를 통째로 쓸 수도 있겠지만… 이야기가 샜습니다.

다시 클라우드 보안으로 돌아가겠습니다. 이 사고 실험의 근본 개념은, 어떤 것이 관측되기 전까지는 여러 상태에 동시에 존재하며 관측이라는 행위가 답을 확정한다는 것입니다. 물론 저는 제 목적에 맞게 왜곡하고 단순화하고 있으니, 물리학을 전공하신 분들은 항의 이메일을 보내지 말아 주시기 바랍니다.

이 개념의 클라우드 버전은, 특정한 잘못된 구성이 조사를 통해 원인을 규명하기 전까지는 공격이면서 실수이면서 정책 위반인 상태로 존재한다는 것입니다.

이 개념을 뒷받침하는 클라우드의 특성은 5가지입니다.

  • 클라우드/개발 팀은 자체 클라우드 인프라를 직접 관리할 수 있는 더 큰 자율성을 갖는 경향이 있습니다.
  • 클라우드 관리 플레인은 인터넷을 통해 접근할 수 있습니다.
  • (오늘날) 클라우드 공격의 가장 흔한 출처는 탈취된 자격 증명입니다.
  • 많은 잘못된 구성이 공격자의 행위와 동일한 상태를 만들어 냅니다(예: 스냅샷을 퍼블릭으로 설정하는 것).
  • 잘못된 구성은 실수로 쉽게 발생하며, 때로는 필요를 충족하기 위해 의도적으로 이루어지지만 해당 작업을 수행한 사람이 그것이 보안 문제라는 점을 인지하지 못하기도 합니다.

이 개념은 기존 인프라에서도 유효하지만, 팀의 자율성이 더 적기 때문에 그 정도는 훨씬 덜합니다. 애플리케이션 개발자가 방화벽 규칙과 라우팅 테이블을 직접 수정할 수 있는 경우는 일반적이지 않습니다. 클라우드에서는 적어도 일부 환경에서 이것이 상당히 흔합니다.

아니라고 입증되기 전까지는 공격으로 간주하십시오

클라우드 사고 대응에서 더욱 중요한 원칙 중 하나는, 잘못된 구성을 반드시 보안 이벤트로 다루어야 하며 아니라고 입증되기 전까지는 공격이라고 가정해야 한다는 것입니다.

이는 사고방식의 전환입니다. 보안 분야는 취약점과 공격 표면의 관점에서 생각하는 데 익숙하지만, 그것들은 주기적으로 스캔하고 대체로 조치해야 할 사안으로 취급해 왔습니다. 저는 클라우드 컴퓨팅에서는 탐지된 잘못된 구성을 IDS나 EDR 경고와 동일한 수준으로 격상해야 한다고 제안합니다. 그것들은 단순한 컴플라이언스 문제가 아니라 잠재적인 침해 지표입니다.

물론 이것이 모든 환경의 모든 잘못된 구성에 적용되는 것은 아닙니다. 걸러내고 우선순위를 정해야 합니다. 더 나아가 소통해야 합니다. 잘못된 구성이 악의적인 공격인지 파악하는 가장 쉬운 방법은 대개 변경을 수행한 사람에게 의도한 것인지 물어보는 것이기 때문입니다.

교육 과정을 위해 내용을 압축해야 했기에, 저는 보안 텔레메트리의 주요 피드를 세 가지로 정리했습니다.

  • 로그
  • 클라우드 제공업체 이벤트(예: Security Hub 이벤트)
  • CSPM 도구, OSS 스캐너 등에서 나오는 클라우드 잘못된 구성

클라우드 보안에 종사하는 대부분의 사람들은 이미 이 개념을 체득하고 있지만, 항상 명시적으로 설명하지는 않습니다. 일부 클라우드 탐지 및 대응(CDR) 도구를 보면 특정 잘못된 구성에 대해 경고를 생성합니다. 이는 보고서와 대시보드에 발견 사항을 생성하는 기본적인 CSPM 도구 방식과는 다릅니다. 그러한 방식도 컴플라이언스와 전반적인 보안 위생에 중요하지만, 공격자는 디스크 이미지를 다른 계정과 공유하거나 IAM 역할에 백도어 접근을 심어 놓는 등의 악성 행위를 하기 때문에, 일부 잘못된 구성은 아니라고 입증되기 전까지 침해 지표처럼 다루어야 합니다.

내부적으로(그리고 DisruptOps 플랫폼에서) 저희는 식별된 API 호출을 기반으로 평가를 실행하는 실시간 위협 탐지기 세트로 이를 처리합니다. 잘못된 구성을 식별하고 위에서 보신 것처럼 Slack(또는 Teams)을 통해 보안팀과 프로젝트 담당자에게 전달하는 데 약 15~30초가 걸립니다. 이러한 경고는 GuardDuty 발견 사항이나 기타 침해 지표와 동일하게 처리되지만, ChatOps를 활용해 활동을 검증하면 매번 심층 분석을 수행하지 않고도 매우 신속하게 분류할 수 있습니다.

요약하자면, 핵심적인 클라우드 잘못된 구성은 거의 실시간으로 처리하고, 아니라고 입증되기 전까지는 침해 지표로 취급하십시오.

이 글을 작성하는 과정에서 다친 고양이는 없습니다.

슈뢰딩거의 잘못된 구성 - www.firemon.com