클래스 수준 권한(CLP)이란?

클래스 수준 권한(CLP)은 어떤 사용자나 역할이 해당 클래스에서 각 작업을 애초에 실행할 수 있는지를 통제하는, 클래스 스키마 단위의 규칙입니다. CLP는 데이터 계층 보안의 가장 바깥쪽 관문입니다. 행 단위 검사가 일어나기 전에, 클래스 자체가 이 호출자가 여기서 find, create, update, delete를 할 수 있는지 결정합니다. 규칙 하나가 테이블 전체에 적용되며, 가장 먼저 검사됩니다.

핵심 요약

클래스 관문: 선언과 체감

CLP는 스키마 설정입니다. 다음은 Config 클래스를 public read, 서버 전용 쓰기로 잠그는 REST 페이로드입니다.

PUT /schemas/Config
{
  "classLevelPermissions": {
    "find":   { "*": true },              // 누구나 쿼리 가능
    "get":    { "*": true },
    "create": {},                         // 클라이언트 측에서는 누구도 불가
    "update": { "role:admin": true },     // 관리자만
    "delete": {},
    "addField": {}                        // 스키마 동결
  }
}

클라이언트 쪽에서는 관문이 제 역할을 하는 모습이 그대로 드러납니다. 읽기는 통과하고, 쓰기는 어떤 데이터에도 닿기 전에 클래스 경계에서 막힙니다.

// JavaScript / Node.js — Back4app JS SDK
// The class gate in action: Config is read-only for clients (CLP),
// so reads succeed and writes never reach the data
const config = await new Parse.Query('Config').first(); // ✓ public read

const c = new Parse.Object('Config');
c.set('flag', true);
try {
  await c.save(); // ✗ CLP blocks client writes to this class entirely
} catch (e) {
  console.log(e.code); // 119: operation forbidden by class-level permissions
}

// Flutter / Dart — Back4app Flutter SDK
// The class gate in action: reads allowed, client writes blocked by CLP
final config = ParseObject('Config')..set('flag', true);
final response = await config.save();
if (!response.success) {
  print(response.error?.code); // 119: forbidden by class-level permissions
}

// iOS / Swift — Back4app Swift SDK
// The class gate in action: reads allowed, client writes blocked by CLP
var config = Config()
config.flag = true
config.save { result in
  if case .failure(let error) = result {
    print(error) // operation forbidden by class-level permissions
  }
}

// Android / Kotlin — Back4app Android SDK
// The class gate in action: reads allowed, client writes blocked by CLP
val config = ParseObject("Config").apply { put("flag", true) }
config.saveInBackground { e ->
  if (e != null) {
    Log.d("CLP", "blocked: ${e.code}") // forbidden by class-level permissions
  }
}

클래스 수준 권한과 ACL이 함께 동작하는 방식

세분성의 사다리: CLP vs. ACL vs. 포인터 권한 vs. 보호 필드

여기서 도출되는 설계 원칙은 큰 틀은 스키마에, 세밀한 제어는 행에 두는 것입니다. 접근 규칙이 균일한 클래스(설정, 카탈로그, 로그)는 클래스 관문만으로 충분하고, 사용자별 데이터가 있는 클래스는 그 아래에 ACL이나 포인터 권한을 더합니다.

다른 엔진의 같은 관문

-- PostgreSQL: 테이블 수준 권한은 이름만 다른 CLP입니다
GRANT SELECT ON films TO PUBLIC;
GRANT INSERT, UPDATE ON films TO role_editor;
REVOKE ALL ON launch_codes FROM PUBLIC;

문서 데이터베이스는 컬렉션 수준 작업에 범위가 지정된 역할로 같은 구조를 구현합니다. 정확히 하나의 컬렉션에 대해 find와 insert를 부여받은 역할이 그 예입니다. 개념은 보편적이며, 다른 것은 사용 편의성입니다. SQL 권한 부여와 역할 문서는 코드로 관리하는 반면, BaaS 플랫폼은 같은 매트릭스를 대시보드 토글로 보여 줍니다.

콘텐츠 유형별 권장 설정

이 표는 대부분의 출시에 실제로 필요한 체크리스트입니다. 마지막 열이 항상 같다는 점과, 그와 짝을 이루는 규칙에 주목해야 합니다. 프로덕션에서는 클라이언트 측 클래스 생성을 꺼서, 스키마가 의도한 경우에만 바뀌게 해야 합니다.

일반적인 사용 사례

• 프로덕션 스키마 동결. 모든 클래스에서 addField를 끕니다. 클라이언트 트래픽 때문에 클래스가 생기거나 구조가 바뀌는 일이 사라집니다.
• 읽기 전용 참조 데이터. 카탈로그와 설정은 누구나 읽을 수 있고, 쓰기는 서버 코드만 할 수 있습니다. 위의 Config 패턴입니다.
• 쓰기 전용 수신함. 피드백과 텔레메트리 클래스는 클라이언트가 생성만 할 수 있고 읽을 수는 없습니다. 애플리케이션 계층 코드가 자주 놓치는 역방향 관문입니다.
• 역할별로 나뉜 관리 화면. 앱은 자유롭게 읽되, update와 delete는 admin 역할에만 허용합니다.
• 고전적인 데이터 덤프 방어. 앱 ID 하나로 열려 있는 User 클래스를 조회하는 악명 높은 curl 한 줄짜리 명령은, 클래스가 인증을 요구하면 find 관문에서 막힙니다.

클래스 관문과 서버 코드 중 무엇으로 강제해야 할까? 결정 매트릭스

둘은 조합됩니다. 정말로 민감한 클래스를 위한 강화 패턴은 CLP를 완전히 잠그고 서버 측 함수만을 유일한 출입구로 노출하는 것입니다. 클래스 관문은 아무도 그 단일 진입점을 우회하지 못하도록 보장합니다.

한계와 트레이드오프

• 클래스 단위는 정의상 굵은 단위입니다. 행 단위의 규칙은 ACL과 포인터 권한의 몫이고, 조건부 규칙은 서버 측 검증의 몫입니다. CLP는 통제할 뿐 판단하지 않습니다.
• 기본값은 개발에 맞게 관대합니다. 프로토타입이 빠르게 진행되도록 새 클래스는 열린 상태로 생성됩니다. 출시 전에 위의 표대로 설정을 바꾸는 작업은 자동으로 일어나지 않으며, 규율의 문제입니다.
• 마스터 키는 모든 것을 무시합니다. 이 키가 닿는 곳에서는 이 글의 모든 관문이 무력화됩니다. 그래서 마스터 키는 서버 측에만 두고, 작업 단위로 사용하며, 클라이언트에는 절대 포함하지 않습니다.
• 강제 범위에 빈틈이 없어야 합니다. 실시간 구독과 특수 엔드포인트에는 과거에 강제의 빈틈이 있었습니다. 플랫폼을 최신 상태로 유지하고, 대시보드만이 아니라 실제 클라이언트에서 관문을 테스트해야 합니다.
• 토글도 리뷰가 필요합니다. 선언형 보안은 누군가 감사할 때에만 감사 가능한 보안이 됩니다. 설정 매트릭스는 몇몇 사람의 기억이 아니라 출시 체크리스트에 있어야 합니다.

Back4app에서의 CLP

Back4app은 관리형 데이터베이스, 자동 생성되는 REST 및 GraphQL API, 인증, 파일 스토리지, Cloud Code 서버리스 함수를 결합한 오픈소스 Backend as a Service(BaaS) 플랫폼입니다. 클래스 수준 권한은 Back4app의 스키마 보안을 시각화한 것입니다. 대시보드의 모든 클래스가 작업 매트릭스를 체크박스로 제공합니다. 공개, 인증 필수, 역할별 설정에 더해 포인터 권한과 보호 필드까지 있으며, 이 모든 것이 SDK, REST, GraphQL을 가리지 않고 모든 요청마다 서버 측에서 강제됩니다. 그 아래에는 객체별 ACL이 있고, 그 위에는 로직이 필요한 규칙을 위한 Cloud Code 트리거가 있습니다. 보안 가이드라인은 출시 전 점검 전체를 안내합니다. 이 글의 설정 매트릭스를 클릭 하나하나로 적용하는 과정입니다.