인가 — 유미위키

어떤 상대가 어떤 자원을 만져도 되는지 정하는 일입니다. 만져도 된다고 내주는 승인이 인가입니다. 같은 상대라도 자원마다 답이 다릅니다. 같은 자원이라도 읽기와 쓰기의 답이 다릅니다.

상세

회사 출입증을 떠올리면 쉽습니다. 정문을 통과한 사람이라고 해서 서버실 문까지 열리지는 않습니다.

인터넷 보안 용어집 RFC(Request for Comments, 의견 요청) 4949 는 인가를 시스템 개체에 시스템 자원 접근을 허락해 주는 승인이라고 정의합니다. 같은 문서는 그 승인을 내주는 과정 자체도 인가라고 적습니다. 결과를 가리키기도 하고 그 결과를 만드는 절차를 가리키기도 합니다.

하나의 인가는 하나 이상의 시스템 자원에 대해 읽기·쓰기·실행 같은 특정 접근 방식을 지정할 수 있습니다. 같은 용어집은 인가의 뜻과 인가가 얼마나 잘게 나뉘는지가 응용과 구현에 달려 있다고 적습니다. 어디까지를 한 덩어리로 묶어 허락할지가 자리마다 다르다는 말입니다.

인가 판정에 들어가는 것은 셋입니다. 누가, 무엇을, 어떤 연산으로입니다. 용어집은 형식 모형의 자리에서 접근 제어를 정보 시스템 안 주체와 객체 사이 상호작용에 걸리는 제약이라고 정의합니다. 같은 용어집은 접근 제어를 하나의 과정으로도 적습니다. 자원 사용이 보안 정책에 따라 규제되는 과정입니다. 사용은 그 정책이 인가한 개체에만 허용됩니다. 인가는 그 과정이 내리는 답입니다.

flowchart TD
    A["요청 · 주체 · 객체 · 연산"] --> B[보안 정책]
    B --> C{정책이 허용하나}
    C -->|허용| D[접근]
    C -->|아니다| E[거부]

요청이 들어오면 주체와 객체와 연산을 보안 정책에 견줍니다. 정책이 허용하는 조합이면 접근이 이루어집니다. 아니면 거부됩니다.

같은 일을 부르는 이름은 자리마다 다릅니다. 용어집은 공개키 기반구조에서는 인가라는 말을, 역할 기반 접근 제어에서는 권한이라는 말을, 컴퓨터 운영체제에서는 특권이라는 말을 쓰기를 권합니다. 뜻이 갈리는 것이 아니라 같은 것을 부르는 이름이 갈리는 것입니다.

그래서 인가 판정은 한 자리에만 있지 않습니다. 운영체제는 프로세스가 가진 자격증명을 보고 권한 검사를 합니다. 데이터베이스는 역할이 그 객체에 그 연산을 할 수 있는지 봅니다. 클러스터는 요청한 쪽이 그 자원에 그 동사를 쓸 수 있는지 봅니다. 웹은 서버가 요청 이행을 거부하는 자리에서 같은 판정을 드러냅니다.

배경

컴퓨터에 저장된 정보를 허락 없이 쓰거나 고치는 일을 막아야 했습니다. 1975년에 나온 Saltzer 와 Schroeder 의 정보 보호 논문이 이 문제를 다룹니다. 하드웨어든 소프트웨어든 정보 보호를 떠받치는 데 필요한 구조가 무엇인지가 그 논문의 주제입니다.

신원을 확인하는 것만으로는 이 문제가 풀리지 않습니다. 같은 논문의 용어 정리는 두 낱말을 따로 세웁니다. 인증은 보호 시스템 바깥에 있는 사람이나 다른 행위자가 요청을 할 때 그 신원을 검증하는 일입니다. 인가는 어떤 주체에게 특정 정보에 대한 접근을 내주는 일입니다. 누구인지 아는 것과 무엇을 해도 되는지 정하는 것이 별개의 결정이라는 말입니다.

그러면 얼마나 내줄 것인가라는 물음이 남습니다. 같은 논문은 최소 권한을 설계 원칙으로 답합니다. 모든 프로그램과 모든 사용자는 일을 마치는 데 필요한 최소한의 권한 집합만 써서 동작해야 한다는 것입니다. 이 원칙이 주로 노리는 것은 사고나 오류로 생길 수 있는 피해를 제한하는 것입니다. 특권을 가진 프로그램들 사이에 있을 수 있는 상호작용의 수도 올바른 동작에 필요한 최소로 줄어듭니다. 그만큼 의도하지 않았거나 원하지 않았거나 부적절한 특권 사용이 일어날 여지가 줄어든다고 그 논문은 적습니다.

갈래

권한을 어디에 적어 두느냐가 축입니다. 자원 쪽에 적을 수도 있고, 그것을 쓰는 쪽에 적을 수도 있습니다. 사이에 역할이나 속성을 두고 적을 수도 있습니다.

접근 제어 목록

접근 제어 목록(access control list)은 자원 쪽에 적는 방식입니다. 용어집은 이것을 시스템 자원에 대한 접근 제어를 구현하는 장치로 정의합니다. 그 자원에 접근이 허용된 시스템 개체들을 죽 적습니다. 개체마다 어떤 접근 방식이 주어졌는지도 명시적으로든 암묵적으로든 밝힙니다.

자격 목록

자격 목록(capability list)은 주체 쪽에 적는 방식입니다. 용어집은 이것을 시스템 개체에 대한 접근 제어를 구현하는 장치로 정의합니다. 그 개체가 접근을 허용받은 시스템 자원들을 죽 적습니다. 자원마다 허용된 접근 방식도 역시 명시적으로든 암묵적으로든 밝힙니다. 적는 방향이 접근 제어 목록과 반대입니다.

Saltzer 와 Schroeder 는 자격을 위조할 수 없는 표로 정의합니다. 그 표를 내밀면 표에 이름이 적힌 객체에 접근할 권한을 가졌다는 반박할 수 없는 증거가 됩니다.

역할 기반 접근 제어

역할 기반 접근 제어(role-based access control)는 사람과 권한 사이에 역할을 놓는 방식입니다. 용어집은 이것을 신원 기반 접근 제어의 한 형태로 정의합니다. 식별되고 통제되는 시스템 개체가 조직이나 프로세스 안의 기능적 직위라는 점이 다릅니다.

관리자는 시스템에서 기능을 수행하는 데 필요한 만큼 역할에 권한을 배정합니다. 사용자 신원을 역할에 배정하는 일은 그와 따로 합니다. 사용자는 등록된 신원으로 시스템에 접근합니다. 그 상태에서 자기가 배정받은 역할로 세션을 시작합니다. 그러면 그 역할에 배정된 권한을 행사할 수 있게 됩니다.

속성 기반 접근 제어

속성 기반 접근 제어(attribute based access control)는 속성을 보고 정하는 방식입니다. 미국 국립표준기술연구소 NIST(National Institute of Standards and Technology) 의 SP(Special Publication, 특별 간행물) 800-162 는 이것을 논리적 접근 제어 방법론으로 정의합니다.

일련의 연산을 수행할 인가를, 주체와 객체와 요청된 연산에 딸린 속성을 평가해서 정합니다. 경우에 따라서는 환경 조건까지 봅니다. 견주는 대상은 주어진 속성 집합에 허용되는 연산을 기술한 정책이나 규칙이나 관계입니다.

예시

PostgreSQL

PostgreSQL 은 GRANT 문으로 권한을 내줍니다. 공식 문서는 이 명령에 두 갈래가 있다고 적습니다. 하나는 데이터베이스 객체에 권한을 주는 것이고, 하나는 역할의 멤버십을 주는 것입니다.

SQL

GRANT INSERT ON films TO PUBLIC;
GRANT ALL PRIVILEGES ON kinds TO manuel;

첫 줄은 films 테이블에 모든 사용자가 삽입 권한을 갖게 합니다. 둘째 줄은 kinds 뷰에 대해 줄 수 있는 모든 권한을 manuel 이라는 사용자에게 줍니다. 줄 수 있는 권한의 이름은 정해져 있습니다. SELECT · INSERT · UPDATE · DELETE · TRUNCATE · REFERENCES · TRIGGER · CREATE · CONNECT · TEMPORARY · EXECUTE · USAGE · SET · ALTER SYSTEM · MAINTAIN 입니다. 이렇게 준 권한은 이미 준 것이 있으면 그 위에 더해집니다.

쿠버네티스

쿠버네티스는 역할 기반 접근 제어로 인가를 판정합니다. 공식 문서는 이 방식이 rbac.authorization.k8s.io 라는 API(Application Programming Interface, 응용 프로그램 인터페이스) 그룹을 써서 인가 판정을 이끈다고 적습니다. 덕분에 정책을 쿠버네티스 API 를 통해 동적으로 설정할 수 있습니다.

YAML

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: default
  name: pod-reader
rules:
- apiGroups: [""] # "" indicates the core API group
  resources: ["pods"]
  verbs: ["get", "watch", "list"]

default 네임스페이스에서 파드 읽기 권한을 주는 역할입니다. rules 아래 세 칸이 판정의 입력을 그대로 드러냅니다. 어느 API 그룹의, 어느 자원에, 어떤 동사를 허용하는지입니다. verbs 에 적힌 get · watch · list 가 이 역할이 허용하는 연산입니다.

Linux

Linux 는 파일마다 모드 비트를 둡니다. chmod(2) 설명은 이 시스템콜이 파일의 모드 비트를 바꾼다고 적습니다. 파일 모드는 파일 권한 비트에 set-user-ID · set-group-ID · sticky 비트를 더한 것입니다.

S_IRUSR (00400) read by owner
S_IWUSR (00200) write by owner
S_IXUSR (00100) execute/search by owner
S_IRGRP (00040) read by group
S_IWGRP (00020) write by group
S_IXGRP (00010) execute/search by group

소유자와 그룹에 읽기·쓰기·실행이 따로 붙습니다. 괄호 안의 값은 8진수로 적힌 비트 자리입니다. 읽기·쓰기·실행이라는 접근 방식이 여기서는 파일에 붙은 숫자 한 벌이 됩니다.

Linux 는 프로세스 쪽에도 권한을 둡니다. capabilities(7) 은 전통적인 유닉스 구현이 권한 검사를 하려고 프로세스를 두 갈래로 갈랐다고 적습니다. 유효 사용자 아이디가 0인 특권 프로세스와 그렇지 않은 비특권 프로세스입니다. 특권 프로세스는 커널의 권한 검사를 전부 건너뜁니다. 비특권 프로세스는 자기 자격증명에 따라 온전한 권한 검사를 받습니다. Linux 2.2 부터는 슈퍼유저에 묶여 있던 특권을 케이퍼빌리티라는 단위로 쪼개서 각각 켜고 끌 수 있게 했습니다.

경계

HTTP(HyperText Transfer Protocol, 하이퍼텍스트 전송 규약) 401 Unauthorized 도 인가 실패인가. 아닙니다.

이름은 인가되지 않았다는 말입니다. 명세가 정하는 조건은 다릅니다. RFC 9110 은 401 을 대상 자원에 대한 유효한 인증 자격증명이 없어서 요청이 적용되지 않았음을 가리키는 상태 코드로 정의합니다. 401 을 만드는 서버는 대상 자원에 적용되는 챌린지를 최소한 하나 담아 WWW-Authenticate 헤더 필드를 반드시 보내야 합니다. 다시 묻는 것은 누구냐는 물음입니다.

인가 판정이 거부로 떨어진 자리를 알리는 코드는 403 Forbidden 입니다. 같은 문서는 403 을 서버가 요청을 이해했지만 이행하기를 거부한다는 뜻으로 정의합니다. 요청에 인증 자격증명이 들어 있었다면 서버는 그 자격증명이 접근을 허용하기에 충분하지 않다고 본 것입니다. 클라이언트는 같은 자격증명으로 요청을 자동으로 되풀이하지 않아야 합니다. 다만 같은 문서는 자격증명과 무관한 이유로 요청이 금지될 수도 있다고 적습니다.

경계가 흐려지는 자리도 명세 안에 있습니다. 401 을 정의한 절은 요청에 인증 자격증명이 들어 있었다면 그 응답이 그 자격증명에 대해 인가가 거부됐음을 가리킨다고도 적습니다. 그래도 401 이 요구하는 것은 새 자격증명입니다. 사용자 에이전트는 새로 얻거나 바꾼 Authorization 헤더 필드를 담아 요청을 되풀이해도 됩니다. 인가 판정의 결과 자체를 알리는 자리는 403 입니다.

인가

상세

배경

갈래

접근 제어 목록

자격 목록

역할 기반 접근 제어

속성 기반 접근 제어

예시

PostgreSQL

쿠버네티스

Linux

경계

관련 항목

인가가 속하는 상위 개념

인가에 앞서 신원을 확인하는 절차

권한을 부르는 이름과 이를 제한하는 원칙

인가 판정 방식의 하위 종류

인가를 실제로 구현한 제품과 구성 요소

인가를 정의하는 표준과 문서

인증 실패와 인가 실패를 가르는 HTTP 요소