사전 접근 제어
개념

접근 제어

gabury1

누가 무엇을 해도 되는지를 요청이 올 때마다 판단해서 통과시키거나 막는 일입니다. 판단의 기준은 미리 정해 둔 정책입니다. 거부로 판단되면 요청은 그 자리에서 끊깁니다.

상세

물건을 살 때마다 계산대의 카드 단말기는 카드사에 승인을 묻습니다. 승인이 떨어진 거래만 물건이 손에 들어옵니다. 다음에 또 사면 단말기는 또 묻습니다.

접근 제어는 어떤 주체가 어떤 객체에 어떤 조작을 하려는 것을 정책에 비추어 허용하거나 막는 일입니다. RFC(Request for Comments) 4949 는 이것을 시스템 자원의 사용이 보안 정책에 따라 규제되는 과정이라고 적습니다. 그리고 그 정책에 따라 인가된 개체에게만 사용이 허용된다고 덧붙입니다. 인가된 개체 자리에는 사용자·프로그램· 프로세스·다른 시스템이 들어갑니다. 같은 문서는 형식 모델의 뜻으로는 정보 시스템 안에서 주체와 객체 사이의 상호작용에 걸리는 제한이라고도 적습니다.

권한과 같은 말이 아닙니다. 권한은 미리 정해 둔 내용입니다. 접근 제어는 그 내용을 보고 판단하는 일, 그리고 판단대로 막는 일입니다.

판단하는 자리와 막는 자리는 나뉩니다. NIST(National Institute of Standards and Technology, 미국 국립표준기술연구소) 용어집은 인가 결정을 내리는 시스템 개체를 정책 결정 지점이라고 부릅니다. 그 결정을 요청하고 이어서 집행하는 시스템 개체는 정책 강제 지점입니다.

flowchart TD
    S[주체] -->|요청| E[강제 지점]
    E -->|판단을 묻는다| D[결정 지점]
    D -->|허용 또는 거부| E
    E -->|허용일 때만| O[객체]

강제 지점은 요청을 가로채는 자리에 있습니다. 결정 지점에 판단을 물은 뒤, 허용이라는 답을 받은 요청만 객체까지 보냅니다.

이 문서가 다루는 것은 논리적 접근 제어입니다. NIST 특별 간행물 800-162 는 속성 기반 접근 제어를 논리적 접근 제어 방법론이라고 부릅니다. RFC 4949 는 미국 정부 용법이라는 단서를 달아 뜻 하나를 더 싣습니다. 물리적·전자적·인적 통제를 써서 적절히 인가된 접근권을 가진 인원을 SCIF(Sensitive Compartmented Information Facility, 민감 구획 정보 시설)에 식별하거나 들여보내는 시스템입니다. 그쪽은 이 문서가 다루는 자리가 아닙니다.

배경

한 대의 기계를 여럿이 나눠 쓰게 되면서 한 사람의 정보가 다른 사람의 프로그램 옆에 놓였습니다. Saltzer 와 Schroeder 는 논문 초록에서 다루려는 문제를 이렇게 적습니다. 컴퓨터에 저장된 정보를 허가받지 않은 사용이나 변경으로부터 지키는 일입니다. 같은 초록은 그 보호를 받치는 데 필요한 하드웨어·소프트웨어 구조에 논문의 초점이 있다고 덧붙입니다.

지키려면 확인이 한 군데라도 빠지면 안 됩니다. 같은 논문은 설계 원칙 하나를 완전 조정이라고 부릅니다. 모든 객체에 대한 모든 접근이 권한 검사를 거쳐야 한다는 원칙입니다. 논문은 이 원칙이 체계적으로 적용될 때 보호 시스템의 주된 받침이 된다고 적습니다. 그리고 이 원칙이 시스템 전체를 보는 관점을 강제한다고 적습니다. 평상시 동작만이 아니라 초기화·복구·종료· 유지보수까지 그 관점에 들어갑니다. 모든 요청의 출처를 확실하게 식별하는 방법도 함께 요구됩니다.

성능을 얻으려고 권한 검사 결과를 기억해 두자는 제안은 회의적으로 살펴야 한다고 논문은 적습니다. 권한이 바뀌면 기억해 둔 결과도 체계적으로 갱신되어야 하기 때문입니다. 확인이 한 번의 사건이 아니라 계속 굴러가야 하는 일이 되는 자리가 여기입니다. 같은 논문의 용어집은 신원을 확인하는 일을 authenticate, 접근을 내주는 일을 authorize 로 갈라 적습니다. RFC 4949 도 두 낱말을 각각 독립 표제로 싣습니다.

갈래

무엇을 보고 허용 여부를 정하느냐가 축입니다. 정책을 누구의 재량으로 바꿀 수 있느냐가 그 축을 따라 같이 갈립니다.

임의적 접근 제어

임의적 접근 제어(Discretionary Access Control, DAC)는 접근 제어의 일정 부분을 객체 소유자의 재량에 맡깁니다. NIST 용어집은 소유자, 또는 그 객체의 접근을 통제하도록 인가된 다른 누군가가 누구에게 어떤 접근권을 줄지 정할 수 있다고 적습니다.

같은 용어집의 다른 정의는 그 재량이 어디까지 뻗는지를 나열합니다. 접근을 받은 주체가 정보를 다른 주체나 객체에 넘기는 것, 자기 특권을 다른 주체에게 주는 것, 주체·객체·정보 시스템·시스템 구성요소의 보안 속성을 바꾸는 것, 새로 만들거나 고친 객체에 붙을 보안 속성을 고르는 것, 접근 제어를 지배하는 규칙 자체를 바꾸는 것입니다. 정책은 이 가운데 하나 이상을 할 수 있다고 명시합니다. 강제적 접근 제어는 이 능력을 제한합니다.

강제적 접근 제어

강제적 접근 제어(Mandatory Access Control, MAC)는 정보 시스템 경계 안의 모든 주체와 객체에 일률적으로 강제되는 정책입니다. NIST 용어집은 접근을 받은 주체가 다음을 하지 못하도록 제약된다고 적습니다. 정보를 인가되지 않은 주체나 객체에 넘기는 것, 자기 특권을 다른 주체에게 주는 것, 주체·객체·정보 시스템·시스템 구성요소의 보안 속성을 하나 이상 바꾸는 것, 새로 만들거나 고친 객체에 붙을 보안 속성을 고르는 것, 접근 제어를 지배하는 규칙 자체를 바꾸는 것입니다.

첫 항목의 한정어가 임의적 접근 제어 쪽과 다릅니다. 그쪽은 정보를 다른 주체나 객체에 넘기는 것이고, 이쪽은 인가되지 않은 주체나 객체에 넘기는 것입니다. 정책을 정하는 쪽과 정책 아래 도는 쪽이 갈리는 자리입니다.

예외 자리가 있습니다. NIST 용어집은 조직이 정한 주체에게 조직이 정한 특권이 명시적으로 부여될 수 있다고 적습니다. 그런 주체를 신뢰된 주체라고 부릅니다. 그 주체는 위 제약의 일부 또는 전부에 묶이지 않습니다.

역할 기반 접근 제어

역할 기반 접근 제어(Role-Based Access Control, RBAC)는 사용자 역할을 보고 판단합니다. NIST 용어집은 역할을 사용자가 어떤 역할을 명시적으로나 묵시적으로 맡음으로써 받는 접근 인가의 모음이라고 적습니다. 허용되는 조작이 개별 주체의 신원이 아니라 역할에 결부됩니다. 하나의 역할이 한 사람에게만 붙기도 합니다. 여러 사람에게 같이 붙기도 합니다.

역할 권한은 역할 계층을 통해 상속될 수 있습니다. 그리고 조직 안에서 정해진 기능을 수행하는 데 필요한 권한을 대체로 반영합니다. 1992년에 David Ferraiolo 와 Rick Kuhn 이 이 모델을 형식화했습니다. 미국 국가표준협회 산하 정보기술표준위원회(ANSI/INCITS)는 2004년 2월 11일에 NIST 모델을 미국 국가표준 359-2004 로 채택했습니다. 2012년에 INCITS 359-2012 로 개정됐습니다.

속성 기반 접근 제어

속성 기반 접근 제어(Attribute-Based Access Control, ABAC)는 주체와 객체에 붙은 속성을 보고 판단합니다. NIST 용어집은 각 객체와 주체가 위치·생성 시각·접근권 같은 속성의 집합을 가진다고 적습니다. 객체에 대한 접근은 그 객체의 속성과 요청한 주체의 속성 사이에 요구되는 상관이 성립하느냐에 따라 허용되거나 거부됩니다. 그 상관을 무엇으로 볼지는 정책이 정합니다.

NIST 특별 간행물 800-162 는 평가 대상을 조금 더 넓게 적습니다. 주체·객체·요청된 조작에 결부된 속성을 평가해서 인가가 정해집니다. 경우에 따라서는 환경 조건도 함께 평가됩니다. 평가의 기준이 되는 것은 허용되는 조작을 기술한 정책·규칙·관계입니다.

예시

파일의 모드 비트

chmod(2) 는 파일의 모드 비트를 바꾸는 시스템콜입니다. 새 모드는 아래 상수를 비트 논리합으로 묶어 만듭니다.

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_IROTH (00004)   read by others
S_IWOTH (00002)   write by others

정책이 객체마다 붙어 있는 모양입니다. 주체 자리는 소유자·그룹·그 외 셋으로 굳어 있습니다. 조작 자리는 읽기·쓰기·실행 셋입니다. 디렉터리에서 실행 비트는 탐색을 뜻합니다. 매뉴얼은 그 비트가 디렉터리 안의 항목에 접근할 수 있음을 뜻한다고 적습니다.

데이터베이스의 GRANT

PostgreSQL 은 GRANT 문으로 접근 권한을 정합니다. 공식 문서의 구문은 이렇게 생겼습니다.

SQL
GRANT { { SELECT | INSERT | UPDATE | DELETE | TRUNCATE | REFERENCES |
TRIGGER | MAINTAIN } [, ...] | ALL [ PRIVILEGES ] }
    ON { [ TABLE ] table_name [, ...] | ALL TABLES IN SCHEMA schema_name [, ...] }
    TO role_specification [, ...] [ WITH GRANT OPTION ]
    [ GRANTED BY role_specification ]

실제 문장은 이렇습니다.

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

첫 줄에서 조작은 INSERT, 객체는 films 표, 주체는 PUBLIC 입니다. WITH GRANT OPTION 은 받은 쪽이 그 권한을 다시 남에게 내줄 수 있게 하는 자리입니다. 문서는 둘째 줄을 슈퍼유저나 kinds 의 소유자가 실행하면 모든 권한이 나간다고 적습니다. 다른 사람이 실행하면 그 사람이 grant option 을 가진 권한만 나갑니다.

클러스터의 역할과 결합

쿠버네티스는 역할 기반 접근 제어를 네 가지 객체로 선언합니다. Role · ClusterRole · RoleBinding · ClusterRoleBinding 입니다. Role 은 특정 네임스페이스 안에서만 권한을 정합니다. Role 을 만들 때 어느 네임스페이스에 속하는지를 반드시 적어야 합니다. ClusterRole 은 네임스페이스에 묶이지 않는 자원입니다.

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

객체는 pods, 조작은 get·watch·list 입니다. 주체는 여기 없습니다. 주체를 붙이는 것은 따로 있는 결합입니다.

YAML
kind: RoleBinding
metadata:
  name: read-secrets
  namespace: development
subjects:
- kind: User
  name: dave
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: secret-reader
  apiGroup: rbac.authorization.k8s.io

공식 문서는 이 결합이 사용자 dave 에게 development 네임스페이스의 시크릿을 읽게 해 준다고 적습니다. 권한 묶음과 그것을 받는 주체가 따로 적히는 것이 역할 기반의 모양입니다.

클라우드의 정책 문서

AWS(Amazon Web Services, 아마존 웹 서비스)의 IAM(Identity and Access Management, 아이덴티티 및 액세스 관리)은 정책을 문서 한 덩이로 적습니다.

JSON
{
  "Version":"2012-10-17",
  "Statement": [
    {
      "Sid": "ThirdStatement",
      "Effect": "Allow",
      "Action": [
        "s3:List*",
        "s3:Get*"
      ],
      "Resource": [
        "arn:aws:s3:::amzn-s3-demo-bucket-confidential-data",
        "arn:aws:s3:::amzn-s3-demo-bucket-confidential-data/*"
      ],
      "Condition": {"Bool": {"aws:MultiFactorAuthPresent": "true"}}
    }
  ]
}

Effect 가 허용인지 거부인지를 정합니다. Action 이 조작 자리, Resource 가 객체 자리입니다. Condition 은 요청 시점의 상태를 조건으로 겁니다. 여기서는 다요소 인증을 거친 요청일 때만 이 문장이 적용됩니다.

관련 항목

정책을 적는 방식

접근 제어 목록 · 능력 · 접근 행렬

판단 기준에 따라 갈리는 정책 모형

임의적 접근 제어 · 강제적 접근 제어 · 역할 기반 접근 제어 · 속성 기반 접근 제어 · 다중 등급 보안

판단에 관여하는 역할과 개념

정책 결정 지점 · 정책 강제 지점 · 인증 · 인가 · 권한

이것에 적용되는 규칙·원칙

최소 권한 · 완전 조정

실제 정책에 쓰이는 필드 이름

모드 비트 · 소유자 · 역할 · 스코프

이것을 실제로 구현·채택한 제품

PostgreSQL · Kubernetes · AWS · IAM(Identity and Access Management, 아이덴티티 및 액세스 관리) · SELinux

이것을 호출·실행하는 명령

chmod · GRANT

이것을 정의하는 표준·문서

RFC 4949 · NIST SP 800-162 · INCITS 359

헷갈리는 이웃 개념

물리적 접근 제어 · 매체 접근 제어(Medium Access Control) · SCIF

다른 이름: access control · 액세스 컨트롤