모델 컨텍스트 프로토콜을 사용한 에이전트 상호작용 보안을 위한 권장사항

MySQL | PostgreSQL | SQL Server

모델 컨텍스트 프로토콜 (MCP)은 생성형 AI 에이전트가 SQL Server용 Cloud SQL에 연결하는 방법을 표준화합니다. 자율 에이전트의 고유한 위험으로 인해 프롬프트 삽입과 같은 취약점을 완화하려면 플랫폼 제어와 보안 애플리케이션 설계를 결합하는 공유 책임 모델이 필요합니다.
모델 컨텍스트 Google Cloud 프로토콜 (MCP) 도구를 사용하는 AI 애플리케이션을 설계하고 배포하려면 이 가이드의 권장사항을 따르세요.

시작하기 전에

MCP 도구를 사용하면 애플리케이션의 보안 상황이 에이전트의 상호작용 모델에 따라 달라집니다. 에이전트 사용이 에이전트를 MCP 서버와 통합하는 데 따른 보안 위험에 미치는 영향을 알아보려면 AI 보안 및 안전을 참고하세요.

보안 책임

고객은 에이전트 플랫폼의 보안 구성 및 운영을 책임집니다.

최소 권한의 원칙 준수

최소 범위의 서비스 계정으로 에이전트를 실행합니다. 이는 첫 번째이자 가장 중요한 방어 계층입니다.

전용 ID: MCP 도구를 사용하여 각 고유 에이전트 또는 애플리케이션에 별도의 전용 서비스 계정을 만듭니다. 기존 SA, 특히 광범위한 권한이 있는 SA를 재사용하지 마세요.
최소 범위: 서비스 계정에 필요한 Identity and Access Management(IAM) 역할만 부여합니다(예: alloydb.admin이 아닌 alloydb.viewer). 에이전트에 특정 데이터 세트에 대한 읽기 액세스 권한만 필요한 경우 커스텀 IAM 역할을 사용하여 기능에 필요한 최소한의 액세스 권한으로 액세스를 제한합니다.
직무 분리: 에이전트에 데이터에 대한 읽기 액세스 권한과 로그 또는 임시 저장소에 대한 쓰기 액세스 권한이 모두 필요한 경우 두 개의 별도 서비스 계정(위험도가 높은 데이터 액세스용 계정(최소 범위)과 위험도가 낮은 운영 작업용 계정)을 사용합니다.

데이터베이스 기본 세분화된 제어 사용

가장 강력한 방어를 위해 IAM 역할을 데이터베이스 자체에서 제공하는 세분화된 액세스 제어와 결합합니다. 이렇게 하면 공격자가 에이전트의 IAM 토큰을 손상시키더라도 손상 범위가 데이터베이스 엔진의 내부 권한에 의해 제한됩니다(예: DROP TABLE 명령어 방지).

제품	세분화된 제어 메커니즘	중점
Cloud SQL 및 AlloyDB	PostgreSQL 및 MySQL의 CREATE ROLE과 같은 데이터베이스 수준 역할	특정 데이터베이스 인스턴스 및 스키마에서 권한을 관리합니다.
BigQuery	열 수준 액세스 제어 (정책 태그 사용)	승인된 테이블에서도 에이전트 액세스를 민감한 열(예: PII)로 제한합니다.
Spanner	세분화된 액세스 제어 (`GRANT/REVOKE`가 있는 데이터베이스 역할)	테이블 및 열에 대한 정확한 읽기/쓰기/업데이트 권한을 적용합니다.
Firestore	IAM 역할 및 IAM 조건	IAM 역할 및 IAM 조건을 사용하여 데이터베이스별 액세스 권한을 구성합니다.
Bigtable	IAM 역할	Bigtable은 프로젝트, 인스턴스, 테이블 수준에서 IAM 역할을 통해 세분화된 제어를 제공합니다.

보안 에이전트 설계

에이전트 전용 모델에는 시스템 프롬프트를 재정의하려는 프롬프트 삽입 공격에 대한 강력한 애플리케이션 수준 방어가 필요합니다. 자세한 내용은 AI 안전 및 보안을 참고하세요.

데이터 및 사용자 입력을 신뢰할 수 없는 것으로 처리

최종 사용자의 입력 또는 에이전트가 웹 검색 결과나 서드 파티 문서와 같은 외부 소스에서 가져온 데이터를 신뢰할 수 없는 것으로 처리합니다.

작업 선택 패턴 구현

시스템이 상위 수준 작업 사양을 기계적 실행과 분리하는 개방형 계획 및 실행 아키텍처는 피하세요. 대신 모델의 자유도를 제한하는 설계 패턴을 사용합니다.

작업 선택기 패턴: 모델의 유일한 작업은 사용자 요청을 작고 미리 정의된 안전한 함수 집합 중 하나로 변환하는 것입니다. 작업 로직은 하드 코딩되어 있으며 LLM에서 수정할 수 없습니다. 이렇게 하면 에이전트가 제어 흐름을 타겟팅하는 삽입 공격에 영향을 받지 않게 됩니다.
이중 LLM 패턴: 기본 작업 (작업 LLM)을 실행하는 기본 LLM과 악의적인 의도를 위해 사용자 프롬프트를 사전 검사하고 무단 작업 또는 데이터 유출을 위해 작업 LLM의 출력을 사후 검사하는 보조 보안 LLM (가드레일 LLM)을 사용합니다.

무단 도구 체이닝 방지

에이전트는 작업에 필요한 도구만 호출해야 합니다. 오케스트레이션 코드가 다음을 방지하는지 확인합니다.

동적 도구: 에이전트가 새 도구를 동적으로 등록하거나 기존 도구의 권한을 변경할 수 없어야 합니다.
허용 목록 적용: 에이전트가 초기 시스템 프롬프트 및 백엔드 코드에서 액세스할 수 있는 함수 또는 데이터베이스 테이블의 허용 목록을 선언합니다. Gemini CLI 예시는 도구 액세스 제한을 참고하세요.

멀티 테넌트 데이터베이스에서 데이터 액세스 제한

execute_sql과 같은 일반 도구를 사용하면 호출자가 IAM 및 데이터베이스 권한이 액세스를 허용하는 모든 데이터를 읽을 수 있는 데이터베이스 쿼리를 실행할 수 있습니다. 신뢰할 수 있는 사람이 루프에 없는 멀티 테넌트 애플리케이션의 데이터에 액세스하는 에이전트를 만들 때는 데이터 액세스를 추가로 제한해야 할 수 있습니다.

에이전트가 액세스할 수 있는 데이터의 하위 집합만 읽을 수 있도록 하려면 데이터베이스용 MCP 도구 상자와 같은 프레임워크를 사용하여 커스텀 도구를 만드는 것이 좋습니다. 자세한 내용은 사전 빌드된 도구와 커스텀 도구를 참고하세요.

예를 들어 데이터베이스가 모든 최종 사용자의 주문을 Orders 테이블에 저장한다고 가정해 보겠습니다. 사용자와 상호작용하고 주문을 조회할 수 있는 채팅 에이전트를 개발하고 있습니다. 채팅 에이전트에는 전체 Orders 테이블을 읽을 수 있는 권한이 있지만 한 최종 사용자는 다른 사용자의 주문에 대한 정보를 요청할 수 없어야 합니다.

안전하지 않은 시나리오에서는 에이전트에 execute_sql 도구만 장착하여 데이터 유출 위험을 만듭니다. 악의적인 사용자는 에이전트를 속여 다른 사용자의 주문을 읽고 반환하도록 할 수 있습니다. 에이전트가 액세스 규칙을 적용하도록 지시하는 것만으로는 데이터를 보호하기에 충분하지 않습니다.

안전한 시나리오에서는 에이전트에 더 구체적인 커스텀 도구(예: 쿼리 필터의 사용자 ID가 에이전트의 제어 외부에 설정된 lookup_active_order)를 제공합니다.

보안 및 안전 구성

SQL Server용 Cloud SQL 은 Model Armor를 제공하여 플랫폼 수준에서 안전 경계를 적용합니다. 이러한 설정을 사용 설정하고 구성해야 합니다.

Model Armor 사용 설정

gcloud CLI를 사용하여 모델 배포에서 Model Armor를 사용 설정합니다. 이렇게 하면 삽입 및 탈옥과 같은 알려진 공격 벡터에 대한 기본 제공 보호가 활성화됩니다.

다음 예시에서는 Vertex AI 엔드포인트에서 Model Armor를 사용 설정합니다.

# Example: Enable Model Armor on a Vertex AI endpoint
gcloud ai endpoints update ENDPOINT_ID \
    --region=REGION \
    --enable-model-armor

자세한 내용과 예시는 Configure Model Armor 보호 구성을 참고하세요 Google Cloud.

민감한 데이터 작업에 최소 안전 기준점 적용

Model Armor를 사용하면 민감한 데이터 작업(예: 개인 식별 정보(PII) 감지 및 익명화)에 최소 안전 기준점을 적용할 수 있습니다. 모델이 손상되더라도 민감한 정보 보호 DeidentifyTemplate 를 사용하여 민감한 정보가 사용자에게 반환되기 전에 수정하거나 마스크 처리합니다.

다음은 구성의 개념적 예시입니다.

  # Example: Apply a DeidentifyTemplate to filter PII
gcloud ai endpoints update ENDPOINT_ID \
    --region=REGION \
    --model-armor-config-file=model_armor_config.json

다음 예시에서 model_armor_config.json은 DLP 템플릿을 참조할 수 있습니다.

{
  "safety_thresholds": {
    "injection": "HIGH",
    "harmful_content": "MEDIUM"
  },
  "data_protection_config": {
    "dlp_deidentify_template": "projects/PROJECT_NUMBER/locations/LOCATION/deidentifyTemplates/DLP_TEMPLATE_ID"
  }
}

감사 및 관측 가능성

에이전트 작업에 대한 가시성은 사고 후 분석 및 손상된 에이전트 감지에 매우 중요합니다.

데이터 복구 전략 구현

IAM 및 데이터베이스 기본 역할과 같은 계층화된 제어는 파괴적인 작업을 방지하도록 설계되었지만 이러한 방어가 실패할 경우를 대비한 복구 계획이 있어야 합니다. 쓰기 권한이 있는 손상되거나 순진한 에이전트('에이전트 전용' 위험)는 DROP TABLE과 같은 파괴적인 명령어를 실행하거나 데이터를 손상시키도록 속일 수 있습니다.

이 시나리오에 대한 기본 방어는 강력한 복구 전략입니다.

거의 모든 Data Cloud 제품은 기존 백업, PITR (point-in-time recovery) 또는 데이터 스냅샷을 통해 데이터 복구 기능을 제공합니다. 이러한 기능을 사용 설정하고 구성하는 것은 사용자의 책임입니다.

제품	백업 및 복구 메커니즘
Cloud SQL	주문형 백업과 자동 백업을 모두 지원하므로 인스턴스를 이전 상태로 복원할 수 있습니다. 또한 PITR (point-in-time recovery)도 지원합니다.
AlloyDB	기본적으로 지속적인 백업 및 복구를 제공합니다. 이렇게 하면 마이크로초 단위로 PITR을 사용 설정하여 보관 기간 내의 어느 시점으로든 클러스터를 복원할 수 있습니다.
BigQuery	데이터 복구는 지난 7일 이내의 어느 시점에서든 데이터에 액세스하고 복원할 수 있는 '시간 이동'을 사용하여 이루어집니다. 장기 보관을 위해 테이블 스냅샷을 만들 수 있습니다.
Spanner	주문형 백업과 PITR을 모두 지원합니다.
Firestore	데이터베이스를 이전 상태로 복원할 수 있는 자동 백업을 지원합니다. 또한 실수로 인한 삭제 또는 쓰기를 방지하기 위해 PITR을 제공합니다. 이러한 기능은 기본적으로 사용 중지되어 있습니다.
Bigtable	주문형 백업과 자동 백업을 지원합니다. 이러한 백업은 완전히 관리되며 새 테이블로 복원할 수 있습니다.

Cloud 감사 로그 사용 설정

데이터 액세스 감사 로그가 MCP뿐만 아니라 BigQuery, Cloud SQL, AlloyDB, Firestore, Spanner와 같은 모든 관련 Google Cloud 서비스 에 사용 설정되어 있는지 확인합니다. 기본적으로 관리자 활동 감사 로그만 사용 설정됩니다. 데이터 액세스 감사 로그는 에이전트가 실행하는 모든 읽기 및 쓰기 작업을 기록합니다. 자세한 내용은 Data access audit logs for MCP를 참고하세요.

민감한 작업 감사

Cloud Logging에서 비정상적이거나 위험도가 높은 작업을 감지하도록 알림을 구성합니다. 로그 탐색기 쿼리는 예를 들어 데이터 유출 또는 파괴적인 공격의 일반적인 타겟인 Firestore에서 데이터 쓰기 작업을 실행하는 서비스 계정을 식별합니다.

resource.type="firestore_database"
# Filter for data write operations
AND protoPayload.methodName="google.firestore.v1.Firestore.Commit"
# Ensure the caller is an agent service account (modify regex as needed)
AND protoPayload.authenticationInfo.principalEmail=~".*@.*.gserviceaccount.com"
# Exclude expected system calls to reduce noise
AND NOT protoPayload.authenticationInfo.principalEmail=~"system-managed-service-account"

에이전트별 로깅 사용

Cloud 감사 로그 외에도 애플리케이션 코드가 모든 에이전트 결정에 대해 다음 데이터를 로깅하는지 확인합니다.

도구 실행: 호출된 MCP 도구입니다.
원시 명령어: LLM에서 생성된 정확한 명령어(예: SQL 쿼리 또는 문서 경로)입니다.
최종 작업: 작업이 실행되는지 (에이전트 전용 모델) 또는 승인되는지 (Human-in-the-Middle) 여부입니다. 자세한 내용은 에이전트 사용 이해를 참고하세요.
사용자 및 세션 ID: 요청을 시작한 최종 사용자의 식별자입니다.