접근통제 사례를 풀 때는 누가 요청하는지(주체), 무엇을 대상으로 하는지(객체), 어떤 작업을 요청하는지(행위)를 먼저 표시합니다. 속성 기반 접근통제(ABAC)에서는 여기에 주체·객체·작업·환경의 속성과 정책 조건을 더해 판단할 수 있습니다.
요청을 분해하는 일은 허용·거부 정책 자체가 아닙니다. 실제 결정에는 해당 시스템의 정책, 속성의 신뢰성, 환경 조건과 규칙 결합 방식이 필요합니다.
‘누가 무엇을 어떻게’라는 요청 구조를 만듭니다
접근통제는 사용자가 이미 인증됐는지와 별개로, 해당 요청이 정책상 허용되는지 판단합니다. 주체(subject)는 요청을 수행하는 사용자나 프로세스이고 객체(object)는 보호할 파일·기록·서비스 같은 대상입니다. 행위(operation)는 읽기·수정·삭제·승인 등 객체에 하려는 작업입니다. NIST ABAC 지침은 이런 요소에 더해 주체·객체·행위·환경 속성을 정책 평가에 사용할 수 있다고 설명합니다.
예를 들어 ‘오후 근무 중인 회계 담당자가 환불 기록을 읽는다’는 요청은 주체=회계 담당자, 객체=환불 기록, 행위=읽기, 환경=근무 시간으로 나눌 수 있습니다. 이후 정책이 역할, 기록의 부서, 요청 위치, 시간, 목적 등을 어떻게 결합하는지 확인합니다. 주체가 누구인지 확인하는 인증(authentication)은 인가(authorization) 결정을 대신하지 않습니다.
요청을 표에 옮겨 누락된 정보를 찾습니다
| 요소 | 교육용 값 | 추가 확인 질문 |
|---|---|---|
| 주체 | 감사 역할 사용자 계정 | 계정 인증과 역할 할당이 최신인가? |
| 객체 | 2분기 환불 기록 | 기록의 소유 부서와 민감도는 무엇인가? |
| 행위 | 내보내기 | 읽기 권한과 대량 내보내기 권한이 같은가? |
| 환경 | 관리 단말, 업무 시간 | 단말 상태와 시간 조건을 정책이 요구하는가? |
이 표만으로 허용을 단정할 수는 없습니다. 정책이 ‘감사 역할은 부서 기록을 읽을 수 있지만 내보내기는 별도 승인 필요’라고 정했다면 읽기 권한만으로 내보내기를 허용할 수 없습니다. 또 기기 상태가 정책 조건이라면 환경 속성을 가져온 출처와 변조 가능성을 확인해야 합니다. 속성 기반 정책의 표현력이 커질수록 잘못된 속성이나 불완전한 규칙이 판단에 영향을 줄 수 있습니다.
시험 문제의 접근 결정을 다섯 칸으로 추적합니다
- 요청의 주체를 계정·역할·프로세스 중 문제에서 지정한 수준으로 씁니다.
- 객체의 식별자·분류·소유 정보를 분리합니다.
- 읽기·수정·삭제·내보내기처럼 구체 작업을 동사로 적습니다.
- 환경 속성이 있다면 시간·위치·단말 상태 등 정책 입력과 연결합니다.
- 마지막에 실제 허용 규칙과 충돌 해결 방식이 주어졌는지 확인합니다.
흔한 오답은 ‘관리자이므로 허용’처럼 역할 하나만 보고 결정하는 것입니다. ABAC는 역할에 한정되지 않고 여러 속성과 조건을 평가할 수 있으며, 정책이 요구하지 않은 조건을 임의로 추가해서도 안 됩니다. 반대로 주체·객체·행위만 식별하고 환경 조건이나 결합 규칙을 무시하면 충분한 근거 없이 결과를 확정하게 됩니다.
접근 결정의 입력을 분해하는 습관은 결과가 거부됐을 때도 원인을 찾게 해 줍니다. 주체 역할이 잘못됐는지, 객체의 부서 속성이 오래됐는지, 요청 작업이 읽기가 아니라 내보내기인지, 단말 속성이 정책 기준을 만족하지 못했는지를 따로 살펴볼 수 있습니다. 이때 속성 공급자가 제공한 값이 최신인지, 누가 값을 바꿀 수 있는지, 오류가 나면 허용·거부 가운데 어떻게 처리하는지도 정책에 영향을 줍니다. 하지만 이는 각 시스템이 반드시 같은 방식으로 실패해야 한다는 보편 규칙이 아닙니다. 문제에서 지정한 정책과 오류 처리 기준을 우선하고, 주어진 내용 밖의 조건은 미확정으로 남기세요.
속성 결합 방식도 문제의 중요한 단서입니다. 정책이 부서와 요청 작업을 모두 만족해야 한다고 정했다면 AND 조건으로 판단할 수 있고, 허용 규칙이 여러 개라면 충돌 시 우선순위나 거부 우선 등 결합 규칙을 따로 확인할 수 있습니다. 이 글은 특정 충돌 해결 알고리즘을 전제하지 않습니다. 같은 속성값이라도 ‘소유 부서’, ‘현재 근무 부서’, ‘요청자가 대신 처리하는 부서’ 가운데 어느 의미로 쓰이는지에 따라 결정이 달라질 수 있습니다. 따라서 입력 이름만 읽지 말고 출처·갱신 시점·정책에서 정의한 의미를 함께 확인하세요. 근거가 없으면 허용이나 거부를 확정하지 말고 필요한 정보를 제시합니다.
회상 문제
교육용 문제입니다. 사용자는 승인 담당자 역할을 갖고 있습니다. 요청은 ‘환불 기록을 CSV로 내보내기’이고 정책은 승인된 감사 단말에서만 대량 내보내기를 허용합니다. 허용 여부를 결정하려면 아직 어떤 입력이 필요한가요?
주체·객체·행위 외에 환경 조건인 단말이 승인된 감사 단말인지 확인해야 합니다. 사용자 역할만으로는 허용이 성립하지 않습니다. 또 정책이 따로 정한 승인 상태나 기록 범위가 있다면 그 입력도 확인해야 하지만, 문제에 없는 조건을 새로 만들어서는 안 됩니다.
접근통제 문제를 다른 규칙과 함께 복습하려면 정보보호론 덱 안내를 확인할 수 있습니다. 표와 문항은 설명을 위해 새로 만든 예시이며 공식 기출문제나 유료 카드 인용이 아닙니다.
정답을 가리고 확인해 보세요
이 글을 위해 만든 학습 예시이며 공식 기출문제나 판매 카드의 인용이 아닙니다.
대량 내보내기가 승인된 감사 단말에서만 허용된다. 사용자 역할 외에 필요한 입력은?
정답과 해설 확인
요청 단말이 승인된 감사 단말인지 확인하는 환경 속성이 필요합니다.요청 요소를 식별한 뒤 ABAC 정책의 실제 조건을 평가해야 합니다. 승인 담당자 역할만으로 단말 조건을 충족했다고 볼 수 없습니다.