Microsoft BHOLD 제품군 개념 가이드

MIM(Microsoft Identity Manager) 2016을 통해 조직은 사용자 ID 및 관련 자격 증명의 전체 수명 주기를 관리할 수 있습니다. ID를 동기화하고, 인증서와 암호를 중앙에서 관리하며, 이기종 시스템 간에 사용자를 프로비전하도록 구성할 수 있습니다. MIM과 함께 IT 조직은 생성부터 사용 중지까지 ID를 관리하는 데 사용된 프로세스를 정의 및 자동화할 수 있습니다.

Microsoft BHOLD 제품군은 역할 기반 액세스 제어를 추가하여 이러한 MIM 기능을 확장합니다. BHOLD를 통해 조직은 사용자 역할을 정의하고 중요한 데이터 및 애플리케이션에 대한 액세스를 제어할 수 있습니다. 액세스는 이러한 역할에 적합한 항목을 기반으로 합니다. BHOLD 제품군에는 조직 내 역할 관계의 모델링을 간소화하는 서비스 및 도구가 포함됩니다. BHOLD는 해당 역할을 권한에 매핑하고 역할 정의 및 관련된 권한이 사용자에게 올바르게 적용되는지 확인합니다. 이러한 기능은 MIM과 완전히 통합되어 최종 사용자 및 IT 직원에게 원활한 환경을 제공합니다.

이 가이드는 BHOLD 제품군과 MIM이 작동하는 방식을 이해하는 데 도움이 되며 다음 항목을 설명합니다.

• 역할 기반 액세스 제어
• 증명
• 보고
• 액세스 관리 커넥터

BHOLD는 새 배포에는 권장되지 않습니다. 이제 Microsoft Entra ID는 액세스 검토를 제공하여 BHOLD 증명 캠페인 기능과 액세스 할당 기능을 대체하는 권한 관리를 대체합니다.

역할 기반 액세스 제어

데이터 및 애플리케이션에 대한 사용자 액세스를 제어하는 가장 일반적인 방법은 DAC(임의 액세스 제어)를 통하는 것입니다. 가장 일반적인 구현에서는 모든 중요한 개체에 식별된 소유자가 있습니다. 소유자는 개별 ID 또는 그룹 구성원 자격에 따라 다른 사용자에게 개체에 대한 액세스를 부여 또는 거부하는 기능을 포함합니다. 실제로 DAC는 일반적으로 보안 그룹 과잉을 초래하는데, 일부는 조직 구조를 반영하고, 일부는 기능 그룹(예: 작업 유형 또는 프로젝트 할당)을 나타내며, 일부는 보다 임시적인 용도로 연결된 사용자 및 디바이스의 임시 컬렉션으로 구성됩니다. 조직이 성장함에 따라 이러한 그룹의 멤버 자격을 관리하는 것이 더욱 어려워집니다. 예를 들어, 직원이 한 프로젝트에서 다른 프로젝트로 이전되는 경우 프로젝트 자산에 대한 액세스를 제어하는 데 사용되는 그룹을 수동으로 업데이트해야 합니다. 이 경우 프로젝트 보안이나 생산성을 저해할 수 있는 실수가 흔히 발생합니다.

MIM에는 그룹 및 메일 그룹 구성원에 대한 자동화된 제어를 제공하여 이 문제를 완화하는 데 도움이 되는 기능이 포함되어 있습니다. 그러나 이것이 구조화된 방식으로 반드시 서로 관련이 있는 것은 아닌 확산 그룹의 본질적인 복잡성 문제를 해결해 주지는 않습니다.

이러한 확산을 크게 줄일 수 있는 한 가지 방법은 역할 기반 액세스 제어(RBAC)를 배포하는 것입니다. RBAC는 DAC에 대한 변위를 수행하지 않습니다. RBAC는 사용자 및 IT 리소스를 분류하기 위한 프레임워크를 제공하여 DAC를 기반으로 합니다. 이를 통해 해당 관계 및 해당 분류에 따라 적합한 액세스 권한을 명시적으로 설정할 수 있습니다. 예를 들어 사용자 직위 및 프로젝트 할당을 지정하는 사용자 특성을 할당함으로써 사용자는 사용자의 작업에 필요한 도구 및 사용자가 특정 프로젝트에 참여해야 하는 데이터에 대한 액세스 권한을 부여받을 수 있습니다. 사용자가 다른 작업과 다른 프로젝트 할당을 가정할 경우, 사용자의 직위와 프로젝트를 지정하는 특성을 변경하면 사용자의 이전 위치에 필요한 리소스에 대한 액세스만 자동으로 차단됩니다.

역할은 계층적 방식으로 역할 내에 포함될 수 있으므로(예: 영업 관리자와 영업 담당자의 역할은 보다 일반적인 판매 역할에 포함될 수 있음) 특정 역할에 적절한 권한을 할당하고 보다 포괄적인 역할을 공유하는 모든 사람에게도 적절한 권한을 쉽게 제공할 수 있습니다. 예를 들어 병원에서 모든 의료진에게는 환자 기록을 볼 수 있는 권한이 제공되지만 의사(의료 역할의 하위 역할)에게만 환자의 처방전을 입력할 수 있는 권한이 부여될 수 있습니다. 마찬가지로, 사무 역할에 속하는 사용자는 환자 기록에 대한 액세스가 거부될 수 있으며, 단, 청구서 작성자(사무 역할의 하위 역할)는 제공된 의료 서비스에 대해 환자에게 청구하는 데 필요한 일부 환자 기록에 대한 액세스 권한을 부여받을 수 있습니다.

RBAC의 또 다른 이점은 SoD(직무 분리)를 정의하고 시행할 수 있다는 것입니다. 이를 통해 조직은 동일한 사용자가 보유해서는 안되는 권한을 부여하는 역할의 조합을 정의할 수 있으므로 예를 들어 특정 사용자에게는 사용자가 지불을 시작하고 지불을 승인할 수 있는 역할을 할당할 수 없습니다. RBAC은 사용자별로 정책의 효과적인 구현을 평가하지 않고 이러한 정책을 자동으로 시행하는 기능을 제공합니다.

BHOLD 역할 모델 개체

BHOLD 제품군을 사용하면 조직 내에서 역할을 지정 및 구성하고, 사용자를 역할에 매핑하고, 적절한 권한을 역할에 매핑할 수 있습니다. 이 구조를 역할 모델이라고 하며 5가지 유형의 개체를 포함하고 연결합니다.

• 조직 구성 단위
• 사용자
• 역할
• 사용 권한
• 애플리케이션

조직 구성 단위

조직 구성 단위(OrgUnits)는 BHOLD 역할 모델에서 사용자가 구성되는 주요한 수단입니다. 모든 사용자는 하나 이상의 OrgUnit에 속해야 합니다. (실제로 사용자가 BHOLD의 마지막 조직 구성 단위에서 제거되면 사용자의 데이터 레코드가 BHOLD 데이터베이스에서 삭제됩니다.)

반드시 그런 것은 아니지만 대부분의 경우 조직 구성 단위는 실제 조직의 계층 구조를 나타내기 위해 BHOLD로 구조화됩니다(아래와 유사).

이 샘플에서 역할 모델은 회사 전체에 대한 조직 구성 단위(회장은 mororganizationalganizatinal 단위에 포함되지 않으므로 회장으로 표시)이거나 항상 존재하는 BHOLD 루트 조직 구성 단위를 해당 용도로 사용할 수 있습니다. 부회장이 경영하는 조직 부서를 나타내는 OrgUnits은 회사 조직 구성 단위에 배치됩니다. 다음으로, 마케팅 및 영업 이사에 해당하는 조직 구성 단위가 마케팅 및 영업 조직 구성 단위에 추가되고 지역 영업 관리자를 나타내는 조직 구성 단위가 동부 지역 영업 관리자를 위한 조직 구성 단위에 배치됩니다. 다른 사용자를 관리하지 않는 영업 사원은 동부 지역 영업 관리자의 조직 구성 단위 구성원이 됩니다. 사용자는 어느 수준에서나 조직 구성 단위의 구성원이 될 수 있습니다. 예를 들어 관리자가 아니며 부회장에게 직접 보고하는 비서실장은 부회장의 조직 구성 단위의 구성원이 됩니다.

조직 구성 단위는 조직 구조를 나타낼 뿐만 아니라 프로젝트 또는 전문화와 같은 기능적 기준에 따라 사용자 및 기타 조직 구성 단위를 그룹화하는 데 사용될 수도 있습니다. 다음 다이어그램은 고객 유형에 따라 영업 사원을 그룹화하는 데 조직 구성 단위가 사용되는 방식을 보여 줍니다.

이 예제에서 각 영업 사원은 두 개의 조직 구성 단위에 속합니다. 하나는 조직의 관리 구조에 있는 동료의 위치를 나타내는 것이고 다른 하나는 동료의 고객 기반(소매 또는 회사)을 나타내는 것입니다. 각 조직 구성 단위에는 차례로 서로 다른 역할을 할당할 수 있으며 조직의 IT 리소스에 액세스하는 데 다른 권한을 할당할 수 있습니다. 또한 부모 조직 구성 단위에서 역할을 상속할 수 있으므로 역할을 사용자에게 전파하는 프로세스가 간소화됩니다. 반면에, 특정 역할이 상속되는 것을 방지하여 특정 역할이 적절한 조직 구성 단위에만 연결되도록 할 수 있습니다.

BHOLD Core 웹 포털을 사용하여 BHOLD Suite에서 OrgUnits를 만들 수 있습니다.

사용자

위에서 언급한 것처럼 모든 사용자는 적어도 하나의 조직 구성 단위(OrgUnit)에 속해야 합니다. 조직 구성 단위는 사용자를 역할과 연관시키는 주요 메커니즘이기 때문에 대부분의 조직에서 지정된 사용자는 여러 OrgUnits에 속하므로 역할을 해당 사용자와 보다 쉽게 연관시킬 수 있습니다. 그러나 어떤 경우에는 사용자가 속하는 OrgUnits와 별개로 역할을 사용자와 연관시켜야 할 수도 있습니다. 따라서 사용자는 역할에 직접 할당되고 사용자가 속한 OrgUnits에서 역할을 얻을 수 있습니다.

사용자가 조직 내에서 활동 중이 아닌 경우(예: 병가 중) 사용자를 일시 중단할 수 있으며 이 경우 역할 모델에서 사용자를 제거하지 않고 모든 사용자의 권한을 철회합니다. 업무 복귀 시, 사용자는 재활성화될 수 있으며, 사용자의 역할에 의해 부여된 모든 권한이 복원됩니다.

사용자 개체는 BHOLD Core 웹 포털을 통해 BHOLD에서 개별적으로 만들거나 FIM 동기화 서비스와 함께 액세스 관리 커넥터를 사용하여 Active Directory Domain Services 또는 인적 리소스 애플리케이션과 같은 원본에서 사용자 정보를 가져올 수 있습니다.

사용자는 FIM 동기화 서비스를 사용하지 않고 BHOLD에서 직접 만들 수 있습니다. 사전 프로덕션 또는 테스트 환경에서 역할을 모델링할 때 유용할 수 있습니다. 또한 외부 사용자(예: 하도급자의 직원)에게 역할을 할당하여 직원 데이터베이스에 추가하지 않고도 IT 리소스에 대한 액세스 권한을 부여할 수 있습니다. 그러나 이러한 사용자는 BHOLD 셀프 서비스 기능을 사용할 수 없습니다.

역할

앞에서 설명한 것처럼 RBAC(역할 기반 액세스 제어) 모델에서 사용 권한은 개별 사용자가 아닌 역할과 연결됩니다. 이렇게 하면 사용자 권한을 별도로 부여하거나 거부하는 대신 사용자의 역할을 변경하여 각 사용자에게 사용자의 직무 수행에 필요한 권한을 부여할 수 있습니다. 결과적으로 사용 권한 할당에 더 이상 IT 부서의 참여가 필요하지 않지만 대신 비즈니스 관리의 일환으로 수행할 수 있습니다. 역할은 직접 또는 하위 역할을 사용하여 다른 시스템에 액세스하기 위한 권한을 집계할 수 있으므로 사용자 권한 관리에 IT 개입 필요성을 줄입니다.

역할은 RBAC 모델 자체의 기능이라는 점에 유의해야 하며 일반적으로 역할은 애플리케이션을 대상으로 프로비전되지 않습니다. 이를 통해 역할을 사용하도록 설계되지 않은 기존 애플리케이션과 함께 RBAC를 사용하거나, 애플리케이션 자체를 수정하지 않고도 비즈니스 모델을 변경해야 하는 요구를 충족시키도록 역할 정의를 변경할 수 있습니다. 대상 애플리케이션이 역할을 사용하도록 설계된 경우 애플리케이션 관련 역할을 사용 권한으로 처리하여 BHOLD 역할 모델의 역할과 해당 애플리케이션 역할을 연결할 수 있습니다.

BHOLD에서는 주로 두 가지 메커니즘을 통해 사용자에게 역할을 할당할 수 있습니다.

• 사용자가 구성원인 조직 구성 단위에 역할 할당
• 사용자에게 직접 역할 할당

상위 조직 구성 단위에 할당된 역할은 필요에 따라 구성원 조직 구성 단위로 상속될 수 있습니다. 역할이 조직 구성 단위에 할당되거나 상속된 경우 유효 또는 제안된 역할로 지정할 수 있습니다. 유효 역할인 경우, 조직 구성 단위의 모든 사용자에게 역할이 할당됩니다. 제안된 역할인 경우, 각 사용자 또는 구성원 조직 구성 단위가 사용자 또는 조직 구성 단위의 구성원에게 적용되도록 역할을 활성화해야 합니다. 이렇게 하면 조직 구성 단위의 모든 역할을 모든 구성원에게 자동으로 할당하는 대신, 조직 구성 단위와 연관된 역할의 하위 집합을 사용자에게 할당할 수 있습니다. 또한 역할에 시작일과 종료일을 지정할 수 있으며 역할을 효과적으로 수행할 수 있는 조직 구성 단위 내의 사용자 비율을 제한할 수 있습니다.

다음 다이어그램은 개별 사용자를 BHOLD의 역할에 할당할 수 있는 방식을 보여 줍니다.

이 다이어그램에서 역할 A는 상속 가능한 역할로 조직 구성 단위에 할당되므로 구성원 조직 구성 단위와 해당 조직 구성 단위 내의 모든 사용자가 이 역할을 상속합니다. 역할 B는 조직 구성 단위에 제안된 역할로 할당됩니다. 조직 구성 단위의 사용자가 역할의 사용 권한을 부여 받기 위해서는 먼저 활성화되어야 합니다. 역할 C는 유효한 역할이므로 해당 사용 권한은 조직 구성 단위의 모든 사용자에게 즉시 적용됩니다. 역할 D는 사용자에게 직접 연결되므로 해당 사용 권한은 해당 사용자에게 즉시 적용됩니다.

또한 사용자의 특성을 기반으로 사용자에 대해 역할을 활성화할 수 있습니다. 자세한 내용은 특성 기반 권한 부여를 참조하세요.

사용 권한

BHOLD의 사용 권한은 대상 애플리케이션에서 가져온 권한 부여에 해당합니다. 즉, BHOLD가 애플리케이션과 함께 작동하도록 구성되면 BHOLD가 역할에 연결할 수 있는 권한 부여 목록을 수신합니다. 예를 들어 AD DS(Active Directory Domain Services)가 애플리케이션으로 BHOLD에 추가되면 BHOLD 권한으로 BHOLD의 역할에 연결할 수 있는 보안 그룹 목록을 수신합니다.

권한은 애플리케이션에만 적용됩니다. BHOLD는 통합된 단일 사용 권한 보기를 제공하므로 역할 관리자가 사용 권한의 구현 세부 정보를 이해하지 몰라도 사용 권한을 역할과 연결할 수 있습니다. 실제로 시스템마다 사용 권한을 다르게 적용할 수 있습니다. FIM 동기화 서비스에서 애플리케이션으로 이어지는 애플리케이션별 커넥터에 따라 해당 애플리케이션에 대해 사용자 권한 변경이 제공되는 방식이 달라집니다.

애플리케이션

BHOLD는 외부 애플리케이션에 RBAC(역할 기반 액세스 제어)를 적용하는 방법을 구현합니다. 즉, BHOLD가 애플리케이션의 사용자 및 사용 권한으로 프로비전되면 BHOLD는 사용자에게 역할을 할당한 후 해당 사용 권한을 역할에 연결하여 사용 권한을 사용자와 연결할 수 있습니다. 애플리케이션의 백그라운드 프로세스는 BHOLD의 역할/권한 매핑을 기반으로 사용자에게 올바른 사용 권한을 매핑할 수 있습니다.

BHOLD 제품군 역할 모델 개발

역할 모델을 개발할 수 있도록 BHOLD 제품군은 사용하기 쉽고 포괄적인 도구인 모델 생성기를 제공합니다.

모델 생성기를 사용하기 전에 모델 생성기가 역할 모델을 구성하는 데 사용하는 개체를 정의하는 일련의 파일을 만들어야 합니다. 이러한 파일을 만드는 방법은 Microsoft BHOLD 제품군 기술 참조를 참조하세요.

BHOLD 모델 생성기를 사용하는 첫 번째 단계는 이러한 파일을 가져와서 기본 구성 요소를 모델 생성기에 로드하는 것입니다. 파일이 성공적으로 로드된 경우 모델 생성기가 여러 역할 클래스를 만드는 데 사용하는 기준을 지정할 수 있습니다.

• 사용자가 속한 OrgUnits(조직 구성 단위)에 따라 사용자에게 할당된 멤버 자격 역할
• BHOLD 데이터베이스에서 사용자 특성에 따라 사용자에게 할당된 특성 역할
• 조직 구성 단위에 연결되어 있지만 특정 사용자를 위해 활성화해야 하는 제안된 역할
• 가져온 파일에 소유자가 지정되지 않은 조직 구성 단위 및 역할에 대한 사용자 제어 권한을 부여하는 소유권 역할

모델 생성기가 역할 모델에서 이러한 역할을 만든 후에는 역할 모델을 XML 파일 형식으로 BHOLD 데이터베이스에 내보낼 수 있습니다.

BHOLD 고급 기능

이전 섹션에서는 BHOLD의 RBAC(역할 기반 액세스 제어) 기본 기능에 대해 설명했습니다. 이 섹션에서는 조직의 RBAC 구현에 향상된 보안과 유연성을 제공할 수 있는 BHOLD의 추가 기능을 설명합니다. 이 섹션은 BHOLD 기능에 대한 개요를 제공합니다.

• 카디널리티
• 직무 분리
• 상황에 따라 조정 가능한 사용 권한
• 특성 기반 권한 부여
• 유연한 특성 유형

카디널리티

카디널리티는 두 엔터티가 서로 관련될 수 있는 횟수를 제한하도록 설계된 비즈니스 규칙의 구현을 나타냅니다. BHOLD의 경우 역할, 사용 권한 및 사용자에 대해 카디널리티 규칙을 설정할 수 있습니다.

다음을 제한하도록 역할을 구성할 수 있습니다.

• 제안된 역할을 활성화할 수 있는 최대 사용자 수
• 역할에 연결할 수 있는 최대 하위 역할 수
• 역할에 연결할 수 있는 최대 사용 권한 수

다음을 제한하도록 사용 권한을 구성할 수 있습니다.

• 사용 권한에 연결할 수 있는 최대 역할 수
• 사용 권한을 부여할 수 있는 최대 사용자 수

다음을 제한하도록 사용자를 구성할 수 있습니다.

• 사용자에게 연결할 수 있는 최대 역할 수
• 역할 할당을 통해 사용자에게 할당할 수 있는 최대 사용 권한 수

직무 분리

SoD(직무 분리) 특정 사람에게 제공해서는 안되는 작업 수행 능력을 개인이 얻지 못하도록 하는 비즈니스 원리입니다. 예를 들어, 직원이 지불을 요청하고 지불을 승인할 수 있도록 하면 안됩니다. SoD 원리를 통해 조직은 직원의 실수나 위법 행위로 인한 위험 노출을 최소화하기 위해 견제와 균형 시스템을 구현할 수 있습니다.

BHOLD는 호환되지 않는 사용 권한을 정의할 수 있도록 SoD를 구현합니다. 이러한 사용 권한이 정의되면 BHOLD는 직접 또는 상속을 통해 연결되었든 관계없이, 호환되지 않는 사용 권한에 연결되는 역할의 생성을 방지하고, 마찬가지로 직접 또는 상속을 통해 연결되었든 관계없이, 사용자에게 호환되지 않는 사용 권한이 부여되는 여러 역할(결합되는 경우)이 할당되지 못하도록 하여 SoD를 적용합니다. 필요에 따라 충돌을 재정의할 수 있습니다.

상황에 따라 조정 가능한 사용 권한

개체 특성에 따라 자동으로 수정될 수 있는 사용 권한을 만들어 관리해야 하는 총 사용 권한 수를 줄일 수 있습니다. CAP(상황에 따라 조정 가능한 사용 권한)을 사용하면 사용 권한이 권한과 연결된 애플리케이션에 적용되는 방식을 수정하는 권한 특성으로 수식을 정의할 수 있습니다. 예를 들어 사용자가 정규직 또는 계약직 직원이 포함된 조직 구성 단위에 속하는지 여부에 따라 파일 폴더에 대한 액세스 권한(폴더의 액세스 제어 목록과 연결된 보안 그룹을 통해)을 변경하는 수식을 만들 수 있습니다. 한 조직 구성 단위에서 다른 조직 구성 단위로 사용자가 이동하면 새 사용 권한이 자동으로 적용되고 이전 권한은 비활성화됩니다.

CAP 수식으로 애플리케이션, 사용 권한, 조직 구성 단위 및 사용자에게 적용된 특성 값을 쿼리할 수 있습니다.

특성 기반 권한 부여

조직 구성 단위의 특정 사용자에 대해 조직 구성 단위에 연결된 역할을 활성화할지 여부를 제어하는 한 가지 방법은 ABA(특성 기반 권한 부여)를 사용하는 것입니다. ABA를 사용하면 사용자 특성을 기반으로 특정 규칙이 충족될 때만 역할을 자동으로 활성화할 수 있습니다. 예를 들어 사용자의 직위가 ABA 규칙의 직위와 일치하는 경우에만 사용자에 대해 활성화되는 조직 단위에 역할을 연결할 수 있습니다. 이렇게 하면 사용자에 대해 제안된 역할을 수동으로 활성화할 필요가 없습니다. 대신, 역할의 ABA 규칙을 충족시키는 특성 값을 가진 조직 구성 단위의 모든 사용자에 대해 역할을 활성화할 수 있습니다. 규칙은 결합할 수 있으므로 사용자 특성이 역할에 대해 지정된 모든 ABA 규칙을 충족시키는 경우에만 역할을 활성화할 수 있습니다.

카디널리티 설정에 따라 ABA 규칙 테스트의 결과가 제한된다는 점에 유의해야 합니다. 예를 들어 규칙의 카디널리티 설정에서 둘 이상의 사용자에게 역할을 할당할 수 없도록 지정하고 ABA 규칙이 네 명의 사용자에 대해 역할을 활성화하는 경우 ABA 테스트를 통과한 처음 두 사용자에 대해서만 역할이 활성화됩니다.

유연한 특성 유형

BHOLD에서 특성 시스템은 확장성이 뛰어납니다. 사용자, 조직 구성 단위 및 역할과 같은 개체에 대해 새 특성 유형을 정의할 수 있습니다. 특성은 정수, 부울(예/아니오), 영숫자, 날짜, 시간 및 이메일 주소 값을 포함하도록 정의할 수 있습니다. 특성은 단일 값 또는 값 목록으로 지정할 수 있습니다.

증명

BHOLD 제품군은 개별 사용자에게 비즈니스 작업을 수행하기 위한 적절한 권한이 부여되었는지 확인하는 데 사용할 수 있는 도구를 제공합니다. 관리자는 BHOLD 증명 모듈에서 제공하는 포털을 사용하여 증명 프로세스를 설계하고 관리할 수 있습니다.

증명 프로세스는 캠페인 관리자에게 BHOLD 관리 애플리케이션에 대한 적절한 액세스 권한과 해당 애플리케이션 내의 올바른 사용 권한이 있는지 확인하는 기회와 수단이 제공되는 캠페인을 통해 수행됩니다. 캠페인 소유자는 캠페인을 감독하고 캠페인이 제대로 수행되고 있는지 확인하기 위해 지정됩니다. 한 번 또는 반복적으로 발생하도록 캠페인을 만들 수 있습니다.

일반적으로 캠페인 관리자는 관리자가 담당하는 하나 이상의 조직 구성 단위에 속하는 사용자의 액세스 권한을 증명할 관리자가 됩니다. 관리자는 사용자 특성을 기반으로 캠페인에서 증명된 사용자에 대해 자동으로 선택될 수 있으며, 캠페인 관리자는 캠페인에서 증명되는 모든 사용자를 관리자(steward)에게 매핑하도록 파일에 나열하여 정의할 수 있습니다.

캠페인이 시작되면 BHOLD는 캠페인 관리자 및 소유자에게 이메일 알림 메시지를 보낸 후 캠페인에서 진행 상황을 유지 관리할 수 있도록 정기적인 알림을 보냅니다. 관리자는 캠페인 포털로 연결되어 여기에서 담당 사용자 목록과 해당 사용자에게 할당된 역할을 목록을 볼 수 있습니다. 그런 다음 관리자는 목록에 있는 각 사용자에 대한 책임이 있는지 여부를 확인하고 나열된 각 사용자의 액세스 권한을 승인 또는 거부할 수 있습니다.

또한 캠페인 소유자는 포털을 사용하여 캠페인 진행 상황을 모니터링하고 캠페인 활동을 기록하므로 캠페인 소유자는 캠페인 과정에서 취한 조치를 분석할 수 있습니다.

보고

BHOLD 보고 모듈을 사용하면 다양한 보고서를 통해 역할 모델의 정보를 볼 수 있습니다. BHOLD 보고 모듈은 기본 보고서와 고급 사용자 지정 보고서를 모두 만들 수 있는 마법사를 포함하며 광범위한 기본 제공 보고서 집합을 제공합니다. 보고서를 실행하면 결과를 즉시 표시하거나 결과를 Microsoft Excel(.xlsx) 파일에 저장할 수 있습니다. Microsoft Excel 2000, Microsoft Excel 2002 또는 Microsoft Excel 2003을 사용하여 이 파일을 보려면 Word, Excel 및 PowerPoint 파일 형식용 Microsoft Office 호환 기능 팩을 다운로드하고 설치할 수 있습니다.

대부분 BHOLD 보고 모듈을 사용하여 현재 역할 정보를 기반으로 보고서를 생성합니다. ID 정보의 변경을 감사하는 보고서를 생성하기 위해 Forefront Identity Manager 2010 R2에는 System Center Service Manager 데이터 웨어하우스에 구현된 FIM 서비스에 대한 보고 기능이 있습니다. FIM 보고에 대한 자세한 내용은 Forefront Identity Management 기술 라이브러리의 Forefront Identity Manager 2010 및 Forefront Identity Manager 2010 R2 설명서를 참조하세요.

기본 제공 보고서에서 다루는 범주는 다음과 같습니다.

• 관리
• 증명
• 컨트롤
• 내부 액세스 제어
• 로깅
• 모델
• 통계
• 워크플로

보고서를 만들고 이러한 범주에 추가하거나 사용자 지정 및 기본 제공 보고서를 배치할 수 있는 사용자 고유의 범주를 정의할 수 있습니다.

보고서를 작성하는 과정에서는 마법사가 다음 매개 변수를 제공하는 단계를 안내합니다.

• 이름, 설명, 범주, 사용법 및 대상 그룹을 포함한 식별 정보
• 보고서에 표시할 필드
• 분석할 항목을 지정하는 쿼리
• 행을 정렬할 순서
• 보고서를 섹션으로 구분하는 데 사용되는 필드
• 보고서에 반환된 요소를 구체화하는 필터

마법사의 각 단계에서 지금까지 정의한 대로 보고서를 미리 볼 수 있으며 추가 매개 변수를 지정할 필요가 없으면 보고서를 저장할 수 있습니다. 또한 이전 단계로 돌아가 마법사에서 이전에 지정한 매개 변수를 변경할 수도 있습니다.

액세스 관리 커넥터

BHOLD 제품군 액세스 관리 커넥터 모듈은 BHOLD에 대한 데이터의 초기 및 진행 중인 동기화를 모두 지원합니다. 액세스 관리 커넥터는 FIM 동기화 서비스와 함께 작동하여 BHOLD Core 데이터베이스, MIM 메타버스, 대상 애플리케이션 및 ID 저장소 간에 데이터를 이동합니다.

이전 버전의 BHOLD에는 MIM 및 중간 BHOLD 데이터베이스 테이블 간의 데이터 흐름을 제어하기 위해 여러 MA가 필요했습니다. BHOLD 제품군 SP1에서는 액세스 관리 커넥터를 통해 BHOLD와 MIM 간에 직접적인 데이터 전송을 제공하는 MIM의 MA(관리 에이전트)를 정의할 수 있습니다.

다음 단계

• BHOLD 설치 가이드
• BHOLD 개발자 참조
• BHOLD 버전 기록