ID-JAG The Hard Way: 실패로 배우는 AI 에이전트 보안 핸즈온
AI 에이전트의 API 접근에는 단순한 사용자 인증을 넘어, 에이전트가 특정 사용자를 대신해 정해진 범위의 작업만 수행하도록 통제하는 위임 인가가 필요하다. 글은 OAuth 기반 프로필인 ID-JAG를 활용해 Keycloak, Athenz, MCP 서버, 리소스 서버가 연계되는 전체 흐름을 로컬 핸즈온으로 재현한다. 특히 인증 정보와 실제 접근 권한을 분리하고, 기업 정책에 따라 실패 지점을 명확히 차단하는 중앙 집중형 인가 구조를 강조한다. ## ID-JAG가 해결하려는 문제 - ID-JAG는 다음 OAuth 표준을 결합해 위임된 크로스 도메인 API 접근을 지원한다. - OAuth 2.0 Token Exchange(RFC 8693) - JWT Profile for OAuth 2.0 Authorization Grants(RFC 7523) - 기존의 “사용자가 누구인가?”라는 인증 중심 질문을 다음과 같이 확장한다. - AI 에이전트가 현재 사용자를 대신해 특정 리소스에 접근할 권한이 있는가? - 요청된 권한 범위와 기업 정책을 충족하는가? - AI 에이전트에 영구적이고 포괄적인 권한을 주면 오작동이나 공격 시 피해 범위가 커지고, 사용자의 의도와 에이전트의 자율 행동을 구분하기 어렵다. - 모든 API 호출마다 사용자의 동의를 요구하면 자동화와 사용자 경험이 훼손된다. - ID-JAG는 임시 토큰 연결 대신, 정책에 기반한 명시적 위임과 중앙 집중형 신뢰 관계를 제공한다. ## 데모 아키텍처와 역할 분리 핸즈온에서는 인증과 인가 정책을 의도적으로 분리한다. - **Keycloak** - 사용자를 인증하는 업스트림 IdP다. - 로그인 결과로 원본 ID 어서션을 발급한다. - **Athenz** - KeycloakTokenExchangePlugin을 통해 연동된 IdP 인가 서버로 동작한다. - Keycloak 토큰의 발급자, 서명, 대상, 주체, 클라이언트 바인딩을 검증한다. - 기업 정책을 평가하고 최종 ID-JAG 어서션을 발급한다. - 중앙 리소스 인가 서버이자 정책 결정 지점(PDP) 역할을 한다. - **AI 에이전트** - 사용자를 대신해 ID-JAG와 액세스 토큰을 요청한다. - 장기 마스터 키가 아니라 정책으로 제한된 임시 권한을 사용한다. - **MCP 서버** - 에이전트가 호출하는 보호된 중간 리소스 서버다. - 전달받은 토큰을 인가 서버와 교환한 뒤 최종 리소스 서버에 접근한다. - **리소스 서버** - Athenz가 발급한 신뢰 가능한 토큰만 수용한다. - 업스트림 IdP의 토큰을 무조건 인가 그랜트로 인정하지 않는다. ## ID-JAG 실행 흐름 실습 환경에서는 다음 순서로 위임 접근이 진행된다. - 사용자가 Keycloak을 통해 로그인한다. - 사용자가 AI 에이전트에 작업을 지시한다. - 에이전트가 Athenz에 ID-JAG 토큰을 요청한다. - Athenz가 사용자, 클라이언트, 대상 리소스, 권한 범위 및 기업 정책을 검증한다. - 허용된 경우 에이전트가 Athenz에 액세스 토큰을 요청한다. - 에이전트가 액세스 토큰을 포함해 MCP 서버를 호출한다. - MCP 서버가 토큰 교환을 수행한다. - 교환된 토큰으로 최종 리소스 서버에 요청한다. 이 구조에서는 인증된 사용자라는 사실만으로 모든 리소스 접근이 허용되지 않으며, 각 단계에서 위임 범위와 정책을 다시 확인한다. ## 인증 토큰과 인가 그랜트의 분리 Keycloak의 ID 토큰을 곧바로 액세스 토큰으로 교환하는 방식도 기술적으로는 가능하지만, 보안 모델상 한계가 있다. - **ID 토큰** - 사용자가 클라이언트에 성공적으로 인증됐음을 나타낸다. - 특정 리소스에 접근할 권리를 직접 의미하지 않는다. - **인가 그랜트** - 특정 리소스와 권한 범위에 대한 액세스 토큰 발급을 요청하기 위해 인가 서버에 제출된다. - ID-JAG를 별도의 인가 그랜트로 사용하면 다음 실패 유형을 구분할 수 있다. - 사용자 인증 실패 - 그랜트 검증 실패 - 에이전트 위임 거부 - 기업 정책 거부 - 리소스 서버의 토큰 거부 - 이 경계는 장애 분석과 감사 추적을 명확하게 만들고, 로그인 성공이 곧 크로스 도메인 API 접근 권한으로 오해되는 것을 방지한다. ## 실패 경로를 통한 보안 검증 핸즈온은 정상 동작뿐 아니라 의도적인 설정 오류를 통해 정책 경계를 확인하도록 구성된다. - 토큰 없이 보호된 API를 호출하면 `401 Unauthorized`가 발생한다. - 엔터프라이즈 역할만 설정하고 멤버십을 누락하면 토큰 교환이 실패한다. - 에이전트에 필요한 위임 권한을 부여하지 않으면 위임 호출이 차단된다. - 각 오류는 인증, 역할, 멤버십, 위임 정책, 토큰 교환 중 어느 단계가 필요한지 보여준다. - Athenz UI에서 에이전트의 위임 권한을 제거한 뒤 다시 실행하면 차단이 발생하는 지점을 직접 추적할 수 있다. ## 중앙 정책 관리의 장점 - 기업의 위임 정책을 Athenz 한 곳에서 관리할 수 있다. - 여러 IdP, SaaS, 리소스 애플리케이션에 정책을 중복 배포할 필요가 줄어든다. - 벤더별 인가 로직에 대한 종속을 완화할 수 있다. - 시스템 간 정책 불일치와 운영상의 보안 위험을 줄인다. - Athenz가 ID-JAG 발급자이자 PDP로 기능하면서, 위임 API 접근에 대한 단일 진실 공급원이 된다. ## 실습 방법과 권장 사항 - `athenz-community/id-jag-the-hard-way` 저장소에서 튜토리얼을 실행한다. - 정상 흐름뿐 아니라 의도적으로 역할, 멤버십, 위임 권한을 제거해 실패 지점을 확인하는 것이 중요하다. - 실제 기업 환경에서는 인증 성공 여부와 별도로 리소스·권한·에이전트·정책을 명시적으로 검증해야 한다. - AI 에이전트 도입 시 장기 자격 증명 대신 제한된 범위의 단기 토큰과 중앙 정책 평가를 사용하는 방식을 권장한다.
원문 읽기(새 탭에서 열림)