GS2-Identifier

크리덴셜 관리 기능

GS2-Identifier는 GS2 관리 콘솔 및 GS2 API에 접근하기 위한 크리덴셜을 관리하는 서비스입니다.

GS2 오너 계정에 연결된 사용자, 각 사용자에게 부여되는 권한(보안 정책), 그리고 실제 API 호출에 사용하는 클라이언트ID/클라이언트시크릿을 발급·관리합니다.

GS2-Identifier는 게임 클라이언트에서 직접 호출하는 것을 상정하지 않은 서비스이며, 운영 측의 셋업이나 배포 자동화, CI/CD 파이프라인 등에서 이용됩니다.

IAM 적인 설계

GS2-Identifier는 클라우드 서비스의 IAM(Identity and Access Management)에 상당하는 개념을 제공합니다.

주요 요소는 다음과 같습니다.

사용자: GS2 오너 계정 산하에 생성하는 개별 이용 주체
보안 정책: 조작 가능한 리소스와 액션을 기술한 정책 문서
보안 정책의 어태치: 사용자에게 보안 정책을 연결하여 권한을 부여
클라이언트ID/클라이언트시크릿: 사용자별로 발급되는 API 인증 정보

graph TD
  Owner["GS2 오너"] --> User["사용자"]
  User -->|어태치| Policy["보안 정책"]
  User -->|발급| Credential["클라이언트ID<br/>클라이언트시크릿"]
  Credential -->|인증| API["GS2 API"]
  Policy -->|권한 제어| API

보안 정책

보안 정책은 JSON 형식으로 기술된 권한 정의입니다. 허용할 리소스 GRN과 허용할 액션(Gs2Account:CreateAccount와 같은 조작 식별자)을 기술함으로써, 해당 정책이 어태치된 사용자에게 어떤 조작을 허용할지를 표현합니다.

개발·운영의 각 단계에 맞는 적절한 정책을 설계하여, 사용자별로 최소 권한을 부여하는 운영을 권장합니다.

클라이언트ID/클라이언트시크릿

사용자에게 발급되는 클라이언트ID와 클라이언트시크릿은 GS2 API를 호출할 때의 인증 정보로 사용됩니다. 한 명의 사용자에게 여러 개의 크리덴셜을 발급할 수 있으며, 용도나 디바이스에 따라 구분하여 사용할 수 있습니다.

클라이언트시크릿은 발급 시에만 취득할 수 있으며, 그 이후에는 GS2에서 다시 조회할 수 없습니다. 만약 유출된 경우에는 해당 크리덴셜을 삭제하고 재발급해 주십시오.

GS2-Version과 연동한 권한의 단계적 부여

GS2-Identifier에서는 사용자에게 연결된 크리덴셜에 “가드"로서 GS2-Version의 Project Token 발급을 요구할 수 있습니다.

구체적으로는, 애플리케이션에 내장된 클라이언트ID/클라이언트시크릿에는 “로그인과 버전 체크를 실행할 수 있는 정도"의 약한 권한만 부여해 두고, 버전 체크에 성공한 후 발급되는 강한 권한의 크리덴셜을 사용하여 게임 본편에 접근하는 설계가 가능합니다.

graph TD
  App["애플리케이션 내장<br/>크리덴셜<br/>(최소 권한)"] -->|버전 체크| Version["GS2-Version"]
  Version -->|Project Token 발급| App
  App -->|Project Token을 이용한 인증| Strong["강한 권한의<br/>크리덴셜"]
  Strong -->|게임 본편 API 호출| API["GS2 API"]

이 흐름을 통해 오래된 애플리케이션 바이너리나 지원이 종료된 에셋 버전에서 동작하는 클라이언트가 게임 본편의 API에 계속 접근하는 것을 방지할 수 있습니다. 자세한 내용은 GS2-Version 문서를 참조해 주세요.

2단계 인증

GS2 관리 콘솔에 로그인하는 사용자에 대해 2단계 인증을 활성화할 수 있습니다. GS2-Identifier에서는 2단계 인증 설정 정보를 관리합니다.

트랜잭션 액션

GS2-Identifier에서는 트랜잭션 액션을 제공하지 않습니다.

마스터 데이터 관리

GS2-Identifier에서는 마스터 데이터 등록이 없습니다. 보안 정책이나 사용자, 크리덴셜 등은 관리 콘솔이나 GS2-Deploy, API를 통해 직접 관리합니다.

구현 예제

GS2-Identifier는 관리 API/서버 사이드 API 중심의 마이크로서비스입니다. 게임 엔진용 SDK(Unity/Unreal Engine/Godot)에는 전용 Domain 클래스가 제공되지 않습니다.

사용자·보안 정책·크리덴셜의 관리 조작은 운영 측의 셋업이나 배포 자동화, CI/CD 파이프라인에서 실행하는 것을 상정하고 있으므로, 다음 중 하나의 수단으로 조작하는 것을 권장합니다.

GS2 관리 콘솔(GUI로 사용자·정책·크리덴셜을 조작)
GS2-Deploy 템플릿에 사용자·정책·크리덴셜의 정의를 작성하여 CI에서 반영
각종 언어용 범용 SDK(C#/Go/Python/TypeScript/PHP/Java)를 이용한 운영 도구에서의 관리 API 호출
GS2 CLI

각종 SDK의 상세 내용은 해당 레퍼런스 페이지를 참조해 주세요.

Project Token 취득

예외적으로, 사용자에 대한 로그인(Project Token 발급)을 애플리케이션 측에서 실행하는 경우가 있습니다. 내장된 클라이언트ID/클라이언트시크릿을 사용하여 Login API를 호출하고, 취득한 Project Token을 GS2 API의 인증 정보로 사용함으로써, 사용자에게 연결된 보안 정책의 범위 내에서 API를 호출할 수 있습니다.

로그인 API는 게임 엔진용 SDK의 Domain을 경유하지 않고, 각종 언어용 범용 SDK(C#/Go/Python/TypeScript/PHP/Java)를 사용하여 호출해 주세요. GS2-Version과 조합하는 경우에는 버전 체크 후에 Project Token을 발급함으로써 권한의 단계적 부여를 실현할 수 있습니다.

보다 실전적인 정보

운영 단계별 권한 분리

개발 단계와 프로덕션 단계에서는 필요한 권한의 종류와 강도가 다릅니다. GS2-Identifier에서는 사용자별로 서로 다른 보안 정책을 어태치할 수 있으므로, 다음과 같은 계정 설계를 고려할 수 있습니다.

개발자 사용자: 개발 환경 리소스에 대한 읽기/쓰기 권한만
운용 사용자: 프로덕션 환경 리소스에 대한 읽기와 제한적인 쓰기 권한
CI 사용자: GS2-Deploy 실행에 필요한 권한
게임 클라이언트 내장 사용자: 로그인과 버전 체크만 실행 가능

이용 주체별로 전용 크리덴셜을 발급하고 최소 권한의 원칙에 따라 운영함으로써, 만약 크리덴셜이 유출되더라도 그 영향을 한정할 수 있습니다.

크리덴셜 로테이션

보안을 유지하기 위해 클라이언트ID/클라이언트시크릿은 정기적으로 로테이션할 것을 권장합니다. 새로운 크리덴셜을 발급한 후 기존 크리덴셜을 삭제하는 절차를 밟음으로써, 무중단으로 전환할 수 있습니다.