 |
광범위한 권한 요구 사항의 경우 컨텍스트 독립 참여자를 사용하십시오. 이는 팀 크기를 적정 레벨로 유지하고 시스템 처리 리소스에 대한 영향을 줄입니다. 컨텍스트 간에 권한 요구 사항이 다양한 경우 컨텍스트 관련 참여자를 사용하십시오.
|
|
|
광범위한 권한 요구 사항의 경우 컨텍스트 독립 참여자를 사용하십시오. 이는 팀 크기를 적정 레벨로 유지하고 시스템 처리 리소스에 대한 영향을 줄입니다. 컨텍스트 간에 권한 요구 사항이 다양한 경우 컨텍스트 관련 참여자를 사용하십시오.
|
|
시스템 리소스 효율성
|
 |
|
가장 적합한 경우
|
특정 참여자 그룹에 대한 권한 요구 사항이 응용 프로그램 컨텍스트 간에 변경되지 않는 경우에 적합합니다.
|
|
사용 방법
|
참여자를 팀에 추가하지 않아야 합니다. 대신 액세스 제어 규칙을 통해 참여자에게 필요한 권한을 부여해야 합니다.
|
|
예제
|
예 1
전체 조직이 조직 내 모든 공개 제품에서 특정 유형의 데이터에 읽기 권한으로 액세스해야 합니다. 이 경우 조직의 모든 사용자를 모든 제품의 게스트 역할에 추가하는 것도 한 가지 옵션입니다. 이 방법은 처리 시간이 많이 소요됩니다. 대신 조직의 /Default/PDM 도메인과 같은 적합한 관리 도메인에서 특정 객체 유형에 대한 액세스 정책 규칙을 통해 읽기 권한이 사용자에게 제공될 수 있습니다.
예 2
특정 사용자 그룹은 모든 응용 프로그램 컨텍스트에서 규제 준수 검토 기능을 수행합니다. 모든 응용 프로그램 컨텍스트에서 규제 준수 검토 역할을 설정하고 해당 역할에 동일한 사용자를 추가하면 불필요한 부담이 가중됩니다. 대신 사이트의 /(루트) 도메인과 같은 적합한 관리 도메인에서 규제 준수 검토 사용자 정의 그룹에 대한 액세스 정책 규칙을 통해 필요한 권한이 사용자 그룹에 제공될 수 있습니다.
|
|
추가 고려 사항
|
사용자가 응용 프로그램 컨텍스트 팀의 멤버가 아닌 경우 응용 프로그램 컨텍스트가 사용자 인터페이스의 제품, 라이브러리, 프로그램 또는 프로젝트 목록 페이지에 나열되지 않습니다. 하지만 사용자는 응용 프로그램 컨텍스트를 검색할 수 있습니다. 사용자에게 적절한 권한이 있는 경우 응용 프로그램 컨텍스트가 검색됩니다. 액세스되면 응용 프로그램 컨텍스트가 탐색기에서 최근에 액세스한 목록에 로드되고 이후 사용을 위해 해당 위치에서 검색될 수 있습니다.
팀 멤버가 아닌 사용자에게 자동으로 표시되지 않는 작업에 액세스해야 하는 경우 팀의 역할에 대한 작업 구성 설정을 사용하여 이러한 작업을 팀 멤버가 아닌 사용자에게 표시하도록 설정할 수 있습니다. 컨텍스트 템플릿을 통해 해당 규칙을 새 컨텍스트에 자동으로 적용할 수 있습니다. 워크플로 참여와 같은 일부 기능은 팀 멤버가 아닌 사용자에 대해 다르게 설정해야 할 수도 있습니다.
그런 사용자가 응용 프로그램 컨텍스트 내에 있는 다양한 유형의 데이터를 탐색하는 데 필요한 액세스 정책 규칙은 사례별로 다를 수 있습니다. 이러한 권한을 식별하여 적절히 부여해야 합니다.
|
|
추가 정보
|
액세스 제어 규칙을 통한 데이터 액세스 관리를 참조하십시오.
|
|
시스템 리소스 효율성
|
 |
|
가장 적합한 경우
|
• 참여자가 컨텍스트에서의 해당 역할을 기반으로 응용 프로그램 컨텍스트에 있는 객체에 액세스할 수 있어야 합니다.
• 최소한의 변경이나 변경 없이 동일한 팀 구조를 다양한 유사 응용 프로그램 컨텍스트에 적용할 수 있습니다.
• 모든 응용 프로그램 컨텍스트에서 동일한 역할의 동일한 사용자 또는 그룹 기능이 있는 경우
• 추가적인 요구 사항을 충족하기 위해 로컬로 확장할 수 있습니다(아래의 추가 고려 사항 참조).
|
|
사용 방법
|
• 사용자에게 제공될 권한의 일반적인 특징으로 인해 라이브러리 팀에 공유 팀이 사용되는 경우가 있습니다.
• 또한 서로 다른 제품 및 프로젝트 세트를 처리하는 여러 공유 팀을 작성할 수 있습니다.
|
|
추가 고려 사항
|
공유 팀은 로컬로 확장되지 않은 경우에 가장 효율적입니다. 팀을 로컬로 확장하면 로컬 팀 인스턴스가 작성되며, 공유 팀에게 기대되는 성능 이점이 일부 줄어듭니다. 모든 로컬 팀에서 공유 팀을 수정하는 정도에 따라 공유 팀의 실질적인 이점이 전혀 실현되지 않을 수도 있습니다.
|
|
추가 정보
|
팀 멤버쉽을 통한 데이터 액세스 관리를 참조하십시오.
|
|
시스템 리소스 효율성
|
 |
|
가장 적합한 경우
|
• 참여자가 컨텍스트에서의 해당 역할을 기반으로 응용 프로그램 컨텍스트에 있는 객체에 액세스할 수 있어야 합니다.
• 팀 구조는 각 응용 프로그램 컨텍스트에만 한정됩니다.
• 팀 역할에서 작업을 수행하는 참여자는 각 응용 프로그램 컨텍스트와 관련이 있습니다.
|
|
사용 방법
|
• 책임을 기반으로 광범위한 사용자 그룹을 작성합니다.
• 그룹을 팀 내의 특정 역할에 추가합니다.
• 각 개별 컨텍스트에 고유한 사용자 그룹을 작성하지 마십시오. 재사용 가능한 사용자 그룹을 사용해 보십시오.
|
|
추가 고려 사항
|
로컬 팀에 포함해야 하는 참여자 수를 적절하게 유지하는 것이 좋습니다.
|
|
추가 정보
|
팀 멤버쉽을 통한 데이터 액세스 관리를 참조하십시오.
|
|
비효율적인 팀 설계 방법
|
단점
|
모범 사례
|
|
조직의 모든 사용자를 모든 팀의 게스트 역할(또는 다른 역할)에 추가하여 응용 프로그램 컨텍스트 데이터에 대한 읽기 권한을 부여합니다.
|
팀 구조가 클 경우 많은 시스템 리소스가 사용됩니다.
|
정책 규칙을 사용하여 기본 액세스 권한을 제공하십시오. 팀에 직접 연결해야 할 사용자 수를 적절하게 유지하십시오.
|
|
모든 팀에 대해 수백 가지 역할을 작성하여 권한을 매우 정교하게 제어합니다.
|
팀 구조가 클 경우 많은 시스템 리소스가 사용됩니다.
|
많은 특수 역할을 정의할 경우 성능 저하를 고려하십시오. 팀 내 역할 수를 적절하게 유지하십시오.
|
|
제품 또는 라이브러리 템플릿을 사용하여 모든 제품 또는 라이브러리에서 팀 역할에 대해 작성되어야 할 동일한 정책 액세스 제어 규칙을 지정하십시오.
|
모든 제품의 동일한 역할에 대해 동일한 정책 액세스 제어 규칙이 작성되어 불필요한 중복이 발생합니다.
|
가능하면 모든 응용 프로그램 컨텍스트에서 정책 액세스 제어 규칙을 중복하는 대신 조직 레벨에서 동적 역할에 대한 정책 액세스 제어 규칙을 작성하십시오. 자세한 내용은 액세스 제어 규칙에서 동적 역할 사용을 참조하십시오.
|
|
제품 내 역할 지정을 위해 임시로 고유한 사용자 그룹을 작성합니다. 그룹은 재사용되지 않고 단일 제품에 한정됩니다.
|
유사한 참여자 멤버쉽을 가진 많은 사용자 그룹이 생성될 수 있습니다. 이로 인해 사용자 그룹에 대한 유지 관리가 복잡해지고 LDAP에 오버로드됩니다.
|
컨텍스트별로 고유한 사용자 그룹을 작성하는 대신 재사용 가능한 사용자 그룹에서 사용자를 구성하십시오. 또는 사용자 그룹을 작성하여 역할에 연결하는 대신 사용자를 팀에 직접 연결하십시오. 두 번째 방법은 첫 번째 방법보다 비효율적입니다.
|