인증·권한·네트워크

7.2 인증·권한·네트워크

세부 학습 목표

• 인증·RBAC 역할/범위·관리 ID·keyless 자격과 연결 권한을 구별한다.
• VNet·Private Endpoint·DNS·라우팅과 공개 경로를 대조한다.
• 401·403·연결 실패를 실제 실행 신원과 네트워크 단계로 좁힌다.

개요

• 인증: 호출하는 사용자나 앱의 신원 확인.
• 권한: 그 주체가 수행할 수 있는 작업과 범위 제한.
• 네트워크: 대상 서비스까지 연결되는 경로 구성.
• 진단: 신원·역할·연결 오류를 구분해 조사.

신원, 역할, 범위

• 앱이 모델을 호출하려면 “누구인가”와 “무엇을 허용받았는가”가 모두 맞아야 합니다.

  Microsoft Entra ID의 토큰은 신원을 증명합니다. Azure RBAC의 역할 할당은 특정 범위에서 허용할 작업을 정합니다. 같은 역할이어도 구독 전체에 부여하는 것과 특정 프로젝트에 부여하는 것은 영향 범위가 다릅니다.

• 로컬에서 az login으로 성공한 코드가 서버에서 실패할 수 있습니다.

  로컬에서는 개발자의 ID를 사용했지만 서버에서는 관리 ID를 사용하기 때문입니다. DefaultAzureCredential을 사용한다는 사실만으로 두 환경의 권한이 같아지지는 않습니다. 실제로 선택된 자격 증명과 대상 리소스의 역할 할당을 확인합니다.

• Foundry 역할에는 개발용 Foundry User, 에이전트 호출용 Foundry Agent Consumer 등이 있습니다.

  문서·포털에 예전 Azure AI User 명칭이 남을 수 있으므로 역할 정의와 범위를 함께 읽습니다. 역할 이름 하나를 모든 연결 서비스에 적용하지 말고 Search, Storage 등 각 서비스의 데이터 접근 권한을 따로 확인합니다.

키와 토큰을 구분한다

• API 키는 키를 가진 호출자를 허용하므로 유출되면 다른 사람이 호출에 사용할 수 있습니다.

  서버 환경 변수나 비밀 저장소에서 읽고 브라우저 코드, Git 저장소, 문제 예제의 출력에 넣지 않습니다. Entra 인증은 ID와 역할을 연결할 수 있지만, 서비스·API가 해당 인증을 지원하는지도 확인해야 합니다.

아래는 애플리케이션에서 사용할 환경 변수 이름의 예시입니다. 실제 비밀 값을 채운 파일은 저장소에 추가하지 않습니다.

FOUNDRY_PROJECT_ENDPOINT=https://<resource>.services.ai.azure.com/api/projects/<project>
MODEL_DEPLOYMENT_NAME=<deployment-name>

• 엔드포인트와 배포 이름은 비밀번호가 아닙니다.

  그렇더라도 프로젝트별 설정으로 관리하면 개발 환경의 이름을 운영 코드에 잘못 넣는 일을 줄일 수 있습니다. 토큰은 요청 대상에 맞는 audience/scope로 발급받아야 합니다. 유효한 토큰이라도 다른 서비스용이면 거절될 수 있습니다.

네트워크 경로를 그려 확인한다

• VNet: Azure에서 리소스의 주소 범위와 연결 경로를 구성하는 가상 네트워크.
• Private Endpoint: VNet의 사설 IP를 통해 지원 서비스에 연결하는 네트워크 인터페이스.
• DNS: 서비스 이름을 IP 주소로 바꾸는 이름 해석 체계.
• 방화벽·라우팅: 통신의 허용 여부와 패킷이 지나갈 경로를 정하는 설정.

예를 들어 앱이 사설 엔드포인트를 사용하려면 서비스 이름이 의도한 사설 IP로 해석되고, 앱에서 그 IP까지 연결할 수 있어야 합니다. 연결이 되어도 서비스 권한은 따로 필요합니다. 아래 그림의 각 연결에서 이름 해석·네트워크 경로·접근 권한을 차례로 확인합니다.

• 이 그림은 논리적인 호출 경로입니다.

  실제 네트워크에서는 유입 경로와 서비스가 외부로 나가는 경로를 구분합니다. Private Endpoint, VNet, 방화벽, DNS가 어느 구간에 적용되는지 확인합니다. 에이전트에서 검색 서비스로 연결할 수 있어야 하며, 그 연결에서 사용하는 ID에도 검색 권한이 있어야 합니다. Foundry를 사설화했다고 연결된 모든 서비스의 경로가 자동으로 사설화되는 것은 아닙니다.

오류를 원인별로 좁힌다

• 401/403은 일반적인 진단 출발점이며 모든 서비스가 같은 원인을 같은 코드로 표현하지는 않습니다.

  요청 ID와 오류 본문을 확인한 뒤 해당 서비스의 로그와 연결합니다. 권한 수정 후에는 허용된 사용자의 성공뿐 아니라 금지된 사용자의 거절도 검사해야 합니다.

키·관리 ID·토큰의 책임

• 비밀키 방식은 키 보관과 유출 대응이 필요합니다.

  관리 ID는 지원되는 Azure 실행 환경에서 서비스 신원으로 토큰을 얻는 방식이며, 권한 할당은 별도로 필요합니다.

• 상황: 소스 코드에 API 키가 하드코딩된 개발 앱을 운영에 배포하려 합니다.

• 적용: 관리 ID를 통해 토큰을 획득한 후에도 대상 리소스에 필요한 RBAC 역할이나 데이터 권한이 있어야 호출이 성공합니다.

최소 권한 RBAC 설계

• 역할 기반 접근 제어(RBAC)는 특정 보안 주체에 특정 범위의 역할을 부여합니다.

  모든 사용자가 Owner 역할을 가질 필요는 없고, 역할 변경 전에는 필요한 실제 작업을 확인합니다.

• 상황: 읽기만 하는 검색 앱이 인덱스 생성과 권한 변경 역할까지 부여받았습니다.

• 적용: 질의 수행에 필요한 데이터 접근만 허용하고 관리 기능은 배포·운영 주체로 분리합니다.

  정확한 Azure 역할은 대상 서비스 권한 문서로 검증합니다.

사설 네트워크 호출 경로

• 사설망 연결에는 리소스별 Private Endpoint와 클라이언트가 연결된 네트워크, 사설 DNS 해석, 방화벽·라우팅 구성이 함께 필요합니다.

  관리 ID를 통해 토큰을 받는 인증 성공은 네트워크 접속 성공을 의미하지 않습니다. 서비스 유형에 따라 요구되는 사설 엔드포인트 구성을 문서에서 확인합니다.

• 상황: 관리 ID 토큰 발급은 성공했지만 사설 AI 서비스에 연결되지 않습니다.

• 적용: 실행 환경의 VNet·Private Endpoint·사설 DNS 이름 해석·라우팅·방화벽을 확인합니다.

  토큰 발급 성공만으로 서비스 연결은 검증되지 않습니다.

• 엔터프라이즈 Foundry 사설망 설계 

401·403·네트워크 오류 분류

• 401은 인증정보 문제, 403은 승인된 주체의 권한·정책 문제, 연결 타임아웃은 네트워크 경로 문제일 수 있습니다.

  실제 서비스 오류 코드와 메시지를 함께 확인해야 합니다.

• 상황: A 요청은 401, B는 403, C는 연결 타임아웃입니다.

• 적용: A는 자격 증명·토큰, B는 역할·정책·범위, C는 DNS·라우팅·방화벽 등 실제 연결 경로를 각각 검토합니다.

확인 문제

app-id → project API: HTTP 200
agent-id → storage/documents: HTTP 403 AuthorizationPermissionMismatch
storage network: connection allowed
agent-id roles: project_scope=[agent_run] / storage_scope=[]
도구가 읽어야 할 대상: storage/documents

참고 자료

• Role-based access control for Microsoft Foundry 
• Configure keyless authentication with Microsoft Entra ID 
• Networking options for Foundry Agent Service 
• Set up permissions for Microsoft Foundry evaluation workflows 
• Private Endpoint의 역할 

자료 확인: 2026-10-23 · 적용 사례 교정: 2026-10-23. 사례는 교육용이며 Azure API 호출·요금은 실행 검증하지 않았습니다.

서비스 신원으로 연결했지만 특정 문서 조회가 거절됩니다. 다른 팀 문서는 보이면 안 되는 요구가 있습니다.