Inbixio

이메일 API 키 보안: 권한 범위, 키 교체, 키를 보관할 곳

이메일 API 키가 유출되면 누구나 회사 이름으로 메일을 보낼 수 있습니다. Inbixio 키의 권한 설정, 안전한 보관, 무중단 교체, 유출 대응 방법을 알아봅니다.

Inbixio Team · 6 분 분량

이메일 API 키는 짧은 문자열이지만 강력한 권한을 가지고 있습니다. 키를 가진 사람은 누구든 여러분의 도메인에서, 여러분의 이름으로, 누구에게나 메일을 보낼 수 있습니다. 유출된 키는 피싱 캠페인이 정상적인 기업의 인프라를 통해 발송되는 가장 흔한 경로 중 하나입니다.

다행히 몇 가지 습관만 들이면 유출 가능성을 낮추고, 그래도 유출이 일어났을 때 피해를 줄일 수 있습니다. 이 가이드에서는 Inbixio가 모든 키에 제공하는 제어 기능을 활용해 그 방법을 설명합니다.

Inbixio 키로 할 수 있는 일

API Keys → Create Api Key(API 키 → API 키 만들기)에서 만드는 모든 키에는 세 가지 설정이 있습니다.

  • Name(이름): 관리용 이름입니다. 예: prod-auth-service.
  • Server Access(서버 접근): All Server(모든 서버, 처음 연결한 SMTP 서버를 통해 발송) 또는 Selected Server(선택한 서버, 지정한 서버 하나만 사용).
  • Permissions(권한): Send(발송), Read(읽기), Manage(관리). 현재 API에는 이메일 발송이라는 엔드포인트 하나만 있으므로, 서비스에 필요한 권한은 Send입니다.

키는 ibx_ 뒤에 16진수 32자가 붙는 형태입니다. 이 접두사 덕분에 사람도 쉽게 알아볼 수 있고, 시크릿 스캐너도 쉽게 잡아낼 수 있습니다.

규칙 1: 서비스와 환경마다 키 하나씩

회사 전체가 키 하나를 공유하지 마세요. 서비스마다, 그리고 환경마다 별도의 키를 만드세요.

키 이름 Server Access Permissions
prod-auth Selected: security@yourco.com Send
prod-billing Selected: billing@yourco.com Send
staging-all Selected: 테스트용 메일함 Send

키를 분리하면 다음과 같은 이점이 있습니다.

  • 유출의 영향이 제한됩니다. prod-billing을 폐기해도 로그인 이메일은 멈추지 않습니다.
  • 각 서비스가 올바른 주소로 발송합니다. billing@ 서버에 고정된 키는 처음 연결한 서버가 아니라 billing@에서 발송합니다. 고정된 서버를 삭제하면 키는 첫 번째 서버로 되돌아가므로, 서버를 제거할 때는 키를 다시 고정하세요.
  • 키 교체가 간편합니다. 다른 서비스에 손대지 않고 한 서비스의 키만 갱신할 수 있습니다.

규칙 2: 작동에 필요한 최소 권한만 부여하기

이메일을 보내는 백엔드에는 Send 외에 아무것도 필요하지 않으므로, Read와 Manage는 체크하지 마세요. 키가 할 수 있는 일이 적을수록 유출되었을 때의 피해도 줄어듭니다.

규칙 3: 키는 서버에 두고, 클라이언트에는 절대 두지 않기

브라우저나 모바일 앱으로 배포되는 것은 압축 여부와 상관없이 모두 추출될 수 있습니다. 여기에는 다음이 포함됩니다.

  • JavaScript 번들(React, Vue, Next.js 클라이언트 컴포넌트),
  • NEXT_PUBLIC_, VITE_, REACT_APP_처럼 브라우저용 접두사가 붙은 환경 변수,
  • iOS 및 Android 앱 바이너리.

프론트엔드의 사용자 동작으로 이메일을 보내야 한다면 여러분의 백엔드 엔드포인트를 호출하세요. 백엔드가 사용자에게 권한이 있는지 확인하고 속도 제한을 적용한 다음, 환경 변수에 보관한 키로 Inbixio를 호출합니다.

// ✅ Browser → your API → Inbixio
await fetch('/api/invite', { method: 'POST', body: JSON.stringify({ email }) });

// ❌ Never do this in frontend code
fetch('https://backend.inbixio.com/api/send-email/', {
  headers: { 'X-API-Key': 'ibx_…' }, // visible to every visitor
});

규칙 4: 키는 비밀번호처럼 보관하기

  • 키는 시크릿 매니저(AWS Secrets Manager, Google Secret Manager, Doppler, 1Password, Vault)나 플랫폼의 암호화된 환경 변수에 저장하세요.
  • 절대 커밋하지 마세요. .env를 .gitignore에 추가하고 저장소에서 시크릿 스캐닝을 켜세요. GitHub의 푸시 보호 기능은 많은 유출을 사전에 차단합니다.
  • 로그에 키가 남지 않게 하세요. 외부로 나가는 요청을 로그로 남긴다면 먼저 X-API-Key 헤더를 제거하세요.
  • 티켓, 채팅, 스크린샷에 키를 붙여 넣지 마세요. 값이 아니라 시크릿에 대한 접근 권한을 공유하세요.

규칙 5: 정기적으로 교체하고, 의심스러우면 즉시 교체하기

Inbixio에서는 키를 갱신할 수 있습니다. API Keys 페이지에서 키 옆의 새로 고침 아이콘을 클릭하세요. 갱신하면 이름, 서버 접근, 권한은 그대로 유지된 채 새 값이 발급되고, 이전 값은 즉시 작동을 멈춥니다. 발송 실패 없이 운영 키를 교체하려면:

  1. 같은 설정으로 두 번째 키를 만듭니다(예: prod-auth-2).
  2. 새 키를 서비스에 배포하고, 자체 애플리케이션 로그 등에서 요청이 200을 반환하는지 확인합니다.
  3. 이전 키를 삭제합니다.

유출 직후처럼 매끄러운 전환보다 속도가 중요할 때는 새로 고침 아이콘을 사용하세요. 일반 키는 몇 달마다, 그리고 접근 권한이 있던 사람이 팀을 떠날 때마다 교체하세요.

키가 유출되었다면

사고로 다루되, 충분히 대응할 수 있는 사고입니다.

  1. 즉시 키를 갱신(새로 고침 아이콘)하거나 삭제하세요. 이렇게 하면 이전 값의 사용이 모두 중단됩니다.
  2. 대시보드 로그에서 비정상적인 활동을 확인하세요. 평소와 다른 시간대의 호출이나 발송량 급증 등입니다. 로그에는 호출 시각은 나오지만 어떤 키로 호출했는지는 나오지 않으므로, 여러분 서비스의 로그와 비교해 보세요.
  3. 메일 제공업체에서 여러분이 보내지 않은 메시지로 인한 반송이나 스팸 신고가 있는지 확인하세요.
  4. 커밋, 로그 한 줄, 프론트엔드 번들 등 어떻게 유출되었는지 찾아내고 그 경로를 막으세요.
  5. 여러분의 이름으로 메시지가 발송되었다면 영향을 받은 사용자에게 알려 해당 메시지를 무시하도록 안내하세요.

간단한 체크리스트

  • 서비스와 환경마다 알아보기 쉬운 이름의 키 하나씩
  • 각 서비스가 사용해야 할 서버(발신 주소)에 키 고정
  • 발송 서비스에는 Send 권한만
  • 프론트엔드 코드, 모바일 앱, 저장소에 키 없음
  • 키는 시크릿 매니저에 보관하고 로그에서 제거
  • 달력에 교체 일정 등록, 유출 대응 계획 마련

보안은 스팸함을 피하는 데에도 중요합니다. 유출된 키로 발송된 메시지는 도메인 평판을 떨어뜨립니다. 전체 그림을 보려면 이 체크리스트를 SPF, DKIM, DMARC와 함께 활용하세요.

Inbixio로 보내세요

자체 SMTP 서버를 연결하고, 권한이 제한된 API 키를 만들어 HTTPS 요청 한 번으로 어떤 언어에서든 발송하세요.

계정 만들기 요금제 보기

더 읽어보기