API 키나 접근 토큰이 공개 저장소, 업무 문서, 메신저 또는 화면 공유에 노출됐다면 게시물을 지우는 것만으로 끝내지 말고 해당 자격증명을 즉시 폐기하거나 비활성화하세요. 새 키는 비밀관리 도구에 저장하고 필요한 서비스·동작·기간으로 권한을 제한해야 합니다. 노출 시점 전후의 호출 기록에서 낯선 IP, 지역, 기능과 사용량을 확인하고, 키로 접근할 수 있었던 데이터와 변경 내역을 보존해 담당자에게 보고하세요.
노출된 키는 지우기 전에 먼저 폐기합니다
API 키와 접근 토큰은 비밀번호처럼 시스템을 대신 호출할 수 있는 자격증명입니다. 공개 저장소에서 파일을 삭제하거나 메신저 메시지를 회수해도 복제본, 알림, 캐시 또는 과거 이력에 값이 남을 수 있으므로 노출된 값 자체를 더 이상 쓸 수 없게 만드는 것이 우선입니다.
CISA의 클라우드 보안 기술 참조 구조는 API 키 유출에 대비한 폐기와 재발급 정책을 마련하고 키를 비밀로 유지하되 필요할 때 폐기할 수 있어야 한다고 설명합니다. 담당 서비스에서 해당 키를 즉시 비활성화하고, 운영 중단을 피해야 한다면 새 키를 안전하게 발급해 정상 동작을 확인한 뒤 기존 키를 폐기하되 전환 시간을 최소화하세요.
- 노출된 키·토큰의 식별자와 발견 시각 기록
- 서비스 관리자 화면에서 즉시 비활성화 또는 폐기
- 새 키 전환 뒤 기존 키가 실제 거부되는지 확인
새 키는 코드와 문서 밖의 비밀 저장소에 둡니다
새 자격증명을 소스코드, 설정 예제, 공동 문서나 채팅에 다시 붙여 넣으면 같은 사고가 반복됩니다. 조직이 승인한 비밀관리 도구나 클라우드의 비밀 저장 기능에 보관하고, 애플리케이션은 실행할 때 필요한 값만 불러오도록 구성하세요. 저장소 접근 권한과 조회 기록도 함께 관리해야 합니다.
CISA의 클라우드 사용사례는 인증서, 비밀번호, API 키 같은 자격증명을 추적·관리하는 공식 절차와 수명주기 관리가 가능한 비밀관리 시스템을 권고합니다. 개발·배포 과정에도 비밀값 검사를 연결하고 예제 파일에는 실제 값 대신 자리표시자만 사용하며, 로그와 오류 화면에 키 전체가 출력되지 않도록 마스킹하세요.
- 승인된 비밀관리 도구에 새 키 저장
- 코드·문서·메신저·작업 티켓에 실제 값 금지
- 빌드 로그·오류 화면·분석 도구의 비밀값 마스킹
한 개의 키에 필요한 권한과 기간만 부여합니다
모든 프로젝트와 자동화가 하나의 관리자 키를 공유하면 한 번의 노출이 넓은 피해로 이어지고 어떤 작업이 어느 시스템에서 발생했는지 구분하기 어렵습니다. 서비스나 애플리케이션별로 키를 분리하고 조회·등록·삭제 중 필요한 동작과 대상 자원만 허용하세요.
NIST SP 800-228의 API 보호 지침은 자격증명을 견고하게 인증·처리하고 권한을 올바르게 적용하며 호출 기록과 이상 징후를 관찰하는 통제를 제시합니다. 가능하다면 만료 시각, 허용 IP·네트워크와 사용량 제한을 설정하고, 담당자·용도·발급일·종료일을 자산 목록에 기록해 주기적으로 불필요한 키를 폐기하세요.
- 서비스·환경·자동화별 키 분리
- 필요한 API·동작·자원만 최소권한으로 허용
- 담당자·용도·발급일·만료일과 허용 위치 기록
호출 기록으로 노출 전후의 사용 범위를 확인합니다
키를 폐기한 뒤에는 발급 시점부터 폐기 시점까지의 API 호출, 로그인·관리자 변경, 데이터 조회와 다운로드 기록을 보존하세요. 평소와 다른 IP·국가·사용 시간, 갑작스러운 호출량 증가, 사용하지 않던 기능과 오류 반복을 찾아 정상 자동화 기록과 대조합니다.
키 문자열 자체를 사고 문서나 메일에 다시 복사하지 말고 키 식별자의 일부, 서비스명과 관련 시각으로 조사 대상을 구분하세요. 로그가 없거나 보존기간이 짧다면 영향이 없었다고 단정하지 말고 서비스 제공자에게 보존 가능한 기록을 요청하며, 연결된 다른 토큰이나 동일 권한의 자격증명도 함께 점검합니다.
- 노출 전후 API 호출·권한 변경·데이터 접근 로그 보존
- 낯선 IP·지역·시간·기능·호출량을 정상 사용과 대조
- 조사 기록에는 전체 비밀값 대신 키 식별자 일부만 사용
접근 가능했던 데이터와 변경 내용을 기준으로 후속 대응합니다
해당 키로 조회·수정·삭제할 수 있었던 시스템과 데이터를 목록화하고 실제 호출 기록과 비교하세요. 고객·직원 정보, 결제나 주문, 파일과 운영 설정에 접근할 수 있었다면 데이터 소유자와 개인정보보호·보안 담당자에게 즉시 알리고 원본 로그와 변경 전후 상태를 보존합니다.
무단 사용이 확인되면 생성된 계정, 바뀐 권한과 설정, 외부 전송 대상, 과금과 서비스 영향까지 조사하고 승인된 복구 절차로 되돌리세요. 신고·통지 필요성은 담당자가 관계 법령과 조직 절차에 따라 판단해야 하며, 복구 후에는 키 자동 탐지, 정기 교체, 만료 알림과 비상 폐기 책임자를 보완합니다.
- 키로 접근 가능했던 시스템·데이터·동작 목록화
- 무단 조회·변경·삭제·외부 전송·과금 영향 확인
- 복구 뒤 자동 탐지·만료 알림·비상 폐기 절차 점검
이 주제로 함께 많이 찾는 안내
상담 전에 많이 묻는 내용
Q. 저장소에서 키를 삭제했는데도 교체해야 하나요?
네. 공개 범위와 노출 시간을 정확히 알 수 없고 과거 이력이나 복제본에 남았을 수 있으므로, 노출된 값은 다시 안전한 것으로 간주하지 말고 폐기한 뒤 새 키를 발급하세요.
Q. 서비스가 멈출까 봐 기존 키를 바로 끌 수 없습니다.
새 키를 비밀 저장소에 등록하고 제한된 환경에서 정상 동작을 확인한 뒤 가능한 짧은 전환 시간 안에 기존 키를 폐기하세요. 두 키가 동시에 유효한 기간과 승인자를 기록하고 종료 여부를 확인해야 합니다.
Q. 주기적으로 키를 바꾸기만 하면 안전한가요?
교체만으로는 부족합니다. 서비스별 분리, 최소권한, 만료 설정, 비밀 저장소, 호출 로그와 이상 사용 알림을 함께 적용해야 노출 범위와 탐지 시간을 줄일 수 있습니다.
참고 출처 및 업데이트
NIST SP 800-228 Update 1, Guidelines for API Protection for Cloud-Native Systems, 작성기관 미국 국립표준기술연구소(NIST), 작성자 Ramaswamy Chandramouli·Zack Butcher, 작성일 2026-03-13, 수집일 2026-08-23CISA Cloud Security Technical Reference Architecture Version 2, 작성기관 미국 사이버보안 및 인프라 보안국(CISA)·미국 디지털 서비스(USDS)·연방위험인가관리프로그램(FedRAMP), 작성자 기관 공동, 작성일 2022-06, 수집일 2026-08-23CISA TIC 3.0 Cloud Use Case, 작성기관 미국 사이버보안 및 인프라 보안국(CISA), 작성자 미표기, 작성일 2023-04, 수집일 2026-08-23NIST NCCoE Secure Software Development, Security, and Operations Practices Appendix B, 작성기관 미국 국립표준기술연구소 국가사이버보안센터(NIST NCCoE), 작성자 미표기, 작성일 미표기, 수집일 2026-08-23최초 작성 2026-08-23 · 최종 수정 2026-08-23
