Analysis Services 의 보안 관리 권오주 대표시삽 www.olapforum.com

1. Analysis Services의 보안 관리 권오주 대표시삽 www.olapforum.com

2. Agenda • 연결과 역할 개요 • 보안 정의 • 차원 보안 • 셀 보안 • 보안 모델 선택 • 동적 보안 • 인증과 미들-티어 전략 • 클라이언트 보안

3. AS 연결 - Direct 클라이언트 App PivotTable Service Analysis Server MOLAP Data SQL Server ROLAP Data

4. AS 연결 - Indirect 클라이언트 App PivotTable Service IIS Msolap.asp Msmdpump.dll Analysis Server MOLAP Data SQL Server ROLAP Data

5. 최종 사용자 보안 수준 - 개요

6. OLAP Administrators - 개요 • 로컬 머신의 OLAP Administrators 그룹 구성원 • OLAP 오브젝트의 생성/수정/처리/삭제 • 다른 역할의 사용 권한 및 멤버쉽 관리 • AS 설치자는 자동으로 OLAP Administrators 그룹의 구성원 • OLAP Administrators만이 분석 관리자 사용 • OLAP Administrators는 모든 큐브와 마이닝모델의 내용 쿼리 가능 • 단순한 관리 모델 • 많은 고객들은 보다 상세하고 세련된 관리 모델 요구

7. 역할 - 개요 • 데이터베이스, 큐브, 데이터마이닝 모델 등에 대한 접근권한을 설정하는 오브젝트 • 사용자 계정과 그룹의 그룹화 • OLAP과 마이닝모델에 대한 사용 권한 할당 • 데이터베이스 역할 • 사용자 계정과 그룹들의 리스트 • 큐브 역할 • 데이터베이스 역할을 큐브에 할당하여 큐브 역할 생성 • 큐브에 대한 상세 사용권한 포함 • 셀 사용권한, 드릴스루,… • 마이닝모델 역할 • 데이터베이스 역할을 마이닝모델에 할당하여 마이닝모델 역할 생성

8. 셀-수준 보안 Employees Total salary Sq Ft East 50 N/A 16,500 차원 구성원 보안 Central 75 $7,600K 20,625 Employees Sq Ft West 35 N/A 10,500 East 50 16,500 Central 75 20,625 West 35 10,500 보안 정의 • 보안을 정의하는 두 가지 방식: • 셀 수준 • 차원 구성원 수준

9. 셀 보안 • 차원 구성원을 볼 수 있지만 구성원에 대한 데이터는 제한 될 때 셀 보안 사용 • 판매 관리자는 일부 제품들에 대한 손익을 볼 수 있지만 다른 제품들에 대해서는 총판매액만 볼 수 있다. • $1000.00미만의 손익은 볼 수 없고, 이상은 볼 수 있다. • 셀 보안은 참, 거짓을 판단하는 MDX 표현식으로 정의 • 표현식이 참이면 볼 수 있고 거짓이면 볼 수 없다.

10. 셀 보안 예 • (사생활 침해를 막기 위해) 개인 고객들을 제외한 고객 차원의 모든 구성원들에 대한 손익을 볼 수 있다 NOT( IsLeaf(Customers.CurrentMember) AND Measures.CurrentMemberIS [Measures].[Profit] )

11. 셀 보안 유형들 • 세가지 다른 유형의 셀 사용권한 • 읽기: 표현식으로부터 결정되는 대상 셀에 접근 • 불확정 읽기: 대상 셀의 수식 정의에 사용된 셀에 접근 가능해야 함 • 읽기/쓰기 “읽기” 셀 사용권한 해석 : TRUE “불확정읽기” 셀 사용권한 해석 : TRUE

12. 셀 보안 : 기타 고려사항 • 셀 보안은 클라이언트 단에서 해석 • 강제 실행 설정 : 클라이언트 • MDX를 이용한 셀 보안 관리 – MDX 지식 필요 • 연결 문자열의 Secured Cell Value 속성 – 보안이 설정된 셀의 표시 변경 가능 • #N/A, ERR, NULL, 0, #SEC • 주의 : Default Isolation Mode(isolation)

13. 차원 보안 : 용어 • 차원 보안은 사용자가 볼 수 있도록 허용한 차원 구성원들(집합)을 정의 • UI를 이용한 간단한 표현 • MDX를 이용한 복잡한 표현 • 허용된 집합: 역할이 볼 수 있는 구성원들 리스트 • 보는 것이 허용된 각 구성원의 조상과 자손 구성원들 • 새로운 구성원을 볼 수 없다 • 거부된 집합: 역할이 보는 것이 허용되지 않은 구성원들 리스트 • 보는 것이 거부된 구성원과 그 자손 구성원들 • 새로운 구성원을 볼 수 있다 • 최하위 수준: 역할이 볼 수 있는 최하위 수준 정의 • 최상위 수준: 역할이 볼 수 있는 최상위 수준 정의

14. 새로운 구성원들 TopLevel BottomLevel 허용된 집합 사용하기

15. TopLevel BottomLevel 거부된 집합 사용하기 새로운 구성원들

16. 보이는 값 합계 • 보이는 값 합계 – 집계값들을 보이는 구성원들에 근거할지 또는 모든 구성원들에 근거할지 제어 • 역할이 캐나다와 멕시코를 제외하고 미국만 볼 수 있다면 전체 고객에 대하여 무슨 값을 보여줄 것인가? • 보이는 값 합계를 설정하면 오직 보이는 구성원들만이 합계에 반영 • 모든 구성원들이 합계에 포함되면 보이는 값 합계는 해제 • 보이는 값 합계의 적용 시작 수준을 정의 가능

17. 차원 보안 예 • 미국 내의 주, 도시, 고객 수준의 구성원들로 접근 제한

18. 역할 관리 • 차원 보안 상속 • 하나 이상의 역할에서의 동시 멤버쉽

19. 차원 보안 상속 • 데이터베이스 역할에서의 기본적인 차원 사용권한 • 데이터베이스 역할을 큐브에 할당할 때 차원 사용권한 상속 • 데이터베이스 수준에서의 차원 사용권한에 대한 수정은 해당 차원을 포함하는 큐브에 상속 • 차원 사용권한은 큐브 수준에서 Override 가능 • 서버 데이터베이스 역할 -> 큐브 역할 상속

20. 역할 결합 • 역할은 데이터에 대한 접근을 부여 • 사용자가 임의의 역할에서 차원 구성원들이나 데이터를 볼 수 있는 사용권한이 있다면 다른 역할에서의 멤버쉽에 상관없이 해당 구성원들이나 데이터를 볼 수 있다 • 세션 동안 적용하기를 원하는 역할을 설정할 수 있다 • 연결 문자열의 Roles 속성 • 사용자가 속해 있는 역할 중에서 선택 역할1 역할2 역할1, 2의 결합

21. 동적 차원 보안 • 가끔 보안을 개인 사용자 수준까지 적용 요구 • 데이터 기반 • 또는 완전한 임의 요구 • 예: • 각 프로젝트 관리자는 자신과 부하 직원들의 프로젝트만을 볼 수 있다 • 각 판매 담당자는 오직 그들의 제품만을 볼 수 있다 • 각 사용자는 판매 지역에서 관리자가 지정한 임의의 부분만 볼 수 있다 • 보안 역할의 관리를 최소화 • 데이터 기반으로 역할 관리 • 사용자별 역할 생성 회피

22. 동적 보안 MDX (1)

23. 동적 보안 MDX (1)

24. 동적 보안 MDX (1) • 판매 큐브의 상점들을, UserName이 해당 상점의 구성원 속성에 포함되는 상점들로 제한 • 하나의 구성원 속성값 256자 제한 • 허용된 집합 표현: Filter( [Store].[Store Name].Members, InStr( [Store].CurrentMember.Properties("User"), UserName ) > 0 )

25. 동적 보안 MDX (2)

26. 동적 보안 MDX (2) • 보안 정보를 포함하는 하나의 원본 큐브를 기반으로 하는 가상 큐브 생성 • 허용된 집합 표현: Filter( [Customers].[NAME].Members, ( StrToTuple( MID( UserName, InStr(1, UserName, "\") + 1, 128 ) ), [SFAccess] ) = 1 )

27. 차원 보안 : 주의 사항 • (동적 보안을 사용하지 않으면) 각각의 고유한 역할 조합에 대하여 복제 차원 생성 • 차원 전체의 복제가 아님 – 허용된 구성원들의 형제 구성원들과 조상 구성원들 • 차원 보안은 서버에서 해석 • 결과: UDF와 MDX 함수 LookUpCube를 이용하지 못함 • 가능하면 데이터베이스 역할 관리자에서 작업 • 오류 처리

28. 셀과 차원 보안 - 요약 • 차원 보안 사용 • 사용자가 어떠한 차원 구성원들에 대하여 모든 데이터를 볼 수 없을 때 • 셀 보안 사용 • 사용자가 특정 차원 구성원들에 대하여 일부 데이터를 볼 수 없을 때 • 예를 들어, 사용자 A는 매출액은 캐나다와 미국에 대하여, 손익은 미국에 대한 것만 볼 수 있다 • 동적 보안 사용 • 보안을 개인 사용자별로 적용할 때

29. 파일 보안 • 별도의 보안 관리 필요 • Msmdrep.mdb • Msmdqlog.mdb

30. 인증 개요 • 두 가지 인증 체계 지원 • 통합 인증 • IIS의 HTTP 인증 • 통합 • 사용자는 도메인 또는 트러스트된 도메인의 인증 받은 계정 필요 • 사용자가 트러스트된 도메인에 속해 있지 않으면, 익명 또는 두 도메인의 일치하는 UserID/Password로 연결 (NTLM) • HTTP • 모든 IIS 인증 메커니즘 지원: anonymous, basic, integrated, SSL, certificates,… • Anonymous는 클라이언트 인증 수행 없음 (IUSR_SrvName) • 전사적 기능

31. AS와 TCP Ports • 방화벽 사용시, 클라이언트를 인트라넷, 익스트라넷 또는 인터넷을 통해 배포할 때 서버와 클라이언트에서 모두 사용하는 TCP 포트를 고려 • OLAP Services • TCP Port 2393, 2394 예약, 미사용 • Analysis Services • TCP Port 2725 사용 • 7.0 클라이언트와 연결시 2393, 2394 사용 • HTTP 연결시 • 웹사이트의 기본포트 (대부분 80) • SSL 사용시 443

32. 인증 메커니즘 선택 • 통합 인증 사용 • 사용자와 서버가 동일 도메인에 속할 때 • 사용자가 서버가 위치한 도메인에 의해 트러스트된 도메인에 속할 때 • HTTP/IIS 인증 사용 • 서버가 트러스트되지 않은 도메인 또는 방화벽 외부로부터 연결을 허용할 때 • HTTPS 사용 • 스푸핑, 데이터 조작, 정보 노출을 방지하고자 할 때

33. Middle Tier Scenarios HTTP Connectivity Scenarios Integrated Internet Firewall Web Server Analysis Server

34. HTTP Connectivity DMZ HTTP Connectivity 옵션 (sp3) Internet Firewall DMZ Web Server Analysis Server Firewall msmdpump.dll pump.ServerName = "서버명” pump.Timeout = 60...

35. DMZ HTTP Basic Authentication: Pros & Cons • Pros • 단순함 • 코딩없이 클라이언트와 연결 가능: OWC, Excel, ProClarity, 등등… • Analysis Services를 인터넷에 노출시키지 않음 • Cons • 모든 사용자에 대한 머신 계정 생성 • 기타 비고 • 사용자 이름과 비밀번호를 보호하기 위해 SSL 사용 • 오직 Basic Authentication 만

36. 미들티어 시나리오 1:Basic Authentication • 시나리오 • 인터넷 • 적은 수의 안정적 또는 느리게 변동되는 사용자 기반 • 단계 • Analysis Services/IIS가 위치하는 곳의 사용자용 머신 계정 생성 • 사용자는 기본 인증을 이용하여 연결 Analysis Services Browser IIS ASP.net, ASP Connection Dialog UserName: Password: KOJ uhahaha

37. HTTP Basic Authentication: Pros & Cons • Pros • 단순. 가장 널리 사용되는 사용자 인증 체계 (HTTP SPEC 1.0에 포함) • 프록시 서버를 통한 인증 가능 • One-hop 위임. • Cons • 모든 사용자에 대한 머신 계정 생성 • 기타 비고 • 사용자 이름과 비밀번호를 보호하기 위해 SSL 사용

38. 미들티어 시나리오 2:Kerberos • 시나리오 • 거대한, 기업 인트라넷 • 진정한 싱글-사인온을 위해 도메인 관리자들에 대한 완전한 신뢰 • 단계 • IIS에 의한 사용자 인증 • Kerberos를 사용하는 통합 인증 • IIS는 Kerberos 인증을 사용하여 연결된 사용자를 impersonation Remote Server 연결 문자열: Provider=msolap;SSPI=Kerberos 사용자를 인증 Analysis Services Browser IIS ASP.net, ASP Analysis Services 연결에 사용되는 원래의 사용자 증명서(Credentials)

39. Kerberos : Pros & Cons • Pros • 진정한 통합 보안을 사용하는 자격 증명(Credential) 위임 • Cons • 클라이언트와 서버 모두 Windows 2000 이상 환경 • 보안 관리를 위해 Active directory 필요 • 도메인 관리자가 위임을 위해 머신의 연쇄적인 트러스트 설정 요구(Trusted for delegation) – 사용자가 네트워크 서비스를 사용할 수 있도록 Impersonation • 컴퓨터, 서비스 계정, 사용자 계정의 위임 활성화 필요

40. Kerberos와 AS 서비스 계정 • Kerberos 인증, 위임, 상호 인증이 작동하도록 하기 위해, MSSQLServerOLAPService 서비스는 다음 유형의 계정 중 하나로 기동해야 한다 • 로컬 시스템 계정 • Active Directory 도메인에서 관리 권한을 가지는 도메인 계정 • Active Directory 도메인에서 관리 권한을 가지지 않는 도메인 계정. • 도메인 관리자가 각 계정별로 SPN(Service Principal Name)을 등록해야 함. • Windows 2000 Resource Kit setspn 유틸리티

41. 미들티어 시나리오 3:연결 문자열의 Roles 속성 • 시나리오: • 인터넷 솔루션 • 단계: • 사용자를 인증 • ASP app가 리포지토리에서 사용자 이름에 대한 역할 조회 • SQL Server, XML File, Active Directory, 등등… • 연결 문자열에서 Roles 예약어를 사용하여 Analysis Services에 연결 연결 문자열: Provider=msolap; roles=<UserRole> Analysis Services Browser IIS ASP.net, ASP 사용자를 인증 각 사용자에 대한 역할 저장소 (Active Directory 가능)

42. 연결 문자열의 Roles : Pros & Cons • Pros • 단순함 • 빠름 • 임의의 표준 또는 사용자 지정 인증 메카니즘 • Cons • 사용자들과 관련된 역할들의 저장 관리 • 약간의 코딩 요구 • 동적인 보안을 사용할 수 없음

43. 보안 구현 • Safety Options – 클라이언트에 의한 안전하지 않은 라이브러리의 등록 및 기동 여부 결정 – UDF, 동작, 로컬 큐브에서의 PASSTHROUGH 예약어 허용 • User defined function <function name> cannot be used, because the class that implements it is not safe for initialization or scripting, which is required by client settings. • Allow All: 모두 허용, 권고하지 않음 • Allow Safe: 안전한 것으로 마크된 라이브러리만 허용 • Allow None: 모든 라이브러리의 로딩 금지 • 기본값: • Integrated: Allow All • HTTP: Allow Safe • 참고 • Excel은 연결 문자열 값을 Allow Safe로 Override • http://support.microsoft.com/default.aspx?scid=kb;en-us;Q182598

44. UDF • UDF가 보안상 약점이 있는 소스일 수 있다. • 시스템 함수나 다른 UDF를 사용자 정보나 개재없이 호출 가능성 • 텍스트 형태의 자격 증명 정보를 포함 가능성 • 함수 구현 전에 보안 이슈 검토 필요 • UDF를 포함하는 라이브러리를 로딩시 항상 절대 경로 사용 권고