게이트웨이를 통해 Azure OpenAI 서비스에 사용자 지정 인증 제공

Azure 네이티브 서비스를 통해 Azure OpenAI 서비스를 사용하는 지능형 애플리케이션은 원활한 사용자 인증 및 권한 부여를 제공합니다. 그러나 일부 시나리오는 복잡하며 다른 아키텍처 디자인이 필요합니다. 이러한 시나리오에는 Azure에서 호스트되지 않은 클라이언트 애플리케이션이 있고, 외부 ID 공급자를 사용하고, 동일한 Azure OpenAI 인스턴스에 액세스하는 여러 클라이언트를 배포하는 토폴로지가 포함됩니다. 이러한 시나리오에서 Azure OpenAI 앞에 게이트웨이를 도입하면 배포된 인스턴스에 일관된 인증을 보장하는 계층을 추가하여 보안을 크게 향상시킬 수 있습니다.

이 문서에서는 Azure OpenAI에 인증을 제공하는 주요 시나리오에 대해 설명합니다.

• 외부 ID 공급자를 통해 클라이언트 애플리케이션 인증

• 인증서를 통해 클라이언트 애플리케이션 인증

• 키를 통해 여러 클라이언트 애플리케이션을 인증하여 공유 Azure OpenAI 인스턴스에 액세스

• 여러 Azure OpenAI 인스턴스에 액세스하는 클라이언트 애플리케이션 인증

각 시나리오에서는 게이트웨이를 통합할 때 발생하는 과제와 이점에 대해 설명합니다.

외부 ID 공급자를 통해 클라이언트 애플리케이션 인증

이 아키텍처의 Visio 파일을 다운로드합니다.

시나리오 제약 조건

이 시나리오에는 다음과 같은 제약 조건이 있습니다.

• 클라이언트 애플리케이션은 Okta, Auth0 또는 소셜 ID 공급자와 같은 외부 OIDC(OpenID Connect) 지원 ID 공급자를 사용합니다.

• 클라이언트 애플리케이션은 Azure OpenAI 데이터 평면의 테넌트와 다른 Microsoft Entra 테넌트에 대해 인증합니다.

이러한 태그에 다음과 같은 제한 사항이 적용됩니다.

• 외부 OIDC 공급자 또는 Microsoft Entra ID에 대해 이미 인증되고 Azure OpenAI 인스턴스와 통합되는 기존 클라이언트 애플리케이션.

• 여러 ID 공급자에서 사용자를 일관되게 인증해야 하는 클라이언트 애플리케이션입니다.

Azure OpenAI에 직접 연결

이러한 시나리오의 클라이언트 애플리케이션이 게이트웨이를 사용하지 않고 Azure OpenAI에 직접 연결하는 경우 키 기반 인증을 사용하여 Azure OpenAI에 인증해야 합니다. 키 기반 인증에는 추가 보안 문제가 발생합니다. 키를 안전하게 저장하고 회전해야 하며 개별 모델 배포에 대해 다른 클라이언트 RBAC(역할 기반 액세스 제어) 구성을 제공할 수 없습니다.

게이트웨이 소개

이 아키텍처의 Visio 파일을 다운로드합니다.

게이트웨이는 다음과 같은 방법으로 이 시나리오의 문제를 해결합니다.

• 게이트웨이는 OAuth(Open Authorization)를 사용하여 기존 외부 ID 공급자를 통해 사용자를 인증합니다. 게이트웨이는 ID 공급자가 생성하는 JWT(JSON 웹 토큰)와 같은 인증된 사용자 액세스 토큰의 유효성을 검사합니다. 그런 다음 게이트웨이는 지원 Azure OpenAI 인스턴스에 대한 권한 부여를 부여합니다.

• 클라이언트 키를 관리할 필요가 없습니다. 이 방법은 키 기반 인증의 보안 위험을 제거합니다.

• 게이트웨이는 관리 ID를 사용하여 Azure OpenAI에 연결하여 최소 권한의 Azure RBAC를 통해 보안을 향상시킵니다.

이 시나리오에 대한 권장 사항

• ID 공급자의 애플리케이션 등록에 OAuth 범위를 추가하여 소비자에게 세분화된 권한을 사용하도록 설정합니다. 이러한 범위를 통해 클라이언트 애플리케이션은 Azure OpenAI에 대한 액세스를 포함하여 게이트웨이에서 특정 작업을 수행할 수 있는 권한을 요청할 수 있습니다.

• 인바운드 정책을 사용하여 API Management에 대해 이 시나리오를 구성합니다. 이 validate-jwt 정책을 사용하여 지원되는 JWT의 존재, 유효성 및 특성 값을 적용합니다.

이 시나리오에서 게이트웨이를 피해야 하는 이유

단일 지능형 애플리케이션이 Azure OpenAI에 액세스하는 경우 게이트웨이를 통하지 않고 앱 내에서 사용자 인증 및 권한 부여를 구성하는 것이 더 쉽습니다. 이 방법을 사용하여 Azure OpenAI를 사용하여 지능형 애플리케이션을 안전하게 인증하는 데 필요한 Azure RBAC를 할당합니다.

인증서를 통해 클라이언트 애플리케이션 인증

이 아키텍처의 Visio 파일을 다운로드합니다.

시나리오 제약 조건

이 시나리오에는 다음과 같은 제약 조건이 있습니다.

• 인증서를 사용하여 클라이언트 애플리케이션을 인증하려고 합니다.

• 클라이언트 애플리케이션은 Microsoft Entra ID 또는 다른 OIDC 공급자를 인증에 사용할 수 없거나 사용하지 않으려는 경우

• 클라이언트는 인증에 페더레이션 ID를 사용할 수 없거나 사용하지 않으려는 경우

이러한 태그에 다음과 같은 제한 사항이 적용됩니다.

• Azure OpenAI에 인증하는 클라이언트는 컴퓨터 또는 디바이스이며 사용자 상호 작용이 발생하지 않습니다.

• 조직에서는 보안 표준 및 규정 준수 규정 때문에 인증에 인증서를 사용해야 합니다.

• 클라이언트 인증서 사용을 포함하여 환경에 따라 인증할 수 있는 옵션을 여러 클라이언트 애플리케이션에 제공하려고 합니다.

Azure OpenAI에 직접 연결

Azure OpenAI는 클라이언트 인증 인증을 기본적으로 지원하지 않습니다. 게이트웨이 없이 이 시나리오를 지원하려면 지능형 애플리케이션이 사용자 및 API 키 또는 관리 ID에 대한 인증서 인증을 사용하여 Azure OpenAI 인스턴스에 대한 요청을 인증해야 합니다. 모든 클라이언트에서 인증서 인증 논리를 구현해야 합니다. 이 시나리오에서 키 기반 인증은 클라이언트에서 Azure OpenAI에 직접 연결하는 경우 위험 및 관리 오버헤드를 발생합니다.

게이트웨이 소개

이 아키텍처의 Visio 파일을 다운로드합니다.

클라이언트에서 클라이언트 인증 유효성 검사를 오프로드하는 게이트웨이를 이 아키텍처에 도입할 수 있습니다. 게이트웨이는 지능형 애플리케이션이 제공하는 클라이언트 디지털 인증서의 유효성을 검사하고 발급자, 만료 날짜, 지문 및 해지 목록을 확인합니다. 게이트웨이는 관리 ID를 사용하여 Azure OpenAI로 인증해야 합니다. 또한 게이트웨이는 Azure Key Vault를 사용하여 루트 CA(인증 기관)를 저장해야 합니다. 이 방법을 사용하여 클라이언트 인증서 유효성 검사를 중앙 집중화하여 유지 관리 오버헤드를 줄입니다.

게이트웨이는 이 시나리오에서 몇 가지 이점을 제공합니다.

• 액세스 키 대신 게이트웨이의 관리 ID를 사용하여 키를 도난당한 위험을 제거하고 키 회전의 유지 관리 부담을 줄입니다.

• 인증서 유효성 검사를 중앙 집중화하여 일관된 보안 정책을 사용하여 모든 지능형 애플리케이션에 대한 클라이언트 디지털 인증서를 평가할 수 있습니다.

• 인증서 유효성 검사를 게이트웨이로 오프로드하여 클라이언트 코드를 간소화할 수 있습니다.

이 시나리오에 대한 권장 사항

• 인증서의 유효성을 검사할 때 루트 CA 및 중간 인증서를 포함하여 전체 인증서 체인을 확인합니다. 전체 확인은 인증서의 신뢰성을 보장하고 무단 액세스를 방지합니다.

• 클라이언트 인증서를 정기적으로 회전 및 갱신하여 인증서 손상 위험을 최소화합니다. Key Vault를 사용하여 이 프로세스를 자동화하고 인증서를 최신 상태로 유지합니다. 게이트웨이에서 서비스 중단을 방지하기 위해 예정된 인증서 만료에 대한 경고를 설정합니다.

• 클라이언트와 서버가 서로를 인증하도록 mTLS(상호 전송 계층 보안)를 구현합니다. 이 전략은 추가 보안 계층을 제공합니다. mTLS를 적용하도록 게이트웨이를 구성하려면 적절한 정책 및 제약 조건을 설정합니다.

• API Management의 validate-client-certificate 정책을 사용하여 Azure Key Vault가 참조하는 클라이언트 인증서의 유효성을 검사합니다. 이 정책은 클라이언트 애플리케이션이 제공하는 클라이언트 인증서의 유효성을 검사하고 발급자, 만료 날짜, 지문 및 해지 목록을 확인합니다.

이 시나리오에서 게이트웨이를 피해야 하는 이유

클라이언트가 거의 없는 간단한 환경에서는 클라이언트에서 보안 및 인증서 관리를 처리하는 비용이 게이트웨이 도입의 복잡성을 더 능가할 수 있습니다. 또한 게이트웨이는 단일 실패 지점이 되고, 계층이 추가되어 대기 시간이 늘어나며, 사용자 지정 구현 대신 상용 솔루션을 선택하는 경우 공급업체 잠금으로 이어질 수 있습니다.

클라이언트 인증서 인증을 위한 게이트웨이를 구현하기 전에 특정 요구 사항, 리소스 가용성 및 애플리케이션의 중요도를 신중하게 평가해야 합니다.

키를 통해 여러 클라이언트 애플리케이션을 인증하여 공유 Azure OpenAI 인스턴스에 액세스

이 아키텍처의 Visio 파일을 다운로드합니다.

시나리오 제약 조건

이 시나리오에는 다음과 같은 제약 조건이 있습니다.

• 여러 클라이언트 애플리케이션이 공유 Azure OpenAI 인스턴스에 액세스합니다.
• 클라이언트는 인증을 위해 Microsoft Entra ID를 사용할 수 없거나 사용하지 않으려는 경우
• 클라이언트는 인증에 페더레이션 ID를 사용할 수 없거나 사용하지 않으려는 경우
• 클라이언트 애플리케이션에 키 기반 인증을 사용하려고 합니다.

이러한 태그에 다음과 같은 제한 사항이 적용됩니다.

• Azure, 온-프레미스 또는 다른 클라우드 공급자를 비롯한 여러 환경에 클라이언트 애플리케이션을 배포합니다.

• 조직은 다른 팀에 Azure OpenAI를 제공하고 각 팀에 대해 고유한 액세스 및 사용 제한을 설정해야 합니다.

Azure OpenAI에 직접 연결

Azure OpenAI는 공유 키를 통한 키 기반 인증을 지원합니다. Azure OpenAI는 기본 키와 보조 키를 노출합니다. 보조 키의 목적은 키 회전을 지원하는 것입니다. 클라이언트 ID 격리를 제공하지 않습니다. 이 시나리오에서 Azure OpenAI에 직접 여러 클라이언트를 인증하는 경우 각 클라이언트는 동일한 키를 공유합니다. 이 구현을 위해서는 다음과 같은 문제가 있습니다:

• 모든 클라이언트가 동일한 키를 공유하므로 특정 클라이언트에 대한 사용 권한을 취소할 수 없습니다.

• 동일한 Azure OpenAI 인스턴스 배포에서 서로 다른 모델에 다른 액세스 권한을 다른 클라이언트에 부여할 수 없습니다.

• 로깅 관점에서 한 클라이언트를 다른 클라이언트와 구분할 수 없습니다.

게이트웨이 소개

이 아키텍처의 Visio 파일을 다운로드합니다.

각 클라이언트 애플리케이션에 전용 키를 발급하는 게이트웨이를 이 아키텍처에 도입할 수 있습니다. API Management는 구독 개념을 사용하여 전용 클라이언트 키를 제공합니다. 게이트웨이는 관리 ID를 사용하여 Azure OpenAI로 인증해야 합니다.

게이트웨이는 이 시나리오에서 몇 가지 이점을 제공합니다.

• 다른 클라이언트에 영향을 주지 않고 단일 클라이언트 애플리케이션에 대한 액세스를 취소할 수 있습니다.

• 키를 회전하기 전에 모든 클라이언트의 키 구성을 업데이트할 필요가 없으므로 키 회전이 물류적으로 더 쉽습니다. 클라이언트 구성을 업데이트한 후 각 클라이언트에 대한 전용 키를 회전할 수 있습니다.

• 로깅 관점에서 각 클라이언트를 고유하게 식별할 수 있습니다.

• 게이트웨이는 각 클라이언트에 대해 속도 제한 및 할당량을 독립적으로 적용합니다.

이 시나리오에 대한 권장 사항

• API 요청과 관련된 메트릭에 대한 모니터링을 향상시킵니다. 게이트웨이에서 관리 ID를 사용하는 경우 Azure OpenAI 로그에서 사용자 및 클라이언트 애플리케이션의 추적 가능성이 향상되지 않습니다. 게이트웨이는 요청 클라이언트 및 사용자 ID와 같은 요청과 연결된 로깅을 제공해야 합니다.

• 게이트웨이를 통해 여러 클라이언트 애플리케이션 요청을 공유 Azure OpenAI 인스턴스로 라우팅할 때 게이트웨이가 클라이언트 ID에 따라 적절한 모델 배포에 대한 라우팅 결정을 내리는지 확인합니다. 자세한 내용은 여러 Azure OpenAI 배포 앞에서 게이트웨이 사용을 참조 하세요.

여러 Azure OpenAI 인스턴스에 액세스하는 클라이언트 애플리케이션 인증

이 아키텍처의 Visio 파일을 다운로드합니다.

시나리오 제약 조건

이 시나리오에는 다음과 같은 제약 조건이 있습니다.

• 클라이언트 애플리케이션은 하나 이상의 지역에서 여러 Azure OpenAI 인스턴스에 연결합니다.
• 클라이언트가 Microsoft Entra ID 또는 다른 OIDC 공급자를 인증에 사용할 수 없거나 사용하지 않으려는 경우
• 클라이언트 애플리케이션에 키 기반 인증을 사용하려고 합니다.

이러한 태그에 다음과 같은 제한 사항이 적용됩니다.

• 클라이언트 애플리케이션은 대기 시간을 줄이고 성능을 향상시키기 위해 워크로드를 지리적으로 배포해야 합니다.

• 클라이언트 애플리케이션은 여러 지역에 인스턴스를 배포하여 분당 토큰을 최적화하려고 시도합니다.

• 조직은 지속적인 작업을 보장하기 위해 원활한 장애 조치(failover) 및 재해 복구 기능이 필요합니다. 따라서 프로비전된 처리량 배포 및 종량제 배포로 구성된 전략과 같은 이중 배포 전략을 관리합니다.

• 클라이언트 애플리케이션은 특정 Azure 지역에서만 사용할 수 있는 특정 모델 기능을 사용해야 합니다.

여러 Azure OpenAI 인스턴스에 직접 연결

클라이언트 애플리케이션이 여러 Azure OpenAI 인스턴스에 직접 연결하는 경우 각 클라이언트는 각 인스턴스에 대한 키를 저장해야 합니다. 키 사용에 대한 보안 고려 사항과 함께 키 회전에 대한 관리 부담이 증가합니다.

게이트웨이 소개

이 아키텍처의 Visio 파일을 다운로드합니다.

게이트웨이를 사용하여 여러 Azure OpenAI 배포에 액세스하는 클라이언트 애플리케이션을 처리하는 경우 키를 통해 여러 클라이언트 애플리케이션을 처리 하여 공유 Azure OpenAI 인스턴스에 액세스하는 게이트웨이와 동일한 이점을 얻을 수 있습니다. 또한 단일 사용자 정의 관리 ID를 사용하여 게이트웨이에서 여러 Azure OpenAI 인스턴스로 요청을 인증하기 때문에 인증 프로세스를 간소화합니다. 이 방법을 구현하여 전반적인 운영 오버헤드를 줄이고 여러 인스턴스로 작업할 때 클라이언트가 잘못 구성될 위험을 최소화합니다.

이 시나리오에 대한 권장 사항

• 부하 분산 기술을 구현하여 Azure OpenAI의 여러 인스턴스에 API 요청을 분산하여 높은 트래픽을 처리하고 고가용성을 보장합니다. 자세한 내용은 여러 Azure OpenAI 배포 또는 인스턴스 앞에서 게이트웨이 사용을 참조 하세요.

• 여러 Azure OpenAI 인스턴스를 사용하여 다중 테넌트 시나리오를 구현할 때 게이트웨이의 각 테넌트에 대한 토큰 사용량을 상호 연결합니다. 이 방법을 사용하면 요청이 전달되는 백 엔드 Azure OpenAI 인스턴스에 관계없이 총 토큰 사용량을 추적할 수 있습니다.

일반 권장 사항

게이트웨이를 통해 Azure OpenAI를 통합하는 경우 모든 시나리오에서 적용되는 몇 가지 교차 절삭 권장 사항이 있습니다.

효율적인 API 오케스트레이션, 다른 Azure 서비스와의 원활한 통합, 개발 및 유지 관리 노력을 줄여 비용 절감을 위해 고유한 솔루션을 만드는 대신 API Management를 사용합니다. API Management는 인증 및 권한 부여를 직접 지원하여 안전한 API 관리를 보장합니다. OAuth 2.0을 사용하도록 설정하고 정책 기반 권한 부여를 제공하는 Microsoft Entra ID와 같은 ID 공급자와 통합됩니다. 또한 API Management는 Azure OpenAI에 대한 안전하고 낮은 유지 관리 액세스를 위해 관리 ID를 사용합니다.

포괄적인 게이트웨이 솔루션에 대한 시나리오 결합

실제 애플리케이션에서 사용 사례는 이 문서의 여러 시나리오에 걸쳐 있습니다. 예를 들어 외부 ID 공급자를 통해 인증하고 여러 Azure OpenAI 인스턴스에 액세스해야 하는 클라이언트 애플리케이션이 있을 수 있습니다.

이 아키텍처의 Visio 파일을 다운로드합니다.

특정 요구 사항을 지원하는 게이트웨이를 빌드하려면 이러한 시나리오의 권장 사항을 결합하여 포괄적인 접근 방식을 만듭니다.

게이트웨이 정책 적용

게이트웨이가 Azure OpenAI 인스턴스에 요청을 보내기 전에 인바운드 인증 및 권한 부여 정책을 적용해야 합니다. 게이트웨이가 인증 및 권한 있는 요청만 전달하도록 하려면 ID 공급자 또는 인증서 유효성 검사의 사용자 액세스 토큰을 사용하여 이 방법을 구현합니다.

세분화된 제어를 사용하도록 설정하려면 게이트웨이에서 클라이언트 애플리케이션에 대한 역할 및 권한으로 더 많은 권한 부여 범위를 구현합니다. 이러한 범위를 사용하여 클라이언트 애플리케이션의 요구 사항에 따라 특정 작업을 허용합니다. 이 방법은 보안 및 관리 효율성을 향상시킵니다.

액세스 토큰 유효성 검사를 위해 등록된 모든 키 클레임(예: iss, aud, exp, 및 nbf )과 관련된 워크로드별 클레임(예: 그룹 멤버 자격 또는 애플리케이션 역할)의 유효성을 검사해야 합니다.

Azure 관리 ID를 사용

모든 클라이언트 애플리케이션 시나리오에서 인증을 간소화하려면 Azure 관리 ID를 사용하여 인증 관리를 중앙 집중화합니다. 이 방법은 클라이언트 애플리케이션에서 여러 API 키 또는 자격 증명을 관리하는 것과 관련된 복잡성과 위험을 줄입니다.

관리 ID는 기본적으로 Azure RBAC를 지원하므로 게이트웨이가 Azure OpenAI 인스턴스에 액세스하는 데 필요한 가장 낮은 수준의 권한만 갖도록 합니다. 무단 액세스의 위험을 줄이고 보안 정책 준수를 간소화하려면 관리 ID를 대체 인증을 사용하지 않도록 설정하는 다른 방법과 결합합니다.

포괄적인 관찰 가능성 구현

관리 ID를 사용하여 게이트웨이를 구현하면 관리 ID가 요청을 만드는 사용자 또는 애플리케이션이 아니라 게이트웨이 자체를 나타내므로 추적 가능성이 줄어듭니다. 따라서 API 요청과 관련된 메트릭에 대한 관찰 가능성을 개선하는 것이 중요합니다. 액세스 패턴 및 사용량에 대한 가시성을 유지하기 위해 게이트웨이는 요청 클라이언트 및 사용자 ID와 같은 더 많은 추적 메타데이터를 제공해야 합니다.

게이트웨이를 통과하는 모든 요청의 중앙 집중식 로깅은 감사 내역을 유지하는 데 도움이 됩니다. 중앙 집중식 감사 내역은 무단 액세스 시도 문제 해결, 규정 준수 및 검색에 특히 중요합니다.

게이트웨이 구현

Azure는 이 문서에서 게이트웨이를 빌드하기 위한 턴키 솔루션 또는 참조 아키텍처를 제공하지 않으므로 게이트웨이를 빌드하고 운영해야 합니다. Azure는 이 문서의 사용 사례를 다루는 커뮤니티 지원 구현의 예를 제공합니다. 사용자 고유의 게이트웨이 솔루션을 빌드할 때 이러한 샘플을 참조합니다. 자세한 내용은 비디오 Learn Live: Azure OpenAI 애플리케이션 ID 및 보안을 참조하세요.

참가자

다음은 최초로 이 문서를 작성한 기여자입니다.

주요 작성자:

• Lizet Pena De Sola | 선임 고객 엔지니어, Azure용 FastTrack
• Bappaditya Banerjee | 수석 고객 엔지니어, FastTrack for Azure
• James Croft | 고객 엔지니어, ISV & 및 디지털 네이티브 우수 센터

LinkedIn 비공개 프로필을 보려면, LinkedIn에 로그인하세요.

다음 단계

• Azure OpenAI용 RBAC
• API Management에서 관리 ID 사용
• API Management의 정책
• API Management의 API에 대한 인증 및 권한 부여
• OAuth 2.0 및 Microsoft Entra ID를 API Management에서 사용하여 API 보호
• Azure API Management에서 클라이언트 인증서 인증을 사용하여 백 엔드 서비스를 보호

관련 참고 자료

• 게이트웨이를 통해 Azure OpenAI 및 기타 언어 모델에 액세스