2016-07-19 2 views
0

상황 : 데이터 일관성을 유지하기 위해 많은 트리거에 크게 의존하는 데이터베이스를 개발했습니다 (CFR 21 Part 11 이행). 사용자를 저장하는 테이블이 두 개 있습니다 (). SQL 서버 사용자 관리가 유리합니다. 사용자는 외부 인증에 대한 정적 로그인 데이터를 포함하고 X1에는 Google 시스템 (가짜 사용자)에 대한 로그인 데이터가 포함됩니다. 사용자는 Login 데이터 (실제 사용자) 중 하나를 사용하여 애플리케이션에 로그인해야합니다. 시스템이 외부 시스템 (Active Directory 또는 FileSystem 또는 Database)과 통신해야하는 경우 해당 User (Fake User)이 가장합니다.삽입 문에 그림자 열 추가

설명을 위해 로그인 용 X1 (실제 사용자) 및 사용자 용 X2 (가짜 사용자)를 사용합니다.

X2가 데이터베이스에 연결되면 트리거는 X1이 누구인지 알지 못합니다.

문제점 : 트리거는 X2에서 수행 한 각 작업을 기록하고 로그에 기록합니다. 서버는 X2가 데이터베이스에 연결되어 있음을 알고 있기 때문에 실제 사용자 X1을 알지 못합니다.

고객은 RealUser X1이 누구인지 확인합니다. 이 정보는 데이터베이스에 연결될 때 없어 지므로 지금이 문제가 있습니다.

해결 시도 :

  1. 가 인수로 RealUser X1에 소요 된 StoredProcedure를 만듭니다. 기존의 소프트웨어가 테이블 삽입 및 업데이트에 의존하므로 불가능합니다.
  2. Insert/Update 문을 추가 데이터 추가 (가능하면 해당 항목을 찾지 못했습니다). 데이터는 트리거에 의해서만 사용되며 테이블에 기록해서는 안됩니다.
  3. 현재 X1 사용자에 대한 정보를 Connection 또는 일반 Connection 기반 저장소에 추가하십시오. (이와 비슷한 것이 SqlServer에 있습니까?)
  4. Username을 "위장"하기 위해 ApplicationName 속성을 사용하십시오. 그러나 이것은 내가 단안경을 입는 느낌을 갖게한다. 더 나은 방법을 사전에

감사가 있어야합니다

답변

0

당신은 (예를 들어, 같은 원래의 사용자 ID) 트리거에 액세스 할 수있는 세션에 추가 데이터를 연결 CONTEXT_INFO를 사용할 수 있습니다

DECLARE @UID VARBINARY(128) = CONVERT(VARBINARY(128), N'User1') 
SET CONTEXT_INFO @UID 

-- Later, at the Hall of Justice 
SELECT CONVERT(NVARCHAR(64), CONTEXT_INFO()) 

물론 VARBINARY(128)에 맞으면 유니 코드 문자열보다 다른 방법으로 사용자를 식별 할 수 있습니다.

이 기능을 사용하려면 명령을 실행하기 전에 일관되게 정보를 설정해야합니다 (연결이 닫힐 때 컨텍스트 정보가 재설정 됨). 또한 보안 문제가 있습니다. SET CONTEXT_INFO은 권한있는 명령문이 아니며 누구든지 실행할 수 있으므로 감사 정보가 위조되지 않도록 데이터베이스의 모든 코드를 제어해야합니다.