Oracle의 스키마 수준 권한 부족을 어떻게 처리합니까? Oracle의 보안 아키텍처는 객체 수준 권한 만 필요한 응용 프로그램에 적합하며 제한이 거의없는 DBA에 적합합니다. 그러나, 다중 스키마에서 프론트 엔드 애플리케이션과 PL / SQL로 개발하는 프로그래머에게는 아키텍처에 큰 차이가있는 것 같습니다. 단점이있는 옵션 중 일부는 다음과 같습니다.

1. 각 프로그래머가 자신의 스키마로 개발하도록하십시오. DBA는 필요한 프로그래머에게 오브젝트 레벨 권한을 부여합니다. 모든 패키지 개발은 DBA가 수행해야합니다. 주요 단점은 프로그래머가 데이터베이스 성능을 저하시키기 위해 비트 버킷처럼 데이터베이스를 사용한다는 것입니다. 프로그래머가 데이터베이스에서 개발하기를 원하지만이 방법은 데이터베이스를 크게 권장하지 않습니다.

2. 각 프로그래머에게 개발에 필요한 12 가지 정도의 스키마에 대한 사용자 이름 / 비밀번호를 부여하십시오.이 응용 프로그램 스키마에 프로 시저, 테이블 등을 작성할 수있는 권한을 부여하십시오.이 방법의 단점 중 일부는 프로그래머가 여러 로그인을 유지 보수해야한다는 것입니다. 그들 자신으로 거의 로그인하지 않았습니다. 크로스 스키마 개발도 어렵습니다.

3. 프로그래머에게 개발에 필요한 각 스키마에 대한 프록시 인증 권한을 부여하십시오. 이렇게하면 프록시 권한 이외의 권한을 부여 할 필요없이 스스로 로그인 상태를 유지할 수 있습니다. 단점은 프록시를 위해 각 스키마에 대해 별도의 연결을 유지해야하는 프로그래머, 연결이 지속적으로 변경되어야하므로 크로스 스키마 개발이 더 번거롭고 인증이 통과 된 공용 데이터베이스 링크를 사용하는 패키지는 프록시 연결 내부에서 컴파일되지 않습니다.

4. 각 프로그래머에게 DBA 권한을 부여하십시오. – 단점은 보안입니다. 스키마 프로그래머를 스키마에서 제외시킬 수 없으며 프로그래머는 다른 프로그래머 (DBA)를 가장 할 수 있습니다.

각 프로그래머에게 SELECT / INSERT / CREATE / etc를 부여하는 옵션이없는 것 같습니다. 개발에 필요한 스키마에 대한 권한. 하나의 연결을 사용하여 작업을 수행하기 위해 스스로 로그인합니다. 액세스 할 수있는 스키마의 새 개체를 즉시 사용할 수 있습니다.

뭔가 빠졌습니까? PL / SQL 개발을 수행하는 응용 프로그램 프로그래머를 어떻게 처리합니까?

답변

sql> 스풀 privs.sql
sql> select 'scott의 부여 선택.'|| table_name || ' role_select; ' dba_tables에서 owner = 'SCOTT';
sql> @ privs.sql
sql> john, sam, peter에게 role_select 부여