Microsoft BHOLD Suite 개념 가이드

MIM(Microsoft Identity Manager 2016)을 사용하면 조직에서 사용자 ID 및 관련 자격 증명의 전체 수명 주기를 관리할 수 있습니다. ID를 동기화하고, 인증서 및 암호를 중앙에서 관리하고, 다른 유형의 시스템에서 사용자를 프로비전하도록 구성할 수 있습니다. MIM을 사용하면 IT 조직에서 생성에서 사용 중지까지 ID를 관리하는 데 사용되는 프로세스를 정의하고 자동화할 수 있습니다.

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

이 가이드는 BHOLD Suite가 MIM에서 작동하는 방식을 이해하고 다음 항목을 다루는 데 도움이 됩니다.

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

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

역할 기반 액세스 제어

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

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

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

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

RBAC의 추가 이점은 SoD(의무 분리)를 정의하고 적용하는 기능입니다. 이렇게 하면 조직에서 동일한 사용자가 보유하지 않아야 하는 권한을 부여하는 역할 조합을 정의할 수 있으므로 사용자가 지불을 시작하고 결제 권한을 부여할 수 있는 역할을 특정 사용자에게 할당할 수 없습니다. RBAC는 사용자 단위로 정책의 효과적인 구현을 평가하지 않고도 이러한 정책을 자동으로 적용할 수 있는 기능을 제공합니다.

BHOLD 역할 모델 개체

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

• 조직 구성 단위
• 사용자
• 역할
• 권한
• 응용 프로그램

조직 구성 단위

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

필수는 아니지만 대부분의 경우 조직 단위는 아래와 유사하게 실제 조직의 계층 구조를 나타내기 위해 BHOLD로 구성됩니다.

이 샘플에서 역할 모델은 기업 전체를 대표하는 조직 단위(대통령은 특정 조직 단위에 속하지 않으므로 대통령이 이를 대표합니다) 또는 그 목적을 위해 항상 존재하는 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에서 개별 사용자에게 역할을 할당하는 방법을 보여 줍니다.

역할 할당role assignment

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

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

권한

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

사용 권한은 애플리케이션에 따라 다릅니다. BHOLD는 역할 관리자가 사용 권한의 구현 세부 정보를 이해할 필요 없이 역할과 사용 권한을 연결할 수 있도록 권한에 대한 단일 통합 보기를 제공합니다. 실제로 다른 시스템에서 사용 권한을 다르게 적용할 수 있습니다. FIM 동기화 서비스에서 애플리케이션으로의 애플리케이션별 커넥터는 사용자에 대한 권한 변경 내용을 해당 애플리케이션에 제공하는 방법을 결정합니다.

응용 프로그램

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

BHOLD Suite 역할 모델 개발

역할 모델을 개발하는 데 도움을 주기 위해 BHOLD Suite는 사용하기 쉽고 포괄적인 도구인 모델 생성기를 제공합니다.

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

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 규칙이 4명의 사용자에 대한 역할을 활성화하는 경우 ABA 테스트를 통과한 처음 두 사용자에 대해서만 역할이 활성화됩니다.

유연한 특성 유형

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

증명

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

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

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

캠페인이 시작되면 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 Suite Access Management Connector 모듈은 데이터의 초기 동기화와 지속적인 BHOLD 동기화를 모두 지원합니다. 액세스 관리 커넥터는 FIM 동기화 서비스와 함께 작동하여 BHOLD Core 데이터베이스, MIM 메타버스 및 대상 애플리케이션 및 ID 저장소 간에 데이터를 이동합니다.

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

다음 단계

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