matters

View the Project on GitHub arinyaho/matters

RAG 보안 3: 장기 자산과 관측 신호가 실제 사고 경로(incident path)를 만든다

2편에서 나는 RAG에서 “관련성(relevance)”과 “인가(ACL)”가 섞이는 순간 시스템이 달라진다고 말했다. 컨텍스트는 ‘정답의 근거’이기 전에 ‘권한이 통과된 결과물’이어야 한다는 이야기다.

2편의 마지막에 한 가지 질문을 남겼다.

“인가를 통과한 컨텍스트는 결국 어디에 남나?”

이번 글은 그 질문에 대한 내 답을 정리하는 3편이다. 실제 사고 경로(incident path)가 어디서 생기는지를 보는 렌즈를 만들고 싶다.

RAG 시스템은 컨텍스트를 만들면서 동시에 ‘남는 것’을 만든다. 그리고 그 ‘남는 것’이 장기 자산이 되어 사고 경로의 시작 지점이 될 수 있다.

이 글에서 말하는 경계는 하나가 아니다.

권한 경계를 지켜도 관측 경계가 넓으면 새는 길이 생긴다.


컨텍스트 레이어: “산출물 공장”

RAG를 “질의 → 컨텍스트 → LLM”으로만 보면 보안은 LLM 입력의 평문 경계만 바라보게 된다. 그런데 프로덕션에서 컨텍스트 레이어는 다음과 같이 많은 동작과 산출물을 내포하고 있다.

즉, 컨텍스트 레이어는 요청마다 컨텍스트를 “만드는” 동시에, 운영과 성능을 위해 여러 산출물을 “저장”한다. 이 저장되는 산출물들을 장기 자산(long-lived artifacts)이라고 부르고자 한다.

장기 자산은 보통 두 특징을 가진다.

1) 요청 단위가 아니라 저장되고 재사용된다 2) 한 번 유출되면 파급(blast radius)이 크다

여기에서 자연스레 다음과 같은 질문을 떠올리게 된다.

“시스템은 무엇을 남기고 누가 볼 수 있나?”


장기 자산: 자연스레 쌓이는 부산물

장기 자산의 범주는 대략 다음과 같이 나눠볼 수 있다.

이 장기 자산은 악의적 목적으로 만들어지는 것이 아니다. 운영 중 성능과 품질, 그리고 디버깅을 위해 생성되고 유지된다.

문제는 2편에서 다룬 바와 같이 ACL(접근제어)이 들어온 뒤다. “사용자에게 보여주면 안 되는 문서”가 컨텍스트에서 빠졌더라도 후보/결과/트레이스가 로그와 캐시에 남을 수 있다. 이때 관측 경계가 넓어지며 권한 경계를 우회하는 누설이 생길 수 있다. MITRE가 로그에 민감정보가 들어가는 문제를 따로 CWE로 분류하는 이유가 이쪽이다.1


에이전트: 추가 장기 자산 생산

여기에 에이전트(agent)나 워크플로우가 붙으면 자산은 더 늘어난다.

에이전트가 하는 일은 대개 “검색”만이 아니다. 요약하고, 계획을 만들고, 툴을 호출하고, 중간 결과물을 저장한다. 그리고 그 과정에서 새로운 산출물이 생긴다.

이 산출물들은 UX와 생산성에는 큰 도움을 주지만, 보안 관점에서는 “또 하나의 저장소”이기도 하다. 특히 요약/메모는 원문보다 더 작은 형태로 민감 정보를 응축해버릴 수 있다. 이는 “정보의 압축 유출”이라고 볼 수 있다. 원문이 드러나지 않아도 요약만으로 중요한 결론이 새어 나갈 수 있다.


value vs metadata

3편에서 다루고 싶은 가장 단순한 레이블 분류는 다음 두 가지이다.

많은 방어 기법이 “value를 가리는 데”는 강하지만 metadata는 그대로 남기 쉽다. 암호화된 검색에서도 access pattern 같은 메타데이터 누설이 공격 표면이 될 수 있다는 것은 오래된 주제이다.2

그리고 RAG에서는 “파생 표현”이 value인지 metadata인지가 자주 혼동된다. 예를 들어 임베딩은 원문이 아니지만, 조건에 따라 원문 수준 정보를 유의미하게 드러낼 수 있다는 연구들이 있다.3 그래서 나는 임베딩을 단순 최적화 부산물로만 취급하는 것을 지양해야 한다고 생각한다.

이 말은 “임베딩은 곧바로 원문과 같다”는 주장과 다르다. 위협모델, 모델/데이터 조건, 공격자의 관측 범위에 따라 위험의 크기는 크게 달라질 수 있다. 내가 하고 싶은 말은 한 줄이다.

“무엇이 남는가(what remains)”를 value와 metadata로 나누지 않으면, 기술 논의가 과장이나 단정으로 흐르기 쉽다.


관측 경계: 관측 신호가 닿는 곳

남는 것을 줄이기 위해 관측 신호(로그/캐시/메트릭)를 무작정 줄이는 것은 비현실적이다. 시스템 운영에는 관측 신호가 반드시 필요하기 때문에 다음과 같은 인식이 필요하다.

관측 신호도 자산이다. 그래서 관측 신호에도 권한/격리/보존(retention) 설계가 필요하다.

특히 ACL이 있는 RAG에서는 관측 경계 설계가 잘못되면 관측 신호가 권한 경계를 우회할 수 있다.

이건 평문 경계 문제로만 설명되지 않는다. 관측 신호가 관측 경계를 넘어 퍼지며 생기는 문제다. 그래서 사고 경로(incident path)가 달라진다.


4가지 사고 경로 (incident path)

조직과 제품의 위협모델에 따라 중요도는 달라질 수 있다. 이 네 가지가 전부를 포괄한다고 주장하려는 건 아니다. 다만 내가 프로덕션에서 반복해서 보게 되는 유용한 분류라고 생각한다.

1) 재현 데이터: 티켓/업무 메신저 확산

품질 이슈를 재현하려고 “top-k 결과 + 유사도 + 필터링 정보”를 그대로 남긴다. 그게 이슈 트래커, 업무 메신저, 이메일로 퍼진다. 그 순간 관측 신호가 관측 경계를 넘어 이동한다.

2) ACL 변경: 캐시/인덱스 잔존

여러 이유로 권한은 변할 수 있다(팀 이동, 퇴사, 링크 만료…). 그런데 캐시/인덱스/로그는 더 오래 남을 수 있다. 그래서 “지금은 접근 불가”가 “어딘가에는 남아 있음”으로 바뀐다. 이 비대칭은 장기 자산의 위험으로 이어질 수 있다.

3) 스냅샷/백업: 복제본 확산

장기 자산은 백업되고 복제된다. 테스트 환경, 분석 파이프라인, 비용 절감을 위한 장기 보관까지 겹치면 “원본 시스템”보다 “복제본”이 더 느슨한 경계가 되는 경우가 생긴다.

4) 에이전트 메모리: ‘새 저장소’

대화 요약과 메모리는 편하지만, 작은 실수로 권한이 다른 대화에 재사용되거나, 테스트/평가를 위해 덤프되거나, 분석을 위해 모인다. 그리고 요약은 원문보다 더 강한 형태로 value를 응축해버릴 수 있다.


다음 질문: value를 덜 보이게

여기까지의 이야기는 다소 비관적으로 들릴 수 있다. 하지만 나는 오히려 이 렌즈가 보안 대화를 덜 감정적으로 만든다고 느낀다.

이걸 분리해서 문서화하면 “완벽한 보안” 논쟁 대신 “무엇이 남는지”를 정직하게 적는 설계로 대화가 옮겨간다.

다음 글에서는 이 질문으로 넘어가보려 한다.

“그럼 장기 자산의 ‘내용(value)’을 덜 보이게 만들 수 있나?”

FHE 같은 암호 기반 접근이 강력한 수단이 되는 이유도 결국 여기로 수렴한다. 다만 어떤 설계를 택하든 남는 흔적을 0으로 만들기는 어렵다.


References

  1. MITRE CWE-532 — Insertion of Sensitive Information into Log File: https://cwe.mitre.org/data/definitions/532.html 

  2. PoPETs 2017 — Leakage abuse attacks against searchable encryption: https://petsymposium.org/popets/2017/popets-2017-0034.php 

  3. EMNLP 2023 — Text embedding inversion: https://aclanthology.org/2023.emnlp-main.765/