컨텍스트 기반 DB 감사 구현 방법은?

컨텍스트 기반 DB 감사 구현 방법은?

현재 DB 기반 애플리케이션을 사용하고 있는데, 이 애플리케이션은 데이터에 접근하기 위한 여러 가지 방법을 가지고 있습니다.

1. 웹 애플리케이션
2. 직접 SQL 액세스 사용자(이 사용자를 제거하려고 합니다)
3. 클라이언트 서버 응용 프로그램
4. 배치 입력 및 출력

현재의 데이터 감사로는 데이터 변경의 원인이 된 프로세스를 소급적으로 식별하기에 충분하지 않기 때문에 컨텍스트 기반 감사를 구현해야 합니다.

저는 현재 XAPI(Transactional APIs) 뒤에 데이터 모델을 숨기는 것을 생각하고 있으며, 데이터 모델에 대한 각 작업은 피감 데이터 자체와 함께 저장될 데이터 변경에 대한 관련 작업 또는 이유를 식별하는 어떤 형태로든 제공해야 합니다.

데이터베이스에 대한 모든 액세스를 포함하는 컨텍스트 기반 감사를 달성하기 위한 더 나은 방법을 제안해 줄 수 있는 사람이 있습니까?아니면 제가 놓친 현재 접근법의 명백한 결함을 지적하기라도 하나요?

미리 감사드립니다.

이것은 오래된 게시물이지만, 누군가에게 유용할지도 모르는 해결책을 제공하고 싶습니다.

Oracle은 각 세션에 대해 "context" 변수를 제공합니다.연결 풀을 사용하여 데이터베이스에 연결하는 응용 프로그램에서 Oracle은 "CLIENT CONTEXT"라는 기본 네임스페이스를 제공합니다.해당 네임스페이스 내에서 USER ID와 같은 변수를 만들고 서버 웹 요청에 연결이 전달될 때 이 변수가 설정되었는지 확인할 수 있습니다.이런 방식으로 데이터베이스 내부에서 dbms_session과 같이 데이터베이스 내부에서 처리되는 "웹 사용자"(또는 앱 사용자별) 요청을 식별할 수 있습니다.set_context('CLIENTCONTECT', user_id, ); 도움이 되길 바랍니다.

EDIT는 아래쪽에 답변의 컨텍스트 특정 부분을 추가했습니다.

• 모든 사용자는 로그인을 합니다.
• 이러한 로그인을 SQL Server 사용자에 연결합니다.
• SYSTEM_USER(예: SYSTEM_USER 선택)를 감사에 사용합니다.

위 내용이 까다로워지는 곳은 웹 앱뿐입니다.

• 웹 응용 프로그램이 내부인지 여부를 알 수 없습니다(내부인 경우 가장/위임과 함께 Windows 인증을 사용하면 좋습니다).
• 외부의 경우 웹 앱 로그인을 확인하는 시스템 정의 계정이 있을 것이며 다른 권한 있는 작업을 수행할 수도 있습니다. 그러면 세션 중에 db 액세스를 위해 사용자 자신의 자격 증명을 사용할 수 있습니다.
• • SQL Server 사용자가 많이 있는 것을 원하지 않는 경우 직접 세션 관리를 수행하여 로그인/로그아웃 시와 같이 즉시 사용자를 생성/삭제할 수 있습니다.

여기 설명할 T-SQL이 있습니다.

-- AFTER SUCCESSFUL LOGIN
BEGIN
-- You would already have the user name and password
DECLARE @user varchar(32)
SET @user = 'tester'
DECLARE @pw varchar(32)
SET @pw = 'SuperTest123'
-- if the user logs in from 2 different sessions
-- keep the name more unique
SELECT @user = @user + REPLACE(NEWID(), '-', '')
-- build the dynamic sql to create a user
DECLARE @sql varchar(8000)
SELECT @sql = 'CREATE LOGIN [' + @user + '] WITH PASSWORD = ''' + @pw + '''; '
SELECT @sql = @sql + 'USE MyDatabase; CREATE USER [' + @user + '] FOR LOGIN [' + @user + '] WITH DEFAULT_SCHEMA = db_datareader; '
EXEC(@sql)
-- use these credentials for web apps sql connections
SELECT @user [UserName], @pw [Password]
END

-- AFTER LOGOUT / SESSION EXPIRATION
BEGIN
-- You would already have the user+guid used by the sql server
DECLARE @login varchar(32)
SET @login = 'tester3C8DA60B996C4E5881774D1FE4'
-- build the dynamic sql to drop user
DECLARE @sql varchar(8000)
SELECT @sql = 'DROP LOGIN [' + @login + ']; '
SELECT @sql = @sql + 'USE MyDatabase; DROP USER [' + @login + ']; '
EXEC(@sql)
-- user gone until next session
END

상황 제약은 감사 트리거에서 직접 달성할 수 있습니다.

• 표: TEMP_AUDIT REASON
• • [사용자] VARCHAR(128) DEFAULT SYSTEM_USER
• • [이유] VARCHAR(512)
• 트리거

약간의 입담일 수도 있지만...

IF EXIST(SELECT [Reason] FROM [TEMP_AUDITREASON] WHERE [User] = SYSTEM_USER AND [Reason] IS NOT NULL)
BEGIN
 SELECT @REASON = [Reason] FROM [TEMP_AUDITREASON] WHERE [User] = SYSTEM_USER
 -- clear it for the next transaction
 DELETE FROM [TEMP_AUDITREASON] WHERE [User] = SYSTEM_USER
END
ELSE
BEGIN
 -- SOUND THE ALARM!!! no reason was given
END

언제, 누구에 의해 무엇이 변경되었는지에 대한 상세한 감사 정보를 요구받는 프로젝트가 있었습니다.

우리의 경우, 우리가 한 일은 MVC 솔루션을 개선하여 상황이 바뀌었을 때 감사 추적을 유지하는 것입니다.그 상황에서, 우리는 웹 유저, 아이피 등과 같은 보조 정보를 저장할 수 있었습니다.

또한, mysql 바이너리 로깅을 활성화하여 필요한 경우 전체 이력을 롤백할 수 있으며, 변경 소스를 구별하기 위해 액세스에 대해 저장된 추가 로그를 제공했습니다.

데이터베이스와 실제 데이터베이스 액세스 사이에 계층이 없다면 좀 더 까다로울 것입니다.그래서 중간 계층으로 작동할 수 있는 데이터로 운영을 위한 api를 만들고 당신이 원하는 모든 제어권을 줄 것을 제안합니다.

이것은 당신이 시작할 수 있는 방법을 알려줄 것입니다.

언급URL : https://stackoverflow.com/questions/6708499/how-to-implement-context-based-db-auditing