API 키를 안전하게 공유하는 방법
비밀을 노출하지 않고
API 키는 Slack, Teams, 이메일, 티켓, Git 기록에 둘 내용이 아닙니다. 키의 범위를 좁히고, 로컬에서 암호화하고, 일회용 링크를 쓰고, 전달이 끝나면 교체하는 더 안전한 절차를 알아보십시오.
핵심 정리
- API 키를 이메일, 채팅, 티켓, 문서, Git에 붙여 넣지 마십시오.
- 필요한 최소 권한만 가진 키를 사용하고, 유효 기간을 짧게 설정하며, 작업이 끝나면 키를 교체하십시오.
- 비밀은 브라우저에서 암호화된 일회용 링크로 보내십시오.
- 위험이 큰 키는 먼저 로컬에서 암호화하고, 암호문만 공유하십시오.
- 공유 뒤 이상한 사용을 감시하십시오. PrivateNote는 전달 도구이지, 금고가 아닙니다.
이 페이지에서
개발자라면 결국 누군가에게 API 키를 보내야 합니다. 스테이징 접근, 외주 담당자, 웹훅 연동, 고객 인계를 위해서입니다. 가장 빠른 길은 보통 가장 긴 흔적도 남깁니다.
API 키를 운영 비밀번호처럼 다루십시오
API 키는 사실상 소프트웨어용 비밀번호입니다. 권한에 따라 유출된 키는 고객 데이터를 노출하고, 유료 자원을 소비하고, 클라우드 인프라를 배포하고, 검증된 도메인으로 이메일을 보내거나, AI 요금을 쌓을 수 있습니다.
사람용 비밀번호와 달리 API 키는 몇 달씩 유효한 채로 구성 파일 안에 있고, 다단계 인증을 완전히 우회하는 경우가 많습니다. 키가 새면 공격자는 애플리케이션인 것처럼 동작할 수 있고, 비용이 치솟거나 데이터가 이미 노출될 때까지 악의적 트래픽이 평범한 운영 사용에 섞일 수 있습니다.
API 키를 영구적인 시스템에 붙여 넣지 마십시오
이 채널들이 편한 이유는 기록을 보존하기 때문입니다. 바로 그 점이 비밀을 두기에는 잘못된 이유입니다.
- Slack, Microsoft Teams, Discord, 또는 그 밖의 채팅 기록
- 이메일, SMS, 또는 전달된 받은편지함 스레드
- Jira, Trello, Notion, Confluence, 또는 GitHub 이슈
- 일반 텍스트 문서, 스프레드시트, 공유 클라우드 폴더
- Git 커밋, 풀 리퀘스트, 코드 주석
API 키가 실제로 새는 곳
대부분의 유출은 정교한 암호학 파괴가 아닙니다. 기록을 남기도록 만들어진 시스템에 누군가 비밀을 복사할 때 일어납니다.
이메일
이메일은 오래 남는 사본을 만듭니다. 키는 받은편지함, 보관함, 백업, 모바일 동기화, 전달된 스레드, 검색 색인에 작업이 끝난 뒤에도 오래 살아남을 수 있습니다.
팀 채팅
Slack과 Teams는 맥락을 보존합니다. 그래서 비밀에는 위험합니다. 붙여 넣은 키 하나가 이후 작업 공간 구성원에게 검색되거나, 침해된 기기를 통해 샐 수 있습니다.
프로젝트 도구
Jira, Notion, Confluence, Trello, GitHub 이슈는 자격 증명 금고가 아닙니다. 삭제한 티켓도 내보내기, 백업, 감사 추적, AI 보조 검색에 남을 수 있습니다.
Git 저장소
Git 기록은 잘 달라붙습니다. 나중 커밋에서 키를 지워도 이전 커밋이 지워지지는 않습니다. 공개 저장소는 끊임없이 스캔되고, 노출된 클라우드 자격 증명은 몇 분 안에 악용될 수 있습니다.
위험이 큰 키: 먼저 로컬에서 암호화하십시오
대부분의 API 키는 바꿀 수 있습니다. 스테이징 토큰, 수명이 짧은 연동 비밀, 교체할 계획인 범위가 좁은 자격 증명입니다. 그런 경우에는 브라우저에서 암호화된 일회용 전달로 보통 충분합니다.
어떤 키는 무게가 더 있습니다. 운영 관리자 접근, 서명 키, 루트 클라우드 자격 증명, 또는 깨끗하게 폐기하기 어렵거나 불가능한 수명이 긴 것입니다. 그런 키는 마스터 비밀처럼 다루십시오. 웹에 업로드하기 전에 로컬에서 암호화한 다음, PrivateNote로 암호문을 보내십시오.
- age — 파일 암호화의 가장 단순한 기본값 (
age -p -o key.txt.age key.txt) - OpenSSL — 플래그를 이미 알고 있다면 신뢰할 수 있는 CLI
- 암호화된 파일을 PrivateNote로 업로드하고, 복호화 암호 문구는 별도 채널(Signal, 전화, 직접 만나서)로 보내십시오
같은 절차가 암호화폐 시드 문구와 그 밖의 대체 불가능한 마스터 비밀에도 적용됩니다. age/OpenSSL 전체 절차, 암호 문구 요령, 일회용 링크가 맞는 도구인 때와 아닌 때는 암호화폐 시드 문구와 일회용 링크를 보십시오.
더 안전한 전달 절차
앱이 실행 중에 키를 가져오는 때가 아니라, 사람이 키를 필요로 할 때는 이 순서를 따르십시오.
키의 범위를 좁히기
최소 권한만
로컬에서 암호화
키는 브라우저를 떠나지 않습니다
링크를 보내기
원문 비밀이 아닙니다
끝나면 폐기
전달 후 교체
메모 비밀번호는 별도 채널로 공유하십시오. 링크와 같은 메시지에는 넣지 마십시오.
PrivateNote가 전달에 맞는 방식
PrivateNote는 사람 사이의 순간에 맞춰져 있습니다. API 키, SSH 개인 키, 데이터베이스 자격 증명, 복구 코드, 웹훅 서명 비밀, 그리고 영구 기록이 되지 않은 채 한 사람에게 닿아야 하는 임시 비밀번호입니다.
비밀이 API 자격 증명이 아니라 SSH 키라면, 공개 키와 개인 키, 배포 키, 편집기 확장은 SSH 키를 안전하게 공유하는 방법을 보십시오.
비밀은 업로드 전에 브라우저에서 암호화됩니다. PrivateNote는 평문이 아니라 암호문을 저장합니다. 복호화 키는 URL 프래그먼트, 즉 # 뒤의 부분에 있으며, 브라우저는 페이지를 불러올 때 그것을 서버로 보내지 않습니다. 그것이 API 자격 증명에 적용된 일회용 비밀 링크 모델입니다.
https://privatenote.ai/note/abc123#kL8mN4...
- 서버는 메모 ID와 암호화된 페이로드를 받습니다.
- 서버는 복호화 키를 받지 않습니다.
- 읽은 뒤 파기와 만료는 암호화된 메모가 존재하는 시간을 제한합니다.
PrivateNote는 전용 비밀 저장소를 보완합니다. 연동 파트너에게 Stripe 키를 보내거나, 외주 담당자에게 임시 OpenAI 키를 공유하거나, 팀원에게 스테이징 자격 증명을 한 번 열어 주게 할 때의 빈틈을 메웁니다.
자주 묻는 질문
환경 변수만 쓰면 되지 않습니까?
환경 변수는 로컬 소프트웨어를 실행하는 데는 좋습니다. 그 값을 팀원, 외주 담당자, 고객, 연동 파트너에게 넘겨야 할 때의 전송 문제는 풀지 못합니다.
API 키는 항상 만료되어야 합니까?
제공자가 지원한다면, 그렇습니다. 수명이 짧은 자격 증명은 실수로 공개된 뒤의 악용 창을 줄이고, 교체를 일상적인 절차의 일부로 만듭니다.
가장 안전한 절차는 무엇입니까?
범위를 좁힌 키를 만들고, 브라우저에서 암호화된 일회용 링크로 보낸 뒤, 선택적 비밀번호는 별도 채널로 공유하고, 작업이 끝나면 키를 교체하거나 폐기하십시오. 위험이 크거나 수명이 긴 키는 age나 OpenSSL로 먼저 로컬에서 암호화하고 암호문만 업로드하십시오.
PrivateNote는 시크릿 관리자입니까?
아닙니다. PrivateNote는 사람 사이의 안전한 전달을 해결합니다. 기계 사이의 비밀 저장에는 HashiCorp Vault, AWS Secrets Manager, Google Cloud Secret Manager, 또는 Azure Key Vault를 사용하십시오.
정리
대부분의 API 키 유출은 암호학이 실패해서 일어나지 않습니다. 누군가 편의를 위해 비밀을 영구적이고 검색 가능한 시스템에 복사해서 일어납니다. 키의 범위는 좁히고, 필요할 때만 공유하고, 채팅, 티켓, 이메일, Git에 평문 흔적을 남기지 마십시오. 전달 파이프라인 쪽—.env 커밋, CI 로그, GitHub 기록—은 [CI/CD, .env 파일, GitHub의 비밀](blog:secrets-in-cicd-env-github-leaks)을 보십시오.
채팅에 남기지 않고 API 키를 공유하십시오
브라우저에서 암호화되고 읽은 뒤 파기되는 PrivateNote 링크를 만드십시오. 일회용 메모에는 계정이 필요 없습니다.
PrivateNote 만들기 ->
