2026년 5월 20일, GitHub은 공격자들이 약 3,800개의 내부 코드 저장소에서 데이터를 훔쳤다고 확인했습니다. 침입 경로는 GitHub 서버의 제로데이 취약점이 아니었습니다. 한 직원의 노트북에 설치된 오염된 VS Code 확장 프로그램이었습니다. 이 확장 프로그램이 개발자와 동일한 파일 시스템 권한으로 실행되자, 접근 가능한 모든 것을 읽을 수 있었습니다: 소스 코드, 구성 파일, 그리고 작업 공간에 있는 모든 자격 증명. 동일한 유형의 공격으로부터 API 키를 보호하고 싶다면, 불편하지만 간단한 교훈이 있습니다. 가장 약한 연결 고리는 클라우드가 아닙니다. 개발자 머신과 그 위에서 실행되는 도구들입니다.
요약 (TL;DR)
손상된 IDE 확장 프로그램이나 유출된 저장소로부터 API 키를 보호하려면, 개발 도구가 읽을 수 있는 곳에 실제 자격 증명을 저장하지 마십시오. 소스 코드와 커밋된 `.env` 파일에서 비밀 정보를 제거하십시오. `.gitignore`를 편의 기능으로 취급하고, 보안 제어로 오해하지 마십시오. 모든 키의 범위를 단일 환경으로 지정하고, 수명이 짧고 최소 권한의 자격 증명을 사용하며, 정기적으로 순환하십시오. Apidog와 같은 도구는 API 자격 증명을 저장소 및 작업 공간에 흩어져 있는 평문 대신 로컬 전용 값을 가진 환경 변수에 보관함으로써 도움을 줍니다.
GitHub 침해 사고가 모든 개발자에게 경종을 울리는 이유
GitHub의 사고는 교과서적인 공급망 공격처럼 읽힙니다. TeamPCP로 추적되는 위협 그룹은 npm, PyPI, PHP 생태계 전반에 걸쳐 패키지를 트로이 목마화한 전력이 있습니다. 이번에는 악성 페이로드가 VS Code 확장 프로그램을 통해 전달되었습니다. TechCrunch의 보도에 따르면, 공격자들은 약 3,800개의 내부 저장소에서 데이터를 빼돌렸고, 현재 이 데이터를 지하 포럼에서 5만 달러 이상에 판매하고 있습니다. GitHub은 해당 내부 저장소 외부에 저장된 고객 데이터가 영향을 받았다는 증거는 없으며, 조사가 진행 중이라고 밝혔습니다. 여기서 잠시 멈춰서 생각해야 할 부분이 있습니다. VS Code 확장 프로그램은 단지 코드일 뿐입니다. 확장 프로그램을 설치하면 사용자 권한으로 에디터 프로세스 내에서 실행됩니다. 파일을 나열하고, 열고, 내용을 읽을 수 있습니다. 파일 변경을 감시할 수 있습니다. 외부 네트워크 요청을 할 수 있습니다. 이 중 어떤 것도 취약점이 아닙니다. 이는 확장 모델이 설계된 대로 작동하는 방식입니다. 대부분의 확장 프로그램은 작업을 수행하기 위해 파일 접근이 필요합니다. 문제는 악성 또는 손상된 확장 프로그램이 동일한 접근 권한을 사용하여 발견하는 모든 것을 수집한다는 것입니다. 무엇을 발견할까요? 일반적인 프로젝트에서는 많은 것을 발견합니다. 저장소 루트에 있는 `.env` 파일. `config/secrets.yml`. 삭제할 생각이었던 빠른 테스트 스크립트에 하드코딩된 토큰. `~/.aws/credentials`에 있는 AWS 자격 증명. 인증 토큰이 있는 `.npmrc`. SSH 키. TeamPCP 그룹은 감염된 머신에서 개발자, CI/CD, 클라우드, AI 툴링 자격 증명을 수집한 "Mini Shai-Hulud" npm 웜 캠페인 배후의 동일한 행위자입니다. 패턴은 일관적입니다: 개발자의 컴퓨터에서 코드를 실행시키고, 자격 증명으로 보이는 모든 것을 긁어모읍니다. 이것은 종류가 새로운 것이 아니라, 단지 프로필이 새로운 것입니다. 우리는 Vercel 침해 사고에서 얻은 API 보안 교훈 분석에서 유사한 노출 패턴에 대해 썼으며, 공급망 메커니즘은 npm 공급망 보안 가이드에서 다룬 내용과 밀접하게 일치합니다. GitHub 사고는 더 큰 이름이 붙은 동일한 이야기입니다. 따라서 오늘날 물어볼 만한 가치가 있는 질문은 직접적입니다: 만약 지금 당신의 에디터에서 악성 확장 프로그램이 실행된다면, 무엇을 가지고 나갈까요?
하드코딩된 키와 커밋된 .env 파일은 지속적인 책임입니다
대부분의 자격 증명 유출은 정교하지 않습니다. 개발자가 "일단" 코드로 키를 붙여넣고 잊어버리거나, `.env` 파일이 커밋에 포함되는 경우입니다. 둘 다 저장소에 무기한으로 존재하는 책임을 만듭니다. 하드코딩된 키는 명백한 죄악입니다. 다음과 같은 코드를 본 적이 있을 것입니다:
import requests
# Quick test of the payments endpoint
STRIPE_KEY = "sk_live_51Qk2mNExampleKeyDoNotShipThis"
response = requests.post(
"https://api.stripe.com/v1/charges",
auth=(STRIPE_KEY, ""),
data={"amount": 2000, "currency": "usd", "source": "tok_visa"},
)
print(response.json())
이 `sk_live_` 키는 이제 파일의 일부입니다. 어떤 확장 프로그램이든 읽을 수 있는 작업 디렉토리에 있습니다. 파일이 커밋되면, 나중에 해당 줄을 삭제하더라도 키는 Git 기록에 영원히 남습니다. 저장소를 복제하는 사람이나 저장소를 스캔하는 모든 도구는 해당 키를 얻게 됩니다. `.env` 파일은 해결책으로 제시되었습니다. 아이디어는 훌륭합니다: 코드로 비밀 정보를 저장하지 않고, 런타임에 로드합니다. 실제 `.env`는 다음과 같습니다:
# .env (loaded at runtime, never meant to ship)
DATABASE_URL=postgres://app_user:Zk7%2BqN9wLx@db.internal:5432/payments
STRIPE_SECRET_KEY=sk_live_51Qk2mNExampleKeyDoNotShipThis
OPENAI_API_KEY=sk-proj-aB3dEf9hKlMnOpQrStUvWxYz1234567890
AWS_ACCESS_KEY_ID=AKIA4EXAMPLE7QRSTUVW
AWS_SECRET_ACCESS_KEY=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY
JWT_SIGNING_SECRET=8f2a91c4e7b6d3508f2a91c4e7b6d350
이것은 하드코딩보다 낫습니다. 하지만 변경되지 않은 부분을 주목하십시오. 해당 파일은 여전히 작업 공간에 평문으로 존재하며, 에디터가 실행하는 모든 프로세스에서 읽을 수 있습니다. 악성 확장 프로그램은 비밀 정보가 `app.py`에 있든 `.env`에 있든 상관하지 않습니다. 둘 다 파일입니다. 둘 다 `fs.readFileSync` 한 번으로 읽을 수 있습니다. `.env` 패턴은 파일이 절대 커밋되지 않는 경우에만 "Git 기록의 비밀 정보" 문제를 해결하며, "손상된 로컬 도구" 문제에 대해서는 아무것도 해결하지 못합니다. 커밋된 `.env`는 최악의 결과입니다. 놀랍도록 흔합니다. 개발자가 프로젝트에 `.env`를 추가하고, 실제 키를 작성한 다음, 첫 번째 커밋 전에 이를 무시하는 것을 잊어버립니다. 또는 동료가 저장소를 복제하고, `.env.example`을 보고, `.env`로 복사하고, 프로덕션 키를 채워 넣은 다음, 나중에 `git add .`가 이를 포함시킵니다. 이제 프로덕션 자격 증명이 공개될 수 있거나, 미러링될 수 있거나, GitHub와 같은 침해 사고에 연루될 수 있는 저장소의 공유 기록에 있습니다. 우리는 API 문서 및 Git 저장소 보안에 대한 동반 문서에서 저장소 유출 측면에 대해 더 깊이 다룹니다.
.gitignore는 보안 제어가 아닙니다
이것은 오해가 너무 널리 퍼져 있기 때문에 별도의 섹션으로 다룰 가치가 있습니다. `.gitignore`에 `.env`를 추가하는 것은 문을 잠그는 것처럼 느껴집니다. 그렇지 않습니다. 이것은 "이것을 가져가지 마십시오"라고 말하는 포스트잇입니다. `.gitignore`가 실제로 하는 일은 다음과 같습니다. `git add`를 실행할 때 Git에 패턴과 일치하는 추적되지 않은 파일을 건너뛰도록 지시합니다. 이것이 전체 범위입니다. 보안에 중요한 세 가지 실패 모드가 있습니다:
- 이미 추적된 파일에는 아무런 영향을 미치지 않습니다. `.env`가 무시 규칙을 추가하기 전에 한 번 커밋되었다면, Git은 계속해서 이를 추적합니다. 무시 규칙은 소리 없이 무시됩니다. `git rm --cached .env`를 실행하고 해당 삭제를 커밋해야 하며, 비밀 정보는 여전히 모든 과거 커밋에 남아 있습니다.
- 디스크의 파일에는 아무런 영향을 미치지 않습니다. `.gitignore`는 Git 명령어입니다. `.env` 파일은 여전히 작업 디렉토리에 평문으로 존재합니다. 악성 VS Code 확장 프로그램은 Git 인덱스가 아닌 파일 시스템을 읽습니다. 당신의 무시 규칙은 확장 프로그램에 보이지 않습니다. 이것이 GitHub 스타일 공격에 가장 중요한 실패 모드입니다.
- 하나의 실수로 우회가 가능합니다. `git add -f .env`는 무시 규칙을 무시합니다. 에디터의 소스 제어 UI를 통해 파일을 추가하는 것도 마찬가지입니다. 패턴을 반복하지 않는 하위 디렉토리에 다른 `.gitignore`가 있는 경우도 마찬가지입니다.
첫 번째 요점은 직접 확인할 수 있습니다. 비밀 정보가 커밋된 적이 있다고 의심되면 다음 명령이 알려줍니다:
# 현재 "무시"되었더라도 해당 파일을 건드린 모든 커밋을 나열합니다.
git log --all --full-history --oneline -- .env
# 기록에 여전히 남아 있는 실제 비밀 값을 확인합니다.
git log -p --all -- .env | grep -iE "key|secret|token|password"
이것이 무언가를 반환한다면, 저장소가 노출되는 순간 자격 증명은 손상된 것입니다. 해결책은 더 나은 무시 규칙이 아닙니다. 해결책은 키를 순환하고 `git filter-repo`와 같은 도구를 사용하여 기록에서 파일을 제거하는 것입니다. 더 근본적인 해결책은 애초에 실제 자격 증명이 파일에 없도록 하는 것입니다. `.gitignore`는 여전히 사용할 가치가 있습니다. 정직한 실수를 잡아내고 diff를 깔끔하게 유지합니다. 다만, 공격자가 존중하는 경계로 오해하지 마십시오. 그것은 위생이지 방어가 아닙니다.
범위 지정, 분리, 단축, 순환: 피해 반경을 줄이는 네 가지 습관
자격 증명이 절대 유출되지 않는다고 보장할 수는 없습니다. 하지만 유출된 자격 증명이 거의 쓸모없다고는 보장할 수 있습니다. 네 가지 습관이 대부분의 작업을 수행합니다.
비밀 정보를 환경에 따라 범위 지정하기
유출된 키는 전체 자산이 아니라 한 가지를 잠금 해제해야 합니다. 가장 흔한 범위 지정 실패는 개발, 스테이징, 프로덕션에서 동일한 API 키를 사용하는 것입니다. 왜냐하면 그렇게 하는 것이 더 쉽기 때문입니다. 그 키가 유출되면 모든 환경이 동시에 무너집니다. 각 환경에 자체 자격 증명을 부여하십시오. 로컬 머신은 샌드박스 프로젝트 및 테스트 데이터에 접근할 수 있는 개발 키를 사용합니다. 스테이징은 스테이징 키를 사용합니다. 프로덕션은 단 한 곳에 존재하며 노트북으로 복사되지 않는 프로덕션 키를 사용합니다. 개발 키가 손상된 확장 프로그램을 통해 유출되면, 공격자는 가짜 고객이 있는 샌드박스에 접근합니다. 이것은 성가신 일이지 사고가 아닙니다.
환경을 적절하게 분리하기
환경 분리는 세 가지 다른 키 값 이상을 의미합니다. 이는 환경들이 서로 접근할 수 없음을 의미합니다. 개발 데이터베이스는 다른 데이터베이스이며, 프로덕션의 읽기 복제본이 아닙니다. 스테이징 결제 제공자는 제공자의 테스트 모드이므로, 유출된 스테이징 키는 실제로는 아무것도 청구하지 않습니다. 도구와 사람이 하나의 변수를 바꾸는 것만으로 "개발" 구성을 프로덕션 데이터로 지정할 수 없어야 합니다. 분리가 실제로 이루어지면, "이 키는 어떤 환경에서 왔는가?"라는 질문에 명확한 답이 있으며, 그 답은 유출이 얼마나 심각한지 정확히 알려줍니다.
최소 권한, 단기 키 사용
도난당한 키가 얼마나 많은 피해를 입힐 수 있는지는 두 가지 속성에 의해 결정됩니다. **권한.** 키는 작업에 필요한 가장 좁은 권한 세트를 가져야 합니다. 공개 제품 카탈로그를 읽는 프론트엔드 빌드는 해당 리소스에 범위가 지정된 읽기 전용 키가 필요합니다. 쓰기 접근 권한, 결제 접근 권한, 그리고 물론 관리자 권한은 필요하지 않습니다. 대부분의 API 제공업체는 범위 지정 키 또는 세분화된 토큰을 지원합니다. GitHub 자체의 세분화된 개인 접근 토큰은 좋은 모델입니다. 토큰 스타일을 저울질하고 있다면, API 키 대 OAuth에 대한 우리의 비교는 수명이 짧은 OAuth 토큰이 정적 키를 완전히 능가하는 경우를 설명합니다. **수명.** 한 시간 후에 만료되는 키는 보잘것없는 전리품입니다. 공격자가 도난당한 데이터 세트를 구매하고 키에 접근할 때쯤이면 키는 만료됩니다. 영원히 살아있는 정적 키는 정반대입니다. 누군가가 알아차릴 때까지 작동하며, 이는 종종 몇 달이 걸립니다. 온디맨드로 발급되는 수명이 짧은 토큰을 선호하십시오. 수명이 긴 키가 불가피한 경우, 워크플로가 허용하는 가장 짧은 만료 기간을 설정하십시오.
패닉 상태가 아닌 일정에 따라 순환
순환은 자격 증명의 값을 변경하여 이전 값이 작동하지 않도록 하는 것입니다. 대부분의 팀은 서두르고 스트레스 받는 상황에서 침해 사고가 발생한 후에야 순환합니다. 이는 순환 프로세스가 문서화되지 않았다는 것을 알게 되는 최악의 시간입니다. 대신 달력에 따라 순환하십시오. 자격 증명 클래스별로 간격을 선택하십시오. 높은 권한의 프로덕션 키는 매월, 낮은 위험 키는 분기별로 순환하십시오. 정기적인 순환은 두 가지를 수행합니다. 오늘 도난당한 키는 다음 주기에 작동을 멈추므로, 아직 감지하지 못한 모든 유출의 유효 수명을 제한합니다. 그리고 모든 소비 환경에서 값을 업데이트하는 메커니즘을 연습하고 지루하게 유지합니다. 실제 사고가 발생했을 때, 순환은 50번 눌러본 버튼이지 화재 훈련이 아닙니다. 더 자세한 내용은 API 키 관리 도구에 대한 종합 가이드를 참조하십시오.
작업 공간에 흩어진 것이 아니라 Apidog 환경 변수에 자격 증명 보관
솔직한 이야기를 해보겠습니다. Apidog는 자체 VS Code 확장 프로그램과 MCP 서버를 제공합니다. 논점은 "우리 도구가 GitHub을 강타한 공격 유형에 면역이다"가 아닙니다. 어떤 클라이언트 측 도구도 그렇지 않습니다. 논점은 비밀 정보가 어디에 저장되며, 머신의 무언가가 오작동할 때 얼마나 노출되는지에 대한 것입니다. 현실적인 시나리오를 생각해 보십시오. 당신은 하루 종일 API를 구축하고 테스트합니다. 베어러 토큰, API 키, 데이터베이스 연결 문자열이 필요합니다. 기본적으로 클라이언트가 사용할 수 있도록 `.env` 파일이나 스크립트에 이들을 넣습니다. 이는 실제 자격 증명을 작업 공간의 평문 파일에 넣는 것이며, 이는 악성 확장 프로그램이 긁어낼 수 있는 정확한 표면입니다. Apidog의 환경 시스템은 해당 값들이 저장되는 위치를 변경합니다.
평문 파일 대신 환경 변수
Apidog에서 자격 증명은 저장소의 느슨한 텍스트가 아닌 환경 변수로 저장됩니다. 요청은 `Authorization` 헤더의 `{{access_token}}`처럼 이름으로 변수를 참조하며, Apidog는 전송 시 이를 해결합니다. 요청 정의의 헤더는 `Bearer sk-proj-aB3dEf...`가 아니라 `Bearer {{access_token}}`으로 표시됩니다. 실제 비밀 정보는 프로젝트 루트의 `.env` 파일에 앉아서 읽히기를 기다리고 있지 않습니다. 이것은 `.env`가 하드코딩보다 낫다는 것과 동일한 이유로 중요하며, 한 단계 더 나아갑니다. 자격 증명은 더 이상 소스 옆에 있는 파일의 평문 줄이 아닙니다. API 클라이언트 내의 관리되는 값이며, 간접적으로 참조됩니다.
로컬 값은 비밀 정보를 머신에 보관합니다
Apidog는 각 변수에 대해 두 가지 종류의 값 사이에 의도적인 선을 긋습니다. Apidog 서버에 동기화되고 팀원에게 보이는 공유 또는 초기 값이 있습니다. 그리고 당신의 머신에만 남아 있고 절대 업로드되지 않는 로컬 또는 현재 값이 있습니다. 공식 지침은 명시적입니다: 토큰 및 비밀번호와 같은 민감한 데이터는 절대 클라이언트를 떠나지 않도록 로컬 값에 저장하십시오. 실질적인 효과는 프로젝트 구조를 복제하는 팀원이 `access_token`, `db_password` 등 변수 이름과 형태를 얻지만, 실제 비밀 정보는 얻지 못한다는 것입니다. 각 개발자는 자체 로컬 값을 채웁니다. 동기화된 프로젝트 데이터에 누구의 실제 프로덕션 토큰도 포함되지 않으며, 유출될 실제 키의 공유 파일도 없습니다.
환경 관리 및 환경 격리
Apidog의 환경 관리는 이전 섹션의 범위 지정 습관을 중심으로 구축되었습니다. 개발, 스테이징, 프로덕션 등 별도의 환경을 정의하고, 각 환경은 자체 기본 URL과 자체 변수 값 세트를 가집니다. 변수는 환경 범위가 지정됩니다: 활성 환경의 값만 적용되며, 환경을 전환하면 전체 자격 증명 세트가 한 번에 전환됩니다. 이것은 구조적으로 환경 격리를 제공합니다. `payment_api_key` 변수는 개발 환경에서는 샌드박스 키를, 프로덕션 환경에서는 프로덕션 키를 보유합니다. 이들 간에 이동하기 위해 요청을 편집할 필요가 없습니다. 환경을 전환하기만 하면 됩니다. 값이 환경에 바인딩되어 있으므로, 개발 자격 증명이 실수로 프로덕션 호출에 사용될 수 없으며, 프로덕션 비밀 정보는 로컬 개발 환경에 전혀 존재할 필요가 없습니다. 유출된 개발 환경은 개발 값을 노출합니다. 프로덕션은 손상되지 않습니다.
강력한 경계가 필요한 팀을 위한 Vault Secrets
팀에서 프로덕션 비밀 정보가 API 클라이언트에 전혀 닿지 않아야 한다면, Apidog Enterprise 플랜은 HashiCorp Vault, Azure Key Vault 또는 AWS Secrets Manager에서 직접 비밀 정보를 가져오는 Vault Secret 기능을 추가합니다. Apidog는 Vault 경로 및 메타데이터만 저장합니다. 실제 비밀 값은 요청 시에 가져와 로컬 클라이언트에서 암호화되며, 프로젝트를 통해 팀원과 공유되지 않습니다. 자격 증명의 본거지는 전용 비밀 관리자로 유지되며, 이는 프로덕션 자격 증명이 존재해야 하는 바로 그곳입니다. 환경 변수 워크플로를 사용해 보려면, Apidog를 다운로드하고 프로젝트를 생성하고, 환경 관리를 열고, 로컬 전용 값을 가진 환경 변수로 자격 증명을 추가하십시오. 몇 분밖에 걸리지 않으며 확장 프로그램이 읽을 수 있는 평문 파일에서 실제 비밀 정보를 제거합니다. 솔직히 말씀드리자면, 비밀 정보를 Apidog로 옮기면 저장소와 작업 공간에 있는 평문 자격 증명의 수가 줄어듭니다. 그렇다고 해서 손상된 도구로부터 머신이 면역되는 것은 아닙니다. 심층 방어는 여전히 적용됩니다: 설치하는 확장 프로그램을 감사하고, 프로덕션 키를 최소 권한 및 짧은 수명으로 유지하며, 일정에 따라 순환하십시오. Apidog는 "자격 증명이 어디에 저장되는가" 부분을 처리합니다. 나머지는 여전히 당신의 책임입니다.
결론
GitHub 침해 사고는 명확한 신호입니다. 공격자들은 신뢰할 수 있는 도구와 평문 구성 파일을 가진 개발자 머신이 어떤 프로덕션 서버보다도 더 쉬운 표적이라는 것을 알아냈습니다. 그 머신을 완벽하게 안전하게 만들 수는 없습니다. 하지만 손상된 IDE 확장 프로그램이나 유출된 저장소가 공격자에게 거의 아무것도 넘겨주지 않도록 할 수는 있습니다. 하나의 감사로 시작하십시오. 가장 많이 작업하는 저장소를 열고 `key`, `secret`, `token`, `password`를 검색하십시오. `.env`가 Git 기록에 있는지 확인하십시오. 무엇을 발견하든 노출된 것으로 간주하십시오. 순환한 다음, 실제 값을 엉뚱한 도구가 읽을 수 없는 곳으로 옮기십시오. Apidog를 다운로드하고 다음 API 자격 증명을 평문 파일 대신 환경 변수에 넣으십시오. 더 넓은 맥락에서, GitHub 침해 사고 후 자체 호스팅 API 도구 및 API 키 관리 도구에 대한 동반 문서들도 좋은 다음 읽을거리입니다.
FAQ
VS Code 확장 프로그램이 정말로 제 .env 파일과 API 키를 읽을 수 있나요?
네. VS Code 확장 프로그램은 사용자 계정의 파일 권한으로 에디터 프로세스 내에서 실행됩니다. 이는 디렉토리를 나열하고, 파일을 열고, `.env` 파일, 구성 파일, `~/.aws/credentials`와 같은 자격 증명 파일을 포함한 내용을 읽을 수 있습니다. 이는 많은 확장 프로그램이 합법적으로 파일 접근을 필요로 하기 때문에 정상적인 확장 프로그램 동작입니다. 위험은 악성 또는 손상된 확장 프로그램이 동일한 접근 권한을 사용하여 비밀 정보를 수집한다는 것입니다. 이것이 2026년 5월 GitHub 침해 사고의 메커니즘입니다.
.gitignore에 .env를 추가하는 것만으로 API 키를 보호하기에 충분한가요?
아니요. `.gitignore`는 `git add` 중에 추적되지 않은 파일을 건너뛰도록 Git에 지시할 뿐입니다. 규칙이 존재하기 전에 이미 커밋된 파일에는 아무런 영향을 미치지 않으며, 비밀 정보는 상관없이 Git 기록에 남아 있습니다. 또한 디스크의 파일에도 아무런 영향을 미치지 않습니다. `.env` 파일은 여전히 작업 공간에 평문으로 존재하며, 모든 로컬 도구 또는 확장 프로그램에서 완전히 읽을 수 있습니다. `.gitignore`는 정직한 실수를 방지하는 방법으로 취급하고, 보안 경계로 오해하지 마십시오.
Git 기록에서 API 키를 발견하면 어떻게 해야 하나요?
저장소가 비공개이더라도 즉시 손상된 것으로 간주하십시오. 먼저 키를 순환하여 노출된 값이 작동하지 않도록 하십시오. 그런 다음 `git filter-repo`와 같은 도구를 사용하여 기록에서 파일을 제거하고, 팀과 조율 후 정리된 기록을 강제 푸시하십시오. 마지막으로, 실제 자격 증명을 평문 파일에서 제거하여 동일한 유출이 다시 발생하지 않도록 하십시오. 지속적인 관행을 위해 API 키 관리 도구 가이드를 참조하십시오.
Apidog에 API 키를 저장하면 노출을 어떻게 줄일 수 있나요?
Apidog를 사용하면 자격 증명을 환경 변수로 저장하고 요청에서 이름으로 참조할 수 있으므로, 실제 비밀 정보가 저장소의 평문 `.env` 파일에 저장되지 않습니다. 각 변수는 머신에만 남아 있고 서버나 팀원에게 동기화되지 않는 로컬 전용 값을 지원하며, 문서에서는 토큰과 비밀번호를 여기에 보관하도록 권장합니다. 환경 범위가 지정된 변수는 개발 및 프로덕션 자격 증명을 분리합니다. 이는 도구가 스크랩할 수 있는 파일에 있는 실제 비밀 정보의 수를 줄여주지만, 손상된 도구로부터 머신이 면역되도록 하지는 않습니다.
Apidog도 VS Code 확장 프로그램을 가지고 있는데, 그것이 위험한가요?
네, Apidog는 VS Code 확장 프로그램과 MCP 서버를 제공합니다. 이 글의 요점은 어떤 도구도 공급망 공격에 면역된다는 것이 아닙니다. 어떤 클라이언트 측 도구도 그렇지 않습니다. 요점은 비밀 정보가 어디에 저장되는지에 있습니다. 환경 변수에 로컬 전용 값으로 자격 증명을 보관하거나, 볼트 통합을 사용하는 것은 Apidog 자체 확장 프로그램을 포함하여 머신의 어떤 도구라도 손상될 경우 노출되는 평문 키의 수가 줄어든다는 것을 의미합니다. 심층 방어, 확장 프로그램 감사, 최소 권한 및 순환은 여전히 적용됩니다.
API 키의 범위 지정과 순환의 차이점은 무엇인가요?
범위 지정은 키가 수행할 수 있는 작업과 적용되는 범위를 제한합니다: 개발 키는 샌드박스에만 접근하고, 읽기 전용 키는 쓰기 작업을 할 수 없습니다. 순환은 키의 값을 일정에 따라 변경하여 이전 값이 작동하지 않도록 합니다. 범위 지정은 유출된 키가 일으킬 수 있는 피해를 줄이고, 순환은 유출된 키가 유용하게 유지되는 시간 창을 줄입니다. 둘 다 필요합니다. 함께 사용하면 도난당한 키는 거의 잠금 해제하지 못하고 곧 만료됩니다.
API 키를 얼마나 자주 순환해야 하나요?
사고 발생 후에만 순환하는 대신, 정해진 일정에 따라 순환하십시오. 합리적인 기준은 높은 권한의 프로덕션 자격 증명은 매월, 낮은 위험 키는 분기별로 순환하는 것이며, 이는 위험 허용 범위와 규정 준수 규칙에 따라 조정됩니다. 정기적인 순환은 감지하지 못한 유출의 유효 수명을 제한하고 순환 프로세스를 잘 연습되게 유지하여, 실제 사고가 발생했을 때 급히 서두르는 것이 아니라 일상적인 일이 되도록 합니다.
프로덕션 API 키가 개발자 노트북에 있어야 하나요?
이상적으로는 아닙니다. 프로덕션 자격 증명은 가능한 한 적은 곳에 존재해야 하며, 일반적으로 전용 비밀 관리자와 프로덕션 런타임에 있어야 하며, 개발자 머신으로 복사되어서는 안 됩니다. 개발자는 비프로덕션 데이터에 범위가 지정된 개발 또는 스테이징 자격 증명을 사용하여 작업해야 합니다. 노트북이 손상되면 공격자는 실제 고객 시스템이 아닌 샌드박스에 접근합니다. Apidog의 환경 격리 및 볼트 통합은 프로덕션 값을 로컬 개발 환경에서 제외함으로써 이를 지원합니다.