감사 트레일 구현- 스프링 AOP vs. hibernate interceptor vs db 트리거
https://stackoverflow.com/questions/769084
-
12-09-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
Russian문제
나는 이것에 대해 몇 가지 토론 스레드를 발견했지만 하나의 스레드 아래에서 세 가지 메커니즘을 모두 비교 한 것은 없습니다.
그래서 여기 내 질문이 있습니다 ...
DB 변경 사항을 감사해야합니다.
나는 이것을하는 세 가지 방법을 생각할 수 있습니다
1) DB 트리거
2) 요면 요약자
3) 스프링 AOP
(이 질문은 스프링 hibernate rdbms에만 해당됩니다. 이것은 이것이 Java c# 또는 Hibernate nhibernate에 중립적 인 것 같지만 답변이 C ++ 또는 Java에 의존하거나 최대 절전 모드의 특정 구현에 의존하는 경우).
이러한 전략 중 하나를 선택할 때의 장단점은 무엇입니까?
구현 세부 사항을 요구하지 않습니다 .- 이것은 디자인 토론입니다.
커뮤니티 위키의 일부로 이것을 만들 수 있기를 바랍니다.
해결책
나는 abou tspring aop에 충분히 알지 못하기 때문에 트리거와 nhibernate에 대해서만 이야기 할 수 있습니다.
그것은 항상 그렇듯이 당신에게 가장 중요한 것이 무엇인지에 달려 있습니다.
DB 트리거
- 빠릅니다
- 기본 SQL에서도 항상 스크립트, 외부 앱에서 호출됩니다.
- NH가 모르는 DB에 데이터를 작성하십시오. 현재 세션에서는 누락됩니다. (예상치 못한 결과로 이어질 수 있음)
- 일반적으로 세션에 대해 아무것도 모릅니다 (예 : 로그인 이름).
인터셉터 / 이벤트를 nhibernate
- DBMS 특정이 아닙니다.
- 사용자 세션, 클라이언트 머신 이름, 특정 계산 또는 해석, 현지화 등과 같은 비즈니스 정보에 쉽게 액세스 할 수 있습니다.
- 엔티티의 속성과 같은 선언 구성을 허용하여 엔티티를 기록 해야하는지 여부와 방법을 정의합니다.
- 로깅을 끄면 업그레이드, 가져 오기, 사용자가 트리거되지 않은 특수 조치에 중요 할 수 있습니다.
- 비즈니스 모델에 대한 엔티티보기를 허용합니다. 당신은 아마도 사용자 관점에 더 가깝습니다.
다른 팁
나는 이것이 질문과 100% 관련이 아니라 새로운 옵션으로 가치를 더한다는 것을 이해합니다.
무슨 일이 일어나고 있는지 감사 할 수있는 두 가지 방법이 있습니다.
트랜잭션 로그 읽기 : 데이터베이스가 전체 복구 모드 인 경우 삽입, 업데이트, 삭제 및 DDL 문에 대한 모든 세부 사항이 트랜잭션 로그에 로그인됩니다.
문제는 기본적으로 지원되지 않았고 다음과 같은 제 3 자 트랜잭션 로그 리더가 필요하기 때문에 읽는 것이 매우 복잡하다는 것입니다. ApexSQL 로그 또는 SQL 로그 구조 (후자는 무료이지만 SQL 2000 만 지원합니다).
이 방법의 장점은 문자 그대로 데이터베이스를 전체 복구 모드로 배치하는 것을 제외하고는 변경할 필요가 없다는 것입니다.
SQL Server Traces : Traces는 일부 규정 준수 시나리오에 필요한 선택 문을 포함하여 추적 파일의 모든 것을 캡처합니다. 단점은 흔적이 구문 분석하고 구성 해야하는 텍스트 파일이라는 것입니다.
데이터베이스 트리거를 사용하지 않아 데이터베이스의 변경 사항을 감사하지 않는 좋은 이유는 생각할 수 없습니다. 인서트, 업데이트 및 삭제는 다양한 소스에서 데이터베이스를 누르면 트리거 가이 모든 것을 포착 할 수 있습니다. 최대 절전 모드 등.
감사를 고려할 때 땜질을 할 때 무엇인지 고려해야합니다. 먼저, 누가 무엇을 바꾸 었는지, 무엇이 변경되었는지에 대한 기록이 악의적 인 변화를 백업 할 수있게되면, 시스템의 문제를 식별 할 수 있습니다 (우리는 어떤 변화가 발생했는지 확인하여 어떤 변화가 발생했는지 확인할 수 있습니다. 그리고 누가 변화를했는지 식별 할 수 있습니다. 사기를 감지 할 때 마지막은 정말 중요 할 수 있습니다. 사용자 인터페이스에서 모든 작업을 수행하면 백엔드의 데이터를 변경하여 수표를 작성하는 사용자가 사기를 저지르는 사용자를 보지 못할 것입니다. 인터페이스에서 모든 작업을 수행하면 Tabel 레벨에 권한을 설정해야하므로 사기가 시작될 수있는 문을 열어야합니다. 인터페이스에서 모든 작업을 수행하면 불만을 품은 직원이 순수한 성가심 값에 대해 전체 사용자 테이블을 삭제했는지 알 수 없습니다. 프론트 엔드에서 모든 일을하면 어떤 무능한 DBA가 실수로 모든 고객 주문을 동일한 고객에게 업데이트했는지 알 수 없습니다. 처음에 감사가 필요한 이유를 잃어 버리기 때문에 감사를위한 트리거를 제외하고는 아무것도 사용하지 않습니다.
최대 절전 모드 인터셉터를 사용하여 감사 로그를 수행하는 것은 깊은 결함이 있습니다. 나는 가장 명백한 결함을 지적하지 않고이 방법을 추천하는 블로그의 수에 놀랐습니다. 인터셉터는 새로운 트랜잭션을 사용하여 감사를 기록해야합니다. 즉, 메인 트랜잭션을 성공적으로 저장하고 감사 거래를 기록하지 못하는 시스템 충돌이 발생할 수 있습니다!
내가 지금 당장 할 수있는 오래된 질문. ver 3.6에서 시작하는 최대 절전 모드와 함께 사용할 수있는 옵션이 하나 더 있습니다.
