콘텐츠로 이동

보안과 개인정보

이 페이지는 당신이 할 수 있는 것만 씁니다: 트래픽이 어디로 가는지 알기, 자격 증명을 올바른 곳에 두기, 데이터가 어디에 남는지 알기, 교체할 수 있게 되기. tansr 내부의 방어선(권한 엔진, 보호 경로, 하드 보안 레드라인, 감사 체인)은 각 형태의 가이드에서 이미 다루었으며, 여기서는 당신의 조작과 관련될 때만 참조합니다.

아웃바운드 통신: 트래픽이 어디로 가고, 어떻게 좁히는가

섹션 제목: “아웃바운드 통신: 트래픽이 어디로 가고, 어떻게 좁히는가”
목적지 언제 끌 수 있는가
tansr 플랫폼 게이트웨이 api.tansr.com 플랫폼 모드 로그인 후: 모델 호출, 설정 번들 가져오기, 하트비트, 사용량 보고, 잔액 TANSR_ESCAPE_LOCAL=1을 설정해 완전 로컬 모드로 들어가면 전체 비활성화
공식 배포 지점 bash.tansr.com 당신이 명시적으로 /update 또는 tansr update를 실행할 때만. 시작 시 자동 확인은 절대 하지 않음 TANSR_UPDATE_CHANNEL=none 또는 TANSR_NO_UPDATE_CHECK=1. 기업은 자체 호스팅 매니페스트 TANSR_UPDATE_MANIFEST_URL을 지정할 수 있음
당신이 설정한 모델 공급자 완전 로컬 모드에서 providers.*.baseUrl 당신이 결정
당신이 설정한 MCP 서버 / 자체 검색과 미디어 엔드포인트 세션 안의 도구 호출 당신이 결정. 프로젝트 층 MCP 서버는 명시적으로 신뢰를 부여해야 함
모델이 도구를 통해 접근하는 임의의 URL(WebFetch / Http) 세션 안 권한 규칙의 제약을 받음. deny 규칙으로 도구 전체를 비활성화할 수 있음

무인 배포(tansr serve / headless에서 auto로 권한 개방)의 권장 기준선은 네트워크 출구 허용 목록입니다: 모델 API 등 필요한 목적지만 허용하고, DNS와 이미 수립된 연결 이외에는 기본적으로 거부합니다. 컨테이너나 최소 권한 전용 사용자와 결합하고, 파일 시스템 쓰기 면은 작업 디렉터리로 제한합니다. 참고 템플릿은 저장소 안 deploy/serve/에 있습니다.

이미 존재하는 사용자에게 보이는 방어선 두 가지: 같은 명령 안에서 비밀 파일(.env, 키, .aws/credentials)을 참조하면서 외부 전송 동작(curl / scp / git push …)을 동반하면 항상 거부되며, 어떤 모드와 규칙으로도 뒤집을 수 없습니다. 세션이 한 번 비밀 파일을 읽으면 그 이후의 외부 전송 동작은 모두 질문으로 바뀝니다(세션 오염). tansr CLI 0.5.0에서 제공 예정: 모든 아웃바운드 통신(WebFetch / Http / hooks / 오디오 다운로드)이 통일된 출구를 거치도록 바뀌고, DNS 해석 후 사설망, 루프백, 링크 로컬 주소를 판정하며, 내부망이나 메타데이터 주소를 가리키는 가져오기는 이유와 함께 거부됩니다. Http 도구와 hooks가 참조할 수 있는 자격 증명 환경 변수는 허용 목록 http.allowedAuthEnvVars로 수렴하며, 목록 밖이면 요청을 보내지 않습니다.

SDK와 세션 서비스는 무엇에 연결하는가

섹션 제목: “SDK와 세션 서비스는 무엇에 연결하는가”
  • @tansr/sdk 토큰 방식은 당신이 전달한 baseUrl(플랫폼 게이트웨이)과 명시적으로 설정한 MCP 서버에만 연결합니다. SDK는 사용자 디렉터리를 스캔하지 않고, 자체 검색 엔드포인트도 없습니다.
  • @tansr/serve의 업스트림 체인은 appid/appkey → POST /v1/app-tokens → GET /t1/config + POST /t1/heartbeat → POST /t1/exchange이며, 모두 apiBaseUrl을 가리킵니다. 그 밖에 당신이 설정한 턴 종료 webhook URL(아웃바운드 요청에는 어떤 인증 자격 증명 헤더도 붙지 않으며, 진위는 서명으로 확인)과 선택적 콜드 계층 객체 저장소가 있습니다.
  • 모바일 SDK는 당신의 세션 서비스 baseUrl에만 연결하며, 플랫폼에 직접 연결하지 않습니다.

자격 증명: 어디에 두고, 어디에 두지 않는가

섹션 제목: “자격 증명: 어디에 두고, 어디에 두지 않는가”
자격 증명 누구를 나타내는가 올바른 위치 절대 두지 않는 곳
개인 액세스 토큰(PAT) 당신 본인 콘솔에서 생성한 뒤 tansr init(마스크 입력) 또는 CI의 TANSR_PAT 환경 변수에만 제공 shell 기록(--pat로 직접 주면 흔적이 남음), 스크립트 평문, 저장소
이 컴퓨터의 파생 앱 키 당신의 이 기기 tansr init이 자동으로 운영 체제 키체인(macOS Keychain / Linux secret-service / Windows DPAPI)에 기록. 사용할 수 없으면 0600 파일로 폴백하며 명확히 경고 당신이 건드릴 필요 없음. tansr doctor의 자격 증명 저장소 섹션에서 위치를 볼 수 있음
모델 공급자 API key(완전 로컬 모드) 당신의 공급자 계정 환경 변수. 설정 파일에는 변수 이름만 auth.env에 기록 settings.json, 오류 메시지, /config 출력(이들은 값을 절대 포함하지 않음)
앱 키 appid / appkey 당신의 앱 당신의 서버 프로세스 환경 변수(Node 프로세스 또는 @tansr/serve) 단말 기기, 로그, 오류 응답, 저장소(.env.gitignore에)
단기 app_user 토큰 당신의 어느 최종 사용자 Electron 메인 프로세스 메모리. @tansr/serve 프로세스 내부 renderer 프로세스, 영구 저장소. 모바일은 절대 접촉하지 않음
당신의 로그인 token(모바일) 당신의 사용자 authProvider로 요청마다 제공하며, SDK는 영구 저장하지 않음 SharedPreferences / DataStore / UserDefaults / 로그
세션 서비스 /v1 Bearer(--token / TANSR_SERVE_TOKEN) 운영자 환경 변수 /v2 면과 서로 통하지 않음. 최종 사용자에게 재사용하지 말 것
webhook secret 당신의 푸시 백엔드 세션 서비스와 수신 측 각자의 환경 변수 로그. 엔진은 절대 출력하지 않음

반복해서 말할 가치가 있는 레드라인 세 가지: appkey는 절대 당신의 서버 밖으로 나가지 않습니다. app_user 토큰은 절대 세션 서비스 밖으로 나가지 않습니다. 세션 id는 인증 요소가 아닙니다.

CLI에는 당신을 위한 마스킹 규율이 한 층 더 있습니다: 보고서, 로그, 내보낸 트랜스크립트 안의 키는 일괄 sk-...뒤 4자리 형태로 마스킹됩니다. tansr sessions export의 산출물은 바로 티켓에 첨부할 수 있습니다.

데이터 보존: 어디에, 얼마나, 누가 삭제하는가

섹션 제목: “데이터 보존: 어디에, 얼마나, 누가 삭제하는가”
  • 세션, 설정 캐시, 사용량 큐, 프로젝트 메모리는 <storageRoot>/(기본값 ~/.tansr. TANSR_STORAGE_ROOT 또는 총 루트 TANSR_USER_HOME으로 리디렉션 가능)에 저장됩니다. 플랫폼에 로그인한 뒤 새 데이터는 계정별로 <storageRoot>/identities/<계정 지문>/에 격리됩니다.
  • 세션마다 디렉터리 하나: journal.jsonl(해시 체인), meta.json, attachments/, 한도 초과 산출물 spill/. 이미지 바이트는 <storageRoot>/image-cache/<sessionId>/에 캐시됩니다. Shell의 긴 출력은 <작업 디렉터리>/.tansr/shell-output/에, TTS 오디오는 <작업 디렉터리>/.tansr/artifacts/<sessionId>/에 저장됩니다.
  • 자동으로 삭제되지 않습니다. 정리는 tansr sessions prune으로 합니다(기본값은 dry-run으로 목록만 나열하고, --apply를 붙여야 삭제. 보존 정책 --keep-days 기본값 90과 --keep-last 기본값 500의 합집합. 오늘의 세션과 사용 중인 세션은 절대 삭제하지 않음. 손상된 디렉터리는 --include-broken이 필요). tansr logout은 신원 저장소 데이터를 삭제하지 않습니다.
  • 세션 종료 시의 metrics.json에는 개수와 비율만 있으며, 경로, 명령, 규칙 원문은 없습니다. 외부 텔레메트리는 기본적으로 꺼져 있습니다: 현재 버전에는 외부 보고 채널이 전혀 존재하지 않습니다.
  • 플랫폼 측은 단말 세션 내용을 저장하지 않고 계량만 합니다. 플랫폼 세션 레지스트리에는 30일 비활성 임대가 있으며, 만료되면 보관 처리됩니다.
  • 세션 기록은 당신이 설정한 store 디렉터리 <dir>/agent-sessions/<endUserKey>/sessions/<sessionId>/에 저장됩니다. endUserKey는 최종 사용자 id의 해시이며 신원이 아닙니다. 콜드 계층을 당신의 객체 저장소에 연결할 수 있으며, 세그먼트는 평문 JSONL(압축)입니다. 암호화, 키 관리, 데이터 소재지, 접근 제어는 당신의 책임입니다(policy.transform 연결점).
  • 메모리 상태의 짧은 창: 종료 레코드는 30분 보존, 유휴 24시간이면 디스크에 저장. DELETE /v2/sessions/:id는 닫기이며 삭제가 아닙니다. 오늘의 store는 기본적으로 영구 보존입니다. 저장소 보존 기간 스캔(일 단위 나이와 사용자별 개수로 휴면 세션 삭제)은 @tansr/serve 0.7.0에서 제공 예정입니다. 실제 삭제는 store.delete로 합니다.
  • 구조화 로그 필드에는 토큰과 메시지 내용이 절대 들어가지 않습니다. 메트릭 라벨에는 sessionId / endUserId가 절대 들어가지 않습니다.
  • 단말로 내려가는 권한 요청 프레임에는 완전한 도구 인자가 절대 실리지 않으며, 대상 요약만 있습니다. webhook 페이로드에는 메시지 내용과 자격 증명이 절대 실리지 않습니다.

Android / iOS SDK는 자격 증명을 캐시하지 않습니다. 뷰 상태는 메모리에 있습니다. sessionId를 로컬에 저장할지(콜드 스타트 resume을 위해)는 당신이 결정합니다. id만 저장하고, 내용도 자격 증명도 저장하지 않습니다.

교체와 폐기: 각 자격 증명을 어떻게 바꾸는가

섹션 제목: “교체와 폐기: 각 자격 증명을 어떻게 바꾸는가”
자격 증명 어떻게 바꾸는가 영향 범위
PAT 콘솔에서 새로 하나 만들고, 이 컴퓨터에서 tansr init --fresh로 다시 로그인한 뒤, 콘솔에서 이전 PAT를 삭제 PAT는 tansr logout으로 절대 폐기되지 않음. 다른 기기가 아직 같은 것을 사용 중일 수 있음
이 컴퓨터의 파생 앱 키 tansr init을 다시 실행하면 교체되어 기간이 연장됨(만료가 가까우면 세션 안에 “키가 곧 만료됩니다” 안내가 표시됨). tansr logout은 로컬을 지우고 원격 비활성화를 최대한 시도. 기기를 잃었으면 콘솔에서 해당 디바이스 키를 수동으로 비활성화할 수 있음 각 기기가 각자의 키를 보유(호스트 이름 + 디바이스 id로 명명)하며 서로 대체하지 않음
앱 키 appkey 콘솔에서 교체(대응하는 POST /v1/apps/:id/rotate). 서버 환경 변수를 업데이트한 뒤 프로세스 재시작 최후의 전면 차단: 이전 appkey는 즉시 무효화
어느 최종 사용자의 토큰 콘솔 또는 관리 API에서 최종 사용자 단위로 폐기(POST /v1/apps/:id/app-user-revocations). 그 사용자의 기존 토큰은 즉시 모두 거부됨. 당신 시스템에서 그의 로그인 상태를 끊으면 자연히 공급이 중단됨(토큰 TTL 60–86400초, 갱신은 없음) 그 사용자에게만 영향
앱 전체 콘솔에서 앱 비활성화 말단 전부 거부
세션 서비스 /v1 Bearer TANSR_SERVE_TOKEN / --token을 바꾸고 재시작 /v1 면 호출자가 동기화해야 함
webhook secret 수신 측이 먼저 새 값과 이전 값을 동시에 받아들이고, 그다음 세션 서비스 쪽을 바꾸고, 마지막에 이전 값을 철회 기간 중 전달 손실 없음
당신의 로그인 token(모바일) 당신의 로그인 체계에 속함. SDK는 401 시 authProvider로 최대 2번 다시 받고, 여전히 401이면 종료 상태로 들어가 당신의 명시적 재연결을 기다림 토큰을 새로 받았는데도 401이면 폐기나 설정 오류이며, 일시적 흔들림이 아님

플랫폼 측에서 토큰 무효화를 유발하는 코드는 하나뿐입니다: unauthorized(401). 세션 서비스가 이를 받으면 같은 요청 안에서 캐시된 토큰을 내보내고, 다시 발급하고, 한 번 다시 보냅니다. 단말 쪽 SDK가 이를 보면 위의 2번 수렴 절차를 따릅니다. 다른 코드(403, 429, 5xx)는 모두 토큰이 잘못되었음을 의미하지 않으므로, 그 때문에 다시 발급하지 마세요.

  • tansr doctor: 자격 증명이 키체인에 있는가, 평문 파일에 있는가? localProviders 섹션이 당신의 예상과 맞는가(플랫폼 모드 / 이스케이프 해치)? 무인 기준선에 관한 안내가 있는가?
  • 저장소에서 TANSR_APP_KEY / sk- / tansr_sk_를 한 번 grep해서 실제 값이 들어가지 않았는지 확인.
  • 세션 서비스를 0.0.0.0에 바인딩할 때 /metrics는 내부망에만 노출되는가? store 디렉터리는 로컬 디스크이며 공유되지 않는가?
  • 당신의 토큰 발급 엔드포인트는 자체 로그인 상태 뒤에서만 발급하고, endUserId는 항상 서버 세션에서 가져오며 요청 본문을 신뢰하지 않는가?
  • 콜드 계층 객체 저장소의 수명 주기 규칙과 암호화는 설정되었는가?