다른 Cognos 보안 소스로 전환

다른 외부 보안 소스(예: Active Directory, LDAP 등)를 사용하도록 기존 Cognos 환경을 재구성해야 하는 경우 취할 수 있는 몇 가지 접근 방식이 있습니다. 저는 그들을 “좋은 것, 나쁜 것, 못생긴 것”이라고 부르고 싶습니다. 이러한 Good, Bad 및 Ugly 접근 방식을 살펴보기 전에 Cognos 환경에서 인증 네임스페이스 변경을 유도하는 경향이 있는 몇 가지 일반적인 시나리오를 살펴보겠습니다.

일반적인 비즈니스 동인:

하드웨어 또는 OS 업데이트 – BI 하드웨어/인프라 현대화는 빈번한 동인이 될 수 있습니다. 나머지 Cognos는 세련된 새 하드웨어와 최신 64비트 OS에서 챔피언처럼 실행될 수 있지만 행운을 빕니다. 2005년경 버전의 Access Manager를 새 플랫폼으로 마이그레이션하십시오. Access Manager(Series 7과 함께 처음 출시됨)는 많은 Cognos 고객이 과거에 사용했던 유서 깊은 제품입니다. 많은 고객들이 Windows Server 2003의 구식 버전을 계속 사용하는 유일한 이유입니다. Access Manager의 글은 꽤 오랫동안 벽에 붙어 있었습니다. 레거시 소프트웨어입니다. 그것에서 벗어날 수 있는 것은 빠를수록 좋습니다.

애플리케이션 표준화– 중앙에서 관리되는 하나의 기업 디렉토리 서버(예: LDAP, AD)에 대해 모든 애플리케이션의 인증을 통합하려는 조직.

합병 및 인수– 회사 A는 회사 B를 구입하고 회사 B의 Cognos 환경이 기존 BI 컨텐츠 또는 구성에 문제를 일으키지 않고 회사 A의 디렉토리 서버를 가리키도록 해야 합니다.

기업 매각– 이것은 합병 시나리오의 반대입니다. 회사의 일부가 자체 엔터티로 분사되어 이제 새 보안 소스에서 기존 BI 환경을 가리켜야 합니다.

네임스페이스 마이그레이션이 번거로운 이유

Cognos 환경에서 새 보안 소스를 지정하는 것은 동일한 사용자, 그룹 및 역할을 가진 새 네임스페이스를 추가하고 이전 네임스페이스의 연결을 끊고 VOILA!- 새 네임스페이스의 모든 Cognos 사용자가 다음과 일치하는 것처럼 간단하지 않습니다. 그들의 콘텐츠. 사실, 당신은 종종 손에 피 묻은 엉망으로 끝날 수 있습니다. 그리고 여기에 그 이유가 있습니다...

모든 Cognos 보안 주체(사용자, 그룹, 역할)는 CAMID라는 고유 식별자로 참조됩니다. 다른 모든 속성이 동일하더라도 사용자의 CAMID는 현존하는 인증 네임스페이스는 해당 사용자의 CAMID와 동일하지 않습니다.   네임스페이스. 이는 기존 Cognos 환경에 큰 피해를 줄 수 있습니다. Cognos 사용자가 몇 명뿐인 경우에도 CAMID 참조가 Content Store의 여러 다른 위치에 존재한다는 사실을 알아야 합니다(또한 Framework 모델, Transformer 모델, TM1 응용 프로그램, 큐브, 계획 응용 프로그램 등의 Content Store 외부에 존재할 수도 있습니다. ).

많은 Cognos 고객은 CAMID가 내 폴더 컨텐츠, 사용자 기본 설정 등에 대해서만 중요하다고 잘못 생각합니다. 이것은 사실과 다를 수 없습니다. 보유하고 있는 사용자 수의 문제가 아니라 관심을 가져야 하는 Cognos 오브젝트의 수입니다. Content Store에만 140개 이상의 서로 다른 유형의 Cognos 개체가 있으며 그 중 많은 개체에 여러 CAMID 참조가 있을 수 있습니다..

예 :

1. Content Store의 단일 일정에 여러 CAMID 참조가 있는 것은 드문 일이 아닙니다(일정 소유자의 CAMID, 일정을 실행해야 하는 사용자의 CAMID, 생성된 보고서 출력을 이메일로 보내야 하는 각 사용자 또는 배포 목록의 CAMID , 등.).
2. Cognos의 모든 개체에는 개체에 액세스할 수 있는 사용자를 제어하는 ​​보안 정책이 있습니다("권한 탭" 참조). Cognos Connection의 해당 폴더에 있는 단일 보안 정책에는 해당 정책에 지정된 각 사용자, 그룹 및 역할에 대한 CAMID 참조가 있습니다.
3. 요점을 이해하기를 바랍니다. 이 목록은 계속해서 진행됩니다!

상당한 규모의 Content Store가 수만 개의 CAMID 참조를 포함하는 것은 드문 일이 아닙니다.

이제 무엇이 들어 있는지 계산해 보세요. your Cognos 환경에서 잠재적으로 많은 CAMID 참조를 처리하고 있음을 알 수 있습니다. 악몽이 될 수 있습니다! 인증 네임스페이스를 전환(또는 재구성)하면 이러한 모든 CAMID 참조가 확인할 수 없는 상태로 남을 수 있습니다. 이는 필연적으로 Cognos 컨텐츠 및 구성 문제(예: 더 이상 실행되지 않는 일정, 생각하는 방식으로 더 이상 보안되지 않는 컨텐츠, 데이터 수준 보안을 더 이상 올바르게 구현하지 않는 패키지 또는 큐브, 내 폴더 컨텐츠 및 사용자 손실)로 이어집니다. 선호도 등).

Cognos 네임스페이스 전환 방법

이제 Cognos 환경에 새 인증 네임스페이스에서 해당하는 새 CAMID 값을 찾고 매핑하고 업데이트해야 하는 수만 개의 CAMID 참조가 있을 수 있다는 사실을 알고 있으므로 이 문제를 해결하기 위한 Good, Bad 및 Ugly 접근 방식에 대해 논의해 보겠습니다.

좋은: 페르소나로 네임스페이스 대체

첫 번째 방법(네임스페이스 교체)은 다음을 활용합니다. Motio' 페르소나 IQ 제품. 이 접근 방식을 사용하면 기존 네임스페이스가 Cognos에 노출된 모든 보안 주체를 가상화할 수 있는 특수 Persona 네임스페이스로 "대체"됩니다. 기존 보안 주체는 여러 외부 보안 소스(예: Active Directory, LDAP 또는 Persona 데이터베이스)의 지원을 받을 수 있지만 이전과 정확히 동일한 CAMID를 사용하여 Cognos에 노출됩니다.

이 접근 방식의 아름다운 부분은 Cognos 컨텐츠에 대한 변경이 전혀 필요하지 않다는 것입니다. 이는 Persona가 새로운 소스의 지원을 받는 경우에도 기존 보안 주체의 CAMID를 유지할 수 있기 때문입니다. 그래서… Content Store, 외부 모델 및 기록 큐브에 있는 수만 개의 CAMID 참조가 모두 무엇입니까? 그들은 그대로 있을 수 있습니다. 작업이 필요하지 않습니다.

이것은 하나의 외부 보안 소스에서 다른 외부 보안 소스로 기존 Cognos 환경을 전환하는 데 사용할 수 있는 가장 위험하고 영향이 가장 적은 접근 방식입니다. Cognos 가동 중지 시간이 약 5분이면 XNUMX시간 이내에 완료할 수 있습니다(Cognos 가동 중지 시간은 Persona 네임스페이스를 구성한 후 Cognos를 다시 시작하는 것뿐입니다).

나쁜: 페르소나를 이용한 네임스페이스 마이그레이션

쉽고 위험도가 낮은 접근 방식이 차 한 잔이 아니라면 is 다른 옵션.

페르소나는 네임스페이스 마이그레이션을 수행하는 데에도 사용할 수 있습니다.

여기에는 Cognos 환경에 두 번째 인증 네임스페이스를 설치하고, 기존의 모든 보안 주체(이전 네임스페이스에서)를 새 네임스페이스의 해당 주체에 매핑하고(여기에 재미있는 부분이 있음), 모든 보안 주체를 찾고 매핑하고 업데이트하는 작업이 포함됩니다. Cognos 환경에 존재하는 단일 CAMID 참조: Content Store, 프레임워크 모델, 변환기 모델, 기록 큐브, TM1 응용 프로그램, 계획 응용 프로그램 등

이 접근 방식은 스트레스가 많고 프로세스 집약적인 경향이 있지만 살아 있음을 느끼기 위해 약간의 아드레날린이 분출해야 하는 Cognos 관리자(심야/이른 아침 전화 통화는 신경 쓰지 않음)라면 아마도… 이 당신이 찾고있는 옵션입니까?

페르소나는 이 프로세스의 일부를 자동화하는 데 사용할 수 있습니다. 이전 보안 주체와 새 보안 주체 간의 매핑을 만들고 콘텐츠 저장소의 콘텐츠에 대한 무차별 대입 "찾기, 분석, 업데이트" 논리 등을 자동화하는 데 도움이 됩니다. Persona가 여기에서 일부 작업을 자동화할 수 있는 것 이 접근 방식의 작업에는 실제 기술이 아닌 "사람과 프로세스"가 포함됩니다.

예를 들어 모든 Framework Manager 모델, 모든 Transformer 모델, 모든 Planning/TM1 응용 프로그램, 모든 SDK 응용 프로그램, 해당 응용 프로그램의 소유자, 업데이트 및 재배포 방법에 대한 정보를 컴파일하는 것은 많은 작업이 될 수 있습니다. 이를 시도하려는 각 Cognos 환경과 마이그레이션을 시도할 수 있는 유지 관리 기간에 대한 조정 중단에는 계획 및 Cognos "다운 타임"이 포함될 수 있습니다. 마이그레이션 이후에 효과적인 테스트 계획을 수립(및 실행)하는 것 또한 상당한 부담이 될 수 있습니다.

또한 비프로덕션 환경에서 이 프로세스를 먼저 수행하려는 것이 정상입니다. 전에 생산에서 그것을 시도합니다.

페르소나를 사용한 네임스페이스 마이그레이션은 효과가 있지만(아래의 "추한" 접근 방식보다 훨씬 우수함) 네임스페이스 교체보다 더 침습적이고 위험하며 훨씬 더 많은 인력이 필요하며 수행하는 데 훨씬 더 많은 인력이 소요됩니다. 일반적으로 마이그레이션은 Cognos 환경이 여전히 온라인 상태이지만 최종 사용자가 사용하는 형식이 제한된 "오프 시간"에 수행해야 합니다.

미운: 수동 네임스페이스 마이그레이션 서비스

추한 방법은 수동으로 한 인증 네임스페이스에서 다른 인증 네임스페이스로 마이그레이션합니다. 여기에는 두 번째 인증 네임스페이스를 Cognos 환경에 연결한 다음 기존 Cognos 컨텐츠 및 구성의 대부분을 수동으로 이동하거나 다시 작성하는 작업이 포함됩니다.

예를 들어, 이 접근 방식을 사용하여 Cognos 관리자는 다음을 시도할 수 있습니다.

1. 새 네임스페이스에서 그룹 및 역할 재생성
2. 새 네임스페이스에서 해당 그룹 및 역할의 구성원을 다시 만듭니다.
3. 내 폴더 콘텐츠, 사용자 기본 설정, 포털 탭 등을 각 소스 계정에서 각 대상 계정으로 수동으로 복사
4. Content Store에서 모든 정책 세트를 찾아 업데이트하여 이전 네임스페이스의 보안 주체를 참조하는 것과 똑같은 방식으로 새 네임스페이스의 동등한 보안 주체를 참조하도록 업데이트합니다.
5. 모든 일정을 다시 만들고 해당 자격 증명, 받는 사람 등으로 채우십시오.
6. Content Store에 있는 모든 개체의 모든 "소유자" 및 "연락처" 속성 재설정
7. [컨텐츠 스토어에서 당신이 잊어버릴 40가지 다른 것들]
8. 개체 또는 데이터 수준 보안을 사용하여 모든 FM 모델을 수집합니다.
   1. 그에 따라 각 모델 업데이트
   2. 각 모델 다시 게시
   3. 수정된 모델을 원래 작성자에게 다시 배포
9. 원래 네임스페이스에 대해 보호되는 Transformer 모델, TM1 애플리케이션 및 계획 애플리케이션에 대한 유사한 작업
10. [그리고 더 많은]

일부 Cognos masochists는 Cognos Connection에서 400,000번을 클릭한다는 아이디어에 비밀리에 기쁨으로 킥킥거릴 수 있지만 대부분의 현명한 사람들에게 이 접근 방식은 매우 지루하고 시간이 많이 걸리며 오류가 발생하기 쉬운 경향이 있습니다. 그러나 이것이 이 접근 방식의 가장 큰 문제는 아닙니다.

이 접근 방식의 가장 큰 문제는 거의 항상 불완전한 마이그레이션으로 이어집니다.

이 접근 방식을 사용하면 (고통스럽게) 자신이 알고 있는 CAMID 참조를 찾고 매핑하려고 시도하지만… 모른다.

일단 생각 이 접근 방식을 사용하면 완료되지 않은 경우가 많습니다. 정말 끝난.

콘텐츠 저장소에 더 이상 생각하는 방식으로 보안되지 않는 개체가 있습니다... 예전처럼 실행되지 않는 일정이 있고 생각하는 방식으로 더 이상 보안되지 않는 데이터가 있습니다. 그렇습니다. 특정 작업에 대해 설명할 수 없는 오류가 있을 수도 있습니다. 당신은 정말로 당신의 손가락을 넣을 수 없습니다.

나쁘고 추악한 접근이 두려운 이유:

• 자동화된 네임스페이스 마이그레이션은 콘텐츠 관리자에게 많은 부담을 줍니다. Content Store의 모든 단일 개체에 대한 검사 및 잠재적 업데이트로 인해 Cognos에 대한 수만 개의 SDK 호출이 발생할 수 있습니다(사실상 모두 Content Manager를 통해 흐릅니다). 이 비정상적인 쿼리는 일반적으로 메모리 사용량/로드를 급증시키고 콘텐츠 관리자를 마이그레이션 중에 충돌할 위험에 빠뜨립니다. Cognos 환경에 이미 어느 정도의 불안정성이 있는 경우 이 접근 방식을 매우 두려워해야 합니다.
• 네임스페이스 마이그레이션에는 상당한 유지 관리 기간이 필요합니다. Cognos가 실행되어야 하지만 마이그레이션 프로세스 중에 사람들이 변경하는 것을 원하지 않습니다. 이것은 일반적으로 아무도 작업하지 않을 때 네임스페이스 마이그레이션을 시작해야 합니다(예: 금요일 밤 10시). 아무도 금요일 밤 10시에 스트레스가 많은 프로젝트를 시작하고 싶어하지 않습니다. 말할 것도 없이, 당신의 정신 능력은 아마도 다음과 같은 프로젝트에서 밤과 주말에 최선을 다하지 못할 것입니다. 하지 예리해야합니다!
• 나는 네임스페이스 마이그레이션이 시간과 노동 집약적이라고 언급했습니다. 이에 대해 조금 더 설명하면 다음과 같습니다.
  • 콘텐츠 매핑 프로세스는 정밀하게 수행되어야 하며 팀 협업과 많은 인력이 필요합니다.
  • 마이그레이션과 관련된 오류나 문제를 확인하려면 여러 번의 테스트 실행이 필요합니다. 일반적인 마이그레이션은 첫 번째 시도에서 완벽하게 진행되지 않습니다. 이러한 경우 복원할 수 있는 Content Store의 유효한 백업도 필요합니다. 우리는 사용 가능한 좋은 백업이 없거나 불완전하다는 것을 깨닫지 못하는 백업이 있는 많은 조직을 보아왔습니다.
  • 당신은 모든 것을 식별해야합니다 외부 잠재적으로 영향을 받을 수 있는 Content Store(프레임워크 모델, 변환기 모델 등). 이 작업에는 여러 팀 간의 조정이 포함될 수 있습니다(특히 대규모 공유 BI 환경에서).
  • Cognos 컨텐츠에 대한 다양한 액세스 수준을 가진 대표자를 포함하는 우수한 테스트 계획이 필요합니다. 여기서 핵심은 마이그레이션이 완료된 직후 모든 것이 완전히 마이그레이션되고 예상대로 작동하는지 확인하는 것입니다. 일반적으로 모든 것을 확인하는 것은 비현실적이므로 대표 샘플로 원하는 것을 확인하게 됩니다.
• 당신은 b가 있어야합니다road Cognos 환경과 이에 의존하는 사물에 대한 지식. 예를 들어, 사용자 정의 보기가 있는 기록 큐브는 NSM 경로로 이동하는 경우 다시 작성해야 합니다.
• 당신이나 당신이 네임스페이스 마이그레이션을 아웃소싱한 회사가...SDK 애플리케이션과 같은 것을 잊어버린다면 어떻게 될까요? 스위치를 전환한 후에는 제대로 업데이트되지 않으면 작동이 중지됩니다. 이를 즉시 알아차릴 수 있도록 적절한 점검을 하고 있습니까? 아니면 증상이 나타나기 시작하기 몇 주 또는 몇 달이 걸릴 것입니까?
• Cognos 업그레이드를 여러 번 수행한 경우 Content Store에 일관성 없는 상태의 개체가 있을 수 있습니다. SDK로 작업하지 않으면 이 상태에 있는 개체를 볼 수 없습니다.

네임스페이스 교체가 최선의 선택인 이유

페르소나 네임스페이스 교체 방법을 사용하면 방금 설명한 주요 위험 요소와 시간 소모적인 단계가 제거됩니다. 네임스페이스 교체 접근 방식을 사용하면 Cognos 가동 중지 시간이 5분이며 콘텐츠를 변경할 필요가 없습니다. "좋은" 방법은 나에게 컷 앤 드라이 "뇌가 없는" 것처럼 보입니다. 금요일 밤은 네임스페이스 마이그레이션 도중에 콘텐츠 관리자가 충돌했다는 사실에 스트레스를 받지 않고 휴식을 취하기 위한 것입니다.