Qué permisos deben tener los Desarrolladores en la instancia de la base de datos Dev.

Question

... y cómo deben otorgarse esos permisos. Trabajo en un gran departamento de TI con más de 70 aplicaciones, algunas en SQL Server y la mayoría en Oracle. Cada sistema tiene una instancia prod, QA y Dev. Nosotros (soy desarrollador) tenemos acceso de solo lectura a prod/qa, con lo cual estoy de acuerdo. En los desarrolladores de instancias de SQL Server, los desarrolladores reciben db_owner, que funciona totalmente bien. El debate es sobre qué permisos debería tener en las bases de datos de DEV Oracle.

Reconozco que lo mejor sería que cada desarrollador ejecutara su propia instancia en su estación de trabajo para el desarrollo, pero debido al tamaño de las bases de datos esto no se ha considerado una opción.

También estoy interesado en CÓMO se deben aplicar estos permisos. En oráculo, los permisos otorgados a través de un rol no están activos durante la ejecución de PL/SQL, por lo que los roles (incluso el rol "dba") no son útiles. Eso deja el uso de una cuenta integrada (sistema) o la creación de docenas de usuarios en docenas de bases de datos y otorgando directamente docenas de permisos a cada uno. En mi mente, simplemente dejar que los desarrolladores inicien sesión como sistema tiene mucho sentido, pero nuestros DBA afirman que es una mala idea.

Answer 1

Solíamos dar acceso a los desarrolladores a la cuenta de la aplicación. Esto funciona para las tiendas pequeñas, pero rápidamente se va de las manos a medida que aumenta el número de desarrolladores.

Aquí es lo que hacemos ahora:

1. la aplicación tiene en cuenta que es propia (también conocido como esquema).
2. Los desarrolladores tienen sus propias cuentas
3. datos residen en el esquema de aplicación
4. Tenemos un script de construcción Ant para construir código en cualquier esquema que desea.
   • código incluye vistas, paquetes, objetos, etc ..
   • la escritura de la estructura incluye un paso para ejecutar un procedimiento almacenado para conceder derechos explícitos a los desarrolladores a los datos de aplicación
5. desarrolladores hacer cambios en su propio esquema
6. Cuando estén contentos, comprueban que en subversión
7. El esquema de desarrollo de la aplicación se crea a partir de la nueva compilación de subversión.
8. Los desarrolladores pueden verificar y reconstruir sus propios entornos.
9. DDL cambios en la estructura de las tablas se realizan a través de la DBA
   • éstos puede ser escrito así

Esto tiene la ventaja de garantizar una aplicación front-end que no está roto por los desarrolladores de bases de datos en constante reconstruyendo todo.

Answer 2

Uno de los trabajos del DBA es administrar los privilegios del usuario. No creo que el sistema sea una buena idea por varias razones, entre otras, la posibilidad de descartar un esquema completo que estoy seguro que no desea. Una vez dicho esto, creo que está perfectamente bien otorgar todo a sus usuarios y permitir que los administradores de bases de datos administren estos permisos sin importar cuántas cuentas puedan haber. La mayoría de los DBA tendrán scripts que pueden usar para administrar estos permisos de todos modos.

Escuche a sus DBA, generalmente saben de lo que están hablando.

Answer 3

Si es solo una instancia de desarrollo; Quisiera que todos los usuarios tuvieran cuentas individuales agregadas al rol de administrador. De esta forma, aún puede registrar actividad por usuario; pero dales a los desarrolladores suficiente espacio para respirar para hacer lo suyo.

Answer 4

Supongo que hay un número relativamente pequeño de cuentas de aplicaciones que poseen los objetos reales. Entonces, una o más aplicaciones lógicas están compuestas por tablas propiedad de un usuario de Oracle en particular. Esto no sería hecho por SYSTEM o SYS, no sería ninguna de las cuentas que Oracle ofrece. Sería una cuenta creada por sus DBA. Si está familiarizado con los esquemas de muestra de Oracle, el usuario de recursos humanos posee todas las tablas en el esquema de recursos humanos que comprenden el back-end para una aplicación de recursos humanos.

Comenzando por el principio de "lo más simple que podría funcionar", lo primero que pensé fue ver si los desarrolladores podían iniciar sesión directamente en esas cuentas de aplicaciones. Esta no es la configuración más segura posible, y está abriendo la posibilidad de que un desarrollador accidental o intencionalmente haga algún daño que puede ser difícil de rastrear o resolver fácilmente. Pero puede funcionar razonablemente bien dependiendo de la organización. La administración de privilegios es trivial: la cuenta del propietario de la aplicación ya cuenta con todos los privilegios que más probablemente necesita. El siguiente paso sería proporcionar a cada desarrollador un esquema separado para desarrollar, presumiblemente junto con una carga de sinónimos públicos en la base de datos y una ausencia de calificadores de esquema en el código de la aplicación, de modo que cualquier objeto creado en el el esquema del desarrollador anula automáticamente la versión compartida de ese objeto. Esto proporciona un aislamiento mucho mejor. Generalmente, los permisos se otorgan creando scripts que contienen todas las concesiones que necesita un desarrollador o creando un script que copie todos los privilegios de una cuenta "conocida como buena" a la cuenta nueva. Ninguno de los dos es particularmente difícil de escribir, solo tienes que asegurarte de que todos los desarrolladores terminen con el mismo conjunto de privilegios, que generalmente es solo otro script que se ejecuta cuando se otorga un nuevo privilegio.

Answer 5

Mi grupo admite aproximadamente 100 aplicaciones, de las cuales 20 tienen su propio esquema de Oracle. Hemos seguido el camino de cada desarrollador que tiene la contraseña para el esquema y es conveniente. Sin embargo, en retrospectiva, recomendaría que cada desarrollador use su propia cuenta Oracle para desarrollar. La razón principal es la auditoría.

Answer 6

que reconocer que la mejor de los casos sería tienen cada Dev dirigir su propio ejemplo en su estación de trabajo para el desarrollo, pero debido al tamaño de las bases de datos esto no se ha considerado una opción.

¿Hay alguna manera de lidiar con esto, tal vez reduciendo la cantidad de datos en sus copias personales? Esta parece ser la solución ideal, ya que le permite hacer los cambios que necesita. Luego, puede enviarlos al DBA cuando esté listo y pedirle que actualice el servidor de desarrollo compartido.

Answer 7

Si está desarrollando objetos PL/SQL almacenados, entonces el esquema que posee esos objetos necesita, como usted mencionó, concesiones explícitas en los objetos utilizados. Si tiene un único esquema de 'datos' pero está desarrollando código en sus propios esquemas individuales, entonces debe tener la capacidad de otorgar acceso a los objetos del esquema de datos a sus esquemas de desarrollo. Normalmente esperaría nombre de usuario/contraseña para el esquema de datos.

Con respecto a los privilegios del sistema (por ejemplo, CREATE), esperaría CREATE TABLE, TYPE, VIEW, PROCEDURE TRIGGER, SYNONYM. Otros pueden ser apropiados (por ejemplo, CONTEXTO) dependiendo de lo que haga. El DBA puede descartar CREATE DIRECTORY, ya que podría ser dañino si se usa incorrectamente. Lo mismo ocurre con los privilegios con CUALQUIERA de ellos (por ejemplo, SELECCIONE CUALQUIER TABLA, BORRUE CUALQUIER TABLA)

Para la optimización del rendimiento/monitorización del sistema, en una base de datos de desarrollo, SELECT_CATALOG_ROLE es bueno. Si el DBA es reacio al riesgo, es posible que tenga que negociar concesiones en vistas individuales. Consulte la guía de REFERENCIA para su versión y solicite la que pueda usar.