1. 왜 표시 시 API 키 값을 마스킹하는가
전체 키는 베어러 자격 증명입니다: 그것을 읽는 누구든 그 키의 제한까지 당신으로서 게이트웨이를 호출할 수 있습니다. 콘솔 뷰는 스크린샷, 화면 공유, 지원 티켓, 버그 리포트로 끊임없이 복사됩니다 — 그래서 키 목록에 라이브 시크릿을 보여주는 것은 그 하나하나를 자격 증명 유출로 바꿀 것입니다. 마스킹은 보통 뒤섞이는 두 가지 필요를 분리하여 이를 해결합니다:- 식별 — 어떤 키인가? 한눈에 읽을 수 있는 안정적이고 마스킹된 지문으로 답합니다.
- 사용 — 시크릿은 무엇인가? 생성 시 정확히 한 번, 그리고 그 후로는 의도적인 역할 게이트 공개 뒤에서 답합니다.
마스킹된 키는 작동하는 자격 증명이 아닙니다. 그것은 요청을 인증할 수 없습니다.
오직 생성 시 복사한 전체 평문(
sk-orca-…), 또는 게이트된 엔드포인트를 통해 다시
공개된 것만 게이트웨이를 호출할 수 있습니다.2. 마스킹된 형태는 어떻게 보이는가
콘솔은 키의 브랜드 접두사, 그다음 고정된 별표 연속, 그다음 마지막 네 글자를 보여줍니다 — 두 키를 구별하기에는 충분하지만, 어느 쪽도 재구성하기에는 충분하지 않게.| 당신이 생성한 것 | 콘솔이 보여주는 것 |
|---|---|
sk-orca-9f3aK2…long…7Qm4 | sk-orca-9f3****7Qm4 |
sk-orca- 접두사와 몇 개의 선행 글자를 유지합니다; 마지막 네 글자는
로그 라인이나 오류를 교차 참조할 때 당신이 인식할 꼬리입니다. 그 사이의 모든 것은
고정된 마스크로 접힙니다 — 별표 연속은 상수이므로, 그 너비는 결코 키의 진짜 길이를
드러내지 않습니다.
3. 평문이 표시될 때 — 그리고 표시되지 않을 때
전체 키가 당신의 복사 대상이 되는 순간은 정확히 한 번이며, 그것을 다시 가져올 단일 게이트 경로가 있습니다.생성 시 — 한 번 표시됨
생성 시 — 한 번 표시됨
키를 발행할 때, 콘솔은 전체
sk-orca-… 평문을 한 번 표시합니다. 그때 그것을
당신의 시크릿 매니저로 복사하세요. 그 키의 이후 모든 뷰 — 목록, 상세 패널, 검색
결과 — 는 마스킹된 형태만 보여줍니다.생성 후 — 재공개는 게이트됨
생성 후 — 재공개는 게이트됨
일반 키의 평문을 필요할 때 다시 공개할 수 있지만, 그것은 Developer+ 역할
뒤의 의도적 작업입니다 — 기본 목록이 결코 노출하는 것이 아닙니다. 게이트웨이
범위 키(
is_firewall_gateway)를 재공개하려면 Admin(또는 Owner) 역할이
필요합니다, 왜냐하면 그 토큰은 등록된 MCP 서버 자격 증명을 읽을 수 있기
때문입니다.그 외 모든 곳 — 항상 마스킹됨
그 외 모든 곳 — 항상 마스킹됨
키 목록 표시, 키 상세 열기, 검색, 그리고 토큰 객체의 모든 읽기는 마스킹된 형태를
반환합니다. 평문은 목록이나 검색 응답에 결코 포함되지 않습니다.
4. 하나의 구체적 예시: 유출된 키 식별하기
알림이 발동한다고 합시다 — 어떤 키가 예상치 못한 IP에서 호출을 하고 있고 — 로그 라인이 마스킹된 꼬리…7Qm4를 담고 있습니다. 조치하는 데 평문이 필요하지 않습니다:
- 콘솔 Keys 목록(
/console/token)을 엽니다. 모든 행이 마스킹된 지문 —sk-orca-9f3****7Qm4— 과 그environment레이블을 보여줍니다. …7Qm4꼬리(와prod태그)를 문제의 행과 매칭합니다. 마스킹된 형태가 바로 여기서 당신이 필요한 식별자입니다 — 목록, 알림, 또는 그것의 스크린샷에서 시크릿이 노출되지 않습니다.- 그 키를 Disable하여 일시 중지하거나, Delete하여 영구히 폐기하세요 — 둘 다 결코 평문을 인쇄하지 않는 마스킹 안전 작업입니다. 키 관리와 유출된 키 대응을 참조하세요.
5. 당신 자신의 로그와 도구에서의 마스킹
게이트웨이는 자체 표면을 마스킹합니다; 당신은 당신 쪽을 통제합니다. 키가 당신의 스택에 들어갈 수 있는 어디서든 동일한 원칙이 적용됩니다:Authorization헤더나 원시sk-orca-…값을 결코 로깅하지 마세요. 어떤 키가 호출을 했는지 기록해야 한다면, 콘솔이 사용하는 동일한 형태 — 접두사와 마지막 네 글자 — 를 로깅하고, 전체 시크릿이 아니라.- 평문을 오직 시크릿 매니저에만 저장하고, 소스 컨트롤, CI 로그, 또는 리포에 체크인된 설정 파일에는 결코 저장하지 마세요. 키는 콘솔에서 정확히 마스킹되므로 당신 자신의 시스템이 라이브 시크릿이 사는 유일한 곳입니다.
- 키를 좁게 범위 지정하여 유출된 자격 증명조차 제한된 피해 반경을 갖게 하세요 — 하나의 모델, 하나의 IP 범위, 하나의 지출 상한. 최소 권한 체크리스트를 참조하세요.
마스킹은 표시 노출을 줄입니다; 그것은 실제로 유출되는 키의 위력을 줄이지 않습니다.
로그의 마스킹된 지문은 안전하지만, 시크릿 매니저의 라이브 키는 여전히 완전히
인증합니다 — 그래서 좁은 범위와 빠른 로테이션이
마스킹만큼이나 중요합니다.
6. 이것이 나머지 키 위생에 어떻게 들어맞는가
마스킹은 자격 증명에 대한 심층 방어 자세의 한 레이어입니다:키 관리
키를 생성, 비활성화, 폐기 — 목록의 모든 마스킹된 행 뒤의 생애 주기.
토큰 객체
유출된 키의 피해 반경을 제한하는 한계를 포함한, 키가 담는 모든 필드.
키 로테이션
이전 키를 복구하거나 신뢰할 수 없을 때 새 키로의 무중단 인계.
유출된 키 대응
자격 증명이 노출되었다고 의심하는 순간 해야 할 일.
