Actian Vector

Материал из Национальной библиотеки им. Н. Э. Баумана
Последнее изменение этой страницы: 15:45, 1 марта 2019.
Actian Vector
Разработчики: Actian Corporation
Выпущена: 2016; 3 years ago (2016)
Постоянный выпуск: 5.0 / 1 July 2017 года; 22 months ago (2017-07-01)
Операционная система: Кросс-платформенная
Тип ПО: Реляционная СУБД
Лицензия: Проприетарная
Веб-сайт actian.com

Actian Vector (ранее известный как VectorWise) представляет собой систему управления реляционными базами данных SQL, предназначенную для высокой производительности в аналитических приложениях баз данных. Он опубликовал результаты рекордных результатов в тесте TPC-H Совета по эффективности транзакций для баз данных размером 100 ГБ, 300 ГБ, 1 ТБ и 3 ТБ на некластеризованном оборудовании. [Источник 1]

Описание

Vectorwise возник из исследовательского проекта X100, проведенного в Centrum Wiskunde & Informatica (CWI, Нидерландский национальный научно-исследовательский институт математики и информатики) в период с 2003 по 2008 год. Он был выделен в качестве стартовой компании в 2008 году и приобретен Ingres Corporation в 2011 году. Он был выпущен как коммерческий продукт в июне 2010 года, изначально для 64-битной платформы Linux, а позднее и для Windows. Начиная с версии 3.5 в апреле 2014 года название продукта было сокращено до «Вектор». В июне 2014 года объявлен Actian Vortex - кластерная версия MPP Vector, работающая в Hadoop [Источник 2] с хранением в HDFS.

Компании и организации признают необходимость анализа данных для принятия мер будь то данные, генерируемые бизнес-процессами или общедоступными данными. Компании и организации создают хранилища данных и магазины данных в реляционных базах данных для хранения и анализа терабайт данных - Big Data.

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

Actian Vector - реляционная база данных для анализа данных. Actian Vector использует возможности современных процессоров архитектуры x86, чего большинство других реляционных баз данных не достигли. В результате Actian Vector может обрабатывать данные гораздо быстрее, чем большинство других реляционных баз данных. Большая производительность открывает широкие возможности. Можно представить не только поддержку большого объема данных, количества пользвателей и более крупные нагрузки, но и возможность непосредственно запрашивать детальные данные, что раньше было возможно только после обширной индексации и материализации промежуточных результатов. Большая производительность значительно уменьшает количество времени задержки ожидания результатов и повышает гибкость доступа к данным.

Кроме того, Actian Vector позволяет выполнять рабочую нагрузку на сервере, когда другим базам данных требуется для этого большее аппаратное обеспечение, кластер серверов или и то, и другое. Вы можете мгновенно сократить расходы, используя Ваше оборудование более эффективно, также Вам не потребуется искать узких специалистов для настройки системы.

Особенности

Уникально эффективное использование процессора

Actian Vector уникален тем, что он использует преимущества мощных функций процессора, чего большинство других баз данных не делает. За последние три десятилетия увеличение мощности процессоров подчинялась закону Мура. Однако на сегодняшний день улучшения в производительности обработки данных ЦП не являются следствием увеличения тактовой частоты и количества транзисторов на чипе. Производители предоставляют дополнительные решения, такие как многоядерные процессоры и многопоточность, которые используются в большинстве баз данных.

Есть, однако, другие оптимизации, которые были введены в последнее десятилетие, которые как правило, не используют большинство баз данных. Примеры включают так называемые инструкции SIMD 2, более большие кэши, супер-скалярные функции, out-of-order исполнение. На самом деле, большинство современных баз данных, которые были первоначально написаны в 1970-х или 1980-х годах стали настолько сложными, что для того, чтобы использовать преимущество этих решений потребуется полная перепись программного обеспечения баз данных.

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

Использование единичного потока инструкции для множественного потока данных. (SIMD)

SIMD - принцип компьютерных вычислений, позволяющий обеспечить параллелизм на уровне данных. Actian Vector использует преимущество simd-инструкции обработки векторов данных, SIMD расширения набора команд. Поскольку типичные запросы анализа данных обрабатывают большие объемы данных, использование SIMD может привести к уменьшению среднего времени обработки единицы данных. На уровне ЦП традиционные базы данных обрабатывают данные по одному кортежу за раз, тратя большую часть времени ЦП время на накладные расходы на управление кортежами, а не на фактическую обработку. В отличие от них, Actian Vector обрабатывает векторы сотен или тысяч элементов одновременно, что эффективно устраняет эти накладные расходы. В результате ресурсы процессора используются для выполнения фактической работы.

Использование кэш-памяти процессора как исполняемой памяти

Большинство улучшений памяти сервера баз данных (ОЗУ) за последние несколько лет привели к увеличению пулов памяти, но не обязательно к ускорению доступа к памяти. В результате, по сравнению с постоянно возрастающей тактовой частотой процессора, доступ к памяти со временем становится медленнее и медленнее. Кроме того, с увеличением количества процессорных ядер, требующих доступ к общему пулу памяти, разногласия могут быть узким местом для производительности обработки данных.

Для того, чтобы достичь максимальной производительности обработки данных, Actian Vector избегает использования общей оперативной памяти как памяти выполнения. Вместо этого Actian Vector использует собственный процессор ядра и процессор кэша как памяти выполнения, обеспечивая значительно большую пропускную способность обработки данных.

Использование возможностей производительности ЦП

На постоянной основе команда разработчиков Actian Vector ищет пути улучшения производительности обработки данных с использованием современной чип-технологии. Например, последние чипы Intel® поддерживают аппаратное ускорение строковых операций, которые используются в Actian Vector. Операции, которые извлекают выгоду из аппаратно-ускоренной оптимизации на основе строк. Однако не все современные процессоры поддерживают аппаратное ускорение на основе строковых операций и Actian Vector также отлично работает, пусть чуть менее оптимально, если эта функция недоступна.

Использование лучших отраслевых практик

Различные специализированные продукты баз данных используют ряд известных методов для достижения высокой производительности. В общем, из-за интенсивного характера нагрузки хранилищ данных, большинство методов направлены на ограничение и оптимизацию ввода/вывода (IO).

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

Колонко-ориентированное хранилище

Когда было впервые написано программное обеспечение реляционной базы данных, оно реализовывало хранилище на основе строки: все значения данных для строки хранятся вместе в блоке данных (страница). Данные всегда извлекается по строкам, даже если запрос обращается только к подмножеству столбцов. Эта модель хранения работает очень хорошо для онлайн систем обработки транзакций (OLTP), в которых данные высоко нормализованы, таблицы относительно узкие, запросы часто извлекают очень мало строк.

хранилища данных различны:

  • Большинство запросов получают много строк.
  • Таблицы часто (частично) денормализованные в результате большого количества столбцов, не все из которых доступны большинству операций

Данные добавляются посредством управляемого, а не специального процесса, и часто большие наборы данных добавляется сразу или через постоянный (контролируемый) поток данных.

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

Базы данных на основе столбцов доступны уже более десяти лет. К тому же в интересах устранения данных при доступе к менее чем всем столбцам таблицы в запросе, дополнительным значительным преимуществом хранилища на основе столбцов является лучшее сжатие данных.

Установка Actian Vector

Установка Actian Vector для Windows

Вы должны извлечь загруженный дистрибутив на диск и запустить установщик из извлеченной директории. Вы устанавливаете Actian Vector для Windows с помощью мастера настройки. Чтобы узнать больше о параметре в мастере настройки, нажмите на кнопку информации. Установка Actian Vector для Windows с помощью мастера установки:

1. Запустите исполняемый файл установки, расположенный в корневом каталоге распределения Vector: настроить. Отобразится первая страница мастера установки.

2. Нажмите «Далее». Откроется диалоговое окно лицензии.

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

4. Выберите «Экспресс» и нажмите «Далее». Отобразится страница выбора компонентов.

5. Выберите «Типичный сервер» и нажмите «Далее». Отобразится страница «Готовность установки Actian Vector». Поскольку мы выбрали режим экспресс-установку, используются значения по умолчанию для всех параметров установки.

6. Нажмите «Установить». Программа установки устанавливает и настраивает Actian Vector. Отобразится страница «Конфигурация Actian Vector».

7. Нажмите «Далее». Установка завершена. Отобразится сводка об установке.

8. Нажмите «Готово».

Установка Actian Vector для Linux

Actian Vector для Linux распространяется в формате RPM, DEB и без пакета (ingbuild).

Установить libaio

Перед установкой Actian Vector необходимо установить библиотеку Linux Asynchronous I / O, libaio. Libaio имеет огромное преимущество в производительности над стандартным асинхронным вводом-выводом POSIX, поскольку операции выполняются в ядре Linux, а не как отдельный процесс пользователя. Примечание. Установщик Actian Vector может установить libaio автоматически или пометить его как отсутствующий, в зависимости от загруженного вами дистрибутива Actian Vector. Чтобы установить libaio Использование RPM:

rpm ‑ivh libaio*.rpm

Использование инструмента обновления системы yum:

yum install libaio

Использование Ubuntu:

 apt-get update
 apt-get install libaio1

Импортировать открытый ключ GPG (только RPM и DEB). Пакеты RPM и DEB подписываются с помощью пары ключей GPG для обеспечения их подлинности. Чтобы включить процесс установки для проверки пакетов, открытый ключ необходимо загрузить и импортировать в систему управления пакетами. Файл открытого ключа GPG можно загрузить из того же места, что и дистрибутив: http://esd.actian.com/. Импорт ключа Укажите имя файла ключа в соответствующей команде. Например: Использование RPM:

rpm --import actian-vector-3.5.0-330-NPTL-com-linux-rpm-x86_64-key.asc

Использование Ubuntu:

 apt-key add actian-vector-3.5.0-330-NPTL-com-linux-deb-amd64-key.asc

Руководство по безопасности

Функции безопасности

Защита данных является проблемой для всех. Необходимость обеспечения безопасности личной информации и защиты жизненно важных корпоративных активов, хранящихся в электронном виде, имеет первостепенное значение. Actian Vector имеет встроенную иерархическую систему безопасности, которую любой привилегированный пользователь может использовать для полного контроля доступа к базе данных. Безопасность в Actian Vector обеспечивается следующими функциями:

  • Разрешения для каталогов и файлов
  • Пользовательские функции безопасности, в том числе:

- Пользователи - Группы - Роли - Профили - Субъективные привилегии

  • Разрешения для объекта
  • Охранные сигнализации
  • Аудит безопасности
  • Шифрование данных в режиме покоя

Уровень безопасности

Экземпляры Actian Vector можно администрировать в соответствии со стандартом безопасности C2, как это определено Национальным советом компьютерной безопасности США (NCSC). Безопасность уровня C2 требует индивидуального входа с паролем и механизма аудита.

Понимание механизмов безопасности Actian Vector

Вектор предоставляет множество методов защиты. Метод по умолчанию - аутентификация СУБД.

  • Методы контроля доступа, которые включают Kerberos и аутентификацию пользователя
  • Методы аутентификации пользователей, которые включают аутентификацию СУБД, механизм INGRES и механизм NULL
  • Методы шифрования, которые включают Kerberos и AES.

1)Kerberos

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

2)Аутентификация СУБД

(По умолчанию) Позволяет аутентифицировать пользователей СУБД и пароли, определенные в установке, без использования каких-либо внешних механизмов безопасности ОС. Сервер СУБД обеспечивает аутентификацию.

3)Механизм INGRES

Позволяет аутентифицировать пользователя в операционной системе.

4)NULL-механизм

Позволяет пользователям проходить аутентификацию без предоставления паролей или других типов аутентификации. Использование механизма Null безопасности настоятельно не рекомендуется.

5)AES

Обеспечивает шифрование сетевого потока данных между сервером СУБД и клиентом. Этот механизм не обеспечивает аутентификацию пользователя. AES является динамическим механизмом, поскольку он использует библиотеки шифрования ОС и загружается в исполняемый образ Actian Vector во время выполнения. За исключением проверки подлинности СУБД, все эти методы выполняются до подключения к серверу СУБД. Механизмы NULL, INGRES, KERBEROS и AES перечислены в компоненте Security в Configuration-By-Forms (или Configuration Manager, если доступно). Резервирование по умолчанию для механизмов безопасности редко необходимо изменить. Одновременно поддерживаются несколько механизмов. Метод аутентификации СУБД контролируется в разделе «Конфигурация по видам», компоненте сервера СУБД, dbms_authentication.

Разрешения доступа к каталогам и файлам

Базы данных защищены от доступа пользователей разрешениями доступа к каталогам, содержащих файлы базы данных, и разрешениями доступа к файлам базы данных. Пользователи не могут просматривать файлы в базе данных, кроме как через Actian Vector. Даже в Actian Vector файлы защищены от доступа, за исключением привилегированных учетных записей. Бинарные файлы имеют особый формат, что затрудняет декодирование любой информации.

Аутентификация пользователя

Для каждого пользователя Actian Vector пользовательский объект должен быть определен в основной базе данных. Actian Vector аутентифицирует пользователей:

  • Через учетную запись операционной системы и пароль, которые должны соответствовать определению пользовательского объекта в основной базе данных. Дополнительные пароли также могут быть установлены для пользователей и ролей.

или

  • Непосредственно через сервер СУБД, в котором имя пользователя и пароль должны соответствовать определению пользовательского объекта в основной базе данных. Этот метод известен как аутентификация СУБД. Если для сервера включена функция DBMS_AUTHENTICATION, пользователь не должен быть определен как пользователь операционной системы.

Удаленные пользователи

Ingres Net обеспечивает доступ к базам данных на локальных или удаленных узлах. Пользователи могут получать доступ только к данным, для которых они авторизованы. Ingres Net можно настроить так, чтобы пользователи могли напрямую обращаться к удаленным узлам (через пароль установки) или указав имя пользователя и пароль. Имя пользователя и пароль могут быть аутентифицированы СУБД (если сервер имеет аутентификацию СУБД) или против учетной записи пользователя локальной ОС. Пароль зашифровывается, поскольку он отправляется по сети.

Установка паролей

Ingres Net позволяет настроить установочный пароль для авторизации доступа к установке сервера с удаленной клиентской установки без настройки учетной записи операционной системы на сервере; пользователь сохраняет свою личность, определенную на экземпляре клиента. Основное преимущество использования паролей установки заключается в том, что пользователям на клиенте не требуется учетная запись на сервере. Действительный пользовательский объект должен быть создан в основной базе данных с использованием того же идентификатора пользователя операционной системы, что и на удаленном клиенте. Аутентификация ОС выполняется на удаленном клиенте, где пользователь должен иметь логин и пароль.

Утилита ingvalidpw (Linux)

В некоторых средах Actian Vector использует программу ingvalidpw для проверки паролей пользователей. Ingvalidpw используется в зависимости от требований платформы, на которой проверяется пароль. Например, сервер СУБД использует программу ingvalidpw для проверки теневых паролей в Linux или для обеспечения безопасности C2 в некоторых средах Linux. Ingvalidpw используется для аутентификации пользователей ОС; он не используется, когда включена проверка подлинности СУБД.

Аутентификация СУБД

Actian Vector позволяет аутентификацию уровня СУБД в дополнение к другим поддерживаемым методам (включая проверку подлинности операционной системы, установочные пароли и проверку подлинности Kerberos). Функция аутентификации СУБД устраняет необходимость добавления пользователя операционной системы каждый раз, когда новому пользователю требуется доступ к базе данных. Пользователь, который соответствующим образом определен в базе данных, может получить доступ к базе данных, используя действительное имя пользователя и пароль пользователя. Пользователь не должен определяться на уровне операционной системы или в глобальном каталоге.

Аутентификация СУБД должна быть включена для сервера СУБД, на котором находится база данных. Он по умолчанию включен (dbms_authentication = on в config.dat). Такая аутентификация может быть включена только на уровне сервера, а не на уровне базы данных.

Администраторы баз данных могут настраивать аутентификацию СУБД для каждого пользователя, используя новые опции WITH в операторах CREATE USER и ALTER USER или с помощью Actian Director или accessdb. Пользователь может быть определен в инструкции CREATE USER либо с помощью DBMS_AUTHENTICATION = 'REQUIRED', либо с помощью DBMS_AUTHENTICATION = 'OPTIONAL' (по умолчанию). Пользователь, который определен с помощью DBMS_AUTHENTICATION = 'REQUIRED', должен подключиться к базе данных, используя его имя и пароль пользователя СУБД. Все другие попытки подключения не состоятся. Такой пользователь не может подключиться к серверу, настроенному как dbms_authentication = no.

Пользователи системного администрирования должны быть определены как DBMS_AUTHENTICATION = 'OPTIONAL.' Все пользователи с привилегией «security», включая владельца установки, вынуждены быть DBMS_AUTHENTICATION = 'OPTIONAL'. Если пользователь создан или изменен с помощью DBMS_AUTHENTICATION = 'REQUIRED', пользователь должен также иметь пароль СУБД или выдается ошибка. Пользователь, не имеющий пароля СУБД, может подключаться к серверам с поддержкой dbms_authentication только через локальное соединение, пароль установки или проверку подлинности Kerberos.

Пользователи могут устанавливать и изменять свои собственные пароли СУБД, если у них есть привилегия CHANGE_PASSWORD (по умолчанию). Пароли СУБД зашифровываются на диске и передаются по сети. Аутентификация СУБД обратно совместима. Более старый удаленный клиент будет работать с новыми удаленными серверами с поддержкой dbms_authentication, предполагая, что пароль СУБД (определенный оператором CREATE USER и хранящийся в каталоге iiuser) совместим с паролем vnode.

Когда существующая версия СУБД обновляется, существующие определения пользователей изменяются до DBMS_AUTHENTICATION = 'OPTIONAL'.

Идентификаторы авторизации

Доступ может быть предоставлен четырем идентификаторам авторизации. Идентификаторы перечислены здесь от наивысшего до самого низкого приоритета, который определяет привилегию, применяемую для сеанса, если определенная привилегия определена для более чем одного идентификатора авторизации, связанного с сеансом.

  • Роль

Роли упрощают доступ к базе данных, связывая права пользователя и разрешения с приложением. Роли можно создать с помощью дополнительного пароля. Параметр EXTERNAL_PASSWORD позволяет передавать пароль роли на внешний сервер аутентификации для аутентификации.

  • Пользователь

Для каждого действительного пользователя Actian Vector пользовательский объект должен быть создан в базе данных iidbdb. Пользовательский объект указывает имя пользователя, группу по умолчанию, профиль по умолчанию, права субъекта и другие атрибуты.

  • Группа

Группы упрощают управление разрешениями, поскольку отдельные пользователи могут быть добавлены или удалены из групп по мере необходимости. Являясь членом группы, вы автоматически не предоставляете пользователям разрешения, предоставленные группе. Пользователь должен иметь группу, указанную как группа по умолчанию, или указать имя группы при запуске сеанса.

  • Общественный

Предоставление разрешений на объекты в PUBLIC позволяет любому пользователю, группе или ролевому доступ к этим объектам. Количество пользователей для PUBLIC должно быть ограничено.

Субъектные привилегии

Субъектные привилегии определяют операции, которые пользователь может выполнять, и назначаются пользователю или роли. Субъектные привилегии включают в себя: Аудитор, Создать базу данных, Ведение аудита, Ведение контактов, Ведение пользователей, Оператор, Безопасность и Трассировка.

Разрешение доступа к объекту

Доступ к данным может быть ограничен путем предоставления разрешений на объекты. Разрешения могут предоставляться по следующим объектам: база данных, таблица, представление, процедура, событие базы данных, роль и текущая установка.

Сигнализация безопасности

Предупредительные сигналы тревоги могут быть настроены для мониторинга событий по базе данных или отдельным таблицам. Такие триггеры для важных баз данных и таблиц полезны при обнаружении несанкционированного доступа. Сигналы безопасности могут отслеживать успех или отказ подключения или отключения от базы данных, а также выбор, удаление, вставку или обновление данных в таблице. Аварийные сигналы безопасности могут вызвать событие базы данных (dbevent), которое может контролироваться фоновыми программами. Сигналы безопасности могут быть назначены определенным идентификаторам авторизации, чтобы ограничить мониторинг выбранными пользователями, группами или ролями.

Аудит безопасности

События безопасности могут быть определены для всей версии Actian Vector. Все объекты или определенные классы объектов могут быть целью. Информация в журналах аудита может быстро расти, поэтому вы должны тщательно планировать, какие события следует назначать для аудита.

Процедуры базы данных

Процедуры базы данных обеспечивают дополнительный уровень контроля за доступом и модификацией данных. Процедуры базы данных могут использоваться с сигналами безопасности для усиления контроля безопасности.

Шифрование данных в режиме останова

Конкретные столбцы таблицы базы данных могут быть зашифрованы для повышения безопасности данных, обеспечения конфиденциальности и защиты носителей, содержащих записи базы данных, содержащие конфиденциальную информацию. Данные в защищенных столбцах хранятся на диске или другом носителе в зашифрованном виде и могут быть доступны только в том случае, если кодовая фраза шифрования известна. Шифрование данных в режиме останова защищает информацию таблицы, информацию о транзакции и полное резервное копирование базы данных.

Авторизация доступа пользователя

Типы пользователей Actian Vector В большинстве установок существует четыре типа пользователей:

  • Владелец установки

Владелец установки обычно является учетной записью с именем «actian», но имя actian не требуется. По умолчанию у этого пользователя есть привилегия безопасности и большинство других привилегий. Однако некоторые привилегии могут быть отменены у этого пользователя, и система будет работать корректно. В хорошей производственной системе этот пользователь выполняет только административные задачи в системе (например, запуск и завершение работы).

  • Системный администратор

Системный администратор иногда является «корневой» учетной записью. Эта учетная запись обычно принадлежит отделу информационных технологий (ИТ), но также обычно принадлежит пользователю, который был определен как администратор системы. В большой производственной среде может быть один или несколько из этих пользователей. У этих пользователей есть привилегия безопасности, которая позволяет им использовать флаг -u для команд для имитации других пользователей и обычно имеет другие привилегии, такие как maintain_locations и maintain_users; если включен аудит безопасности, они также, как правило, имеют привилегии maintain_locations и maintain_users. Ответственность этого пользователя заключается в выполнении административных задач, которые влияют на весь экземпляр Actian Vector, например, на создание и уничтожение пользователей Actian Vector, что позволяет Actian Vector использовать новые дисковые накопители и отслеживать журналы аудита безопасности Actian Vector. В небольших средах системный администратор и владелец установки могут быть одним и тем же пользователем.

  • Администратор базы данных (DBA)

Администратор базы данных обычно имеет только привилегию Createdb. Администраторы баз данных могут использовать флаг -u только в своих собственных базах данных. Как правило, администратор баз данных не является владельцем копии продукта и в хорошей производственной системе не имеет привилегий безопасности. Определение первичного DBA для любой данной базы данных - это пользователь, который запустил команду createdb для создания этой базы данных. Дополнительные администраторы баз данных могут быть определены для базы данных, предоставив привилегию db_admin для этой базы данных.

  • Конечный пользователь

Конечный пользователь обычно не имеет никаких прав и не может создать базу данных.

Как установить пользовательский доступ

По умолчанию Actian Vector использует аутентификацию СУБД для доступа пользователя. Процесс установки доступа к Vector выглядит следующим образом:

1. (Необязательно) Системный администратор определяет учетные записи пользователей в операционной системе. Учетные записи необходимы для локальных пользователей и для удаленных пользователей, которые обращаются к продукту через локальную учетную запись. Примечание. Этот шаг является необязательным:

  • Если пароль установки определен, и в этом случае пользователь обращается к Actian Vector напрямую, без необходимости проходить через локальную учетную запись.
  • Для удаленных пользователей, если сервер СУБД настроен на использование аутентификации СУБД. (Это значение по умолчанию для Actian Vector.)

Учетные записи могут быть установлены до или после установки Actian Vector (за исключением учетной записи владельца установки, которая настроена во время установки, принадлежит системному администратору и ей назначены максимальные привилегии для выполнения всех операций).

2. Администратор базы данных определяет объекты пользователя. Администратор базы данных или системный администратор запускает Actian Vector и определяет объекты пользователя. Часть определения пользовательского объекта - это идентификатор пользователя. Если используется проверка подлинности ОС, идентификатор пользователя должен соответствовать идентификатору пользователя, используемому для входа в операционную систему. Как правило, системный администратор настраивает пользовательский объект для администратора базы данных, который, в свою очередь, настраивает пользовательские объекты для других пользователей.

Пользователи и профили

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

Работа с объектами пользователя

Вы можете выполнять следующие основные операции с объектами пользователя:

  • Создание и изменение пользовательских объектов
  • Просмотр существующих пользовательских объектов, включая подробные свойства каждого объекта
  • Отбрасывать объекты пользователя

Эти задачи могут быть выполнены с помощью Actian Director, VDBA или утилиты на основе форм accessdb. В SQL вы можете использовать инструкции CREATE USER, ALTER USER и DROP USER при работе в сеансе, подключенном к базе данных iidbdb.

   Примечание. Многие функции, связанные с объектом пользователя, такие как права субъекта, пароль, дата истечения срока действия и аудит безопасности, являются связанными с безопасностью функциями, описанными далее в этом руководстве.

Создание нового пользователя с помощью Accessdb

У вас должно быть разрешение maintain_users для авторизации пользователей. Используя утилиту accessdb, вы можете добавлять, изменять или удалять пользователей и предоставлять им разрешения доступа к базе данных. Чтобы авторизовать нового пользователя:

1. Запустите accessdb, выпустив следующую команду в командной строке операционной системы:

  accessdb

Появится главное меню accessdb.

2. Выберите «Пользователи» из главного меню accessdb. Появится экран «Каталог пользователей».

3. Выберите «Создать». Появится экран «Создать пользователя».

4. Введите информацию о пользователе в следующие поля:

  • Имя пользователя

Имя пользователя. Имя может быть регулярным или ограниченным идентификатором. Например, чтобы использовать числовой идентификатор пользователя, имя должно быть ограничено (заключено в двойные кавычки, как в «888282»). (Подробнее о разделительных идентификаторах см. Справочное руководство по SQL.)

  • Профиль для пользователя

(Необязательно) Профиль по умолчанию для пользователя.

  • Группа по умолчанию

(Необязательно) Группа по умолчанию (см. Группы), которой назначен пользователь.

  • Срок действия до

(Необязательно) Дата истечения срока действия пользователя (см. Дата истечения срока действия пользователя). Примечание. После сохранения пользовательского определения вы можете назначить пароль пользователя (см. User Password). Пароль пользователя является необязательным, если пользователю не потребуется проверка подлинности СУБД.

5. В разделе «Разрешения» измените настройки прав пользователя по умолчанию для пользователя, введя вкладку в нужное поле и введя соответствующее значение: Y Предоставляет привилегию N Отменяет привилегию р

6. В меню выберите «Сохранить». Запись пользователя сохраняется.

7. Повторите шаги 3-6 для каждого нового пользователя, которого вы хотите добавить.

8. Выберите «Конец» дважды. Вы вернетесь в главное меню accessdb.

9. Выберите «Выйти».

   Примечание. Если вы не видите функцию «Выход», нажмите ESC, чтобы просмотреть параметры меню.

Утилита accessdb заканчивается.

Дата истечения срока действия пользователя

Дата истечения срока действия пользователя является необязательной частью определения пользователя. Он определяет дату, после которой пользователь больше не может обращаться к Actian Vector. Дата истечения срока действия может быть указана как любая действительная дата Actian Vector или как дата или временной интервал. Например, вы можете указать интервал «1 месяц» или «1 год» или абсолютную дату, например «5-ян-2007». Дата истечения срока действия пользователя проверяется каждый раз, когда пользователь подключается к серверу СУБД. Если дата истечения срока действия прошла, доступ запрещен. Чтобы включить пользователя с истекшим сроком действия, связанный объект (или профиль) должен быть изменен для сброса даты истечения срока действия.

Пользовательский пароль

Пароль может быть указан как часть пользовательского определения. Использование пароля зависит от того, включена ли проверка подлинности СУБД. Если он включен, имя пользователя и пароль, предоставленные попыткой подключения, должны совпадать с этим именем пользователя и паролем. Если пароль не указан приложением подключения, попытка удаленного подключения не удалась. Локальная попытка подключения без пароля будет успешной, если предположить, что пользователь не был определен с помощью DBMS_AUTHENTICATION = 'REQUIRED'. Если аутентификация СУБД не включена, пароль СУБД работает как второй уровень пароля после установления первоначального соединения (с использованием настроенного механизма безопасности GCF, такого как проверка подлинности на пользователя ОС и пароль). В этом случае приложение отправляет пароль СУБД в открытом виде, после установления соединения. Если ни один пароль СУБД не предоставлен приложением, сервер СУБД просит библиотеки клиентов запрашивать один, если это возможно; или, попытка подключения не выполняется, если запрос невозможен. Когда сеанс требует пароля, а один не указан, запрос запрашивает пароль. По соображениям безопасности приглашение пароля выдается, если отсутствует требуемый пароль или имя пользователя неизвестно или незаконно. Это поведение совместимо с операционными системами во время входа в систему.

   Примечание. Если пользователь с привилегией безопасности запускает сеанс с использованием флага -u для олицетворения другого пользователя, требуется пароль реального пользователя - а не злоумышленник.
   Пользователю с привилегией Change_Password разрешено изменять свой собственный пароль; однако для этого он должен предоставить свой старый пароль. Пользователь с привилегией maintain_users может изменить пароль другого пользователя, в дополнение 
   к изменению метода проверки пароля или вообще удалению пароля.
   Примечание. Пароли также применяются к ролям.

Авторизация нескольких пользователей с помощью SQLscript

Используя accessdb, вы можете создать файл пользователей при установке и соответствующие разрешения. Этот файл полезен для копирования установок. Чтобы создать файл пользователей:

1. В главном меню accessdb выберите «Пользователи». Появится экран «Каталог пользователей».

2. Выберите пункт меню SQLscript. Утилита accessdb создает SQL-скрипт и отображает сообщение SQLscript, указывающее местоположение файла.

3. Нажмите Return. Сообщение очищается от экрана.

4. Выберите «Конец».

   Примечание. Если вы не видите перечисленную функцию End, нажмите ESC, чтобы просмотреть параметры меню.
   Вы вернетесь в главное меню accessdb.
   Примечание. Функция SQLscript создает только пользователей, а не профили, группы или роли, связанные с каждым пользователем. Роли и группы должны быть выгружены и перезагружены для сценария для генерации ожидаемых результатов.

Работа с объектами профиля

Вы можете выполнять следующие основные операции над объектами профиля:

  • Создание и изменение объектов профиля
  • Просмотр существующих объектов профиля, включая подробные свойства каждого объекта
  • Объекты профиля

В SQL вы можете использовать инструкции CREATE PROFILE, ALTER PROFILE и DROP PROFILE при работе в сеансе, подключенном к базе данных iidbdb. Вы можете работать с объектами профиля в Actian Director и VDBA.

Пример использования профиля

После создания профиля он может быть связан с новым или существующим пользовательским объектом в качестве профиля по умолчанию для этого пользователя. Таким образом, атрибуты, определенные в профиле, связаны с пользователем, а атрибуты пользователя обновляются каждый раз, когда профиль изменяется.

Атрибуты также могут быть установлены непосредственно на уровне пользователя, чтобы переопределить настройки на уровне профиля. Например, компания проводит анализ задач и обязанностей своих операторов базы данных на нескольких сайтах. Они находят три задачи, общие для этого типа пользователей: обслуживание базы данных и файлов, отладка и резервное копирование базы данных. Они создают профиль для поддержки баз данных, называемых dbop (оператором базы данных), с соответствующими правами субъекта:

  • maintain_locations
  • trace
  • operator

Всякий раз, когда компания нанимает нового оператора базы данных, администратор базы данных может связать профиль dbop с этим новым пользователем. Выполнение этого автоматически присваивает пользователю права на обслуживание, отслеживание и операторские привилегии.

Если компания изменяет профиль dbop, включив в него привилегию maintain_users, это изменение автоматически влияет на любого пользователя, использующего данный профиль. Поскольку в профиле dbop не указана опция для проверки текста запроса, связанного с пользовательскими запросами, пользователи, связанные с этим профилем, не проверяются для текста запроса. Чтобы проверить текст запроса только для одного из пользователей, связанных с профилем dbop, этот параметр можно включить на уровне пользователя (с помощью инструкции ALTER USER). Это переопределяет значение по умолчанию для этого конкретного пользователя, не затрагивая других пользователей профиля dbop.

Профиль по умолчанию

Профиль по умолчанию - это профиль, первоначально назначенный пользователю, если он явно не назначен. Профиль по умолчанию определяет следующее:

  • Нет группы по умолчанию
  • Отсутствие прав пользователя или привилегий по умолчанию
  • Отсутствие срока годности
  • Нет параметров аудита безопасности (то есть события по умолчанию проверяются)

Заметки:

  • Вы можете изменить профиль по умолчанию, но вы не можете его удалить.
  • Изменение профиля по умолчанию изменяет атрибуты привилегий для всех пользователей, которым не был предоставлен конкретный профиль.

Вы можете изменить профиль по умолчанию, используя инструкцию ALTER DEFAULT PROFILE, Actian Director или VDBA.

Группы и роли

Группы и роли могут упростить управление доступом к базе данных. Группы используются для применения разрешений к списку пользователей, в то время как роли используются для связывания прав и прав субъекта с приложением.

Группы

Группа - это идентификатор, который может использоваться для применения разрешений к списку пользователей, связанных с идентификатором. Группа позволяет нескольким пользователям ссылаться на одно имя.

   Например, у компании есть учетная группа для идентификации сотрудников бухгалтерии в целом и группы расчета заработной платы для определения сотрудников отдела заработной платы в целом. Чтобы определить эти группы, администратор баз данных создает группы и добавляет всех пользователей в соответствующие отделы в свои соответствующие группы. Группы можно легко поддерживать, добавляя и отбрасывая пользователей, когда они присоединяются или покидают отделы.

Примечание. Пользователь может быть членом более чем одной группы.

Работа с объектами группы

Вы можете выполнять следующие основные операции над объектами группы:

  • Создание и изменение объектов группы
  • Просмотр существующих объектов группы, включая подробные свойства каждого отдельного объекта
  • Объекты группы снизу

В SQL вы можете выполнить эти задачи с помощью операторов CREATE GROUP, ALTER GROUP и DROP GROUP при работе в сеансе, подключенном к базе данных iidbdb. Вы также можете работать с объектами группы с помощью Actian Director и VDBA.

   Пример: создание, изменение и удаление группы с использованием операторов SQL

Чтобы создать новую группу, укажите определяемый пользователем идентификатор группы в инструкции CREATE GROUP, а затем укажите пользователей в группе в предложении WITH USERS. Группа может быть изменена позже с помощью ADD USERS или DROP USERS в отношении предложения ALTER GROUP. Группу можно удалить с помощью оператора DROP GROUP. Вот примеры использования операторов CREATE GROUP, ALTER GROUP и DROP GROUP:

1. Создайте идентификатор группы для службы продаж телефона компании и поместите идентификаторы пользователей продавцов в список пользователей группы:

CREATE GROUP tel_sales
   WITH USERS = (harryk, joanb, jerryw, arlenep);

2. Создайте идентификатор группы and_muchmuchmore и зарезервируйте его для последующего использования. Это делается путем исключения предложения WITH USERS:

CREATE GROUP and_muchmuchmore;

3. Добавьте двух пользователей в группу tel_sales и оставьте трех пользователей. Добавление и отбрасывание должно выполняться в отдельных операторах ALTER:

ALTER GROUP tel_sales
   ADD USERS (dannyh, helent);
ALTER GROUP tel_sales
   DROP USERS (harryk, joanb, arlenep);

4. Отбросьте всех пользователей из группы исследователей. Затем отбросьте группу. Параметр DROP ALL должен быть запущен до удаления группы, так как группа не может быть удалена, если в ее списке пользователей есть члены.

ALTER GROUP researchers DROP ALL;
DROP GROUP researchers;

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

Группы и разрешения

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

Группы также упрощают управление разрешениями, позволяя добавлять пользователей (и удалять пользователей) из группы. Например, предоставить группе платежной ведомости вставку, удаление и выбор разрешений в таблицах расчета заработной платы, что дает всем пользователям в группе эти разрешения. Если сотрудник покидает отдел расчета заработной платы или присоединяется к новому сотруднику, вам просто нужно отказаться или добавить пользователя из группы, не изменяя разрешения. Аналогичным образом, если вы обнаружите, что группе требуется меньше или больше разрешений, отмените или предоставите разрешения один раз для всей группы, а не отдельно для каждого члена группы.

Однако, будучи членом группы, он автоматически не предоставляет пользователю разрешения, предоставленные группе. Пользователи должны конкретно идентифицировать себя как часть группы, которым разрешены соответствующие разрешения. Пользователь может быть идентифицирован как часть группы двумя способами:

  • Указание идентификатора группы при запуске сеанса
  • Указание группы по умолчанию для пользователя. Группа по умолчанию указана для пользователя с использованием операторов SQL CREATE USER или ALTER USER.

Указание идентификатора группы при запуске сеанса При запуске сеанса пользователь может указать идентификатор группы следующим образом:

  • Для флага -G для многих системных команд. Для получения дополнительной информации см. Справочное руководство по командам.
  • С инструкцией CONNECT как частью приложения.
  • Как часть профиля подключения для сеанса OpenROAD. Для получения дополнительной информации см. Интерактивную справку для диалога «Создать профиль соединения» в OpenROAD.

Роли

Роль - это идентификатор, который может использоваться для связывания разрешений с приложениями. Роль обычно связана с одним или несколькими приложениями для предоставления разрешений этим приложениям.

   Например, компания использует ограниченное приложение, которое выполняет определенные проверки перед обновлением таблиц расчета заработной платы, чтобы обеспечить правильное обновление этих таблиц. Администратор базы данных определяет роль, например update_payroll, а затем назначает соответствующие разрешения для необходимых таблиц. Разработчик приложения связывает роль с приложением.
   Примечание. При определении роли DBA обычно работает с разработчиком приложения, чтобы они могли согласовать, какой идентификатор роли и пароль использовать для определенных приложений.

Для дополнительной безопасности можно указать пароль роли. Пароль роли необязателен.

Работа с объектами роли

Вы можете выполнять следующие основные операции над ролями:

  • Создание и изменение объектов роли
   Примечание. Пароли могут быть связаны с объектами роли, а также с объектами пользователя. В разделе User Password содержится дополнительная информация о паролях.
  • Просмотр существующих объектов роли, включая подробные свойства каждого объекта
  • Объекты ролевой роли

В SQL вы выполняете роли с операторами CREATE ROLE, ALTER ROLE и DROP ROLE при работе в сеансе, подключенном к базе данных iidbdb. Вы также можете работать с ролями с помощью Actian Director и VDBA.

   Пример: создание, изменение и удаление роли с помощью SQL-выражений

Ниже приведены примеры использования операторов CREATE ROLE, ALTER ROLE и DROP ROLE:

1. Создайте идентификатор роли и пароль для приложения инвентаря для книжного магазина: CREATE ROLE bks_onhand WITH PASSWORD = ’hgwells’;

   Примечание. В одиночных кавычках добавьте какие-либо специальные символы или пробелы в ключевом пароле. Бланки не важны для паролей - например, «a b c» эквивалентно «abc». Длина пароля может составлять до 24 символов. (Вы должны выбрать длинные пароли, которые нельзя легко догадаться.) Если пароль не назначен, то всем пользователям, которым был предоставлен доступ к этой роли, предоставляется доступ к идентификатору роли и связанным с ней разрешениям. (См. Инструкцию GRANT ROLE в Справочном руководстве SQL.) Если пароль назначен, то пользователь или приложение должны дополнительно использовать пароль для доступа к роли.

2. Создайте идентификатор роли без пароля для ежедневного приложения продаж для книжного магазина: CREATE ROLE dly_sales WITH NOPASSWORD;

3. Создайте идентификаторы двойной роли (эти функции как синонимы) и пароль для рекомендуемого приложения списка для книжного магазина: CREATE ROLE sclemens, mtwain WITH PASSWORD = ’goodluck’;

4. Измените пароль для существующего идентификатора роли new_accounts на eggbasket: ALTER ROLE new_accounts WITH PASSWORD = eggbasket;

5. Отмените существующий идентификатор роли sales_report: DROP ROLE sales_report;

Роли и разрешения

После создания роли вы можете связать с ней разрешения и создать для нее гранты для отдельных пользователей. Например, чтобы связанное приложение выполнялось правильно, дайте разрешение на обновление всем таблицам расчета для роли update_payroll. Дополнительные сведения см. В разделе «Разрешения объекта».

Когда вы предоставляете разрешение объекта или привилегию субъекта для роли, вы фактически предоставляете такое же разрешение или привилегию для любого сеанса, который запускается с использованием этой роли. Определение идентификатора роли при запуске сеанса.

При запуске сеанса необходимо указать идентификатор роли, который вводит в действие соответствующие разрешения и права субъекта. Например:

  • Для флага -R для многих системных команд. Для получения дополнительной информации см. Справочное руководство по командам.
  • С инструкцией CONNECT как частью приложения.
  • Для изображения приложения как части профиля подключения для сеанса OpenROAD. Для получения дополнительной информации см. Интерактивную справку для диалога «Создать профиль соединения» в OpenROAD.

Для администратора базы данных или пользователя (такого как системный администратор), у которого есть привилегия безопасности, ни идентификатор ролей, ни пароль не проверяются. Для любого другого пользователя указанная роль должна существовать, пользователю должно быть предоставлено разрешение на использование этой роли, и любой требуемый пароль должен быть указан правильно; в противном случае соединение будет отклонено.

Присвоение привилегий и предоставление разрешений

Субъектные привилегии

Субъектная привилегия определяет тип операций, допустимых в пользовательском сеансе. Субъектные права назначаются пользователю (субъекту). Субъектные привилегии обычно назначаются при создании или изменении пользовательского объекта. Субъектные привилегии также могут быть назначены ролям, как описано в группах и ролях. Чтобы установить или изменить права субъекта для пользователя, вы должны иметь привилегию maintain_users.

   Важно! Субъектные привилегии позволяют выполнять много доверенных операций. Поэтому назначьте привилегии с осторожностью, особенно привилегии безопасности.

Субъектные привилегии заключаются в следующем:

  • auditor

Позволяет пользователю запрашивать журнал аудита безопасности

  • change_password

Позволяет пользователю изменять свой пароль.

  • CREATEDB

Позволяет пользователю создавать и уничтожать базы данных.

  • maintain_audit

Позволяет пользователю контролировать, какая информация записывается в журнал аудита безопасности

  • maintain_locations

Позволяет пользователю управлять базами данных и местоположениями файлов

  • maintain_users

Позволяет пользователю выполнять различные пользовательские функции, такие как создание пользователей и ролей

  • operator

Позволяет пользователю выполнять резервное копирование базы данных и другие операции обслуживания

  • security

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

  • trace

Позволяет пользователю получать доступ к средствам отслеживания и отладки

Привилегия auditor

Аудиторская привилегия позволяет пользователю получать информацию из журнала аудита. Пользователь с этой привилегией может:

  • Зарегистрируйте файл журнала аудита в виртуальной таблице с помощью оператора REGISTER TABLE (или выполните эквивалентную операцию в Actian Director или VDBA).
  • Удалите регистрацию для файла журнала аудита с помощью оператора REMOVE TABLE (или выполните эквивалентную операцию в Actian Director или VDBA).
  • Запросить журнал аудита после его регистрации в виде виртуальной таблицы.
  • Получить имя файла журнала аудита, вызвав dbmsinfo ('security_audit_log').

Change_Password привилегия

Признак Change_Password позволяет пользователю сменить пароль (но не на других).

Createdb привилегия

Createdb привилегия дает пользователю возможность создавать базы данных. Эта привилегия требуется для использования команды createdb system или для использования эквивалентной операции в Actian Director или Visual DBA.

Привилегия maintain_audit

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

  • Включить или отключить аудит безопасности (используя инструкции ENABLE и DISABLE SECURITY_AUDIT или эквивалентные операции в Actian Director или VDBA).
  • Измените текущее состояние аудита (используя инструкцию ALTER SECURITY_AUDIT или эквивалентную операцию в Actian Director или VDBA).
  • Определите уровень активности аудита безопасности при работе с профилями, пользователями и ролями (указав предложение SECURITY_AUDIT в инструкциях ALTER / CREATE PROFILE, ALTER / CREATE USER и ALTER / CREATE ROLE или используя Actian Director или VDBA).

maintain_locations привилегии

Преимущество maintain_locations позволяет пользователю управлять распределением дискового пространства, создавать новые местоположения или создавать новые местоположения и разрешать или удалять существующие местоположения. Эта привилегия необходима для выдачи операторов CREATE, ALTER и DROP LOCATION (или для выполнения эквивалентных операций над объектами местоположения в Actian Director или VDBA).

Привилегия Maintain_Users

Признание keep_users позволяет пользователю выполнять различные функции, связанные с пользователем. Пользователь с этой привилегией может:

  • Поддерживать профили (используя инструкции CREATE / ALTER / DROP PROFILE или эквивалентные операции в Actian Director или VDBA).
  • Поддерживать пользователей (используя инструкции CREATE / ALTER / DROP USER или эквивалентные операции в Actian Director или VDBA).
  • Поддерживать группы (используя инструкции CREATE / ALTER / DROP GROUP или эквивалентные операции в Actian Director или VDBA).
  • Поддерживать роли (используя инструкции CREATE / ALTER / DROP ROLE или эквивалентные операции в Actian Director или VDBA).

Привилегия Operator

Привилегия оператора позволяет пользователю запускать следующие системные команды:

  • ckpdb
  • rollforwarddb
  • auditdb
  • sysmod
  • verifydb
  • relocatedb
  • fastload
  • alterdb
  • infodb

Пользователь, ответственный за запуск Vector, требует привилегии оператора. Эти системные команды можно альтернативно запускать через сервер удаленной команды (rmcmd) пользователем (клиентом), у которого есть привилегии rmcmd, а не привилегии оператора (при условии, что пользователь, запустивший rmcmd на стороне сервера, имеет привилегии оператора). Однако команда sysmod требует, чтобы клиентский пользователь имел привилегию безопасности или был пользователем, который запустил rmcmd на стороне сервера. Дополнительные сведения см. В разделе Предоставление доступа к удаленным пользователям и о том, как выполняются удаленные команды в руководстве по системному администрированию.

Привилегия Security

Права безопасности позволяют пользователю контролировать безопасность системы и действия ее пользователей. Права безопасности и все другие привилегии автоматически предоставляются владельцу установки. Пользователь с этой привилегией может:

  • Выдавать себя за других пользователей (используя флаг -u для команд или выполнять эквивалент с помощью Actian Director или ветви Users на панели инструментов Virtual Nodes в VDBA).
  • Подключитесь к любой базе данных с неограниченными привилегиями базы данных. (Фактически, привилегии базы данных не применяются для пользователей с привилегией безопасности.)
  • Настройте аварийные сигналы безопасности базы данных и установки (используя инструкции CREATE / DROP SECURITY_ALARM или эквивалентные операции в Actian Director или VDBA).

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

Привилегия Trace

Преимущество трассировки позволяет пользователю выполнять операции трассировки, устранения неполадок и отладки. Он позволяет пользователю устанавливать флаги отладки трассировки, используя следующие утверждения:

  • SET[NO]PRINTQRY
  • SET[NO]RULES
  • SET[NO]PRINTRULES
  • SET[NO]IO_TRACE
  • SET[NO]LOCK_TRACE
  • SET[NO]LOG_TRACE
  • SET TRACE POINT

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

Наборы привилегий, связанных с сеансом

В дополнение к назначению пользователю прав пользователя, Vector позволяет вам определить набор привилегий субъекта по умолчанию, которые будут доступны при запуске сеанса. Кроме того, любая привилегия, назначенная пользователю, может быть добавлена ​​или удалена в течение всего сеанса; эта способность эффективно применяет принцип наименьших привилегий. Принцип наименьших привилегий утверждает, что субъект должен иметь минимальные привилегии, необходимые для выполнения операции, и чтобы эти привилегии были активны в течение минимального времени, необходимого для выполнения этой операции. Таким образом, сеанс имеет три набора связанных с ним прав:

  • Набор привилегий по умолчанию содержит те привилегии, которые становятся активными при запуске соединения с вектором.
  • Набор рабочих привилегий содержит те привилегии, которые активны в любой конкретный момент времени (при запуске сеанса рабочий набор привилегий эквивалентен набору привилегий по умолчанию).
  • Максимальный набор привилегий содержит все привилегии, которыми может обладать определенный пользователь.

Набор рабочих привилегий определяется в течение срока действия сеанса, когда привилегии могут быть активированы по мере необходимости, чтобы разрешить выполнение привилегированной операции и сделать ее неактивной после завершения задачи. Набор рабочих привилегий задается с помощью инструкции SET SESSION. Используя SET SESSION, вы можете:

  • Добавить разрешенные привилегии для набора рабочих привилегий
  • Отбрасывать привилегии из набора рабочих привилегий
  • Замените набор рабочих привилегий на указанные разрешенные привилегии
  • Установите для набора рабочих привилегий все разрешенные привилегии
  • Сбросьте набор рабочих привилегий на набор привилегий по умолчанию
  • Удалите все привилегии из набора рабочих привилегий

В VDBA максимальный набор привилегий состоит из всех привилегий, разрешенных в столбце «Active by Request» диалогового окна «Создать пользователя» или «Изменение пользователя». Набор привилегий по умолчанию, который является подмножеством максимального набора привилегий, состоит из всех привилегий, включенных в столбце «Active по умолчанию» диалогового окна «Создать пользователя» или «Изменение пользователя».

Разрешения объекта

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

Владелец объекта может предоставлять и отзывать разрешения объекта и может предоставить другим пользователям привилегию предоставить разрешение на объект. Предоставление разрешений, как правило, является ответственностью администратора баз данных.

Используя разрешения, доступ к данным может быть ограничен несколькими способами. Гранты на объекты могут варьироваться от общего к конкретному. Разрешения классифицируются в зависимости от типа объектов, которые они затрагивают. Типы объектов включают:

  • База данных
  • Таблица
  • Посмотреть
  • Процедура
  • Событие базы данных
  • Роль
  • Текущая установка

Работа с грантами

Вы можете выполнить следующие основные операции над грантами (разрешения объектов):

  • Предоставить любое разрешение, разрешенное для определенного типа объекта для любой группы, роли или пользователя (включая общедоступную, которая охватывает всех текущих и будущих пользователей)
  • Просмотр всех типов разрешений объектов, предоставляемых определенной группе, роли или пользователю, или просмотр разрешений, предоставленных для определенного типа объекта
  • Отменить ранее предоставленное разрешение

В SQL вы можете предоставлять и отзывать разрешения с помощью операторов GRANT и REVOKE. Чтобы отобразить предоставленные привилегии, выберите данные из системного каталога iidbprivileges. В Actian Director используйте диалог Modify или Properties для пользователя, группы и роли.

В VDBA вы можете получить доступ к грантам несколькими способами с помощью диспетчера объектов базы данных. Например, если вы разветвляете ветвь для группы, роли или пользовательского объекта, существует подсекция Grants, где вы можете получить доступ ко всем разрешениям, предоставленным этой конкретной группе, роли или пользователю. Вы также можете развернуть ветку для других типов объектов, таких как база данных или таблица, и использовать связанную ветвь Grantees ... для доступа ко всем группам, ролям и пользователям, которым предоставлено каждое разрешение, разрешенное для этого типа объекта. Подробные инструкции по выполнению этих процедур см. В интерактивной справке.

Разрешения на объект и предоставление прав объекта

Когда вы создаете объект, вы становитесь владельцем этого объекта. Как владелец, вы автоматически имеете право предоставлять и отзывать разрешения для объекта (с представлениями, вы также должны иметь базовые таблицы). Когда вы предоставляете разрешения для объекта (кроме базы данных) другому пользователю, вы также можете предоставить разрешение для этого пользователя предоставлять разрешения для объекта другим пользователям, и вы также можете аннулировать это разрешение, если это необходимо.

Оператор GRANT

Оператор GRANT используется для предоставления разрешений. Это утверждение имеет общий вид: GRANT privilege ON object TO whom Полный синтаксис заявления GRANT:

GRANT ALL [PRIVILEGES] | privilege {, privilege}
   [ON [object_type] [schema.]object_name {, [schema.]object_name}]
   TO PUBLIC | [authorization_type] auth_id {, auth_id} [WITH GRANT OPTION];;

Тип объекта по умолчанию - TABLE, который используется для любой таблицы или представления. Тип авторизации по умолчанию - USER. Идентификаторы авторизации определяют, кто получает разрешения. Разрешения могут быть указаны для:

  • Индивидуальные пользователи

Разрешения, определенные конкретным оператором GRANT, могут быть выданы одному или нескольким конечным пользователям, указав идентификатор пользователя входа в систему.

  • Ключевое слово PUBLIC, которое включает всех пользователей. Тип авторизации PUBLIC не сопровождается никакими auth_ids.

Например: Предоставьте все разрешения на доступ для таблицы игр ко всем сеансам: GRANT ALL ON games TO PUBLIC;

  • Определенная группа
  • Определенная роль

Разрешения для отдельного пользователя и PUBLIC всегда действуют, но могут быть скорректированы с помощью разрешений групп и ролей.

Разрешения доступа базы данных

Разрешения базы данных определяются в базе данных в целом. Они устанавливают ряд ограничений, которые влияют на идентификаторы авторизации (то есть группы, роли, пользователи или общедоступные), определенные при определении гранта. Большинство разрешений базы данных запрещают разрешения - если не указано, по умолчанию нет ограничений. Запрет разрешений, даже если он определен, не применяется для владельца базы данных или для любого пользователя с правами безопасности, например системного администратора.

Допустимые разрешения базы данных следующие:

1. Доступ

Позволяет получателям получать доступ к базе данных. По умолчанию: все идентификаторы авторизации могут подключаться ко всем общедоступным базам данных. Доступ к частным базам данных возможен только пользователям, которым явно разрешено получать к ним доступ. Разрешение на доступ к частной базе данных может быть предоставлено следующими способами:

  • Использование гранта базы данных
  • Включение базы данных в разделе «Доступ к безграничным базам данных» в соответствующем диалоговом окне (например, диалог «Создать группу»)

2. Connect_time_limit

Указывает максимальное время (в секундах), которое может использовать сеанс. По умолчанию: нет ограничения времени подключения.

3. Create_procedure

Позволяет грантополучателям создавать процедуры базы данных в базе данных. По умолчанию: все идентификаторы авторизации могут создавать процедуры базы данных.

4. Create_table

Позволяет получателям создавать таблицы в базе данных. По умолчанию: все идентификаторы авторизации могут создавать таблицы.

5. Db_admin

Предоставляет грантополучателям неограниченные привилегии базы данных для базы данных и возможность выдавать себя за другого пользователя (используя флаг -u). По умолчанию: предоставляется владельцу базы данных и любому пользователю с правами безопасности, например системному администратору. Для всех остальных пользователей по умолчанию не разрешается использовать неограниченные привилегии базы данных.

6. Idle_time_limit

Задает максимальное время, которое может выполнять сеанс между выдачей выписок. По умолчанию: время ожидания

7. Lockmode

Позволяет грантополучателям выдавать заданный оператор lockmode. По умолчанию: все идентификаторы авторизации могут выдавать оператор set lockmode.

8. Query_cost_limit

Указывает максимальную стоимость каждого запроса в базе данных с точки зрения дискового ввода-вывода и использования ЦП. По умолчанию: всем идентификаторам авторизации разрешается неограниченная стоимость запроса.

9. Query_cpu_limit

Указывает максимальное использование ЦП на запрос в базе данных. По умолчанию: всем идентификаторам авторизации разрешено неограниченное использование ЦП на запрос.

10. Query_io_limit

Задает максимальное количество запросов ввода-вывода для каждого запроса в базе данных. По умолчанию: всем идентификаторам авторизации разрешено неограниченное количество запросов ввода-вывода. Права на базу данных query_io_limit и query_row_limit применяются на основе оценок оптимизатора запросов. Если оптимизатор предсказывает, что для запроса может потребоваться больше операций ввода-вывода или вернуть больше строк, чем разрешено для сеанса, запрос прерывается до выполнения. Это предотвращает потребление ресурсов по запросам, которые вряд ли удастся.

11. Query_page_limit

Задает максимальное количество страниц на запрос в базе данных. По умолчанию: всем идентификаторам авторизации разрешено неограниченное количество страниц для каждого запроса.

12. Query_row_limit

Задает максимальное количество строк, возвращаемых для каждого запроса в базе данных. По умолчанию: всем идентификаторам авторизации разрешено неограниченное количество строк для каждого запроса.

13. Select_syscat

Позволяет сеансу запрашивать системные каталоги для определения информации о схеме. По умолчанию: сеансам разрешено запрашивать системные каталоги.

14. Session_priority

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

15. Update_syscat

Позволяет получателям обновлять системные каталоги. По умолчанию: идентификатор авторизации не может обновлять системные каталоги. Preventing Permissions - у каждого разрешения есть соответствующее запрещающее разрешение, специально запрещающее разрешение. Например, чтобы предотвратить доступ к базе данных, укажите разрешение Noaccess.

Как определяются разрешения для базы данных для сеанса

Разрешения базы данных для сеанса вычисляются, когда сеанс подключается к базе данных и остается в силе в течение всего сеанса. Если после подключения сеанса к базе данных будут изменены разрешения базы данных для одного из идентификаторов авторизации этого сеанса, активный сеанс не будет затронут. Любые новые сеансы, созданные с одинаковыми идентификаторами авторизации, подчиняются пересмотренным разрешениям базы данных.

Примеры разрешений доступа базы данных

Ниже приведены примеры предоставления разрешений для базы данных:

1. Определите предел размера строки запроса из 100 строк в базе данных new_accts для пользователя Ralph:

GRANT QUERY_ROW_LIMIT 100
ON DATABASE new_accts TO ralph;

2. Запретить групповым программам создавать таблицы и процедуры базы данных в базе данных new_accts:

GRANT NOCREATE_TABLE, NOCREATE_PROCEDURE 
ON DATABASE new_accts TO prodrams;
<console>

3. Привилегия базы данных может быть заменена выдачей последующего заявления GRANT для авторизации пользователя. Например, предположим, что пользователю karenk было предоставлено ограничение строки запроса в 1000 строк в базе данных клиентов:
<console>
GRANT QUERY_ROW_LIMIT 1000
ON DATABASE customers TO karenk;

Ее работа меняется, и ей не нужно получать доступ к такой базе данных, поэтому администратор баз данных выпускает новую инструкцию GRANT, дающую ей ограничение строки запроса 250:

GRANT QUERY_ROW_LIMIT 250
ON DATABASE customers TO karenk;

Эта новая привилегия заменяет старую привилегию 1000 рядов. Если DBA впоследствии отменяет новый предел:

GRANT NOQUERY_ROW_LIMIT 
ON DATABASE customers TO karenk;

Ограничение привилегий строки запроса karenk для базы данных становится неопределенным (старый предел 1000 не восстанавливается). В этот момент, если для любого другого идентификатора авторизации, связанного с сеансом karenk, не было определено значение QUERY_ROW_LIMIT, количество строк, которые могут быть возвращены запросам ее сеанса, не ограничено.

Графики в таблице и представлении

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

Разрешения на таблицы и представления:

Для обеих таблиц и представлений могут быть предоставлены следующие разрешения на запросы:

  • Выбрать

Позволяет доступополучателям выбирать строки из таблицы или представления, например, используя инструкцию SELECT или предложение WHERE.

  • Вставить

Позволяет получателям добавлять строки в таблицу или просматривать, например, с помощью инструкции INSERT.

  • Удалить

Позволяет получателям доступа к операции удалять строки из таблицы или представления, например, используя оператор DELETE.

  • Обновить

Позволяет получателям изменять существующие строки в таблице или представлении, например, с помощью инструкции UPDATE. Грант обновления может применяться ко всем столбцам в таблице или представлении или только к определенным столбцам.

  • Разрешения на таблицы

Следующие разрешения разрешений могут предоставляться только для таблиц:

  • Копировать в

Позволяет получателям копировать содержимое таблицы в файл данных, например, используя предложение INTO оператора COPY.

  • Копировать из

Позволяет получателям копировать содержимое файла в таблицу, например, используя предложение FROM инструкции COPY.

  • Рекомендации

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

Примеры табличных грантов

Ниже приведены примеры предоставления разрешений для таблиц:

1. Предоставьте разрешение выбора на таблицу сотрудников пользователю freddy:

GRANT SELECT ON employee TO freddy;

2. Предоставьте разрешение выбора для таблиц employee и department_table для отдельных пользователей sally и ralph:

GRANT SELECT ON employee, department_table
TO sally, ralph;

3. Предоставьте разрешениям выбора и обновления для таблицы сотрудников для роли пользователя. Обратите внимание, что вы должны иметь возможность выбирать значения для их обновления:

GRANT SELECT, UPDATE ON employee TO rollin;

4. Предоставьте разрешения выбора и обновления для столбцов empname и empaddress в таблице employee для пользователей joander и gerryr:

GRANT SELECT, UPDATE (empname, empaddress)
ON employee TO joank, gerryr;

5. Предоставьте разрешение на ссылки на таблицу «адрес» пользователю «joe»:

GRANT REFERENCES ON address TO joe;

6. Разрешить ссылки на выбранные столбцы таблицы «finder» пользователю «joe»:

GRANT REFERENCES ON finder (lname, finit, state)
TO joe;

Пользователь «joe» может затем создать ссылочное ограничение на «адрес» таблицы или указанные столбцы таблицы «finder». Обратите внимание, что ему не нужно разрешение выбора для создания ссылочного ограничения. 7. Предоставьте все разрешения на запрос (выберите, вставьте, обновите, удалите и ссылки) в таблице phonelist всем пользователям:

GRANT ALL ON phonelist TO PUBLIC;

Процедурные привилегии

Для процедур базы данных единственным допустимым разрешением является разрешение Execute, которое позволяет грантополучателям выполнять процедуру. Предоставление разрешения на выполнение процедуры делает запросы к базе данных, содержащиеся в коде процедуры, доступными для получателей. Предоставление разрешения на выполнение процедуры базы данных также позволяет получателям создавать правила, которые запускают процедуру.

Разрешение Execute является разрешающим. По умолчанию выполнение запрещается, если разрешение не предоставлено специально. Это разрешение не применяется для владельца процедуры. Разрешение на создание процедур в базе данных описано в разделе «Гранты базы данных».

Гранты на мероприятия базы данных

Допустимые допустимые разрешения для базы данных приведены ниже: поднимать

Позволяет грантополучателям поднимать событие базы данных (используя инструкцию RAISE DBEVENT). регистр

Позволяет получателям зарегистрироваться для получения события базы данных (с помощью оператора REGISTER DBEVENT). Это разрешающие разрешения - по умолчанию выполнение запрещено, если только это не разрешено. Права владельца базы данных не применяются для владельца события.

Ролевые гранты

Когда роль создается, имплицитный грант выдается на роль пользователю, создающему роль. Доступ к роли должен предоставляться другим пользователям (или публичным), прежде чем они смогут использовать эту роль. Ролевым доступом является разрешающее разрешение - по умолчанию доступ к роли запрещен, если только это не разрешено.

Как гранты ограничивают доступ к данным

Гранты позволяют ограничить доступ к данным следующими способами:

  • Операционные ограничения (например, разрешения выбора, вставки, обновления и удаления, применяемые к некоторым или ко всем столбцам таблицы).
  • Ограничения данных (ограничения данных), которые реализуются через представления.
  • Ограничения ресурсов, которые являются правами, определенными для базы данных в целом, а не отдельными таблицами или столбцами.

В сеансе, где действуют разрешения, при выдаче запроса (например, из приложения или окна Scratchpad SQL в VDBA) запрос передается на сервер СУБД. Затем вектор оценивает гранты в таблицах, участвующих в запросе. Если операция не проходит операционное ограничение, возвращается сообщение об ошибке.

Если операция не ограничивает ограничение данных, это означает, что представления используются, а представления отображаются в представлениях, но авторизация пользователя не передает гранты данных. В этом случае ошибка не возвращается, но влияет количество возвращаемых строк. Например, если Мэри обращается к представлению, которое возвращает строки только из отдела обуви, тогда, если она запрашивает информацию из отдела игрушек, строки не возвращаются.

Излишние полномочия

Гранты могут влиять на время обработки запроса. Запросы для таблицы или представления имеют накладные расходы, если:

  • Разрешения предоставляются на столе или в представлении;
  • Разрешены разрешения для столбцов;
  • Многие разрешения предоставляются в базе данных.

Однако для следующего нет накладных расходов:

  • Для владельца стола;
  • По некоторым государственным грантам:

- В некоторых операциях; - Любая операция, для которой все разрешенные разрешения указаны для общедоступных;

  • Если разрешения не разрешены (запрос просто прерван).

Во время инициализации сеанса есть дополнительные накладные расходы для оценки привилегий базы данных для идентификаторов авторизации, связанных с сеансом. Поскольку инициализация сеанса должна считывать каталоги, в которых хранятся группы, роли и базы данных, определенные операции, выданные администратором баз данных или системным администратором, которые могут быть записаны в эти каталоги, могут быть скорректированы или отменены как можно скорее. Эти операции включают:

  • Предоставление или отзыв привилегий базы данных;
  • Создание, изменение или удаление группы;
  • Создание, изменение или удаление роли.

Множественные проверки разрешений

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

Например, предположим, что были созданы гранты, позволяющие публиковать все разрешения для таблицы employee и чтобы был создан грант, чтобы разрешить определенному пользователю Susan выбрать привилегию в таблице employee. Сьюзан, как часть общественности, может выполнять все операции над таблицей сотрудников, даже если ее индивидуальный грант был только для выбранного разрешения.

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

Как определяются привилегии для сессии

В любом сеансе привилегии, действующие для этого сеанса, производятся из привилегий, предоставленных идентификаторам полномочий (роли, пользователя, группы и общественности), связанным с сеансом, и любым применимым значениям по умолчанию. Если определенная привилегия определена для более чем одного идентификатора авторизации, связанного с сеансом, то иерархия используется для определения того, какая определенная привилегия применяется для этого сеанса. Иерархия авторизации в порядке наивысшего наименьшего приоритета:

  1. роль;
  2. пользователь;
  3. группа;
  4. публичный.

Для каждого доступного объекта в сеансе есть поиск определенной привилегии, которая указывает этот объект и требуемые характеристики доступа (например, «Выбрать», «Вставить», «Выполнить» и т.д.).

Доступ к таблицам, представлениям или процедурам и иерархии авторизации

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

Например, чтобы вставить в указанную таблицу, один из идентификаторов авторизации, связанных с сеансом, должен иметь разрешение Insert, определенное для указанной таблицы. Если ни один из идентификаторов авторизации, связанных с сеансом, не имеет этого разрешения, и пользователь не владеет этой таблицей, используется внутреннее значение по умолчанию. В этом случае, поскольку внутреннее значение по умолчанию для разрешения Insert не допускает вставки, вставки не допускаются в указанную таблицу.

Доступ к базам данных и иерархии авторизации

Когда указанным объектом, к которому требуется доступ, является база данных, иерархия авторизации также важна, потому что привилегии, определенные в базе данных, могут быть определены с разными значениями для разных идентификаторов авторизации. Когда привилегия базы данных определяется на разных уровнях, иерархия используется для определения того, какая привилегия применяется. Например, предположим, что границы строк запроса были определены по-разному для каждого уровня авторизации следующим образом:

Идентификатор авторизации Ограничение строки запроса
Идентификатор роли 1700
Пользователь 1500
Идентификатор группы 2000
Публика 1000

Если пользователь запускает сеанс и задает идентификаторы групп и ролей, предел, определенный для этой роли, применяется, поскольку он имеет самый высокий порядок приоритета в иерархии, предоставляя сеансу ограничение строки запроса 1700. Ниже описаны несколько других возможных сценариев:

  • Если для роли не было определено ограничение строки запроса, то применяется ограничение строки запроса, определенное для этого пользователя, которое составляет 1500 строк. Это также имеет место, если пользователь не указал идентификатор роли.
  • Если для этого пользователя не было определено ограничение строки запроса, тогда применяется ограничение строки запроса, определенное для группы (2000 строк).
  • Если для группы не было определено ограничение строки запроса, или если пользователь не указал идентификатор группы, то префикс строки запроса, определенный для публичных (1000 строк), принудительно применяется.
  • Если ни один из идентификаторов не задал ограничение строки запроса, применяется внутреннее умолчание, которое в этом случае является неограниченным количеством строк.

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

Как определяются привилегии базы данных для сеанса

Для определения привилегий базы данных сеанса используется иерархия авторизации (см. Раздел «Как определяются привилегии для сеанса»). Иерархия включает в себя привилегии, предоставленные для идентификаторов авторизации, действующих для сеанса, и внутренние значения по умолчанию.

Когда пользователь начинает сеанс:

  • Права, действующие для этого сеанса, получены из привилегий, определенных для идентификатора пользователя и для публики. Например, хотя у вас может быть привилегия выбора всех таблиц в базе данных, у вас может быть только разрешение на обновление для ограниченного числа этих таблиц. Если пользователь включает флаг -G или -R или оба в командной строке при запуске сеанса, тогда привилегии для указанного идентификатора группы или роли также действуют для сеанса.
  • Если у пользователя есть идентификатор группы по умолчанию, определенный для идентификатора пользователя, когда пользователь начинает сеанс без указания идентификатора группы, идентификатор группы по умолчанию автоматически применяется к сеансу. Идентификатор группы по умолчанию может быть указан для пользователя, когда пользовательский объект создается или изменяется.

DBMSINFO - просмотр разрешений для текущей сессии

Вы можете использовать функцию DBMSINFO, чтобы получить текущее значение любой привилегии базы данных, действующей для текущего сеанса. Чтобы выполнить запрос DBMSINFO, используйте следующий синтаксис:

SELECT DBMSINFO('request_name');

Имя request_name может быть любым из следующих параметров: connect_time_limt Значение сеанса для ограничения времени соединения, или -1, если нет create_procedure «Y», если сеанс имеет права процедуры процедуры или «N», если нет create_table «Y», если в сеансе созданы привилегии таблицы или «N», если нет db_admin «Y», если сеанс имеет привилегию db_admin или «N», если нет idle_time_limit Значение сеанса для ограничения времени ожидания или -1, если нет lockmode «Y», если сеанс может выдавать заданный оператор lockmode или «N», если нет query_cost_limit Значение сеанса для ограничения стоимости запроса или -1, если нет query_cpu_limit Значение сеанса для предела ЦП или -1, если нет query_io_limit Значение сеанса для ограничения ввода-вывода запроса или -1, если нет query_page_limit Значение сеанса для ограничения страницы запроса или -1, если нет query_row_limit Значение сеанса для ограничения строки запроса или -1, если нет session_priority Текущий приоритет сеанса или -1, если нет select_syscat «Y», если сеанс имеет привилегию select_syscat или «N», если нет update_syscat «Y», если сеанс имеет привилегию update_syscat или «N», если нет

   Пример. Возврат значения предела строки запроса для текущей сессии.

Предполагая, что разрешение Query_row_limit для текущего сеанса равно 50, следующий запрос возвращает значение «50» в x: SELECT x = DBMSINFO('query_row_limit') AS x;

   Примечание. Функция DBMSINFO позволяет использовать другие значения request_name, относящиеся к другим аспектам текущего сеанса. Подробнее см. В разделе «Функция DBMSINFO» руководства по языку SQL.

Источники

  1. Official website of Actian Vector // Actian [2008—2017]. Дата обновления: 05.12.2013. URL: http://www.actian.com/products/analytics-platform/vector-smp-analytics-database/ (дата обращения: 01.12.2017).
  2. Official website of Actian Vector in Hadoop // Actian [2008—2017]. Дата обновления: 05.12.2013. URL: http://www.actian.com/products/analytics-platform/vortex-sql-hadoop-analytics/ (дата обращения: 01.12.2017).