멀티테넌트 AI 서비스: SQLite·파일·비밀 키의 격리 경계
TECH INSIGHT / EXPLAINED
멀티테넌트 서비스의 핵심 검증은 “A 고객의 로그인으로 B 고객의 ID를 넣으면 어떻게 되는가”입니다. 목록 조회뿐 아니라 파일, 검색 색인, 캐시, 백업, 백그라운드 작업까지 같은 질문을 적용해야 합니다.
실제 프로젝트의 로컬 실행 화면
기존 프로젝트의 화면 또는 함수를 로컬에서 실행해 촬영했습니다. 개인정보 없는 샘플 입력을 사용했으며, 실행한 범위는 각 이미지 아래에 설명했습니다.
테넌트 ID는 인증된 관계에서 결정한다
요청 헤더의 tenant_id를 그대로 신뢰하지 말고 로그인 주체의 소속과 요청 범위를 확인합니다. 인증된 컨텍스트나 명시적 인자로 저장소에 전달할 수 있지만, 누락되면 필터 없는 조회로 바꾸지 않고 거부해야 합니다. 테넌트에 묶인 API 키도 탈취·오설정 위험이 없어지는 것은 아닙니다.
리소스 ID 조회·수정·삭제에는 tenant 조건을 함께 걸고, 다른 테넌트의 ID를 아는 경우도 권한을 주지 않습니다. 세션은 tenant·user·agent·channel 외에 실제 대화/thread 구분도 고려하세요. 같은 사용자의 서로 다른 대화를 무조건 합치지 않습니다.
SQLite 규모는 고객 수보다 쓰기 패턴
공유 DB에 tenant_id를 두는 방식과 테넌트별 파일 방식 모두 가능합니다. 파일을 나눠도 실행 프로세스가 모든 파일을 열 수 있다면 자동으로 강한 격리가 생기지는 않습니다. SQLite WAL은 읽기와 쓰기의 동시성을 개선하지만 동시에 쓰는 writer는 하나이며 busy 오류 가능성은 남습니다. 실제 쓰기 시간·빈도·체크포인트·복구 부하를 측정하세요.
tenant_id 선두 인덱스는 해당 조회에 유용할 수 있지만 보안 경계나 원본 행의 물리 격리를 보장하지 않습니다. 쿼리 조건, 외래 키, 복합 유일성, 접근 검사와 별개입니다. foreign_keys와 busy_timeout처럼 연결별 설정이 필요한 항목도 각 연결에서 적용했는지 확인합니다.
경로를 확인한 뒤 여는 두 단계의 틈
EvalSymlinks로 검사하고 나중에 os.Open하는 사이에 경로가 바뀔 수 있습니다. 새 파일이 없다는 이유로 symlink 검사를 생략하면 상위 디렉터리의 외부 링크를 놓칩니다. Go 1.24 이후에는 os.OpenRoot와 root의 파일 연산처럼 루트 안에서 직접 처리하는 API를 검토하세요. 운영체제별 한계와 실행 권한은 여전히 확인해야 합니다.
파일 도구에 임의 셸 실행을 함께 주면 파일 API만의 경계를 우회할 수 있습니다. 도구 전체의 권한, 프로세스 격리, 마운트·네트워크 접근을 같은 위협 모델로 설계합니다.
암호화 설정이 없으면 저장 실패
비밀 키를 암호화할 키가 없을 때 평문을 반환하는 fallback은 두지 않습니다. 관리형 비밀 저장소 또는 검증된 인증 암호화 라이브러리를 쓰고, nonce 재사용을 막으며 키 버전과 회전 계획을 둡니다. 테넌트·레코드 식별자를 추가 인증 데이터로 결합하면 암호문 바꿔치기 탐지에도 도움이 됩니다. 접두사 문자열만으로 암호문이 유효하다고 믿지 않습니다.
배포 전 비교할 요청
- 테넌트 누락, 존재하지 않는 역할, 다른 테넌트의 리소스 ID는 거부되는가.
- 같은 ID로 목록·검색·다운로드·수정 경로를 각각 호출해도 경계가 같은가.
- 삭제가 색인·캐시·파일과 보관 정책에 맞는 백업 처리까지 이어지는가.
- 암호화 키 누락·잘못된 키·변조된 암호문이 평문 저장이나 성공 응답으로 이어지지 않는가.
참고 자료
내용·예제 검토: 2026-09-29
댓글
댓글 쓰기