oracle - para - manual de programacion android pdf

Qué permisos deberían tener los Desarrolladores en la instancia de la base de datos Dev

Question

... y cómo deberían 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 el mejor caso sería hacer que cada desarrollador ejecute 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 opinión, dejar que los desarrolladores inicien sesión como sistema tiene mucho sentido, pero nuestros DBA afirman que es una mala idea.

Answer 1

Reconozco que el mejor caso sería hacer que cada desarrollador ejecute 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.

¿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 2

Mi grupo admite aproximadamente 100 aplicaciones, de las cuales unas 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 de Oracle para desarrollar. La razón principal es la auditoría.

Answer 3

Si está desarrollando objetos PL / SQL almacenados, entonces el esquema que posee esos objetos necesita, como usted mencionó, concesiones explícitas en los objetos usados. 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, CREAR), esperaría CREAR TABLA, TIPO, VISTA, DISPARO DE PROCEDIMIENTO, SINÓNIMO. 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, BORRE CUALQUIER TABLA)

Para la optimización del rendimiento / supervisió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.

Answer 4

Si solo es 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 5

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 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.

Partiendo del principio de "lo más simple que podría funcionar", mi primer pensamiento sería 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 darle 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, para que cualquier objeto creado en el esquema del desarrollador anule 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 un desarrollador necesita 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 6

Uno de los trabajos del DBA es administrar los privilegios del usuario. No creo que el sistema sea una buena idea por algunas razones, entre otras, la posibilidad de descartar un esquema completo que estoy seguro que no deseas. 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 7

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.

Esto es lo que hacemos ahora:

1. la aplicación tiene su propia cuenta (también conocido como esquema).
2. Los desarrolladores tienen sus propias cuentas
3. Los datos residen en el esquema de la aplicación
4. Tenemos un script de construcción ant para construir código en cualquier esquema que desee.
   • el código incluye vistas, paquetes, objetos, etc.
   • el script de compilación incluye un paso para ejecutar un procedimiento almacenado para otorgar derechos explícitos a los desarrolladores sobre los datos de la aplicación
5. Los desarrolladores hacen cambios en su propio esquema
6. Cuando están contentos lo verifican en subversión
7. El esquema de desarrollo de la Aplicación se construye a partir de la nueva compilación de subversión.
8. Los desarrolladores pueden verificar y reconstruir sus propios entornos.
9. Los cambios de DDL a las estructuras de la tabla se realizan a través del DBA
   • estos pueden ser guionados también

Esto tiene el beneficio de garantizar que cualquier aplicación de front-end no se rompa por los desarrolladores de bases de datos constantemente reconstruyendo todo.