Msty Nexus · 글 19편Msty Nexus
  1. Msty Nexus 설치부터 첫 요청까지
  2. Fleet으로 여러 기기 관리하기
  3. Providers에서 제공업체와 엔드포인트 연결하기
  4. Local Runtimes로 로컬 엔진 설치하고 관리하기
  5. Models에서 모델 카탈로그 관리하기
  6. Presets와 route pack으로 모델 설정 고정하기
  7. Smart Routes로 요청 나눠 보내기
  8. Smart Balancer로 여러 기기에 요청 분산하기
  9. Cluster로 여러 Mac을 묶어 큰 모델 돌리기
  10. Chat Lab으로 앱 연결 전에 시험하기
  11. Data Protection으로 민감 정보 걸러 내기
  12. 게이트웨이 API로 앱 연결하기
  13. Client Tokens로 앱별 접근 관리하기
  14. Teams로 팀별 기기 접근 정하기
  15. Usage, Gauge, Activity로 사용 현황 보기
  16. Nexus Settings 항목별 안내
  17. Nexus 보안 모델 이해하기
  18. Nexus 문제 해결
  19. Nexus 요금제별 기능 차이

이 글에서 다루는 것Nexus의 로컬 토큰, 쓰기 전용 제공업체 키, 네트워크 공개와 CORS의 차이, Access from anywhere의 중계 경로, 앱 pairing, 진단과 감사 기록의 경계를 공식 Security 문서 기준으로 정리합니다.

이 글을 읽어야 하는 때

Security 문서는 LAN 접근, 브라우저 CORS, 원격 controller 프로필을 켜기 전에 이 내용을 읽으라고 적었습니다. 혼자 한 컴퓨터에서만 쓴다면 기본 설정 그대로가 가장 안전한 상태이므로, 마지막 절의 기본 수칙만 봐도 됩니다.

Msty Nexus는 로컬 우선 소프트웨어입니다. 보안 모델은 다섯 가지 위에 서 있습니다.

  1. 로컬 Runtime API
  2. 로컬 Nexus 토큰
  3. 쓰기 전용 제공업체 자격 증명
  4. 명시적으로 켜야 하는 네트워크 공개
  5. 민감 정보가 가려진 진단

Msty 제품 전체의 보안 관점은 보안과 거버넌스에 따로 있습니다.

토큰 모델

모든 /v1/* 엔드포인트는 로컬 Nexus 토큰을 요구합니다. 예외는 로컬 네이티브 앱의 pairing 요청 하나뿐입니다.

토큰은 세 가지 헤더 형식 가운데 하나로 보냅니다. Authorization: Bearer <token>, X-Msty-Nexus-Token: <token>, x-api-key: <token>입니다.

로컬 Nexus 토큰은 클라이언트를 Nexus에 인증하는 데만 쓰입니다. 온라인 제공업체나 로컬 런타임으로는 절대 전달되지 않습니다.

저장 방식은 이렇습니다.

대상 저장 방식
관리되는 클라이언트 토큰 SQLite에 해시로 저장
토큰 원문 만들 때 한 번만 돌려줌
토큰 목록·조회 응답 정보와 표시용 접두어만 노출
Nexus 앱 자신의 로컬 토큰 운영체제 키체인

해시로 저장한다는 것은, Nexus의 데이터 파일을 누가 들여다봐도 토큰 원문을 되살릴 수 없게 해 둔다는 뜻입니다. 그래서 잃어버린 토큰은 다시 볼 수 없고 새로 만들어야 합니다.

제공업체 키의 경계

제공업체 키는 Msty Nexus Runtime이 운영체제의 안전한 저장소나 설정된 자격 증명 백엔드에 저장합니다. API 응답은 credentialConfigured(설정되어 있음) 여부만 돌려줍니다.

문서는 키가 나타나면 안 되는 곳을 하나하나 적었습니다.

  • 제공업체 API 응답
  • 앱 상태
  • SDK 출력
  • 로그
  • 작업(job) 정보
  • 감사 정보
  • 진단 보고서
  • 생성된 런타임 설정 파일

제공업체의 부가 정보(metadata)는 API로 보이는 값입니다. 그래서 Nexus는 apiKey, authorization, token, secret처럼 자격 증명처럼 생긴 키 이름을 부가 정보에 넣는 것을 거부합니다. 실수로 키를 엉뚱한 칸에 넣는 일을 막는 장치입니다.

네트워크 공개

Runtime은 기본적으로 로컬에만 묶입니다. 다른 믿을 수 있는 기기가 접속해야 할 때만 네트워크 공개를 씁니다.

가장 자주 헷갈리는 두 가지를 구별해야 합니다.

설정 정하는 것 적용 시점
Bind address 다른 기기가 Runtime에 닿을 수 있는가 Runtime을 다시 시작해야 적용
CORS 어떤 브라우저 출처가 Runtime을 부를 수 있는가 Runtime이 도는 중에 바로 적용

여기서 따라 나오는 사실 두 가지입니다.

  • CORS는 Runtime을 LAN에 공개하지 않습니다.
  • LAN에 공개해도 토큰 인증은 없어지지 않습니다.

로컬 Nexus 토큰은 믿는 클라이언트에게만 나눠 줍니다.

브라우저와 CORS의 경계

허용된 출처의 CORS 사전 요청(preflight)은 토큰 없이 통과합니다. 그러나 실제 /v1/* 호출은 여전히 로컬 Nexus 토큰이 필요합니다.

Nexus는 제공업체가 보낸 Access-Control-* 응답 헤더를 걷어 내고, 자기에게 설정된 정책으로 CORS 헤더를 씁니다. 제공업체 주소나 로컬 런타임 도구가 브라우저 공개 정책을 덮어쓸 수 없습니다.

브라우저 출처에서 온 요청은 pairing 요청을 만들 수 없습니다. 네이티브 앱 pairing은 루프백 전용입니다.

Access from anywhere

Access from anywhere는 등록된 기기로 가는 호스팅 HTTPS 경로를 만들어 줍니다. Runtime을 수신 네트워크 포트로 내놓지 않고도 밖에서 닿을 수 있게 합니다. 이 주소가 작동하려면 기기가 Fleet으로 나가는 연결을 유지해야 합니다.

항목 내용
주소 자체의 자격 증명 없습니다
추론 요청에 필요한 것 대상 기기가 발급한 클라이언트 토큰
제공업체 자격 증명 그 기기에 그대로 남습니다
데이터가 지나는 길 Msty가 운영하는 중계 서버

마지막 줄이 중요합니다. 요청과 응답이 Msty가 호스팅하는 중계를 지납니다. 업무상 승인된 데이터 경로에 호스팅 중계가 들어가지 않는다면, 사설 네트워크 접근이나 믿을 수 있는 VPN을 쓰라고 문서는 안내합니다.

켜는 방법과 요금제 조건은 Fleet에 있습니다.

Pairing (앱 연결 승인)

로컬 앱 pairing은 네이티브 클라이언트가 명시적인 승인 절차를 거쳐 로컬 토큰을 요청하게 해 줍니다. 사용자가 토큰을 손으로 복사해 붙이지 않아도 되는 방식입니다.

제약이 촘촘합니다.

  • 요청은 루프백의 네이티브 클라이언트만 만들 수 있습니다.
  • 콜백 주소는 숫자로 적은 루프백 IP와 명시적인 포트를 써야 합니다.
  • localhost, 주소에 넣은 자격 증명, fragment, 루프백이 아닌 콜백은 거부됩니다.
  • 승인하면 토큰은 요청한 쪽의 콜백으로만 전달됩니다.
  • 콜백 전달이 실패하면 Nexus는 만들었던 토큰을 되돌립니다.
  • 승인 API는 민감 정보가 가려진 토큰 정보만 돌려줍니다.

사용자가 지킬 것은 하나입니다. 화면에 표시된 코드가 방금 연 앱의 코드와 일치할 때만 pairing 요청을 승인합니다.

진단과 감사 기록

Nexus는 보안과 수명 주기에 관련된 변경에 대해 감사 사건을 기록합니다. 감사 기록을 읽을 때는 허용 목록(allow-list)에 있는 정보만 내보내므로, 오래되었거나 형식이 깨진 기록이 임의의 저장 데이터를 드러낼 수 없습니다.

진단에 들어갈 수 있는 것 진단에 들어가면 안 되는 것
버전과 플랫폼 정보 제공업체 키
Runtime 상태 로컬 토큰 값, 토큰 접두어
제공업체 자격 증명이 있는지 여부 로컬 경로
서비스 동작 지원 여부 요청 본문, 프롬프트, 응답
상태 ID와 메시지 키 제공업체 오류 원문
수치와 시각 프로세스 ID, 명령줄
안전한 작업 상태 생성된 파일 경로

로컬 파일과 모델 저장소

로컬 파일 가져오기는 입력으로만 쓰입니다. 예를 들어 llama.cpp의 GGUF 가져오기는 네이티브 앱에서 로컬 파일 경로를 받고, 파일을 Nexus가 관리하는 저장소로 복사한 뒤, 안전한 상대 정보만 남깁니다.

삭제 동작은 Nexus가 소유한 저장소와 기록으로 제한됩니다. 관리 대상이 아닌 것, 절대 경로, 심볼릭 링크로 빠져나가는 것, 경로를 거슬러 올라가는 것, 모델이 아닌 대상은 거부합니다.

기능별 보안 메모

다른 문서 페이지에 흩어져 있는 보안 관련 내용을 모았습니다.

기능 알아 둘 점
Smart Balancer 제공업체 키를 호출자나 다른 기기에 나눠 주지 않습니다. 대상마다 자기 자격 증명을 갖습니다
Cluster 일반적인 작업 흐름에서 SSH를 쓰지 않습니다. 자격이 있다고 Runtime을 공개해도 되는 것은 아닙니다
Teams 팀을 배정해도 제공업체 자격 증명이나 토큰 원문은 공유되지 않습니다
Data Protection 검사 모델은 Runtime 안에서 돌고, 찾아낸 내용은 저장하지 않습니다
Usage, Gauge, Activity 프롬프트와 응답 본문을 저장하거나 돌려주지 않습니다
Local Runtimes 연결된 앱이 추론 요청으로 업데이트 출처나 신뢰 설정을 바꿀 수 없습니다

기본 수칙

문서가 “실용적인 기준선”으로 제시한 일곱 가지입니다.

  1. 다른 믿을 수 있는 기기가 접근해야 하는 경우가 아니면 Runtime을 로컬 전용으로 둡니다.
  2. 앱이나 작업마다 클라이언트 토큰을 따로 만듭니다.
  3. 클라이언트를 없앨 때 토큰을 폐기합니다.
  4. *로 모든 출처를 허용하지 말고, 믿을 수 있는 특정 브라우저 출처를 추가합니다.
  5. 실제 업무 요청을 보내기 전에 제공업체 Test를 실행합니다.
  6. 진단 자료는 지원 요청에 써도 안전한 범위로 유지합니다.
  7. 게이트웨이 요청 로깅은 켜기 전에 검토합니다. 메타데이터만 기록하지만 의도적인 선택이어야 합니다.

문서에 없는 것

보안 검토에서 흔히 묻지만 공식 문서에는 설명이 없는 항목입니다.

  • 외부 보안 인증이나 감사 보고서
  • 저장 데이터(SQLite 파일 등)의 암호화 방식
  • 중계 서버의 위치와 로그 보관 정책
  • 취약점 신고 절차

이런 항목이 도입 조건이라면 Msty에 직접 문의해야 합니다.

참고한 문서