(노트: 독자 편의를 위해 DeepL을 사용하여 기계 번역한 내용입니다. 원문과 같이 살펴보시는 것을 추천합니다.)
Postman은 원격 웹 API를 테스트하는 개발자에게 매우 인기 있는 애플리케이션입니다. 이 애플리케이션을 사용하면 HTTP 요청을 작성하고, 응답과 상호 작용하며, 주고받은 내역을 살펴볼 수 있습니다.
이러한 HTTP 요청의 대부분은 인증된 것으로, 애플리케이션이 API 키, 로그인 토큰, 자격증명 등을 처리한다는 의미입니다.
5월에 Postman은 많은 기능을 클라우드 전용 제품으로 전환했습니다.
포스트맨의 보안 위험
Postman에 로그인하면 요청에 포함된 민감한 데이터를 포함한 모든 데이터가 자동으로 클라우드 서비스에 동기화됩니다. 예를 들어, 다음은 온프레미스 애플리케이션만 사용했을 때의 Postman의 클라우드 보기입니다.
포스트맨 위협 모델의 변경 사항
클라우드 연결은 물론 보안 위협은 아니지만, 제품이나 회사가 위협 모델에서 새로운 위험을 고려해야 합니다.
이 변경으로 인해 Postman의 보안 위험에 몇 가지 주요 변경 사항이 도입됩니다:
이제 사용자가 직접 관리하는 Postman 계정 자격 증명으로 사용 중인 모든 프로덕션 비밀에 액세스할 수 있습니다. 조직에서 프로덕션 리소스를 관리할 때 ID 분리를 시행하는 경우, 이제 이러한 자체 관리 Postman 계정이 이를 위반하게 됩니다.
이제 Postman 계정에 대한 기존의 공격(피싱, 크리덴셜 스터핑 등)으로 인해 프로덕션 기밀이 노출될 가능성이 높습니다.
Okta의 최근 침해 사례에서 알 수 있듯이, 공격자들은 인증 자료를 저장하는 회사를 공격하여 이를 악용하고 원래의 공격 대상에 대해 다시 공격합니다.
이러한 종류의 문제 외에도 Postman은 API 요청을 위한 소셜 네트워크의 길을 걷고 있습니다. 사람들이 실수로 깃허브에 크레딧을 확인하는 것이 문제라고 생각했다면, 공격자들이 포스트맨이라는 보물창고를 발견할 때까지 기다립니다.
Postman은 이러한 접근 방식의 보안 위험에 대한 엄청난 양의 피드백을 받았지만 이를 고려한 변경을 하지 않기로 결정했습니다. 보안 페이지에는 가장 기본적인 체크박스 스타일의 보안만 언급되어 있습니다:
당사는 암호화 방법과 업계 표준을 사용하여 Postman 클라이언트, 클라우드 및 미사용 상태의 고객 데이터를 보호합니다. 예를 들어, 인터넷을 통해 전송되는 모든 통신과 데이터에는 종단 간 암호화를 제공하는 암호화 프로토콜인 최신 버전의 전송 계층 보안이 필요합니다. 기본적으로 암호화는 미사용 데이터가 포함된 모든 서비스에서도 사용하도록 설정되어 있습니다.
또한 저장 중인 민감한 데이터는 AES-256-GCM을 사용하여 저장하기 전에 서버 측에서 암호화됩니다. 갈루아 카운터 모드가 포함된 고급 암호화 표준(AES-GCM)은 인증된 암호화를 제공하여 데이터 기밀성과 무결성을 보장합니다.
따라서 다른 대안이 있다면 Postman은 위험을 감수할 가치가 없습니다.
측정된 위험
샘플을 추출한 대규모 데이터 세트에서:
- 56%의 Postman 사용자가 자신의 기록을 검토할 때 민감한 인증 정보를 발견했습니다.
- 이 중 30%는 여전히 유효했기 때문에 교체해야 했습니다.
- 나머지 70%는 어느 시점에는 유효했기 때문에 공격자가 사용자 계정이나 Postman 인프라에 적극적으로 액세스할 수 있었다면 정보 유출을 의미할 수 있었습니다.
- 대체 클라이언트로 이동하는 데 방해가 되는 차단 문제는 아무도 발견하지 못했습니다.
Postman의 대안
Postman을 대체할 수 있는 몇 가지 인기 있는 서비스가 있습니다:
- Insomia. 인섬니아는 계정이 필요하지만, 서버가 민감한 정보를 절대 볼 수 없도록 명시적으로 구현된 기능(예: 종단 간 암호화)을 갖추고 있습니다. 이 정도의 연결성조차도 불안하다면, 이러한 기능을 제거한 Insomnia의 포크 버전이 있습니다: 인섬니움.
- Bruno. 역시 매우 인기 있고 오프라인에서만 사용할 수 있습니다.
- Visual Studio(시크릿에 대한 풍부한 지원 포함), PowerShell의 Invoke-RestMethod, Curl 등을 지원합니다.
Insomnia와 Bruno는 Postman에서 가져오기를 지원합니다.
회사에서 Postman 제거하기
다음은 회사에서 Postman을 제거하는 방법에 대한 대략적인 플레이북입니다. 물론 마일리지는 다를 수 있습니다.
- Postman 사용자 인구를 파악합니다. https://identity.getpostman.com 에 접속하는 사용자의 엔드포인트 URL 사용 데이터를 통해 이 목록을 얻을 수 있었습니다.
- 이러한 사용자에게 다음과 같이 지시합니다:
- Postman에 로그인(또는 열기)하고 기록 탭으로 이동합니다.
- ‘인증’ 헤더 또는 기타 민감한 헤더가 있는 항목을 검토합니다. 저장된 모든 항목과 관련된 자격 증명을 모두 교체합니다.
- URL 기반 인증(예: Azure Storage용 SAS 키, 사전 서명된 AWS URL, 웹 후크 등)을 사용하는 모든 항목을 검토합니다. 저장된 자격 증명과 관련된 모든 자격 증명을 교체합니다.
- 문제가 해결되면 Postman 기록을 지우고 계정을 해지하세요.
- 인섬니아, 인섬니아 또는 브루노를 대체 고객으로 살펴봅니다.
- 설문조사 양식에 이들의 완료 내용을 기록합니다. 다음 질문이 포함된 Office 양식을 사용했습니다:
- 내 Postman 기록을 검토했습니다. 민감한 자료와 관련하여:
- 민감한 자격증명/비밀이 이미 만료되었습니다.
- 민감한 자격증명/비밀을 교체했습니다.
- 민감한 자격증명/비밀번호를 교체하는 중입니다.
- 민감한 자료가 있지만 올바른 다음 단계를 잘 모르겠습니다. 연락처]에 연락했습니다.
- 민감한 자료가 없습니다.
- Postman Cloud 사용을 중단했습니다.
- 예, 대안을 찾았습니다.
- 예, 필요에 따라 대안을 찾겠습니다.
- 아니요, 차단되어 [연락처]로 연락했습니다.
- 내 Postman 기록을 검토했습니다. 민감한 자료와 관련하여:
회사 또는 조직에 있는 모든 프로세스(에스컬레이션, CCing 관리자, 이사 등)를 사용하여 Postman을 사용했지만 설문조사에 응답하지 않은 직원 목록을 삭제하세요. 물론 연락을 취하는 직원들을 적극적으로 지원하세요.
이력 분석 자동화
이상적으로는 콘텐츠 디렉터리에서 CredScan과 같은 비밀 정보 분석 도구를 실행하여 위의 3.1단계를 자동화할 수 있습니다. 안타깝게도 기록 분석을 자동화할 수 있는 합리적인 방법을 찾지 못했습니다.
Postman은 데이터를 내보내는 기능을 지원하지만, 이 내보내기는 컬렉션 및 유사한 구성에 대해서만 가능합니다. 기록은 내보내지 않습니다. 심지어 GDPR 내보내기에도 기록은 포함되지 않습니다.
또한 로컬 및 웹 클라이언트는 문서화되지 않은 복잡한 웹소켓 프로토콜을 사용하여 Postman 서비스 자체와 상호 작용하기 때문에 상당히 광범위한 리버스 엔지니어링 및 소프트웨어 엔지니어링 작업이 필요했을 것입니다.