Skip to content

Governance

  • granting a database role to an account role implicitly grants usage on the database
  • future grants on schema take precedence over future grants on database
  • data recovery: up to 90 days time-travel and 7 days failsafe
  • Third party certifications: HiPPA, PCI, SOC 2/1
    • Only available to customers upon signing NDA

Grants for executables

  • Owner rights: The owner role of the executable must have privileges
  • Caller rights: The caller role of the executable must have privileges
  • Restricted caller rights: The caller role must have privileges and the owner must have caller rights privileges
    • inherited caller permissions include all future and current grants on objects of specific type within schema, database or account

Secure Views

  • Certain optimizations are disabled to prevent user from determining data existence indirectly
  • query optimizer does not evaluate the user’s filter before the authorization predicate

Audits

  • Views in ACCOUNT_USAGE
    • Data ingestion/exfiltration: COPY_HISTORY, DATA_TRANSFER_HISTORY, LOAD_HISTORY, PIPE_USAGE_HISTORY
    • User/SQL level: LOGIN_HISTORY, QUERY_HISTORY
  • Parameters:
    • prevent_unload_to_inline_url: No ad-hoc data unloads
    • require_storage_integration_for_stage_creation: require SI for stage creation
    • require_storage_integration_for_stage_operation: users cannot specify credentials when loading/unloading data

Data Lineage

  • ACCESS_HISTORY stores table, view, stage, UDF, stored-procedure, and column lineage
  • DDL operations that are tracked including assigning tags, policies

Object Dependencies

  • Limitations
    • does not record dependencies of functions, if the calls are made within definition of another object.
    • dependencies maybe broken if they are of by_name_and_id type

DMF

Tags

  • 50 tags max per table/view counting the tags set on the columns
  • inheritance: based on object hierarchy (eg Org -> Account -> Database -> Schema -> Table -> Column), but not containment/dependency hierarchy (i.e. View -> Table etc)
  • tags can optionally contain a list of allowed values (SYSTEM$GET_TAG_ALLOWED_VALUES('<tag>'))
  • applying a tag requires a value: create ... with tag (tag1 = 'value1') or alter ... set tag tag1 = 'value1'
    • system$get_tag('tag1', 'my_table', 'table')
    • select * from snowflake.account_usage.tags
    • select * from table(snowflake.account_usage.tag_references_with_lineage('my_db.my_schema.cost_center'))
    • select * from snowflake.account_usage.tag_references (without lineage)
    • select * from table(information_schema.tag_references_all_columns('my_table', 'table'))

Propagation

  • Unlike inheritance, tag propagation allows object-dependency and/or data-movement based tag assignment
  • tags can optionally automatically propagate on_dependency, on_data_movement or on_dependency_and_data_movement
  • conflicts can occur due to multiple sources deriving target value. Three options to resolve conflicts
    1. replace the tag value with string CONFLICT (default)
    2. replace the tag value with user specified string CREATE TAG ... ON_CONFLICT = 'CONFIDENTIAL'
    3. using ordering of the allowed values: ... on_conflict = allowed_value_sequence. The value at the beginning of the list is given priority.
      • e.g. given allowed_values 'confidential', 'internal', 'public', conflict between internal and public will use internal
      • use event table to monitor tag propagation