Spanner 세분화된 액세스 제어를 통해 Identity and Access Management(IAM)의 이점을 SQL 역할 기반 액세스 제어와 함께 활용합니다. 세분화된 액세스 제어를 통해 데이터베이스 역할을 정의하고, 역할에 권한을 부여하고, IAM 정책을 생성하여 IAM 주 구성원에게 데이터베이스 역할에 대한 권한을 부여합니다. 이 페이지에서는 GoogleSQL 언어 데이터베이스 및 PostgreSQL 언어 데이터베이스에 대해 Spanner를 사용하여 세분화된 액세스 제어를 사용하는 방법을 설명합니다.
관리자가 개별 IAM 주 구성원마다 세분화된 액세스 제어를 사용 설정해야 합니다. 세분화된 액세스 제어가 사용 설정된 주 구성원('세분화된 액세스 제어 사용자')은 Spanner 리소스에 액세스할 수 있는 데이터베이스 역할을 맡아야 합니다.
세분화된 액세스 제어 사용자가 아닌 사용자의 리소스 액세스는 IAM 데이터베이스 수준 역할로 제어됩니다.
세분화된 액세스 제어는 완전히 호환되며 기존 IAM 데이터베이스 수준 액세스 제어와 공존할 수 있습니다. 이를 사용하여 개별 데이터베이스 객체를 정의할 수 있습니다. 전체 데이터베이스에 대한 액세스를 제어하려면 IAM 역할을 사용합니다.
세분화된 액세스 제어를 통해 테이블, 열, 보기 및 변경 내역에 대한 액세스를 제어할 수 있습니다.
세분화된 액세스 제어를 관리하려면 다음 DDL 문을 사용합니다.
데이터베이스 역할 만들기 및 삭제를 위한 CREATE 및 DROP 문.
데이터베이스 역할은 권한 모음입니다. 데이터베이스 하나에 최대 100개의 역할을 만들 수 있습니다.
데이터베이스 역할에 대해 권한을 부여하거나 취소하는 GRANT 및 REVOKE 문. 권한에는 SELECT, INSERT, UPDATE, DELETE, EXECUTE가 포함됩니다. 권한 이름은 비슷한 이름의 SQL 문에 해당합니다. 예를 들어 INSERT 권한이 있는 역할은 GRANT 문에 지정된 테이블에서 INSERT SQL 문을 실행할 수 있습니다.
다음 DDL 문은 hr_rep 데이터베이스 역할에 대해 employees 테이블에 SELECT 권한을 부여합니다.
스키마에 대한 USAGE 권한을 특정 데이터베이스 역할에 부여할 수 있습니다. 기본이 아닌 스키마의 경우 데이터베이스 역할에는 데이터베이스 객체에 액세스할 수 있도록 USAGE 권한이 있어야 합니다. 권한 확인은 다음과 같습니다.
스키마에 USAGE가 있나요?
아니요: 액세스를 거부합니다.
예: 테이블에 대한 적절한 권한도 있나요?
아니요: 액세스를 거부합니다.
예: 테이블에 액세스할 수 있습니다.
테이블
데이터베이스 역할에 테이블에 대한 SELECT, INSERT, UPDATE, DELETE 권한을 부여할 수 있습니다. 인터리브 처리된 테이블의 경우 상위 테이블에 부여된 권한은 하위 테이블에 전파되지 않습니다.
열
테이블의 열 하위 집합에 대한 SELECT, INSERT, UPDATE를 부여할 수 있습니다. 이 권한은 해당 열에 대해서만 유효합니다. 열 수준에서는 DELETE가 허용되지 않습니다.
뷰
뷰에 대한 SELECT 권한을 부여할 수 있습니다. SELECT만 뷰에 대해 지원됩니다. Spanner는 호출자의 권한 뷰와 정의자의 권한 뷰를 모두 지원합니다. 호출자 권한으로 뷰를 만드는 경우 뷰를 쿼리하려면 데이터베이스 역할 또는 사용자에게 해당 뷰에 대한 SELECT 권한과 뷰에서 참조된 기본 객체에 대한 SELECT 권한이 필요합니다. 정의자 권한으로 뷰를 만드는 경우 뷰를 쿼리하려면 데이터베이스 역할이나 사용자에게 뷰에 대한 SELECT 권한만 필요합니다. 자세한 내용은 뷰 개요를 참조하세요.
변경 스트림
변경 내역에 대한 SELECT를 부여할 수 있습니다. 변경 내역과 연결된 읽기 함수에 EXECUTE를 부여해야 합니다. 자세한 내용은 변경 내역에 대해 세분화된 액세스 제어를 참조하세요.
세분화된 액세스 제어에는 데이터베이스별로 사전 정의된 시스템 역할이 있습니다.
사용자 정의 데이터베이스 역할과 같이 시스템 역할에서 Spanner 리소스에 대한 액세스를 제어할 수 있습니다.
예를 들어 Key Visualizer에 액세스하려면 세분화된 액세스 제어 사용자에게 spanner_sys_reader 시스템 역할을 부여해야 하며 INFORMATION_SCHEMA 테이블을 쿼리할 때 필터링되지 않은 결과를 볼 수 있으려면 spanner_info_reader 시스템 역할이 필요합니다.
hr_manager 및 hr_director는 pii_access 역할의 구성원이고 employees 테이블에서 SELECT 권한을 상속합니다.
또한 hr_manager 및 hr_director도 구성원을 가질 수 있고 이러한 구성원은 employees의 SELECT 권한을 상속합니다.
역할 계층 구조의 깊이는 제한이 없지만 역할 계층 구조가 깊고 광범위한 경우 쿼리 성능이 저하될 수 있습니다.
백업 및 복원
Spanner 백업에는 데이터베이스 역할 정의가 포함됩니다. 백업에서 데이터베이스가 복원되면 부여된 권한으로 데이터베이스 역할이 다시 생성됩니다. 하지만 IAM 정책이 데이터베이스 백업에 포함되지 않으므로 복원된 데이터베이스에서 주 구성원에 대해 데이터베이스 역할에 대해 액세스를 다시 부여해야 합니다.
세분화된 액세스 제어 설정 개요
다음에서는 세분화된 액세스 제어로 데이터를 보호하는 단계를 간략하게 설명합니다. 자세한 내용은 세분화된 액세스 제어 구성을 참조하세요.
이 태스크를 수행하려면 roles/spanner.admin 또는 roles/spanner.databaseAdmin IAM 역할이 부여되어야 합니다.
데이터베이스 역할을 만들고 이 역할에 권한을 부여합니다.
선택사항: 역할을 다른 역할에 부여하여 상속성이 있는 역할 계층 구조를 만듭니다.
세분화된 액세스 제어 사용자로 설정할 각 주 구성원에 대해 이 단계를 수행합니다.
주 구성원에 대해 세분화된 액세스 제어를 사용 설정합니다.
그러면 주 구성원에 기본적으로 권한이 없는 public 데이터베이스 역할이 자동으로 부여됩니다. 이 작업은 각 주 구성원에 대해 한 번만 수행하면 됩니다.
주 구성원에 대해 하나 이상의 데이터베이스 역할에 대한 IAM 권한을 부여합니다.
주 구성원에 모든 필수 데이터베이스 역할을 부여한 후, 주 구성원에 데이터베이스 수준의 IAM 역할이 있으면 주 구성원의 액세스 제어가 하나의 메서드로만 관리되도록 데이터베이스 수준 역할을 취소하는 것이 좋습니다.
제한사항
내보내기 작업은 데이터베이스 역할 및 권한을 내보내지 않으며 가져오기 작업으로 이를 가져올 수 없습니다. 가져오기가 완료된 후에 역할과 권한을 수동으로 설정해야 합니다.
Google Cloud 콘솔에서 TABLE 페이지의 데이터 탭은 세분화된 액세스 제어 사용자에게 제공되지 않습니다.
[[["이해하기 쉬움","easyToUnderstand","thumb-up"],["문제가 해결됨","solvedMyProblem","thumb-up"],["기타","otherUp","thumb-up"]],[["이해하기 어려움","hardToUnderstand","thumb-down"],["잘못된 정보 또는 샘플 코드","incorrectInformationOrSampleCode","thumb-down"],["필요한 정보/샘플이 없음","missingTheInformationSamplesINeed","thumb-down"],["번역 문제","translationIssue","thumb-down"],["기타","otherDown","thumb-down"]],["최종 업데이트: 2025-09-05(UTC)"],[],[],null,["# Fine-grained access control overview\n\nSpanner fine-grained access control combines the benefits of\n[Identity and Access Management](/iam/docs) (IAM) with\nSQL role-based access control. With fine-grained access control, you define\ndatabase roles, grant privileges to the roles, and create\nIAM policies to grant permissions on database roles to\nIAM principals. This page describes how to use fine-grained access control\nwith Spanner for GoogleSQL-dialect databases and PostgreSQL-dialect databases.\n\nAs an administrator, you must enable fine-grained access control for individual IAM\nprincipals. Principals\nfor whom fine-grained access control is enabled (\"fine-grained access control users\") must assume a database\nrole to access Spanner resources.\n\nResource access for users who are are not fine-grained access control users is governed\nby IAM database-level roles.\nFine-grained access control is fully compatible and can co-exist with existing\nIAM database-level access control. You can use it to access\nindividual database objects. To control access to the entire database, use\n[IAM roles](/spanner/docs/iam).\n| **Note:** Spanner relies on IAM for identity management rather than managing user credentials within the database.\n\nWith fine-grained access control, you can control access to tables, columns, views, and\nchange streams.\n\nTo manage fine-grained access control, you use the following DDL\nstatements:\n\n- `CREATE` and `DROP` statements for creating and dropping database roles. Database roles are collections of privileges. You can create up to 100 roles for a database.\n- `GRANT` and `REVOKE` statements to grant and revoke privileges to and from\n database roles. Privileges include `SELECT`, `INSERT`, `UPDATE`, `DELETE`, and\n `EXECUTE`. Privilege names\n correspond to the like-named SQL statements. For example, a role with the\n `INSERT` privilege can execute the `INSERT` SQL statement on the tables that\n are specified in the `GRANT` statement.\n\n The following DDL statements grant `SELECT` on table `employees`\n to the `hr_rep` database role. \n\n ### GoogleSQL\n\n CREATE ROLE hr_rep;\n GRANT SELECT ON TABLE employees TO ROLE hr_rep;\n\n ### PostgreSQL\n\n CREATE ROLE hr_rep;\n GRANT SELECT ON TABLE employees TO hr_rep;\n\n For more information on privileges, see\n [Fine-grained access control privileges reference](/spanner/docs/fgac-privileges).\n- `GRANT` statements for granting roles to other roles to create hierarchies of\n roles, with privilege inheritance.\n\nUse cases\n---------\n\nThe following are sample use cases for fine-grained access control:\n\n- An HR information system that has roles for sales compensation analyst, sales management, and HR analyst, each with different access levels on the data. For example, compensation analysts and sales management shouldn't see social security numbers.\n- A ride-sharing application with different service accounts and privileges for riders and drivers.\n- A ledger that permits `SELECT` and `INSERT` operations but not `UPDATE` and `DELETE` operations.\n\nSpanner resources and their privileges\n--------------------------------------\n\nThe following is a list of Spanner resources and the [fine-grained access control\nprivileges](/spanner/docs/fgac-privileges) that you can grant for them.\n\nSchemas\n: You can grant the `USAGE` privilege on schemas to specific database roles. For\n a non-default schema, database roles must have the `USAGE` privilege to access\n the database objects. The privilege check looks like the following:\n\nDo you have `USAGE` on the schema?\n\nNo: Reject access.\n\nYes: Do you also have the appropriate rights on the table?\n\nNo: Reject access.\n\nYes: You can access the table.\n| **Note:** You can use `ALL` to bulk grant privileges on all objects that use the same type in the schema. If you later add objects, you must grant privileges to the new objects as you add them.\n\nTables\n: You can grant the `SELECT`, `INSERT`, `UPDATE`, and `DELETE` privileges on\n tables to database roles. For interleaved tables, a privilege granted on the\n parent table doesn't propagate to the child table.\n\nColumns\n: You can grant `SELECT`, `INSERT`, and `UPDATE` on a subset of columns in a\n table. The privilege is then valid only for those columns. `DELETE` is not\n permitted at the column level.\n\nViews\n: You can grant `SELECT` privilege on a view. Only `SELECT` is supported for\n views. Spanner supports both invoker's rights views and definer's\n rights views. If you create a view with invoker's rights, to query the view, the\n database role or user needs the `SELECT` privilege on the view, and also the\n `SELECT` privilege on the underlying objects referenced in the view. If you\n create a view with definer's rights, to query the view, the database role or\n user only needs the `SELECT` privilege on the view. For more information, see\n [Views overview](/spanner/docs/views).\n\nChange streams\n: You can grant `SELECT` on change streams. You must also grant `EXECUTE` on the\n read function associated with a change stream. For information,\n see [Fine-grained access control for change streams](/spanner/docs/fgac-change-streams).\n\nSequences\n: You can grant `SELECT` and `UPDATE` on sequences. For information,\n see [Fine-grained access control for sequences](/spanner/docs/fgac-sequences).\n\nModels\n: You can grant `EXECUTE` on models. For information,\n see [Fine-grained access control for models](/spanner/docs/fgac-models).\n\nFine-grained access control system roles\n----------------------------------------\n\nFine-grained access control has predefined *system roles* for each database.\nLike user-defined database roles, system roles can control access to\nSpanner resources.\n\nFor example, a fine-grained access control user needs to be granted the `spanner_sys_reader`\nsystem role to access Key Visualizer, and needs the `spanner_info_reader` system\nrole to be able to see unfiltered results when querying the\n`INFORMATION_SCHEMA` tables.\n\nFor more information, see [Fine-grained access control system roles](/spanner/docs/fgac-system-roles).\n\nDatabase role hierarchies and inheritance\n-----------------------------------------\n\nYou can create hierarchies of database roles, where child roles\ninherit the privileges of parent roles. Child roles are known as *members* of\nthe parent role.\n\nFor example, consider the following `GRANT` statements: \n\n### GoogleSQL\n\n GRANT SELECT ON TABLE employees TO ROLE pii_access;\n GRANT ROLE pii_access TO ROLE hr_manager, hr_director;\n\n### PostgreSQL\n\n GRANT SELECT ON TABLE employees TO pii_access;\n GRANT pii_access TO hr_manager, hr_director;\n\n`hr_manager` and `hr_director` are members of role `pii_access`, and inherit the\n`SELECT` privilege on table `employees`.\n\n`hr_manager` and `hr_director` can also have members, and those members would\ninherit the `SELECT` privilege on `employees`.\n\nThere are no limits on the depth of role hierarchies, but query performance\nmight degrade with deep and wide role hierarchy structures.\n\nBackup and restore\n------------------\n\nSpanner [backups](/spanner/docs/backup) include database role\ndefinitions. When a database is restored from backup, database roles\nare re-created with their granted privileges. However, IAM\npolicies are not a part of database backups, so you must re-grant access to\ndatabase roles to principals in the restored database.\n\nOverview of setting up fine-grained access control\n--------------------------------------------------\n\nThe following are the high-level steps that you take to begin\nsecuring data with fine-grained access control. For details, see\n[Configure fine-grained access control](/spanner/docs/configure-fgac).\n\nYou must be granted the `roles/spanner.admin` or\n`roles/spanner.databaseAdmin` IAM roles to perform these tasks.\n\n1. Create database roles and grant privileges to the roles.\n2. Optional: Create role hierarchies with inheritance by granting roles to other roles.\n3. Perform these steps for each principal who is to be a fine-grained access control user:\n 1. Enable fine-grained access control for the principal. The principal is then automatically granted the `public` database role, which has no privileges by default. This is a one-time operation for each principal.\n 2. Grant IAM permissions on one or more database roles to the principal.\n 3. After the principal is granted all required database roles, if the principal has database-level IAM roles, consider revoking the database-level roles so that the principal's access control is managed by only one method.\n\nLimitations\n-----------\n\n- Export operations don't export database roles and privileges, and import operations can't import them. You must manually set up roles and privileges after your import is complete.\n- The **Data** tab on the **TABLE** page in the Google Cloud console is not available for fine-grained access control users.\n\nWhat's next\n-----------\n\n- [Access a database with fine-grained access control](/spanner/docs/access-with-fgac)\n- [Fine-grained access control for change streams](/spanner/docs/fgac-change-streams)\n- [Configure fine-grained access control](/spanner/docs/configure-fgac)\n- [Fine-grained access control privileges reference](/spanner/docs/fgac-privileges)\n- [Fine-grained access control system roles](/spanner/docs/fgac-system-roles)\n- [GoogleSQL `GRANT` and `REVOKE` statements](/spanner/docs/reference/standard-sql/data-definition-language#grant_and_revoke_statements)\n- [PostgreSQL `GRANT` and `REVOKE` statements](/spanner/docs/reference/postgresql/data-definition-language#grant_and_revoke_statements)\n- [Fine-grained access control for sequences](/spanner/docs/fgac-sequences)\n- [Fine-grained access control for models](/spanner/docs/fgac-models)"]]
