TL; DR: глобальная привилегия CREATE DATABASE в Snowflake разрешает пользователю / роли выполнять такой оператор. Чтобы удалить его, необходимо спроектировать систему доступа на основе ролей и отозвать права администратора на уровне существующих пользователей.
Как минимум, строго ограничить пользователей, которым разрешено запускать операторы, как ACCOUNTADMIN, SECURITYADMIN или SYSADMIN ролей . Отмените эти привилегии у группы пользователей, которую вы хотите запретить выполнять операции уровня DATABASE:
REVOKE accountadmin FROM USER other_user1;
REVOKE securityadmin FROM USER other_user1;
REVOKE sysadmin FROM USER other_user1;
REVOKE accountadmin FROM USER other_user2;
REVOKE securityadmin FROM USER other_user2;
REVOKE sysadmin FROM USER other_user2;
(… repeat for all users that need to be limited …)
Далее создайте пользовательские роли и определите желаемый уровень доступа к ним. Также определите, какие имена пользователей будут принадлежать каждой роли в зависимости от их функций в вашей организации.
Ниже приведен очень обобщенный пример c и basi c только для иллюстративных целей, который разделяет всех пользователей базы данных «Заказы». на два уровня доступа. Потребности в спецификациях c будут различаться в зависимости от уникальной ситуации в вашей организации.
CREATE ROLE orders_read_and_write;
CREATE ROLE orders_read_only;
-- Snowflake recommends you create a hierarchy of roles so you can allow any
-- SYSADMIN-allowed users to manage these newly created roles instead of
-- requiring an ACCOUNTADMIN level user to do so in future
GRANT ROLE orders_read_and_write TO ROLE sysadmin;
GRANT ROLE orders_read_only TO ROLE sysadmin;
Созданным выше двум ролям orders_read_and_write и orders_read_only могут быть предоставлены соответствующие права для управления уровнем доступа к схеме и таблицы в базе данных «Заказы». Продолжая пример:
-- Allow both these roles to access schema and tables under "Orders" DB
-- This does not allow them to perform any DB-level operations
-- such as replacing/overwriting it
GRANT USAGE ON DATABASE "Orders" TO ROLE orders_read_and_write;
GRANT USAGE ON DATABASE "Orders" TO ROLE orders_read_only;
-- Allow read and write access appropriately to schema under the DB
-- Note the difference on using ALL vs. USAGE in the privilege granted
-- to each role here:
GRANT ALL ON SCHEMA "Orders"."SCHEMA-NAME" TO ROLE orders_read_and_write;
GRANT USAGE ON SCHEMA "Orders"."SCHEMA-NAME" TO ROLE orders_read_only;
GRANT SELECT
ON ALL TABLES IN SCHEMA "Orders"."SCHEMA-NAME"
TO ROLE orders_read_only;
Наконец, присвойте роли соответствующим именам пользователей.
GRANT ROLE orders_read_and_write TO USER other_user_1;
GRANT ROLE orders_read_only TO USER other_user_2;
(…)
Любая роль, не обладающая привилегией уровня CREATE DATABASE больше не сможет выполнять оператор, такой как CREATE OR REPLACE DATABASE "Orders";.
. В приведенном выше примере обе роли получают доступ только на уровне USAGE к базе данных Orders, что не позволяет им выполнять такие заявления больше.
Если вам когда-либо понадобится разрешить такую привилегию для роли, вы можете GRANT явно указать ее для роли выбора, которой доверяют пользователи:
GRANT CREATE DATABASE TO ROLE role_name;
Я настоятельно рекомендую несколько раз пройтись по разделу в Snowflake , чтобы привыкнуть к терминологии. Это упрощает внедрение и управление эффективными средствами контроля доступа в вашей организации.
Примечание . Введение контроля доступа - это серьезное изменение, которое потребует подлинной коммуникации и координации в вашей организации. эффективный. Всегда трудно удалить свободу, так как это может быть заложено в уже используемые скрипты и программы.