기존 응용 프로그램에서는 삽입, 업데이트 및 삭제 작업을위한 저장 프로 시저를 만들어야한다고하는 것은 일반적인 지식입니다. 또한 트리거를 사용할 필요가 없도록 저장 프로 시저를 사용하므로 트리거의 일반적인 함정을 피할 수 있습니다.저장 프로 시저 대신 보안을위한 뷰 및 트리거 사용
또 다른 생각은 전체 데이터베이스를 뷰로 덮는 것입니다. 누구도 테이블 자체에 액세스 할 수 없으므로 뷰에 대해 CRUD 작업을 수행합니다. 그렇게하면 특정 열에 대한 액세스 권한을 다른 사용자에게 부여하려는 경우 해당 열이 포함 된보기 또는 계산 만 만들 수 있습니다. 업데이트 & 삭제 작업에 논리를 적용해야하는 경우 (즉, 누군가가 테이블의 총 행 수에 2 % 이상 영향을주지 못하게하는 경우) instead of 트리거를 통해이를 수행 할 수 있습니다.
트리거의 일반적인 함정에 빠지지 않기 위해 (1) 트리거는 테이블 만 업데이트해야하며 다른 뷰는 업데이트하지 않아야합니다. (2) 트리거는 절대로 테이블에 놓이지 않습니다. (3)보기는 다른보기에 액세스 할 수 없습니다. (4) 어떤 이유로 든 처음 세 가지 규칙에 따라 원하는 것을 수행 할 수없는 경우 저장 프로 시저를 만듭니다.
보안을 구현할 때 나타나는 이점은보기 및 어쩌면 일부 트리거 (평균 사례 - 2 개의 추가 개체) 만 만들어야한다는 것입니다. 반면 저장 프로 시저 경로를 만들면 항상 3 개 이상 또는 4 개의 추가 오브젝트 (선택을위한 프로 시저를 작성한 경우에 따라 다름). 또한 모든 객체에 대해 세 개의 프로 시저를 매핑 할 필요가 없으므로 NHibernate 매핑이 더 간단합니다.
저장 프로 시저보다는 뷰와 트리거를 주로 사용하는 것과 관련하여 심각한 보안 허점이나 실제적인 문제가있는 경우 질문이 있습니다.
은 "Conventional wisdom"에 대한 참고 자료를보고 싶습니다. 응용 프로그램의 향후 변경 사항에 대해 매우 복잡하고 확실한 악몽을 통해 읽습니다. 이것은 응용 프로그램 보안을 처리하기위한 실용적인 해결책이 아닙니다. –
@K - 무엇이 복잡하게 들릴까요? "Conventional wisdom"또는 "triggers & views"? – kelloti