컴퓨터 액세스 제어

Computer access control
시리즈의 일부
정보 보안
vectorial version
관련 보안 카테고리
위협
방어.

컴퓨터 보안에서 일반적인 액세스 제어는 식별, 허가, 인증, 액세스 승인 및 감사를 포함합니다.액세스 컨트롤의 보다 좁은 정의는 액세스 승인만을 대상으로 합니다.이 경우 시스템은 이미 인증된 서브젝트로부터의 액세스 요구를 서브젝트에게 액세스 할 수 있는 권한을 바탕으로 허가 또는 거부 결정을 합니다.인증과 접근컨트롤은 보통 1개의 조작으로 결합되기 때문에 접근은 성공한 인증 또는 익명 접근토큰에 따라 승인됩니다.인증방법 및 토큰에는 패스워드, 바이오메트릭스캔, 물리키, 전자키 및 기기, 숨겨진 경로, 사회적 장벽, 인간 및 자동화 [citation needed]시스템에 의한 감시가 포함됩니다.

소프트웨어 엔티티

어느 액세스 제어 모델에서도 시스템에서 액션을 실행할 수 있는 엔티티는 서브젝트라고 불리며, 액세스를 제어할 필요가 있는 자원을 나타내는 엔티티는 오브젝트라고 불립니다(「액세스 제어 매트릭스」도 참조).대상과 오브젝트는 모두 인간 사용자가 아닌 소프트웨어 엔티티로 간주해야 합니다.인간 사용자는 자신이 [citation needed]제어하는 소프트웨어 엔티티를 통해서만 시스템에 영향을 미칠 수 있습니다.

일부 시스템은 대상을 사용자 ID와 동일시하기 때문에 기본적으로 사용자에 의해 시작된 모든 프로세스가 동일한 권한을 가지지만 이 수준의 제어는 최소 특권의 원칙을 충족할 정도로 세분화되지 않으며 이러한 시스템에서 말웨어가 확산되는 원인이 됩니다(컴퓨터 보안 [citation needed]참조).

객체 능력 모형과 같은 일부 모델에서는 모든 소프트웨어 엔티티가 잠재적으로 주체 및 [citation needed]객체의 역할을 할 수 있다.

2014년 현재 접근컨트롤 모델은 기능에 근거한 클래스와 Access Control List(ACL; 접근컨트롤 리스트)에 근거한 클래스 중 하나로 분류되는 경향이 있습니다.

  • 능력 기반 모델에서 오브젝트에 대한 허용할 수 없는 참조 또는 기능을 보유하여 오브젝트에 대한 액세스를 제공하는 것(자신의 집 키를 소유함으로써 자신의 집에 대한 액세스를 허용하는 방법과 거의 유사함). 이러한 기능을 안전한 채널을 통해 전송함으로써 다른 당사자에게 접근권이 전달됩니다.
  • ACL 기반 모델에서 오브젝트에 대한 서브젝트의 액세스는 오브젝트에 관련된 목록에 해당 ID가 표시되는지 여부에 따라 달라집니다(프라이빗 파티의 바운서가 게스트목록에 이름이 표시되는지 여부를 확인하기 위해 ID를 체크하는 방법과 거의 유사합니다).접근은 목록을 편집함으로써 전달됩니다(ACL 시스템에는 다양한 connovio가 있습니다).목록 편집에 대한 책임자와 내용 및 편집 방법에 대한 ns).[citation needed]

기능 기반 모델과 ACL 기반 모델 모두 서브젝트 그룹의 모든 멤버에게 접근권을 부여할 수 있는 메커니즘이 있습니다(많은 경우 그룹은 [citation needed]서브젝트로서 모델화되어 있습니다).

서비스

액세스 컨트롤 시스템은 다음과 같은 [citation needed]경우 인가, 식별 및 인증(I&A), 액세스 승인 및 책임과 같은 필수 서비스를 제공합니다.

  • 허가는 서브젝트가 할 수 있는 것을 지정합니다.
  • 식별 및 인증을 통해 합법적인 주체만 시스템에 로그온할 수 있습니다.
  • 접근 승인 권한 정책에 따라 사용자가 접근이 허용된 리소스와 관련지어 작업 중에 접근 권한을 부여합니다.
  • 어카운터빌리티는 서브젝트(또는 사용자와 관련된 모든 서브젝트)가 수행한 작업을 식별합니다.

허가

권한 부여에는 주체에 대한 액세스 권한을 정의하는 작업이 포함됩니다.인가 정책은 서브젝트가 시스템 [citation needed]내에서 실행할 수 있는 작업을 지정합니다.

대부분의 최신 운영 체제에서는 다음과 같은 세 가지 기본 유형의 [citation needed]액세스를 변형 또는 확장한 정식 권한 집합으로 권한 정책을 구현합니다.

  • 읽기(R):주제는 다음과 같습니다.
    • 파일 내용 읽기
    • 디렉터리 내용 나열
  • 쓰기(W):서브젝트는, 다음의 태스크로 파일 또는 디렉토리의 내용을 변경할 수 있습니다.
    • 더하다
    • 갱신하다
    • 삭제
    • 이름 바꾸기
  • Execute (X): 파일이 프로그램인 경우 제목으로 인해 프로그램이 실행될 수 있습니다. (유닉스 스타일 시스템에서 "실행" 권한은 디렉터리에 부여될 때 "이동 디렉터리" 권한으로 사용됩니다.)

이러한 권리와 권한은 임의 접근컨트롤(DAC)과 필수 접근컨트롤(MAC)에 따라 시스템에서 다르게 구현됩니다.

식별 및 인증

주요 기사:인증

I&A(Identification and Authentication)는 아이덴티티가 아이덴티티의 어설션 또는 클레임을 하는 엔티티에 구속되어 있는지 확인하는 프로세스입니다.I&A 프로세스에서는 일반적으로 ID 증명이라고 불리는 ID의 초기 검증이 있었다고 가정합니다.정부가 발급한 신분증을 이용한 본인 확인부터 청구인이 익명을 유지하되 반환하면 시스템에 알려지는 익명의 방법까지 다양한 신분증명 방법이 있다.신원증명 및 검증에 사용되는 방법은 시스템 내에서 의도된 신원 사용에 상응하는 보증 수준을 제공해야 한다.그 후, 실체는 인증자와 함께 검증 수단으로서 정체성을 주장한다.ID의 유일한 요건은 ID가 보안 [citation needed]도메인 내에서 고유해야 한다는 것입니다.

오센티케이터는 일반적으로 다음 4가지 요소 [citation needed]중 적어도1가지를 기반으로 합니다.

  • 패스워드나 개인식별번호(PIN) 등 알고 있는 것.이는 계정의 소유자만 계정에 액세스하는 데 필요한 비밀번호 또는 PIN을 알고 있다고 가정합니다.
  • 스마트 카드나 보안 토큰과 같이 가지고 있는 것.이는 계정 잠금 해제에 필요한 스마트 카드 또는 토큰을 계정의 소유자만 가지고 있다고 가정합니다.
  • 지문, 음성, 망막, 홍채 등의 특징.
  • 현재 위치(예: 회사 방화벽 내부 또는 외부) 또는 개인 GPS 장치에 대한 로그인 위치 근접.

접근 승인

액세스 승인은 [1]작업 중에 실제로 액세스를 허용하거나 거부하는 기능입니다.

접근 승인 시 시스템은 접근요구와 인가정책의 공식적인 표현을 비교하여 요구가 허가되어야 하는지 거부되어야 하는지를 판단합니다.또한 접속 평가는 온라인/[2]온오잉으로 할 수 있습니다.

설명 책임

어카운터빌리티는 감사증적(레코드)이나 로그 등의 시스템컴포넌트를 사용하여 서브젝트와 액션을 관련짓습니다.기록된 정보는 환자를 통제 사용자에게 매핑하기에 충분해야 합니다.감사[citation needed] 추적 및 로그는

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

로그를 정기적으로 검토하는 사람이 없고 로그를 안전하고 일관되게 유지하지 않으면 로그가 [citation needed]증거로 인정되지 않을 수 있습니다.

많은 시스템에서 클리핑 수준이라고 하는 미리 정의된 기준 또는 임계값을 기반으로 자동 보고서를 생성할 수 있습니다. 예를 들어 다음과 [citation needed]같은 보고서를 생성하도록 클리핑 수준을 설정할 수 있습니다.

  • 특정 기간 동안 3회 이상 로그온 시도 실패
  • 비활성화된 사용자 계정을 사용하려는 시도

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

액세스 컨트롤

액세스 컨트롤 모델은 임의 또는 비재량으로 분류될 수 있습니다.가장 널리 인식되고 있는 3가지 모델은 Defactional Access Control(DAC; 임의 접근컨트롤), Mandatory Access Control(MAC; 필수 접근컨트롤) 및 Role Based Access Control(RBAC; 롤베이스 접근컨트롤)입니다.MAC는 [citation needed]비재량입니다.

임의 접근 제어

Defactional Access Control(DAC; 임의 접근컨트롤)은 오브젝트 소유자에 의해 결정되는 정책입니다.소유자는 개체에 액세스할 수 있는 사용자와 해당 개체에 대한 권한을 결정합니다.

DAC의[citation needed] 두 가지 중요한 개념은 다음과 같습니다.

  • 파일 및 데이터 소유권:시스템의 모든 개체에는 소유자가 있습니다.대부분의 DAC 시스템에서는 각 객체의 초기 소유자가 객체가 생성된 주체입니다.오브젝트의 액세스정책은 오브젝트의 소유자에 의해 결정됩니다.
  • 액세스 권한 및 권한:소유자가 특정 리소스에 대해 다른 주제에 할당할 수 있는 컨트롤입니다.

액세스 제어는 ACL 기반 또는 기능 기반 액세스 제어 시스템에서 재량할 수 있습니다(기능 기반 시스템에서는 일반적으로 '소유자'라는 명확한 개념은 없지만 오브젝트 작성자는 액세스 정책에 대해 비슷한 수준의 제어를 가집니다).

필수 접근 제어

필수 액세스 제어는 특정 사용자가 리소스에 액세스할 수 있도록 허용하는 규칙이 존재하는 경우에만 리소스에 대한 액세스를 허용하는 것을 의미합니다.관리가 어렵지만, 일반적으로 매우 민감한 정보를 보호하기 위해 사용되는 것은 정당합니다.예를 들어 특정 정부 및 군사 정보를 포함합니다.계층형 접근컨트롤 또는 감도라벨을 사용하여 정보를 보호할 수 있는 경우 관리가 (필요에 따라) 간소화되는 경우가 많습니다.이 방법을 '필수'로 하는 것은 규칙 또는 감도 [citation needed]라벨의 사용입니다.

  • 감도 라벨:이러한 시스템에서는 서브젝트 및 오브젝트에 라벨이 할당되어 있어야 합니다.제목의 민감도 레이블은 신뢰 수준을 지정합니다.개체의 민감도 레이블은 액세스에 필요한 신뢰 수준을 지정합니다.지정된 개체에 액세스하려면 대상 개체의 감도 수준이 요청된 개체보다 크거나 같아야 합니다.
  • 데이터 Import 및 내보내기: 다른 시스템에서 정보를 Import하여 다른 시스템(프린터 포함)으로 내보내는 것을 제어하는 것은 이러한 시스템의 중요한 기능입니다.이러한 기능은 기밀 정보가 항상 적절하게 보호되도록 감도 라벨을 적절히 유지 및 구현해야 합니다.

필수 접근 [citation needed]제어를 적용하려면 일반적으로 다음 두 가지 방법이 사용됩니다.

  • 규칙 기반(또는 라벨 기반) 액세스 제어:이러한 유형의 제어는 요청된 개체에 대한 액세스에 대한 특정 조건을 추가로 정의합니다.필수 접근 제어 시스템은 규칙 기반 접근컨트롤의 단순한 형식을 구현하여 접근을 허용할지 거부할지 결정합니다.
    • 개체의 민감도 레이블
    • A 피사체의 민감도 레이블
  • 격자 기반 액세스 제어:여러 객체 및/또는 서브젝트와 관련된 복잡한 접근컨트롤 결정에 사용할 수 있습니다.격자 모델은 대상 및 개체와 같은 요소 쌍에 대해 가장 큰 하한 및 최소 상한 값을 정의하는 수학적 구조입니다.

MAC를 실장하는 시스템은 거의 없습니다.XTS-400 및 SELinux가 실장하는 시스템의 예입니다.

역할 기반 액세스 제어

Role-Based Access Control(RBAC; 롤베이스 액세스컨트롤)은 소유자가 아닌 시스템에 의해 결정되는 접근정책입니다.RBAC는 상용 어플리케이션 및 다단계 보안 요건이 존재할 수 있는 군사 시스템에서도 사용됩니다.RBAC는 DAC와 달리 사용자가 리소스에 대한 액세스를 제어할 수 있도록 하는 반면, RBAC에서는 액세스가 사용자의 제어 범위 밖에 있는 시스템레벨로 제어됩니다.RBAC는 재량권이 아니지만 주로 권한 처리 방법에 따라 MAC와 구별할 수 있습니다.MAC는 사용자의 클리어런스 수준과 추가 라벨을 기반으로 읽기 및 쓰기 권한을 제어합니다.RBAC는 전자상거래와 같은 복잡한 작업을 포함하거나 읽기 또는 쓰기처럼 간단한 권한 모음을 제어합니다.RBAC의 역할은 권한 세트로 볼 수 있습니다.

RBAC에는 다음 3가지 주요 규칙이 정의되어 있습니다.

  1. 역할 할당: 서브젝트는 서브젝트가 적절한 역할을 선택했거나 할당된 경우에만 트랜잭션을 실행할 수 있습니다.
  2. 역할 권한 부여:주제의 활성 역할은 주체에 대해 인증되어야 합니다.위의 규칙 1에서는 이 규칙에 따라 사용자는 자신이 인가받은 역할만 맡을 수 있습니다.
  3. 트랜잭션 승인:서브젝트는 서브젝트의 활성 역할에 대해 트랜잭션이 승인된 경우에만 트랜잭션을 실행할 수 있습니다.규칙 1과 규칙2에서는 이 규칙에 따라 사용자는 자신이 인가받은 트랜잭션만 실행할 수 있습니다.

추가 제약 조건을 적용할 수도 있으며, 상위 수준 역할이 하위 수준 하위 역할이 소유한 권한을 포함하는 계층에서 역할을 결합할 수 있습니다.

대부분의 IT 벤더는 RBAC를 1개 이상의 제품으로 제공하고 있습니다.

속성 기반 액세스 제어

Attribute-Based Access Control(ABAC;[4][5] 속성 기반 접근컨트롤)에서는 인증 후 사용자와 관련된 주체의 권리에 기반하지 않고 사용자의 속성에 기반하여 액세스가 허용됩니다.사용자는 액세스 제어 엔진에 대한 자신의 속성에 대한 이른바 클레임을 증명해야 합니다.속성 기반 액세스 제어 정책은 개체에 대한 액세스를 허용하기 위해 충족해야 하는 클레임을 지정합니다.예를 들어, 클레임은 "18세 이상"일 수 있습니다.이 주장을 증명할 수 있는 사용자는 누구나 접근이 허용됩니다.인증 및 식별이 엄격히 필요하지 않은 경우 사용자는 익명일 수 있습니다.그러나 익명으로 청구를 증명하기 위한 수단이 필요하다.예를 들어 익명 [citation needed]자격 증명을 사용하여 이 작업을 수행할 수 있습니다.XACML(Extensible Access Control Markup Language)은 속성 기반 액세스 제어의 표준입니다.XACML 3.0은 2013년 [6]1월에 표준화되었습니다.

브레이크글라스 액세스컨트롤 모델

전통적으로 접근은 접근을 제한하는 목적을 가지고 있기 때문에 대부분의 접근컨트롤 모델은 "기본 거부 원칙"을 따릅니다.즉, 특정 접근요구가 명시적으로 허용되지 않으면 거부됩니다.이 동작은 시스템의 통상적인 동작과 경합할 수 있습니다.달성 가능한 잠재적 이익이 이 위험보다 큰 경우, 특정 상황에서 인간은 접근통제 정책 위반과 관련된 위험을 기꺼이 감수할 수 있습니다.이러한 필요성은 환자 기록에 대한 접근이 거부되면 환자가 사망할 수 있는 의료 분야에서 특히 두드러집니다.Break-Glass(Break-the-Glass라고도 함)는 사용자가 접근컨트롤 결정을 덮어쓸 수 있도록 함으로써 이 문제를 완화하려고 합니다.Break-Glass는 액세스 제어 고유의 방식(예: RBAC에)[7] 또는 범용(예: 기본 액세스 제어 [8]모델로부터 독립)으로 구현될 수 있습니다.

호스트 기반 액세스 제어(HBAC)

이니셜리즘 HBAC는 "호스트 기반 액세스 제어"[9]를 나타냅니다.

「 」를 참조해 주세요.

레퍼런스

  1. ^ 디터 골만컴퓨터 보안, 3차 교육Wiley Publishing, 2011, 페이지 387, 하단
  2. ^ Marcon, A. L.; Olivo Santin, A.; Stihler, M.; Bachtold, J., "A UCOnabc Resilient Authorization Evaluation for Cloud Computing", 병렬 및 분산 시스템, IEE 트랜잭션 on, vol 25, no, no, 45-746.
  3. ^ "Definition of: clipping level". PC Magazine.
  4. ^ 진, 신, 람 크리슈난, 라비 샌두."dac, mac 및 rbac을 포함하는 통합 속성 기반 액세스 제어 모델입니다."데이터 및 애플리케이션 보안 및 프라이버시 XXVI.스프링거 베를린 하이델베르크, 2012. 41-55.
  5. ^ 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). {{cite journal}}:Cite 저널 요구 사항 journal=(도움말)
  6. ^ eXtensible Access Control Markup Language(XACML) V3.0은 OASIS 표준으로 인정되며 eXtensible Access Control Markup Language(XACML) V3.0은 OAS 표준으로 인정됩니다.
  7. ^ 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. pp. 23–31. doi:10.1109/ACSAC.2009.12.
  8. ^ Brucker, Achim D.; Petritsch, Helmut (2009). "Extending Access Control Models with Break-glass.". ACM symposium on access control models and technologies (SACMAT). ACM Press. pp. 197–206. doi:10.1145/1542207.1542239.
  9. ^ Ballard, Ella Deon (2013). "Identity Management Guide: Managing Identity and Authorization Policies for Linux-Based Infrastructures". Red Hat. Retrieved 2014-01-06. Any PAM service can be identified as to the host-based access control (HBAC) system in IdM.