OpenAI 플랫폼에서 권한 관리하기

OpenAI 플랫폼에서 권한 관리하기 (Manage permissions in the OpenAI platform)

출처: 문서

역할 기반 접근 제어(Role-based access control, RBAC)를 사용하면 조직과 프로젝트 전반에서 누가 어떤 작업을 할 수 있는지 — API와 Dashboard 양쪽 모두에서 — 결정할 수 있어요. 두 표면이 동일한 권한으로 관리돼요: 엔드포인트(예: /v1/chat/completions)를 호출할 수 있는 사람은 동등한 Dashboard 페이지도 사용할 수 있으며, 권한이 없으면 관련 UI(예: Playground의 Upload 버튼)가 비활성화돼요. RBAC로 다음을 할 수 있어요:

  • 사용자를 그룹화하고 규모에 맞게 권한을 할당하기
  • 정확히 필요한 권한으로 커스텀 역할을 만들기
  • 조직 또는 프로젝트 수준에서 접근 범위를 지정하기
  • Dashboard와 API 양쪽에 일관된 권한을 적용하기

주요 개념

  • Organization: 최상위 계정이에요. 조직 역할은 모든 프로젝트에 걸쳐 접근 권한을 부여할 수 있어요.
  • Project: 키, 파일, 리소스를 위한 워크스페이스예요. 프로젝트 역할은 해당 프로젝트 안에서만 접근 권한을 부여해요.
  • Groups: 역할을 할당할 수 있는 사용자 모음이에요. 그룹은 identity provider(SCIM 경유)에서 동기화해 멤버십을 자동으로 최신 상태로 유지할 수 있어요.
  • Roles: 권한 묶음(예: Models Request 또는 Files Write)이에요. 조직 역할은 Organization settings 아래에서 만들 수 있고, 특정 프로젝트 역할은 해당 프로젝트 설정 아래에서 만들 수 있어요. 만들어진 조직 또는 프로젝트 역할은 사용자나 그룹에 할당할 수 있어요. 사용자는 여러 역할을 가질 수 있으며, 접근 권한은 이 역할들의 합집합(union)이에요.
  • Permissions: 역할이 허용하는 구체적인 작업이에요(예: 모델에 요청하기, 파일 읽기, 파일 쓰기, 키 관리).

Permissions

아래 표는 사용 가능한 권한, 어떤 프리셋 역할이 이를 포함하는지, 커스텀 역할에서 구성할 수 있는지를 보여줘요.

영역 허용하는 작업 Org owner 권한 Org reader 권한 Project owner 권한 Project member 권한 Project viewer 권한 커스텀 역할 가능
List models 이 조직이 접근할 수 있는 모델 나열하기 Read Read Read Read Read ✓
Groups 그룹 보기 및 관리 Read, Write Read Read, Write Read, Write Read
Roles 역할 보기 및 관리 Read, Write Read Read, Write Read, Write Read
Organization Admin 조직 사용자, 프로젝트, 초대, Admin API 키, 비율 한도 관리 Read, Write
Usage 사용량 대시보드 보기 및 내보내기 Read ✓
External Keys Enterprise Key Management용 키 보기 및 관리 Read, Write
IP allowlist IP allowlist 보기 및 관리 Read, Write
mTLS 상호 TLS(mutual TLS) 설정 보기 및 관리 Read, Write
OIDC OIDC 구성 보기 및 관리 Read, Write
Model capabilities chat completions, audio, embeddings, images에 요청하기 Request Request Request Request ✓
Assistants Assistants 생성 및 검색 Read, Write Read, Write Read, Write Read, Write Read ✓
Threads Threads/Messages/Runs 생성 및 검색 Read, Write Read, Write Read, Write Read, Write Read ✓
Evals Evals 생성, 검색, 삭제 Read, Write Read, Write Read, Write Read, Write Read ✓
Fine-tuning 파인튜닝 작업 생성 및 검색 Read, Write Read, Write Read, Write Read, Write Read ✓
Files 파일 생성 및 검색 Read, Write Read, Write Read, Write Read, Write Read ✓
Vector Stores vector store 생성 및 검색 Read, Write Read, Write Read, Write Read, Write ✓
Responses API responses 생성 Read, Write Read, Write Read, Write Read, Write ✓
Prompts Responses API 및 Realtime API의 컨텍스트로 사용할 프롬프트 생성 및 검색 Read, Write Read, Write Read, Write Read, Write Read ✓
Webhooks 프로젝트에서 웹훅 생성 및 보기 Read, Write Read Read, Write Read, Write Read ✓
Datasets Datasets 생성 및 검색 Read, Write Read, Write Read, Write Read, Write Read ✓
Apps Dashboard에서 앱 생성, 관리, 검토 제출 Read, Write ✓
Tunnels 조직 범위 tunnels 검사, 사용, 관리 Read, Use, Manage ✓
Project API Keys 사용자가 자신의 API 키를 관리할 수 있는 권한 Read, Write Read, Write Read, Write Read, Write Read ✓
Project Administration 관리 API로 프로젝트 사용자, 서비스 계정, API 키, 비율 한도 관리 Read, Write Read, Write
Batch batch 작업 생성 및 관리 Read, Write Read, Write Read, Write Read, Write Read
Service Accounts 프로젝트 서비스 계정 보기 및 관리 Read, Write Read, Write
Voices 음성 생성 및 검색 Read, Write Read, Write Read, Write Read, Write Read
Agent Builder Agent Builder에서 에이전트와 워크플로 생성 및 관리 Read, Write Read Read, Write Read, Write Read ✓

Batch 권한의 함의

Batch 권한에는 batch 입력 파일 준비, 요청 실행, 결과 검색에 필요한 접근이 포함돼요. 이 실질적 접근은 batch 안에 제출할 수 있는 엔드포인트와는 별개이며, 후자는 Batch API 가이드에 나열돼 있어요.

Batch 권한 추가로 부여되는 접근
Read (api.batch.read) /v1/files에 대한 Files Read (api.files.read)
Write (api.batch.write) Batch Read
/v1/models에 대한 List models (api.model.read 및 model.read)
/v1/files에 대한 Files Read and Write (api.files.read 및 api.files.write)
/v1/audio, /v1/chat/completions, /v1/embeddings, /v1/images, /v1/moderations, /v1/realtime, /v1/responses에 대한 Model capabilities Request (api.model.request 및 model.request)

RBAC 설정하기

역할 변경과 그룹 동기화가 전파되도록 최대 30분을 허용해요.

  1. 그룹 만들기 팀용 그룹을 추가해요(예: Data Science 및 Support). IdP를 사용한다면 SCIM 동기화를 활성화해서 그룹 멤버십이 최신 상태로 유지되게 해요.

  2. 커스텀 역할 만들기 최소 권한에서 시작해요. 예를 들어:

    • Model Tester: Models Read, Model Capabilities Request, Evals
    • Model Engineer: Model Capabilities Request, Files Read/Write, Fine-tuning
    • App Publisher: Apps Read, Apps Write

  3. 역할 할당하기

    • Organization 수준 역할은 모든 곳(조직 내 모든 프로젝트)에 적용돼요.
    • Project 수준 역할은 해당 프로젝트에서만 적용돼요. 역할을 사용자와 그룹에 할당할 수 있어요. 사용자는 여러 역할을 가질 수 있으며, 접근 권한은 합집합이에요.

  4. 검증하기 non-owner 계정을 사용해 예상 접근 권한(API 및 Dashboard)을 확인해요. 사용자가 필요한 것보다 더 많이 볼 수 있다면 역할을 조정해요.

최소 권한 원칙을 사용해요. 작업에 필요한 최소 권한으로 시작하고, 필요할 때만 권한을 추가해요.

접근 구성 예시

소규모 팀

  • 핵심 팀에 Model Capabilities Request와 Files Read/Write가 있는 조직 수준 역할을 부여해요.
  • 각 앱에 프로젝트를 만들고, 계약자에게는 프로젝트 수준 역할로 해당 프로젝트에만 접근을 부여해요.

더 큰 조직

  • IdP에서 그룹을 동기화해요(예: Research, Support, Finance).
  • 기능별 커스텀 역할을 만들고 조직 수준에서 할당하거나, 프로젝트에 더 엄격한 제어가 필요할 때만 프로젝트별 역할을 부여해요.

계약자 & 공급업체

  • 조직 수준 역할이 없는 "Contractors" 그룹을 만들어요.
  • 좁은 범위의 프로젝트 역할(예: 읽기 전용 접근)로 특정 프로젝트에 추가해요.

사용자 접근이 평가되는 방식

Dashboard에서 다음을 결합해요:

  • organization 의 역할(직접 + 그룹 경유)
  • project 의 역할(직접 + 그룹 경유)

실질적 권한은 할당된 모든 역할의 합집합이에요.

프로젝트 안에서 API 키로 요청하는 경우, API 키에 할당된 권한을 취하고, 사용자가 해당 권한을 부여하는 프로젝트 역할을 가지고 있는지 확인해요. 예를 들어 /v1/models를 요청하면 API 키에 api.model.read가 할당되어 있어야 하고, 사용자에게도 api.model.read가 있는 프로젝트 역할이 있어야 해요.

모범 사례

  • 조직을 그룹으로 모델링하기: IdP의 팀을 미러링하고 개인이 아니라 그룹에 역할을 할당해요.
  • 업무 분리하기: 모델 읽기 vs 파일 업로드 vs 키 관리.
  • 프로젝트 경계: 실험, 스테이징, 프로덕션을 별도의 프로젝트로 분리해요.
  • 정기적으로 검토하기: 사용하지 않는 역할과 키를 제거하고 민감한 키를 회전해요.
  • non-owner로 테스트하기: 광범위 배포 전에 접근이 기대와 일치하는지 검증해요.