이 글은 AWS Security Blog에 게시된 Methodology for incident response on generative AI workloads by Anna McAbee, Jennifer Paz, AJ Evans, and Steve de Vera를 한국어로 번역 및 편집하였습니다.
AWS 고객 사고 대응팀(CIRT)은 생성형 AI 기반 애플리케이션과 관련된 보안 사고를 조사하는데 사용할 수 있는 방법론을 개발했습니다. 생성형 AI 워크로드와 관련된 보안 이벤트라고 하더라도, 여전히 AWS 보안 사고 대응 가이드에 설명된 지침과 원칙을 따라서 대응할 수 있습니다. 하지만, 생성형 AI 워크로드의 특성을 고려하여 대응하기 위해서는 이 게시글에서 설명하는 몇 가지 추가 요소를 함께 고려할 필요가 있습니다.
이 글에서는 다음과 같은 내용을 다룹니다.
먼저, 생성형 AI 워크로드의 일반적인 구성 요소에 대해 설명하고, 이벤트가 발생하기 전에 어떻게 대비할 수 있는지를 설명합니다. 그 다음에는, 생성형 AI 워크로드에서 보안 이벤트를 분류하고 대응할 때 고려해야 할 7가지 요소로 구성된 생성형 AI 워크로드의 인시던트 대응 방법론을 소개할 것입니다. 마지막으로, 보안 사고 예시 시나리오를 통해 실제 대응방법을 어떻게 적용할 수 있는지를 살펴보겠습니다.
생성형 AI 워크로드의 일반적인 구성 요소
아래 그림 1에서 볼 수 있듯이 생성형 AI 애플리케이션에는 일반적으로 다음 다섯 가지 구성 요소가 포함됩니다.
[그림1. AI 워크로드의 일반적인 구성 요소]
1. 조직(Organization) : 인프라, 생성형 AI 애플리케이션, 조직의 Private 데이터를 소유하거나 책임지는 전체 조직 또는 회사를 말합니다.
2. 인프라(Infrastructure) : 데이터베이스, 백엔드 서버 및 웹사이트처럼 생성형 AI 애플리케이션 자체를 위해서 특별하게 마련된 것이 아닌, 통상적인 인프라를 말합니다.
3. 생성형 AI 애플리케이션(Generative AI Applications) : 아래의 구성요소들을 포함합니다.
- 파운데이션 모델(Foundation models) – 매우 많은 매개변수(parameters)를 포함하는, 방대한 양의 다양한 데이터로 학습된 AI 모델.
- 사용자 지정 모델(Custom model) – 조직의 특정 데이터 및 사용 사례에 따라 미세 조정되거나 학습된 모델로, 조직의 고유한 요구 사항에 맞게 조정된 모델.
- 가드레일(Guardrails) – AI 애플리케이션이 의도하는 범위 내에서 작동하도록 하는 메커니즘 또는 제약 조건. (예를 들어, 콘텐츠 필터링, 제약 조건 또는 윤리 가이드라인 등)
- 에이전트(Agents) – AI 애플리케이션이 회사 시스템 및 데이터 소스 전반에서 단계별 작업을 수행할 수 있도록 하는 워크플로우.
- 지식 기반(Knowledge bases) – AI 애플리케이션이 액세스하고 사용할 수 있는 도메인별 지식, 규칙 또는 데이터의 리포지토리.
- 학습 데이터(Training data) – 검색 증강 생성(RAG)과 같은 기술을 위한 데이터를 포함하여 생성형 AI 애플리케이션의 모델을 학습, 미세 조정 또는 증강하는 데 사용되는 데이터.
- Note : 학습 데이터는 아래에서 설명하는 ‘조직의 비공개 데이터(Private data)’와는 구별됩니다. 많은 경우, AI 애플리케이션은 해당 Private 데이터에 직접 액세스 할 수 없습니다.
- 플러그인(Plugins) – 특수 기능을 제공하거나 외부 서비스 또는 데이터 소스에 액세스하기 위해 AI 애플리케이션과 통합할 수 있는 추가 소프트웨어 구성 요소 또는 확장 기능.
4. 비공개 데이터(Private data) : AI 리소스 또는 애플리케이션이 정상 작동 중에 상호 작용할 의도가 없는, 고객의 비공개 저장 기밀 데이터를 의미합니다.
5. 사용자(Users) : 생성형 AI 애플리케이션과 상호 작용하거나 액세스할 수 있는 ID를 말합니다. 사용자는 사람 또는 비인간(예: 기계)일 수 있습니다.
생성형 AI 워크로드에 대한 사고 대응 준비
일반적으로 보안 사고에 대비하기 위해서는 사람, 프로세스, 기술의 세 가지 영역에 걸쳐서 준비가 되어야 합니다. 준비 방법에 대한 요약은 보안 인시던트 대응 가이드의 준비 항목을 참조 할 수 있습니다. 생성형 AI 워크로드와 관련된 보안 이벤트에 대한 준비 항목에는 해당하는 세 가지 영역마다 다음의 내용들이 추가로 포함되어야 합니다.
1. 사람(People) : 사고 대응 및 보안 운영 임직원에 대한 생성형 AI 교육 제공 – 임직원이 생성형 AI에 대한 개념과 회사에서 사용 중인 AI/ML 서비스에 대해 잘 알고 있는지 확인해야 합니다. AWS에서 제공하는 스킬 빌더프로그램을 통해서 무료 및 유료 과정을 수료할 수 있습니다.
2. 프로세스(Process) : 새로운 대응 방안(Playbook) 확보 – 생성형 AI 워크로드와 관련된 보안 이벤트를 처리할 수 있도록 새로운 대응 방안을 개발하고 내재화해야 합니다. 아래에는 참조할 수 있는 몇 가지 대응 방안(Playbook)을 포함되어 있습니다.
이러한 플레이북을 시작점으로 삼아 전사 조직 또는 서비스/애플리케이션별로 적합하게 수정하여 활용하도록 합니다.
3. 기술(Technology) : 생성형 AI 애플리케이션 프롬프트 및 호출 로그 생성 – AWS CloudTrail에서 제공되는 것과 같은 기본 로그 외에도 애플리케이션으로 들어오는 프롬프트와 출력을 분석할 수 있도록 Amazon Bedrock 모델 호출 로그를 저장하도록해야 합니다. 보다 자세한 내용은 Amazon Bedrock 모델 호출 로깅을 참조할 수 있습니다. CloudTrail 데이터 이벤트 로깅은 Amazon Bedrock, Amazon Q 및 Amazon SageMaker에서도 사용할 수 있습니다. 더 많은 일반적인 지침은 보안 인시던트 대응을 위한 로깅 전략을 참조 할 수 있습니다.
중요! : 로그에는 민감한 정보가 포함될 수 있습니다. 이 정보를 보호하려면 다른 보안 로그와 마찬가지로 이러한 로그에 대해 최소 권한 액세스를 설정해야 합니다. 데이터 마스킹으로 민감한 로그 데이터를 보호할 수도 있습니다. Amazon CloudWatch에서는 로그 그룹 데이터 보호 정책을 통해 기본적으로 데이터를 마스킹할 수 있습니다.
생성형 AI 워크로드에 대한 사고 대응 방법론
대응 준비를 완료한 후에는 아래에서 설명하는 7가지 영역에서 ‘생성형 AI 워크로드에 대한 사고 대응 방법론’을 적용하여 AI 애플리케이션과 관련된 보안 이벤트를 신속하게 분류하고 처리하는데 도움을 받을 수 있습니다.
아래의 각 요소는 다른 구성 요소와 상호 작용할 수 있는 방법 또는 구성 요소를 수정할 수 있는 방법을 설명합니다. 이러한 요소를 고려하면 탐지, 분석, 봉쇄, 제거 및 복구 단계를 거치는 보안 인시던트의 처리 과정에서 취해야 할 조치를 수립하고 수행하는 데 도움이 됩니다.
1. 접근(Access) – 생성형 AI 애플리케이션의 구성 요소를 호스팅하는 조직에서 설계 또는 의도한 액세스 패턴을 파악하고, 이러한 패턴에서 벗어난 편차나 이상 징후를 찾습니다. 애플리케이션이 외부에서 액세스할 수 있는지 또는 내부에서 액세스할 수 있는지 여부는 분석에 영향을 미칠 수 있으므로 구분하여 고려하여야 합니다.
AWS 환경에 대한 비정상적이고 잠재적인 무단 액세스를 식별하는 데 도움을 주기 위해 Amazon GuardDuty를 사용할 수 있습니다. 다만, 애플리케이션이 외부에서 액세스할 수 있는 경우, 위협 행위자가 AWS 환경에 직접 액세스할 수 없으므로 GuardDuty가 이를 탐지하지 못할 수 있습니다. 애플리케이션에 대한 인증을 설정한 방식에 따라 무단 액세스를 탐지하고 분석하는 방법이 달라집니다.
AWS 계정 또는 관련 인프라에 대한 무단 액세스의 증거가 있는 경우, 관련 권한 및 타임라인 등 무단 액세스의 범위를 파악하여야 합니다. 무단 액세스에 서비스 자격 증명(예: Amazon EC2 인스턴스 자격 증명)이 포함된 경우, 서비스에 취약성이 있는지도 함께 검토할 필요가 있습니다.
2. 인프라 변경 – 서버, 데이터베이스, 서버리스 컴퓨팅 인스턴스, 내부 또는 외부 웹사이트와 같은 지원 인프라를 검토하여 액세스 또는 변경 여부를 확인합니다. 인프라 변경 사항을 조사하려면 CloudTrail 로그를 분석하여 범위 내 리소스의 수정 사항을 확인하거나, 운영 체제 로그, 애플리케이션 로그, 또는 데이터베이스 액세스 로그를 분석할 수 있습니다.
3. AI 변경 – 사용자가 생성형 AI 애플리케이션의 구성 요소에 액세스했는지 여부와 해당 구성 요소를 변경했는지 여부를 조사합니다. 사용자 지정 모델의 생성 또는 삭제, 모델 가용성 수정, AI 모델 로깅 기능의 변조 또는 삭제, 애플리케이션 코드 변조, 가드레일 제거 또는 수정과 같은 무단 활동의 징후를 찾습니다.
4. 데이터 저장소 변경 – 설계 또는 의도된 데이터 액세스 패턴, 사용자가 생성형 AI 애플리케이션의 데이터 저장소에 액세스했는지 여부 및 이러한 데이터 저장소에 대한 변경 여부를 확인합니다. 또한 AI 애플리케이션에 에이전트를 추가하거나 수정했는지 확인해야 합니다.
5. 모델 호출 – 프롬프트 인젝션이나 멀웨어와 같은 위협에 대해 문자열과 파일 입력을 포함한 생성형 AI 모델의 호출 내역을 분석합니다. 호출 관련 위협을 이해하기 위한 출발점으로 OWASP Top 10 for LLM을 사용할 수 있으며, 호출 로그에서 프롬프트 인젝션 시도를 보여주는 의심스러운 패턴, 키워드 또는 구조에 대한 프롬프트를 분석할 수 있습니다. 또한 로그로 부터 모델의 출력과 응답을 캡처하여 행동 분석을 통해 프롬프트 인젝션을 나타내는 비정상적이거나 안전하지 않은 모델 동작을 식별하는데 활용 할 수 있습니다. 로그의 타임스탬프를 시간 분석에 사용하여 시간 경과에 따른 조직적인 프롬프트 인젝션 시도를 탐지하고 모델 호출을 시작한 사용자 또는 시스템에 대한 정보를 수집하여 잠재적인 익스플로잇의 출처를 파악하도록 합니다.
6. 비공개 데이터 – 생성형 AI 애플리케이션이 비공개 또는 기밀 데이터에 액세스할 수 있도록 설계되었는지 확인합니다. 그런 다음 해당 데이터에 대한 무단 액세스 또는 변조 여부를 확인합니다.
7. Agent – Agent는 애플리케이션이 조직의 리소스를 변경하거나 사용자를 대신하여 조치를 취할 수 있는 기능을 말합니다. 생성형 AI 애플리케이션을 통해서 이메일을 보내는데 사용되는 콘텐츠를 생성하여 다른 리소스나 기능을 호출하도록 구성하는 경우를 그 예로써 생각해 볼 수 있습니다. 이렇듯, AI 애플리케이션에 다른 함수나 애플리케이션을 호출할 수 있는 기능이 있는지 확인해야 합니다. 만약 그렇다면, 의도하지 않은 변경이 이루어졌는지 또는 생성 AI 애플리케이션이 승인되지 않은 함수나 애플리케이션을 호출하였는지를 추가로 조사해야 합니다.
다음 표에는 방법론의 7가지 요소를 해결하는 데 도움이 되는 몇 가지 질문이 나와 있습니다.
| 주제 | 확인하여야 할 내용, 질문 예시 |
| 접근 | 의심시러운 행위자가 현재도 여전히 컴퓨팅 환경에 액세스할 수 있나요? 무단 액세스를 지속적으로 수행하고 있다는 증거를 발견할 수 있나요? |
| 인프라 변경 | 생성형 AI 애플리케이션과 관련된 각종 인프라 리소스에 액세스하거나 변경을 적용한 것이 확인되나요? |
| AI 변경 | AI 모델, 코드 또는 리소스에 액세스하거나 변경한 적이 있나요? |
| 데이터 저장소 변경 | 데이터 저장소, knowledge base, agent, 플러그인 또는 학습 데이터에 액세스하거나 변조한 적이 있나요? |
| 모델 호출 | 어떤 데이터, 문자열 또는 파일이 모델에 입력으로 전송되었나요? 어떤 프롬프트가 전송되었나요? 어떤 응답이 생성되어 전달 되었나요? |
| 비공개 데이터 | 생성형 AI 리소스가 액세스할 수 있는 비공개 또는 기밀 데이터에는 어떤 것이 있나요? 회사의 Private 데이터가 변경되거나 변조된 적이 있나요? |
| Agent | 생성형 AI 애플리케이션에서 API 를 실행하거나, 함수를 호출하는 등 서비스를 trigger 할 수 있나요? 생성형 AI 애플리케이션에서 다른 리소스를 변경할 수 있는 권한이 있나요? 무단 변경이 이루어졌나요? |
보안 사고 예시
생성형 AI 워크로드에 대한 보안 사건 대응 방법론을 보다 잘 이해하기 위해, AWS에 호스팅된 생성형 AI 애플리케이션이 공용 코드 저장소에 노출된 자격 증명을 사용하여 무단 사용자에게 침해되는 예시 시나리오를 살펴보겠습니다. 여기서 우리의 목표는 어떤 자원이 접근되었고, 수정되었으며, 생성되었거나 삭제되었는지를 파악하는 것입니다.
AWS에서 생성형 AI 보안 이벤트를 조사하기 위해 검토해야 할 주요 로그 소스는 다음과 같습니다:
- CloudTrail
- CloudWatch
- VPC Flow Logs
- Amazon S3(Amazon Simple Storage Service) data events
- Amazon Bedrock 모델 호출 로그(애플리케이션에서 이 서비스를 사용하는 경우)
액세스
생성형 AI 애플리케이션에 대한 액세스 분석은 표준 3계층 웹 애플리케이션에 대한 분석과 유사합니다. 먼저 조직에서 AWS 계정에 대한 액세스 권한이 있는지 확인합니다. 만약 조사과정에서 AWS 사용자 또는 루트 사용자의 패스워드가 유출되었거나, 변경된 것이 확인되면, 즉시 패스워드를 재설정 하고, 사용자에 대해 MFA(다단계 인증) 장치를 활성화하여 위협 행위자가 더 이상 임의로 액세스하는 것을 차단해야 합니다.
다음으로 계정에 대한 무단 액세스가 지속되는지 여부를 확인합니다. AWS Identity and Access Management(IAM) 및 AWS Security Token Service(Amazon STS)에 의해 기록된 내용을 확인할 때는, GitHub에 있는 손상된 IAM 자격증명 대응 방법에서 분석 섹션을 참조합니다. 또한 Trusted Advisor를 통해서 액세스 키가 공개 리포지토리에 저장되어 있는지 확인하고, Amazon Inspector를 이용하여 애플리케이션 코드에 하드코딩된 키가 있는지도 확인해야 합니다. (장기 자격증명인 액세스 키를 사용하지 않도록 합니다. 대안으로 단기 자격증명인 역할을 사용하도록 변경하는 것이 강력하게 권장됩니다.)
인프라 변경 사항
애플리케이션의 인프라 변경 사항을 분석하려면 제어 플레인과 데이터 플레인을 모두 고려해야 합니다. 이 예제에서는 생성 AI 애플리케이션의 다운스트림 구성 요소에 대한 인증에 Amazon API Gateway가 사용되었고 다른 여러 리소스를 통해서 애플리케이션과 상호 작용하고 있다고 가정해 보겠습니다. 이러한 리소스에 대한 제어 영역 변경 사항을 CloudTrail에서 검토할 수 있지만, 리소스가 포함된 운영 체제에서 변경 사항을 검토하려면 추가 로깅을 사용 설정해야 합니다. 다음은 인프라 변경 사항에 대해 CloudTrail에서 찾을 수 있는 컨트롤 플레인 이벤트의 몇 가지 일반적인 이름들 입니다:
- ec2:RunInstances
- ec2:StartInstances
- ec2:TerminateInstances
- ecs:CreateCluster
- cloudformation:CreateStack
- rds:DeleteDBInstance
- rds:ModifyDBClusterSnapshotAttribute
AI 서비스 변경
AI 서비스에 대한 무단 변경에는 시스템 프롬프트, 애플리케이션 코드, 가드레일 및 모델 가용성 등이 포함될 수 있지만 이에 국한되지만은 않습니다. AWS가 호스팅하는 생성형 AI 리소스에 대한 내부 사용자 액세스는 CloudTrail에 기록되며 다음 이벤트 소스 중 하나와 함께 표시됩니다:
다음은 본 예시 시나리오에서 AI 리소스 로그 변조를 확인할 때 사용되는 CloudTrail의 이벤트 이름들 입니다:
- bedrock:PutModelInvocationLoggingConfiguration
- bedrock:DeleteModelInvocationLoggingConfiguration
다음은 CloudTrail에서 AI/ML 모델 서비스 구성에 대한 액세스를 확인할 수 있는 몇 가지 일반적인 이벤트 이름입니다:
- bedrock:GetFoundationModelAvailability
- bedrock:ListProvisionedModelThroughputs
- bedrock:ListCustomModels
- bedrock:ListFoundationModels
- bedrock:ListProvisionedModelThroughput
- bedrock:GetGuardrail
- bedrock:DeleteGuardrail
본 예시 시나리오에서는 권한이 없는 사용자가 AWS 계정에 액세스 권한을 얻었습니다. 이제 침해된 사용자에게 모든 리소스에 대한 전체 액세스 권한을 부여하는 정책이 첨부되어 있다고 가정해 보겠습니다. 이 액세스 권한으로 권한이 없는 사용자는 Amazon Bedrock의 각 구성 요소를 열거하고 애플리케이션의 일부인 지식 기반 및 가드레일을 식별할 수 있습니다.
그런 다음, 권한이 없는 사용자는 Amazon Bedrock 내의 다른 파운데이션 모델(FM)에 대한 모델 액세스를 요청하고 기존 가드레일을 제거합니다. 다른 파운데이션 모델에 대한 액세스는 권한이 없는 사용자가 생성형 AI 애플리케이션을 자신의 목적으로 사용하려는 의도를 나타낼 수 있으며, 가드레일을 제거하면 모델에 의한 필터링 또는 출력 확인이 최소화됩니다. AWS는 IAM 정책과 리소스 기반 정책을 사용하여 세분화된 액세스 제어를 구현하여 애플리케이션에 필요한 Amazon Bedrock 리소스, AWS Lambda 기능 및 기타 구성 요소에만 액세스를 제한할 것을 권장합니다. 또한, Amazon Bedrock과 같은 중요한 구성 요소와 생성형 AI 애플리케이션의 기타 구성 요소에 대한 액세스 권한이 있는 IAM 사용자, 역할 및 서비스 계정에 대해서 반드시 MFA를 사용하도록 해야 합니다.
데이터 저장소 변경 사항
일반적으로는 데이터 저장소 및 지식 기반에 접근하기 위해서 모델 호출(Model invocation)을 사용합니다. Amazon Bedrock의 경우에는 bedrock:InvokeModel 를 이용하여 모델을 호출하게 됩니다.
그러나 권한이 없는 사용자가 환경에 액세스할 수 있는 경우라면, 생성형 AI 애플리케이션이 통합하는 데이터 소스 및 지식 기반을 임의로 생성, 변경 또는 삭제할 수 있습니다. 이로 인해 데이터 또는 모델이 유출되거나 파괴되고 데이터 오염이 발생할 수 있으며, 모델에 대한 서비스 거부 상태가 발생할 수 있습니다. 다음은 예시 시나리오에서 AI/ML 데이터 소스의 변경 사항을 나타내는 CloudTrail의 몇 가지 일반적인 이벤트 이름들 입니다:
- bedrock:CreateDataSource
- bedrock:GetKnowledgeBase
- bedrock:DeleteKnowledgeBase
- bedrock:CreateAgent
- bedrock:DeleteAgent
- bedrock:InvokeAgent
- bedrock:Retrieve
- bedrock:RetrieveAndGenerate
전체 작업 목록은 Amazon Bedrock API 를 참조할 수 있습니다.
이 시나리오에서는 권한이 없는 사용자가 생성형 AI 애플리케이션에 대한 전체 액세스 권한을 가지고 있으며, 연결된 데이터 저장소들을 확인할 수 있었습니다. 그런 다음 권한이 없는 사용자는 생성형 AI 애플리케이션의 지식 기반인 S3 버킷을 식별하고 부정확한 데이터를 업로드하여 LLM을 손상시켰습니다. 이 취약점은 OWASP TOP 10 for LLM Applications에서 LLM03: Training Data Poisoning을 참조하여 더 자세히 살펴볼 수 있습니다.
호출
Amazon Bedrock은 특정 API를 사용하여 모델 호출을 수행합니다. Amazon Bedrock의 모델이 호출되면 CloudTrail이 이를 기록합니다. 그러나 생성형 AI 모델에 전송된 프롬프트와 그로부터 수신된 출력 응답을 확인하려면 모델 호출 로깅을 별도로 구성해야 합니다.
이러한 모델 호출 로그는, 위협 행위자가 모델을 통해 데이터 저장소의 정보를 유출하도록 유도했는지 또는 모델이 학습 또는 미세 조정된 데이터를 공개했는지와 같은 중요한 정보를 파악할 수 있기 때문에 매우 중요합니다. 예를 들어, 위협 행위자가 민감한 데이터를 추출하거나 보안 제어를 우회하거나 정책을 위반하는 콘텐츠를 생성하도록 프롬프트를 조작하여 모델 호출을 시도했는지 여부를 해당 로그를 통해 확인할 수 있습니다. 또한 로그를 사용하여 모델이 악의적인 보안 공격에 사용될 수 있는 각종 잘못된 정보, 스팸 또는 기타 악의적인 출력을 생성하는 데 사용되었는지 여부를 알 수 있습니다.
참고: Amazon Bedrock과 같은 서비스의 경우 기본적으로 모델 호출 로깅이 비활성화되어 있습니다. 가능한 경우 생성형 AI 서비스에 대해 데이터 이벤트 및 모델 호출 로깅을 활성화하는 것이 좋습니다. 하지만 개인정보 보호 및 법적 이유로 인해 조직에서 호출 로그를 캡처하여 저장하지 않으려 할 수도 있습니다. 한 가지 일반적인 우려는 사용자가 민감한 데이터를 입력할 경우 보호해야 할 자산의 범위가 넓어진다는 점입니다. 이는 비즈니스 차원에서 고려해야 할 사항입니다.
본 예시 시나리오에서는 모델 호출 로그가 활성화되지 않아서, 보안 관리자가 무단 호출에 대한 모델 입력 또는 출력 데이터를 볼 수 없다고 가정해 보겠습니다. 이로 인해 보안 관리자는 LLM의 프롬프트와 후속 응답을 확인할 수 없습니다. 로깅이 활성화되어 있지 않았으므로, 모델 호출과 관련된 전체 요청 데이터, 응답 데이터 및 메타데이터도 볼 수 없습니다.
Amazon Bedrock에서 모델 호출 로깅과 관련된 이벤트 이름에는 다음이 포함됩니다.
- bedrock:InvokeModel
- bedrock:InvokeModelWithResponseStream
- bedrock:Converse
- bedrock:ConverseStream
다음은 Amazon Bedrock 모델 호출 로깅에 대한 샘플 로그 항목입니다.
[그림 2: 프롬프트 및 응답을 포함한 모델 호출 로그 샘플]
Private Data
아키텍처 관점에서 볼 때, 생성형 AI 애플리케이션은 조직의 비공개 데이터에 직접 액세스할 수 없어야 합니다. AI 애플리케이션이 조직의 비공개 데이터를 사용해야만 하는경우 (예: 생성형 AI 애플리케이션이 환자의 의료 기록에 대한 질문에 답변하는 작업을 수행하는 경우) 가 아니라면, AI 애플리케이션을 학습시키거나 RAG 사용에 사용되는 데이터를 데이터 저장소 데이터로 분류하고 조직의 비공개 데이터와 분리해서 관리해야 합니다. 조직의 비공개 데이터를 생성형 AI 애플리케이션과 분리하는데 도움이 되는 한 가지 방법은 별도의 계정을 사용하고 최소 권한 원칙을 준수하기 위해 필요에 따라 액세스 권한을 인증 및 승인하는 것입니다.
Agent
생성형 AI에서 사용되는 Agent에 대해서 과도한 권한이나 자율성이 주어지거나 또는 의사 결정 권한이 너무 클 경우, 의도하지 않은 보안 사고가 발생할 수 있습니다. 이는 LLM이 불충분한 감독, 제약 또는 의도하지 않은 약한 제약을 가진채 배포되어, 우리가 일반적으로 당연히 생각하는 보편적인 윤리성을 가지지 못할 경우에 발생합니다.
본 예시 시나리오에서는 생성형 AI 애플리케이션이 동작에 필요하지 않은 서비스에 대한 과도한 권한을 가지고 있습니다. 애플리케이션 코드가 Amazon SES(Amazon Simple Email Service)에 대한 전체 액세스 권한이 있는 역할로 실행되고 있다고 가정해 봅니다. 이렇게 하면 권한이 없는 사용자가 사용자 대신 스팸 이메일을 보낼 수 있습니다. 이럴 경우에는 생성형 AI 애플리케이션 플러그인 및 에이전트의 권한과 기능을 제한하여 문제점을 미연에 방지할 수 있습니다. 보다 자세한 내용은 OWASP Top 10 for LLM Applications의 LLM08 Excessive Agency를 참조할 수 있습니다.
로그를 분석하는 동안 확인할 수 있는 sourceIPAddress 및 userAgent 필드는 모두 생성형 AI 애플리케이션(예: sagemaker.amazonaws.com, bedrock.amazonaws.com 또는 q.amazonaws.com)과 연관되어 있습니다. 그 외에 일반적으로 다른 서비스에서 호출하거나 호출할 수 있는 서비스의 예로는 Lambda, Amazon SNS, Amazon SES 등이 있습니다.
결론
생성형 AI 워크로드와 관련된 보안 이벤트에 대응할 때도, 여전히 AWS 보안 사고 대응 가이드에 설명된 지침과 원칙에 따라 수행하는 것이 권장됩니다. 거기에, 생성형 AI 워크로드의 특성에 맞는 몇가지 추가요소를 고려하면 좀 더 효과적인 대응이 될 수 있습니다.
본 게시글에서 소개한 방법론을 사용하면 이러한 새로운 요소를 고려하여 문제를 해결하는 데 도움이 될 것입니다. 생성형 AI 애플리케이션이 의도하지 않게 무단 사용되었거나, 혹은 무단 사용의 메커니즘의 일부로 동작되는 것이 확인되었을 경우에, 이 글에서 소개한 방법론을 참조하면 보다 효과적으로 조사를 수행할 수 있을 것입니다. 이 방법론은 생성형 AI 워크로드와 관련된 보안 사고에 대비하고 대응할 수 있는 구조화된 접근 방식을 제공하여 이러한 중요한 애플리케이션의 보안과 무결성을 유지하는데 도움을 주도록 작성되었습니다.
생성형 AI 애플리케이션을 설계하기 위한 모범 사례에 대한 자세한 내용은 생성형 AI를 위한 AWS 보안 참조 아키텍처를 참조할 수 있습니다. 또한 일반적인 생성형 AI 애플리케이션에 대한 전술적 완화 조치에 대한 자세한 내용은 보안 설계 및 패턴 방지 완화 청사진을 참조할 수 있습니다.