RDS for SQL Server インスタンスのマスターユーザーがアクセスできなくなりました、その理由とアクセス権を回復する方法を教えてください?

最終更新日: 2022 年 9 月 30 日

Amazon Relational Database Service (Amazon RDS) for SQL Server インスタンスのマスターユーザーからアクセスができなくなりました。または、別のユーザーが作成したデータベースへのアクセスを、マスターユーザーに対し許可する必要があります。マスターユーザーのアクセス権を復元したり、アクセス権を付与したりするにはどうすればいいですか?

簡単な説明

新しい DB インスタンスを作成すると、デフォルトのマスターユーザーには、その DB インスタンスに対する特定の権限が自動的に付与されます。DB インスタンスの作成後、マスターユーザー名を変更することはできません。

注: アプリケーション内では、直接マスターユーザーを使用しないことがベストプラクティスです。代わりに、アプリケーションに必要な最小限の権限で作成された、データベースユーザーを使用します。

マスターユーザーとしてのアクセス許可を誤って削除した場合は、DB インスタンスを変更し新しいマスターユーザーパスワードを設定することで、その許可を復元できます。詳細については、「マスターユーザーアカウント特権」を参照してください。

解決方法

マスターユーザーが DB インスタンスへのアクセスを失う、一般的なシナリオを以下に示します。または、特定のユーザーデータベースに対し、マスターユーザーが接続およびアクセスできないという場合もあります。

シナリオ 1: 対象のDB インスタンスでの明示的な DENY の指定により、マスターユーザーが接続できない

Connect SQL 権限で明示的な DENY が設定されている DB インスタンスでは、マスターユーザーからの接続ができない場合があります。デフォルトでは、Amazon RDS システム管理者 (rdsa) としてログインすることによって、マスターユーザーに Connect SQL が付与されます。ただし、Microsoft SQL Server では、明示的な DENY が明示的な GRANT よりも優先されます。

これを修正するには、以下を実行します:

1.    マスターユーザーログインの Connect SQL に明示的な DENY を設定した付与者としてログインし、RDS for SQL Server に接続します。

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_denydatawriter db_denydatareader の固定データベースロールに、マスターユーザーが追加されます。db_owner 固定データベースロールのメンバーであるにもかかわらず、db_denydatawriterdb_denydatareader の拒否権限により、データベースの SELECT、INSERT、UPDATE、DELETE 権限が禁止されています。

この問題を解決するには、以下の方法に従います。

1.    マスターユーザーとして、RDS for SQL Server インスタンスにログインします。

2.    次の T-SQL コマンドを使用して、これら 2 つのロールのメンバーからマスターユーザーを削除します。

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 権限が、マスターユーザーに付与されます。

マスターユーザーが持つ特定の役割の詳細については、「マスターユーザーアカウント特権」を参照してください。


この記事は役に立ちましたか?


請求に関するサポートまたは技術サポートが必要ですか?