AI 보안 기본
3줄 요약
- AI 보안은 prompt injection, sensitive data disclosure, insecure output handling, excessive agency를 중심으로 봐야 한다.
- 모델은 보안 경계가 아니므로 인증, 인가, 권한 필터, output validation은 서버가 강제해야 한다.
- RAG 문서와 tool 결과도 공격 입력이 될 수 있다.
핵심 정리
- OWASP LLM Top 10은 LLM 애플리케이션의 대표 위험을 정리한다.
- prompt injection은 사용자 입력뿐 아니라 문서, 웹 페이지, tool result에서 올 수 있다.
- 개인정보는 provider 전송, 로그 저장, eval dataset, vector DB에 들어갈 수 있다.
- tool 권한이 과하면 excessive agency 위험이 생긴다.
- 모델 출력은 HTML, SQL, command로 바로 실행하지 않는다.
헷갈리는 지점
- 보안 프롬프트를 잘 쓰면 안전하다고 생각하기 쉽다.
- 핵심은 프롬프트는 방어층일 뿐 보안 경계가 아니라는 점이다.
- 서버 권한과 검증이 필요하다.
- 사내 도구는 내부 사용자만 쓰니 덜 위험하다고 생각하기 쉽다.
- 핵심은 사내 도구가 더 민감한 데이터와 강한 권한을 가질 수 있다는 점이다.
확인 질문
- AI 보안에서 모델을 보안 경계로 보면 안 되는 이유는 무엇인가?
- 모델은 prompt injection과 오류에 흔들릴 수 있으므로 권한과 실행 통제는 서버가 해야 한다.
- prompt injection은 어디서 올 수 있는가?
- 사용자 입력, RAG 문서, 웹 페이지, tool 결과, 외부 API 응답에서 올 수 있다.
개인정보와 데이터 흐름
3줄 요약
- AI 기능은 사용자 입력, 문서, 로그, eval dataset, provider 요청으로 개인정보가 이동할 수 있다.
- 개인정보는 수집, 전송, 저장, 보존, 삭제, 접근 권한을 모두 문서화해야 한다.
- 백엔드 개발자는 provider 데이터 정책과 로그 마스킹, vector index 삭제를 함께 봐야 한다.
핵심 정리
- 개인정보는 prompt, context, tool result, model output, trace에 섞일 수 있다.
- provider로 보내는 데이터와 저장되는 데이터를 구분한다.
- eval dataset은 운영 로그에서 만들 수 있지만 익명화와 최소화가 필요하다.
- vector DB에 개인정보가 들어가면 삭제와 재색인 절차가 필요하다.
- 로그에는 원문보다 hash, id, count, status를 우선 남긴다.
헷갈리는 지점
- provider가 유명하면 데이터 처리는 안전하다고 생각하기 쉽다.
- 핵심은 우리 서비스의 데이터 흐름과 계약 책임은 여전히 우리에게 있다는 점이다.
- 보안팀과 provider 정책을 확인해야 한다.
- 로그는 내부용이라 개인정보가 있어도 된다고 생각하기 쉽다.
- 핵심은 로그는 접근자가 많고 보존 기간이 길 수 있다는 점이다.
확인 질문
- AI 기능의 개인정보 흐름에서 확인할 저장 위치는 무엇인가?
- provider 요청, 애플리케이션 로그, trace, eval dataset, vector DB, result DB다.
- eval dataset을 운영 로그에서 만들 때 필요한 것은 무엇인가?
- 개인정보 제거, 권한 정보 보호, 접근 제어, 보존 기간이다.
3줄 요약
- 모델이 tool을 사용할 수 있게 되면 정보 조회와 상태 변경 권한을 얻게 된다.
- read-only tool과 write tool은 권한, idempotency, audit log, approval을 다르게 설계해야 한다.
- 모델 출력은 HTML, SQL, shell command, DB update로 직접 실행하면 안 된다.
핵심 정리
- excessive agency는 AI에게 너무 많은 권한과 자율 실행 능력을 주는 위험이다.
- write tool은 최소 권한, 승인, audit log, idempotency key가 필요하다.
- 모델이 생성한 SQL은 read-only, allowlist, row limit, timeout이 필요하다.
- HTML 출력은 XSS 관점에서 escape 또는 sanitize한다.
- shell command 생성은 자동 실행하지 않는 편이 안전하다.
헷갈리는 지점
- tool 권한을 줄이면 agent 성능이 떨어진다고 생각하기 쉽다.
- 핵심은 권한 제한이 사고 반경을 줄인다는 점이다.
- read-only와 draft 생성부터 시작한다.
- 모델 출력은 우리가 만든 것이니 내부 데이터라고 생각하기 쉽다.
- 핵심은 모델 출력도 신뢰할 수 없는 외부 입력처럼 검증해야 한다는 점이다.
확인 질문
- excessive agency를 줄이는 방법은 무엇인가?
- tool 최소 권한, read/write 분리, approval, idempotency, max step, audit log다.
- 모델 출력 SQL을 바로 실행하면 안 되는 이유는 무엇인가?
- 권한 우회, 데이터 유출, 과도한 쿼리, injection, 잘못된 변경 위험이 있기 때문이다.