RDS for SQL Server 인스턴스의 마스터 사용자가 액세스 권한을 상실한 이유는 무엇이며 어떻게 복원할 수 있습니까?

4분 분량
0

Amazon Relational Database Service(RDS) for SQL Server 인스턴스의 마스터 사용자가 액세스 권한을 잃었습니다. 또는 마스터 사용자에게 다른 사용자가 생성한 데이터베이스에 대한 액세스 권한을 부여해야 합니다. 마스터 사용자에게 액세스 권한을 복원하거나 액세스 권한을 부여하려면 어떻게 해야 합니까?

간략한 설명

새로운 DB 인스턴스를 생성할 때, 기본 마스터 사용자에게 자동으로 DB 인스턴스에 대한 특정 권한이 부여됩니다. DB 인스턴스를 생성한 후에는 마스터 사용자 이름을 변경할 수 없습니다.

참고: 애플리케이션에서 마스터 사용자를 직접 사용하지 않는 것이 좋습니다. 대신 애플리케이션에 필요한 최소 권한으로 생성한 데이터베이스 사용자를 사용하십시오.

마스터 사용자의 권한을 실수로 삭제한 경우에는 DB 인스턴스를 수정하고 새 마스터 사용자 암호를 설정하여 권한을 복원할 수 있습니다. 자세한 내용은 마스터 사용자 계정 권한을 참조하십시오.

해결 방법

다음은 마스터 사용자가 DB 인스턴스 연결에 대한 액세스 권한을 상실할 수 있는 일반적인 시나리오입니다. 또는 마스터 사용자가 특정 사용자 데이터베이스에 연결 및 액세스하지 못할 수도 있습니다.

시나리오 1: 명시적인 DENY로 인해 마스터 사용자가 DB 인스턴스에 연결할 수 없음

DENY가 명시적으로 Connect SQL 권한에 설정되어 있기 때문에 마스터 사용자가 DB 인스턴스에 연결하지 못할 수 있습니다. 기본적으로 마스터 사용자에게는 Connect SQL이 Amazon RDS 시스템 관리자(rdsa) 로그인을 통해 부여됩니다. 하지만 Microsoft SQL Server에서는 명시적인 DENY가 명시적인 GRANT보다 우선합니다.

이를 수정하기 위해서는 다음을 수행합니다.

1.    RDS for SQL Server에 연결하려면 명시적인 DENY로 설정한 권한 부여자의 로그인을 마스터 사용자 로그인에 대한 Connect SQL에서 사용합니다.

2.    다음 T-SQL 명령을 사용하여 명시적 DENY를 취소합니다. 다음 예에서 RDS 마스터 사용자 로그인은 master_user이고 부여자 보안 주체는 grantor_principal입니다. 사용 사례에 맞게 이러한 값을 변경하십시오.

USE [master];
GO
REVOKE CONNECT SQL TO [master_user] AS [grantor_principal];
GO

시나리오 2: 마스터 사용자는 데이터베이스의 사용자에 매핑되지 않기 때문에 특정 데이터베이스에 연결할 수 없음

이는 다음과 같은 경우에 발생할 수 있습니다.

  • 데이터베이스가 다른 로그인 계정으로 생성되었습니다. 또한 마스터 사용자 로그인은 데이터베이스의 데이터베이스 사용자에 매핑되지 않으며, 데이터베이스에 대한 권한을 부여 받습니다.
  • 이전에 적절한 권한을 통해 마스터 사용자 로그인에 매핑한 데이터베이스 사용자가 명시적으로 삭제되었습니다.

이 문제를 해결하려면 마스터 사용자 암호를 재설정하십시오. 비밀번호를 재설정하면 마스터 사용자 로그인에 매핑된 데이터베이스 사용자가 생성됩니다(해당 사용자가 삭제된 경우). 또한 사용자에게 db_owner 고정 데이터베이스 역할을 부여합니다. 마스터 사용자 암호 재설정에 대한 지침은 Amazon RDS DB 인스턴스의 마스터 사용자 암호를 재설정하려면 어떻게 해야 하나요?를 참조하십시오.

참고: 암호를 재설정하는 AWS Identify and Access Management (IAM) 사용자는 RDS 리소스에서 ModifyDBInstance 작업을 수행할 권한을 보유하고 있어야 합니다.

마스터 사용자 암호를 업데이트하면 다음과 같은 작업이 수행됩니다.

  • 마스터 사용자에게 다른 사용자가 생성한 데이터베이스에 db_owner 데이터베이스 수준 역할을 부여합니다.
  • 시스템 권한을 마스터 사용자에게 복원합니다.
  • 서버 수준 역할을 마스터 사용자에게 복원합니다.
  • 서버 수준 권한을 마스터 사용자에게 복원합니다.
  • 마스터 사용자에게 시스템 저장 프로시저에 대한 액세스를 복원합니다.
  • 마스터 사용자에게 RDS 관련 저장 프로시저에 대한 액세스를 복원합니다.

시나리오 3: 마스터 사용자가 특정 작업을 수행할 수 없음

마스터 사용자는 데이터베이스에 대한 db_owner 역할 권한을 가지고 있지만 CONNECT, SELECT, INSERT, UPDATE, ALTER 등과 같은 특정 작업을 수행합니다. 이는 마스터 사용자 로그인에 매핑된 데이터베이스 사용자가 데이터베이스에 대한 특정 권한을 명시적으로 거부했을 때 발생할 수 있습니다.

데이터베이스 역할 목록 및 해당 역할의 구성원인 데이터베이스 사용자를 보려면 다음 T-SQL 명령을 실행합니다. 다음에서는 database_name을 사용 사례에 맞는 올바른 값으로 변경합니다.

USE [database_name];
  GO
  SELECT DP1.name AS DatabaseRoleName,
   isnull (DP2.name, 'No members') AS DatabaseUserName
 FROM sys.database_role_members AS DRM
 RIGHT OUTER JOIN sys.database_principals AS DP1
   ON DRM.role_principal_id = DP1.principal_id
 LEFT OUTER JOIN sys.database_principals AS DP2
   ON DRM.member_principal_id = DP2.principal_id
WHERE DP1.type = 'R'
ORDER BY DP1.name;

다음 명령을 실행하여 특정 데이터베이스에 대한 사용자의 권한 목록을 확인합니다. 다음 예시에서는 database_name을 사용 사례에 맞는 올바른 값으로 변경합니다.

USE [database_name];
GO
EXECUTE AS USER = 'master_user';
SELECT * FROM sys.fn_my_permissions(NULL, 'DATABASE');
GO

이 예시에서는 마스터 사용자가 db_denydatawriterdb_denydatareader 고정 데이터베이스 역할에 추가됩니다. db_owner 고정 데이터베이스 역할의 구성원임에도 불구하고db_denydatawriterdb_denydatareader의 거부 권한은 데이터베이스에 대한 SELECT, INSERT, UPDATE 및 DELETE 권한을 금지합니다.

이 문제를 해결하려면 다음을 수행합니다.

1.    마스터 사용자를 사용하여 RDS for SQL Server 인스턴스에 로그인합니다.

2.    다음 T-SQL 명령을 사용하여 마스터 사용자를 이 두 역할의 구성원으로 드롭합니다.

USE [database_name];
GO
ALTER ROLE [db_denydatawriter] DROP MEMBER [master_user];
ALTER ROLE [db_denydatareader] DROP MEMBER [master_user];
GO

명령이 완료되면 마스터 사용자는 복원된 데이터베이스에 대한 SELECT, INSERT, UPDATE 및 DELETE 권한을 갖게 됩니다.

마스터 사용자의 특정 역할에 대한 자세한 내용은 마스터 사용자 계정 권한을 참조하십시오.


관련 정보

db_owner 역할 암호 재설정

Microsoft SQL Server 보안

DENY (Transact-SQL)