개발자는 Dev 데이터베이스 인스턴스

Question

...에 대한 사용 권한과 권한을 어떻게 부여해야합니까? 나는 대규모 IT 부서에서 70 개 이상의 응용 프로그램을 사용하고 있으며, 일부는 SQL 서버에 있고 대부분 Oracle에 있습니다. 각 시스템에는 prod, QA 및 Dev 인스턴스가 있습니다. 우리 (저는 개발자입니다)는 prod/qa에 읽기 전용으로 액세스 할 수 있습니다. SQL Server 개발 인스턴스에서 devs는 db_owner로 주어지며, 이는 정상적으로 작동합니다. DEV oracle 데이터베이스에서 어떤 권한을 가져야하는지에 대한 논쟁이 있습니다.

저는 각 개발팀이 개발을 위해 자신의 인스턴스를 자신의 워크 스테이션에서 실행하는 것이 가장 좋지만 데이터베이스의 크기 때문에 이것이 옵션으로 간주되지 않았 음을 알고 있습니다.

이 사용 권한을 적용해야하는 방법에 대해서도 관심이 있습니다. 역할을 통해 부여 된 오라클 권한은 PL/SQL 실행 중에 활성화되지 않으므로 역할 (심지어 "dba"역할)도 유용하지 않습니다. 따라서 계정 (시스템)이 내장되거나 수십 명의 사용자가 수십 개의 데이터베이스를 만들고 각각에 수십 개의 사용 권한을 직접 부여 할 수 있습니다. 내 마음 속에는 시스템으로 devs 로그인을시키는 것이 많은 의미를 갖지만 DBA는 이것이 나쁜 생각이라고 주장합니다.

Answer 1

우리는 단지 개발자에게 응용 프로그램 계정에 대한 액세스 권한을 부여했습니다. 이것은 작은 상점에서 효과적이지만 개발자 수가 증가함에 따라 급속도로 어려워집니다. 그것은 자신의 계정 (일명 스키마)의

1. 응용 프로그램이있다 :

   여기에 우리가 지금하는 일입니다.

2. 개발자는
3. 데이터 우리는 당신이 원하는대로 스키마에 코드를 구축 할 수있는 개미 빌드 스크립트가 응용 프로그램 스키마
4. 에있는 자신의 계정이있다.
   • 코드 뷰, 패키지, 개체 등
   • 빌드 스크립트는
5. 개발자는 변경할 응용 프로그램 데이터를 개발자에게 명시 적으로 권한을 부여하는 저장 프로 시저를 실행하는 단계를 포함을 포함 자신의 자신의 스키마
6. 그들이 행복 할 때 서브 버전으로 확인하십시오
7. 응용 프로그램의 dev 스키마는 새 subversion 빌드에서 작성됩니다.
8. 개발자는 자신의 환경을 체크 아웃하고 다시 작성할 수 있습니다.테이블 구조에
9. DDL 변경이뿐만 아니라이 모든 프런트 엔드 응용 프로그램을 확보하는 이점을 갖고

스크립팅 할 수 있습니다 지속적으로 데이터베이스 개발자에 의해 파괴되지

• DBA에 통해 수행된다 모든 것을 재건.

Answer 2

DBA의 작업 중 하나는 사용자 권한을 관리하는 것입니다. 필자는 시스템이 몇 가지 이유로 좋은 생각이 아니라고 생각하지 않는다. 당신이 원하지 않는 전체 스키마를 삭제할 수있는 능력은 최소한이다. 즉, 모든 사용자에게 권한을 부여하고 DBA가 수십 개의 계정이있을 수 있음에도 불구하고 이러한 권한을 관리하게하는 것이 이상적이라고 생각합니다. 대부분의 DBA는 어쨌든이 권한을 관리하는 데 사용할 수있는 스크립트를 갖습니다.

DBA의 말을 듣고, 그들은 일반적으로 그들이 말하는 것을 알고 있습니다.

Answer 3

단지 dev 인스턴스 일 경우; 모든 사용자에게 관리 역할에 개별 계정이 추가되어 있습니다. 그렇게하면 사용자별로 활동을 기록 할 수 있습니다. 그러나 devs에게 그들의 일을하기에 충분한 숨쉴 공간을 제공하십시오.

Answer 4

실제 개체를 소유 한 응용 프로그램 계정이 비교적 적은 것으로 가정합니다. 따라서 하나 이상의 논리적 응용 프로그램은 특정 Oracle 사용자가 소유 한 테이블로 구성됩니다. 이것은 SYSTEM 또는 SYS가 아니라 회사가 제공하는 계정이 될 수 없습니다. DBA가 작성한 계정입니다. Oracle 샘플 스키마에 익숙하다면 HR 사용자는 HR 어플리케이션의 백엔드를 구성하는 HR 스키마의 모든 테이블을 소유합니다.

"가장 간단하게 작동 할 수있는"원칙부터 시작하여 개발자가 해당 응용 프로그램 계정에 직접 로그인 할 수 있는지를 먼저 판단해야합니다. 이것은 가능한 가장 안전한 구성이 아니며, 개발자가 우발적으로 또는 의도적으로 추적하거나 쉽게 해결할 수없는 손상을 입을 수있는 가능성을 열어줍니다. 그러나 그것은 조직에 따라 합리적으로 잘 작동 할 수 있습니다. 권한 관리는 간단합니다. 응용 프로그램 소유자 계정에는 이미 필요한 모든 권한이 이미 있습니다.

다음 단계는 모든 개발자에게 데이터베이스의 공용 동의어가로드되고 응용 프로그램 코드에 스키마 한정자가 없을 경우 개발할 별도의 스키마를 제공하는 것입니다. 개발자의 스키마는 해당 객체의 공유 버전을 자동으로 대체합니다. 이것은 훨씬 더 좋은 격리를 제공합니다. 권한은 일반적으로 개발자가 필요로하는 모든 권한을 포함하는 스크립트를 작성하거나 "알려진 양호한"계정의 모든 권한을 새 계정으로 복사하는 스크립트를 작성하여 부여됩니다. 특별히 작성하기도 쉽지 않습니다. 모든 개발자가 새로운 권한이 부여 될 때 실행되는 일반적으로 또 다른 스크립트 인 동일한 권한 집합으로 끝나야합니다.

Answer 5

내 그룹은 약 100 개의 응용 프로그램을 지원하며 약 20 개는 자체 Oracle 스키마가 있습니다. 우리는 모든 개발자의 길을 간 다음 스키마에 대한 암호를 가지고 있으므로 편리합니다. 그러나 궁금한 점은 각 개발자가 자체 Oracle 계정을 사용하여 개발할 것을 권장합니다. 주된 이유는 감사입니다.

Answer 6

나는 최상의 경우는 에 될 것이라고 각각 개발, 에 대한 자신의 워크 스테이션에서 자신의 예를 을 실행 디바이스가 인식 할 수 있습니다 만, 때문에 데이터베이스의 크기의이 옵션으로 간주되지 않았습니다.

개인 데이터 복사본의 데이터 양을 줄이는 방법이 있습니까? 이상적인 해결책 인 것 같습니다. 필요한 변경을 할 수 있기 때문입니다. 그런 다음 준비가되면 DBA에 제출하여 공유 개발 서버를 업데이트 할 수 있습니다.

Answer 7

저장된 PL/SQL 오브젝트를 개발할 경우, 언급 된 오브젝트를 소유 한 스키마에는 언급 한대로 사용 된 오브젝트에 대한 명시 적 권한이 필요합니다. 단일 '데이터'스키마가 있지만 자신의 개별 스키마에 코드를 개발하는 경우 개발 스키마에 데이터 스키마 개체에 대한 액세스 권한을 부여해야합니다. 일반적으로 나는 데이터 스키마의 사용자 이름/암호를 기대합니다.

시스템 권한 (예 : CREATE)과 관련하여 CREATE TABLE, TYPE, VIEW, PROCEDURE TRIGGER, SYNONYM을 기대합니다. 자신이하는 일에 따라 다른 것이 적절할 수 있습니다 (예 : CONTEXT). DBA는 잘못 사용하면 손상 될 수 있으므로 CREATE DIRECTORY를 배제 할 수 있습니다. 그 중에서 ANY가있는 특권을위한 DOTTO (예 : SELECT ANY TABLE, DELETE ANY TABLE)

성능 조정/시스템 모니터링의 경우, 데이터베이스의 SELECT_CATALOG_ROLE이 좋습니다. DBA가 위험을 회피하는 경우 개별 견해에 대한 교섭을 협상해야 할 수도 있습니다. 사용중인 버전에 대한 REFERENCE 가이드를 통해 사용할 수있는 것이 있는지 물어보십시오.