What is used to verify that an administrator is not accessing data that he should not be accessing?

Índice Show

Recover administrator access using automated recovery
Recover administrator access using support-assisted recovery
If you're a user and can't contact your administrator
Related topics

If you're an administrator of your organization's Google Workspace or Cloud Identity account and you forgot your password, or you're a user and your administrator is unreachable, here's what you can do to access your account.

Recover administrator access using automated recovery

If you forgot your password or username, choose an option below depending on whether you added a recovery phone number or email address to your administrator account. If you're not sure, start with Option 1.

Option 1: If you set up email or phone recovery information

Go to https://accounts.google.com/signin/recovery and enter the email address you use to sign in to your administrator account.
Click NextTry another way.
If you have a recovery email or phone number set up for your account, Google will send you a verification code. Follow the instructions to reset your password. Or, you might receive a message to enter an email address so support can contact you later.

Go to https://accounts.google.com/signin/recovery
Click Forgot email?
Enter your recovery email address or phone number, then click Next.
Enter the full name on your account.
If you have a recovery email or phone number set up for your account, Google will send you a verification code. Follow the instructions to reset your password.

Option 2: If you did not set up email or phone recovery information

If you don’t have recovery options set up, the recovery wizard asks you to verify your domain. This option works best if you are familiar with managing domains.

Go to https://accounts.google.com/signin/recovery and enter the email address you use to sign in to your administrator account.
Click NextTry another way until you get to this screen:
Follow the instructions to add a CNAME record to your domain’s DNS settings. For details, go to Recover your Google Workspace password with a CNAME record.
If your hosting provider is separate from your domain registrar, make sure you are modifying the CNAME record with your hosting provider.
After adding the CNAME record, wait a few minutes before clicking Next. This makes it more likely that Google will find the new record and allow you to immediately reset your password.
Return to the recovery wizard and click Next. If Google finds the new CNAME record, the Create Password screen displays.
Create a new password and sign in to your account.
If the CNAME record is not found, continue with the following steps.
Enter an email address where we can contact you, then click Next. Do not enter the email address of your locked account. Google sends a verification code to the email address you provided.
Enter the verification code you received, then click Next. After Google verifies the new CNAME record, you’ll get an email with a password reset link.
Use the password reset link to reset your password and sign in to your account.
Answer the questions about your Google Workspace account. You don't have to answer all the questions correctly to verify that it’s your account. If you're having trouble answering them, go to Tips to complete account recovery steps.
If the CNAME isn’t found in 48 hours, you’ll get an email letting you know the password recovery was unsuccessful.

If you still can’t reset your administrator password

Ask another admin in your organization with Super Admin privileges to reset your password using the Google Admin console.
If you purchased your Google service from a Google reseller, go to Contact your Google reseller.
The recovery wizard may provide an option to initiate a support-assisted recovery flow. If so, click Contact support and follow the steps below.

Recover administrator access using support-assisted recovery

If you're unable to recover your administrator account through the automated self-recovery flow outlined above, you may be able to use supported-assisted recovery. You will need to provide evidence of ownership of the domain name and the data within the domain.

Before you begin

Use support-assisted recovery

After going through the automated-recovery flow, click Contact support on this screen:

You're directed to the Apps Admin Toolbox.
Enter an email address where we can contact you, then click Continue. Do not enter the email address of your locked account. Google generates a support reference number and sends it to the email address you provide.
Follow the instructions to help us verify that you own the domain. You'll need to add a CNAME record or TXT record to your DNS record at your domain host. If you’re not sure who your domain host is, go to Identify your domain host.
After adding the CNAME or TXT record, click Check Again.
The DNS record can take up to 24 hours to propagate. You can check if the DNS record has propagated using one of the following:
- https://toolbox.googleapps.com/apps/dig/#CNAME/reference number.domain
- https://toolbox.googleapps.com/apps/dig/#TXT/domain
After your DNS record successfully updates, return to the form to complete your request.
Select Request for Password Reset (Recommended), and then click Submit Request.

After you submit the request, the support team will contact you for the next steps. In some cases, you may need to provide additional verification to make sure access is only granted to the rightful owner of the account.

If you're a user and can't contact your administrator

If you’re having issues reaching the administrator of your Google Workspace or Cloud Identity account, your user account can be promoted to the super administrator role with proof of domain ownership.

Sign in to your Google Account (if you haven't signed in recently). Only active accounts can be promoted to administrator. If you’re unable to sign in, you’ll need to Recover your Google Account.
Go to https://toolbox.googleapps.com/apps/recovery/form and enter the domain name you use for your account.
The domain name is the unique name that appears after the @ sign in your email address. For example, if your email address is , the domain name is solarmora.com.
Click Lookup Recovery Options.
Select I am a user and cannot contact my administrator, then click Continue.
Confirm your details, then click Continue.
Google generates a support reference number and sends it to your email address.
Follow the instructions to help us verify that you own the domain. You'll need to add a CNAME record or TXT record to your DNS record at your domain host. If you’re not sure who your domain host is, go to Identify your domain host.
After adding the CNAME or TXT record, click Check Again.
The DNS record can take up to 24 hours to propagate. You can check if the DNS record has propagated using one of the following:
- https://toolbox.googleapps.com/apps/dig/#CNAME/reference number.domain
- https://toolbox.googleapps.com/apps/dig/#TXT/domain
After your DNS record successfully updates, return to the form to complete your request.
Select Request User Promotion (Recommended), then click Submit Request.
Google will reach out to the existing administrators.
- If the administrators are inactive and unresponsive, Google will promote your user account.
- Alternatively, you will have the option to have Google provide the current administrators with your contact information.

This topic provides best practices and important considerations for managing secure access to your Snowflake account and data stored within the account. In particular, it provides general guidance for configuring role-based access control, which limits access to objects based on a user’s role.

In this Topic:

The account administrator (i.e users with the ACCOUNTADMIN system role) role is the most powerful role in the system. This role alone is responsible for configuring parameters at the account level. Users with the ACCOUNTADMIN role can view and manage Snowflake billing and credit data, and can stop any running SQL statements.

Note that ACCOUNTADMIN is not a superuser role. This role only allows viewing and managing objects in the account if this role, or a role lower in a role hierarchy, has sufficient privileges on the objects.

In the system role hierarchy, the other administrator roles are children of this role:

The user administrator (USERADMIN) role includes the privileges to create and manage users and roles (assuming ownership of those roles or users has not been transferred to another role).
The security administrator (i.e users with the SECURITYADMIN system role) role includes the global MANAGE GRANTS privilege to grant or revoke privileges on objects in the account. The USERADMIN role is a child of this role in the default access control hierarchy.
The system administrator (SYSADMIN) role includes the privileges to create warehouses, databases, and all database objects (schemas, tables, etc.).

Attention

By default, when your account is provisioned, the first user is assigned the ACCOUNTADMIN role. This user should then create one or more additional users who are assigned the USERADMIN role. All remaining users should be created by the user(s) with the USERADMIN role or another role that is granted the global CREATE USER privilege.

We strongly recommend the following precautions when assigning the ACCOUNTADMIN role to users:

Assign this role only to a select/limited number of people in your organization.
All users assigned the ACCOUNTADMIN role should also be required to use multi-factor authentication (MFA) for login (for details, see Configuring Access Control).
Assign this role to at least two users. We follow strict security procedures for resetting a forgotten or lost password for users with the ACCOUNTADMIN role. These procedures can take up to two business days. Assigning the ACCOUNTADMIN role to more than one user avoids having to go through these procedures because the users can reset each other’s passwords.

Tip

It also helps if you associate an actual person’s email address to ACCOUNTADMIN users, so that Snowflake Support knows who to contact in an urgent situation.

The ACCOUNTADMIN role is intended for performing initial setup tasks in the system and managing account-level objects and tasks on a day-to-day basis. As such, it should not be used to create objects in your account, unless you absolutely need these objects to have the highest level of secure access. If you create objects with the ACCOUNTADMIN role and you want users to have access to these objects, you must explicitly grant privileges on the objects to the roles for these users.

Instead, we recommend creating a hierarchy of roles aligned with business functions in your organization and ultimately assigning these roles to the SYSADMIN role. For more information, see Aligning Object Access with Business Functions in this topic.

Tip

To help prevent account administrators from inadvertently using the ACCOUNTADMIN role to create objects, assign these users additional roles and designate one of these roles as their default (i.e. do not make ACCOUNTADMIN the default role for any users in the system).

This doesn’t prevent them from using the ACCOUNTADMIN role to create objects, but it forces them to explicitly change their role to ACCOUNTADMIN each time they log in. This can help make them aware of the purpose/function of roles in the system and encourage them to change to the appropriate role for performing a given task, particularly when they need to perform account administrator tasks.

We recommend using a role other than ACCOUNTADMIN for automated scripts. If, as recommended, you create a role hierarchy under the SYSADMIN role, all warehouse and database object operations can be performed using the SYSADMIN role or lower roles in the hierarchy. The only limitations you would encounter is creating or modifying users or roles. These operations must be performed by a user with the SECURITYADMIN role or another role with sufficient object privileges.

All securable database objects (such as TABLE, FUNCTION, FILE FORMAT, STAGE, SEQUENCE, etc.) are contained within a SCHEMA object within a DATABASE. As a result, to access database objects, in addition to the privileges on the specific database objects, users must be granted the USAGE privilege on the container database and schema.

For example, suppose mytable is created in mydb.myschema. In order to query mytable, a user must have the following privileges at a minimum:

Database

USAGE on mydb

Schema

USAGE on myschema

Table

SELECT on mytable

When a custom role is first created, it exists in isolation. The role must be assigned to any users who will use the object privileges associated with the role. The custom role must also be granted to any roles that will manage the objects created by the custom role.

Important

By default, not even the ACCOUNTADMIN role can modify or drop objects created by a custom role. The custom role must be granted to the ACCOUNTADMIN role directly or, preferably, to another role in a hierarchy with the SYSADMIN role as the parent. The SYSADMIN role is managed by the ACCOUNTADMIN role.

For instructions to create a role hierarchy, see Creating a Role Hierarchy.

Consider taking advantage of role hierarchies to align access to database objects with business functions in your organization. In a role hierarchy, roles are granted to other roles to form an inheritance relationship. Permissions granted to roles at a lower level are inherited by roles at a higher level.

For optimal flexibility in controlling access to database objects, create a combination of object access roles with different permissions on objects and assign them as appropriate to functional roles:

Grant permissions on database objects or account objects (such as warehouses) to access roles.
Grant access roles to functional roles to create a role hierarchy. These roles correspond to the business functions of your organization and serve as a catch-all for any access roles required for these functions.

When appropriate, grant lower-level functional roles to higher-level functional roles in a parent-child relationship where the parent roles map to business functions that should subsume the permissions of the child roles.

Following best practices for role hierarchies, grant the highest-level functional roles in a role hierarchy to the system administrator (SYSADMIN) role. System administrators can then grant privileges on database objects to any roles in this hierarchy:

Note

There is no technical difference between an object access role and a functional role in Snowflake. The difference is in how they are used logically to assemble and assign sets of permissions to groups of users.

As a simple example, suppose two databases in an account, fin and hr, contain payroll and employee data, respectively. Accountants and analysts in your organization require different permissions on the objects in these databases to perform their business functions. Accountants should have read-write access to fin but might only require read-only access to hr because human resources personnel maintain the data in this database. Analysts could require read-only access to both databases.

Permissions on existing database objects are granted via the following hierarchy of access roles and functional roles:

Note

When new objects are added in each database, consider automatically granting privileges on the objects to roles based on object type (e.g. schemas, tables, or views). For information, see Simplifying Grant Management Using Future Grants (in this topic).

Custom Role	Description	Privileges
db_hr_r	Access role that permits read-only access to tables in the hr database.	USAGE on database hr. USAGE on all schemas in database hr. SELECT on all tables in database hr.
db_fin_r	Access role that permits read-only access to tables in the fin database.	USAGE on database fin. USAGE on all schemas in database fin. SELECT on all tables in database fin.
db_fin_rw	Access role that permits read-write access to tables in the fin database.	USAGE on database fin. USAGE on all schemas in database fin. SELECT, INSERT, UPDATE, DELETE on all tables in database fin.
accountant	Functional role for accountants in your organization.	N/A
analyst	Functional role for analysts in your organization.	N/A

The following diagram shows the role hierarchy for this example:

To configure access control for this example:

As a user administrator (user with the USERADMIN role) or another role with the CREATE ROLE privilege on the account, create the access roles and functional roles in this example:

CREATE ROLE db_hr_r; CREATE ROLE db_fin_r; CREATE ROLE db_fin_rw; CREATE ROLE accountant; CREATE ROLE analyst;
As a security administrator (user with the SECURITYADMIN role) or another role with the MANAGE GRANTS privilege on the account, grant the required minimum permissions to each of the access roles:

-- Grant read-only permissions on database HR to db_hr_r role. GRANT USAGE ON DATABASE hr TO ROLE db_hr_r; GRANT USAGE ON ALL SCHEMAS IN DATABASE hr TO ROLE db_hr_r; GRANT SELECT ON ALL TABLES IN DATABASE hr TO ROLE db_hr_r; -- Grant read-only permissions on database FIN to db_fin_r role. GRANT USAGE ON DATABASE fin TO ROLE db_fin_r; GRANT USAGE ON ALL SCHEMAS IN DATABASE fin TO ROLE db_fin_r; GRANT SELECT ON ALL TABLES IN DATABASE fin TO ROLE db_fin_r; -- Grant read-write permissions on database FIN to db_fin_rw role. GRANT USAGE ON DATABASE fin TO ROLE db_fin_rw; GRANT USAGE ON ALL SCHEMAS IN DATABASE fin TO ROLE db_fin_rw; GRANT SELECT,INSERT,UPDATE,DELETE ON ALL TABLES IN DATABASE fin TO ROLE db_fin_rw;
As a security administrator (user with the SECURITYADMIN role) or another role with the MANAGE GRANTS privilege on the account, grant the db_fin_rw access role to the accountant functional role, and grant the db_hr_r db_fin_r access roles to the analyst functional role:

GRANT ROLE db_fin_rw TO ROLE accountant; GRANT ROLE db_hr_r TO ROLE analyst; GRANT ROLE db_fin_r TO ROLE analyst;
As a security administrator (user with the SECURITYADMIN role) or another role with the MANAGE GRANTS privilege on the account, grant both the analyst and accountant roles to the system administrator (SYSADMIN) role:

GRANT ROLE accountant,analyst TO ROLE sysadmin;
As a security administrator (user with the SECURITYADMIN role) or another role with the MANAGE GRANTS privilege on the account, grant the business functional roles to the users who perform those business functions in your organization. In this example, the analyst functional role is granted to user user1, and the accountant functional role is granted to user user2.

GRANT ROLE accountant TO USER user1; GRANT ROLE analyst TO USER user2;

With regular (i.e. non-managed) schemas in a database, object owners (i.e. roles with the OWNERSHIP privilege on one or more objects) can grant access on those objects to other roles, with the option to further grant those roles the ability to manage object grants.

To further lock down object security, consider using managed access schemas. In a managed access schema, object owners lose the ability to make grant decisions. Only the schema owner (i.e. the role with the OWNERSHIP privilege on the schema) or a role with the MANAGE GRANTS privilege can grant privileges on objects in the schema, including future grants, centralizing privilege management.

Note that a role that holds the global MANAGE GRANTS privilege can grant additional privileges to the current (grantor) role.

For more information on managed access schemas, see Creating Managed Access Schemas.

Future grants allow defining an initial set of privileges on objects of a certain type (e.g. tables or views) in a specified schema. As new objects are created, the defined privileges are automatically granted to a role, simplifying grant management.

Consider the following scenario, in which a particular role is granted the SELECT privilege on all new tables created in schema. At a later date, the decision is made to revoke the privilege from this role and instead grant it to a different role. Using the ON FUTURE keywords for new tables and the ALL keyword for existing tables, few SQL statements are required to grant and revoke privileges on new and existing tables. For example:

-- Grant the SELECT privilege on all new (i.e. future) tables in a schema to role R1 GRANT SELECT ON FUTURE TABLES IN SCHEMA s1 TO ROLE r1; -- / Create tables in the schema / -- Grant the SELECT privilege on all new tables in a schema to role R2 GRANT SELECT ON FUTURE TABLES IN SCHEMA s1 TO ROLE r2; -- Grant the SELECT privilege on all existing tables in a schema to role R2 GRANT SELECT ON ALL TABLES IN SCHEMA s1 TO ROLE r2; -- Revoke the SELECT privilege on all new tables in a schema (i.e. future grant) from role R1 REVOKE SELECT ON FUTURE TABLES IN SCHEMA s1 FROM ROLE r1; -- Revoke the SELECT privilege on all existing tables in a schema from role R1 REVOKE SELECT ON ALL TABLES IN SCHEMA s1 FROM ROLE r1;

For more information on future grants, see Assigning Future Grants on Objects.

A user cannot view the result set from a query that another user executed. This behavior is intentional. For security reasons, only the user who executed a query can access the query results.

Note

This behavior is not connected to the Snowflake access control model for objects. Even a user with the ACCOUNTADMIN role cannot view the results for a query run by another user.

Cloning a database, schema or table creates a copy of the source object. The cloned object includes a snapshot of data present in the source object when the clone was created.

A cloned object is considered a new object in Snowflake. Any privileges granted on the source object do not transfer to the cloned object. However, a cloned container object (a database or schema) retains any privileges granted on the objects contained in the source object. For example, a cloned schema retains any privileges granted on the tables, views, UDFs, and other objects in the source schema.

For more details about cloning, see Cloning Considerations and CREATE <object> … CLONE.