애플리케이션 정보

이 페이지의 스크립트 콘텐츠는 탐색 용도로만 사용되며 어떤 방식으로든 콘텐츠를 변경하지 않습니다.

응용 프로그램의 용도, 구조 및 이름 지정 규약은 다음과 같습니다.

애플리케이션의 목적

이 애플리케이션은 회사에서 두 종류의 사용자를 대상으로 합니다.

• 일반 유저(직원 관리자)

• 응용 프로그램 관리자

일반 사용자는 다음 태스크를 완료할 수 있습니다.

• 지정된 부서의 사원 가져오기

• 지정된 사원의 직무 기록 가져오기

• 지정된 사원(이름, 부서, 직무, 관리자, 급여 등)에 대한 일반 정보 표시

• 지정된 사원의 급여 변경

• 지정된 사원의 직무 변경

응용 프로그램 관리자는 다음 작업을 완료할 수 있습니다.

• 기존 직무의 ID, 직책 또는 급여 범위 변경

• 새 작업 추가

• 기존 부서의 ID, 이름 또는 관리자 변경

• 새 부서 추가

애플리케이션 구조

응용 프로그램은 다음 스키마 객체 및 스키마를 사용합니다.

응용 프로그램의 스키마 객체

응용 프로그램은 다음 스키마 객체로 구성됩니다.

• 다음 데이터를 저장하는 네 개의 테이블:

  • 작업

  • 부서

  • 직원

  • 사원의 직무 기록

• 테이블이 포함된 네 개의 에디션 뷰로, 에디션 기반 재정의(EBR)를 사용하여 완성된 애플리케이션을 사용 중일 때 업그레이드할 수 있습니다.

• 업무 규칙을 적용하는 두 개의 트리거

• 새 부서 및 새 사원에 대해 고유한 Primary Key를 생성하는 두 개의 시퀀스

• 두 가지 패키지:

  • employees_pkg - 일반 사용자를 위한 API(응용 프로그램 인터페이스)

  • admin_pkg, 응용 프로그램 관리자를 위한 API

  일반적인 사용자 및 응용 프로그램 관리자는 API를 통해서만 응용 프로그램에 액세스합니다. 따라서 패키지 서브 프로그램을 호출해야만 데이터를 변경할 수 있습니다.

참조:

• 스키마 객체에 대한 정보는 "Oracle Database 정보"를 참조하십시오.

• Oracle Database Development Guide - EBR에 대한 정보

응용 프로그램의 스키마

보안을 위해 응용 프로그램은 다음 5개의 스키마(또는 사용자)를 사용하며, 각 스키마에는 필요한 권한만 있습니다.

• app_data는 패키지를 제외한 모든 스키마 객체를 소유하며 예제 스키마 HR에 있는 테이블의 데이터로 테이블을 로드합니다.

  패키지를 생성하는 개발자는 이 스키마에서 작동하지 않습니다. 따라서 응용 프로그램 스키마 객체는 실수로 변경하거나 삭제할 수 없습니다.

• app_code는 employees_pkg 패키지만 소유합니다.

  employees_pkg의 개발자가 이 스키마에서 작업합니다.

• app_admin은 admin_pkg 패키지만 소유

  admin_pkg의 개발자가 이 스키마에서 작업합니다.

• 일반적인 응용 프로그램 유저인 app_user는 아무 것도 소유하지 않으며 employees_pkg만 실행할 수 있습니다.

  middle-tier 응용 프로그램 서버는 app_user로 연결 풀의 데이터베이스에 연결합니다. 예를 들어, SQL 주입 버그에 의해 이 스키마가 손상되면 공격자는 employees_pkg 서브 프로그램이 보고 변경할 수 있는 것만 보고 변경할 수 있습니다. 공격자는 테이블을 삭제하거나, 권한을 escalate하거나, 스키마 객체를 생성하거나, 변경하거나, 다른 작업을 수행할 수 없습니다.

• 응용 프로그램 관리자인 app_admin_user는 아무 것도 소유하지 않으며 admin_pkg 및 employees_pkg만 실행할 수 있습니다.

  이 스키마에 대한 연결 풀은 매우 작으며 권한이 있는 유저만 액세스할 수 있습니다. 이 스키마가 손상된 경우 공격자는 admin_pkg 및 employees_pkg 서브 프로그램이 보고 변경할 수 있는 것만 보고 변경할 수 있습니다.

app_user와 app_admin_user 대신 응용 프로그램에 아무것도 소유하지 않은 스키마가 하나만 있고 employees_pkg와 admin_pkg를 모두 실행할 수 있다고 가정해 보겠습니다. 이 스키마에 대한 연결 풀은 일반 사용자와 응용 프로그램 관리자 모두에게 충분히 커야 합니다. employees_pkg에 SQL 주입 버그가 있는 경우 해당 버그를 악용한 일반 유저는 admin_pkg에 액세스할 수 있습니다.

app_data, app_code 및 app_admin 대신 응용 프로그램에 패키지를 포함한 모든 스키마 객체를 소유한 스키마가 하나만 있다고 가정합시다. 그러면 패키지는 테이블에 대한 모든 권한을 가지며 이는 불필요하고 바람직하지 않습니다.

예를 들어, Audit Trail 테이블 AUDIT_TRAIL이 있다고 가정해 보겠습니다. employees_pkg의 개발자가 AUDIT_TRAIL은 쓸 수 있지만 읽거나 변경할 수는 없습니다. admin_pkg의 개발자가 AUDIT_TRAIL을 읽고 쓸 수 있기를 원하지만 변경할 수는 없습니다. AUDIT_TRAIL, employees_pkg 및 admin_pkg가 동일한 스키마에 속하는 경우 두 패키지의 개발자는 AUDIT_TRAIL에 대한 모든 권한을 가집니다. 그러나 AUDIT_TRAIL이 app_data에 속하고 employees_pkg이 app_code에 속하며 admin_pkg이 app_admin에 속하는 경우 데이터베이스에 app_data로 연결하여 다음 작업을 수행할 수 있습니다.

GRANT INSERT ON AUDIT_TRAIL TO app_code;
GRANT INSERT, SELECT ON AUDIT_TRAIL TO app_admin;

참조:

• 스키마에 대한 정보는 "Oracle Database 정보"를 참조하십시오.

• 샘플 스키마 HR에 대한 정보의 "샘플 스키마 HR 정보"

• "권장되는 보안 정책"

응용 프로그램의 이름 지정 규칙

응용 프로그램에서는 이러한 이름 지정 규칙을 사용합니다.

항목	이름
테이블	테이블 번호
테이블 번호에 대한 에디션 보기	테이블
에디션 보기 테이블에서 트리거	table_{a|b}event[_fer] 설명: a는 AFTER 트리거를 식별합니다. b는 BEFORE 트리거를 식별합니다. fer는 FOR EACH ROW 트리거를 식별합니다. event는 트리거를 실행하는 이벤트를 식별합니다. 예: INSERT의 경우 i, INSERT의 경우 iu, UPDATE의 경우 d, DELETE의 경우 d
PRIMARY KEY 제약 조건(table#)	table_pk
table#.column의 NOT NULL 제약 조건	table_column_not_null(각주 1)
table#.column의 UNIQUE 제약 조건	table_column_unique(각주 1)
table#.column에 대한 CHECK 제약 조건	table_column_check(각주 1)
table1#.column에서 table2#.column에 대한 REF 제약 조건	table1_to_table2_fk(각주 1)
table1#.column1에서 table2#.column2로의 REF 제약 조건	table1_col1totable2_col2_fk(각주 1)(각주 2)
테이블 번호의 시퀀스	테이블_순서
매개변수 이름입니다	p_이름
로컬 변수 이름입니다.	l_name(이름)

각주 1: table, table1 및 table2는 emp for employees, dept for departments 및 job_history의 job_hist로 축약됩니다.

각주 2: col1 및 col2는 열 이름 column1 및 column2의 약어입니다. 제약 조건 이름은 30자를 초과할 수 없음.