6. 입자 도 데이터 조작 권한

6. 입자 도 데이터 조작 권한
제6 장
입자 도 데이터 조작 권한
 
 
많은 시스템 이 해커 에 게 취약 하 다.이러한 예 를 보십시오.
1.         프론트 데스크 는 고객 이 볼 수 있 는 고객 데 이 터 를 보 여주 고 사용자 가 삭제 할 수 있 는 고객 데 이 터 는 바로 프론트 데스크 에서 보 여 준 데이터 이다.
2.         사용자 가 어떤 사용 자 를 선택 하면 삭제 단 추 를 누 르 고 배경 에서 삭제 작업 을 수행 합 니 다.
예 를 들 어 배경 에서 삭 제 를 요청 한 url 은:http://www.test.com/crm/customer.do?id=3
가령 id = 13 의 클 라 이언 트 가 프론트 데스크 에 표시 되 지 않 는 다 고 가정 하면 (현재 사용자 가 이 클 라 이언 트 데이터 에 대해 삭제 권한 이 없 기 때문에) 사용자 가 입력 합 니 다.http://www.test.com/crm/customer.do?id=13 분명히 id = 13 의 고객 은 삭 제 될 것 이다.
 
개발 자 들 은 id 값 을 사용 하여 자체 성장 형 을 사용 하지 말고 다른 형 으로 바 꾸 는 것 을 권장 합 니 다. 예 를 들 어 hashcode 등 입 니 다.파충류 로 구멍 을 쉽게 기어 나 올 수 있 는 것 도 적절 하지 않다.
 
분명히 인터페이스 차원 을 통 해 데이터 급 권한 을 제어 하 는 것 만 으로 는 부족 하 다.
해결 방안
데이터 급 방화벽
분명히 업무 시스템 을 위해 데이터 급 방화벽 을 구축 해 야 한다.이 방화벽 은 현재 사용자 가 요청 한 데이터 에 대해 조작 권한 이 있 는 지 판단 할 수 있다.조작 권한 이 없 으 면 업무 시스템 에 알 리 고 거부 이 유 를 알려 준다.
방화벽 위치
백 스테이지 업무 방법 이 실행 되 기 전에 권한 검 사 를 해 야 합 니 다.검 사 를 통과 한 후에 야 이 조작 을 실행 할 수 있 으 며, 그렇지 않 으 면 실행 하지 않 을 것 이다.
 
이런 주입 모드 는 2 가지, 1, 하 드 코딩 주입 이 있다.2. AOP 방법 으로 차단 합 니 다.
하 드 인 코딩 주입, 이와 유사:
…
if
( SecurityService.permit( user, customer, Privilege.DELETE_CUSTOMER ) ) {    customerService.delete( customer ); } 
else
 {     …     
//
 이 클 라 이언 트 에 대한 삭제 권한 이 없습니다. 알림 인터페이스 로 이동 합 니 다.
} …
 
AOP 방법 으로 차단 하고 업무 방법 annotation 에 서명 합 니 다. 이 방법 이 실 행 될 때 자동 으로 권한 판단 논 리 를 촉발 합 니 다.
public
 
interface
 CustomerService {     
/**
       * @security id=DELETE_CUSTOMER     public void delete( Customer customer, User user ); }
권한 논리
대부분의 업무 시스템 은 if else 논리 로 사용자 가 특정한 데이터 에 대한 조작 권한 이 있 는 지 판단 합 니 다.
이러한 세분 화 된 권한 논 리 는 어떤 모델 을 사용 하여 자동 으로 처리 하기 어렵 거나 매우 어렵다. 따라서 대부분의 시스템 은 하 드 코딩 모델 로 권한 논 리 를 실현 한다.
이 장 에 서 는 권한 논 리 를 관리 하기 위해 Metadmin 을 어떻게 사용 하 는 지 소개 합 니 다.
하면, 만약, 만약...
다음은 metadmin 다운로드 패키지 에 포 함 된 프 리 젠 테 이 션 예제 입 니 다. www. metadmin. com 에서 Metadmin 설치 패 키 지 를 다운로드 할 수 있 습 니 다.
 
Metadmin 은 프로 그래 밍 을 통 하지 않 고 디자이너 를 통 해 권한 논 리 를 신속하게 설계 하고 온라인 으로 권한 논 리 를 테스트 할 수 있 습 니 다.
어떻게 시스템 과 통합 합 니까?
MetadminService 클래스, 다음 과 같은 방법 을 제공 합 니 다.static Decision permit (int privilegeId,   User user, java.lang.Object businessData, java.util.Map context)             의사 결정 권한 수여 전략 을 평가 하고 의사 결정 결 과 를 되 돌려 줍 니 다.
privilegeId 작업 에 대해 user 는 businessData 업무 데이터 에 대해 조작 권한 이 있 는 지 여 부 를 표시 합 니 다. context 는 권한 이 필요 한 업무 데 이 터 를 판정 하고 null 로 할 수 있 습 니 다.
 
WebMetadminService 클래스 는 다음 과 같은 방법 을 제공 합 니 다.static boolean permit (HttpServletRequest req, int privilegeId, java.lang.Object businessObject)             의사 결정 권한 수여 전략 을 평가 하고 의사 결정 결 과 를 되 돌려 줍 니 다.static boolean permit (HttpServletRequest req, int privilegeId, java.lang.Object businessObject, java.util.Map context)             의사 결정 권한 수여 전략 을 평가 하고 의사 결정 결 과 를 되 돌려 줍 니 다.
웹 MetadminService 는 MetadminService 를 웹 프로그램 으로 패키지 하고 HttpServletRequest 에서 user 를 꺼 내 며 명시 적 으로 값 을 전달 하지 않 습 니 다.
전체 JAVADOC 탐색:http://www.metadmin.com/doc/javadoc/index.html
 
예제 프로그램, 삭제 직원 에 대한 권한 판정 코드 는 다음 과 같 습 니 다.
if
 (WebMetadminService.permit(req, Privilege.DELETE_EMPLOYEE,                     employee)) {     employeeManager.deleteEmployee(id); }
 
employee 대상 은 프론트 데스크 에 들 어 오 는 id 매개 변수 에 따라 데이터베이스 에서 조회 한 직원 대상 입 니 다.
권한 논리 설정
상기 사례 설정: 본사 사용 자 는 모든 직원 을 조회 할 수 있 고 지사 사용 자 는 본 지사 와 산하 영업부 직원 을 조회 할 수 있 으 며 영업부 직원 은 본 영업부 직원 을 조회 할 수 있다.
 
본 사례 는 직원 삭제 권한 을 수정 합 니 다. 모든 사용 자 는 자신 이 있 는 기구의 직원 만 삭제 할 수 있 습 니 다. 즉, 본사 사용 자 는 본사 직원 만 삭제 할 수 있 고 지사 사용 자 는 지사 직원 만 삭제 할 수 있 습 니 다. 영업부 사용 자 는 영업부 직원 만 삭제 할 수 있 습 니 다.
 
Metadmin 은 이러한 권한 논리 에 대해 '모든 사용자' 사용자 분류 와 '사용자 가 있 는 기구 직원' 업무 데 이 터 를 분류 한 다음 에 이 두 가지 분류 쌍 을 '직원 삭제' 권한 으로 설정 하면 됩 니 다.
 
우선, "모든 사용자" 사용자 분 류 를 만 들 고 디자이너 를 엽 니 다.http://localhost:8080/mydemo/metadmin/designer
1.         사용자 분류 표시 줄 에 새 분 류 를 만 들 고 이름 을 '모든 사용자' 로 입력 하 십시오.
2.         고정 값 a 를 만 들 고 값 을 1 로 설정 합 니 다.
3.         표현 식 정의 에서 Binary 표현 식 'a = a' 를 정의 합 니 다.
이렇게 하면 모든 사용자 가 이 조건 을 만족 시 킬 것 이다.
 
그 다음 에 '사용자 가 있 는 기구 직원' 업무 데이터 분 류 를 만 들 고 디자이너 를 엽 니 다.http://localhost:8080/mydemo/metadmin/designer
1.         업무 데이터 분류 표시 줄 에 새 분 류 를 만 들 고 이름 을 '사용자 가 있 는 기구 직원' 으로 입력 하 십시오.
2.         사용자 속성 변수 'userCompanyId' 를 만 듭 니 다. 그 값 은 사용자 의 companyId 속성 과 같 습 니 다.
3.         업무 데이터 변수 인 "businessDataCompanyId" 를 만 듭 니 다. 그 값 은 Employee 대상 의 companyId 속성 과 같 습 니 다.
4.         표현 식 정의 에서 Binary 표현 식 userCompanyId = = businessDataCompanyId 를 정의 합 니 다.
이렇게 하면 user 대상 과 employee 대상 의 copanyId 속성 이 같 을 때 만 데 이 터 는 이 업무 데이터 분류 에 속 합 니 다. 그림 과 같 습 니 다.
 
그리고 이 분류 쌍 을 직원 삭제 권한 에 설정 합 니 다. 그림 과 같이:
이로써 권한 논리 설정 이 완료 되 었 습 니 다. 업무 코드 에 통 합 된 권한 판단 은 이 논리 에 따라 실 행 됩 니 다. 권한 판단 논리 가 바 뀌 면 디자이너 를 열 어 권한 논 리 를 재 설계 하면 됩 니 다. 코드 를 수정 하지 않 고 시스템 을 다시 발표 할 필요 가 없습니다.