8.2.10 Using Roles

8.2.10 Using Roles

MySQL role은 권한들의 이름이 있는 집합입니다. 사용자 계정과 마찬가지로, role에는 권한을 부여하거나 회수할 수 있습니다.

사용자 계정에는 role을 부여할 수 있으며, 이를 통해 각 role에 연관된 권한이 계정에 부여됩니다. 이렇게 하면 계정에 권한 집합을 할당할 수 있고, 개별 권한을 부여하는 것에 비해 개념적으로나 구현 측면에서 모두 더 편리한 대안이 됩니다.

다음 목록은 MySQL이 제공하는 role 관리 기능을 요약한 것입니다:

• CREATE ROLE 및 DROP ROLE은 role을 생성하고 제거합니다.

• GRANT 및 REVOKE는 사용자 계정과 role에 대해 권한을 부여하거나 회수합니다.

• SHOW GRANTS는 사용자 계정과 role에 대한 권한 및 role 할당을 표시합니다.

• SET DEFAULT ROLE은 기본적으로 어떤 계정 role이 활성 상태인지를 지정합니다.

• SET ROLE은 현재 세션 내에서 활성 role을 변경합니다.

• CURRENT_ROLE() 함수는 현재 세션 내에서 활성 role을 표시합니다.

• mandatory_roles 및 activate_all_roles_on_login 시스템 변수를 사용하면 필수 role을 정의하고, 사용자가 서버에 로그인할 때 부여된 role을 자동으로 활성화하도록 설정할 수 있습니다.

개별 role 조작 구문(이를 사용하기 위해 필요한 권한 포함)에 대한 설명은 Section 15.7.1, “Account Management Statements”를 참조하십시오. 다음 설명에서는 role 사용 예제를 제공합니다. 별도로 명시하지 않는 한, 여기에 제시된 SQL 구문은 root 계정과 같이 충분한 관리 권한을 가진 MySQL 계정을 사용하여 실행해야 합니다.

• Creating Roles and Granting Privileges to Them
• Defining Mandatory Roles
• Checking Role Privileges
• Activating Roles
• Revoking Roles or Role Privileges
• Dropping Roles
• User and Role Interchangeability

Creating Roles and Granting Privileges to Them

다음 시나리오를 생각해 보십시오:

• 어떤 애플리케이션이 app_db라는 데이터베이스를 사용합니다.

• 해당 애플리케이션과 관련하여, 애플리케이션을 생성 및 유지관리하는 개발자용 계정과, 애플리케이션과 상호작용하는 사용자용 계정이 있을 수 있습니다.

• 개발자는 데이터베이스에 대한 전체 액세스가 필요합니다. 일부 사용자는 읽기 전용 액세스만 필요하고, 다른 사용자는 읽기/쓰기 액세스가 필요합니다.

많은 사용자 계정에 권한을 개별적으로 부여하지 않으려면, 필요한 권한 집합에 대한 이름으로서 role을 생성하십시오. 이렇게 하면 적절한 role을 부여하는 방식으로 사용자 계정에 필요한 권한을 쉽게 부여할 수 있습니다.

role을 생성하려면 CREATE ROLE 구문을 사용합니다:

1CREATE ROLE 'app_developer', 'app_read', 'app_write';

role 이름은 사용자 계정 이름과 매우 비슷하며, 'user_name'@'host_name' 형식의 사용자 부분과 호스트 부분으로 구성됩니다. 호스트 부분을 생략하면 기본값은 '%'입니다. 사용자와 호스트 부분은 -나 %와 같은 특수 문자를 포함하지 않는 한 따옴표 없이 사용할 수 있습니다. 계정 이름과 달리, role 이름의 사용자 부분은 비어 있을 수 없습니다. 추가 정보는 Section 8.2.5, “Specifying Role Names”를 참조하십시오.

role에 권한을 할당하려면 사용자 계정에 권한을 할당할 때와 동일한 구문을 사용하여 GRANT 구문을 실행합니다:

1GRANT ALL ON app_db.* TO 'app_developer';
2GRANT SELECT ON app_db.* TO 'app_read';
3GRANT INSERT, UPDATE, DELETE ON app_db.* TO 'app_write';

이제 처음에는 개발자 계정 1개, 읽기 전용 액세스가 필요한 사용자 계정 2개, 읽기/쓰기 액세스가 필요한 사용자 계정 1개가 필요하다고 가정해 보겠습니다. CREATE USER를 사용하여 계정을 생성합니다:

1CREATE USER 'dev1'@'localhost' IDENTIFIED BY 'dev1pass';
2CREATE USER 'read_user1'@'localhost' IDENTIFIED BY 'read_user1pass';
3CREATE USER 'read_user2'@'localhost' IDENTIFIED BY 'read_user2pass';
4CREATE USER 'rw_user1'@'localhost' IDENTIFIED BY 'rw_user1pass';

각 사용자 계정에 필요한 권한을 할당하려면, 직전에 보여 준 형식과 동일한 GRANT 구문을 사용할 수 있지만, 그러려면 각 사용자에 대해 개별 권한을 나열해야 합니다. 대신 권한이 아니라 role을 부여할 수 있는 대체 GRANT 구문을 사용하십시오:

1GRANT 'app_developer' TO 'dev1'@'localhost';
2GRANT 'app_read' TO 'read_user1'@'localhost', 'read_user2'@'localhost';
3GRANT 'app_read', 'app_write' TO 'rw_user1'@'localhost';

rw_user1 계정에 대한 GRANT 구문은 읽기 및 쓰기 role을 부여하며, 이 두 role은 결합되어 필요한 읽기 및 쓰기 권한을 제공합니다.

계정에 role을 부여하기 위한 GRANT 구문은 권한을 부여하기 위한 구문과 다릅니다. 권한을 부여할 때는 ON 절이 있지만, role을 부여할 때는 ON 절이 없습니다. 이 두 구문은 구분되므로 동일한 구문에서 권한과 role을 함께 부여할 수는 없습니다. (계정에 권한과 role을 모두 부여하는 것은 허용되지만, 각각에 적합한 구문을 사용하는 별도의 GRANT 구문을 사용해야 합니다.) role은 anonymous 사용자에게는 부여할 수 없습니다.

role은 생성 시 잠금 상태이며 패스워드가 없고 기본 인증 플러그인이 할당됩니다. (이러한 role 속성은 global CREATE USER 권한을 가진 사용자가 ALTER USER 구문을 사용하여 나중에 변경할 수 있습니다.)

잠금 상태일 때는 role을 사용하여 서버에 인증할 수 없습니다. 잠금이 해제된 상태라면 role을 사용하여 인증할 수 있습니다. 그 이유는 role과 사용자가 모두 인증 식별자이며 공통점이 많고 차이점이 거의 없기 때문입니다. User and Role Interchangeability도 참조하십시오.

Defining Mandatory Roles

mandatory_roles 시스템 변수 값에 role 이름을 지정하여 이를 필수로 설정할 수 있습니다. 서버는 필수 role을 모든 사용자에게 부여된 것으로 처리하므로, 어떤 계정에도 명시적으로 부여할 필요가 없습니다.

서버 시작 시 필수 role을 지정하려면, 서버의 my.cnf 파일에서 mandatory_roles를 정의합니다:

1[mysqld]
2mandatory_roles='role1,role2@localhost,r3@%.example.com'

런타임 중에 mandatory_roles를 설정하고 이를 지속시키려면 다음과 같은 구문을 사용합니다:

1SET PERSIST mandatory_roles = 'role1,role2@localhost,r3@%.example.com';

SET PERSIST는 실행 중인 MySQL 인스턴스에 대한 값을 설정합니다. 또한 이 값을 저장하여 이후 서버 재시작 시에도 이어지도록 합니다. 실행 중인 MySQL 인스턴스에 대한 값만 변경하고 이후 재시작 시에는 이어지지 않게 하려면, PERSIST 대신 GLOBAL 키워드를 사용하십시오. Section 15.7.6.1, “SET Syntax for Variable Assignment”를 참조하십시오.

mandatory_roles를 설정하려면 SYSTEM_VARIABLES_ADMIN 권한에 더해 global 시스템 변수를 설정할 때 일반적으로 필요한 더 이상 사용되지 않는 권한인 SUPER 권한 또는 ROLE_ADMIN 권한이 필요합니다.

필수 role은 명시적으로 부여된 role과 마찬가지로, 활성화되기 전까지는 효력이 없습니다(Activating Roles 참조). 로그인 시점에는 activate_all_roles_on_login 시스템 변수가 활성화되어 있으면 부여된 모든 role이 활성화되고, 그렇지 않으면 기본 role로 설정된 role이 활성화됩니다. 런타임 중에는 SET ROLE이 role을 활성화합니다.

mandatory_roles 값에 지정된 role은 REVOKE로 회수할 수 없고, DROP ROLE 또는 DROP USER로 삭제할 수도 없습니다.

세션이 기본적으로 시스템 세션이 되는 것을 막기 위해, SYSTEM_USER 권한을 가진 role은 mandatory_roles 시스템 변수의 값에 나열될 수 없습니다:

• mandatory_roles에 시작 시점에 SYSTEM_USER 권한을 가진 role이 지정되면, 서버는 오류 로그에 메시지를 기록하고 종료합니다.

• 런타임 중에 mandatory_roles에 SYSTEM_USER 권한을 가진 role이 지정되면 오류가 발생하며, mandatory_roles 값은 변하지 않습니다.

이러한 보호장치가 있더라도, 권한 상승 가능성을 막기 위해 role을 통해 SYSTEM_USER 권한을 부여하지 않는 것이 좋습니다.

mandatory_roles에 지정된 role이 mysql.user 시스템 테이블에 존재하지 않으면, 해당 role은 사용자에게 부여되지 않습니다. 서버가 사용자에 대해 role을 활성화하려고 시도할 때, 서버는 존재하지 않는 role을 필수로 처리하지 않으며 오류 로그에 경고를 기록합니다. 나중에 해당 role이 생성되어 유효해지면, 서버가 이를 필수로 처리하도록 FLUSH PRIVILEGES를 실행해야 할 수 있습니다.

SHOW GRANTS는 Section 15.7.7.23, “SHOW GRANTS Statement”에 설명된 규칙에 따라 필수 role을 표시합니다.

Checking Role Privileges

계정에 할당된 권한을 확인하려면 SHOW GRANTS를 사용합니다. 예를 들면 다음과 같습니다:

1mysql> SHOW GRANTS FOR 'dev1'@'localhost';
2+-------------------------------------------------+
3| Grants for dev1@localhost                       |
4+-------------------------------------------------+
5| GRANT USAGE ON *.* TO `dev1`@`localhost`        |
6| GRANT `app_developer`@`%` TO `dev1`@`localhost` |
7+-------------------------------------------------+

그러나 위 출력은 각 부여된 role을 role이 나타내는 권한으로 “전개”하지 않고 role 자체만 표시합니다. role 권한도 함께 표시하려면, 권한을 표시할 부여된 role 이름을 USING 절에 지정하십시오:

1mysql> SHOW GRANTS FOR 'dev1'@'localhost' USING 'app_developer';
2+----------------------------------------------------------+
3| Grants for dev1@localhost                                |
4+----------------------------------------------------------+
5| GRANT USAGE ON *.* TO `dev1`@`localhost`                 |
6| GRANT ALL PRIVILEGES ON `app_db`.* TO `dev1`@`localhost` |
7| GRANT `app_developer`@`%` TO `dev1`@`localhost`          |
8+----------------------------------------------------------+

다른 유형의 사용자에 대해서도 이와 유사하게 확인합니다:

1mysql> SHOW GRANTS FOR 'read_user1'@'localhost' USING 'app_read';
2+--------------------------------------------------------+
3| Grants for read_user1@localhost                        |
4+--------------------------------------------------------+
5| GRANT USAGE ON *.* TO `read_user1`@`localhost`         |
6| GRANT SELECT ON `app_db`.* TO `read_user1`@`localhost` |
7| GRANT `app_read`@`%` TO `read_user1`@`localhost`       |
8+--------------------------------------------------------+
9mysql> SHOW GRANTS FOR 'rw_user1'@'localhost' USING 'app_read', 'app_write';
10+------------------------------------------------------------------------------+
11| Grants for rw_user1@localhost                                                |
12+------------------------------------------------------------------------------+
13| GRANT USAGE ON *.* TO `rw_user1`@`localhost`                                 |
14| GRANT SELECT, INSERT, UPDATE, DELETE ON `app_db`.* TO `rw_user1`@`localhost` |
15| GRANT `app_read`@`%`,`app_write`@`%` TO `rw_user1`@`localhost`               |
16+------------------------------------------------------------------------------+

SHOW GRANTS는 Section 15.7.7.23, “SHOW GRANTS Statement”에 설명된 규칙에 따라 필수 role을 표시합니다.

Activating Roles

사용자 계정에 부여된 role은 계정 세션 내에서 활성 상태일 수도 있고 비활성 상태일 수도 있습니다. 부여된 role이 세션 내에서 활성 상태이면 해당 role의 권한이 적용되고, 그렇지 않으면 적용되지 않습니다. 현재 세션 내에서 어떤 role이 활성 상태인지 확인하려면 CURRENT_ROLE() 함수를 사용하십시오.

기본적으로, 계정에 role을 부여하거나 mandatory_roles 시스템 변수 값에 role을 지정하더라도, 그 role이 계정 세션 내에서 자동으로 활성 상태가 되지는 않습니다. 예를 들어, 지금까지 앞선 설명에서는 rw_user1의 role을 아무것도 활성화하지 않았으므로, 서버에 rw_user1로 연결한 후 CURRENT_ROLE() 함수를 호출하면 결과는 NONE(활성 role 없음)이 됩니다:

1mysql> SELECT CURRENT_ROLE();
2+----------------+
3| CURRENT_ROLE() |
4+----------------+
5| NONE           |
6+----------------+

사용자가 서버에 연결하여 인증할 때마다 어떤 role이 활성 상태가 되어야 하는지 지정하려면 SET DEFAULT ROLE를 사용합니다. 앞에서 생성한 각 계정에 대해 기본값을 모든 할당된 role로 설정하려면 다음 구문을 사용합니다:

1SET DEFAULT ROLE ALL TO
2  'dev1'@'localhost',
3  'read_user1'@'localhost',
4  'read_user2'@'localhost',
5  'rw_user1'@'localhost';

이제 rw_user1로 연결하면, CURRENT_ROLE()의 초기 값은 새로운 기본 role 할당을 반영합니다:

1mysql> SELECT CURRENT_ROLE();
2+--------------------------------+
3| CURRENT_ROLE()                 |
4+--------------------------------+
5| `app_read`@`%`,`app_write`@`%` |
6+--------------------------------+

사용자가 서버에 연결할 때 부여된 모든 role과 필수 role을 자동으로 활성화하려면 activate_all_roles_on_login 시스템 변수를 활성화하십시오. 기본적으로 자동 role 활성화는 비활성화되어 있습니다.

세션 내에서 사용자는 SET ROLE을 실행하여 활성 role 집합을 변경할 수 있습니다. 예를 들어, rw_user1에 대해 다음과 같이 할 수 있습니다:

1mysql> SET ROLE NONE; SELECT CURRENT_ROLE();
2+----------------+
3| CURRENT_ROLE() |
4+----------------+
5| NONE           |
6+----------------+
7mysql> SET ROLE ALL EXCEPT 'app_write'; SELECT CURRENT_ROLE();
8+----------------+
9| CURRENT_ROLE() |
10+----------------+
11| `app_read`@`%` |
12+----------------+
13mysql> SET ROLE DEFAULT; SELECT CURRENT_ROLE();
14+--------------------------------+
15| CURRENT_ROLE()                 |
16+--------------------------------+
17| `app_read`@`%`,`app_write`@`%` |
18+--------------------------------+

첫 번째 SET ROLE 구문은 모든 role을 비활성화합니다. 두 번째 구문은 rw_user1을 사실상 읽기 전용으로 만듭니다. 세 번째 구문은 기본 role을 복원합니다.

저장 프로시저 및 뷰 객체에 대한 실제 사용자는 호출자 또는 정의자 컨텍스트에서 실행되는지를 결정하는 DEFINER 및 SQL SECURITY 속성에 의해 영향을 받습니다 (Section 27.8, “Stored Object Access Control” 참조):

• 호출자 컨텍스트에서 실행되는 저장 프로시저 및 뷰 객체는 현재 세션 내에서 활성 상태인 role과 함께 실행됩니다.

• 정의자 컨텍스트에서 실행되는 저장 프로시저 및 뷰 객체는 DEFINER 속성에 지정된 사용자의 기본 role과 함께 실행됩니다. activate_all_roles_on_login이 활성화되어 있으면, 이러한 객체는 필수 role을 포함하여 DEFINER 사용자에 부여된 모든 role과 함께 실행됩니다. 저장 프로시저의 경우, 기본과 다른 role로 실행해야 한다면 프로시저 본문에서 SET ROLE을 실행하여 필요한 role을 활성화할 수 있습니다. role에 할당된 권한은 변경될 수 있으므로, 이 작업은 주의를 기울여 수행해야 합니다.

Revoking Roles or Role Privileges

role이 계정에 부여될 수 있는 것처럼, 계정에서 role을 회수할 수도 있습니다:

1REVOKE role FROM user;

mandatory_roles 시스템 변수 값에 지정된 role은 회수할 수 없습니다.

REVOKE는 role에 적용하여 해당 role에 부여된 권한을 수정할 수도 있습니다. 이는 role 자체뿐 아니라 그 role이 부여된 모든 계정에도 영향을 미칩니다. 예를 들어, 모든 애플리케이션 사용자를 일시적으로 읽기 전용으로 만들고자 한다고 가정해 보겠습니다. 이를 위해 REVOKE를 사용하여 app_write role에서 수정 권한을 회수할 수 있습니다:

1REVOKE INSERT, UPDATE, DELETE ON app_db.* FROM 'app_write';

이렇게 하면 결과적으로 role에는 아무 권한도 남지 않게 되며, 이는 SHOW GRANTS를 사용하여 확인할 수 있습니다(이 예제는 이 구문이 사용자뿐 아니라 role에도 사용할 수 있음을 보여 줍니다):

1mysql> SHOW GRANTS FOR 'app_write';
2+---------------------------------------+
3| Grants for app_write@%                |
4+---------------------------------------+
5| GRANT USAGE ON *.* TO `app_write`@`%` |
6+---------------------------------------+

role에서 권한을 회수하면 해당 role이 부여된 모든 사용자의 권한에도 영향을 미치므로, rw_user1은 이제 테이블 수정 권한을 전혀 가지지 않게 됩니다 (INSERT, UPDATE, DELETE가 더 이상 존재하지 않음):

1mysql> SHOW GRANTS FOR 'rw_user1'@'localhost'
2       USING 'app_read', 'app_write';
3+----------------------------------------------------------------+
4| Grants for rw_user1@localhost                                  |
5+----------------------------------------------------------------+
6| GRANT USAGE ON *.* TO `rw_user1`@`localhost`                   |
7| GRANT SELECT ON `app_db`.* TO `rw_user1`@`localhost`           |
8| GRANT `app_read`@`%`,`app_write`@`%` TO `rw_user1`@`localhost` |
9+----------------------------------------------------------------+

결과적으로, 읽기/쓰기 사용자인 rw_user1은 읽기 전용 사용자가 됩니다. 이와 같은 일은 app_write role이 부여된 다른 계정에도 모두 발생하며, 이를 통해 role을 사용하면 개별 계정의 권한을 수정할 필요가 없음을 알 수 있습니다.

role에 수정 권한을 다시 부여하려면 단순히 권한을 재부여하면 됩니다:

1GRANT INSERT, UPDATE, DELETE ON app_db.* TO 'app_write';

이제 rw_user1은 다시 수정 권한을 갖게 되며, app_write role이 부여된 다른 계정도 마찬가지입니다.

Dropping Roles

role을 삭제하려면 DROP ROLE을 사용합니다:

1DROP ROLE 'app_read', 'app_write';

role을 삭제하면, 해당 role이 부여된 모든 계정에서 그 role이 회수됩니다.

mandatory_roles 시스템 변수 값에 지정된 role은 삭제할 수 없습니다.

User and Role Interchangeability

사용자 계정 또는 role에 대한 grant를 표시하는 [SHOW GRANTS](https://dev.mysql.com/doc/refman/9.5/en/show-grants.html "15.7.7.23 SHOW GRANTS Statement)에서 이미 암시되었듯이, 계정과 role은 서로 교환하여 사용할 수 있습니다.

role과 사용자의 한 가지 차이점은 [CREATE ROLE](https://dev.mysql.com/doc/refman/9.5/en/create-role.html "15.7.1.2 CREATE ROLE Statement)이 기본적으로 잠겨 있는 인증 식별자를 생성하는 반면, CREATE USER는 기본적으로 잠금 해제된 인증 식별자를 생성한다는 점입니다. 이 구분은 불변의 것이 아니라는 점을 기억해야 합니다. 적절한 권한을 가진 사용자라면 생성 후에 role이나 (다른) 사용자를 잠그거나 잠금 해제할 수 있습니다.

특정 인증 식별자가 반드시 role이어야 한다는 데이터베이스 관리자의 선호가 있다면, 이러한 의도를 전달하기 위해 이름 체계를 사용할 수 있습니다. 예를 들어, role만을 위해 r_ 접두사를 사용하는 방식으로 인증 식별자의 용도를 나타낼 수 있습니다.

role과 사용자 사이의 또 다른 차이점은 이를 관리하기 위해 사용 가능한 권한에 있습니다:

• CREATE ROLE 및 DROP ROLE 권한은 각각 CREATE ROLE 및 DROP ROLE 구문만 사용할 수 있게 합니다.

• CREATE USER 권한은 ALTER USER, CREATE ROLE, CREATE USER, DROP ROLE, DROP USER, RENAME USER, REVOKE ALL PRIVILEGES 구문 사용을 가능하게 합니다.

따라서 CREATE ROLE 및 DROP ROLE 권한은 CREATE USER만큼 강력하지 않으며, role만 생성 및 삭제할 수 있고 보다 일반적인 계정 조작은 수행하지 못하도록 해야 하는 사용자에게 부여할 수 있습니다.

권한 및 사용자와 role의 상호 교환성 측면에서, 사용자 계정을 role처럼 취급하여 해당 계정을 다른 사용자나 role에 grant할 수 있습니다. 그 효과는 그 계정의 권한과 role을 다른 사용자나 role에 부여하는 것입니다.

다음 구문 집합은 사용자를 사용자에, role을 사용자에, 사용자를 role에, role을 role에 grant할 수 있음을 보여 줍니다:

1CREATE USER 'u1';
2CREATE ROLE 'r1';
3GRANT SELECT ON db1.* TO 'u1';
4GRANT SELECT ON db2.* TO 'r1';
5CREATE USER 'u2';
6CREATE ROLE 'r2';
7GRANT 'u1', 'r1' TO 'u2';
8GRANT 'u1', 'r1' TO 'r2';

각 경우의 결과는 grant된 객체에 연관된 권한을 grant 대상 객체에 grant하는 것입니다. 위 구문을 실행한 후에는 u2와 r2 모두 사용자(u1)와 role(r1)에서 grant된 권한을 가지게 됩니다:

1mysql> SHOW GRANTS FOR 'u2' USING 'u1', 'r1';
2+-------------------------------------+
3| Grants for u2@%                     |
4+-------------------------------------+
5| GRANT USAGE ON *.* TO `u2`@`%`      |
6| GRANT SELECT ON `db1`.* TO `u2`@`%` |
7| GRANT SELECT ON `db2`.* TO `u2`@`%` |
8| GRANT `u1`@`%`,`r1`@`%` TO `u2`@`%` |
9+-------------------------------------+
10mysql> SHOW GRANTS FOR 'r2' USING 'u1', 'r1';
11+-------------------------------------+
12| Grants for r2@%                     |
13+-------------------------------------+
14| GRANT USAGE ON *.* TO `r2`@`%`      |
15| GRANT SELECT ON `db1`.* TO `r2`@`%` |
16| GRANT SELECT ON `db2`.* TO `r2`@`%` |
17| GRANT `u1`@`%`,`r1`@`%` TO `r2`@`%` |
18+-------------------------------------+

앞의 예제는 단지 설명을 위한 것이지만, 사용자 계정과 role의 상호 교환성은 다음과 같은 실제 상황에서 유용하게 사용될 수 있습니다. 어떤 레거시 애플리케이션 개발 프로젝트가 MySQL에 role이 도입되기 전에 시작되어, 해당 프로젝트와 연관된 모든 사용자 계정이 role 부여를 통해서가 아니라 권한을 직접 부여받았다고 가정해 보겠습니다. 이 계정 중 하나는 처음에 다음과 같이 권한을 부여받은 개발자 계정입니다:

1CREATE USER 'old_app_dev'@'localhost' IDENTIFIED BY 'old_app_devpass';
2GRANT ALL ON old_app.* TO 'old_app_dev'@'localhost';

이 개발자가 프로젝트에서 떠나면, 해당 권한을 다른 사용자 또는 개발 활동이 확장된 경우 여러 사용자에 할당해야 하는 상황이 발생합니다. 이 문제를 해결하는 방법에는 다음과 같은 것들이 있습니다:

• role을 사용하지 않는 경우: 원래 개발자가 계정을 사용하지 못하도록 계정 패스워드를 변경하고, 새로운 개발자가 해당 계정을 사용하게 합니다:

1ALTER USER 'old_app_dev'@'localhost' IDENTIFIED BY 'new_password';

• role을 사용하는 경우: 계정을 잠가서 누군가 이 계정을 사용해 서버에 연결하지 못하게 합니다:

1ALTER USER 'old_app_dev'@'localhost' ACCOUNT LOCK;

그런 다음 이 계정을 role처럼 취급합니다. 프로젝트에 새로 참여하는 각 개발자에 대해 새 계정을 생성하고, 여기에 원래 개발자 계정을 grant합니다:

1CREATE USER 'new_app_dev1'@'localhost' IDENTIFIED BY 'new_password';
2GRANT 'old_app_dev'@'localhost' TO 'new_app_dev1'@'localhost';

그 효과는 원래 개발자 계정에 부여된 권한을 새로운 계정에 할당하는 것입니다.