How Benchling secured multi-tenant AI agents with Amazon Bedrock AgentCore

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 요약

Benchling은 Amazon Bedrock AgentCore Code Interpreter의 VPC 모드에 계정 격리, DNS Firewall, VPC 엔드포인트 정책과 작업별 자격 증명을 결합해 다중 테넌트 AI 코드 실행을 보호하며, 하루 600회 초과 세션과 주간 250개 초과 테넌트 규모에서 보안 사고 0건을 보고했다.

📌 핵심 요약

• Benchling은 수천 개 생명과학 테넌트를 위한 AI 생성 과학 코드를 실행하면서 테넌트 간 데이터 격리, 무단 네트워크 연결 및 데이터 유출 차단, 테넌트별 IAM 역할 증가 방지를 요구했다.
• AgentCore Code Interpreter의 VPC 모드를 별도의 Untrusted Code Account에 배치하고 인터넷 게이트웨이와 NAT 게이트웨이를 제거했으며, AWS STS로 작업별 자격 증명을 주입해 필요한 데이터에만 접근하도록 구성했다.
• Route 53 Resolver DNS Firewall은 P10에서 알려진 악성 도메인을 차단하고, P100에서 명시된 S3 엔드포인트 등의 도메인만 허용하며, P200에서 나머지 질의에 NODATA를 반환한다.
• VPC 엔드포인트 정책은 접근 가능한 S3 버킷을 제한해 IAM과 독립적인 방어를 제공하고, 지속적 통합 테스트는 DNS 터널링, 무단 엔드포인트 연결, 허용 범위 밖 S3 접근이 성공하면 릴리스를 차단한다.
• 글은 이 아키텍처가 하루 600회 초과 코드 실행 세션과 주간 250개 초과 테넌트를 처리하면서 보안 사고 0건을 기록했다고 설명하지만, 해당 실적의 측정 기간은 제시하지 않는다.

🧩 주요 포인트

1. Sandbox 모드의 기본 제한만으로는 Benchling의 위협 모델을 충족하지 못함 → VPC 모드에서 DNS와 도달 가능한 엔드포인트를 직접 통제하고 검증하는 구조를 선택했다.
2. 계정 격리·AWS STS 작업별 자격 증명·VPC 엔드포인트 정책의 결합 → 운영 계정의 직접 노출과 테넌트별 IAM 역할 증가를 줄이면서 데이터 접근을 여러 계층에서 제한한다.
3. DNS Firewall의 기본 차단과 지속적 통합 테스트의 결합 → 데이터 유출 방어를 초기 설정에 그치지 않고 인프라 변경 때마다 검증하며, 보안 사고 0건이라는 운영 실적은 측정 기간이 불명확하다는 한계와 함께 해석해야 한다.

🧠 상세 정리

1. 다중 테넌트 과학 코드 실행의 보안 요구

Benchling의 AI 애플리케이션은 수천 개 생명과학 테넌트의 연구자를 대신해 과학 코드를 생성하고 실행하며, Code Interpreter는 간단한 계산과 코드 생성용 샌드박스로도 사용된다. 각 세션은 해당 테넌트의 데이터에만 접근해야 하고, 다른 테넌트의 데이터를 볼 수 없어야 하며, 무단 네트워크 연결이나 어떤 경로를 통한 데이터 유출도 허용해서는 안 된다는 요구가 있었다. 일반적인 네트워크 통제는 HTTP와 외부 연결 포트를 제한하더라도 DNS 해석을 허용할 수 있고, 시스템 기본값이 DNS를 제한해도 고객이 그 제한을 충분히 관찰하거나 통제하지 못할 수 있다는 점이 문제였다. 따라서 Benchling은 실행 세션의 완전한 격리와 함께 DNS까지 포함한 네트워크 경계의 직접 통제를 요구했으며, 수천 개 테넌트마다 IAM 역할을 만드는 방식도 지속 가능하지 않다고 판단했다.

2. Sandbox 모드 검토에서 VPC 모드 선택까지

보안 검토 과정에서 Benchling은 Code Interpreter의 각 네트워크 모드가 제공하는 격리 특성을 자체 위협 모델과 비교했다. Sandbox 모드는 외부 접근을 Amazon S3 작업으로 제한하지만, Benchling은 어떤 도메인이 해석되고 어떤 엔드포인트에 도달할 수 있는지를 고객이 직접 정의해야 한다고 보았다. 민감한 과학 데이터를 다루는 수천 개의 규제 대상 생명과학 테넌트를 지원하기 때문에 애플리케이션이 관리하는 네트워크 제한에만 의존하는 것으로는 충분하지 않았으며, 자체 통합 테스트로 통제를 계속 검증할 필요도 있었다. 이에 Amazon Bedrock AgentCore의 기능인 AgentCore Code Interpreter를 VPC 모드로 사용하고 계정 격리, DNS Firewall, VPC 엔드포인트 정책을 결합해 보안 통제를 직접 소유하는 방식을 선택했다.

3. 별도 계정과 작업별 자격 증명을 통한 격리

전체 구조는 Benchling Stack, IAM 역할, AWS STS, 고객 데이터가 담긴 Amazon S3가 있는 운영 계정과 신뢰할 수 없는 코드를 실행하는 별도의 Untrusted Code Account로 나뉜다. AI 생성 코드는 후자의 계정에서 실행되므로 문제가 발생하더라도 고객 데이터와 접근 역할을 보유한 주 운영 계정이 직접 노출되지 않도록 범위를 제한한다. 이 계정에는 AgentCore Code Interpreter와 기존 gVisor 기반 컨테이너 실행 환경이 함께 있지만, gVisor는 기존의 작업별 컴퓨팅 격리 계층이며 글에서 제시하는 패턴의 필수 구성 요소는 아니다. 두 실행 환경은 각각 범위가 제한된 IAM 역할을 사용하고, 운영 계정에서 작업을 전달할 때는 AWS STS를 통해 해당 작업에 필요한 데이터로 접근을 제한한 자격 증명을 세션에 주입한다. 이 방식은 광범위한 운영 계정 자격 증명이나 고객 데이터 저장소를 직접 노출하지 않으면서 테넌트마다 정적 IAM 역할을 누적하는 문제를 피한다.

4. 인터넷 경로를 제거하고 허용된 통신만 유지

ACCI VPC는 명시적으로 허용하지 않은 것은 사용할 수 없다는 원칙으로 설계되었으며, 인터넷 게이트웨이와 NAT 게이트웨이가 없어 코드가 공용 인터넷에 직접 도달할 경로가 없다. Code Interpreter는 포트 443으로 제한된 전용 보안 그룹 안에서 실행되고, 허용된 네트워크 경로는 VPC 엔드포인트를 통해 제공된다. 구성도에서는 S3 Gateway 엔드포인트와 Interface 엔드포인트가 승인된 S3 접근을 담당하며, NACL과 접두사 목록 기반 라우팅이 트래픽을 해당 경로로 제한한다. 여기에 DNS 질의 제어와 작업별 데이터 접근 제한이 겹쳐 적용되므로, 네트워크 연결을 허용할지와 연결 후 어떤 데이터에 접근할지를 서로 다른 통제 지점에서 다룬다. 이 구조는 단순히 외부 포트를 차단하는 데서 끝나지 않고, DNS 해석과 실제 목적지 도달 경로를 함께 제한한다는 점에서 출발점의 문제에 대응한다.

5. DNS Firewall의 명시적 차단과 최소 허용

Route 53 Resolver DNS Firewall의 첫 번째 계층인 P10은 가장 먼저 평가되어 알려진 악성 또는 의도하지 않은 도메인의 해석을 차단한다. 데이터 유출 도구나 명령·제어 인프라와 관련된 도메인을 식별하면 다른 허용 구성과 관계없이 이 계층에서 거부할 수 있으며, 명시적 차단 목록에 걸린 질의의 로그는 의심스러운 코드 동작을 조기에 파악하는 근거가 된다. 두 번째 계층인 P100은 명시적으로 등록한 도메인만 허용하며, 실제로는 작업에 필요한 특정 S3 버킷 엔드포인트 중심으로 목록을 최소화한다. 정상적인 AWS 서비스 엔드포인트라도 Benchling이 승인하지 않았다면 해석할 수 없도록 하여, 허용된 도메인 자체가 잠재적 유출 경로가 될 수 있다는 점을 반영한다. 이 허용 목록은 서비스 버전에 따라 달라질 수 있는 시스템 기본값과 달리 Benchling이 직접 감사하고 버전을 관리하며 자체 일정에 따라 갱신할 수 있는 통제 수단이다.

6. P200의 NODATA 응답과 DNS 유출 차단 원리

마지막 계층인 P200은 P100에서 명시적으로 허용되지 않은 모든 DNS 질의에 NODATA를 반환하는 포괄적 차단 규칙이다. 글에서 설명하는 전형적인 DNS 터널링은 탈취한 데이터를 하위 도메인 이름에 인코딩하고, 재귀적 이름 해석을 통해 공격자가 통제하는 권한 있는 네임서버로 그 질의를 전달하는 방식이다. 엄격한 허용 목록 밖의 도메인에 NODATA를 반환하면 이러한 질의가 전달될 해석 경로가 없어지고, DNS 재귀 체인이 첫 단계에서 끊어진다는 것이 원문의 설명이다. 원문은 이 규칙이 DNS 유출을 불가능하게 만들고 VPC를 봉쇄된 상태로 전환한다고 주장하며, 핵심 근거로 허용 목록 밖의 질의가 외부 해석 경로를 타지 못한다는 점을 제시한다. 따라서 새로운 도메인이나 누락된 엔드포인트가 기본적으로 해석되는 대신, Benchling이 의도적으로 승인한 대상만 해석되는 보안 상태를 만든다.

7. 개념 검증을 지속적 통합 테스트로 전환

Benchling의 Product Security 팀은 먼저 개념 검증용 VPC에서 각 방어 계층을 개별적으로 시험했고, 허용 목록 밖의 DNS 질의에 NODATA가 반환되는지 확인했다. 직접 IP 연결 시도에서는 접두사 목록 라우팅과 NACL이 통신을 포트 443과 임시 포트로 제한하며 임의의 외부 호스트로 가는 경로가 없음을 검증했고, API 호출에서는 범위 밖 S3 버킷 요청이 VPC 엔드포인트 정책으로 거부되는지 확인했다. 이후 Infrastructure 팀은 인코딩된 하위 도메인을 이용한 DNS 터널링, 무단 엔드포인트 연결, 정책 범위 밖 S3 접근 시뮬레이션을 지속적 통합 테스트에 포함했다. 해석되어서는 안 되는 도메인이 해석되거나 외부 엔드포인트에 도달하거나 승인된 버킷 밖으로 데이터가 이동하면 파이프라인이 실패하고 릴리스가 차단된다. VPC 설정, 엔드포인트, IAM 정책이 계속 바뀔 수 있으므로, 이 방식은 배포 시점의 안전성을 한 번 확인하는 데서 그치지 않고 이후 변경이 보안 경계를 약화하는지도 운영 반영 전에 검증한다.

8. 엔드포인트 정책의 독립적 방어와 운영 실적

인터넷 게이트웨이와 NAT 게이트웨이가 없는 VPC에서 AWS 서비스에 접근하려면 VPC 엔드포인트를 거쳐야 하며, Benchling은 같은 리전의 S3 접근에 Gateway 엔드포인트를, 다른 리전의 S3 접근에 Interface 엔드포인트를 사용한다. 각 엔드포인트에 연결한 정책은 도달 가능한 S3 버킷을 명시적으로 열거하고, 목록 밖의 버킷을 대상으로 하는 요청은 S3에 도달하기 전에 네트워크 계층에서 거부한다고 원문은 설명한다. 따라서 신뢰할 수 없는 코드가 접근해서는 안 되는 버킷의 유효한 자격 증명을 확보하더라도 엔드포인트 정책이 요청을 막는다는 점에서 IAM과 독립적인 방어가 성립한다. 글의 도입부는 현재 이 아키텍처가 하루 600회가 넘는 코드 실행 세션과 주간 250개가 넘는 테넌트를 처리하며 보안 사고 0건을 기록했다고 보고하지만, 측정 기간은 제시하지 않는다. 제공된 본문은 자격 증명과 엔드포인트 정책의 역할을 이어 설명하던 문장 중간에서 끝나므로, 이후의 설명이나 결론은 확인할 수 없다.

🧾 핵심 주장 / 시사점

• Benchling의 선택 기준은 네트워크 제한의 존재뿐 아니라 고객이 DNS와 엔드포인트 통제를 직접 정의하고 지속적으로 검증할 수 있는지에 있었다.
• 작업별 자격 증명은 데이터 접근 권한을 좁히고 VPC 엔드포인트 정책은 도달 가능한 버킷을 제한하므로, 유효한 자격 증명만으로 모든 접근 제한이 해제되는 구조를 피한다.
• 데이터 유출 시뮬레이션을 릴리스 차단 조건으로 연결하면 인프라 변경에 따른 보안 경계의 약화를 반복적으로 검증할 수 있지만, 보고된 보안 사고 0건만으로 모든 공격 가능성이 제거되었다고 판단할 수는 없다.

✅ 액션 아이템

• Benchling의 위협 모델을 기준으로 VPC 모드에서 DNS와 도달 가능한 엔드포인트의 직접 통제 범위를 검토한다.
• AWS STS 작업별 자격 증명과 VPC 엔드포인트 정책이 필요한 데이터와 허용된 S3 버킷으로 접근을 제한하는지 확인한다.
• 지속적 통합 테스트에서 DNS 터널링, 무단 엔드포인트 연결, 허용 범위 밖 S3 접근의 성공이 릴리스 차단으로 이어지는지 검증한다.

❓ 열린 질문

• 보안 사고 0건이라는 실적과 하루 600회 초과 세션·주간 250개 초과 테넌트라는 처리 규모는 각각 어느 기간을 기준으로 측정되었는가?
• AWS STS 작업별 자격 증명은 테넌트별 IAM 역할을 늘리지 않으면서 각 작업에 필요한 데이터의 범위를 구체적으로 어떻게 정하는가?
• DNS Firewall의 P100 허용 목록과 VPC 엔드포인트 정책이 변경될 때 지속적 통합 테스트는 어떤 기준으로 검증 범위를 조정하는가?