본문으로 이동

컴퓨터 접근 제어

위키백과, 우리 모두의 백과사전.

컴퓨터 접근 제어(Computer access control)는 컴퓨터 보안에서 일반적으로 식별, 권한 부여, 인증, 접근 승인 및 감사가 포함된다. 접근 제어에 대한 보다 좁은 정의는 접근 승인만 포함하며, 시스템은 주체에게 접근 권한이 부여된 항목에 따라 이미 인증된 주체의 접근 요청을 승인하거나 거부하는 결정을 내린다. 인증 및 접근 제어는 단일 작업으로 결합되는 경우가 많으므로 인증 성공 또는 익명 접근 토큰을 기반으로 접근이 승인된다. 인증 방법 및 토큰에는 비밀번호, 생체 인식 스캔, 물리적 키, 전자 키 및 장치, 숨겨진 경로, 사회적 장벽, 사람과 자동화 시스템에 의한 모니터링이 포함된다.

소프트웨어 엔티티

[편집]

모든 접근 제어 모델에서 시스템에 대해 작업을 수행할 수 있는 엔티티를 주체(subject)라고 하며, 액세스를 제어해야 할 자원을 나타내는 엔티티를 객체(object)라고 한다(Access Control Matrix 참조). 주체와 객체는 인간 사용자가 아니라 소프트웨어 엔티티로 간주되어야 한다. 인간 사용자는 자신이 제어하는 소프트웨어 엔티티를 통해서만 시스템에 영향을 미칠 수 있기 때문이다.

일부 시스템은 주체를 사용자 ID와 동일시하여 사용자가 시작한 모든 프로세스가 기본적으로 동일한 권한을 갖도록 하지만, 이러한 수준의 제어는 최소 권한의 원칙을 충족할 만큼 세밀하지 못하며, 이러한 시스템에서 악성 소프트웨어가 널리 퍼지는 원인이 되기도 한다(컴퓨터 비보안 참조).

객체 기능 모델(object-capability model)과 같은 일부 모델에서는 모든 소프트웨어 엔티티가 잠재적으로 주체와 객체 역할을 모두 수행할 수 있다.

2014년 기준, 접근 제어 모델은 크게 두 가지 부류로 나뉘는 경향이 있다. 바로 기능 기반 보안에 기초한 모델과 접근 제어 목록(ACL)에 기초한 모델이다.

  • 기능 기반 모델에서는 객체에 대한 위조 불가능한 참조 또는 기능(capability)을 보유하는 것이 객체에 대한 접근 권한을 제공한다(마치 집 열쇠를 소유하는 것이 집에 들어갈 권한을 부여하는 것과 유사하다). 접근 권한은 보안 채널을 통해 이러한 기능을 다른 당사자에게 전송함으로써 전달된다.
  • ACL 기반 모델에서 주체의 객체 또는 객체 그룹에 대한 접근[1]은 해당 주체의 식별자가 객체와 연관된 목록에 있는지 여부에 따라 달라진다(마치 프라이빗 파티의 보안 요원이 신분증을 확인하여 이름이 명단에 있는지 확인하는 것과 유사하다). 접근 권한은 목록을 편집함으로써 전달된다. (시스템마다 목록 편집 권한이나 방식에 대해 다양한 관례가 존재한다.)

기능 기반 및 ACL 기반 모델 모두 주체 그룹의 모든 구성원에게 접근 권한을 부여할 수 있는 메커니즘을 가지고 있다(종종 그룹 자체가 하나의 주체로 모델링되기도 한다).

서비스

[편집]

접근 제어 시스템은 허가, 식별 및 인증(I&A), 접근 승인, 책임 추적성이라는 핵심 서비스를 제공한다.

  • 허가(authorization)는 주체가 수행할 수 있는 작업을 규정한다.
  • 식별 및 인증(identification and authentication)은 정당한 주체만이 시스템에 로그인할 수 있도록 보장한다.
  • 접근 승인(access approval)은 허가 정책에 따라 사용자와 접근이 허용된 자원을 연결함으로써 작업 중에 접근을 허용한다.
  • 책임 추적성(accountability)은 주체(또는 사용자와 연관된 모든 주체)가 수행한 작업을 식별한다.

허가

[편집]

허가는 주체에 대한 접근 권한을 정의하는 행위를 포함한다. 허가 정책은 시스템 내에서 주체가 실행할 수 있도록 허용된 작업을 명시한다.

대부분의 현대 운영체제는 세 가지 기본 접근 유형의 변형 또는 확장인 공식적인 권한 세트로 허가 정책을 구현한다.

  • 읽기 (R): 주체는 다음을 수행할 수 있다.
    • 파일 내용 읽기
    • 디렉터리 내용 목록 표시
  • 쓰기 (W): 주체는 다음 작업을 통해 파일이나 디렉터리의 내용을 변경할 수 있다.
    • 추가
    • 업데이트
    • 삭제
    • 이름 변경
  • 실행 (X): 파일이 프로그램인 경우, 주체는 프로그램을 실행할 수 있다. (유닉스 스타일 시스템에서 디렉터리에 부여된 "실행" 권한은 "디렉터리 탐색" 권한의 역할을 겸한다.)

이러한 권한은 임의 접근 제어(DAC) 및 강제적 접근 제어(MAC) 기반 시스템에서 서로 다르게 구현된다.

식별 및 인증

[편집]

식별 및 인증(I&A)은 신원 주장을 하는 엔티티에 해당 신원이 결합되어 있는지 확인하는 과정이다. I&A 프로세스는 일반적으로 신원 증명(identity proofing)이라고 불리는 초기 신원 검증이 있었다고 가정한다. 신원 증명에는 정부 발행 신분증을 이용한 대면 확인부터, 신청자가 익명으로 남을 수 있지만 재방문 시 시스템이 인지할 수 있도록 하는 익명 방법까지 다양한 방법이 있다. 신원 증명 및 검증에 사용되는 방법은 시스템 내 신원 사용 목적에 부합하는 보증 수준을 제공해야 한다. 이후 엔티티는 검증 수단으로서 인증자와 함께 신원을 주장한다. 식별자에 대한 유일한 요구 사항은 해당 보안 도메인 내에서 고유해야 한다는 것이다.

인증자는 일반적으로 다음 네 가지 요소 중 적어도 하나를 기반으로 한다.

  • 지식 기반(Something you know): 비밀번호나 개인 식별 번호(PIN)와 같은 것. 이는 계정 소유자만이 접근에 필요한 비밀번호나 PIN을 알고 있다고 가정한다.
  • 소유 기반(Something you have): 스마트카드나 보안 토큰과 같은 것. 이는 계정 소유자만이 계정 잠금을 해제하는 데 필요한 카드나 토큰을 가지고 있다고 가정한다.
  • 존재 기반(Something you are): 지문, 목소리, 망막 또는 홍채 특성과 같은 생체 정보.
  • 위치 기반(Where you are): 예를 들어 회사 방화벽 내부나 외부, 또는 개인 GPS 장치와의 근접성 등.

접근 승인

[편집]

접근 승인은 작업 중에 실제로 접근을 허용하거나 거부하는 기능이다.[2]

접근 승인 중에 시스템은 허가 정책의 공식적 표현과 접근 요청을 비교하여 요청을 승인할지 거부할지 결정한다. 또한, 접근 평가는 온라인 또는 지속적으로 수행될 수 있다.[3]

책임 추적성

[편집]

책임 추적성은 감사용 기록(audit trails) 및 로그와 같은 시스템 구성 요소를 사용하여 주체와 그 행위를 연관시킨다. 기록된 정보는 주체를 제어 사용자와 매핑하기에 충분해야 한다. 감사 기록과 로그는 다음에 중요하다.

  • 보안 위반 탐지
  • 보안 사고 재구성

로그를 정기적으로 검토하는 사람이 없고 보안상 안전하고 일관된 방식으로 유지되지 않는다면, 증거로서의 효력을 갖지 못할 수 있다.

많은 시스템은 클리핑 레벨(clipping levels)이라고 알려진 특정 미리 정의된 기준이나 임계값을 기반으로 자동 보고서를 생성할 수 있다. 예를 들어, 클리핑 레벨은 다음에 대해 보고서를 생성하도록 설정될 수 있다.

  • 일정 기간 내에 3회 이상의 로그인 시도 실패
  • 비활성화된 사용자 계정을 사용하려는 시도

이러한 보고서는 시스템 관리자나 보안 관리자가 가능한 침입 시도를 더 쉽게 식별하도록 도와준다. – 클리핑 레벨의 정의:[4] 디스크가 자기 특성을 유지하고 콘텐츠를 보존하는 능력. 고품질 범위는 65~70%이며, 저품질은 55% 미만이다.

접근 제어

[편집]

접근 제어 모델은 때때로 임의적(discretionary) 또는 비임의적(non-discretionary) 모델로 분류된다. 가장 널리 알려진 세 가지 모델은 임의 접근 제어(DAC), 강제적 접근 제어(MAC), 역할 기반 접근 제어(RBAC)이다. MAC은 비임의적이다.

임의 접근 제어

[편집]

임의 접근 제어(DAC)는 객체의 소유자에 의해 결정되는 정책이다. 소유자는 누가 객체에 접근할 수 있는지, 그리고 그들이 어떤 특권을 갖는지 결정한다.

DAC의 두 가지 중요한 개념은 다음과 같다.

  • 파일 및 데이터 소유권: 시스템의 모든 객체에는 소유자가 있다. 대부분의 DAC 시스템에서 각 객체의 초기 소유자는 해당 객체를 생성하게 한 주체다. 객체에 대한 접근 정책은 소유자에 의해 결정된다.
  • 접근 권한 및 허용: 소유자가 특정 자원에 대해 다른 주체에게 할당할 수 있는 제어 기능이다.

접근 제어는 ACL 기반 또는 기능 기반 보안 시스템에서 임의적일 수 있다. (기능 기반 시스템에서는 보통 명시적인 '소유자' 개념은 없지만, 객체 생성자가 접근 정책에 대해 유사한 수준의 제어권을 갖는다.)

강제적 접근 제어

[편집]

강제적 접근 제어(MAC)는 특정 사용자가 자원에 접근할 수 있도록 허용하는 규칙이 존재하는 경우에만 자원 접근을 허용하는 것을 의미한다. 관리가 어렵지만, 매우 민감한 정보를 보호할 때 그 사용이 정당화된다. 정부 및 군사 정보가 그 예시다. 계층적 접근 제어를 사용하거나 민감도 라벨을 구현하면 관리가 (필요한 수준보다) 단순화되는 경우가 많다. 이 방법이 "강제적"인 이유는 규칙이나 민감도 라벨을 사용하기 때문이다.

  • 민감도 라벨: 이러한 시스템에서 주체와 객체에는 라벨이 할당되어야 한다. 주체의 민감도 라벨은 신뢰 수준을 명시한다. 객체의 민감도 라벨은 접근에 필요한 신뢰 수준을 명시한다. 특정 객체에 접근하려면 주체의 민감도 수준이 요청된 객체보다 높거나 같아야 한다.
  • 데이터 가져오기 및 내보내기: 다른 시스템으로부터 정보를 가져오고 다른 시스템(프린터 포함)으로 내보내는 것을 제어하는 것은 이러한 시스템의 중요한 기능이며, 민감한 정보가 항상 적절하게 보호되도록 민감도 라벨이 올바르게 유지 및 구현되어야 한다.

강제적 접근 제어를 적용하는 데 두 가지 방법이 일반적으로 사용된다.

  • 규칙 기반(또는 라벨 기반) 접근 제어: 이 유형의 제어는 요청된 객체에 대한 접근에 대해 구체적인 조건을 추가로 정의한다. 강제적 접근 제어 시스템은 다음을 일치시켜 접근 승인 또는 거부 여부를 결정하는 간단한 형태의 규칙 기반 접근 제어를 구현한다.
    • 객체의 민감도 라벨
    • 주체의 민감도 라벨
  • 격자 기반 접근 제어: 여러 객체 및 주체가 관련된 복잡한 접근 제어 결정에 사용될 수 있다. 격자 모델은 주체와 객체와 같은 한 쌍의 요소에 대해 최소 상한값과 최대 하한값을 정의하는 수학적 구조이다.

MAC을 구현하는 시스템은 거의 없으며, XTS-400과 SELinux가 그 예시이다.

역할 기반 접근 제어

[편집]

역할 기반 접근 제어(RBAC)는 소유자가 아닌 시스템에 의해 결정되는 접근 정책이다. RBAC은 상업적 응용 프로그램과 다단계 보안 요구 사항이 존재할 수 있는 군사 시스템에서 사용된다. RBAC이 DAC과 다른 점은 DAC은 사용자가 자신의 자원에 대한 접근을 제어할 수 있게 하는 반면, RBAC에서는 사용자의 제어 범위를 벗어나 시스템 수준에서 접근이 제어된다는 것이다. RBAC은 비임의적이지만, 권한이 처리되는 방식에서 주로 MAC과 구별될 수 있다. MAC은 사용자의 허가 수준과 추가 라벨을 기반으로 읽기 및 쓰기 권한을 제어한다. RBAC은 전자 상거래 트랜잭션과 같은 복잡한 작업이나 읽기 또는 쓰기와 같이 단순할 수 있는 권한 집합을 제어한다. RBAC에서의 역할은 권한의 집합으로 볼 수 있다.

RBAC에는 세 가지 기본 규칙이 정의되어 있다.

  1. 역할 할당: 주체는 적절한 역할을 선택하거나 할당받은 경우에만 트랜잭션을 실행할 수 있다.
  2. 역할 허가: 주체의 활성 역할은 해당 주체에 대해 허가되어야 한다. 위의 규칙 1과 함께, 이 규칙은 사용자가 자신에게 허가된 역할만 맡을 수 있도록 보장한다.
  3. 트랜잭션 허가: 주체는 트랜잭션이 주체의 활성 역할에 대해 허가된 경우에만 트랜잭션을 실행할 수 있다. 규칙 1 및 2와 함께, 이 규칙은 사용자가 자신에게 허가된 트랜잭션만 실행할 수 있도록 보장한다.

추가적인 제약 조건이 적용될 수 있으며, 역할은 상위 수준의 역할이 하위 수준 서브 역할의 권한을 포함하는 계층 구조로 결합될 수 있다.

대부분의 IT 벤더는 하나 이상의 제품에서 RBAC을 제공한다.

속성 기반 접근 제어

[편집]

속성 기반 접근 제어(ABAC)에서는[5][6] 인증 후 사용자와 연결된 주체의 권한이 아니라, 주체, 객체의 속성, 요청된 작업, 그리고 정책, 규칙 또는 관계에 대비한 환경 조건에 기초하여 접근이 승인된다.[7] 사용자는 접근 제어 엔진에 자신의 속성에 대한 소위 '클레임'(claims)을 증명해야 한다. 속성 기반 접근 제어 정책은 객체에 대한 접근을 승인하기 위해 어떤 클레임이 충족되어야 하는지를 명시한다. 예를 들어, 클레임은 "18세 이상"일 수 있다. 이 클레임을 증명할 수 있는 모든 사용자에게는 접근 권한이 부여된다. 인증과 식별이 엄격하게 요구되지 않을 때 사용자는 익명일 수 있다. 하지만 클레임을 익명으로 증명할 수 있는 수단이 필요하다. 이는 예를 들어 익명 자격 증명을 사용하여 달성할 수 있다. XACML(가변형 접근 제어 마크업 언어)은 속성 기반 접근 제어를 위한 표준이다. XACML 3.0은 2013년 1월에 표준화되었다.[8]

비상시 접근 제어 모델

[편집]

전통적으로 접근 제어는 접근을 제한하는 목적을 가지므로, 대부분의 접근 제어 모델은 "기본 거부 원칙"을 따른다. 즉, 특정 접근 요청이 명시적으로 허용되지 않으면 거부된다. 이러한 동작은 시스템의 정기적인 운영과 충돌할 수 있다. 특정 상황에서 인간은 접근 제어 정책을 위반함으로써 발생할 수 있는 잠재적 이익이 위험보다 크다면 기꺼이 위험을 감수하려 한다. 이러한 요구는 특히 환자 기록에 대한 접근 거부가 환자의 사망을 초래할 수 있는 의료 분야에서 두드러진다. 비상시 접근(Break-Glass 또는 break-the-glass)은 사용자가 접근 제어 결정을 무시할 수 있도록 허용함으로써 이를 완화하려 한다. 비상시 접근은 특정 접근 제어 방식(예: RBAC)에 내장되어 구현되거나,[9] 일반적인 형태(즉, 하부 접근 제어 모델에 독립적)로 구현될 수 있다.[10]

호스트 기반 접근 제어 (HBAC)

[편집]

약어 HBAC은 "호스트 기반 접근 제어"(host-based access control)를 의미한다.[11]

같이 보기

[편집]

각주

[편집]
  1. ↑ Feio, Rui 외 (2014년 8월 12일). 《ABCs of IBM Z/OS System Programming Volume 6》 2판. IBM Corporation. 24쪽. ISBN 9780738439808. 2024년 12월 17일에 확인함.
  2. ↑ Dieter Gollmann. Computer Security, 3rd ed. Wiley Publishing, 2011, p. 387, bottom
  3. ↑ Marcon, A. L.; Olivo Santin, A.; Stihler, M.; Bachtold, J., "A UCONabc Resilient Authorization Evaluation for Cloud Computing," Parallel and Distributed Systems, IEEE Transactions on, vol. 25, no. 2, pp. 457–467, Feb. 2014 doi:10.1109/TPDS.2013.113, bottom
  4. ↑ “Definition of: clipping level”. 《PC Magazine》. 2010년 4월 16일에 원본 문서에서 보존된 문서. 2017년 8월 26일에 확인함.
  5. ↑ Jin, Xin, Ram Krishnan, and Ravi Sandhu. "A unified attribute-based access control model covering dac, mac and rbac." Data and Applications Security and Privacy XXVI. Springer Berlin Heidelberg, 2012. 41–55.
  6. ↑ Hu, Vincent C.; Ferraiolo, David; Kuhn, Rick; Schnitzer, Adam; Sandlin, Kenneth; Miller, Robert; Scarfone, Karen. 《Guide to Attribute Based Access Control (ABAC) Definition and Considerations》 (PDF).
  7. ↑ Hu, Vincent C. (2013). 《Guide to Attribute Based Access Control (ABAC) Definition and Considerations (Draft)》. 《National Institute of Standards and Technology》 800. 54쪽.
  8. ↑ eXtensible Access Control Markup Language (XACML) V3.0 approved as an OASIS Standard, eXtensible Access Control Markup Language (XACML) V3.0 approved as an OASIS Standard.
  9. ↑ Ferreira, Ana; Chadwick, David; Farinha, Pedro; Correia, Ricardo; Zao, Gansen; Chiro, Rui; Antunes, Luis (2009). 〈How to Securely Break into RBAC: The BTG-RBAC Model〉. 《Computer Security Applications Conference (ACSAC)》. IEEE. 23–31쪽. doi:10.1109/ACSAC.2009.12. hdl:10216/21676.
  10. ↑ Brucker, Achim D.; Petritsch, Helmut (2009). 〈Extending Access Control Models with Break-glass.〉. 《ACM symposium on access control models and technologies (SACMAT)》. ACM Press. 197–206쪽. doi:10.1145/1542207.1542239.
  11. ↑ Ballard, Ella Deon (2013). “Identity Management Guide: Managing Identity and Authorization Policies for Linux-Based Infrastructures”. Red Hat. 2014년 1월 6일에 확인함. Any PAM service can be identified as to the host-based access control (HBAC) system in IdM.
원본 주소 "https://ko.wikipedia.org/w/index.php?title=컴퓨터_접근_제어&oldid=41226327"