Что полномочия должны Разработчики иметь в экземпляре базы данных Dev

Я предполагаю, что существует относительно небольшое количество учетных записей приложений, которым принадлежат фактические объекты. Таким образом, одно или несколько логических приложений состоят из таблиц, принадлежащих конкретному пользователю Oracle. Это не будет SYSTEM или SYS, это не будет ни одна из учетных записей Oracle, которые предоставляет компания. Это будет учетная запись, созданная вашими администраторами баз данных. Если вы знакомы с примерами схем Oracle, пользователь HR владеет всеми таблицами в схеме HR, которые составляют серверную часть приложения HR.

Исходя из принципа «простейшей вещи, которая могла бы работать», моя первая мысль заключалась в том, чтобы посмотреть, могут ли разработчики войти непосредственно в эти учетные записи приложений. Это не самая безопасная конфигурация, и вы открываете возможность того, что разработчик случайно или намеренно нанесет какой-либо ущерб, который может быть трудно отследить или легко устранить. Но это может работать достаточно хорошо в зависимости от организации. Управление привилегиями тривиально - учетная запись владельца приложения уже имеет все необходимые привилегии.

Следующим шагом будет предоставление каждому разработчику отдельной схемы для разработки, предположительно в сочетании с множеством общедоступных синонимов в база данных и отсутствие квалификаторов схемы в коде приложения, так что любой объект, созданный в схеме разработчика, автоматически переопределяет общую версию этого объекта. Это обеспечивает гораздо лучшую изоляцию. Разрешения обычно предоставляются либо путем создания сценариев, содержащих все разрешения, необходимые разработчику, либо путем создания сценария, который копирует все привилегии из «заведомо исправной» учетной записи в новую учетную запись. Ни то, ни другое не особенно сложно написать - вам просто нужно убедиться, что все разработчики имеют одинаковый набор привилегий, который обычно представляет собой просто еще один сценарий, запускаемый при предоставлении новой привилегии.

Одна из задач администратора базы данных - управление привилегиями пользователей. Я не думаю, что система - хорошая идея по нескольким причинам, не в последнюю очередь из-за возможности отбросить всю схему, что, я уверен, вам не нужно. При этом я думаю, что совершенно нормально предоставить все вашим пользователям и позволить администраторам баз данных управлять этими разрешениями, независимо от того, сколько десятков учетных записей может быть. У большинства администраторов баз данных есть сценарии, которые они могут использовать для управления этими разрешениями.

Послушайте своих администраторов баз данных, они обычно знают, о чем говорят.

Если это просто экземпляр разработчика; Я бы хотел, чтобы у всех пользователей были отдельные учетные записи, добавленные к роли администратора. Таким образом, вы по-прежнему можете регистрировать активность для каждого пользователя; но дайте разработчикам достаточно передышки, чтобы они могли делать свое дело.

Если вы разрабатываете хранимые объекты PL / SQL, то схема, владеющая этими объектами, требует, как вы упомянули, явных прав доступа к используемым объектам. Если у вас есть одна схема «данных», но вы разрабатываете код в своих индивидуальных схемах, вы должны получить возможность предоставлять доступ к объектам схемы данных для ваших схем разработки. Обычно я ожидаю имя пользователя / пароль для схемы данных.

Что касается системных привилегий (например, CREATE), я ожидал бы CREATE TABLE, TYPE, VIEW, PROCEDURE TRIGGER, SYNONYM. Другие могут быть подходящими (например, КОНТЕКСТ) в зависимости от того, что вы делаете. Администратор базы данных может исключить CREATE DIRECTORY, поскольку неправильное использование может нанести вред. То же самое для привилегий с ЛЮБОЙ в них (например, ВЫБРАТЬ ЛЮБУЮ ТАБЛИЦУ, УДАЛИТЬ ЛЮБУЮ ТАБЛИЦУ)

Для настройки производительности / мониторинга системы, в базе данных разработчика SELECT_CATALOG_ROLE - это хорошо. Если администратор базы данных не склонен к риску, вам, возможно, придется договариваться о грантах по отдельным представлениям. Просмотрите СПРАВОЧНИК для вашей версии и спросите, что вы можете использовать.

Моя группа поддерживает около 100 приложений, около 20 из которых имеют собственную схему Oracle. Мы пошли по пути, каждый разработчик имеет пароль к схеме и это удобно. Однако, оглядываясь назад, я бы порекомендовал каждому разработчику использовать свою учетную запись Oracle для разработки. Основная причина - аудит.

Я понимаю, что в лучшем случае пусть каждый разработчик запускает свой собственный экземпляр на своей рабочей станции для разработки, но из-за размера базы данных это не было учтено вариант.

Есть ли способ справиться с этим, возможно, уменьшив количество данных в ваших личных копиях? Это кажется идеальным решением, поскольку оно позволит вам вносить любые необходимые изменения. Затем вы можете отправить их администратору баз данных, когда будете готовы, и попросить его обновить общий сервер разработки.