메인 콘텐츠로 건너뛰기
화면에서 읽을 수 있는 자격 증명은 유출할 수 있는 자격 증명입니다. 새 키를 한 번 복사하고 나면, 거의 그 평문이 다시 필요하지 않습니다 — 당신이 필요한 것은 그것을 인식하는 것입니다: 이게 어떤 키인지, 어떤 환경인지, 실패하는 에이전트가 사용하는 그것인지. OrcaRouter의 콘솔은 작동하는 시크릿을 결코 다시 인쇄하지 않고 그것에 답합니다: 모든 키는 식별하기에 딱 충분한 글자만 유지하고 나머지를 숨기는 마스킹된 형태로 렌더링됩니다. 이 페이지는 마스킹된 형태가 어떻게 보이는지, 언제 평문이 표시되고 표시되지 않는지, 그리고 당신 자신의 로그와 도구에서 API 키를 마스킹하는 값을 안전하게 다루는 방법을 다룹니다.

1. 왜 표시 시 API 키 값을 마스킹하는가

전체 키는 베어러 자격 증명입니다: 그것을 읽는 누구든 그 키의 제한까지 당신으로서 게이트웨이를 호출할 수 있습니다. 콘솔 뷰는 스크린샷, 화면 공유, 지원 티켓, 버그 리포트로 끊임없이 복사됩니다 — 그래서 키 목록에 라이브 시크릿을 보여주는 것은 그 하나하나를 자격 증명 유출로 바꿀 것입니다. 마스킹은 보통 뒤섞이는 두 가지 필요를 분리하여 이를 해결합니다:
  • 식별어떤 키인가? 한눈에 읽을 수 있는 안정적이고 마스킹된 지문으로 답합니다.
  • 사용시크릿은 무엇인가? 생성 시 정확히 한 번, 그리고 그 후로는 의도적인 역할 게이트 공개 뒤에서 답합니다.
콘솔은 어디서나 첫 번째 필요를 충족하고 두 번째를 게이트하므로, 기본 표면 — 당신이 하루 종일 응시하는 키 목록 — 은 결코 사용 가능한 시크릿을 담지 않습니다.
마스킹된 키는 작동하는 자격 증명이 아닙니다. 그것은 요청을 인증할 수 없습니다. 오직 생성 시 복사한 전체 평문(sk-orca-…), 또는 게이트된 엔드포인트를 통해 다시 공개된 것만 게이트웨이를 호출할 수 있습니다.

2. 마스킹된 형태는 어떻게 보이는가

콘솔은 키의 브랜드 접두사, 그다음 고정된 별표 연속, 그다음 마지막 네 글자를 보여줍니다 — 두 키를 구별하기에는 충분하지만, 어느 쪽도 재구성하기에는 충분하지 않게.
당신이 생성한 것콘솔이 보여주는 것
sk-orca-9f3aK2…long…7Qm4sk-orca-9f3****7Qm4
첫 세그먼트는 sk-orca- 접두사와 몇 개의 선행 글자를 유지합니다; 마지막 네 글자는 로그 라인이나 오류를 교차 참조할 때 당신이 인식할 꼬리입니다. 그 사이의 모든 것은 고정된 마스크로 접힙니다 — 별표 연속은 상수이므로, 그 너비는 결코 키의 진짜 길이를 드러내지 않습니다.
특정 키를 빠르게 찾아야 할 때 마스킹된 꼬리를 키의 environment 레이블 및 이름과 짝지으세요 — 네 글자 꼬리에 prod / staging 태그를 더하면 평문을 결코 드러내지 않고 목록에서 올바른 것을 골라내기에 거의 항상 충분합니다.

3. 평문이 표시될 때 — 그리고 표시되지 않을 때

전체 키가 당신의 복사 대상이 되는 순간은 정확히 한 번이며, 그것을 다시 가져올 단일 게이트 경로가 있습니다.
키를 발행할 때, 콘솔은 전체 sk-orca-… 평문을 한 번 표시합니다. 그때 그것을 당신의 시크릿 매니저로 복사하세요. 그 키의 이후 모든 뷰 — 목록, 상세 패널, 검색 결과 — 는 마스킹된 형태만 보여줍니다.
일반 키의 평문을 필요할 때 다시 공개할 수 있지만, 그것은 Developer+ 역할 뒤의 의도적 작업입니다 — 기본 목록이 결코 노출하는 것이 아닙니다. 게이트웨이 범위 키(is_firewall_gateway)를 재공개하려면 Admin(또는 Owner) 역할이 필요합니다, 왜냐하면 그 토큰은 등록된 MCP 서버 자격 증명을 읽을 수 있기 때문입니다.
키 목록 표시, 키 상세 열기, 검색, 그리고 토큰 객체의 모든 읽기는 마스킹된 형태를 반환합니다. 평문은 목록이나 검색 응답에 결코 포함되지 않습니다.
재공개가 게이트되고 게이트웨이 범위 키는 다시 읽으려면 Admin이 필요하므로, 생성 시점의 복사를 당신의 유일한 신뢰할 수 있는 캡처로 취급하세요. 그것을 즉시 시크릿 매니저에 저장하세요. 일반 키의 평문을 잃으면 다시 공개할 수 있습니다(Developer+); 그것을 공개할 수도 복구할 수도 없다면, 더 이상 읽을 수 없는 키를 우회하기보다 새 키로 로테이션하세요.

4. 하나의 구체적 예시: 유출된 키 식별하기

알림이 발동한다고 합시다 — 어떤 키가 예상치 못한 IP에서 호출을 하고 있고 — 로그 라인이 마스킹된 꼬리 …7Qm4를 담고 있습니다. 조치하는 데 평문이 필요하지 않습니다:
  1. 콘솔 Keys 목록(/console/token)을 엽니다. 모든 행이 마스킹된 지문 — sk-orca-9f3****7Qm4 — 과 그 environment 레이블을 보여줍니다.
  2. …7Qm4 꼬리(와 prod 태그)를 문제의 행과 매칭합니다. 마스킹된 형태가 바로 여기서 당신이 필요한 식별자입니다 — 목록, 알림, 또는 그것의 스크린샷에서 시크릿이 노출되지 않습니다.
  3. 그 키를 Disable하여 일시 중지하거나, Delete하여 영구히 폐기하세요 — 둘 다 결코 평문을 인쇄하지 않는 마스킹 안전 작업입니다. 키 관리유출된 키 대응을 참조하세요.
전체 분류가 마스킹된 지문에서 실행됩니다. 평문은 그것이 속한 당신의 시크릿 매니저에 남습니다.

5. 당신 자신의 로그와 도구에서의 마스킹

게이트웨이는 자체 표면을 마스킹합니다; 당신은 당신 쪽을 통제합니다. 키가 당신의 스택에 들어갈 수 있는 어디서든 동일한 원칙이 적용됩니다:
  • Authorization 헤더나 원시 sk-orca-… 값을 결코 로깅하지 마세요. 어떤 키가 호출을 했는지 기록해야 한다면, 콘솔이 사용하는 동일한 형태 — 접두사와 마지막 네 글자 — 를 로깅하고, 전체 시크릿이 아니라.
  • 평문을 오직 시크릿 매니저에만 저장하고, 소스 컨트롤, CI 로그, 또는 리포에 체크인된 설정 파일에는 결코 저장하지 마세요. 키는 콘솔에서 정확히 마스킹되므로 당신 자신의 시스템이 라이브 시크릿이 사는 유일한 곳입니다.
  • 키를 좁게 범위 지정하여 유출된 자격 증명조차 제한된 피해 반경을 갖게 하세요 — 하나의 모델, 하나의 IP 범위, 하나의 지출 상한. 최소 권한 체크리스트를 참조하세요.
마스킹은 표시 노출을 줄입니다; 그것은 실제로 유출되는 키의 위력을 줄이지 않습니다. 로그의 마스킹된 지문은 안전하지만, 시크릿 매니저의 라이브 키는 여전히 완전히 인증합니다 — 그래서 좁은 범위와 빠른 로테이션이 마스킹만큼이나 중요합니다.

6. 이것이 나머지 키 위생에 어떻게 들어맞는가

마스킹은 자격 증명에 대한 심층 방어 자세의 한 레이어입니다:

키 관리

키를 생성, 비활성화, 폐기 — 목록의 모든 마스킹된 행 뒤의 생애 주기.

토큰 객체

유출된 키의 피해 반경을 제한하는 한계를 포함한, 키가 담는 모든 필드.

키 로테이션

이전 키를 복구하거나 신뢰할 수 없을 때 새 키로의 무중단 인계.

유출된 키 대응

자격 증명이 노출되었다고 의심하는 순간 해야 할 일.
키, 정책, 워크스페이스가 어떻게 중첩되어 각 에이전트에 가장 좁은 신원을 주는지에 대한 더 큰 그림은 범위 & 키를 참조하세요. 규칙은 단순합니다: 콘솔은 키를 인식하기에 충분한 것을 보여주고 결코 유출하기에 충분한 것은 보여주지 않습니다. 평문은 시크릿 매니저에 두고, 그 외 모든 곳에서는 마스킹된 지문에 의지하고, 키의 신원이 의심될 때는 그 순간 로테이션하세요.