Multi-party approval은 AWS Organizations의 기능으로, 미리 지정된 고위험 작업 집합을 정족수만큼의 지명된 사람이 별도 경로(out of band)에서 승인할 때까지 차단합니다. 단 하나의 자격 증명은, 그것이 유효한 것이라 하더라도, 더 이상 혼자서 방아쇠를 당길 수 없습니다. 요청자가 작업을 시작하면, 별도의 approval team이 전용 portal에서 이를 검토하고, 팀의 approval threshold가 충족되어야만 작업이 실행됩니다.

이것은 runbook이나 Slack 메시지가 아니라 API 계층에서 강제되는 "four eyes" 원칙입니다. "두 사람이 서명해야 한다는 정책은 있다"와 "두 사람의 서명 없이는 플랫폼이 물리적으로 진행을 거부한다" 사이의 간극을 메웁니다.

정확히 무엇인가

Multi-party approval(MPA)은 AWS Organizations 안에 있으며, 사람 신원은 IAM Identity Center에 의존합니다. 신원 소스에서 가져온 승인자 집합으로 approval team을 정의하고, 여기에 approval threshold를 붙입니다. 즉 protected operation이 실행되기 전에 yes라고 말해야 하는 최소 인원 수입니다.

그런 다음 특정 작업을 protected로 표시합니다. 이 시점부터, protected operation을 호출하는 사람은 즉각적인 결과를 받지 못합니다. 대신 대기 중 요청을 받습니다. MPA는 팀의 모든 승인자에게 이메일을 보내고, 각 승인자는 approval portal을 열어 요청을 검토한 뒤 승인하거나 거부합니다. threshold가 충족되면 원래 호출자의 작업이 진행을 허용받습니다. 승인은 사후 통지가 아니라 관문입니다.

용어

  • Approval team: IAM Identity Center 사용자로 뒷받침되는, 이름이 붙은 승인자 그룹.
  • Approval threshold: 몇 명의 승인자가 승인해야 하는지. threshold가 2인 3인 팀이라면, 그 중 어느 두 명이든 작업의 차단을 해제합니다.
  • Protected operation: 관문 뒤에 배치한 특정 작업.
  • Approval portal: 승인자가 검토하고 응답하는 별도 경로의 화면. 요청을 만든 콘솔 세션과 의도적으로 분리되어 있습니다.

흐름은 어떻게 작동하는가

과정은 세 단계이며, 단계 사이의 분리가 핵심 전부입니다.

  1. 요청. 사용자(또는 자동화된 호출자)가 protected operation을 호출합니다. AWS는 작업을 실행하는 대신 approval session을 생성하고 팀에 알립니다.
  2. Approval session. 승인자는 링크가 담긴 이메일을 받아 portal을 열고, 무엇이, 누구에 의해, 어떤 리소스를 대상으로 요청되었는지 정확히 확인합니다. 그들은 독립적으로 승인하거나 거부합니다.
  3. 실행. 승인이 threshold에 도달하면 작업이 실행됩니다. 세션이 시간 초과되거나 threshold가 끝내 충족되지 않으면 작업은 결코 일어나지 않습니다.

요청자는 자신의 세션 안에서 자신의 요청을 승인할 수 없습니다. 승인은 다른 화면에서, 다른 신원에 묶여 일어납니다. 바로 이 점이 탈취된 세션 토큰이나 침해된 CI 역할만으로는 충분하지 않게 만듭니다.

왜 보안에서 중요한가

가치는 이메일이나 portal에 있지 않습니다. 통제가 애플리케이션 아래, 플랫폼 안에 자리해서, 단 하나의 침해된 주체가 그것을 우회할 수 없다는 데 있습니다.

단일 침해 지점을 제거한다

대부분의 치명적인 클라우드 사고는 너무 넓은 도달 범위를 가진 하나의 신원으로 귀결됩니다. 유출된 장기 키, 피싱당한 관리자, 과도하게 부여된 자동화 역할 같은 것들이죠. 한 주를 망칠 수 있는 소수의 작업에 대해, MPA는 "침해된 자격 증명 하나"를 "동시에 N명의 독립적인 사람도 함께 무력화해야 한다"로 바꿉니다. 이것은 다른 부류의 공격입니다.

API에서 직무 분리를 강제한다

직무 분리(separation of duties)는 보통 컴플라이언스 문서 안에 살아 있다가 현실에서는 죽어버립니다. 서두르는 엔지니어가 민감한 변경의 두 절반을 모두 처리하는 것을 막을 게 아무것도 없기 때문입니다. MPA는 그 규칙을 control plane으로 옮깁니다. 선의가 아니라 플랫폼이 두 번째 서명을 강제합니다.

랜섬웨어와 파괴적 내부자에 대한 제동 장치다

고전적인 파괴 시나리오는 백업을 먼저 삭제한 뒤 데이터를 지우는 것입니다. protected recovery point를 삭제하거나 변경하는 작업이 정족수 뒤에 있으면, 하나의 신원을 장악한 공격자는 당신의 마지막 복구 수단을 조용히 파괴할 수 없습니다. 같은 제동이 정당한 접근 권한을 가진 불만 품은 내부자에게도 적용됩니다.

방어할 수 있는 감사 추적을 만든다

이제 모든 protected operation에는 누가 요청했고, 누가 승인했으며, 언제였는지에 대한 기록이 따라붙습니다. SOC 2, ISO 27001, PCI DSS, 또는 내부 사후 검토에서 "이 작업에 대한 승인을 보여달라"는 요청은 발굴 작업이 아니라 단순한 질의가 됩니다.

어디에 맞고, 어디에 맞지 않는가

Multi-party approval를 쓸 때건너뛸 때
작업이 드물고, blast radius가 크며, 되돌릴 수 없을 때작업이 빈번하고 즉시 실행이 필요할 때
IAM Identity Center와 함께 AWS Organizations를 운영할 때Organizations나 Identity Center 없이 독립 계정을 운영할 때
컴플라이언스나 Zero Trust를 위해 분산 서명이 필요할 때위험이 팀과 워크플로 관리의 부담을 정당화하지 못할 때
최후의 보루인 백업의 삭제나 변경을 보호하고 싶을 때사람 개입 없이 무인으로 실행되는 자동화가 필요할 때

MPA는 메스이지 담요가 아닙니다. 잘못된 한 수가 복구 불가능한 작업에 붙이세요. 논리적으로 air-gapped된 백업 볼트를 파괴하기, org 수준 가드레일을 해체하기, recovery point를 삭제하기 같은 것들이요. 팀이 하루에 마흔 번씩 실행하는 작업에는 붙이지 마세요. 그러면 모두에게 승인을 도장 찍듯 통과시키도록 훈련시키게 되고, 이는 통제가 아예 없는 것보다 더 나쁩니다.

대비해야 할 실패 모드

  • 승인자 가용성. threshold가 2인데 팀에 두 사람만 있다면, 단 한 번의 휴가가 정당한 긴급 상황을 멈춰 세울 수 있습니다. 팀을 threshold보다 크게 구성하고 명단을 최신으로 유지하세요.
  • Break-glass 긴장. 실제 사고는 protected operation이 빠르게 필요할 수 있습니다. 업무 시간 외에 승인자에게 어떻게 연락할지 미리 정하고, 그것이 중요해지는 밤이 오기 전에 연습하세요.
  • 승인 피로. 너무 많이 보호하면 승인자가 읽기를 멈춥니다. 통제는 반사적인 클릭으로 전락합니다. 보호 목록을 짧고 진정으로 고위험인 것으로 유지하세요.
  • 신원 소스 의존성. MPA는 IAM Identity Center에 기댑니다. 그것이 잘못 구성되거나 사용 불가능하면, 승인 경로도 마찬가지입니다. 이는 회복력 계획의 바깥이 아니라 안에 속합니다.

핵심 정리

Multi-party approval은 단지 깃발을 올리는 것이 아니라 공격자의 셈법 자체를 바꾸는, 몇 안 되는 AWS 통제 중 하나입니다. 단 하나의 실수나 단 하나의 탈취된 자격 증명이 치명적인 소수의 작업에 대해, 정족수 관문은 사고와 재앙을 가르는 차이입니다. 좁게 적용하고, approval team을 제대로 충원하며, break-glass 경로를 연습하세요.

다음으로 읽을 글

AWS 자격 증명을 쥐는 agentic 시스템을 구축 중이신가요? 같은 정족수 사고가 자율적 동작에도 적용됩니다. ercan.ai의 field note를 보세요. AWS, 클라우드 보안, 플랫폼 거버넌스 컨설팅은 ercanermis.com에서 시작하세요.