Amazon AWS, AgentCore Identity에 Private Key JWT 추가…공유 시크릿을 KMS 제어로 전환

Amazon AWS가 AgentCore Identity에 Private Key JWT 인증을 추가하며, 자동화된 에이전트에 장기 유지형 OAuth 클라이언트 시크릿의 새로운 대안을 제공했다. 이 변화는 클라이언트 인증을 AWS Key Management Service가 지원하는 단기 서명 어설션 방식으로 전환한다. 또한 각 서명 요청에 대한 더 명확한 기록을 AWS CloudTrail에 남긴다.

이 조합이 중요한 이유는 자율 에이전트가 일반적인 직원용 애플리케이션보다 훨씬 더 자주 토큰을 요청할 수 있기 때문이다. 복사된 클라이언트 시크릿은 누군가 이를 교체하거나 폐기할 때까지 계속 사용할 수 있다. 반면 Private Key JWT 어설션은 빠르게 만료되며, 새 요청마다 보호된 서명 키에 접근해야 한다.

핵심 쟁점은 단순히 키와 비밀번호의 대결이 아니다. Amazon Bedrock AgentCore Identity는 개발자가 자체 서명 서비스를 구축하고 운영하지 않아도 더 강력한 제어를 제공하겠다고 약속한다. 이 약속이 실현되는지는 ID 공급자 호환성, 정확한 클레임 구성, KMS 권한, 완전한 감사 범위에 달려 있다.

Amazon AWS, OAuth 클라이언트 인증을 KMS로 이전

핵심 변화는 AgentCore Identity가 재사용 가능한 클라이언트 시크릿을 저장하지 않고도 OAuth 클라이언트를 인증할 수 있게 됐다는 점이다.

Private Key JWT 발표에서 설명한 새 패턴에서는 AgentCore Identity가 JSON Web Token을 생성하고 AWS KMS를 통해 서명한다. ID 공급자는 이에 대응하는 공개 키로 해당 서명을 검증한다.

개인 키는 KMS 내부에 남아 있다. 에이전트, 애플리케이션 프로세스, 관리자 모두 이 키를 구성 파일, 컨테이너 이미지, 환경 변수 또는 별도 시크릿 저장소로 내보낼 필요가 없다.

서명된 JWT는 클라이언트 어설션으로, OAuth 클라이언트의 ID를 인가 서버에 증명한다는 의미다. 이는 최종적으로 API에 제시되는 액세스 토큰이 아니다. 인가 서버는 액세스 토큰을 발급하기 전에 어설션을 검증한다.

이 구분은 놓치기 쉽다. OAuth 클라이언트 인증은 토큰을 요청하는 애플리케이션이 등록된 클라이언트인지 확인한다. OAuth grant는 결과 토큰이 누구의 권한을 나타내는지, 어떤 권한을 받는지를 결정한다.

따라서 Private Key JWT는 둘 이상의 grant flow에서 작동할 수 있다. AgentCore Identity는 authorization code grant를 통한 사용자 위임 액세스와 client credentials를 통한 머신 간 액세스를 지원한다. 더 폭넓은 authentication patterns에는 on-behalf-of 토큰 교환 구성도 포함된다.

사용자 위임 요청에서는 먼저 사용자가 ID 공급자를 통해 액세스를 승인한다. 이후 AgentCore Identity는 authorization code를 토큰으로 교환할 때 OAuth 클라이언트를 인증한다. 사용자의 승인과 클라이언트 ID는 별개의 제어 수단으로 유지된다.

머신 간 요청에서는 사용자가 대화형 동의 화면을 완료하지 않는다. 에이전트는 애플리케이션 자체 권한으로 액세스 토큰을 요청한다. Private Key JWT는 client credentials 교환 과정에서 해당 애플리케이션을 인증한다.

이 때문에 이 기능은 로그인 이상의 영역에서 의미가 있다. 에이전트가 엔터프라이즈 API, 소프트웨어 서비스 및 기타 보호된 리소스에 외부로 접근하는 상황을 겨냥한다. 바로 이런 연결에서 정적 자격 증명이 운영상 부담이 될 수 있다.

AgentCore Identity는 이미 에이전트, 인가 서버, 리소스 서버 사이의 중개자 역할을 한다. 장기 시크릿과 refresh token을 에이전트 코드에서 분리한 채 자격 증명을 가져온다. Private Key JWT는 이 경계를 OAuth 클라이언트의 인증 자격 자료까지 확장한다.

이제 요청 경로에는 여러 명시적 단계가 있다. 에이전트가 AgentCore Identity에 인가된 액세스를 요청한다. AgentCore Identity는 시간 제한이 있는 어설션을 생성하고, KMS를 호출해 서명한 뒤 이를 ID 공급자의 토큰 엔드포인트로 전송한다.

ID 공급자는 등록된 공개 키를 기준으로 서명을 확인한다. 또한 클라이언트 ID, audience, 발행 시각, 만료 시각을 식별하는 클레임을 평가한다. 이 검사가 통과되면 공급자는 AgentCore Identity를 통해 액세스 토큰을 반환한다.

이 설계가 신뢰 자체를 없애는 것은 아니다. 신뢰를 KMS 정책, IAM 역할, OAuth 구성, ID 공급자의 공개 키 등록으로 이전한다. 이러한 제어 수단은 복사된 하나의 문자열보다 더 세분화돼 있지만, 불일치가 발생하면 인증을 중단시킬 수 있는 지점도 더 많아진다.

Private Key JWT가 시크릿 모델을 바꾸는 방식

Private Key JWT는 공유 시크릿 의존도를 낮추지만, 보안은 KMS에 서명을 요청할 수 있는 주체를 통제하는 데 달려 있다.

기존 OAuth 클라이언트 인증은 일반적으로 client_secret_basic 또는 client_secret_post를 사용한다. 두 방식 모두 클라이언트 ID와 공유 시크릿을 인가 서버에 전송한다. 차이는 해당 자격 증명이 HTTP Basic 헤더에 포함되는지, 요청 본문에 포함되는지다.

AWS 문서는 HTTP Basic을 커스텀 AgentCore Identity 공급자의 기본 방식으로 설명한다. 시크릿은 교체, 만료 또는 폐기 전까지 재사용 가능하다. 복사본을 보유한 모든 시스템이 해당 자격 증명의 보안 경계에 포함된다.

Private Key JWT는 이 대칭형 모델을 비대칭 키 쌍으로 대체한다. 한쪽은 개인 서명 키를 제어하고, ID 공급자는 공개 검증 키만 저장한다. 공개 키가 노출되더라도 공격자가 유효한 어설션을 생성할 수는 없다.

이 접근 방식은 클라이언트 인증과 인가 grant를 위한 JWT를 정의하는 OAuth JWT profile을 따른다. 토큰 요청에는 클라이언트 어설션이 포함되며, 이를 JWT bearer 어설션으로 식별한다.

일반적인 어설션에는 클라이언트를 식별하는 issuer 클레임, 해당 클라이언트를 위한 subject 클레임, 토큰 엔드포인트를 지정하는 audience 클레임이 포함된다. 또한 만료 및 발행 시각도 포함된다. 고유한 JWT 식별자는 ID 공급자가 재전송 공격 시도를 탐지하는 데 도움이 될 수 있다.

이 필드는 장식용 메타데이터가 아니다. audience가 잘못되면 올바르게 서명된 JWT도 무효가 될 수 있다. 시스템 시계 차이로 인해 공급자가 어설션을 아직 유효하지 않거나 이미 만료된 것으로 거부할 수 있다.

Private Key JWT 역시 재전송 방지를 자동으로 보장하지는 않는다. RFC 7523은 일부 재전송 방어를 배포 정책에 맡긴다. ID 공급자에는 적절한 수명 제한과 지원되는 경우 고유 어설션 추적이 필요하다.

짧은 만료 기간은 탈취된 어설션의 유효성을 제한한다. 하지만 공격자가 서명 키를 반복 호출할 권한을 가진 시스템을 보호하지는 못한다. 이것이 KMS 키 정책과 IAM 권한이 핵심 시행 계층이 되는 이유다.

AWS KMS는 비대칭 키를 연결된 공개 및 개인 키 쌍으로 표현한다. 서명 키의 경우 개인 구성 요소는 서비스 내부에서 보호된다. 공개 구성 요소는 다운로드해 외부 ID 공급자에 등록할 수 있다.

KMS는 서명 및 검증용 RSA 및 타원 곡선 키를 포함한 여러 asymmetric key types를 지원한다. 선택한 키 유형과 알고리즘은 ID 공급자가 허용하는 방식과 일치해야 한다.

AgentCore Identity는 구성된 키를 서명에 사용할 권한이 필요하다. AWS는 KMS Sign 작업의 호출자에게 키 정책을 통한 kms:Sign 권한이 필요하다고 설명한다. 이후 서비스는 개인 구성 요소를 반환하지 않고 이를 사용한다.

이는 의미 있는 격리 개선이다. 키 ARN을 노출하는 구성 유출만으로는 개인 키 자료가 드러나지 않는다. 공격자가 키를 호출하려면 여전히 AWS 자격 증명과 유효한 권한이 필요하다.

다만 서명 권한 자체는 민감하다. 광범위한 kms:Sign 액세스 권한을 가진 역할은 의도된 워크로드 경로 밖에서 서명을 요청할 가능성이 있다. 팀은 권한을 올바른 AgentCore 실행 역할에 연결하고, 일반적인 와일드카드 액세스를 피해야 한다.

이 변화는 키 교체에도 영향을 준다. 공유 시크릿에서는 양측이 동일한 기밀 값을 교체해야 한다. 비대칭 인증에서는 팀이 통제된 전환 과정에서 기존 검증 키를 유지한 채 ID 공급자에 새 공개 키를 도입할 수 있다.

ID 공급자가 여러 활성 키를 지원한다면 이러한 중첩은 다운타임을 줄일 수 있다. 공개 키를 하나만 허용한다면 키 교체에는 여전히 조율된 타이밍이 필요하다. Private Key JWT는 교체 대상 자료를 바꾸는 것이지, 검증된 키 교체 프로세스의 필요성을 없애는 것은 아니다.

지원되는 Grant Flow는 서로 다른 에이전트 ID에 대응한다

Private Key JWT는 OAuth 클라이언트를 인증하며, 선택한 grant는 에이전트가 자신을 위해 행동하는지 사용자를 위해 행동하는지를 결정한다.

authorization code grant는 개인을 대신해 리소스에 접근하는 에이전트에 적합하다. 사용자는 ID 공급자를 통해 로그인하고 요청된 권한을 승인한다. 인가 서버는 클라이언트가 토큰으로 교환할 수 있는 코드를 반환한다.

이 교환 과정에서 AgentCore Identity는 Private Key JWT 어설션을 사용해 등록된 클라이언트가 요청을 보내고 있음을 증명한다. 이 어설션은 사용자 동의를 대체하지 않는다. 토큰 엔드포인트에서의 인증을 강화한다.

이 흐름은 사용자의 캘린더를 읽거나, 직원에게 인가된 레코드를 검색하거나, 위임된 권한 안에서 고객 관리 시스템을 업데이트하는 에이전트에 적합하다. 결과 액세스는 사용자 및 승인된 scope와 계속 연결된다.

client credentials grant는 다른 사례를 다룬다. 여기서 워크로드는 대화형 사용자 없이 자신을 위해 동작한다. 예약된 에이전트는 내부 재고 API를 호출하거나, 서비스 알림을 처리하거나, 승인된 운영 데이터를 가져올 수 있다.

Private Key JWT는 인가 서버가 애플리케이션 토큰을 발급하기 전에 해당 머신 클라이언트를 인증한다. 사용자가 없기 때문에 클라이언트 ID, 토큰 scope, 다운스트림 인가 정책이 보안 부담의 더 큰 부분을 맡는다.

조직은 두 grant를 서로 바꿔 쓸 수 있는 배포 옵션으로 간주해서는 안 된다. 사용자 ID를 유지해야 하는 작업에 client credentials를 사용하면 책임 추적이 불명확해질 수 있다. 백그라운드 서비스 작업에 위임 흐름을 사용하면 개인 계정에 취약하게 의존할 수 있다.

On-behalf-of 액세스는 또 다른 변형을 도입한다. 에이전트는 기존 사용자 ID의 증거를 받아 다른 리소스에 적합한 토큰으로 교환한다. 이 흐름은 사용자, 에이전트, 대상 서비스 간의 관계를 보존해야 한다.

AgentCore Identity 문서는 이러한 사례에 대해 표준 토큰 교환과 JWT 기반 authorization grant 접근 방식을 모두 설명한다. 지원 여부는 여전히 외부 인가 서버와 해당 서버의 토큰 교환 규칙에 달려 있다.

Private Key JWT는 해당 교환에 참여하는 클라이언트를 인증할 수 있다. 들어오는 사용자 토큰이 유효한지, 요청된 위임을 허용해야 하는지는 결정하지 않는다. 이러한 결정은 관련 ID 및 인가 시스템에 남아 있다.

이러한 분리는 이 기능의 가장 강력한 아키텍처상 장점 중 하나다. 팀은 에이전트에 필요한 권한을 기준으로 grant를 선택한 뒤, 클라이언트가 자신의 ID를 증명할 방식을 기준으로 Private Key JWT를 선택할 수 있다.

또한 하나의 “에이전트 자격 증명”이라는 사고방식이 안전하지 않은 이유도 부각한다. 에이전트는 워크로드 ID를 가질 수 있고, 사용자를 대신해 동작하며, 여러 리소스 서버를 호출하고, 각 대상에 서로 다른 토큰을 사용할 수 있다.

AgentCore Identity의 워크로드 액세스 토큰은 또 하나의 계층을 추가한다. AWS에 따르면 에이전트가 볼트에서 자격 증명을 요청할 때 이 토큰에는 에이전트의 ID와 최종 사용자의 ID가 포함될 수 있다. AgentCore Runtime은 호스팅된 에이전트에 이를 자동으로 제공할 수 있다.

이 워크로드 토큰은 AgentCore Identity에 대한 액세스를 승인한다. 외부 OAuth 액세스 토큰은 대상 API에 대한 액세스를 승인한다. Private Key JWT assertion은 토큰 발급 과정에서 OAuth 클라이언트를 인증한다.

따라서 하나의 엔드투엔드 트랜잭션에 서로 다른 역할을 수행하는 세 가지 토큰이 나타날 수 있다. 이를 혼동하면 잘못된 검증, 과도한 로깅 또는 의도치 않은 노출로 이어질 수 있다.

보안 검토에서는 각 토큰을 발급자, 대상, 보유자, 수명, 목적지에 따라 매핑해야 한다. 또한 어떤 구성 요소가 이를 갱신하거나 교체할 수 있는지도 식별해야 한다. 이 작업은 제품 수준 다이어그램에서 숨겨질 수 있는 설계 오류를 찾아낸다.

더 광범위한 경쟁 압력은 시크릿 기반 에이전트 통합에 가해진다. 정적 클라이언트 시크릿은 익숙하고 폭넓게 지원되지만, 많은 자율 워크로드에 각각 독립적인 권한과 감사 추적이 필요할 때는 확장성이 떨어진다.

Private Key JWT는 설정 부담을 높이는 대신 자격 증명 중복을 줄인다. 이미 AWS IAM, KMS, CloudTrail을 운영하는 팀에는 이러한 교환 조건이 매력적일 수 있다. 규모가 작은 배포 환경에서는 추가 정책 관리 범위가 즉각적인 이점을 웃돌 수 있다.

신뢰 체인 구성은 방식 선택만으로는 충분하지 않다

설정이 성공하려면 KMS, IAM, AgentCore Identity, 외부 ID 공급자가 동일한 암호화 및 OAuth 세부 사항에 합의해야 한다.

첫 번째 요구 사항은 서명과 검증용으로 구성된 비대칭 KMS 키다. 암호화 키는 이 작업을 수행할 수 없다. 키 사양과 서명 알고리즘은 대상 ID 공급자가 허용하는 조합과 일치해야 한다.

AWS KMS는 비대칭 서명 키의 공개 부분을 노출한다. 팀은 이 공개 키를 ID 공급자에 직접 등록하거나, 지원되는 JSON Web Key 구성을 통해 등록한다.

ID 공급자는 해당 키를 올바른 OAuth 클라이언트와 연결해야 한다. 또한 토큰 엔드포인트에서 Private Key JWT를 지원해야 한다. 등록 인터페이스와 허용 알고리즘은 공급자마다 다르므로, 이 단계는 여전히 공급자별로 진행된다.

다음으로 관리자는 Amazon Bedrock AgentCore 콘솔에서 사용자 지정 OAuth 자격 증명 공급자를 만들거나 업데이트한다. 구성에는 공급자의 디스커버리 정보, 클라이언트 식별자, KMS 키 ARN, 서명 알고리즘이 필요하다.

OAuth 디스커버리를 통해 AgentCore Identity는 공급자 메타데이터에서 인증 및 토큰 엔드포인트를 찾을 수 있다. 팀은 검색된 토큰 엔드포인트가 ID 공급자가 요구하는 audience 값과 일치하는지 확인해야 한다.

AgentCore Identity에는 KMS 호출 권한도 필요하다. KMS 서명 작업에는 SIGN_VERIFY 용도의 키와 해당 키에 호환되는 알고리즘이 필요하다.

KMS는 선택한 메시지 유형에 따라 원본 메시지나 미리 계산된 다이제스트를 받는다. 외부 검증은 알고리즘에 지정된 해싱 동작을 전제로 하므로, JWT 구현은 의도치 않은 이중 해싱을 피해야 한다.

JWT 헤더 구성도 중요하다. ID 공급자는 키 식별자를 사용해 적절한 공개 키를 선택할 수 있다. 식별자가 없거나 잘못되면 여러 공개 키가 활성화될 수 있는 로테이션 과정에서 특히 문제가 된다.

페이로드 클레임도 동일한 수준의 주의가 필요하다. issuer와 subject는 일반적으로 OAuth 클라이언트 ID에 해당한다. audience는 보통 인증 서버의 토큰 엔드포인트를 식별하지만, 정확한 값은 공급자 요구 사항에 따라야 한다.

만료 시간은 짧게 유지해야 한다. 발급 시간은 동기화된 시계를 반영해야 한다. 공급자가 이전에 수락된 assertion을 기록하는 경우에는 고유한 토큰 식별자가 유용하다.

자격 증명 공급자를 저장한 뒤에는 각 의도한 grant를 독립적으로 테스트해야 한다. 클라이언트 자격 증명 요청이 성공했다고 해서 authorization code 교환이나 토큰 교환이 올바르게 구성되었다는 뜻은 아니다.

테스트는 최소 범위의 scope로 시작해야 한다. 인증에는 성공했지만 인가에 실패한 경우, 문제의 구분이 더 쉬워진다. 오류를 우회하려고 광범위한 권한을 추가하면 audience 또는 클라이언트 등록 문제를 가릴 수 있다.

팀은 부정 경로도 테스트해야 한다. 잘못된 키로 서명한 요청은 실패해야 한다. 만료된 assertion도 실패해야 한다. 잘못된 audience와 권한 없는 KMS 호출자는 각각 구별 가능한 증거를 남겨야 한다.

이 지점에서 운영상의 교환 조건이 드러난다. 공유 시크릿은 단순해서 팀이 정상 경로만 검증하는 경우가 많다. Private Key JWT는 더 강한 경계를 제공하지만, 그 경계에는 명시적인 테스트가 필요하다.

이 구성은 관리 팀 간의 종속성도 만든다. 클라우드 보안 팀이 KMS와 IAM 정책을 소유할 수 있다. ID 팀은 OAuth 클라이언트와 공개 키 등록을 통제할 수 있다.

애플리케이션 소유자는 AgentCore Identity를 구성하고 grant scope를 결정한다. 감사 팀은 보존 및 경고가 필요한 CloudTrail 레코드를 정한다. 어느 한 콘솔의 선택만으로는 이러한 소유권 문제를 해결할 수 없다.

유용한 도입 방식은 중요하지 않은 통합 하나로 시작하는 것이다. 팀은 이 방식을 많은 에이전트에 적용하기 전에 클레임 요구 사항, 실패 응답, 로테이션 단계, 에스컬레이션 책임을 문서화할 수 있다.

자동화는 최초로 검증된 배포 이후에 따라와야 한다. 인프라 템플릿은 키 정책과 자격 증명 공급자 설정을 표준화할 수 있지만, ID 공급자의 동작을 추측해서는 안 된다.

그 결과는 시크릿이 전혀 없는 시스템이 아니다. 토큰은 여전히 존재하고, 인증 서버는 여전히 신뢰를 보유하며, AWS 권한 역시 자격 증명으로 남는다. 더 방어 가능한 주장은 OAuth 클라이언트가 더 이상 공유되고 재사용 가능한 시크릿에 의존하지 않는다는 것이다.

CloudTrail은 모든 서명을 감사 신호로 전환한다

KMS 기반 서명은 방어자가 토큰 요청 및 에이전트 활동과 연관 지을 수 있는 AWS 측 이벤트를 제공한다.

AWS KMS는 CloudTrail과 통합되며, CloudTrail은 사용자, 역할, AWS 서비스가 수행한 호출을 기록한다. KMS 감사 로깅에는 암호화 작업과 키 관리 작업이 모두 포함된다.

따라서 Private Key JWT 트랜잭션은 KMS 서명 요청에 관한 증거를 생성해야 한다. 이 이벤트는 관련 작업, 리전, 시간, 키, 그리고 관련 AWS 주체 또는 서비스 컨텍스트를 식별할 수 있다.

그러나 이 기록만으로 전체 상황을 알 수는 없다. CloudTrail은 권한을 가진 AWS ID가 서명을 요청했다는 사실을 보여준다. 외부 ID 공급자의 로그는 assertion을 수락하고 토큰을 발급했는지를 보여준다.

대상 서비스의 감사 로그는 결과로 나온 액세스 토큰이 수행한 작업을 보여준다. 효과적인 조사는 KMS 이벤트를 리소스 액세스 성공의 증거로 간주하지 않고, 이 세 계층을 모두 연관 분석한다.

CloudTrail은 여전히 중요한 질문에 답할 수 있다. 조사자는 예상치 못한 서명량, 잘못된 역할의 요청, 승인되지 않은 리전의 호출, 또는 정상 일정에서 벗어난 키 관련 활동을 찾을 수 있다.

구성된 이벤트 선택기도 중요하다. AWS는 KMS 이벤트를 관리 이벤트로 분류하며, CloudTrail trail은 일반적으로 관리 활동을 기록한다. 하지만 관리자는 KMS 이벤트를 명시적으로 제외할 수 있다.

AWS는 KMS 작업이 많은 이벤트 볼륨을 생성할 수 있다고 경고한다. 일부 조직은 로깅 볼륨을 제어하기 위해 이를 필터링한다. 그렇게 하면 이 인증 패턴의 감사 용이성을 높이는 바로 그 서명 증거가 사라질 수 있다.

Private Key JWT를 도입하는 팀은 관리 이벤트 설정을 검토해야 한다. 관련 KMS 활동이 의도한 trail 또는 이벤트 데이터 스토어에 도달하는지 확인해야 한다.

보존 기간과 검색 가능성도 중요하다. 이벤트 기록은 최근 조사에 유용하며, trail 또는 CloudTrail Lake 이벤트 데이터 스토어는 더 장기적인 분석을 지원한다. 내보낸 레코드는 보안 모니터링 시스템에도 공급할 수 있다.

기준선은 예상되는 토큰 갱신 동작과 이상 징후를 구분해야 한다. 지속적으로 실행되는 머신 에이전트는 일정한 주기로 assertion에 서명할 수 있다. 사용자 위임 워크플로는 활성 세션 중에 급증을 일으킬 수 있다.

큰 편차는 재시도 루프, 구성 실패 또는 자격 증명 오용을 나타낼 수 있다. 서명이 반복된 뒤 토큰 엔드포인트에서 거부된다면 잘못된 audience, 만료된 공개 키 또는 시계 문제를 가리킬 수 있다.

상응하는 AgentCore 요청 없이 발생하는 서명 활동은 더 면밀한 조사가 필요하다. 예상된 다운스트림 호출 없이 토큰이 성공적으로 발급되는 경우도 마찬가지다. 각 패턴은 신뢰 체인의 서로 다른 단절을 식별한다.

키 수명 주기 이벤트에는 별도의 경고가 필요하다. 서명 키를 비활성화하면 종속된 모든 통합이 중단될 수 있다. 정책 변경은 호출 권한이 있는 주체의 범위를 조용히 확장할 수 있다.

CloudTrail은 로테이션 과정에도 도움이 된다. 팀은 새 키가 활성화된 이후에도 이전 키가 계속 서명 요청을 받는지 관찰할 수 있다. 지속적인 활동은 간과된 자격 증명 공급자나 지연된 배포를 드러낼 수 있다.

하지만 감사 가시성에는 조건이 따른다. 로그는 활성화, 보존, 보호, 검토되어야 한다. 기록되었지만 한 번도 조회되지 않은 이벤트는 실질적인 방어 효과가 거의 없다.

CloudTrail 이벤트는 요청의 비즈니스상 이유도 검증하지 않는다. 적절한 권한을 가진 에이전트라도 잘못된 시점에 액세스 토큰을 요청하거나 지나치게 광범위한 작업에 이를 사용할 수 있다.

이러한 한계는 인가 설계에 주의를 돌리게 한다. Private Key JWT는 클라이언트가 서명 키에 대한 액세스를 통제한다는 점을 증명할 수 있다. 하지만 에이전트의 목표, 선택한 도구 또는 요청한 작업이 적절한지는 판단할 수 없다.

조직은 암호학적 증명 주위에 scope 제한, 리소스 서버 정책, 워크로드 제어, 행동 모니터링을 구축해야 한다. 서명은 고품질 신호 중 하나일 뿐, 완전한 에이전트 거버넌스 시스템은 아니다.

Private Key JWT 출시 이후 기업이 주시해야 할 사항

다음 시험대는 Private Key JWT가 운영상의 기본값이 될지, 아니면 엄격히 관리되는 배포를 위한 고급 옵션으로 남을지다.

첫 번째 신호는 ID 공급자 상호 운용성이다. 성공적인 도입을 위해서는 공급자가 선택된 서명 알고리즘, 클레임, audience 형식, 공개 키 등록 방식을 수락해야 한다.

AWS는 교환 과정에서 자사 측을 단순화할 수 있지만, 모든 공급자의 관리 워크플로를 표준화할 수는 없다. 명확하고 공급자별로 구체적인 예시는 실패한 배포와 안전하지 않은 우회책을 줄일 수 있다.

두 번째 신호는 로테이션 동작이다. 기업은 중복된 공개 키를 등록할 수 있는지, 중단 없이 AgentCore 공급자를 업데이트할 수 있는지, 감사 레코드를 통해 마이그레이션을 확인할 수 있는지를 알아야 한다.

초기 설정에서만 작동하는 기능은 문제의 절반만 해결한다. 프로덕션 인증에는 키가 비활성화, 교체 또는 손상되었을 때 예측 가능한 복구도 필요하다.

세 번째 신호는 감사 도입이다. CloudTrail은 팀에 서명 레코드에 대한 액세스를 제공하지만, 조직은 KMS 이벤트를 보존하고 이를 ID 공급자 및 리소스 서버 로그와 연결해야 한다.

탐지 지침은 이 기능의 유용성을 높일 수 있다. 높은 서명 빈도, 익숙하지 않은 주체, 반복 오류, 예상치 못한 리전 활동은 경고의 실용적인 후보이다.

보안 팀은 AgentCore Identity 권한 모델의 경계도 주시해야 한다. 이상적인 정책은 관련 없는 서명 액세스를 부여하지 않으면서 하나의 워크로드가 승인된 하나의 공급자에 대해 하나의 서명 키를 사용하도록 허용한다.

교차 계정 키는 유연성을 더하지만 신중한 리소스 정책이 필요하다. AWS KMS는 호출자가 키 ARN을 지정하고 필요한 권한을 받을 때 서명용 교차 계정 사용을 지원한다.

이 기능은 보안 책임을 중앙에서 관리하는 데 도움이 될 수 있습니다. 동시에 애플리케이션 계정과 중앙 ID 계정 간의 종속성을 만들 수도 있습니다. 중앙 계정의 장애나 정책 실수는 많은 에이전트에 영향을 미칠 수 있습니다.

기업은 암호화 설계가 성공을 보장한다고 가정하기보다 운영 결과를 측정해야 합니다. 유용한 지표로는 시크릿 교체 작업량, 토큰 요청 실패, 권한 없는 서명 시도, 키 변경 후 복구 시간 등이 있습니다.

또한 Private Key JWT를 AWS IAM 서명 JWT 인증과 비교해야 합니다. AgentCore Identity 문서는 IAM에서 발급한 어설션을 사용하고, 인증 서버가 AWS IAM을 신뢰해야 하는 AWS_IAM_ID_TOKEN_JWT 방식을 설명합니다.

두 접근 방식 모두 공유 클라이언트 시크릿에서 벗어나지만, 신뢰를 설정하는 방식은 다릅니다. Private Key JWT는 ID 공급자가 고객이 관리하는 공개 키를 신뢰하도록 합니다. IAM 방식은 ID 공급자가 발급자로서 AWS IAM을 신뢰하도록 합니다.

실질적으로 어떤 경로를 선택할지는 제공업체 지원 여부가 결정하는 경우가 많습니다. 일부 ID 시스템은 이미 기밀 OAuth 클라이언트를 위한 Private Key JWT를 지원합니다. 반면 AWS IAM 발급자를 직접 수용하도록 구성된 시스템은 더 적을 수 있습니다.

따라서 Private Key JWT는 유용한 중간 지점에 위치합니다. 표준 OAuth 인증 방식을 적용하면서도, 비공개 서명 자료는 KMS의 통제 아래 유지합니다.

이 기능의 더 넓은 의미는 에이전트를 다루는 방식에 있습니다. 플랫폼은 에이전트에 재사용 가능한 자격 증명을 제공하는 대신, 액세스가 필요할 때 제한적으로 승인된 암호화 작업을 수행합니다.

이 패턴은 복사된 구성 데이터의 가치를 낮춥니다. 또한 모든 토큰 요청에 대해 강제 가능한 점검 지점을 만듭니다. 이는 빈번하게 작동하고 감독이 제한적인 자율 워크로드에 실질적인 개선입니다.

그 대가로 구성의 정밀성이 더 중요해집니다. 팀은 알고리즘, 공개 키, JWT 클레임, IAM 정책, OAuth 권한 부여, 토큰 범위, 로깅 제어를 일치시켜야 합니다.

Amazon AWS는 서명 기능을 AgentCore Identity에 통합해 이러한 복잡성을 더 관리하기 쉽게 만들었습니다. 그러나 그에 수반되는 신뢰 결정까지 사라지게 하지는 않았습니다.

이 방식을 광범위하게 도입하기 전에 대표 에이전트 하나를 선택해 전체 액세스 경로를 추적하세요. 관련된 모든 주체, 토큰, 권한 부여, 범위, 로그 소스, 폐기 메커니즘을 식별해야 합니다.

그다음 성공적인 인증뿐 아니라 교체와 실패도 테스트하세요. 팀이 각 서명을 누가 요청했으며 그 이후 무엇이 발생했는지 설명할 수 있다면, Private Key JWT는 단순히 시크릿을 대체하는 수준을 넘어섭니다.