핵심 인사이트 (3줄 요약)
- 본질: Capability List는 접근 제어 행렬을 주체(프로세스/사용자) 기준으로 분할하여, 각 사용자가 "어떤 객체에 어떤 권한을 가지는지" 목록을 프로세스의 메모리(PCB)에 티켓 형태로 저장하는 방식이다.
- 가치: 프로세스가 객체에 접근할 때 중앙 테이블이나 파일 ACL을 참조할 필요 없이, 자신이持有的(보유한) 티켓만 제시하면 되어 $O(1)$ 시간에 인증이 가능하다.
- 한계: 권한을 회수하려면 해당 사용자로부터 모든 티켓을 회수해야 하므로 $O(N)$ 작업이 필요하며, 티켓을 다른 사용자에게 복사하면 **위임(Delegation)**으로 인한 권한 누출 위험이 있다.
Ⅰ. 개요 및 필요성
1.1 ACL의 한계: 역방향 조회
ACL은 "파일별로 권한 목록"을 저장하므로:
- "파일 A에 접근 가능한 사용자" 조회: O(1) - 해당 파일 ACL만 확인
- "사용자 B가 접근 가능한 파일" 조회: O(N) - 모든 파일 ACL을 스캔
1.2 Capability의 해결책
Capability는 **"사용자별로 권한 목록"**을 저장한다:
[ 사용자 A의 Capability List (티켓 뭉치) ]
- 티켓1: <파일1, {Read, Write}>
- 티켓2: <프린터, {Print}>
[ 사용자 B의 Capability List ]
- 티켓3: <파일1, {Read}>
- 티켓4: <파일2, {Read}>
- 📢 섹션 요약 비유: 복잡한 창고에서 필요한 물건을 찾기 위해 먼저 구역과 표지판을 세우는 것과 같다.
Ⅱ. 아키텍처 및 핵심 원리
2.1 Capability의實現: 파일 디스크립터
리눅스에서 open() 시스템콜이 반환하는 **파일 디스크립터(FD)**가 대표적인 Capability이다:
int fd = open("/data/file.txt", O_RDONLY);
// fd가Capability(티켓)
read(fd, buffer, 100); // fd(티켓)만 제시하면 읽기 가능
파일 디스크립터는 커널 공간에 저장되어 있으므로, 사용자 프로세스가 조작할 수 없다.
2.2 티켓 위조 방지
일반 사용자 메모리에 티켓을 저장하면 해킹에 의해 위조될 수 있다. 이를 방지하기 위해:
| 방식 | 설명 |
|---|---|
| 커널 공간 저장 | 티켓을 커널 메모리에 저장하고, 사용자에게는 번호(FD)만 반환 |
| 하드웨어 태그 | 메모리 칩마다 Tag 비트를 부여하여 커널만 수정 가능 |
2.3 권한 회수 문제
사용자에게 부여된 Capability를 회수하려면:
- 해당 사용자의 모든 티켓을 찾아야 함
- 각 티켓을 무효화
중앙 테이블이 없으면 모든 프로세스를 검사해야 하므로 $O(N)$ 시간이 소요된다.
- 📢 섹션 요약 비유: 공장 컨베이어벨트가 어떤 순서로 부품을 받아 가공하고 내보내는지 설계도를 펼쳐 보는 것과 같다.
Ⅲ. 비교 및 연결
3.1 전통 세션 기반 인증
[ 문제 ]
사용자 -> 로그인 -> 서버 세션 저장 (Redis 등)
-> API 요청 -> 세션 조회 (매번 DB 접근, O(N))
3.2 JWT 토큰 (Capability 패턴)
[ 해결 ]
사용자 -> 로그인 -> 서버가 JWT 토큰(티켓) 발급
토큰 내용: { 사용자ID, 만료시간, 권한 }
-> API 요청 -> 토큰 검증만으로 인증 완료 (O(1))
JWT 토큰 자체에 권한 정보가 포함되어 있어, 중앙 세션 저장소 없이 인증이 가능하다.
- 📢 섹션 요약 비유: 비슷해 보이는 공구를 나란히 놓고 언제 망치를 쓰고 언제 드라이버를 써야 하는지 구분하는 것과 같다.
Ⅳ. 실무 적용 및 기술사 판단
-
분산 환경 최적화: 중앙 테이블 없이 인증이 가능하므로 스케일링에 유리
-
권한 회수 복잡성: 분산된 티켓의 회수가 어려움
-
현대적 변형: JWT, OAuth 2.0 등 클라우드 환경에서 활용
-
📢 섹션 요약 비유: 운전자가 도로 상황에 따라 기어와 브레이크를 다르게 선택하는 것처럼 조건별 판단이 중요하다.
Ⅴ. 기대효과 및 결론
자격 증명 리스트 (Capability List / Ticket)은 운영체제 보호와 보안 메커니즘을 이해하는 연결 고리 역할을 한다. 이 개념을 익히면 시스템 동작을 더 예측 가능하게 설명할 수 있지만, 만능 해법은 아니므로 적용 전제와 한계를 함께 기억해야 한다. 앞으로는 롤 기반 접근 제어 (RBAC, Role-Based Access Control)처럼 더 세분화된 기술과 결합되며 자동화·최적화 방향으로 발전한다.
- 📢 섹션 요약 비유: 도구의 장점만 외우는 것이 아니라 어디까지 믿고 어디서 보완해야 하는지 기억하는 정리 노트와 같다.
📌 관련 개념 맵
| 개념 | 연결 포인트 |
|---|---|
| 전역 테이블 (Global Table) 방식 구현 (행렬 희소성 문제) | 현재 개념으로 들어오기 전에 함께 이해하면 경계가 선명해지는 기반 개념이다. |
| 접근 제어 목록 (ACL, Access Control List) | 현재 개념이 등장하게 만든 직접적인 선행 흐름이다. |
| 롤 기반 접근 제어 (RBAC, Role-Based Access Control) | 현재 개념이 구현·세분화될 때 바로 연결되는 후속 개념이다. |
| 임의적 접근 제어 (DAC, Discretionary Access Control) | 확장 학습이나 심화 비교로 이어지는 다음 단계의 키워드다. |
📈 관련 키워드 및 발전 흐름도
[접근 제어 목록 (ACL, Access Control List)]
│
▼
[자격 증명 리스트 (Capability List / Ticket)]
│
├──▶ [롤 기반 접근 제어 (RBAC, Role-Based Access Control)]
└──▶ [임의적 접근 제어 (DAC, Discretionary Access Control)]
이 흐름도는 선행 개념에서 현재 개념으로 넘어온 뒤, 구현 세분화와 후속 확장으로 이어지는 학습 순서를 압축해 보여준다.
👶 어린이를 위한 3줄 비유 설명
-
Capability는 놀이공원의 **"종이 팔찌"**와 같다. 입장할 때 받고, 각 놀이기구에서 팔찌만 보여주면 된다. 매번 명부를 확인할 필요가 없다.
-
파일 디스크립터는 **"줄 번호표"**와 같다. 窓口(창구)에서 번호표를 받고, 창구에서 번호표를 제시하면 번호표에 해당하는 업무를 처리받을 수 있다.
-
권한 회수 어려움은 종이 팔찌를 회수하려면 "모든 놀이기구를 돌아다니며 그 사람의 팔찌를 찾아 잘라내야" 하는 것과 같다. 입장时(시)에 발급된 팔찌를 한꺼번에 회수하기 어렵다.