matters

View the Project on GitHub arinyaho/matters

RAG 보안 4: FHE가 바꾸는 사고 경로와 잔여 위협

이 글은 RAG 보안을 두고 내가 정리해온 4부작의 마지막 편이다.

3편은 이런 질문으로 끝났다.

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

가정 하나로 시작해보자

말이 너무 추상적으로 흐르는 걸 막기 위해 상황을 하나 가정해보자.

4편에서는 이 질문들에 ‘기술 이름’으로 바로 답하기보다 사고 경로가 어떻게 바뀌는지로 답해보려 한다.

위협모델의 조건을 분명히 하고 나면, 특정 PET(예: FHE)가 무엇을 가리고(cover) 무엇을 여전히 남기는지(residuals)를 과장 없이 적을 수 있다.

FHE(Fully Homomorphic Encryption, 동형암호)를 예로 들면, 장기 자산을 암호화해 보호했을 때 “데이터 유출 = 즉시 활용” 같은 경로가 (가정이 성립하는 한) “유출 + 키/경계 동시 붕괴”가 필요한 경로로 이동할 수 있다. 다만 잔여 위협은 남는다(아래에서 3개로 고정해 적는다).

이때 잔여 위협을 설명하는 공통 언어로 NIST AI RMF나 Google SAIF 같은 프레임이 도움이 된다.12


정책 기반 신뢰 vs 암호 기반 경계

여기서는 신뢰 모델을 두 축으로 나눠 비교해본다. 다만 A가 항상 B보다 낫다는 말을 하려는 게 아니다. 실제 시스템은 섞이고, 조직/환경에 따라 최적점이 달라진다.

모델 B는 “완벽한 비밀”을 약속하지 않는다. 대신 실패가 일어날 때의 경로와 비용을 바꾸는 비교 틀이 된다.

그리고 여기서 3편의 결론이 그대로 다시 등장한다. 평문 구간을 줄여도, 관측 신호(로그/캐시/메트릭/접근 패턴)는 남고 퍼질 수 있다. 그래서 모델 B를 이야기할수록 오히려 관측 경계(Observability boundary) 설계가 더 중요해진다.


사고 경로: 저장된 검색 자산 탈취

3편에서 나열한 장기 자산 중에서도 특히 레버리지가 크다고 느끼는 건 “저장되고 재사용되는 검색 자산”이다.

요청 단위가 아니라 쌓이고 재사용된다. 그래서 한 번 새면 blast radius가 커진다. 또 공격자 입장에서는 오프라인에서 반복 실험이 가능해진다.

모델 A(정책 기반)에서는 이 사고 경로가 비교적 직관적이다. 누군가가 저장소/스냅샷/인덱스 파일을 가져가면, 공격자는 오프라인에서 반복 실험을 할 수 있다. 그리고 “평문이 아니니까 안전” 같은 문장은 조건에 따라 쉽게 흔들린다. 파생 표현(임베딩/스코어/인덱스 구조)도 경우에 따라서는 value에 가까운 정보량을 갖기 때문이다.

모델 B(암호 기반)를 상정하면 이 사고 경로의 성격이 바뀐다. 위협모델을 좁히면, “인덱스를 훔치면 곧바로 검색이 된다”가 아니라 “인덱스를 훔쳐도, 추가로 키/경계까지 무너뜨려야 의미 있는 활용이 된다”로 이동할 수 있다. (가정이 성립하는 한) 공격의 즉시성이 낮아지고, 조직 입장에서는 사고 대응의 형태가 달라진다.

하지만 여기서 끝이 아니다. 남는 게 많다.

그래도 “저장된 검색 자산을 훔쳤을 때의 즉시성”을 낮추는 건, 많은 조직에서 사고의 종류를 바꾼다. 나는 이 지점이 RAG 보안을 “모델/프롬프트 문제”로만 볼 수 없게 만드는 이유 중 하나라고 생각한다.


무엇이 바뀌고 무엇이 남나

모델 B는 모든 사고 경로를 지워주지 않는다. 오히려 “어디가 안 바뀌는지”가 더 선명해진다.

운영자 열람

모델 A에서는 “보면 안 된다”를 정책과 통제로 관리한다. 권한 분리, 승인 프로세스, 사후 감사가 핵심이다. 하지만 긴급 장애 대응, 소수 슈퍼권한, 설정 실수가 겹치면 이 사고 경로는 반복해서 등장한다.

모델 B는 일부 구간에서 이 가능성을 구조적으로 줄일 수 있다. 다만 “열람이 불가능”해지는 게 아니라, 평문이 존재하는 지점으로 문제가 밀려난다. 결국 “평문이 생기는 경계”를 어디에 두는지로 대화가 옮겨간다.

장애 대응과 관측 신호

컨텍스트 레이어는 관측 없이는 운영이 어렵다. 캐시, 로그, 재시도, 샘플링, 재현 테스트가 붙는다. 모델 A에서 흔한 실패는 “장애 상황에서 민감한 value가 관측 신호로 남는 것”이고, 그 임시 산출물이 생각보다 오래 남는 것이다.

모델 B를 쓰더라도 관측 경계 문제는 남는다. 관측 신호를 줄이는 건 비현실적일 수 있다. 대신 관측 신호를 자산으로 보고 권한/격리/보존(retention)을 설계하는 문제로 돌아온다.

백업과 복제본

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

모델 B는 여기서도 “유출의 의미”를 바꿀 수 있다. 스냅샷만으로 즉시 value를 꺼내기 어렵게 만들 수 있기 때문이다. 대신 키 관리와 키 사용 권한이 중심축이 된다.


잔여 위협: 3개

사고 경로가 바뀐다고 해서 시스템이 “완전히 안전”해지지는 않는다. 그래서 나는 잔여 위협을 3개로 고정해서 적어두는 편이 대화가 덜 꼬인다고 느낀다. (더 늘릴 수도 있지만, 우선은 “합의 가능한 최소 세트”로 시작하자.)

1) 최종 평문 경계(모델 입력/출력)

장기 자산의 value를 가리더라도, 최종적으로 사용자·애플리케이션·모델이 만나는 지점에는 평문이 생긴다. 이 경계는 기술로 “미뤄”질 수는 있어도 사라지지 않는다. 그래서 결국 “평문이 생기는 지점이 어디인지”, “누가 접근하는지”, “얼마나 남기는지”를 문서화해야 한다.

2) 런타임/메모리

키를 쓰는 순간, 평문을 만드는 순간, 런타임은 공격 표면이 된다. 내부자/디버그 도구/메모리 덤프/에이전트의 장기 메모리 같은 경로가 전부 여기로 모인다. 그래서 암호 기반 경계를 얹을수록 “키 관리”만이 아니라 “운영자 권한/디버깅 권한/관측 권한”을 더 촘촘히 나눠야 한다.

3) 접근 패턴/메타데이터(관측 신호)

value를 숨겨도 metadata는 남는다. 그리고 관측 신호는 운영상 필요하다(없으면 운영이 안 된다). 결국 남는 숙제는 관측 경계를 설계하는 일이다: 누가 볼 수 있는지(권한), 테넌트/환경 간 격리가 되는지(격리), 얼마나 오래 남는지(보존), 원시 로그 대신 집계로 대체할 수 있는지(집계).


시리즈를 마치며

이 시리즈에서 내가 반복해서 하고 싶었던 말은 하나다.

RAG 보안 논의를 “모델이 평문을 보나”에서 끝내지 말고, 컨텍스트 레이어의 라이프사이클과 장기 자산, 관측 신호, 사고 경로로 옮겨보자는 것이다.

FHE 같은 개념은 이 대화를 “기술 이름”이 아니라 “실패의 형태”로 옮기는 데 도움이 된다. 일부 사고 경로의 비용을 바꿀 수 있기 때문이다. 대신 잔여 위협은 사라지지 않는다. 그래서 나는 마지막 질문을 이렇게 두고 싶다.

그래서 우리는 무엇을 보장하고, 무엇을 잔여 위협으로 문서화할 것인가?


References

  1. NIST — Artificial Intelligence Risk Management Framework (AI RMF 1.0) (PDF): https://nvlpubs.nist.gov/nistpubs/ai/nist.ai.100-1.pdf 

  2. Google — Secure AI Framework (SAIF): https://saif.google/ 

  3. Craig Gentry — A Fully Homomorphic Encryption Scheme (IACR ePrint 2009/616): https://eprint.iacr.org/2009/616 

  4. Homomorphic Encryption Standardization Consortium — Homomorphic Encryption Standard: https://homomorphicencryption.org/standard 

  5. Jung Hee Cheon et al. — Homomorphic Encryption for Arithmetic of Approximate Numbers (CKKS) (IACR ePrint 2016/421): https://eprint.iacr.org/2016/421