27.8 Stored Object Access Control

27.8 Stored Object Access Control

Stored program(procedure, function, trigger, event)과 view는 사용 전에 정의되며, 참조될 때 그 권한을 결정하는 security context 내에서 실행됩니다. stored object 실행에 적용되는 권한은 그 객체의 DEFINER attribute와 SQL SECURITY characteristic에 의해 제어됩니다.

• The DEFINER Attribute

• The SQL SECURITY Characteristic

• Examples

• Orphan Stored Objects

• Risk-Minimization Guidelines

The DEFINER Attribute

stored object 정의에는 MySQL account를 지정하는 DEFINER attribute를 포함할 수 있습니다. 정의에서 DEFINER attribute를 생략하면, 기본 object definer는 그것을 생성한 사용자입니다.

다음 규칙은 stored object에 대해 DEFINER attribute로 어떤 account를 지정할 수 있는지 결정합니다:

• SET_ANY_DEFINER privilege가 있으면, 어떤 account든지 DEFINER attribute로 지정할 수 있습니다. 해당 account가 존재하지 않으면 경고가 생성됩니다. 추가로, stored object의 DEFINER attribute를 SYSTEM_USER privilege를 가진 account로 설정하려면, SYSTEM_USER privilege를 가지고 있어야 합니다.

• 그렇지 않으면, 허용되는 유일한 account는 자신의 account뿐이며, 이는 literal로 지정하거나 CURRENT_USER 또는 CURRENT_USER()로 지정할 수 있습니다. 다른 어떤 account로도 definer를 설정할 수 없습니다.

존재하지 않는 DEFINER account로 stored object를 생성하면 orphan object가 생성되며, 이는 부정적인 영향을 미칠 수 있습니다. 자세한 내용은 Orphan Stored Objects를 참조하십시오.

The SQL SECURITY Characteristic

stored routine(procedure와 function)과 view의 object 정의에는 SQL SECURITY characteristic을 포함할 수 있으며, 값으로 DEFINER 또는 INVOKER를 사용하여 객체가 definer context 또는 invoker context에서 실행되는지를 지정할 수 있습니다. 정의에서 SQL SECURITY characteristic을 생략하면, 기본값은 definer context입니다.

trigger와 event에는 SQL SECURITY characteristic이 없으며 항상 definer context에서 실행됩니다. server는 필요에 따라 이러한 object를 자동으로 호출하므로, invoking user는 존재하지 않습니다.

definer와 invoker security context는 다음과 같이 다릅니다:

• definer security context에서 실행되는 stored object는 DEFINER attribute에 명시된 account의 권한으로 실행됩니다. 이 권한은 invoking user의 권한과 완전히 다를 수 있습니다. invoker는 object를 참조하기 위한 적절한 권한(예를 들어, stored procedure를 호출하기 위한 EXECUTE 권한 또는 view를 select하기 위한 SELECT 권한)을 가지고 있어야 하지만, object 실행 중에는 invoker의 권한은 무시되고 DEFINER account의 권한만 중요합니다. DEFINER account에 권한이 거의 없다면, object는 수행할 수 있는 작업이 그에 상응하여 제한됩니다. DEFINER account가 (관리자 account와 같은) 매우 높은 권한을 가진 경우, 이 object는 누가 호출하든 상관없이 _강력한 작업_을 수행할 수 있습니다.

• invoker security context에서 실행되는 stored routine 또는 view는 invoker가 권한을 가진 작업만 수행할 수 있습니다. DEFINER attribute는 object 실행에 영향을 미치지 않습니다.

Examples

다음 stored procedure를 살펴보십시오. 이 procedure는 definer security context에서 실행되도록 SQL SECURITY DEFINER로 선언되어 있습니다:

1CREATE DEFINER = 'admin'@'localhost' PROCEDURE p1()
2SQL SECURITY DEFINER
3BEGIN
4  UPDATE t1 SET counter = counter + 1;
5END;

EXECUTE privilege를 p1에 대해 가진 사용자는 누구나 CALL statement로 이를 호출할 수 있습니다. 그러나 p1이 실행될 때는 definer security context에서 실행되므로, DEFINER attribute에 명시된 account인 'admin'@'localhost'의 권한으로 실행됩니다. 이 account는 p1에 대한 EXECUTE privilege와, object body 내에서 참조되는 table t1에 대한 UPDATE privilege를 둘 다 가지고 있어야 합니다. 그렇지 않으면 procedure는 실패합니다.

이제 다음 stored procedure를 살펴보십시오. 이 procedure는 SQL SECURITY characteristic이 INVOKER라는 점을 제외하면 p1과 동일합니다:

1CREATE DEFINER = 'admin'@'localhost' PROCEDURE p2()
2SQL SECURITY INVOKER
3BEGIN
4  UPDATE t1 SET counter = counter + 1;
5END;

p1과 달리, p2는 invoker security context에서 실행되며, 따라서 DEFINER attribute 값과 관계없이 invoking user의 권한으로 실행됩니다. invoker가 p2에 대한 EXECUTE privilege나 table t1에 대한 UPDATE privilege를 갖고 있지 않으면, p2는 실패합니다.

Orphan Stored Objects

orphan stored object란, 그 object의 DEFINER attribute가 존재하지 않는 account를 지정하는 object를 말합니다:

• orphan stored object는 object 생성 시점에 존재하지 않는 DEFINER account를 지정함으로써 생성될 수 있습니다.

• 기존 stored object는 DROP USER statement를 실행하여 object DEFINER account를 drop하거나, RENAME USER statement를 실행하여 object DEFINER account의 이름을 변경함으로써 orphan이 될 수 있습니다.

orphan stored object는 다음과 같은 방식으로 문제가 될 수 있습니다:

• DEFINER account가 존재하지 않기 때문에, object가 definer security context에서 실행될 경우 예상대로 동작하지 않을 수 있습니다:

  • stored routine의 경우, SQL SECURITY 값이 DEFINER이지만 definer account가 존재하지 않으면 routine 실행 시점에 오류가 발생합니다.

  • trigger의 경우, account가 실제로 존재하기 전까지 trigger activation이 발생하는 것은 좋은 생각이 아닙니다. 그렇지 않으면, privilege checking과 관련된 동작이 정의되지 않습니다.

  • event의 경우, account가 존재하지 않으면 event 실행 시점에 오류가 발생합니다.

  • view의 경우, SQL SECURITY 값이 DEFINER이지만 definer account가 존재하지 않으면 view가 참조될 때 오류가 발생합니다.

• object의 DEFINER account가 이후에 object와는 관계없는 목적으로 다시 생성되는 경우, 그 object는 security risk를 초래할 수 있습니다. 이 경우, account는 그 object를 “입양”하게 되며, 적절한 privilege를 통해 의도하지 않았더라도 그 object를 실행할 수 있게 됩니다.

server는 stored object가 orphan이 되도록 하는(아마도 의도치 않은) 작업이나, 현재 orphan 상태인 stored object의 adoption을 유발하는 작업을 방지하기 위해 다음과 같은 account-management security check를 적용합니다:

• DROP USER는 drop하려는 account 중 하나라도 어떤 stored object의 DEFINER attribute로 지정되어 있으면 오류와 함께 실패합니다. (즉, account를 drop하면 stored object가 orphan이 되는 경우 statement는 실패합니다.)

• RENAME USER는 이름을 변경하려는 account 중 하나라도 어떤 stored object의 DEFINER attribute로 지정되어 있으면 오류와 함께 실패합니다. (즉, account 이름을 변경하면 stored object가 orphan이 되는 경우 statement는 실패합니다.)

• CREATE USER는 생성하려는 account 중 하나라도 어떤 stored object의 DEFINER attribute로 지정되어 있으면 오류와 함께 실패합니다. (즉, account를 생성하면 현재 orphan 상태인 stored object를 그 account가 입양하게 되는 경우 statement는 실패합니다.)

특정 상황에서는, 이러한 account-management statement를 실행하면 보통은 실패하더라도 의도적으로 실행해야 할 필요가 있을 수 있습니다. 이를 가능하게 하기 위해, 사용자에게 ALLOW_NONEXISTENT_DEFINER privilege가 있는 경우, 이 privilege는 orphan object security check를 무시하게 하며, statement는 오류 대신 경고와 함께 성공합니다.

MySQL 설치에서 stored object definer로 사용되는 account에 대한 정보를 얻으려면, INFORMATION_SCHEMA를 query하십시오.

다음 query는 DEFINER attribute를 가진 object를 설명하는 INFORMATION_SCHEMA table이 무엇인지 식별합니다:

1mysql> SELECT TABLE_SCHEMA, TABLE_NAME FROM INFORMATION_SCHEMA.COLUMNS
2       WHERE COLUMN_NAME = 'DEFINER';
3+--------------------+------------+
4| TABLE_SCHEMA       | TABLE_NAME |
5+--------------------+------------+
6| information_schema | EVENTS     |
7| information_schema | ROUTINES   |
8| information_schema | TRIGGERS   |
9| information_schema | VIEWS      |
10+--------------------+------------+

이 결과는 어떤 table을 query해야 stored object DEFINER 값이 무엇인지, 그리고 어떤 object가 특정 DEFINER 값을 가지고 있는지를 알 수 있는지를 알려줍니다:

• 각 table에서 어떤 DEFINER 값이 존재하는지 식별하려면, 다음 query를 사용하십시오:

1SELECT DISTINCT DEFINER FROM INFORMATION_SCHEMA.EVENTS;
2SELECT DISTINCT DEFINER FROM INFORMATION_SCHEMA.ROUTINES;
3SELECT DISTINCT DEFINER FROM INFORMATION_SCHEMA.TRIGGERS;
4SELECT DISTINCT DEFINER FROM INFORMATION_SCHEMA.VIEWS;

이 query 결과는 다음과 같은 방식으로 표시되는 어떤 account에 대해서도 중요합니다:

• account가 존재하는 경우, 이를 drop하거나 rename하면 stored object가 orphan이 됩니다. account를 drop하거나 rename하려는 경우, 먼저 이 account와 연관된 stored object를 drop하거나, 다른 definer를 사용하도록 다시 정의하는 것을 고려하십시오.

• account가 존재하지 않는 경우, 이를 생성하면 현재 orphan 상태인 stored object를 입양하게 됩니다. account를 생성하려는 경우, orphan 상태인 object가 이 account와 연관되어야 하는지 고려하십시오. 그렇지 않다면, 다른 definer를 사용하도록 이들을 다시 정의하십시오.

다른 definer로 object를 다시 정의하려면, ALTER EVENT 또는 ALTER VIEW를 사용하여 event와 view의 DEFINER account를 직접 수정할 수 있습니다. stored procedure와 function, 그리고 trigger의 경우에는 다른 DEFINER account를 지정하려면 object를 drop한 뒤 다시 생성해야 합니다.

• 특정 DEFINER account를 가진 object가 무엇인지 식별하려면, 다음 query를 사용하고, 관심 있는 account를 user_name@host_name 대신 지정하십시오:

1SELECT EVENT_SCHEMA, EVENT_NAME FROM INFORMATION_SCHEMA.EVENTS
2WHERE DEFINER = 'user_name@host_name';
3SELECT ROUTINE_SCHEMA, ROUTINE_NAME, ROUTINE_TYPE
4FROM INFORMATION_SCHEMA.ROUTINES
5WHERE DEFINER = 'user_name@host_name';
6SELECT TRIGGER_SCHEMA, TRIGGER_NAME FROM INFORMATION_SCHEMA.TRIGGERS
7WHERE DEFINER = 'user_name@host_name';
8SELECT TABLE_SCHEMA, TABLE_NAME FROM INFORMATION_SCHEMA.VIEWS
9WHERE DEFINER = 'user_name@host_name';

ROUTINES table의 경우, query에는 ROUTINE_TYPE column이 포함되어 출력 row가 DEFINER가 stored procedure에 해당하는지 stored function에 해당하는지를 구분할 수 있습니다.

검색 중인 account가 존재하지 않는다면, 이 query에서 표시되는 object는 모두 orphan object입니다.

Risk-Minimization Guidelines

stored object 생성 및 사용과 관련된 risk potential을 최소화하려면, 다음 guideline을 따르십시오:

• DEFINER attribute가 존재하지 않는 account를 지정하는 object, 즉 orphan stored object를 생성하지 마십시오. 또한, 기존 object의 DEFINER attribute에 지정된 account를 drop하거나 rename하여 stored object가 orphan이 되도록 하지 마십시오.

• stored routine 또는 view의 경우, 가능하면 object 정의에 SQL SECURITY INVOKER를 사용하여, object가 그 object가 수행하는 작업에 대해 적절한 permission을 가진 사용자만 사용할 수 있도록 하십시오.

• account에 SET_ANY_DEFINER privilege가 있을 때 definer-context stored object를 생성하는 경우, object가 수행하는 작업에 필요한 privilege만 가지고 있는 account를 명시하는 explicit DEFINER attribute를 지정하십시오. 매우 높은 권한을 가진 DEFINER account는 꼭 필요한 경우에만 지정하십시오.

• 관리자는 사용자에게 SET_ANY_DEFINER privilege를 부여하지 않음으로써, 사용자가 매우 높은 권한을 가진 DEFINER account를 지정하는 stored object를 생성하지 못하도록 할 수 있습니다.

• definer-context object는, 이들이 invoking user에게는 권한이 없는 data에 접근할 수 있을 수 있다는 점을 염두에 두고 작성해야 합니다. 어떤 경우에는, 허가되지 않은 사용자에게 특정 privilege를 부여하지 않음으로써 이러한 object에 대한 참조를 차단할 수 있습니다:

  • stored routine은 이에 대한 EXECUTE privilege를 가지지 않은 사용자가 참조할 수 없습니다.

  • view는 그 view에 대한 적절한 privilege가 없는 사용자(SELECT로부터 select, INSERT로 insert 등)가 참조할 수 없습니다.

그러나 trigger와 event는 항상 definer context에서 실행되므로, 이에 대해서는 그러한 control이 존재하지 않습니다. server는 필요에 따라 이러한 object를 자동으로 호출하며, 사용자는 이들을 직접 참조하지 않습니다:

• trigger는 그것이 연관된 table에 대한 access에 의해 활성화되며, 특별한 privilege가 없는 사용자에 의한 일반적인 table access도 포함됩니다.

• event는 server에 의해 일정에 따라 실행됩니다.

두 경우 모두, DEFINER account가 매우 높은 권한을 가지고 있다면, object는 민감하거나 위험한 작업을 수행할 수 있습니다. object를 생성하는 데 필요한 privilege가 object를 생성한 사용자의 account에서 revoke된 이후에도 이 사실은 변함이 없습니다. 관리자는 사용자에게 object-creation privilege를 부여할 때 특히 주의해야 합니다.

• 기본적으로, SQL SECURITY DEFINER characteristic을 가진 routine이 실행될 때 MySQL Server는 DEFINER 절에 명시된 MySQL account에 대해 활성 role을 설정하지 않고, default role만 설정합니다. 예외는 activate_all_roles_on_login system variable이 활성화되어 있는 경우로, 이때는 MySQL Server가 DEFINER user에 대해 부여된 모든 role(필수 role 포함)을 설정합니다. 따라서, role을 통해 부여된 privilege는 CREATE PROCEDURE 또는 CREATE FUNCTION statement가 실행될 때 기본적으로 check되지 않습니다. stored program의 경우, 실행이 default와 다른 role로 이루어져야 한다면, program body에서 SET ROLE을 실행하여 필요한 role을 활성화할 수 있습니다. role에 할당된 privilege는 변경될 수 있으므로, 이 작업은 주의해서 수행해야 합니다.