기업 내 사고 발생: 누군가가 Azure OpenAI를 통해 회사의 보안 경계 밖으로 나가서는 안 될 텍스트를 생성했습니다. 액세스 키(Access Key)를 취소하는 것은 1분도 걸리지 않는 표준적인 대응입니다. 하지만 보안 팀에게는 취소된 키로는 답할 수 없는 질문이 남습니다. 어떤 작업 ID(Workload Identity)가 어떤 역할(Role)로 호출을 수행했는가 하는 점입니다.

키가 통과된 이유는 그것이 안전한 선택이었기 때문이 아니라, 유효(Valid)했기 때문입니다. 유효성(Validity)과 조사 가능성(Traceability)은 서로 다른 속성입니다. 키는 호출 권한을 확인하지만, 작성자가 누구인지에 대해서는 아무것도 말해주지 않습니다. 사고를 분석할 때 모든 작업은 바로 이 간극을 메우는 데 집중됩니다.

다음은 구체적인 솔루션에 대한 엔지니어링 분석입니다. 호출 자체를 조사하기 위해 Azure AI 액세스 시 키 대신 Microsoft Entra ID를 선택해야 하는 이유와, 이러한 액세스를 '조사 가능하다'고 부르기 전에 확인해야 할 증거는 무엇인지 다룹니다. 아래의 두 가지 서비스 주체(Service Principals) 시나리오는 완성된 로그를 보여주는 것이 아니라, 재현 가능한 검증 계획이며 완료된 실험 보고서가 아닙니다.

무엇을 증명해야 하며, 무엇이 분석 범위에서 제외되는가

api azure ai를 검색하는 개발자는 보통 5분 안에 작동하는 요청을 얻을 수 있습니다. 포털에서 키를 복사하여 헤더에 붙여넣으면 모델의 응답을 받을 수 있습니다. 여기서 편리함이 바로 함정입니다. 키는 리소스의 공용 비밀(Shared Secret)이지, 그것을 사용한 사람의 신원(Identity)이 아닙니다. 만약 5개의 서비스와 3명의 엔지니어가 키를 알고 있다면, 성공적인 호출 사실은 단 하나만 말해줍니다. 발신자가 해당 키를 가지고 있었다는 사실입니다.

결론이 흐려지지 않도록 작업의 경계를 즉시 설정해야 합니다. 이는 단순히 "관리형 ID(Managed Identity)가 비밀번호보다 낫다"는 일반적인 논쟁이 아니라, Azure AI 호출의 구체적인 감사 가능성(Auditability)에 관한 것입니다. 즉, 로그를 통해 어떤 작업 ID가 어떤 역할로 모델에 대한 바로 그 데이터 평면(Data-plane) 요청을 수행했는지 증명할 수 있는가에 대한 문제입니다. Azure 외부에서 실행되는 워크로드는 이번 분석 범위에 포함되지 않습니다. 외부 환경은 자체적인 로그와 동일한 질문에 답하는 별도의 방식을 가지고 있기 때문입니다.

전체 텍스트를 관통하는 반증 가능한 논제는 다음과 같습니다. 만약 로그가 특정 Azure AI 호출을 작업 ID(workload identity) 및 그 역할과 연결할 수 없다면, 이 시나리오에서 Entra ID는 조사(investigation) 측면의 이점을 증명하지 못합니다. 지도가 완성되기 전까지는 '보통 더 나은' 것이 아니라, 정확히 '증명하지 못하는' 상태입니다.

리소스에 대한 Entra ID 액세스가 활성화되는 방식

Microsoft Learn 문서(2026-07-18 접속)에 따르면, Azure OpenAI 및 Foundry 리소스는 API 키의 대안으로 Microsoft Entra ID를 통한 인증을 지원하지만, 두 가지 필수 조건이 따릅니다. 첫째, 리소스에 사용자 지정 서브도메인(custom subdomain)이 설정되어 있어야 하며, 이것 없이는 Entra ID 인증이 아예 활성화되지 않습니다. 둘째, 호출 측(사용자, 서비스 주체(service principal) 또는 관리 ID(managed identity))은 반드시 Cognitive Services OpenAI User 또는 Cognitive Services OpenAI Contributor와 같은 역할을 보유해야 하며, 그렇지 않으면 추론(inference) 호출이 실패합니다.

클라이언트 흐름(client flow) 문서는 DefaultAzureCredential을 통해 이를 보여줍니다. 라이브러리는 Entra ID로부터 베어러 토큰(bearer token)을 받고, 이 토큰을 사용하여 모델에 호출을 보냅니다. 두 개의 서비스 주체(service principal)를 사용하는 감사(audit) 시나리오는 정확히 이 흐름을 반복하며, 단지 각 ID가 고유한 토큰을 받는다는 점만 다릅니다.

from azure.identity import DefaultAzureCredential, get_bearer_token_provider
from openai import AzureOpenAI

...

역할 할당은 Access control (IAM) → Add role assignment을 통해 수행됩니다. 역할은 리소스, 리소스 그룹 또는 구독 수준에서 사용자, 그룹, 서비스 주체(service principal) 또는 관리 ID(managed identity)에 할당할 수 있으며, 문서에 따르면 할당은 몇 분 이내에 활성화됩니다. 조사 지도의 관점에서 이는 두 작업 ID 각각이 제어 평면(control-plane) 수준에서부터 추적 가능한 별도의 의도 흔적(trace of intent)을 갖게 됨을 의미합니다.

역할이 호출 여부를 결정한다

신원만으로는 충분하지 않다: 게이트를 통과하는 것은 바로 역할(role)이며, 이는 쉽게 간과할 수 있다. Cognitive Services OpenAI User 및 Cognitive Services OpenAI Contributor 역할은 Microsoft Entra ID를 사용하여 '추론 API 호출을 수행할 수 있는' 것으로 문서화되어 있다. 반면 더 광범위한 관리 역할인 Cognitive Services Contributor는 그러지 못한다고 명시적으로 문서화되어 있다: 이는 제어 평면(control-plane) 역할이며, 리소스를 관리할 수는 있지만 그 리소스를 통해 데이터를 전송하는 것은 불가능하다.

여기서 실질적인 결론이 나온다. 만약 서비스 주체(service principal)에게 가짜로 '강한' Cognitive Services Contributor 역할을 부여하더라도, 해당 주체는 리소스 전체를 관리할 수는 있지만 Entra ID를 통한 모델 데이터 평면(data-plane) 호출은 실패한다. 이 역할은 단순한 접근 레이블이 아니라 호출을 생성하는 것 자체의 조건이며, 이는 조사 지도(map of investigation)에 있어 선물과 같다: 서로 다른 역할들은 구별 가능한 이벤트 의미를 제공하기 때문이다.

바로 이것이 시나리오 가설의 기반이다: 서로 다른 역할을 가진 두 서비스 주체는 로그에 구별 가능한 흔적을 남겨야 한다. 이는 확립된 사실이 아니라 가설이며, 테스트 자체가 이를 검증해야 한다. 날짜 관련 주의사항도 있다: Cognitive Services 및 OpenAI에 대한 RBAC 역할 정의는 여러 번 변경되었다(원본 Microsoft 문서에는 'Added Fall 2023'과 같은 표시가 직접 되어 있다). 이 표는 문서 작성일 기준의 최신 정보(ms.date 2026-01-31, 업데이트 2026-06-05)이지만, 이는 변동하는 목표이지 영구적인 계약이 아니다. 역할 이름은 실제로 사용자의 테넌트에서 표시되는 포털 세대와 비교해야 한다: Azure OpenAI는 현재 'Foundry classic'과 'Foundry'라는 두 가지 세대에 존재하며, 문서 페이지가 겹치지만 동일하지 않다.

리소스 로그에 실제로 기록되는 것들

여기서부터는 상황이 까다로워집니다. Azure AI 및 Cognitive Services의 리소스 수준 로깅(Logging)은 자동으로 활성화되지 않습니다. 수동으로 진단 설정(Diagnostic setting, Monitoring → Diagnostic settings)을 추가하고 Audit, RequestResponse, AllMetrics 등의 로그 카테고리를 선택한 다음, 이를 Log Analytics 또는 Azure Storage로 전송하도록 설정해야 합니다. 또한, 기록된 데이터가 쿼리 가능한 상태가 되기까지 최대 2시간의 지연 시간이 발생할 수 있다는 점을 고려해야 합니다.

Microsoft.CognitiveServices/accounts에 대한 리소스 로그 카테고리는 "Audit Logs", "Azure OpenAI Request Usage", "Request and Response Logs", "Managed Network Events", "Trace Logs"로 각각 문서화되어 있습니다. Log Analytics로 라우팅하면 이 모든 로그는 AzureDiagnostics 테이블에 저장되며, 별도의 AzureActivity 테이블은 제어 평면(Control-plane) 작업을 유지합니다. 여기서 "로그"는 단일 엔티티가 아니라, 나중에 서로 연결(stitch)해야 하는 여러 개의 스트림입니다.

핵심 질문은 이것입니다: 리소스 로그가 호출자의 신원(Identity)을 포함하고 있는가? Azure Monitor 리소스 로그의 일반적인 상위 수준 스키마는 선택적 필드인 identity를 정의합니다: "작업을 수행한 사용자 또는 애플리케이션의 신원을 설명하는 JSON 블롭(blob)"으로, 일반적으로 Microsoft Entra ID의 인증 클레임(Claims) 또는 JWT 토큰을 포함하며, 이벤트 연결을 위한 선택적 callerIpAddress 및 correlationId가 포함됩니다. 이는 마치 우리가 찾던 증거처럼 들립니다. 하지만 이것은 범용 플랫폼 스키마이며, Azure OpenAI 또는 Cognitive Services 전용 페이지 중 그 어디에서도 Microsoft.CognitiveServices/accounts에 대한 모든 Request/Response 또는 Audit 기록 시 이 필드가 실제 사용 가능한 Entra ID Object ID로 채워진다는 점을 확인해주지 않습니다.

따라서 "리소스 로그가 각 추론(Inference) 호출에 대해 호출자의 신원을 안정적으로 전달한다"는 주장은 검증되지 않은 가설로 남아 있습니다. 이를 확인하거나 반박하려면 두 개의 서비스 주체(Service principals)를 사용하는 시나리오가 필요합니다. 만약 해당 필드가 비어 있거나 Object ID가 없다면, 바로 이 지점에서 계획이 무너지게 되며, 결론은 다음과 같이 내려져야 합니다: 이 리소스의 데이터 평면(Data-plane) 로그 자체만으로는 신원을 증명할 수 없다.

두 번째 소스: Entra ID 로그인 로그

이 과제에는 두 번째 소스가 있으며, 이는 조사 질문에 정확히 부합하도록 설계되어 있습니다. Microsoft Entra ID 로그인 로그는 interactive user, non-interactive user, service principal, 그리고 managed identity의 네 가지 유형으로 나뉩니다. 공식 문서에서는 이 로그들을 "managed identities와 service principals가 어떤 Azure 리소스에 접근했는가?"라는 질문에 대한 답변으로 정의하며, 각 이벤트를 Who (신원), How (애플리케이션 또는 클라이언트), What (접근한 리소스)의 모델로 구성합니다.

service principal 로그인 기록에는 service principal의 이름과 ID, 로그인 상태, IP 주소, 그리고 요청 대상 리소스의 이름 또는 ID가 기록됩니다. 여기서 주의해야 할 점(pitfall)이 하나 있습니다. Microsoft는 service principal, 상태, IP 주소, 리소스가 모두 일치하는 반복적인 로그를 하나의 행으로 집계(aggregate)하므로, 모든 개별 호출이 각각 별도의 행으로 생성되지는 않습니다. 감사(audit) 관점에서 이는 "한 행"이 "한 번의 호출"을 의미하지 않음을 뜻하며, 로그 행의 수만으로 활동량을 파악하는 것은 순진한 접근일 수 있습니다.

반면, sign-in 로그에는 증거로서 가치를 부여하는 고유한 속성이 있습니다. 바로 기록이 시스템에 의해 생성되어 수정하거나 삭제할 수 없다는 점입니다. 스스로 작성하거나 수정할 수 있는 로그는 조사에 거의 무용지물인 반면, 변경 불가능한(immutable) 로그는 이미 증거물(evidence)에 가깝습니다. 한계점도 존재합니다. sign-in 로그는 Entra ID, Microsoft Graph, Azure Resource Manager에서의 인증을 기록하며, 이는 Cognitive Services의 리소스 데이터 평면(data-plane) 로그와는 별개의 소스입니다. 두 로그 제품군을 이미 하나로 결합해 놓은 단일 완성형 테이블을 제공하는 소스는 없으므로, 방어 가능한(defensible) 조사 지도를 그리려면 시간과 연결 필드를 기반으로 수동 상관관계 분석(manual correlation)을 수행해야 합니다. 바로 이 상관관계 분석이야말로, 단순히 Entra ID를 사용했다는 사실을 넘어 "역할, 신원, 호출, 이벤트" 사이의 연결 고리를 입증해 줍니다.

키(Key)인가 Entra ID인가: 감사를 위한 선택 방법

결정을 내리기 위해 표로 정리해 보겠습니다. 각 행은 동일한 질문에 답합니다. 즉, 요청이 기술적으로 통과되는지를 넘어, 사고 발생 후 당신이 정확히 무엇을 증명할 수 있는가에 대한 질문입니다.

관리형 ID (Managed Identity)는 실제로 키보다 복잡합니다. 이는 공짜 업그레이드가 아니라 정당한 교환입니다. 당신은 역할 설정, 진단 설정 (diagnostic settings), 그리고 이를 로그와 연결하는 수고를 지불해야 합니다. 그 대가로 특정 동작을 검증 가능한 역할에 결합할 수 있는 능력을 얻습니다. 규제 준수 측면에서의 선택은 명확합니다. 조사가 필요한 기업용 액세스의 경우, 역할 및 이벤트와 연결할 수 있는 인증 방식을 선택하십시오. 하지만 이는 "신원, 역할, 호출, 감사 이벤트"의 연결 고리가 추측이 아닌 입증되었을 때에만 유효합니다. 만약 시나리오가 검증 가능한 이벤트를 생성하지 못하거나 역할을 호출에 연결할 수 없다면, Entra ID는 해당 사례에서 선택의 근거가 되었던 이점을 제공하지 못합니다.

유사한 책임성 문제는 Azure 외부에서도 다른 수준으로 발생하며, 이때 도구를 혼동하지 않는 것이 중요합니다. provod.ai는 Entra ID와 그 개체별 역할 (object-level roles)을 대체하는 것이 아닙니다. 이는 Azure 리소스의 감사 메커니즘이 아니라, 모델에 접근하기 위한 별도의 API 액세스 경로입니다. 하지만 여기에는 고유한 계정 단위가 있습니다. OpenAI 프로토콜을 지원하는 클라이언트는 Base URL과 키를 변경함으로써 provod.ai에 연결되며, 해당 키는 구성원들이 역할과 액세스 제어를 가지고 조직은 공통 비용 잔액을 관리하는 팀 워크스페이스 내에 존재합니다.