이득:
- 인증과 승인을 분리하고 RBAC/ABAC를 통해 최소 승인을 적용하는 기능
- 사용자 컨텍스트에서 모델을 실행하여 혼합 프록시 위험을 방지하는 기능
- 비밀 관리 시스템으로 API 키를 저장하고 순환하는 기능
AI 시스템에 대한 공격의 상당 부분은 모델을 "속이는" 것이 아니라 도난당한 API 키나 과도하게 인증된 계정으로 시작됩니다. 이 보안 계층은 고전적인 정보 보안에서 비롯되었지만 AI의 맥락에서 새로운 위험을 추가합니다. 모델이 다른 사람을 대신하여 차량을 호출하고, 서비스 계정이 모든 데이터에 액세스하고, 키가 GitHub로 유출됩니다. 본 단원에서는 인증, 권한 부여(RBAC/ABAC), 최소 권한 부여 및 비밀 관리를 통해 AI 시스템에 대한 접근 범위를 좁히는 방법을 알아봅니다.
인증과 권한 부여의 차이점
두 용어는 종종 혼동됩니다.
- 인증: "당신은 누구입니까?" — 사용자/서비스가 실제로 자신이 주장하는 사람(비밀번호, 토큰, 인증서, MFA)임을 증명합니다.
- 승인: "당신은 무엇을 할 수 있나요?" — 인증된 당사자가 액세스할 수 있는 리소스/작업을 결정합니다.
AI 시스템의 중요한 미묘함은 모델이 사용자를 대신하여 작업을 수행할 때 해당 사용자의 권한으로 작동하는지 아니면 광범위한 서비스 계정으로 작동하는지입니다. 후자는 위험합니다. 주입으로 속인 모델이 서비스 계정에 대한 전체 액세스 권한을 얻기 때문입니다.
주의: "대리인 혼란" 문제: 권한이 낮은 사용자는 권한이 높은 모델을 아웃소싱하여 액세스할 수 없는 데이터에 간접적으로 액세스합니다. 모델은 항상 사용자 자신의 광범위한 권한이 아닌 사용자 권한의 맥락 내에서 작동해야 합니다.
RBAC 및 ABAC
- RBAC(역할 기반 액세스 제어): 액세스는 사용자의 역할에 따라 다릅니다. "지원 전문가" 역할은 고객 메모를 읽을 수 있지만 삭제할 수는 없습니다. 단순하고 일반적입니다.
- ABAC(속성 기반 액세스 제어): 액세스는 사용자 부서, 데이터의 개인정보 보호 라벨, 시간, 요청이 들어오는 네트워크 등의 속성에 따라 달라집니다. 더 미세하게 조정되었지만 더 복잡했습니다.
대부분의 조직은 RBAC로 시작하여 민감한 데이터를 위해 ABAC로 심화됩니다. AI에 대한 경험적 법칙: 모델은 요청하는 사용자의 역할/속성을 기반으로 호출하는 모든 에이전트와 액세스하는 모든 데이터를 필터링해야 합니다.
단계별: 최소한의 권한 행사
- 재고를 확보하십시오. 모델은 어떤 도구를 호출하고 어떤 데이터에 액세스합니까? 모두 나열해 보세요.
- 각 액세스를 정당화하십시오. “이 어시스턴트가 정말 삭제 권한이 필요한가요?” 그렇지 않으면 제거하십시오.
- 읽기 전용 기본값입니다. 모델은 기본적으로 읽을 수 있어야 합니다. 별도의 좁은 범위 토큰 쓰기/삭제가 필요합니다.
- 사용자 컨텍스트를 이동합니다. 서비스 계정이 아닌 사용자 권한으로 차량을 호출합니다.
- 단기 자격 증명. 수명이 긴 키 대신 수명이 짧은 자동 갱신 토큰을 사용하세요.
비밀 관리
비밀은 API 키, 비밀번호, 토큰 또는 인증서와 같이 비밀로 유지되어야 하는 자격 증명입니다. AI 프로젝트에서 가장 흔한 사고는 모델 제공자의 API 키가 코드에 내장되어 버전 관리(Git)로 유출되는 경우입니다.
올바른 적용:
- 코드에 키를 포함하지 마세요. 환경 변수 또는 비밀 관리 시스템(암호화된 키를 저장하고 액세스를 제어하는 서비스)을 사용하세요.
- 순환: 정기적인 간격(예: 90일마다)으로 키를 갱신합니다. 누출이 의심되는 경우 즉시 취소하십시오.
- 범위 축소: 각 스위치에는 필수 서비스와 필수 인증만 있습니다.
- 감사: 키를 누가, 언제, 어디서 사용했는지 기록합니다.
복사 가능한 템플릿 4개
액세스 검토 제어 프롬프트:
아래 도구 목록의 각 도구에 대해 다음을 평가하십시오. - 이 보조자의 업무를 수행하는 데 이 도구가 필수입니까? (예/아니요) - 읽기 전용인가요, 아니면 쓰기/삭제인가요? - 이 도구는 사용자의 권한으로 호출되는 건가요, 아니면 서비스 계정으로 호출되는 건가요? 불필요하거나 과도하게 승인된 항목을 "제거/수정"으로 표시합니다.<tools>{{ tool_list }}</tools>
비밀 유출 검색 프롬프트:
API 키, 비밀번호, 토큰, 연결 문자열, 개인 키 등의 코드 조각에서 하드코딩된 비밀이 될 수 있는 모든 항목을 찾으세요. 각각에 대해 행과 유형을 지정하십시오. 응답에 값을 복사합니다. 마스크(처음 4자 + ***).<code>{{ 소스 }}</code>
최소 권한 결정 규칙:
새로운 도구/액세스 요청이 도착하면 다음을 질문하십시오.1. 이 액세스 권한 없이 작업을 수행할 수 있습니까? -> 그렇다면: REJECT2. 읽기 전용이면 충분합니까? -> 그렇다면: GRANT 쓰기 권한3. 범위를 단일 소스로 좁힐 수 있습니까? -> 그렇다면: darat기본 대답은 "아니요"입니다. 이유에 따라 액세스 권한을 얻습니다.
순환 달력 알림:
각 비밀에 대해 소유자, 생성 날짜, 만료, 범위를 기록합니다. 90일을 초과했거나 30일 동안 사용되지 않은 키를 "ROTATION/CANCELLATION CANDIDATE"로 보고합니다.
약한 프롬프트 / 강한 프롬프트
접근 방식이 좋지 않음
강력한 접근 방식
모델은 단일 서비스 계정으로 모든 데이터에 액세스합니다.
모델은 요청한 사용자의 권한으로 접근합니다.
API 키는 코드에 포함되어 있으며 변경되지 않습니다.
주요 비밀 관리자의 순환, 90일
보조자에 대한 광범위한 "무엇이든 수행" 권한
읽기 전용 기본값, 좁게 쓰기
액세스는 검토되지 않습니다.
정기적인 액세스 검토 및 철회
미니 케이스 3개
사례 1 — 혼합 프록시 데이터 유출. 사내 조수가 모든 직원 기록에 액세스할 수 있는 서비스 계정으로 작업하고 있었습니다. 인턴 사용자는 "임원 급여표를 요약해 주세요"라고 말하여 평소에는 볼 수 없는 데이터에 액세스했습니다. 모델이 사용자의 권한이 아닌 자신의 광범위한 권한의 맥락에서 질문을 던졌기 때문입니다. 사용자 컨텍스트가 이동되도록 조정되면 인턴은 자신만 볼 수 있는 녹음을 가져올 수 있었습니다.
사례 2 - 키 유출, 2주 만에 190,000TL 청구서. 개발자는 도우미 스크립트에 모델 API 키를 포함하고 이를 공개 저장소에 푸시했습니다. 봇은 40분 만에 열쇠를 찾아 2주 동안 사용했습니다. 청구서는 190,000TL에 도달했습니다. 비밀관리자로 키를 이동하고 순환으로 연결하고 저장소 스캐닝을 추가했더니 사건이 재발하지 않았습니다.
사례 3 — 읽기 전용 기본으로 인터럽트가 방지되었습니다. DevOps 도우미는 프롬프트 주입을 통해 "프로덕션 데이터베이스 재설정" 명령을 받았습니다. 그러나 어시스턴트에게는 읽기 전용 토큰만 제공되었습니다. 쓰기/삭제는 별도의 승인된 흐름에 있었습니다. 인증 오류로 인해 명령이 거부되었으며 이벤트가 경보로 기록되었습니다. 데이터 손실은 없었습니다.
팁: 새 액세스 요청에 대한 기본 대답을 "아니요"로 설정하세요. 접근은 정당화를 통해 얻는 것입니다. 모든 사람에게 넓은 범위를 제공하고 축소하는 것은 거의 완료되지 않으며 위험이 누적됩니다.
일반적인 실수
- 대규모 서비스 계정으로 모델을 실행하고 사용자 컨텍스트를 잃습니다(혼합 프록시).
- 코드에 API 키를 삽입하고 이를 버전 제어에 유출합니다.
- 키를 전혀 회전하지 않습니다("작동 중, 만지지 마세요").
- 기본적으로 보조자에게 쓰기/삭제 권한을 부여합니다.
- 한 번만 액세스 권한을 부여하고 다시 고려하지 않습니다.
- 인증과 승인을 혼동하고 "그가 로그인하면 모든 것에 접근할 수 있다"고 가정합니다.
요약하면
- 인증은 "당신은 누구인가"에 대한 질문이고, 승인은 "당신이 무엇을 할 수 있는가"에 대한 질문입니다. AI에서는 둘 다 사용자의 맥락에서 작동해야 합니다.
- 모델은 자신의 광범위한 권한이 아닌 요청하는 사용자의 권한으로 작동해야 합니다(혼합 대행사의 위험 방지).
- RBAC로 시작하고 민감한 데이터에 대해 ABAC로 심화하세요. 최소 권한을 기본값으로 설정합니다.
- 코드에 비밀을 묻어두지 마세요. 비밀 관리자에 저장하고 범위를 좁혀 정기적으로 순환시킵니다.
- 읽기 전용 기본값과 좁은 쓰기는 주입의 영향을 크게 제한합니다.
응용과제
AI 보조자가 액세스하는 모든 도구와 데이터를 나열합니다. 각각에 대해 세 가지 질문에 대답하십시오. (1) 정말 필요한가요? (2) 읽기 전용이면 충분합니까? (3) 사용자 컨텍스트에서 실행됩니까? 그런 다음 위의 검색 프롬프트를 통해 하드 코딩된 모든 비밀을 검색하고 찾은 각 키에 대한 순환 계획을 작성합니다. 불필요한 인증을 하나 이상 제거하세요.
체크리스트
- [ ] 모델은 요청하는 사용자의 권한 컨텍스트에서 실행됩니다.
- [ ] 도구 및 데이터 액세스가 최소 권한 원칙으로 범위가 좁혀졌습니다.
- [ ] 쓰기/삭제는 읽기 전용, 인증 및 제한과 별개입니다.
- [ ] 코드에는 어떤 비밀도 묻혀있지 않습니다. 비밀관리자에 보관되어 있습니다.
- [ ] 열쇠에는 순환 일정과 취소 절차가 있습니다.
- [ ] 액세스는 정기적으로 검토됩니다.