AI 에이전트가 데이터베이스, API 및 민감한 비즈니스 작업에 접근할 때, X.509 공개 키 인프라(PKI)를 통한 암호화 기반 신원 확립이 중요한 요구 사항이 됩니다. 핵심 과제는 어떤 에이전트가 요청을 보냈는지 증명하고, 에이전트 간 위조를 방지하며, 각 에이전트가 승인된 사용자를 대신해서만 작동하는지 확인하는 것입니다. 구성 요소 간에 API 키를 공유하거나 에이전트 체인을 통해 OAuth 토큰을 전달하는 등의 전통적인 접근 방식은 엔터프라이즈 배포가 요구하는 제로 트러스트 요건을 충족하지 못합니다.
멀티 에이전트 AI 프레임워크는 에이전트를 외부 도구 및 데이터 소스에 연결하기 위해 점점 더 Model Context Protocol(MCP)을 사용하고 있습니다. MCP는 대규모 언어 모델(LLM) 기반 에이전트가 데이터베이스 쿼리나 이메일 작업과 같은 도구를 호출하는 방식을 정의합니다. 그러나 MCP에는 내장된 인증 표준이 없으며, 설계상 전송 계층에 구애받지 않습니다(transport-agnostic). 이는 심각한 공백을 만듭니다. 적절한 신원 확인 메커니즘이 없으면 어떤 구성 요소든 에이전트를 사칭하거나, 가로챈 자격 증명을 재사용하거나, 승인 없이 도구를 호출할 수 있습니다.
이 게시물에서는 Keyfactor EJBCA를 AWS 서비스와 결합하여 이 공백을 해결하는 방법을 보여드립니다. EJBCA는 고가용성 배포, REST API 자동화, Online Certificate Status Protocol(OCSP) 검증을 지원하는 PKI 플랫폼입니다. 이 참조 아키텍처는 상호 보완적인 네 가지 보안 메커니즘을 사용합니다. 첫째, 서명된 요청 봉투는 모든 에이전트 호출에서 암호화 기반 소유 증명(proof-of-possession)을 제공합니다. 둘째, 사용자 서명 위임 assertion은 자격 증명을 공유하지 않고도 에이전트에게 권한을 부여합니다. 셋째, RFC 8693 audience 범위 토큰은 단일 토큰 노출로 인한 노출 범위를 제한합니다. 넷째, 실시간 OCSP 폐기 확인은 자격 증명 변경을 모든 에이전트에 즉시 전파합니다.
이 솔루션은 Amazon Bedrock 을 통해 LLM 추론을 위해 AWS Strands Agents SDK를 사용합니다. 이 참조 아키텍처는 데이터베이스를 보호 대상 리소스로 사용하지만, 동일한 인증 패턴이 MCP 호환 모든 도구 서버에 적용됩니다. 모든 예제의 전체 소스 코드는 함께 제공되는 GitHub 리포지토리에서 확인할 수 있습니다.
Keyfactor EJBCA 소개
Keyfactor에 따르면, Keyfactor는 전 세계 1,500개 이상의 엔터프라이즈 고객이 사용하는 널리 채택된 머신 신원 관리 플랫폼을 제공합니다. 이러한 조직들은 금융 서비스, 의료, 제조 및 정부 분야에 걸쳐 있습니다. Keyfactor는 인증서 수명 주기 관리, PKI 운영 및 머신 신원 거버넌스를 통해 조직이 암호화 기반 신뢰를 구축하고 유지하도록 지원합니다.
EJBCA Enterprise는 고가용성 배포와 REST API 자동화를 위해 설계된 Keyfactor의 인증 기관(CA) 및 PKI 플랫폼입니다. 엔터프라이즈 제품으로 제공되는 EJBCA는 웹 콘솔과 REST API를 모두 통해 X.509 인증서 발급, OCSP 검증, 인증서 폐기 목록(CRL) 배포 및 전체 인증서 수명 주기 관리를 제공합니다. EJBCA는 온프레미스, 컨테이너 또는 Amazon Elastic Compute Cloud(Amazon EC2)에서의 배포를 지원합니다.
AWS와 Keyfactor의 파트너십은 AWS 관리형 서비스(Amazon Bedrock, AWS Secrets Manager, Amazon Relational Database Service(Amazon RDS))를 인증서 수명 주기 관리, 자동 등록 및 실시간 폐기를 지원하는 PKI 인프라와 결합합니다. 이 조합은 AI 에이전트 생태계의 공백을 해결합니다. AWS가 컴퓨팅, 스토리지 및 AI 추론 계층을 제공하는 반면, Keyfactor는 에이전트를 검증 가능하고 폐기 가능한 단기 자격 증명에 연결하는 암호화 신원 계층을 제공합니다. AWS와 Keyfactor 엔지니어링 팀이 공동으로 개발한 이 공동 참조 아키텍처는 이러한 기술을 통합하는 방법을 보여줍니다. 여기에 소개된 패턴을 자신의 멀티 에이전트 배포에 맞게 조정할 수 있습니다.
솔루션 개요
이 아키텍처는 에이전트 통신 체인에서 서로 다른 신뢰 경계를 각각 다루는 세 가지 인증 계층을 구현합니다. 이 세 계층은 앞서 소개한 네 가지 보안 메커니즘, 즉 소유 증명을 위한 서명된 봉투, 자격 증명 없는 권한 부여를 위한 위임 assertion, 노출 제한을 위한 audience 범위 토큰, 실시간 폐기를 위한 OCSP를 사용합니다. 각 메커니즘은 다음 표와 같이 계층 전반에 걸쳐 결합됩니다.
| 계층 | 신뢰 경계 | 메커니즘 | 검증 항목 |
| 1. 사용자 인증 | 사용자에서 시스템으로 | OAuth + X.509 인증서 + 위임 발급 | 사용자 신원, 자격 증명 바인딩 |
| 2. 에이전트 간 | 에이전트에서 에이전트로 | 서명된 봉투(PoP + nonce + 타임스탬프) | 호출자 신원, 요청 신선도, 재생 없음 |
| 3. MCP 인증 | 에이전트에서 도구 서버로 | 범위 토큰 + 봉투 + 위임 | 모든 신원(identity), 인증 위임 체인, OCSP |
그림 1은 세 가지 인증 계층과 사용자, 에이전트, MCP 툴 서버 간에 자격 증명이 어떻게 흐르는지 보여줍니다. 이 다이어그램은 사용자 자격 증명(로그인 흐름에 유지됨), 에이전트 자격 증명(에이전트별로 범위가 지정됨), 그리고 이 둘을 연결하는 위임 체인 간의 분리를 보여줍니다.
그림 1: AWS에서 AI 에이전트 시스템을 위한 3계층 PKI 인증 아키텍처
그림 2는 일반적인 사용자 세션 중의 상세한 트래픽 흐름을 보여줍니다. 로그인부터 인증서 발급, 에이전트 위임, 도구 호출, 세션 정리에 이르는 인증 단계의 순서를 보여줍니다.
그림 2: 사용자 로그인부터 에이전트 위임, 도구 호출, 세션 정리까지의 인증 트래픽 흐름
사용된 AWS 서비스
다음 AWS 서비스들이 이 참조 아키텍처의 기반이 됩니다.
| 서비스 | 용도 |
| Amazon Bedrock | Strands Agents SDK를 통한 LLM 추론 |
| Amazon RDS for MySQL | MCP 도구를 통해 액세스하는 애플리케이션 데이터베이스 |
| Amazon Simple Email Service(Amazon SES) | Email Agent를 위한 이메일 전송 |
| AWS Secrets Manager | PKCS12 번들, 토큰 및 메타데이터의 보안 저장소 |
| Amazon EC2 | Keycloak IDP 및 EJBCA PKI 서버 호스팅 |
솔루션 워크스루
다음 단계에서는 초기 사용자 로그인부터 세션 정리까지 아키텍처의 각 구성 요소를 살펴봅니다. 각 단계는 이전 단계를 기반으로 하며, 인간 사용자와 최종 도구 실행을 연결하는 신뢰 체인을 구축합니다.
사전 조건
- Amazon Bedrock, Amazon RDS for MySQL, Amazon SES 및 AWS Secrets Manager에 액세스할 수 있는 활성 AWS 계정.
- Keycloak 26.2 이상(RFC 8693 표준 토큰 교환에 필요. 이전 버전은 호환되지 않는 레거시 교환 방식을 사용함).
- REST API V1과 OCSP 응답자가 구성된 Keyfactor EJBCA Enterprise.
- REST API 인증을 위한 EJBCA API 관리자 인증서(
api-admin.p12) - Python 3.9+ 개발 환경.
- X.509 인증서, OCSP, OAuth 2.0, RSA 디지털 서명 및 PKCS#12 키 스토어에 대한 지식.
1단계: 사용자 로그인, 인증서 발급 및 위임 생성
로그인 흐름은 세 가지 메커니즘을 통해 사용자의 신원을 확인한 다음, 사용자의 자격 증명을 공유하지 않고 AI 에이전트에게 권한을 위임합니다. 이 분리가 핵심입니다: 에이전트는 사용자의 개인 키나 전체 세션 OAuth 토큰을 전혀 보유하지 않으면서도 권한 부여의 증거를 받게 됩니다.
먼저, 애플리케이션은 OAuth 2.0 password grant를 사용하여 Keycloak에 대해 사용자를 인증하고, 전체 세션 액세스 토큰과 리프레시 토큰을 받습니다. 직후, 애플리케이션은 RFC 8693 토큰 교환을 수행하여 다운스코핑된 토큰을 얻습니다. 이 토큰의 오디언스는 MCP 서버로 제한됩니다. 이 제한된 토큰만 에이전트에게 전달됩니다. 실수로 노출되더라도 조직의 다른 서비스에는 액세스할 수 없습니다.
둘째, 애플리케이션은 RSA 2048+ 키 쌍을 로컬에서 생성하고 인증서 서명 요청(CSR)을 통해 pkcs10enroll REST API 엔드포인트로 EJBCA에 제출합니다. EJBCA는 CSR에 서명하고 인증서를 반환합니다. 애플리케이션은 인증서와 개인 키를 PKCS12 컨테이너로 번들하여 AWS Secrets Manager에 저장합니다. 개인 키는 애플리케이션 경계를 절대 벗어나지 않습니다. EJBCA로 전송되지 않고, 에이전트와 공유되지 않으며, 파일시스템에 저장되지도 않습니다. 세 개의 에이전트 인증서가 동일한 CSR 기반 흐름을 사용하여 에이전트 역할별로 하나씩 발급됩니다.
셋째, 사용자의 개인 키가 위임 어서션에 서명합니다. 이는 세 에이전트 인증서 모두의 SHA-256 지문과 사용자의 주체 이름, 발급 시간 및 만료 시간을 나열하는 JSON 문서입니다. 이 위임은 사용자가 이 특정 에이전트들이 자신을 대신하여 행동하도록 승인했음을 증명합니다. 에이전트는 사용자의 인증서 대신 이 위임을 지니고 다닙니다.
# RFC 8693 Token Exchange - downscope to MCP audience
downscoped_token = keycloak.token_exchange(
original_token, audience="mysql-mcp-server", scope="database:write"
)
# Client-side key generation (user key never leaves this flow)
private_key = rsa.generate_private_key(public_exponent=65537, key_size=2048)
csr = build_csr(private_key, f"CN={username},E={username}@org.com")
user_cert = ejbca.pkcs10enroll(csr, ca_name="UserCA")
# User signs delegation over agent cert fingerprints
delegation = mint_delegation(
username=username,
user_cert_pem=user_cert,
user_key_pem=private_key_pem,
agent_cert_pems=[orch_cert, mysql_cert, email_cert]
)
# Result: {sub, agent_fingerprints[], iat, exp, user_cert_pem, signature_b64}2단계: 에이전트 간 서명된 엔벨로프
오케스트레이터 에이전트가 요청을 하위 에이전트(예: MySQL 에이전트 또는 Email 에이전트)로 라우팅할 때, 단순히 식별을 위해 자신의 인증서를 전달하지 않습니다. 대신 도구 이름, 인수, 타임스탬프, 암호학적으로 무작위인 nonce를 포함한 전체 요청 페이로드를 자신의 개인 키로 다음과 같이 서명합니다: RSA-PSS-SHA256결과적으로 생성된 서명된 봉투(signed envelope)는 소유 증명(proof-of-possession)을 제공합니다. 수신 에이전트는 호출자가 제시된 인증서에 해당하는 개인 키를 실제로 보유하고 있는지 검증할 수 있습니다.
수신 에이전트는 요청을 처리하기 전에 봉투에 대해 여섯 가지 검증 절차를 수행합니다:
- 서명 검증: 발신자가 개인 키를 보유하고 있음을 증명합니다(소유 증명, proof-of-possession).
- 타임스탬프 최신성: 그 봉투는 다음 범위 안에 있어야 합니다
ENVELOPE_MAX_AGE_SECONDS(기본값 60초) 현재 시간 기준. - Nonce 고유성: The
ReplayCache이전에 본 nonce를 거부하여 요청 재전송(replay)을 방지합니다. - CA 체인 검증: 송신자의 인증서는 신뢰할 수 있는 CA(
UserCA.pem). - 역할 권한 부여: 인증서 CN의 역할 접미사는 다음에 속해야 합니다
ALLOWED_CALLER_ROLES이 에이전트를 위한 것입니다. - OCSP 폐기 확인: EJBCA에 대한 실시간 확인을 통해 인증서가 폐기되지 않았음이 확인됩니다.
오케스트레이터가 동일한 프롬프트를 다시 보내야 하는 경우(예: 일시적 실패 후), 새로운 nonce로 새 봉투(envelope)를 생성해야 합니다. 오래된 봉투는 정당한 발신자라 하더라도 재생할 수 없습니다.
# Orchestrator signs request to sub-agent
envelope = sign_envelope(
payload={"tool": "query_database", "args": {"sql": "SELECT ..."}},
cert_pem=orchestrator_cert_pem,
private_key_pem=orchestrator_key_pem
)
# envelope: {payload_b64, cert_pem, timestamp, nonce, signature_b64, alg}
# Sub-agent verifies (six checks)
verified_payload = verify_envelope(
envelope,
allowed_role="orchestrator-agent",
ca_cert_pem=ca_pem,
replay_cache=cache
)3단계: MCP 서버 인증
MCP 서버(FastMCP)는 데이터베이스 작업이 실행되기 전의 최종 신뢰 경계입니다. 이 서버는 모든 도구 호출에 대해 네 가지 검증 검사를 수행하여 다층 방어(defense-in-depth)를 구현합니다. 하나의 자격 증명이 무단 접근을 당하더라도 나머지 검사가 무단 작업을 방지합니다.
인증 절차:
- 토큰 인트로스펙션: Keycloak에 게시된 글
/token/introspect엔드포인트는 토큰이 활성 상태인지 그리고 audience에 "mcp-server"가 포함되어 있는지 확인합니다. 올바른 audience가 없는 전체 세션 토큰은 거부됩니다. - 봉투 검증: 에이전트의 서명된 봉투는 서명 정확성, 타임스탬프 신선도, nonce 고유성, CA 체인 신뢰, 역할 일치(
mysql-agent( ), OCSP 폐지되지 않음 검사. - 위임 검증: 사용자의 위임 assertion이 검증됩니다. 서명은 사용자 키 보유자가 이 위임을 승인했음을 증명하고, 호출하는 에이전트의 인증서 지문이 승인 목록에 포함되어 있으며, 사용자의 인증서는 OCSP를 통해 확인됩니다.
- 신원 교차 확인: 토큰 사용자명, 위임 subject, 에이전트 인증서 CN 접두어가 모두 일치해야 합니다. 이를 통해 사용자부터 도구 실행까지 단일하고 일관된 신원 체인이 확인됩니다.
# MCP Server - Four validation checks
# 1. Token: must be active with correct audience
info = introspect(token)
assert info["active"] and "mcp-server" in info["aud"]
# 2. Envelope: proof-of-possession + freshness + replay + CA + role + OCSP
payload = verify_envelope(envelope, "mysql-agent", ca_pem, replay_cache)
# 3. Delegation: user authorized this agent + user cert not revoked
claims = verify_delegation(delegation, agent_cert_pem, ca_pem)
# 4. Cross-check: consistent identity chain
assert token_username == claims["sub"] == agent_cn.rsplit("_", 1)[0]
# All checks passed - execute tool
result = execute_sql(payload["args"]["sql"])4단계: 재생 방지
서명된 모든 envelope은 고유한 nonce, 즉 Python의 secrets 모듈로 생성된 128비트 암호학적 난수 16진수 문자열을 담고 있습니다. ReplayCache 은(는) 모든 nonce를 신선도(freshness) 기간이 만료될 때까지(2x ENVELOPE_MAX_AGE_SECONDS). 동일한 nonce가 두 번째 요청에 나타나면, 서명이 유효하고 타임스탬프가 신선하더라도 봉투는 즉시 거부됩니다.
타임스탬프 검증은 nonce 검사를 보완합니다. 봉투의 타임스탬프는 ENVELOPE_MAX_AGE_SECONDS (기본값 60초) 이내여야 하며, 이는 서버의 현재 시간 기준입니다. 이 두 메커니즘은 함께 네 가지 무단 접근 시나리오를 해결합니다:
- 기록된 재전송(replay): 무단 사용자가 유효한 봉투를 캡처한 후 나중에 다시 제출합니다. 해당 nonce는 이미 확인된 것입니다.
- 지연 전달: 전송 중 가로채인 봉투가 신선도(freshness) 창이 지난 후에 도착합니다. 타임스탬프 검사가 실패합니다.
- 오래된 요청 재사용: 프록시에 캐시된 오래된 봉투가 다시 제출됩니다. nonce와 타임스탬프 검사 모두 실패합니다.
- 사전 계산된 위조: 무단 사용자는 미래의 nonce를 예측하여 봉투를 미리 서명할 수 없습니다.
5단계: 클라이언트 측 키 생성
이 아키텍처의 핵심 보안 특성은 개인 키가 로컬에서 생성되며 어떤 외부 시스템으로도 전송되지 않는다는 것입니다. 애플리케이션은 Python cryptography 라이브러리를 사용하여 RSA 2048+ 키 쌍을 생성합니다. 공개 키와 주체 정보만 포함하는 CSR을 구성하고, CSR만 pkcs10enroll 엔드포인트를 통해 EJBCA로 전송합니다.
EJBCA는 CSR을 검증하고, 인증서 프로파일(7일 유효 기간, 키 사용 제약)을 적용하며, CA 키로 서명한 후 발급된 인증서를 반환합니다. 애플리케이션은 로컬에 보관된 개인 키를 반환된 인증서와 함께 PKCS12 컨테이너로 묶어 AWS Secrets Manager에 저장합니다.
이 설계는 여러 가지 보안 특성을 제공합니다:
- 사용자의 개인 키는 로그인 시 위임 assertion에 서명하는 데에만 사용됩니다. 에이전트와 공유되지 않습니다.
- 각 에이전트의 개인 키는 해당 에이전트가 봉투에 서명하는 데에만 사용됩니다. 에이전트 간에 공유되지 않습니다.
- EJBCA는 개인 키를 보거나 저장하지 않습니다. 순수하게 인증 기관으로만 동작합니다.
- Secrets Manager에 무단 접근이 발생하더라도, PKCS12 비밀번호(별도로 저장됨)가 추가적인 보호 계층을 제공합니다.
- 키 자료는 다음 로그인 시 새로운 CSR로 재등록함으로써 독립적으로 교체될 수 있습니다.
6단계: 완전한 로그아웃 및 자격 증명 폐기
로그아웃은 폐기 연쇄(cascade)를 트리거하여 아직 유효한 모든 자격 증명을 즉시 무효화합니다. 이 시퀀스가 완료되면 남아 있는 유효한 자격 증명이 없습니다:
- EJBCA에서 사용자 인증서 폐기: 이는 모든 미결 위임을 즉시 무효화합니다. 위임 검증이 실시간으로 OCSP를 통해 사용자의 인증서를 확인하기 때문입니다.
- 세 개의 에이전트 인증서를 모두 폐기: 이는 모든 미결 서명 봉투를 무효화합니다. 봉투 검증에 OCSP가 포함되어 있기 때문입니다.
- AWS Secrets Manager에서 모든 시크릿 삭제: 복구 기간 없이 즉시 삭제하기 위해
ForceDeleteWithoutRecovery를 사용합니다. - Keycloak 세션 종료: 세션 종료 엔드포인트를 통해 다운스코핑된 토큰을 무효화합니다.
폐기 연쇄가 핵심 보안 속성입니다. PKI 계층에서 단일 사용자 인증서를 폐기하면 토큰을 개별적으로 폐기하거나, 세션을 삭제하거나, 각 에이전트에 연락할 필요 없이 모든 다운스트림 에이전트 권한이 신속하게 폐기됩니다. OCSP가 전파 메커니즘을 제공하며, 모든 요청이 OCSP를 확인하기 때문에 그 효과는 즉각적입니다.
보안 고려 사항
이 아키텍처의 설계 선택은 프로덕션 멀티 에이전트 배포에 중요한 여러 보안 속성을 다룹니다.
프라이빗 키 격리. 사용자의 프라이빗 키는 로그인 흐름 중에만 존재하며 위임 서명에만 사용됩니다. 에이전트 키는 에이전트별로 범위가 지정되며 절대 공유되지 않습니다. 어떤 키 자료도 신뢰 경계를 넘지 않습니다.
자격 증명 공유와 비교한 위임. 에이전트는 사용자 자격 증명을 전혀 보유하지 않고도 암호화 체인(위임 → 에이전트 지문 → 봉투 서명)을 통해 권한을 증명합니다. 에이전트 키가 노출되더라도 해당 에이전트의 키만 노출되며 사용자의 키는 노출되지 않습니다.
대상 범위 토큰. RFC 8693 토큰 교환은 MCP 서버만 수락하는 토큰을 생성합니다. 실수로 유출된 다운스코핑된 토큰은 Keycloak 관리 API나 다른 서비스, 심지어 다른 MCP 서버 인스턴스에 대해서도 인증할 수 없습니다.
리플레이 방지. 요청별 nonce와 60초 신선도 창의 조합으로 모든 요청이 일회성이며 시간 제한이 있음을 확인합니다. 이 ReplayCache 는 스레드 안전하며 자체 정리됩니다.
Fail-closed 설계. 모든 검증 실패는 즉각적인 거부로 이어집니다. OCSP 도달 불가: 거부. 잘못된 서명: 거부. 만료된 타임스탬프: 거부. 재사용된 nonce: 거부. 잘못된 대상: 거부. 보안 검사에 대한 우아한 성능 저하(graceful degradation)는 없습니다.
폐기 연쇄. 사용자 인증서 하나를 폐기하면 모든 위임, 모든 에이전트 권한, 모든 미결 봉투가 신속하게 무효화됩니다. 이는 개별 자격 증명 정리 없이 실시간 OCSP를 통해 전파됩니다.
순방향 전용 신뢰 체인. 이 ALLOWED_CALLER_ROLES 맵은 orchestrator-agent 만이 mysql-agent 및 email-agent을 호출할 수 있음을 강제합니다. 하위 에이전트는 서로를 호출할 수 없고, 오케스트레이터를 향해 상향 호출할 수 없으며, 사용자를 사칭할 수 없습니다.
AI 거버넌스 고려 사항
PKI 아키텍처는 이 시스템의 AI 에이전트를 위한 내장된 행동 경계를 제공합니다. 프로덕션 배포에서는 이 게시물에서 설명하는 PKI 기반 액세스 제어와 함께 Amazon Bedrock Guardrails를 사용하여 에이전트 응답에 대한 콘텐츠 필터링, 주제 회피, 그라운딩 검사를 강제해야 합니다.
- 도구 경계: AI 에이전트는 엄격한 도구 제약 하에서 작동합니다. 사전 정의된 MCP 도구(
execute_sql,describe_table,list_tables)만 호출할 수 있습니다. 에이전트는 임의의 코드를 실행하거나 인증서 범위를 벗어난 리소스에 액세스할 수 없습니다. - 인간 감독: 모든 에이전트 작업은 기록되고 감사 가능합니다. AWS CloudTrail은 AWS API 호출을 캡처하고, MCP 서버는 전체 신원 체인(사용자, 에이전트, 타임스탬프, 작업)과 함께 검증된 모든 도구 호출을 기록합니다.
- 데이터 처리: 사용자 쿼리와 결과는 인증된 세션 경계 내에 머무릅니다. 오디언스 스코프 토큰은 데이터 접근을 특정 MCP 서버 인스턴스로 제한합니다.
- 인증서 기반 동작 경계: 에이전트는 유효한 인증서를 보유한 도구만 호출할 수 있습니다.
mysql-agent인증서가 없는 에이전트는 LLM이 어떤 지시를 생성하더라도 데이터베이스에 접근할 수 없습니다.
아키텍처 확장
이 아키텍처를 확장하여 추가 에이전트 유형, 수평 확장, 멀티 테넌트 격리를 지원할 수 있습니다. 다음 단락에서는 가장 일반적인 확장 지점을 설명합니다.
- 새로운 에이전트 유형을 추가하려면
ALLOWED_CALLER_ROLES에 항목만 추가하면 됩니다. 인증서는 로그인 시 자동으로 발급되며, 위임 assertion은 새 에이전트의 지문을 동적으로 포함합니다. 인프라 변경은 필요하지 않습니다. - 수평 확장을 위해 로드 밸런서 뒤에 EJBCA의 OCSP responder를 고가용성 모드로 배포할 수 있습니다. AWS Secrets Manager는 이 워크로드에 적합한 높은 요청률을 지원합니다.
ReplayCache는 분산 배포를 위해 Amazon ElastiCache로 백업할 수 있습니다. - 프로덕션을 위해 아키텍처를 강화하려면 AWS CloudHSM 또는 온프레미스 HSM을 통해 하드웨어 보안 모듈(HSM) 기반 EJBCA 서명 키를 사용할 수 있습니다. OCSP 응답 스테이플링은 검증 지연 시간을 줄여주며, Certificate Transparency 로그는 발급된 인증서의 전체 감사 추적을 제공합니다.
- 멀티 테넌트 배포의 경우, 암호화 기반 테넌트 격리를 위해 테넌트별 Certificate Authority 또는 테넌트별 위임 기관을 생성할 수 있습니다. 테넌트별 AWS 계정과 결합하면 테넌트 간 강력한 격리를 제공합니다.
- PKI 기반 에이전트 신원을 AWS Identity and Access Management(IAM) 역할로 보완할 수도 있습니다. 에이전트 간 인증에는 PKI를, AWS 서비스 권한 부여에는 IAM을 사용하세요. 두 시스템은 독립적으로 작동하여 심층 방어를 제공합니다.
정리
지속적인 요금 청구를 피하려면 이 워크스루에서 생성한 리소스를 제거하세요:
- Amazon RDS for MySQL 인스턴스를 삭제합니다(스크립트 방식 설정을 사용한 경우 해당 AWS CloudFormation 스택을 삭제).
- AWS Secrets Manager에서
mcp/접두사 아래의 사용자 인증서와 에이전트 인증서를 포함한 모든 시크릿을 삭제합니다. - Amazon SES에서 확인된 발신자 이메일 주소를 제거합니다.
- Keycloak 및 EJBCA를 실행 중인 Amazon EC2 인스턴스를 종료합니다(이 데모를 위해 배포한 경우).
- EJBCA 관리 콘솔 또는 REST API를 사용하여 EJBCA의 모든 테스트 인증서를 폐기하고 삭제합니다.
- Keycloak realm(
mcp-realm) 및 관련 클라이언트를 제거합니다. - 스크립트 기반 설정을 사용한 경우,
./scripts/cleanup.sh(Linux) 또는./scripts/cleanup.bat(Windows)을 실행하여 이 단계를 자동화하세요.
결론
이 게시물에서는 Keyfactor EJBCA와 AWS 서비스를 사용하여 X.509 PKI로 AI 에이전트 통신을 보호하는 레퍼런스 아키텍처를 시연했습니다. 이 아키텍처는 네 가지 상호 보완적인 메커니즘을 통해 멀티 에이전트 AI 시스템의 근본적인 아이덴티티 격차를 해결합니다:
- 서명된 요청 봉투(signed request envelope)는 에이전트 간 모든 호출에서 암호학적 소유 증명(proof-of-possession)을 제공하여, 승인되지 않은 당사자가 에이전트의 신원을 위조하거나 요청을 재생하는 것을 훨씬 더 어렵게 만듭니다.
- 사용자 서명 위임 assertion은 권한 부여를 자격 증명 공유로부터 분리합니다. 에이전트는 사용자의 개인 키나 전체 세션 토큰을 보유하지 않고도 사용자를 대신하여 행동할 권한이 있음을 증명합니다.
- RFC 8693 audience 범위 토큰은 토큰 유출 시 노출 범위를 단일 서비스 경계로 제한합니다.
- 실시간 OCSP 폐기 확인은 자격 증명 폐기가 전체 시스템에서 즉시 효력을 발휘함을 확인합니다. 사용자 인증서 하나를 폐기하면 모든 다운스트림 에이전트 권한이 즉시 종료됩니다.
이 아키텍처는 프레임워크에 구애받지 않습니다. 여기서는 AWS Strands Agents SDK와 FastMCP로 시연했지만, 동일한 PKI 패턴은 도구 프로토콜을 사용하는 LangChain, CrewAI, AutoGen 또는 기타 모든 멀티 에이전트 프레임워크에 적용됩니다. AI 에이전트가 확산되고 점점 더 민감한 작업에 접근함에 따라, 에이전트 아이덴티티 인프라는 선택 사항에서 필수 사항으로 이동하고 있습니다.
이 레퍼런스 아키텍처를 시작하려면 함께 제공되는 GitHub 리포지토리를 참조하세요. 사용된 서비스에 대한 자세한 내용은 다음 리소스를 참조하세요:
- Amazon Bedrock
- Amazon Bedrock 사용 설명서
- Keyfactor EJBCA Enterprise
- MCP 사양
- AWS Strands Agents SDK
- Introducing Strands Agents, an Open Source AI Agents SDK (AWS 오픈 소스 블로그 게시물)