AuthZ(권한 부여)란 무엇인가?

AuthZ란 무엇이며 AuthN과 어떻게 다른가?#

AuthZ는 권한 부여의 줄임말입니다. 권한 부여는 인증과는 별개의 메커니즘입니다. 인증이 사용자의 신원을 확인하는 반면, 권한 부여는 사용자가 특정 리소스에 접근할 수 있는지, 그리고 어떤 작업을 수행할 수 있는지를 결정합니다.

실제 사례에서 리소스는 소프트웨어, 시스템, 문서, 주문 및 자산 등을 포함할 수 있습니다. 권한 부여는 누가 이러한 리소스에 접근할 수 있는지, 어떠한 조건에서 접근할 수 있는지를 지정하는 추가적인 제어 계층을 제공합니다.

AuthZ는 어떻게 작동하는가?#

권한 부여는 인증과는 별개이지만 종종 연결되어 있습니다. 예를 들어, OAuth 2.0, OIDC, SAML과 같은 표준 프로토콜은 토큰 기반 권한 부여 메커니즘을 통합합니다.

토큰 기반 권한 부여 시스템에서 권한 부여 서버는 사용자에게 액세스 토큰을 부여합니다. 이 토큰에는 권한이 포함되어 있으며 사용자가 특정 리소스에 접근할 수 있는지를 결정합니다.

사용자에게 직접 권한을 할당하는 것은 비효율적일 수 있으며, 특히 더 세부적인 조건이 필요한 경우 더욱 그렇습니다. 예를 들어, 접근은 사용자의 위치와 같은 특정 상황에 따라 달라질 수 있으며, 이는 더 나은 권한 관리를 위한 접근 제어 정책을 필요로 합니다.

다음은 권한 부여가 작동하는 단계별 고수준 흐름입니다:

1. 인증 시작: 사용자는 이메일과 비밀번호를 사용하는 것과 같은 식별자와 방법을 선택하여 로그인합니다.
2. 권한 요청: 로그인 후, 사용자는 자신의 사용자 ID 및 역할과 같은 세부 정보를 포함하여 리소스에 접근을 요청합니다.
3. 접근 제어 확인: 시스템은 역할 기반 또는 속성 기반 규칙과 같은 사전 정의된 권한 부여 정책과 요청을 비교합니다.
4. 권한 결정: 시스템은 정책 및 권한에 기반해 접근을 허용 또는 거부할지를 결정합니다.

OAuth 2.0 권한 요청 흐름을 자세히 이해하려면, 권한 요청을 확인하세요.

권한 부여 유형은 무엇인가?#

역할 기반 접근 제어와 작동 방식#

Role-Based Access Control (RBAC)은 역할을 사용하여 접근을 관리합니다. 각 사용자에게 하나 이상의 미리 정의된 역할이 할당되며, 각 역할에는 일련의 권한이 포함됩니다. RBAC의 핵심은 주체(또는 사용자), 역할, 권한 간의 관계를 이해하는 것입니다.

역할 기반 접근 제어(RBAC)가 어떻게 작동하는지 이해하기 위해 알아야 할 것은 다음과 같습니다:

1. 주체: 이는 사용자 또는 기계 간의 애플리케이션과 같은 인간이 아닌 엔티티일 수 있습니다.
2. 역할: 직무 기능이나 책임을 나타냅니다. 예: admin, member
3. 권한: 특정 리소스에 허용되는 작업을 지정합니다. 예: read: order.

속성 기반 접근 제어와 작동 방식#

Attribute-Based Access Control (ABAC)은 권한 부여에서 널리 사용되며 역할뿐 아니라 특정 엔터티의 속성을 사용하여 더 복잡한 시나리오를 지원합니다.

예를 들어, 한 회사는 직원이 자신의 직무 역할, 위치, 문서의 분류 수준에 따라 민감한 파일에 대한 제어된 접근을 필요로 하는 글로벌 문서 공유 플랫폼을 관리합니다.

속성은 다음과 같은 방식으로 설계될 수 있습니다:

1. 사용자 속성: 역할 (예: “Manager”, “Engineer”), 위치 (예: “US”, “Europe”)
2. 리소스 속성: 문서 유형 (예: “Financial Report”, “Design File”), 분류 수준 (예: “Confidential”)
3. 환경 속성: 접근 시간 (예: “During Work Hours”), 장치 유형 (예: “Company Laptop”)

또한, 정책 기반 접근 제어(PBAC)와 같은 다른 접근 제어 모델도 있습니다. 각 모델은 장단점이 있으며, 모델 선택은 사용 사례와 요구 사항에 따라 달라집니다.

AuthZ 사례와 예시#

B2C 소프트웨어#

B2C 소프트웨어는 종종 비즈니스 요구에 기반한 특정 역할을 필요로 합니다. 예를 들어, 서점 관리 앱은 리소스와 서비스를 관리하는 등 다른 책임을 가진 역할을 포함할 수 있습니다.

B2B 멀티 테넌트 앱#

B2B 앱은 종종 조직을 대표하는 각 테넌트가 있는 멀티 테넌트 아키텍처를 사용합니다. 조직 내에서는 admin과 member 같은 역할이 필요합니다. 여기서 권한 부여(AuthZ)는 조직 수준에서 사용자 관리를 위한 중요한 역할을 하며, 종종 역할 기반 접근 제어(RBAC)를 사용합니다.

기계 간 권한 부여#

기계 간 통신은 인간의 상호작용 없이 서비스 간에 직접 발생합니다. 예를 들어 API 서비스를 호출하는 것과 같습니다. 이는 보안, 동적 및 세분화된 접근을 보장하기 위해 종종 토큰(OAuth 2.0 액세스 토큰 등)을 포함합니다.

AuthZ에 대한 모범 사례는 무엇인가?#

다음은 보안 및 효과적인 접근 제어를 보장하기 위한 권한 부여(AuthZ) 모범 사례입니다:

• 최소 권한의 원칙

  이는 무단 접근 또는 손상된 계정으로 인한 피해의 위험을 최소화합니다. 사용자 및 시스템은 자신의 역할에 필요한 리소스와 작업만 접근할 수 있어야 합니다.

• 토큰 기반 권한 부여 사용

  토큰 기반 접근 제어는 더 많은 유연성과 세부적인 제어를 제공하며, 오픈 표준을 준수합니다. 안전한 토큰(OAuth 2.0, JWT 등)을 사용하여 시간에 민감하고 범위가 있는 접근을 허용하세요.

• 정기적인 감사 및 모니터링

  접근 로그 및 권한 부여 정책을 정기적으로 리뷰하여 이상이나 오래된 권한을 감지해야 합니다.

• 직무 분리를 적용

  구체적인 작업 및 리소스를 정의하는 세분화된 권한 예: 읽기, 쓰기, 삭제) 같은 권한을 정의하여 시작합니다. 역할을 만들 때 명확한 역할 이름을 사용하고 직무 분리를 강제하여 단일 사용자에 의한 사기나 실수의 위험을 최소화합니다.

• 멀티 테넌트 지원(적용 가능한 경우)

  멀티 테넌트 시스템에서는 테넌트 격리가 중요합니다. 이는 역할 기반 접근 제어와 결합하여 데이터 리소스의 구분을 달성하고, 적절한 역할이 그들의 테넌트 내에서만 리소스에 접근할 수 있도록 보장합니다. 이는 다른 테넌트의 리소스에 대한 우발적 또는 악의적인 접근을 방지합니다.

• 동적으로 접근 철회

  AuthZ 시스템을 설계할 때, 조건이 변경되면 (예: 역할 업데이트, 고용 해지) 즉시 권한을 업데이트하거나 철회할 수 있도록 보장하세요. 이는 동적 API 체크, 웹후크 및 기타 방법을 통해 달성할 수 있습니다. 목표는 실시간으로 무단 접근을 방지하는 것입니다.

AuthZ(권한 부여)와 Auth(인증)의 차이는 무엇인가?#

인증과 권한 부여의 차이는 신원 및 접근 관리의 목적과 과정에 있습니다.

AuthN(인증)은 “누구이며 어떤 신원을 소유하고 있는가”라는 질문에 답합니다. 이는 사용자, 서비스 또는 장치의 신원을 확인하는 과정입니다. 인증은 시스템 또는 리소스에 접근하려는 엔터티가 진정한지를 보장합니다. 일반적인 방법은 비밀번호, 생체 인식, 그리고 이중 인증(2FA) 등이 있습니다. 예를 들어, 이메일과 비밀번호를 사용하여 계정에 로그인할 때 시스템은 인증을 통해 신원을 확인합니다.

AuthZ(권한 부여)는 “무엇을 할 수 있는가?”라는 질문에 답합니다. 이는 사용자의 권한이나 역할에 기반해 리소스에 대한 접근을 허용하거나 거부하는 과정입니다. 권한 부여는 인증이 끝난 후 이루어지며, 인증된 사용자가 수행할 수 있는 작업을 결정합니다. 예를 들어, 로그인 후, 관리자 사용자는 설정을 수정할 수 있는 반면, 일반 사용자는 이를 볼 수만 있습니다.

요약하면, AuthN(인증)은 신원을 확인하고, AuthZ(권한 부여)는 접근을 정의합니다. 인증이 먼저 이루어지고, 권한 부여가 뒤따라 자원의 안전하고 적절한 사용을 보장합니다.

Logto를 사용하여 AuthZ(권한 부여) 구축하기#

Logto Cloud는 OIDC, OAuth 2.0 및 SAML과 같은 오픈 표준 프로토콜에 기반한 주요 권한 부여 서비스를 제공합니다. 여기에는 다양한 관점에서 권한 부여 요구 사항을 충족시키기 위한 역할 기반 접근 제어, 조직(멀티 테넌시), 사용자 정의 토큰 클레임 기능이 포함되어 있습니다.