허가서비스
허가서비스는 사용자 인증/식별 완료후 해당 사용자에게 적절한 사용권한을 부여하는 서비스를 말한다.
사용 권한 할당을 위한 허가서비스는 계정관리를 위해 필요로 하는 허가/인가/권한관리 등으로 표현되며, 최근에는 EAM (Extranet Access Management), IAM(Identity Access Management)등의 주요 기능으로 흡수되고 있는 추세이다.
사용자 계정관리와 관련된 3A는 다음과 같다.
| 구분 | 설명 |
|---|---|
| 인증 (Authentication) | • 하나의 사용자 ID를 이용하여 다양한 시스템에 접근할 수 있는 통합인증(싱글 사인 온: Single Sign On)기능 • PKI, 생체인식 등 다양한 인증 방법 • 모든 업무 애플리케이션에 ID정책, PWD정책, 인증방법을 중앙에서 결정, 적용, 관리할 수 있는 시스템 • 사용자 스스로 자신의 패스워드를 관리할 수 있는 기능 |
| 인가 (Authorization) | • 기업의 일관된 정책을 유연성 있게 반영할 수 있는 권한 관리 체계 • 기존의 레거시를 포함한 다양한 플랫폼에 적용 가능한 권한 관리 인프라 • 개인의 프로파일을 반영한 개인화 기능 • 효율적인 권한 위임을 위한 서비스 체계 |
| 관리 (Administration) | • 통합적인 로깅과 이를 이용한 감사, 리포팅 기능 • 웹등을 이용한 접근성/관리성이 용이한 관리화면 • 모든 3A 기능을 관리할 수 있는 일원화된 관리 툴 |
PMI 구조
PMI는 SOA, AA, 권한 소유자, 권한 검증자로 구성되어 있다.
| 구분 | 설명 |
|---|---|
| SOA | • 공개키 기반구조의 루트 CA와 유사한 역할을 수행하는 자로서 권한 검증자가 무조건 신뢰하는 AA임 |
| AA | • SOA로부터 권한의 전부 또는 일부를 위임 받아 인증서 발급 업무를 수행하는 자로서 제3의 신뢰 기관. 속성 소유자의 권한, 지위, 임무 등 속성 정보의 요청을 중재하는 역할을 하며, 속성 정보의 종류와 조건을 정의한 규정에 따라 속성 소유자의 속성 정보에 의한 데이터베이스 접근 권한을 제공함 |
| 권한 주장자(권한소유자) (Privilege Holder) | • 인증서를 통해 AA로부터 권한에 대한 소유권을 보증 받은 자로서 PKI의 End-entity에 해당함 |
| 권한 검증자(Privilege Verifier) | • 속성 인증서를 받아 이것을 응용에 맞게 사용하는 자로서 권한 주장자가 권한을 정당하게 소유하고 있는지 확인함 |
PMI 구조(이미지)
PMI 모델
ITU-T.X509 표준에서는 속성 인증서를 정보보호 메커니즘으로 활용할 수 있도록 일반모델, 제어모델, 위임모델, 역할모델을 제시하고 있다.
| 구분 | 설명 |
|---|---|
| 일반 모델 (General Model) | • 일반적인 권한관리 모델은 객체(Object), 권한 주장자(Privilege Holder) 및 권한 검증자(Privilege Verifier)로 구성됨 • 객체 : 보호되는 자원을 의미하며 예를 들어 내부 네트워크시스템을 보호하는 방화벽 또는 파일시스템의 파일이 객체가 될 수 있음 • 권한 주장자 : 권한 주장자는 특정 권한을 소유하고 있는 주체 • 권한 검증자 : 일정한 권한을 소유하고 특정 환경에서 그 권한 주장자가 제시하는 권한이 적절한지 판단하는 개체로써 즉, 속성 인증서의 검증 모듈에 해당함 |
| 제어모델(Control Model) | • 권한 주장자, 권한 검증자, 객체 메쏘드, 권한 정책, 환경 변수들의 다섯 개의 구성요소로 이루어져 있음 |
| 위임모델(Delegation Model) | • PMI는 일반적으로 일반모델을 사용하여 일부 환경에서 권한을 위임하는 것이 필요하지만 이것은 모든 환경에서 꼭 필요한 경우는 아니며 원하는 PMI구조를 고려해서 선택적으로 수용 가능한 것임 • 위임모델은 권한 검증자, SOA, 다른 AA들, 그리고 권한 주장자로 구성됨 • 위임모델을 사용하지 않는 환경에서는 SOA가 권한 소유자에게 직접 속성 인증서를 발급해주지만 이 모델에서는 SOA가 어떤 개체가 AA의 역할을 할 수 있게 권한을 줄 수 있으며 나아가 자신의 권한을 다른 개체에게 위임할 수 있는 권한을 허가해 줄 수도 있음 • 위임모델에서는 권한 검증자는 End-entity의 권한을 검증하기 위해서 자신이 신뢰하는 SOA로부터 AA가 적절한 권한 우임을 받았는지 검증하는 과정이 추가적으로 필요하게 됨 |
| 역할모델(Roles Model) | • 역할모델은 개인들에게 간접적으로 권한을 할당할 수 있는 기능을 제공해 주며 이 모델에서는 개인들에게 직접 권한을 주지 않고 단지 속성 인증서의 role 속성에 몇몇 역할을 할당함 • 각 권한들은 개인들에게 할당되기보다는 역할 명세 인증서(Role Specification Certificate) 를 통해 역할에 할당되고 이런 방식으로 개인들에게 간접적으로 권한을 할당할 수 있음 • 간접적인 권한 할당은 어떤 역할에 할당된 권한이 변경되었을 때 개개인의 속성 인증서에 영향을 주지 않고 역할에 따르는 권한을 조정할 수 있으므로 상당한 장점을 가진다. 역할 명세 인증서는 공개키 인증서로서는 제공할 수 없으며 속성 인증서를 이용해야 함 • 만약, 이런 역할 명세 인증서를 사용할 수 없는 경우라면 다른 수단을 통해 역할에 권한을 할당할 수도 있음 |
접근제어
접근제어 개요
접근(Access)이란 컴퓨터 내 자원의 사용, 변경, 조회 등 어떤 행위를 할 수 있는 능력을 말하며 접근제어는 접근을 허용하거나 제한할 수 있는 수단이라 말할 수 있다.
전통적으로 접근제어(Access Control)는 보안영역중에서 상대적으로 가장 상위의 애플리케이션에 대한 관리적 보안을 의미하며 여기서 접근제어가 관리적인 보안의 개념을 띄는 것은 IT환경의 다수 사용자와 다수의 애플리케이션을 제공하고 있다는 특성과 접근권한이 있는 사용자들에게만 특정 데이터 또는 자원들이 제공되는 것을 보장하기 위한 자원관리의 특성을 가지고 있기 때문이다.
또한, 사용자에 대한 인증 후 실질적인 사용권한을 할당하기 위하여 PMI에서는 다양한 형태의 접근제어를 구현하고 있다.
응용수준에서의 보안정책 적용 기법
응용 수준에서 실제적으로 보안정책을 적용하는 접근제어 기법으로는 강제적 접근제어, 임의적 접근제어, 역할기반 접근제어로 구분할 수 있다.
이외에도 행위기반의 접근제어 등을 비롯하여 다양한 방법으로 접근제어를 달성할 수 있지만 기업조직 특성의 보안정책 반영과 사용자와 정보자원에 대한 권한관리의 유연성을 제공하는 역할기반 접근제어(RBAC)가 권한관리 기반구조를 구축하는 대안으로 사용되고 있다.
| 구분 | 설명 |
|---|---|
| 강제적 접근제어(Mandatory Access control, MAC) | • 강제적 접근제어는 각 정보에 결합된 보안 등급과 사용자에게 부여된 인가등급을 사전에 규정된 규칙과 비교하여 그 규칙을 만족하는 사용자에게만 접근 권한을 부여하는 보안정책으로서, 군사적 환경과 같이 정보의 기밀성이 매우 중요시되는 환경에서 사용되고 있지만 보안 등급과 같이 확연하게 구분되는 기준의 설정이 모호한 경우에는 적용의 한계가 존재함 |
| 임의적 접근제어(Discretionary Access Cotnrol, DAC) | • 임의적 접근제어는 사용자 본위로 접근권한을 정의하는 방법으로 사용자의 식별(Identification)과 권한인가에 기초한 접근제어 방식임 • 만일, 사용자가 특정 모드로 객체에 접근할 수 있다는 것을 명시한 권한을 소유하였다면 접근은 허락되고, 그렇지 않으면 거절됨 • 임의적 접근제어의 임의적 유연성은 다양한 시스템과 응용에 적당하여 상업 및 기업 환경에서 다양하게 구현되어 사용되고 있지만 접근권한의 명백한 표현과 관리성에 대한 개선의 여지가 존재함 |
| 역할기반 접근제어(Role BaseAccess Control, RBAC) | • RBAC은 임의적 접근제어 및 강제적 접근제어와 달리 사용자와 접근권한 간의 1:1 매핑구조를 탈피하여 역할(Role)이라는 추상화된 개념을 도입하여 사용자-역할, 역할-접근권한의 2단계 구조를 가지는 접근제어 기법임 • RABAC의 기본적인 개념은 임의의 사용자가 기업이나 조직의 정보 자원을 접근할 수 없도록 하는 것이며 대신에 접근권한이 역할에 부여되고 사용자는 적절한 역할에 소속됨으로써 역할의 수행에 필요한 최소 자원(Least of Privilege)만을 접근할 수 있도록 함 • 이러한 아이디어는 권한 관리를 매우 단순화 시켜주고 기업의 특정한 보안정책을 구현하는데 있어서 유연성을 제공하는 장점이 있음 • 사용자는 그들의 업무적 권한과 책임에 따라 특정 역할의 구성원이 되며 접근 구조의 변경 없이도 역할의 변경을 쉽게 할 수 있음 |
RBAC
RBAC의 근원
RBAC의 중요 요소인 역할개념은 적어도 25년 동안 소프트웨어 애플리케이션에서 사용되어 왔다. 그러나, RBAC의 개념이 정립되어 전통적인 MAC과 DAC개념처럼 충분하게 발달한 메커니즘으로 나왔던 것은 불과 10년 이내이다.
RABAC의 근원은 UNIX시스템이나 다른 OS의 사용자 그룹과 데이터베이스의 특권 그룹 및 직무 분리 개념을 포함한다. 근대 RBAC의 개념은 하나의 접근 통제에 역할, 역할의 계층구조, 역할의 활성화, 사용자-역할 멤버십 및 역할 집합 활성화에 대한 모든 개념을 의미한다.
이러한 구조는 이전에 발표되었던 다양한 형식들을 일반화 시킨 것이다. 현재의 RBAC모델을 위한 구조는 Sandhu에 의해 정의되었고 이후의 지속적인 연구 발전이 이루어 지고 있다.
RBAC 구성 요소
RBAC의 구성요소는 크게 핵심(Core) RBAC, 계층(Hierarchical)RBAC, 제약(Constraint)RBAC으로 구분할 수 있으며 핵심 RBAC은 모든 RBAC 시스템에서 기본적으로 필요하다.
일반적으로 RBAC참조모델에서 정의하는 엔티티는 다음과 같다.
- 사용자 : 인간으로 국한하며, 기계, 네트워크 또는 에이전트 등으로 확장 가능
- 역할 : 어떤 사용자에게 부여된 직권과 책임에 관련된 어떤 조직의 작업 함수
- 오브젝트 : 정보를 저장하거나 정보를 수신하는 엔티티
- 오퍼레이션 : 사용자가 수행하는 이미지
- 퍼미션 : 오브젝트와 오퍼레이션의 쌍
| 구분 | 설명 |
|---|---|
| 핵심 RBAC | • 핵심 RBAC은 RBAC의 필수적인 부분을 구성하는 요소이며 RBAC의 기본 개념은 사용자가 역할에 할당되고, 퍼미션이 역할에 할당되고, 사용자는 역할의 구성원으로서 사용권한을 획득하는 것임 • 핵심 RBAC은 사용자-역할, 퍼미션-역할 할당의 다대다(Many to Many)관계에 대한 요구사항을 포함하여 사용자는 여러 역할에 할당되고 하나의 역할은 많은 사용자를 포함할 수 있으며 사용권한에 대해서도 동일함 |
| 계층 RBAC | • 계층 RBAC은 역할 계층의 지원을 위해 필요한 구성요소이며 역할의 계층은 역할의 선후 관계를 수학적 부분 순서(Partial Order)로 정의하는 것이임 • 이로서 상위 역할은 하위 역할에 할당된 퍼미션을 획득하며 하위 역할은 상위 역할에 할당된 사용자를 멤버로 획득함 • 계층 RBAC은 일반 계층 RBAC(General hierarchical RBAC) 과 한계 계층 RBAC(Limited hierarchical RBAC)으로 구분됨 |
| 제약 RBAC | • 제약 RBAC은 정적 직무분리(Static Separation of Duty, SSD)와 동적 직무분리(Dynamic Separation of Duty, DSD)로 구분할 수 있으며 직무분리 관계는 정책 설정 시 역할에 대한 사용자의 충돌을 방지하기 위한 것임 • SSD - SSD관계는 역할기반 시스템에서 역할의 특성상 한 사용자가 동시에 서로 상충되는 역할에 할당되어 관련된 퍼미션을 획득하는 시점에서 발생함 - 이러한, 충돌을 막는 방법은 사용자가 역할에 할당될 때 제약 조건(정적 직무분리)을 부여하는 것임 • DSD - DSD관계는 정적 직무분리와 같이 사용자에 대한 퍼미션을 제약하는 것임 - 그러나, 정적 직무분리와는 달리 사용자 세션 동안에 활성화된 역할들 중에서 퍼미션이 충동을 제한하는 것임 - 즉, 정적 직무분리는 세션과 무관하게 충돌을 원천적으로 피하는 방법(전체 퍼미션공간의 제약)이라면 동적 직무분리는 실제 실행시점에서 퍼미션의 충돌을 피하는 방법(사용자의 접근 가능성의 제약)임 |
