공유 비밀키를 대체하는 Private Key JWT 인증 도입

Amazon Bedrock AgentCore Identity가 공유 비밀키 없이 하위 ID 제공자(IdP)에 인증하는 Private Key JWT 인증 방식을 지원한다. 기존 OAuth 2.0 방식에서는 클라이언트 비밀키(Client Secret)라는 공통 비밀번호를 IdP와 에이전트가 공유해야 했으나, 이제는 서명된 토큰을 통해 신원을 증명한다. 비밀번호를 직접 주고받거나 설정 파일에 보관하지 않아도 되므로 자격 증명 유출 위험을 낮추고 인증 보안 수준을 높일 수 있다. 특히 주기적으로 비밀키를 변경해야 하는 로테이션 작업의 번거로움을 없애 운영 효율을 높인다. 이는 보안 요구사항이 엄격한 기업 환경에서 에이전트의 인증 체계를 단순화하고 관리 리스크를 제거하는 실질적인 선택지가 된다.

이 방식은 JSON 웹 토큰(JWT, JSON 기반의 데이터 교환 표준) 형태의 클라이언트 어설션을 활용한다. 어설션은 요청자가 누구인지 증명하는 디지털 신분증과 같다. 에이전트는 이 신분증에 개인키로 디지털 서명을 남겨 IdP의 토큰 엔드포인트로 전송한다. IdP는 미리 등록된 공개키를 사용해 해당 서명이 유효한지 검증함으로써 에이전트의 신원을 확인한다. 비밀키를 직접 전달하는 대신 서명 결과값만 확인하는 구조이므로, 네트워크 전송 과정에서 인증 정보가 탈취되어도 공격자가 이를 재사용해 인증을 통과하기 어렵다.

인증에 필요한 키 관리는 AWS Key Management Service(AWS KMS, AWS의 키 관리 서비스)가 전담한다. 서명에 사용되는 개인키는 외부로 노출되지 않고 KMS 내부에 안전하게 보관되며, 에이전트는 KMS를 호출하여 어설션에 서명한다. 관리자는 대응하는 공개키만 IdP에 등록하면 된다. 개인키가 네트워크를 통해 이동하거나 애플리케이션 설정 파일에 평문으로 저장될 필요가 없으므로 키 로테이션이나 관리 부담이 크게 줄어든다. 하드웨어 보안 모듈 수준의 보호를 받는 KMS를 통해 개인키의 물리적 보안을 확보하고 접근 권한을 중앙에서 제어하는 구조다.

실무자는 AWS 관리 콘솔의 AgentCore Identity 설정 페이지에서 인증 방법을 Private key JWT로 선택해 적용할 수 있다. 와 에서 보듯 OAuth 클라이언트를 추가하는 과정의 제공자 구성 섹션에서 해당 옵션을 선택하여 활성화한다. 기존의 공유 비밀키 기반 인증 워크플로를 비대칭 키 기반의 보안 모델로 전환하려면 IdP에 공개키를 등록하는 사전 작업이 필요하다. 설정이 완료되면 에이전트는 공유 비밀키라는 취약점 없이도 안전하게 하위 IdP로부터 토큰을 발급받아 필요한 리소스에 접근할 수 있다. 관리자는 콘솔 내에서 인증 방식의 전환 여부를 즉시 확인하고 제어할 수 있다.

기술이 실제로 작동하는 방식

AgentCore Identity가 AWS KMS(Amazon Web Services Key Management Service, AWS의 암호화 키 관리 서비스)를 호출하여 어설션에 서명하는 것으로 인증 절차가 시작된다. 여기서 어설션은 요청자가 누구인지, 어떤 권한을 가졌는지 기술한 일종의 신원 주장서다. 서명이 완료된 어설션은 IdP(Identity Provider, 자격 증명 제공자)의 토큰 엔드포인트로 전송된다. 토큰 엔드포인트는 IdP가 외부의 인증 요청을 받아 처리하는 전용 접점이다. 이 과정에서 실제 서명 작업은 KMS 내부의 보안 모듈에서 수행되므로 서명에 사용된 키가 네트워크를 타고 이동할 일이 없다.

IdP는 미리 등록해 둔 공개키를 사용하여 전송받은 서명의 유효성을 검증한다. 비대칭 키 방식은 서명용 개인키와 검증용 공개키가 한 쌍으로 묶여 작동하는 암호화 구조다. 개인키는 오직 KMS 내부에만 존재하며, 외부에서는 이 키의 값을 읽거나 복사할 수 없다. IdP는 공개키만을 이용해 해당 서명이 짝이 맞는 개인키로 작성되었는지를 수학적으로 확인하고, 검증이 성공하면 최종적으로 액세스 토큰을 발행한다. 이는 비밀번호와 같은 공유 비밀키를 IdP와 클라이언트가 동시에 가지고 있어야 했던 기존 방식의 보안 취약점을 해결한다.

이 메커니즘을 작동시키려면 먼저 KMS에서 비대칭 키를 생성하고 대응하는 공개키를 내보내 IdP에 등록하는 사전 작업이 필요하다. 만약 기업의 보안 정책상 IdP가 직접 키 쌍을 생성하고 관리해야 한다면, IdP가 발행한 개인키 재료를 KMS로 가져오기(Import) 하는 경로를 선택한다. 가져오기 방식을 사용하면 키의 생성 주체는 IdP가 되지만, 실제 서명 수행은 여전히 KMS의 안전한 환경 내에서 이루어진다. 관리자는 KMS의 키 ARN(Amazon Resource Name, AWS 리소스 고유 식별자)을 AgentCore Identity 설정에 입력하여 어떤 키로 서명할지 지정한다.

실무 관점에서는 개인키의 노출 경로를 완전히 차단하면서도 자동화된 인증 흐름을 유지할 수 있다는 점이 가장 큰 이점이다. 다만 KMS 비대칭 키는 생성 및 유지 시 비용이 발생하므로, 워크플로 테스트가 끝난 후에는 생성한 자격 증명 제공자와 서명 키를 삭제하여 자원을 정리해야 한다. KMS 키는 즉시 삭제되지 않고 예약 삭제 대기 기간을 거치므로, 운영 환경에서는 이 대기 기간 동안의 비용과 보안 정책을 함께 고려하여 삭제 일정을 잡는 것이 실용적이다.

M2M부터 사용자 위임까지 지원하는 3가지 Grant Flow

다수의 외부 API와 연동하는 에이전트 개발자는 단일 자격 증명 제공자(Credential Provider, 인증 정보를 관리하고 제공하는 모듈) 하나로 세 가지 인증 흐름을 모두 처리할 수 있다. 가장 기본이 되는 M2M(Machine-to-Machine) 흐름은 에이전트가 사용자 개입 없이 서비스 계정 권한으로 직접 하위 API를 호출할 때 사용한다. 이는 백엔드 시스템 간의 자동화된 데이터 교환이나 정기적인 배치 작업에 적합한 방식이다. 인증 주체가 사람이 아닌 소프트웨어 자체이므로 별도의 로그인 과정 없이 사전에 정의된 권한으로 통신하며 단순한 구조를 가진다.

사용자 권한을 대행하는 OBO(On-Behalf-Of) 흐름과 사용자 위임(User-delegated) 흐름에서도 동일한 키 기반 인증 체계가 작동한다. OBO 흐름은 사용자가 에이전트에 특정 요청을 보냈을 때 에이전트가 그 사용자의 신원과 권한을 이어받아 하위 API에 접근하는 방식이다. 사용자 위임 흐름은 사용자가 명시적으로 에이전트에게 자신의 리소스에 접근할 수 있는 권한을 부여한 상태에서 동작한다. 기존에는 각 흐름마다 서로 다른 인증 라이브러리를 도입하거나 설정 방식을 파편화하여 관리해야 했으나 이제는 하나의 제공자로 모든 흐름을 확장해 처리할 수 있다. 이는 개발자가 인증 흐름별로 별도의 인증 로직을 짤 필요 없이 설정값만 변경하여 대응할 수 있음을 의미한다.

모든 토큰 요청 과정은 AWS CloudTrail(AWS 리소스 활동을 기록하는 감사 서비스)에 기록되어 운영 단계의 사후 검증이 가능하다. 에이전트가 자격 증명 제공자를 통해 토큰을 가져오는 모든 작업이 구체적인 이벤트 이름과 함께 로그로 남으므로 보안 사고 발생 시 추적이 용이하다. 어떤 인증 흐름을 선택하든 서명 키는 AWS KMS 내부에 유지되며 외부로 노출되지 않는 구조를 유지한다. 인증 흐름이 다양해져도 실제 서명 작업이 일어나는 지점은 동일하므로 관리 포인트가 늘어나지 않으며 일관된 보안 정책을 적용할 수 있다. 기업의 보안 컴플라이언스 요구사항에 따라 누가 언제 어떤 권한으로 토큰을 요청했는지 증명해야 하는 환경에서 이러한 감사 로그는 필수적인 요소다.

실제 환경에 적용하려면 Entra나 Okta 같은 ID 제공자(IdP, 사용자 신원을 확인하고 토큰을 발행하는 시스템) 등록 과정과 각 흐름의 요청 구조를 파악해야 한다. M2M과 OBO 흐름을 포함한 전체 구현 예제는 Amazon Bedrock AgentCore samples GitHub 저장소에서 확인할 수 있다. Amazon Bedrock AgentCore samples 저장소의 코드를 참고하면 IdP 등록부터 토큰 요청까지의 전체 워크플로를 그대로 따라 할 수 있다. 특히 각 흐름별로 필요한 클레임 설정과 토큰 엔드포인트 호출 방식이 상세히 구현되어 있어 즉시 도입이 가능하다.

AWS Management Console 설정과 CloudTrail 감사 체계

AWS Management Console 설정 단계에서는 Discovery URL, Client ID, 비대칭 KMS 키 ARN, 서명 알고리즘 네 가지 항목을 필수적으로 입력해야 한다. Discovery URL은 IdP(자격 증명 제공자)의 설정 정보를 자동으로 찾는 엔드포인트 주소이며, KMS 키 ARN은 AWS 내에서 생성한 비대칭 키의 고유한 리소스 이름이다. 만약 사용하는 IdP가 JWT 클라이언트 어설션에 추가적인 클레임(Claims, 토큰 내에 포함될 사용자나 서비스의 식별 속성 정보)을 요구하는 경우, 설정 화면에서 이를 직접 삽입해 대응할 수 있다. 인프라 설정 단계에서 이 네 가지 항목이 IdP의 등록 정보와 정확히 일치해야만 에이전트가 서명된 토큰을 정상적으로 발급받는다.

인증 과정에서 발생하는 모든 호출 내역은 AWS CloudTrail을 통해 기록되며 이를 통해 에이전트의 액세스 이벤트를 실시간으로 감사할 수 있다. CloudTrail은 AWS 계정 내에서 발생하는 모든 API 호출을 기록하는 서비스로, 어떤 에이전트가 특정 시점에 KMS 키를 사용해 서명을 요청했는지에 대한 상세 로그를 남긴다. 기업 환경의 보안 담당자는 이 로그를 분석해 비정상적인 인증 시도나 권한 오남용 여부를 추적하고 대응할 수 있다. 이는 단순히 인증 성공 여부를 확인하는 수준을 넘어, 인프라 전체의 보안 가시성을 확보하고 규정 준수 여부를 증명하는 핵심 장치로 활용된다.

KMS 키를 삭제할 때는 즉시 삭제가 불가능하며 반드시 일정 대기 기간을 두는 예약 삭제(Schedule deletion) 프로세스를 적용해야 한다. KMS 키 삭제는 한 번 실행하면 되돌릴 수 없는 영구적인 작업이며, 키가 사라지면 해당 키에 의존하던 모든 데이터 복호화나 서명 생성 작업이 즉시 중단된다. 따라서 삭제 예약 버튼을 누르기 전에는 해당 키를 참조하고 있는 자격 증명 제공자나 IdP 등록 정보가 남아있는지 전수 조사를 수행해야 한다. 만약 키의 현재 사용 여부를 확신할 수 없는 상황이라면, 삭제 대신 키 비활성화를 선택해 사용을 중단시키면서도 필요시 즉시 복구할 수 있는 상태를 유지하는 것이 실무적인 판단 기준이다.

구체적인 설정 방법과 구현 예시는 AWS에서 공개한 https://github.com/aws-samples/amazon-bedrock-agentcore-samples 저장소에서 확인할 수 있다. 해당 샘플에는 콘솔 설정값의 배치부터 실제 인증 흐름을 검증하는 코드까지 포함되어 있어 실무자가 자신의 환경에 맞춰 빠르게 벤치마킹하기 좋다. 설정 과정에서 발생하는 ARN 경로 오류나 알고리즘 불일치는 인증 실패의 가장 빈번한 원인이 되므로, 샘플 저장소의 구성 방식을 기준으로 설정 값을 대조하며 입력하는 것이 시행착오를 줄이는 방법이다.

한국 기업의 IdP 연동 시 고려해야 할 실무 판단 기준

Entra ID나 Okta 같은 외부 IdP(ID 제공자)를 연동할 때 다른 계정의 KMS(키 관리 서비스) 키를 사용하려면 동일 리전 내의 키 ARN(Amazon Resource Name)을 입력해야 한다. 한국 기업처럼 개발과 운영 계정을 엄격히 분리한 환경에서는 특정 보안 계정에서 키를 통합 관리하고 이를 다른 서비스 계정에서 호출하는 교차 계정 액세스 설정이 빈번하게 사용된다. 이 과정에서 두 계정 모두에 적절한 IAM(ID 및 액세스 관리) 권한을 부여해야 하며 이는 AWS 공식 문서의 다른 계정 사용자의 KMS 키 사용 허용 지침을 통해 설정한다. 계정 간 권한 체계를 명확히 정의해야만 중앙 집중식 키 관리 구조를 유지하면서도 서비스 간 독립성을 확보할 수 있다.

KMS 키가 설정된 대기 기간을 지나 영구 삭제되면 IdP에 등록해 둔 대응 공개키를 반드시 함께 제거하거나 교체해야 한다. IdP는 등록된 공개키를 통해 서명을 검증하므로 AWS KMS에서 키가 사라졌음에도 IdP에 공개키가 남아 있으면 인증 시도 시 불필요한 오류가 발생하거나 보안 허점이 생길 수 있다. 특히 키 교체 주기가 짧은 금융권이나 공공기관 환경에서는 KMS의 키 로테이션 주기와 IdP의 공개키 업데이트 시점을 동기화하는 자동화 프로세스가 중요하다. 키의 생명주기와 외부 인증 제공자의 신뢰 설정을 일치시키는 운영 절차를 갖춰야 인증 장애를 방지할 수 있다.

공유 비밀키를 코드나 설정 파일에 저장해 관리하던 기존 방식은 유출 시 모든 권한이 탈취되는 위험이 있으며 주기적인 수동 교체 부담이 크다. 따라서 비밀키 노출 위험이 높은 환경일수록 자격 증명을 직접 다루지 않는 Secret-less(비밀키 없는) 아키텍처로의 전환을 우선적으로 고려해야 한다. 실무자는 Entra 및 Okta IdP 등록 과정과 시스템 간 인증을 위한 M2M(기계 간 통신) 및 사용자 권한을 위임받는 OBO(대리 인증) 흐름이 포함된 Amazon Bedrock AgentCore GitHub 샘플 코드를 통해 실제 구현 경로를 확인할 수 있다. 해당 샘플 코드는 https://github.com/aws-samples/amazon-bedrock-agentcore-samples 주소에서 제공되며 이를 통해 기업의 기존 인증 정책을 어떻게 AWS KMS 서명 방식으로 대체할 수 있는지 검토 가능하다.

AWS CloudTrail(클라우드 트레일)로 모든 인증 시도를 감사하고 비밀키를 직접 관리하거나 노출할 필요가 없는 Secret-less 인증 체계를 구축하는 것이 실무적인 도입 기준이다.