신원, 역할, 권한 집합, 레코드 접근, 필드 보안 — 전체 접근 모델을 한 페이지에서.

권한

ObjectOS는 엔터프라이즈 소프트웨어에서 20년간 검증된 방식을 차용한 계층형 접근 모델을 갖추고 있습니다: 신원 → 역할 → 권한 집합 → 레코드 접근 → 필드 보안. 각 계층은 서로 다른 질문에 답하며, 필요하지 않은 계층은 무시할 수 있습니다.

하나의 다이어그램으로 보는 모델

Authentication       Who is the caller?
        ↓
Identity             Which user/org/membership is active?
        ↓
Roles                Where do they sit in the hierarchy?
        ↓
Permission sets      What CAN they do — apps, objects, fields, system?
        ↓
Record access        WHICH records can they touch?
        ↓
Field security       For those records, which FIELDS are readable / writable?

각 계층은 보안 플러그인에 의해 적용됩니다. 단순한 앱이라면 권한 집합만 사용하고(역할이나 공유 규칙 없이), 요구 사항이 생길 때 나머지를 추가할 수 있습니다.

계층 1 — 신원

신원 객체는 프로젝트 데이터베이스에 존재합니다. 가장 중요한 것들은 다음과 같습니다:

객체	의미
`sys_user`	인증할 수 있는 사람 또는 서비스 계정
`sys_organization`	테넌트 / 워크스페이스 경계(멀티테넌트 앱)
`sys_member`	조직 내 사용자의 멤버십(역할은 멤버십 단위로 할당됨)
`sys_department`, `sys_team`	공유 규칙을 위한 선택적 조직 구조
`sys_invitation`	수락을 기다리는 대기 중인 초대
`sys_session`	활성 인증 세션
`sys_api_key`	사용자에 바인딩된 장기 프로그래밍 자격 증명

멀티테넌트 배포에서는:

사용자는 프로젝트 데이터베이스 범위로 한정됩니다.
세션은 프로젝트 호스트명 범위로 한정됩니다.
행 수준 검사는 현재 사용자의 조직과 권한을 사용합니다.
컨트롤 플레인 사용자는 자동으로 비즈니스 사용자가 아닙니다 — 플랫폼 SSO 또는 명시적 프로비저닝을 통해 매핑되어야 합니다.

이들은 런타임에 Console(/_console/)에서 생성/관리하거나, 새 환경을 위해 objectstack.config.ts에 시드할 수 있습니다.

계층 2 — 역할

역할은 조직도(CFO → Finance Manager → Analyst)를 모델링합니다. 역할이 존재하는 주된 이유는 공유 규칙과 보고서가 "레코드 소유자의 관리자"와 같은 표현을 할 수 있게 하기 위함입니다. 계층적 접근이 필요할 때 역할을 사용하고, 평면적인 팀에서는 생략하세요.

역할을 참조하세요.

계층 3 — 권한 집합

권한 집합은 기능을 부여하는 주요 방법입니다. 사용자에게 직접 연결되거나 역할을 통해 연결됩니다.

무엇을 부여하는가

유형	예시
애플리케이션 접근	CRM 열기, 지원 포털 열기
객체 권한	객체의 레코드 생성 / 읽기 / 수정 / 삭제
필드 권한	특정 필드 읽기 또는 수정
시스템 권한	Console 접근, 보고서 실행, 데이터 내보내기, 감사 로그 보기
통합 권한	API 키 사용, 웹훅 구성, 관리 작업 실행

객체 권한 플래그

다음은 보안 플러그인이 검사하는 정확한 플래그 이름입니다:

플래그	의미
`allowRead`	레코드 접근을 통해 사용자가 볼 수 있는 레코드 읽기
`allowCreate`	새 레코드 생성
`allowEdit`	사용자가 볼 수 있는 레코드 수정
`allowDelete`	사용자가 볼 수 있는 레코드 삭제
`viewAllRecords`	레코드 접근 규칙을 무시하고 해당 객체의 모든 레코드 읽기
`modifyAllRecords`	모든 레코드 수정/삭제; `viewAllRecords`를 함의함

viewAllRecords와 modifyAllRecords는 해당 객체에 대한 테넌트 전역 슈퍼유저 권한입니다. 명시적인 관리용 권한 집합에만 한정하고, 사용자 대상 역할에서는 제외하세요.

권한 집합을 참조하세요.

계층 4 — 레코드 접근

viewAllRecords가 없는 사용자의 경우, 어떤 행을 볼 수 있을까요?

이 모델은 다음을 지원합니다:

암묵적 소유권(사용자가 생성했거나 소유한 행)
공유 규칙(선언적 — "팀 A는 팀 A의 레코드를 본다")
명시적 공유(sys_record_share 행 — 일회성 공유)
조직 범위 지정(행의 organization_id가 사용자의 조직과 일치)

레코드 접근을 참조하세요.

계층 5 — 필드 보안

사용자가 레코드를 볼 수 있는 경우에도, 개별 필드는 다음과 같이 설정될 수 있습니다:

숨김 — 필드가 API 및 UI 응답에서 제거됩니다.
읽기 전용 — 필드는 반환되지만 쓰기 시 거부됩니다.

필드 보안은 객체별 + 권한 집합별로 적용됩니다. 일반적인 사용 예:

HR 외부의 누구에게나 sys_user의 salary를 숨김.
지원 담당자에게 external_account_id를 읽을 수는 있지만 수정할 수는 없게 설정.

이는 객체 권한과 동일한 평가기에서 적용되므로 REST, ObjectQL, Console 전반에 걸쳐 일관되게 작동합니다.

어디서 시작할까

무엇을 만들고 있다면 …	사용
단일 팀 내부 도구	권한 집합만
관리자가 보고서를 보는 멀티팀 앱	역할 + 권한 집합
멀티테넌트 SaaS 형태의 앱	조직 범위 지정 + 권한 집합
PII가 있는 규제 대상 앱	그 위에 필드 보안 추가
복잡한 CRM 스타일 앱	전체 스택

진단 및 감사

/_console/는 평가되는 대로 모든 사용자의 유효 권한을 보여줍니다.
감사 로그(sys_audit_log)는 권한에 민감한 변경 사항(권한 부여, 역할 할당, 권한 집합 편집)을 기록합니다.
거부된 요청은 실패한 규칙(객체 권한, 레코드 접근, 필드 보안 중 무엇인지)을 기록하므로, 지원 담당자가 "왜 이걸 볼 수 없나요?"라는 질문에 빠르게 답할 수 있습니다.

권한

On this page