0 소개
관리 정보 시스템은 복잡한 인간-컴퓨터 상호 작용 시스템이며, 각 특정 링크는 보안 위협을 받을 수 있습니다. 강력한 권한 관리 시스템을 구축하여 관리 정보 시스템의 보안을 보장하는 것이 중요합니다. 권한 관리 시스템은 관리 정보 시스템에서 가장 재사용 가능한 모듈 중 하나입니다. 모든 다중 사용자 시스템은 필연적으로 동일한 권한 요구 사항을 수반하며 엔티티 인증, 데이터 기밀성, 데이터 무결성, 부인 방지, 액세스 제어 등의 보안 서비스를 해결해야 합니다 (ISO7498-2 에 따르면). 예를 들어, 액세스 제어 서비스를 사용하려면 시스템 제어 운영자가 액세스할 수 있는 리소스를 제어하고 운영자가 설정한 운영 권한에 따라 이러한 리소스를 조작하는 방법을 결정해야 합니다.
현재 권한 관리 시스템도 중복 개발률이 가장 높은 모듈 중 하나다. 기업에서, 서로 다른 응용 시스템은 독립적인 권한 관리 시스템을 가지고 있다. 각 권한 관리 시스템은 해당 시스템의 권한 관리 요구 사항만 충족하며 데이터 저장소, 권한 액세스, 권한 제어 메커니즘 등에 따라 다를 수 있습니다. 이 불일치에는 다음과 같은 단점이 있습니다.
A. 시스템 관리자는 여러 권한 관리 시스템을 유지 관리하고 작업을 반복해야 합니다.
B 사용자 관리, 조직 등의 데이터 중복 유지 관리는 데이터의 일관성과 무결성을 보장하지 않습니다.
C. 서로 다른 권한 관리 시스템 설계, 개념 및 기술로 인해 단일 사인온을 실현하는 것은 매우 어렵고 권한 관리 시스템 통합에도 문제가 있어 기업 포털 건설에 어려움을 겪고 있습니다.
통합 보안 관리 설계 아이디어, 표준화 된 설계 및 고급 기술 아키텍처 시스템을 사용하여 범용, 완전성, 보안, 관리 용이성, 이식성 및 확장 가능한 권한 관리 시스템을 구축하여 권한 관리 시스템을 실제로 권한 제어의 핵심으로 만들고 시스템 보안을 유지하는 데 중요한 역할을 할 필요가 있습니다.
에서는 J2EE 아키텍처 기술을 사용하여 구현된 RBAC (역할 기반 정책 액세스 제어) 모델을 기반으로 하는 권한 관리 시스템의 설계 및 구현에 대해 설명합니다. 응용 프로그램 시스템에 액세스하고 제어하는 방법에 대해서도 설명합니다.
1 J2EE 건축 설계 사용.
J2EE 엔터프라이즈 플랫폼 아키텍처를 사용하여 권한 관리 시스템을 구축합니다. J2EE 아키텍처는 다중 계층 분산 애플리케이션 모델, 구성 요소 및 재사용 가능한 구성 요소, 통합된 전체 모델 및 유연한 트랜잭션 제어 등의 기능을 갖춘 고급 소프트웨어 아키텍처 아이디어를 통합합니다.
시스템은 논리적으로 고객 계층, 웹 계층, 비즈니스 계층 및 자원 계층의 네 가지 계층으로 나뉩니다.
A. 클라이언트 계층은 주로 인간-컴퓨터 상호 작용을 담당합니다. 시스템 관리자가 웹 브라우저를 통해 액세스하거나 다른 비즈니스 시스템에 대한 API 및 웹 서비스 호출을 제공할 수 있습니다.
B. 웹 계층은 웹을 통해 시스템에 액세스하는 클라이언트에 계층 논리를 나타내는 서비스를 캡슐화합니다.
C. 비즈니스 계층은 비즈니스 데이터 및 비즈니스 논리를 포함한 비즈니스 서비스를 제공하고 시스템 비즈니스 프로세스를 중앙 집중화합니다. 주요 비즈니스 관리 모듈에는 조직 관리, 사용자 관리, 자원 관리, 권한 관리 및 액세스 제어가 포함됩니다.
D. 자원 계층은 주로 데이터의 저장, 구성 및 관리를 담당합니다. 자원 계층은 ORACLE 과 같은 대규모 관계형 데이터베이스와 Microsoft Active Directory 와 같은 LDAP (lightweight directory access protocol) 디렉토리 서버의 두 가지 구현을 제공합니다.
2 RBAC 모드
액세스 제어는 자원의 무단 사용을 방지하는 방어 조치입니다. 기본 목표는 주체 (사용자, 프로세스, 서비스 등) 에 대한 액세스를 제한하는 것입니다. ) 을 눌러 객체 (파일, 시스템 등) 에 액세스합니다. ), 컴퓨터 시스템을 합법적 인 범위 내에서 사용할 수 있도록; 사용자가 무엇을 할 수 있는지, 특정 사용자의 흥미를 나타내는 프로그램이 무엇을 할 수 있는지 결정합니다 [1].
기업 환경에는 일반적으로 자율 액세스 제어 방법, 강제 액세스 제어 방법 및 역할 기반 액세스 제어 방법 (RBAC) 의 세 가지 액세스 제어 정책이 있습니다. 그 중 자율성이 너무 약하고, 강제성이 너무 강하며, 둘 다 작업량이 많아 관리하기가 불편하다 [1]. 역할 기반 액세스 제어 방법은 현재 대기업의 통합 리소스 액세스 제어를 해결하는 효과적인 방법으로 인정받고 있습니다. 그것의 두 가지 두드러진 특징은 1 이다. 권한 관리의 복잡성을 줄이고 관리 부담을 줄입니다. 2. 기업의 보안 정책을 유연하게 지원하여 기업의 변화에 큰 유연성을 제공합니다.
NIST (National Standards and Technology Institute) 표준 RBAC 모델은 네 가지 구성 요소 모델로 구성됩니다. 네 가지 구성 요소 모델은 기본 모델 RBAC0 (코어 RBAC), 역할 분류 모델 RBAC 1 (계층 RBAC), 역할 제한 모델 RBAC2 (제약 RBAC) 및 통합 모델 RBAC3 (조합 RBAC) [/
A.RBAC0 은 RBAC 제어 시스템을 구성할 수 있는 최소 요소 세트를 정의합니다. RBAC 에는 사용자 (users), 역할 (roles), 객체 (OBS), 작업 (OPS) 및 권한 (PRMS) 의 다섯 가지 기본 데이터 요소가 있습니다. 권한은 사용자가 아닌 롤을 부여합니다. 사용자에게 역할이 할당되면 해당 사용자는 해당 역할에 포함된 권한을 갖게 됩니다. 세션은 사용자와 활성화된 역할 집합 간의 매핑입니다. RBAC0 과 기존 액세스 제어의 차이점은 간접적인 유연성이 향상되었다는 것입니다. RBAC 1, RBAC2 및 RBAC3 은 모두 RBAC0 의 확장입니다.
B.RBAC 1 에서는 역할 간의 상속 관계를 일반 상속 관계와 제한 상속 관계로 설명합니다. 일반적인 상속 관계에서는 역할 상속 관계만 절대적인 편순서 관계로 요구하여 역할 간의 다중 상속을 허용합니다. 제한된 상속 관계는 역할 상속 관계가 트리 구조라고 더 요구합니다.
C.RBAC2 모델은 책임 분리를 추가합니다. RBAC2 의 제약 조건은 역할에 권한을 부여할 때 또는 사용자에게 역할을 부여할 때, 그리고 사용자가 특정 시점에서 역할을 활성화할 때 따라야 하는 필수 규칙을 지정합니다. 책임 분리에는 정적 책임 분리와 동적 책임 분리가 포함됩니다. 제약 조건과 사용자-역할-권한 관계는 함께 RBAC2 모델의 사용자에 대한 액세스 권한을 결정합니다.
D.RBAC3 에는 RBAC 1 및 RBAC2 가 포함되어 역할 간의 상속 관계뿐만 아니라 책임 분리도 제공합니다.
3 코어 객체 모델 설계
RBAC 모델의 권한 설계 아이디어에 따라 권한 관리 시스템의 핵심 객체 모델이 설정됩니다.
개체 모델에는 주로 사용자, 그룹, 역할, 개체, 액세스 모드 및 운영자가 포함됩니다. 주요 관계는 역할 권한 지정 PA (권한 할당) 및 사용자 역할 지정 UA (사용자 할당) 에 대한 설명은 다음과 같습니다.
A. 제어 객체: 시스템 보호 리소스 및 액세스 가능한 객체입니다. 자원 정의는 다음 두 가지 문제에주의를 기울여야합니다.
1. 자원에는 계층적 관계와 포함 관계가 있습니다. 예를 들어, 웹 페이지는 리소스이고, 웹 페이지의 버튼, 텍스트 상자 등의 객체도 리소스이며, 웹 노드의 하위 노드입니다. 버튼에 액세스할 수 있는 경우 페이지에 액세스할 수 있어야 합니다.
2. 여기에 언급된 자원 개념은 특정 자원의 인스턴스가 아닌 자원 클래스를 의미합니다. 자원 범주와 자원 인스턴스의 구분과 자원 세분성의 세분화는 권한 관리 시스템과 애플리케이션 시스템의 관리 경계를 결정하는 데 도움이 됩니다. 권한 관리 시스템에는 리소스 범주를 관리할 수 있는 권한이 필요하고, 응용 시스템에는 특정 리소스 인스턴스를 관리할 수 있는 권한이 필요합니다. 두 가지의 차이점은 주로 다음 두 가지 고려 사항을 기반으로합니다.
한편, 자원 인스턴스에 대한 권한은 종종 자원과 연관되어 있습니다. 즉, 리소스 인스턴스와 리소스에 액세스하는 주체 간의 관계에 따라 리소스의 인스턴스 권한을 확인할 수 있습니다.
예를 들어, 관리 정보 시스템의 경우, 서로 다른 부서의 고객은 업무 영역별로 나누어야 합니다. A 구역과 B 구역 모두 고객 자료를 수정하는 관리 자원을 가지고 있으며, 여기서' 고객 프로필' 은 자원 범주에 속한다. A 구역이 A 구역에서 관리하는 고객 데이터만 수정할 수 있도록 규정한 경우, 자원 인스턴스의 범주에 속하는 데이터의 귀속을 구분해야 합니다. 고객 프로필 (자원) 자체에는 특정 자원의 인스턴스 작업을 구분하고 관할 정보 내용을 수정할 수 있도록 사용자 정보 (고객 데이터에는 업무 영역의 속성이 포함될 수 있음) 가 있어야 합니다.
한편, 자원에 대한 인스턴스 권한은 종종 상당한 비즈니스 논리적 종속성을 갖습니다. 비즈니스 논리에 따라 권한 결정 원칙과 정책이 완전히 다르다는 의미인 경우가 많습니다.
B. 권한: 보호된 자원 작업에 대한 액세스 권한이 특정 자원 인스턴스에 바인딩됩니다. 이에 따라 액세스 정책은 리소스 범주와 관련이 있으며 리소스 범주에 따라 액세스 방식이 다를 수 있습니다. 예를 들어 페이지에는 열 수 있는 액세스 모드와 열 수 없는 액세스 모드, 단추에 사용할 수 있는 액세스 모드와 사용할 수 없는 액세스 모드, 텍스트 편집 상자에 편집 가능한 액세스 모드와 편집 불가능한 액세스 모드가 있습니다. 동일한 자원에 대한 액세스 정책에 제외 및 포함 관계가 있을 수 있습니다. 예를 들어 데이터 세트의 수정 가능한 액세스 모드에는 쿼리 가능한 액세스 모드가 포함됩니다.
C. 사용자: 권리의 소유자 또는 주체입니다. 사용자와 권한은 권한 부여 관리를 통해 분리되고 바인딩됩니다.
D. 사용자 그룹: 사용자 모음입니다. 상업 논리의 판단에서, 개인의 정체성이나 집단 정체성에 근거하여 판단할 수 있다. 시스템은 사용자 집단의 개념을 약화시키고 주로 사용자의 방식 (개인 신분) 을 구현합니다.
E. 역할: 권력 분배의 단위와 운반 대. 역할은 상속 관계 지원을 통해 계층 적 권한을 지원합니다. 예를 들어 과장이라는 배역은 과장의 배역도 있고, 과실에서 서로 다른 업무 인원의 배역도 있다.
F. 작업: 리소스 범주 및 액세스 정책 바인딩을 완료합니다.
G. 롤 권한 할당 PA: 작업과 롤 간의 연관 매핑을 구현합니다.
H. 사용자 롤 지정 UA: 사용자와 롤 간의 연관 매핑을 구현합니다.
객체 모델은 결국 액세스 제어 모델을 액세스 매트릭스로 변환합니다. 액세스 매트릭스의 행은 사용자, 열 매핑 작업, 각 매트릭스 요소는 해당 목표에 부여된 액세스 및 구현 동작에 해당하는 역할을 지정합니다. 액세스 매트릭스의 행에 따라 CL (액세스 가능성) 의 내용입니다. 액세스 매트릭스의 열에 따라 ACL (액세스 제어 목록) 의 내용입니다.
4 권한 액세스 메커니즘
권한 관리 시스템: 사용자 식별, 사용자 정보, 조직 구조 정보, 권한 관계 테이블 계산을 담당하는 중앙 집중식 권한 관리 서비스를 제공합니다.
사용자의 최소 권한은 사용자, 역할, 작업, 액세스 정책 및 제어 객체 간의 관계를 기준으로 계산되며 권한의 양수 및 음수 부여를 고려하여 계산됩니다. 비즈니스 논리 계층에서 Session Bean 을 사용하여 이 서비스를 구현하거나 웹 서비스로 게시할 수 있습니다. 애플리케이션 시스템 액세스 권한 계산 서비스를 중앙에서 제어하고 권한 관계 테이블, 즉 이진 그룹 {ObjectId, operated} 를 반환합니다.
애플리케이션 시스템 측: 액세스 능력 테이블 CL 과 액세스 제어 테이블 ACL 의 두 가지 선택적 액세스 방법으로 액세스 관리 시스템에 액세스할 수 있습니다.
J2EE 프레임워크 기반 애플리케이션 시스템을 예로 들어 액세스 프로세스를 설명합니다.
A. 먼저, 양식 기반 인증을 사용하여 로그인 요청은 서블릿에 의해 중앙에서 처리됩니다 [2]. 인증될 개체가 사용자임을 고려하여 ACL 기반 액세스 모드를 사용합니다. 사용자가 로그인할 때 권한 관리 시스템의 사용자 인증 서비스를 호출합니다. 인증에 성공하면 권한 계산 서비스가 호출되고 권한 관계 테이블로 반환되며 로그인한 사용자의 글로벌 세션에 HashMap 으로 저장됩니다. 글로벌 세션이 없거나 세션이 만료된 경우 로그인 페이지로 리디렉션되어 권한을 다시 얻습니다.
B. 직접 URL 리소스에 대한 액세스 제어는 CL 액세스를 기반으로 합니다. 사용자가 URL 주소를 직접 입력하여 페이지에 액세스하는 경우 액세스를 제어하는 두 가지 방법이 있습니다: 1. 권한 태그에서 CL 을 읽어서 제어합니다. 2. 필터 모드 제어 권한을 취하고 권한이 없을 경우 로그인 페이지로 리디렉션합니다.
5 액세스 제어 메커니즘
권한에 의해 제어되는 자원 범주는 애플리케이션 시스템의 요구에 따라 정의되며, 의미 및 제어 규칙도 애플리케이션 시스템에서 제공하며, 권한 관리 시스템에 투명하며, 권한은 서로 다른 애플리케이션 시스템의 자원 및 작업을 균일하게 처리합니다. 응용 프로그램 시스템이 권한 관리 시스템을 호출하여 얻은 권한 관계 테이블도 시스템 해석을 적용해야 합니다. 이러한 설계에 따라 권한 관리 시스템은 일반적이며 권한 제어 메커니즘은 응용 프로그램 시스템에 의해 처리됩니다.
응용 프로그램 시스템의 액세스 제어는 특정 기술 환경과 관련이 있기 때문에 J2EE 아키텍처 기반 응용 프로그램 시스템의 경우 시스템의 주요 디스플레이 구성 요소는 태그 라이브러리 및 액세스 제어 구성 요소 * * * 를 통해 구현된 JSP 페이지입니다.
A. 권한 id: 레이블을 사용하여 서로 다른 수준의 리소스를 식별하고 페이지 권한 레이블은 페이지 객체를 식별합니다.
B. 권한 등록: JSP 페이지의 권한 제어 탭을 통해 JSP 의 제어 권한을 읽습니다. 권한 등록 구성 요소를 통해 JSP 페이지의 권한 제어 객체와 규칙을 권한 관리 정보 시스템에 등록합니다.
C. 권한 제어: 시스템 사용자가 시스템에 로그인할 때 권한 관리 시스템에서 권한 관계 테이블을 가져오면 권한 레이블 제어 페이지가 표시됩니다. 반면 권한 제어 구성 요소는 비즈니스 논리에서 해당 권한, 특히 비즈니스 논리와 밀접한 관련이 있는 제어 객체 인스턴스의 권한 제어를 제어하는 데 사용됩니다.
6 권한 저장 메커니즘
권한 관리 시스템은 LDAP (lightweight directory access protocol) 디렉토리 서비스 데이터베이스와 관계형 데이터베이스의 두 가지 선택적 저장 메커니즘을 사용합니다. 사용자 정보, 조직 구조, 역할, 작업, 액세스 방법 등의 정보를 저장합니다.
이 중 디렉토리 서비스 시스템은 LDAP 표준을 기반으로 광범위한 데이터 통합 및 * * * 공유 기능을 갖추고 있습니다. 메타 디렉토리 기능을 사용하면 기존 엔터프라이즈 인프라와 빠르고 간결하게 통합할 수 있어 기존 RDBMS 및 LDAP 사용자 데이터베이스와 같은 사용자 데이터베이스 간의 동기화 문제를 해결할 수 있습니다.
7 결론
이 문서에서는 RBAC 모델을 기반으로 하는 권한 관리 시스템의 기술 시나리오에 대해 설명합니다. 이 권한 관리 시스템은 시스템 설계 및 개발 관행에 성공적으로 적용되었으며 응용 프로그램 시스템과 잘 통합되어 있습니다. 실제로 RBAC 모델 기반 권한을 채택하면 권한 할당이 직관적이고 이해하기 쉽고 사용하기 쉽다는 장점이 있습니다. 일자리와 권한의 변화 요구를 지원하는 우수한 확장성 계층 적 권한은 계층 적 조직 구조에 적용됩니다. 재사용성이 강하다.