현지화 위협 모델¶

번역 작업을 서드파티에 외주하거나 크라우드소싱하면 추가적인 보안 및 개인정보 위험이 발생합니다. 내부 개발 팀과 달리 번역가는 조직과의 신뢰 관계가 제한적일 수 있으며 다양한 관할권에서 활동할 수 있습니다. 이 모델은 외부 번역 기여자와 관련된 위협을 식별하고 분류합니다.

주요 가정¶

번역가는 다양한 수준의 검증을 거친 계약자, 자원봉사자 또는 대행사일 수 있습니다.
번역가들이 Weblate를 사용할 수 있도록 접근 권한이 필요합니다.
번역 문자열에는 미출시 기능, 법률 용어 또는 보안 메시지와 같은 민감한 콘텐츠가 포함될 수 있습니다.
조직은 번역가의 로컬 환경에 대한 통제가 제한적입니다.

위협 분류 (STRIDE)¶

1. 스푸핑¶

S1. 합법적인 기여자를 사칭하는 가짜 번역가 계정.
- 위험: 프로젝트에 대한 무단 접근 또는 악의적 문자열 주입.
- 대응 방안:
  - 강력한 인증 (2FA)을 적용합니다. 강제 2단계 인증 를 참조하세요.
  - 계약된 번역가들의 신원을 확인합니다.
  - 역할 기반 접근을 사용하여 프로젝트 범위를 제한합니다. 프로젝트 접근 제어 를 참조하세요.

2. 변조¶

T1. 유해한 페이로드를 포함하는 악의적 번역.
- 위험: 번역이 적절히 이스케이프되지 않은 경우 JavaScript, HTML 또는 형식 문자열 공격이 주입될 수 있습니다.
- 대응 방안:
  - Weblate에서 엄격한 입력 유효성 검사를 적용합니다. 안전하지 않은 HTML 과 같은 품질 검사를 강제하면 도움이 될 수 있습니다. 품질 검사 및 강제 검사 를 참조하세요.
  - CI에서 번역 파일에 대한 자동 보안 스캔을 사용하세요.
  - 번역 파일에서 위험한 마크업의 사용을 제한합니다. 사용하는 현지화 프레임워크에 따라 암시적, 선택적 또는 서드파티 라이브러리가 필요할 수 있습니다.
T2. 오해의 소지가 있는 번역 삽입.
- 위험: 사용자가 애플리케이션 동작에 대해 오도될 수 있음 (예: 동의 대화 상자가 잘못 번역된 경우).
- 대응 방안:
  - 중요 문자열에 대한 동료 검토를 수행합니다. 동료 검토 또는 전담 검토자 를 참조하세요.
  - 조작을 방지하기 위해 스타일 가이드와 용어집 를 유지합니다.

3. 부인¶

R1. 악의적이거나 품질이 낮은 번역에 대한 분쟁.
- 위험: 번역가가 주입된 문제에 대한 책임을 부인할 수 있음.
- 대응 방안:
  - Weblate의 모든 변경 사항이 기록됩니다.
  - 변하지 않는 히스토리를 위해 버전 제어와 함께 Weblate를 사용합니다.

4. 정보 유출¶

I1. 미출시 제품 세부 정보 유출.
- 위험: 번역가가 미출시 기능이나 기밀 용어에 조기 접근할 수 있음.
- 대응 방안:
  - 민감한 문자열에 대한 접근을 제한하기 위해 프로젝트를 분리합니다.
  - 외부 기관과 비공개 계약을 적용합니다.
  - 매우 기밀인 문자열의 번역을 공개 출시까지 연기합니다.
I2. 문자열 내 개인 데이터 노출.
- 위험: 번역가가 포함된 사용자 데이터에 접근하거나 오용할 수 있음.
- 대응 방안:
  - 원문 문자열에 실제 사용자 데이터를 노출하지 마세요.
  - 민감한 필드에 플레이스홀더를 사용하세요.

5. 서비스 거부¶

D1. 쓸모없는 번역의 대량 제출.
- 위험: 검토 대기열이 압도됨; 출시 일정이 중단됨.
- 대응 방안:
  - 팀 역량에 맞는 적절한 워크플로를 선택하세요. 워크플로 사용자 지정 을 사용하여 언어별로 조정할 수 있습니다.
  - 자동 번역 품질 검사를 구성합니다. 품질 검사 를 참조하세요.

6. 권한 상승¶

E1. 번역가가 프로젝트 전체 또는 관리자 권한을 무단으로 획득.
- 위험: 변조 또는 데이터 노출로 이어지는 권한 상승.
- 대응 방안:
  - 최소 권한 원칙을 적용합니다.
  - 접근 권한 및 그룹 멤버십을 정기적으로 검토합니다.

자산 목록¶

원문 문자열: 미출시 제품 기능 또는 법률 텍스트가 포함될 수 있습니다.
번역된 문자열: 최종 사용자에게 직접 표시되는 출력.
사용자 데이터 플레이스홀더: 문자열에서 참조되는 이름, 이메일 또는 ID.
접근 자격 증명: 번역가, 대행사 또는 봇의 계정.

신뢰 경계¶

조직 ↔ 번역가: 인증 및 역할 기반 접근이 적용되어야 합니다.
번역 플랫폼 ↔ 소스 제어: 동기화에는 보안 토큰/키가 필요합니다.
번역가 ↔ 번역 플랫폼: 모든 입력은 빌드에 통합되기 전에 검증되어야 합니다.
플랫폼 ↔ 최종 사용자: 코드 주입을 방지하기 위해 번역이 검증되어야 합니다.

대응 방안 요약¶

번역가 계정에 2FA 및 RBAC를 적용합니다. 강제 2단계 인증 를 참조하세요.
전문 번역가에게 비공개 계약 또는 계약을 요구합니다.
번역에 대한 자동 품질/보안 스캔을 사용합니다. 품질 검사 를 참조하세요.
중요 문자열에 대한 동료 검토를 수행합니다. 동료 검토 또는 전담 검토자 를 참조하세요.
민감한 콘텐츠의 노출을 줄이기 위해 프로젝트 가시성을 제한합니다. 프로젝트 접근 제어 를 참조하세요.
Weblate 서버를 정기적으로 패치하고 강화하세요. Weblate 지원 받기 도 고려해 보세요.
버전 제어 시스템에서 모든 번역 변경에 대한 변하지 않는 버전 히스토리을 유지합니다.

결론¶

서드파티 번역가는 내부 기여자에 비해 고유한 위험을 도입합니다. 적절한 기술적, 조직적, 계약적 통제를 통해 조직은 이러한 위험을 완화하고 제품 무결성과 규정 준수를 유지하면서 외부 번역 서비스를 안전하게 통합할 수 있습니다.