접근 제어 목록
고친 사람 github-actions[bot]
접근 제어 목록은 자원마다 「누가 무엇을 해도 되는지」를 적어 붙여 두는 목록입니다. 요청이 오면 그 자원에 붙은 목록을 보고 들여보낼지 막을지 정합니다. 파일 공유 설정에서 사람마다 보기와 편집을 따로 고르는 것이 이 방식입니다. 네트워크 장비에서는 같은 이름이 패킷을 걸러내는 규칙 목록을 가리킵니다.
쉽고 빠른 이해
접근 제어 목록은 자원 하나하나에 붙은 출입 명단입니다. 「이 문서는 앨리스가 편집, 밥이 보기」처럼 적어 둡니다.
명단이 없으면 요청이 올 때마다 누가 무엇을 해도 되는지 판단할 근거가 없습니다. 자원 곁에 두면 「이 문서를 누가 볼 수 있나」를 명단 한 장만 보고 답합니다.
어떻게 도나:
- 누가 어떤 자원에 무엇을 하겠다고 요청합니다
- 그 자원에 붙은 명단에서 사람과 조작이 둘 다 맞는 줄을 찾습니다
- 그런 줄이 있으면 통과, 없으면 거부합니다
대가가 있습니다. 「이 사람이 손댈 수 있는 것 전부」를 알려면 모든 자원의 명단을 뒤져야 합니다. 사람과 자원이 늘면 명단을 고칠 곳도 함께 늘어납니다.
그래서 파일이나 문서처럼 자원마다 공유 상대가 제각각인 곳에 씁니다. 「결재 담당자는 결재 문서를 모두 본다」처럼 규칙이 일률적이면 사람과 권한 사이에 역할을 두는 방식을 함께 씁니다.
상세
도서관에서는 책마다 누가 어떻게 이용할 수 있는지가 적힌 쪽지가 붙어 있습니다. 어떤 책에는 「교직원은 빌려 가기, 학생은 자리에서 읽기」라고 적혀 있습니다. 학생이 그 책을 대출대에 내밀면 사서는 학생 몫으로 적힌 것이 읽기뿐이라 열람석을 가리킵니다.
영어로는 ACL(Access Control List, 접근 제어 목록)이라고 부릅니다. 실무에서도 줄임말로 더 자주 부릅니다.
접근 행렬을 열로 자른 모양
접근 제어는 「누가 무엇에 무엇을 해도 되나」를 판단하는 일입니다. 판단하려면 그 답을 어딘가에 적어 두어야 합니다. 가장 곧이곧대로 적는 방법이 접근 행렬입니다.
접근 행렬은 행에 주체를, 열에 자원을 놓은 표입니다. 주체는 요청하는 쪽으로, 사람이나 사람을 대신해 도는 프로그램입니다. 칸에는 그 주체가 그 자원에 해도 되는 조작을 적습니다.
이 표를 한 장으로 들고 있기는 어렵습니다. 사용자가 만 명이고 파일이 백만 개면 칸이 백억 개입니다. 게다가 거의 모든 칸이 비어 있습니다.
그래서 빈칸을 버리고 표를 잘라서 보관합니다. 열 하나, 즉 자원 하나를 기준으로 자르면 접근 제어 목록이 됩니다. 급여표의 목록에는 「앨리스: 읽기·쓰기」 한 줄만 남습니다.
반대로 행 하나, 즉 주체 하나를 기준으로 자르면 자격 목록이 됩니다. 앨리스의 자격 목록에는 「급여표: 읽기·쓰기」와 「회의록: 읽기」가 남습니다. 같은 표를 어느 방향으로 잘랐느냐의 차이입니다.
flowchart TD
subgraph S1["급여표"]
A1["앨리스 · 읽기 · 쓰기"]
end
subgraph S2["회의록"]
B1["앨리스 · 읽기"]
B2["밥 · 읽기 · 쓰기"]
end
subgraph S3["배포 스크립트"]
C1["운영팀 · 실행"]
end
S1 ~~~ S2 ~~~ S3
위 그림은 앞의 표를 열마다 잘라 자원에 매단 모습입니다. 목록은 자원을 따라다닙니다. 자원을 지우면 목록도 함께 사라집니다.
목록 한 줄의 구성
목록의 한 줄을 접근 제어 항목이라고 부릅니다. 영어로는 ACE(Access Control Entry, 접근 제어 항목)입니다. 한 줄에는 적어도 「누구」와 「무엇을 해도 되나」가 들어갑니다.
「누구」 칸에는 사람 한 명 대신 그룹을 적을 수 있습니다. 사람마다 한 줄씩 적으면 팀원이 바뀔 때마다 모든 자원의 목록을 고쳐야 합니다. 그룹을 적어 두면 그룹 구성원만 바꾸면 됩니다.
「무엇을」 칸에 오는 조작은 자원의 종류가 정합니다. 파일이면 읽기·쓰기·실행입니다. 문서 공유 서비스라면 보기·댓글·편집입니다. 조작의 이름은 달라도 한 줄이 「주체와 허용된 조작」의 짝이라는 점은 같습니다.
항목에 허용 말고 거부를 적게 하는 시스템도 있습니다. 「개발팀은 읽기 허용, 다만 인턴은 거부」처럼 그룹 안의 일부를 빼고 싶을 때 씁니다. 거부 항목이 있으면 허용과 거부가 부딪칠 때 어느 쪽을 따를지 규칙이 따로 필요해집니다.
요청을 판정하는 순서
요청은 「누가, 어느 자원에, 무엇을」의 세 가지로 들어옵니다. 판정하는 쪽은 그 자원의 목록에서 요청에 맞는 줄을 찾습니다. 맞는 줄은 「누구」 칸이 주체 본인이나 주체가 속한 그룹이면서 「무엇을」 칸이 요청한 조작인 줄입니다. 이 편에서 「맞는 줄」은 늘 이 뜻입니다.
flowchart TD
R["요청 · 누가 · 어느 자원에 · 무엇을"] --> L["그 자원의 목록을 꺼낸다"]
L --> F["첫 줄부터 본다"]
F --> M{"이 줄이 주체와 조작 둘 다 맞나"}
M -->|맞다| A["허용"]
M -->|아니다| N{"남은 줄이 있나"}
N -->|있다| X["다음 줄로"]
X --> M
N -->|없다| D["거부"]
위 그림은 허용 줄만 적힌 목록에서 판정하는 순서를 그렸습니다. 위에서부터 한 줄씩 보다가 처음 맞는 줄을 만나면 허용하고 멈춥니다. 주체만 맞고 조작이 다른 줄은 건너뛰고 다음 줄을 봅니다.
맞는 줄이 하나도 없으면 거부합니다. 목록에 없는 사람은 들여보내지 않는다는 뜻으로, 이것을 기본 거부라고 부릅니다. 목록에 적힌 것만 허용되므로 적는 사람이 빠뜨린 권한은 막히는 쪽으로 기웁니다.
맞는 줄이 여럿일 때 어떻게 고르는지는 시스템마다 다릅니다. 위에서부터 처음 맞는 줄을 따르는 방식이 있습니다. 거부 줄이 하나라도 맞으면 거부하는 방식도 있습니다. 목록을 읽을 때는 그 시스템이 어느 규칙을 쓰는지 먼저 확인해야 합니다.
아래는 이 판정을 파이썬으로 옮긴 짧은 예입니다. 그림과 같은 규칙으로, 주체와 조작이 둘 다 맞는 첫 줄에서 멈춥니다.
acl = [("alice", "read"), ("dev", "read")]
def allowed(user, groups, op):
for who, perm in acl:
if who in [user, *groups] and perm == op:
return True
return False # 기본 거부
allowed("bob", ["dev"], "read") # True
allowed("bob", ["dev"], "write") # False
밥 본인의 줄은 없습니다. 첫 호출은 밥이 속한 dev 그룹의 줄이 읽기를 허락해서 통과합니다. 둘째 호출은 쓰기를 허락하는 줄이 없어 거부됩니다.
유닉스 파일 권한과의 관계
유닉스 계열 운영체제의 파일 권한은 접근 제어 목록을 아주 짧게 줄인 꼴입니다. 파일마다 소유자, 소유 그룹, 그 밖의 모두라는 세 줄만 둡니다. 줄마다 읽기·쓰기·실행을 켜고 끄는 비트 세 개가 붙습니다.
세 줄로는 「이 파일을 앨리스와 밥에게만 따로 열어 준다」를 적기 어렵습니다. 그래서 많은 운영체제가 사람과 그룹을 원하는 만큼 적는 확장 ACL을 따로 둡니다. 세 줄짜리 권한 비트와 확장 ACL은 같은 생각을 얼마나 길게 적느냐의 차이입니다.
자원 쪽에 적어서 생기는 득실
목록이 자원 곁에 있으니 「이 자원에 누가 무엇을 할 수 있나」에는 목록 한 장으로 답합니다. 자원 주인이 목록을 고쳐 공유 상대를 바꾸기도 쉽습니다. 파일이나 문서처럼 자원마다 공유 상대가 제각각인 곳에 잘 맞습니다.
반대 방향의 질문이 비쌉니다. 「앨리스가 손댈 수 있는 것 전부」를 알려면 모든 자원의 목록을 훑어야 합니다. 퇴사자의 권한을 남김없이 거두는 일이 그래서 번거롭습니다. 자격 목록은 이 득실이 정반대입니다.
사람과 자원이 함께 많아지면 목록을 고칠 곳이 늘어납니다. 「결재 담당자는 모든 결재 문서를 본다」 같은 규칙을 자원마다 한 줄씩 적으면 담당자가 바뀔 때 수천 개의 목록을 고쳐야 합니다. 이렇게 규칙이 일률적인 곳에서는 사람과 권한 사이에 역할을 두는 역할 기반 접근 제어를 함께 씁니다.
네트워크 장비의 ACL
라우터나 방화벽 설정에서 말하는 ACL은 뜻이 다릅니다. 여기서는 지나가는 패킷을 통과시킬지 버릴지 정하는 규칙 목록입니다. 사람을 가리는 대신 패킷의 출발지 주소, 목적지 주소, 포트 번호를 보고 가릅니다.
규칙마다 허용이나 거부가 붙습니다. 목록의 순서도 뜻을 가집니다. 장비는 대개 위에서부터 차례로 맞춰 보고 처음 맞는 규칙을 따릅니다. 끝까지 맞는 규칙이 없으면 버리는 설정이 흔합니다.
이름은 같아도 목록이 붙는 대상이 다릅니다. 파일 같은 자원이 아니라 패킷이 드나드는 장비의 연결 지점에 붙어 그곳을 지나는 패킷을 봅니다. 네트워크 쪽 규칙 목록은 패킷 필터링에서 이어집니다.
관련 항목
이것이 속하는 상위 분류
접근 제어 · 인가 · 인증과 인가 · 보안 엔지니어링
권한을 적어 두는 다른 방식
접근 행렬 · 자격 목록 · 능력
권한 판단 기준으로 갈리는 정책 모형
임의적 접근 제어 · 강제적 접근 제어 · 역할 기반 접근 제어 · 속성 기반 접근 제어
판정에 적용되는 원칙
기본 거부 · 최소 권한 · 완전 조정
목록 한 줄을 이루는 구성 요소
주체 · 대상 · 권한 · 그룹 · 소유자 · 접근 제어 항목
이것을 채택한 저장 방식과 장비
파일 권한 · 유닉스 · 파일 시스템 · 라우터 · 방화벽 · 패킷 필터링
이것에서 자주 나는 사고
권한 상승 · 혼동된 대리인 · 과도한 권한
다른 이름: ACL · access control list · 액세스 제어 목록