액세스 제어를 통한 인가
인가란 웹 애플리케이션의 다양한 부분과 자산에 대한 접근을 사용자에게 부여하는 프로세스입니다. 사용자를 인가하는 일반적인 방법은 액세스 제어를 통한 것으로, 사이트 관리자가 사용자 및 기타 엔티티가 특정 리소스에 접근하기 위해 어떤 권한을 부여받아야 하는지를 정의합니다.
인가는 인증과 혼동해서는 안 됩니다. 인증이란 사용자가 자신이 주장하는 사람임을 검증하는 프로세스로, 일반적으로 계정 자격 증명을 제공함으로써 이루어집니다. 사용자가 인증된 후에도, 사용자가 요청한 리소스에 접근할 수 있는지 확인하기 위해 모든 요청에서 인가 프로세스를 수행해야 합니다.
GraphQL을 통해 애플리케이션에 접근할 때, 사용자가 스키마에서 요청한 요소에 대한 접근 권한을 가지고 있는지 검증해야 합니다. 인가 로직은 GraphQL 레이어 내에 코딩되어야 할까요?
답은 아니오입니다. graphql.org의 문서에서 명확히 밝히고 있듯이, 인가 로직은 비즈니스 로직 레이어에 속하며, GraphQL은 그곳에서 이를 접근합니다. 이렇게 하면 애플리케이션은 인가를 위한 단일 진실 공급원(즉, WordPress가 제공하는 것)을 가질 수 있습니다:
Gato GraphQL은 이 원칙을 존중하여 WordPress가 제공하는 인가 메커니즘을 반영(및 엔진 내부에서 위임)합니다.
액세스 제어 정책
애플리케이션에 구현할 수 있는 여러 액세스 제어 정책 중에서, 가장 널리 사용되는 두 가지는 역할 기반 액세스 제어(RBAC)와 속성 기반 액세스 제어(ABAC)입니다.
WordPress와 Gato GraphQL은 두 가지 모두를 지원합니다.
역할 기반 액세스 제어에서는 역할을 기반으로 권한을 부여한 다음, 해당 역할을 사용자에게 할당합니다. 예를 들어 WordPress에는 모든 리소스에 접근할 수 있는 administrator 역할과, 블로그 게시물 작성 및 게시, 작성만, 또는 읽기만 가능한 것처럼 다양한 수준으로 제한된 권한을 가진 editor, author, contributor, subscriber 역할이 있습니다.
속성 기반 액세스 제어에서는 사용자, 자산, 환경 조건(시간대나 방문자의 IP 등)을 포함한 다양한 엔티티에 할당할 수 있는 메타데이터를 기반으로 권한이 부여됩니다. 예를 들어 WordPress에서는 edit_others_posts 기능을 사용하여 사용자가 다른 사용자의 게시물을 편집할 수 있는지 검증합니다.
일반적으로 ABAC는 RBAC보다 선호됩니다. 왜냐하면 세분화된 제어로 권한을 구성할 수 있고, 권한의 목적이 명확하기 때문입니다.
예를 들어 WordPress에서 editor 역할은 edit_others_posts 기능을 갖지만, author 역할을 가진 사람이 다른 저자의 게시물을 편집할 수 있도록 허용하면서도 편집자에게 부여되는 전체 권한 집합(다른 저자의 게시물 삭제 권한 등)을 부여하지 않고 싶을 수 있습니다. 따라서 edit_others_posts 기능을 부여하고 이 조건을 확인하는 것이 editor 역할을 확인하는 것보다 더 적절합니다.
가시성 정의
사용자가 GraphQL 스키마에서 요청한 필드에 접근할 권한이 없을 때, 반환되는 오류는 어떠해야 할까요?
스키마에 원하는 가시성, 즉 퍼블릭 또는 프라이빗에 따라 두 가지 가능성이 있습니다.
퍼블릭 스키마의 경우, 노출되는 GraphQL 스키마는 모든 사용자에게 동일하며, 각 필드에는 접근에 필요한 권한이 설명되어 있습니다. 접근할 수 없는 필드를 요청하면, 오류 메시지가 사용자에게 접근이 허용되지 않는 이유를 설명합니다.
프라이빗 스키마의 경우, GraphQL 스키마는 사용자마다 맞춤화되며, 해당 사용자가 접근할 수 있는 필드만 노출됩니다. 접근할 수 없는 필드를 요청하면, 오류 메시지는 해당 필드가 존재하지 않는다고 나타냅니다.
사용자 인터페이스를 통한 액세스 제어
Gato GraphQL에서는 액세스 제어 규칙이 런타임에 스키마에 주입됩니다. 이는 액세스 제어 목록을 통한 사용자 정의 구성으로 이루어집니다. 이를 통해 GraphQL 레이어는 코드를 업데이트하거나 스키마를 재컴파일할 필요 없이 액세스 제어 정책의 변경 사항을 즉시 반영합니다:
사이트 관리자는 ACL을 구성하여 다음을 선택합니다:
- 검증할 필드
- 다음 중에서 선택하는 검증 규칙:
- 사용자가 로그인되어 있어야 하는가?
- 사용자가 로그아웃되어 있어야 하는가?
- 사용자가 특정 역할을 가져야 하는가?
- 사용자가 특정 기능을 가져야 하는가?
- 규칙별 구성:
- 어떤 역할인가?
- 어떤 기능인가?
- 가시성:
- 기본값(스키마에 할당된 것과 동일)?
- 퍼블릭?
- 프라이빗?
