SQL Server

データはあらゆる組織にとって重要な資産であり、データベースのセキュリティが不十分であることがセキュリティ侵害の原因となることがよくあります。SQL Serverは安全なデータベースプラットフォームとして設計されていますが、デフォルト設定のままではシステムにセキュリティ上の欠陥が残ります。SQL Serverには、セキュリティを強化するために個別に設定する必要があるセキュリティ機能が多数あります。このページでは、SQL Serverのセキュリティに関するベストプラクティスと、悪意のある攻撃からデータベースを保護するための重要なセキュリティ上の考慮事項について詳しく説明します。

リスクポスチャにおける主要な事前定義されたルール

アドホック分散クエリ
CLRアセンブリ関数
クロスDBオーナーシップチェーン
Database Mail XPs
OLE Automation Procedures
リモートアクセス
リモート管理者接続
起動プロシージャ用にスキャン
Trustworthyデータベースプロパティ
SQL Mail XPs
標準ポート
インスタンスを非表示
saログインを無効化
saログインの名前を変更
XP CMDSHELL
自動クローズ
saログインを制限
CLR厳重セキュリティ
認証モード
ゲスト接続許可
孤立したユーザー
包含データベース認証
パブリックデフォルト許可
BUILTINグループをログインにする
ローカルグループをログインにする
パブリックロール用のエージェントプロキシアクセス
パスワードの有効期限をチェックします
パスワードポリシーをチェックします
エラーログファイルの数
デフォルトトレース
ログイン監査
SQL Server監査
CLRアセンブリ許可
対称鍵暗号アルゴリズム
非対称鍵サイズ

1. アドホック分散クエリ

ルールの説明：

「Ad Hoc Distributed Queries」サーバー構成オプションが「0」に設定されていることを確認します。

脆弱性：

「Ad Hoc Distributed Queries」を有効にすると、ユーザーは外部データソースに対してデータのクエリやステートメントの実行が可能になります。この機能は、リモートからアクセスしてリモートSQL Serverインスタンスの脆弱性を悪用したり、安全でないVisual Basic for Application関数を実行したりするために使用される可能性があります。

可能な値：

有効または「1」
無効または「0」

ベストプラクティス：

設定値を「0」にすること。

推奨：

以下のT-SQLコマンドを実行します。


                        EXECUTE sp_configure 'show advanced options', 1; RECONFIGURE;

                        EXECUTE sp_configure 'Ad Hoc Distributed Queries', 0; RECONFIGURE;

                        GO

                        EXECUTE sp_configure 'show advanced options', 0; RECONFIGURE;

2. CLRアセンブリ関数

ルールの説明：

「CLR Enabled」サーバー構成オプションが「0」に設定されていることを確認します。

脆弱性：

「clr enabled」オプションは、SQL Serverでユーザーアセンブリを実行できるかどうかを指定します。CLR アセンブリの使用を有効にすると、SQL Serverの攻撃対象領域が拡大し、不注意なアセンブリや悪意のあるアセンブリによるリスクにさらされることになります。

可能な値：

有効または「1」
無効または「0」

ベストプラクティス：

「clr strict security」オプションが「0」に設定されている場合、この機能を無効にすること。このオプションは SQL Server 2017以降でのみ使用可能です。「clr strict security」が「1」に設定されている場合、この推奨事項は適用されません。デフォルトでは、「clr strict security」は有効になっており、「SAFE」アセンブリと「EXTERNAL_ACCESS」アセンブリは「UNSAFE」としてマークされているものとして扱われます。推奨されませんが、下位互換性のために「clr strict security」オプションを無効にすることもできます。「clr strict security」オプションの状態を確認するには、以下のT-SQLコマンドを実行します。

SELECT name, CAST(value as int) as value_configured, CAST(value_in_use as int) as value_in_use FROM sys.configurations WHERE name = 'clr strict security';

推奨：

以下のT-SQLコマンドを実行します。

EXECUTE sp_configure 'clr enabled', 0; RECONFIGURE;

3. クロスDBオーナーシップチェーン

ルールの説明：

「Cross DB Ownership Chaining」サーバー構成オプションが「0」に設定されていることを確認します。

脆弱性：

このオプションを使用すると、データベースの「db_owner」ロールのメンバーが、他のデータベースのログインが所有するオブジェクトにアクセスできるようになるため、不要な情報漏洩が発生します。データベース間の所有権の連鎖は、「ALTER DATABASESET DB_CHAINING ON」コマンドを使用してすべてのデータベースのインスタンスレベルで有効にするのではなく、必要な特定のデータベースに対してのみ有効にする必要があります。このデータベースオプションは、「master」、「model」または「tempdb」システムデータベースでは変更できません。

可能な値：

有効または「1」
無効または「0」

ベストプラクティス：

設定値を「0」にすること。

推奨：

以下のT-SQLコマンドを実行します。


                        EXECUTE sp_configure 'cross db ownership chaining', 0; RECONFIGURE;

                        GO

4. Database Mail XPs

ルールの説明：

「Database Mail XPs」サーバー構成オプションが「0」に設定されていることを確認します。

脆弱性：

「Database Mail XPs」オプションは、SQL Serverから電子メールメッセージを生成および送信する機能を制御します。

可能な値：

有効または「1」
無効または「0」

ベストプラクティス：

設定値を「0」にすること。「Database Mail XPs」オプションを無効にすると、SQL Serverの攻撃対象領域が縮小され、DOS攻撃ベクトルとデータベースサーバーからリモートホストへのデータ流出経路が排除されます。

推奨：

以下のT-SQLコマンドを実行します。


                        EXECUTE sp_configure 'show advanced options', 1; RECONFIGURE; EXECUTE sp_configure 'Database Mail XPs', 0; RECONFIGURE;

                        GO

                        EXECUTE sp_configure 'show advanced options', 0; RECONFIGURE;

5. OLE Automation Procedures

ルールの説明：

「Ole Automation Procedures」サーバー構成オプションが「0」に設定されていることを確認します。

脆弱性：

「Ole Automation Procedures」オプションは、Transact-SQLバッチ内でOLEオートメーションオブジェクトをインスタンス化できるかどうかを制御します。OLEオートメーションオブジェクトは、SQL ServerユーザーがSQL Server外部の関数を実行できるようにする拡張ストアドプロシージャです。このオプションを有効にすると、SQL Serverの攻撃対象領域が拡大し、ユーザーはSQL Serverのセキュリティコンテキスト内で関数を実行できるようになります。

可能な値：

有効または「1」
無効または「0」

ベストプラクティス：

設定値を「0」にすること。

推奨：

以下のT-SQLコマンドを実行します。


                        EXECUTE sp_configure 'show advanced options', 1; RECONFIGURE; EXECUTE sp_configure 'Ole Automation Procedures', 0; RECONFIGURE;

                        GO

                        EXECUTE sp_configure 'show advanced options', 0; RECONFIGURE;

6. リモートアクセス

ルールの説明：

「Remote Access」サーバー構成オプションが「0」に設定されていることを確認します。

脆弱性：

「Remote Access」オプションは、リモートサーバー上のローカルストアドプロシージャ、またはローカルサーバー上のリモートストアドプロシージャの実行を制御します。この機能は、クエリ処理をターゲットサーバーにオフロードすることで、リモートサーバーへのサービス拒否（DoS）攻撃に悪用される可能性があります。

可能な値：

有効または「1」
無効または「0」

ベストプラクティス：

設定値を「0」にすること。

推奨：

以下のT-SQLコマンドを実行します。


                        EXECUTE sp_configure 'show advanced options', 1; RECONFIGURE; EXECUTE sp_configure 'remote access', 0; RECONFIGURE;

                        GO

                        EXECUTE sp_configure 'show advanced options', 0; RECONFIGURE;

注記：SQL Serverサービスを再起動します。

7. リモート管理者接続

ルールの説明：

「Remote Admin Connections」サーバー構成オプションが「0」に設定されていることを確認します。

脆弱性：

「Remote Admin Connections」オプションは、リモートコンピュータ上のクライアントアプリケーションが専用管理者接続（DAC）を使用できるかどうかを制御します。DACを使用すると、サーバーがロックされているか異常な状態で実行されていてSQL Serverデータベースエンジン接続に応答していない場合でも、管理者は実行中のサーバーにアクセスして診断関数やTransact-SQLステートメントを実行したり、サーバーの問題をトラブルシューティングしたりできます。

可能な値：

有効または「1」
無効または「0」

ベストプラクティス：

クラスター環境では、管理者がSQL Serverインスタンスをホストしているノードに実際にはログオンしていない可能性があり、その場合「リモート」とみなされます。そのため、この設定は通常、SQL Serverフェールオーバークラスターでは有効（1）にし、それ以外の場合は無効（0）にする必要があります。

推奨：

以下のT-SQLコマンドを実行します。


                        EXECUTE sp_configure 'remote admin connections', 0; RECONFIGURE;

                        GO

8. 起動プロシージャ用にスキャン

ルールの説明：

「Scan For Startup Procs」サーバー構成オプションが「0」に設定されていることを確認します。

脆弱性：

「scan for startup procs」オプションを有効にすると、SQL Serverはサービス起動時に実行するように設定されているすべてのストアドプロシージャをスキャンし、自動的に実行します。スタートアッププロシージャのスキャンを「0」に設定すると、特定の監査トレースやその他のよく使用される監視ストアドプロシージャが起動時に再起動されなくなります。また、レプリケーションを実行するにはこの設定が有効（1）になっている必要があり、必要に応じて自動的に変更されます。

可能な値：

有効または「1」
無効または「0」

ベストプラクティス：

設定値を「0」にすること。

推奨：

以下のT-SQLコマンドを実行します。


                        EXECUTE sp_configure 'show advanced options', 1; RECONFIGURE; EXECUTE sp_configure 'scan for startup procs', 0; RECONFIGURE;

                        GO

                        EXECUTE sp_configure 'show advanced options', 0; RECONFIGURE;

注記：SQL Serverサービスを再起動します。

9. Trustworthyデータベースプロパティ

ルールの説明：

「Trustworthy」データベースプロパティが「OFF」に設定されていることを確認します。

脆弱性：

「Trustworthy」データベースオプションは、特定の状況下でデータベースオブジェクトが他のデータベース内のオブジェクトにアクセスできるようにします。悪意のあるCLRアセンブリや拡張プロシージャからの保護を提供します。

可能な値：

有効または「ON」
無効または「OFF」

ベストプラクティス：

「ON」に設定する必要があるmsdbデータベースの場合を除き、「OFF」に設定すること。

推奨：

プロパティが「ON」になっているデータベースに対して、以下のT-SQLコマンドを実行します。

ALTER DATABASE [<データベース名>] SET TRUSTWORTHY OFF;

10. SQL Mail XPs

ルールの説明：

「SQL Mail XPs」サーバー構成オプションが「0」に設定されていることを確認します。

脆弱性：

SQL Mailは、SQL Server 2008 R2以前を使用して電子メールメッセージを送信、受信、削除、および処理するためのメカニズムを提供します。

可能な値：

有効または「1」
無効または「0」

ベストプラクティス：

設定値を「0」にすること。

推奨：

以下のT-SQLコマンドを実行します。


                        EXECUTE sp_configure 'show advanced options', 1; RECONFIGURE; EXECUTE sp_configure 'SQL Mail XPs', 0; RECONFIGURE;

                        GO

                        EXECUTE sp_configure 'show advanced options', 0; RECONFIGURE;

11. 標準ポート

ルールの説明：

SQL Serverが非標準ポートを使用する構成になっていることを確認します。

脆弱性：

デフォルトポート（1433）を使用すると、サーバーはデフォルトポートに向けた攻撃に対して脆弱になります。

可能な値：

サーバーで使用可能な任意のポート

ベストプラクティス：

デフォルトの1433以外のポートを利用すること。

推奨：

GUIを使用して、以下の手順を実施します。

SQL Server構成マネージャーを開きます。
コンソールペインで、[SQL Server ネットワークの構成]を展開し、[<インスタンス名> のプロトコル]を展開して、[TCP/IP]プロトコルをダブルクリックします。
[TCP/IPのプロパティ]ダイアログボックスの[IPアドレス]タブには、IP1、IP2、IPAllといった形式で複数のIPアドレスが表示されます。そのうちの1つはループバックアダプターのIPアドレス（127.0.0.1）です。コンピュータ上の各IPアドレスには、追加のIPアドレスが表示されます。
[IPAll]の下で、[TCP ポート]フィールドを「1433」から非標準ポートに変更するか、[TCP ポート]フィールドを空のままにして[TCP 動的ポート]の値を「0」に設定し、動的ポートの割り当てを有効にして [OK]をクリックします。
コンソールペインで、[SQL Server のサービス]をクリックします。
詳細ウィンドウで、[SQL Server (<インスタンス名>)]を右クリックし、[再起動]をクリックして、SQL Serverを停止して再起動します。

注記：SQL Serverのポート番号を変更する場合は、SQLサーバーとの通信にポート番号を使用するアプリケーションの接続設定を再設定する必要があります。

EventLog Analyzerでポート番号を再設定する方法

EventLog Analyzerを停止します。
<EventLog Analyzer_インストールディレクトリ>\conf\database_params.confを開きます。
既存のポート番号を必要なポート番号に変更します。
変更を有効にするには、EventLog Analyzerを再起動します。

12. インスタンスを非表示

ルールの説明：

実稼働SQL Serverインスタンスの「インスタンスの非表示」オプションが「はい」に設定されていることを確認します。

脆弱性：

実稼働環境内の非クラスター化SQL Serverインスタンスは、SQL Server Browserサービスによるアドバタイズを防ぐために、非表示に指定する必要があります。ただし、このオプションを選択すると、クラスター化されたインスタンスが機能しなくなる可能性があります。クラスター化された名前付きインスタンスを非表示にすると、クラスターサービスがSQL Serverに接続できなくなる可能性があります。

可能な値：

有効または「1」
無効または「0」

ベストプラクティス：

設定値を「1」にすること。

推奨：

GUIを使用して、以下の手順を実施します。

SQL Server構成マネージャーを開きます。
[SQL Server ネットワークの構成]を展開し、[<インスタンス名> のプロトコル]を右クリックして、[プロパティ]を選択します。
[フラグ]タブの[インスタンスの非表示]ボックスで「はい」が選択されている場合は、準拠しています。

または、以下のT-SQLコマンドを実行します。

EXEC master.sys.xp_instance_regwrite @rootkey = N'HKEY_LOCAL_MACHINE', @key = N'SOFTWARE\Microsoft\Microsoft SQL Server\MSSQLServer\SuperSocketNetLib', @value_name = N'HideInstance', @type = N'REG_DWORD', @value = 1;

注記：

SQL Serverサービスを再起動します。
SQL Serverインスタンスの検出にSQL Browserサービスを使用するアプリケーションは、「インスタンスの非表示」が有効になっている場合、インスタンスを自動的に検出できません。「インスタンスの非表示」を一時的に無効にするか、ポート番号を使用してSQL Serverインスタンスに接続する必要があります。

13. saログインを無効化

ルールの説明：

「sa」ログインアカウントが「無効」に設定されていることを確認します。

脆弱性：

saアカウントは、広く知られ、「sysadmin」権限を持つSQL Serverアカウントとして広く使用されています。これはインストール時に作成される元のログインであり、常に「principal_id=1」、「sid=0x01」を持ちます。この制御を適用することで、攻撃者が既知のプリンシパルに対してブルートフォース攻撃を実行する可能性を低減できます。

可能な値：

有効
無効

ベストプラクティス：

アプリケーションやスクリプトでsaアカウントを使用するようにコーディングすることは、セキュリティ上好ましくありません。既にスクリプトやアプリケーションがデータベースサーバーへの認証を行っている場合、saアカウントを無効化した際に必要なタスクや機能を実行できなくなります。

推奨：

以下のT-SQLコマンドを実行します。


                        USE [master]

                        GO

                        DECLARE @tsql nvarchar(max) SET @tsql = 'ALTER LOGIN ' + SUSER_NAME(0x01) + ' DISABLE' EXEC (@tsql)

                        GO

注記：saログインを使用してSQL Server接続を認証するアプリケーションは、saログインを変更するときに別のユーザーで再設定する必要があります。

14. saログインの名前を変更

ルールの説明：

「sa」ログインアカウントの名前が変更されていることを確認します。

脆弱性：

名前が知られている場合、saログインに対してパスワード推測やブルートフォース攻撃を実行することが容易になります。

可能な値：

Microsoft SQLログイン名制限で許可されている文字セット

ベストプラクティス：

saログインの名前を変更すること。

推奨：

以下のT-SQLコマンドを実行します。

ALTER LOGIN sa WITH NAME = <異なるユーザー名>;

注記：saログインを使用してSQL Server接続を認証するアプリケーションは、saログインを変更するときに別のユーザーで再設定する必要があります。

15. XP CMDSHELL

ルールの説明：

「xp_cmdshell」サーバー構成オプションが「0」に設定されていることを確認します。

脆弱性：

「xp_cmdshell」オプションは、認証されたSQL Serverユーザーがxp_cmdshell拡張ストアドプロシージャを使用してオペレーティングシステムのコマンドシェルコマンドを実行し、結果をSQLクライアント内の行として返すことができるかどうかを制御します。xp_cmdshellプロシージャは、通常、攻撃者がデータベースサーバーの基盤となるオペレーティングシステムに対してデータを読み取ったり、書き込んだりするために使用されます。

可能な値：

有効または「1」
無効または「0」

ベストプラクティス：

設定値を「0」にすること。

推奨：

以下のT-SQLコマンドを実行します。


                        EXECUTE sp_configure 'show advanced options', 1; RECONFIGURE; EXECUTE sp_configure 'xp_cmdshell', 0; RECONFIGURE;

                        GO

                        EXECUTE sp_configure 'show advanced options', 0; RECONFIGURE;

16. 自動クローズ

ルールの説明：

包含データベースで「AUTO_CLOSE」が「OFF」に設定されていることを確認します。

脆弱性：

「AUTO_CLOSE」は、接続終了後に特定のデータベースを閉じるかどうかを決定します。有効にした場合、特定のデータベースへの後続の接続では、データベースを再度開き、関連するプロシージャキャッシュを再構築する必要があります。

可能な値：

有効または「ON」
無効または「OFF」

ベストプラクティス：

設定値を「OFF」にすること。

推奨：

この構成が「OFF」になっているデータベースに対して、以下のT-SQLコマンドを実行します。

ALTER DATABASE <データベース名> SET AUTO_CLOSE OFF;

17. saログインを制限

ルールの説明：

「sa」という名前のログインが存在しないことを確認します。

脆弱性：

saログイン（例：プリンシパル）は広く知られており、頻繁に使用されるSQL Serverアカウントです。そのため、元のsaログイン（principal_id = 1）の名前が変更されたとしても、saという名前のログインは存在すべきではありません。

可能な値：

ログイン名には、Microsoft SQLログイン名ガイドラインで許可している任意の文字セットを使用できます。

ベストプラクティス：

ログイン名は「sa」にしない。

推奨：

名前が「sa」であるログインに対して、以下のT-SQLコマンドを実行します。


                        USE [master]

                        GO

                        ALTER LOGIN [sa] WITH NAME = <異なるユーザー名>;

                        GO

注記：変更したログインを使用してSQL Server接続を認証するアプリケーションは、同等の権限を持つ別のユーザーに再構成する必要があります。

18. CLR厳重セキュリティ

ルールの説明：

「clr strict security」サーバー構成オプションが「1」に設定されていることを確認します。

脆弱性：

「clr strict security」オプションは、エンジンがSQL Server 2017および2019のアセンブリに「PERMISSION_SET」を適用するかどうかを指定します。

可能な値：

有効または「1」
無効または「0」

ベストプラクティス：

設定値を「1」にすること。

推奨：

以下のT-SQLコマンドを実行します。


                        EXECUTE sp_configure 'show advanced options', 1; RECONFIGURE; EXECUTE sp_configure 'clr strict security', 1; RECONFIGURE;

                        GO

                        EXECUTE sp_configure 'show advanced options', 0; RECONFIGURE;

19. 認証モード

ルールの説明：

「サーバー認証」プロパティが「Windows 認証モード」に設定されていることを確認します。

脆弱性：

「Windows 認証」は、「SQL Server 認証」よりも強力な認証メカニズムを提供します。

可能な値：

SQL Server 認証
Windows 認証
混合認証

ベストプラクティス：

設定値を「Windows 認証モード」にすること。

推奨：

GUIを使用して、以下の手順を実施します。

SQL Server Management Studioを開きます。
オブジェクトエクスプローラーを開き、対象のSQL Serverインスタンスに接続します。
インスタンス名を右クリックし、[プロパティ]を選択します。
左側のメニューから[セキュリティ]を選択します。
[サーバー認証]設定を[Windows 認証モード]に設定します。

または、以下のT-SQLコマンドを実行します。


                        USE [master]

                        GO

                        EXEC xp_instance_regwrite N'HKEY_LOCAL_MACHINE', N'Software\Microsoft\MSSQLServer\MSSQLServer', N'LoginMode', REG_DWORD, 1

                        GO

注記：SQL Serverサービスを再起動します。

20. ゲスト接続許可

ルールの説明：

master、msdb、tempdbを除くすべてのSQL Serverデータベース内で、「guest」ユーザーの「CONNECT」権限が取り消されていることを確認します。

脆弱性：

ログインがSQL Serverにアクセスできるものの、自身のアカウントでデータベースにアクセスできず、データベースにゲストユーザーアカウントがある場合、ログインはゲストユーザーのIDを前提とします。ゲストユーザーの「CONNECT」権限を取り消すことで、明示的なアクセス権がない限り、ログインはデータベース情報にアクセスできなくなります。

可能な値：

ゲストユーザーには「CONNECT」権限がある場合とない場合があります。

ベストプラクティス：

master、msdb、tempdbを除くすべてのデータベースで、ゲストユーザーの「CONNECT」権限を取り消すこと。

推奨：

ゲスト接続権限を持つデータベースに対して、以下のT-SQLコマンドを実行します。


                        USE <データベース名>;

                        GO

                        REVOKE CONNECT FROM guest CASCADE;

21. 孤立したユーザー

ルールの説明：

SQL Serverデータベースから「孤立したユーザー」が確実に削除されていることを確認します。

脆弱性：

対応するSQL Serverログインが未定義、またはサーバーインスタンス上で正しく定義されていないデータベースユーザーは、インスタンスにログインできず、孤立したユーザーとして扱われるため削除する必要があります。孤立したユーザーは、これらのユーザーが何らかの形で悪用される可能性を回避するために削除する必要があります。

可能な値：

データベースには孤立したユーザーが存在する場合と存在しない場合があります。

ベストプラクティス：

データベースサーバーに孤立したユーザーが存在しないこと。

推奨：

すべての孤立したユーザーに対して、以下のT-SQLコマンドを実行します。


                        USE <データベース名>;

                        GO

                        DROP USER <ユーザー名>;

注記：孤立したユーザーは、トラブルシューティングが可能です。詳細は、Microsoft Learnを参照してください。

22. 包含データベース認証

ルールの説明：

包含データベースでSQL認証が使用されていないことを確認します。

脆弱性：

包含データベースでは、SQL認証ユーザーに対してパスワードの複雑さに関するルールは適用されません。適用されたパスワードポリシーがない場合、包含データベースで弱い認証情報が確立される可能性が高くなります。

可能な値：

SQL Server 認証
Windows 認証
混合認証

ベストプラクティス：

設定値を「Windows 認証モード」にすること。

推奨：

包含データベースでWindows認証ユーザーを活用します。詳細は、Microsoft Learnを参照してください。

必要に応じて、以下のT-SQLコマンドを実行してログインを削除します。


                        USE <データベース名>

                        GO

                        DROP USER <ユーザー名>;

注記：削除したログインを使用してSQLサーバーを認証するアプリケーションは、別のログインで再設定する必要があります。

23. パブリックデフォルト許可

ルールの説明：

「public」サーバーロールに、Microsoftが指定したデフォルトの権限のみが付与されていることを確認します。

脆弱性：

「public」は、すべてのログインを含む特別な固定サーバーロールです。他の固定サーバーロールとは異なり、「public」ロールの権限は変更できます。最小権限の原則に従い、サーバースコープでの権限付与には「public」サーバーロールを使用しないでください。これらの権限はすべてのユーザーに継承されます。すべてのSQL Serverログインは「public」ロールに属しており、このロールから削除することはできません。したがって、このロールに付与された権限は、特定のログインまたはユーザー定義サーバーロールに対して明示的に拒否されていない限り、すべてのログインで使用できます。「public」サーバーロールから不要な権限が取り消されると、明示的なログインまたはアクセスを必要とするログインを含むユーザー定義サーバーロールに権限が付与されない限り、アクセスが失われる可能性があります。

可能な値：

「public」ロールには任意の数の権限を付与できます。

ベストプラクティス：

「public」ロールには不要な権限を与えず、与えられた場合は削除し、必要に応じてユーザー定義のロールに委任すること。

推奨：

結果で見つかった不要な権限を、アクセスを必要とするユーザー定義のサーバーロールへの特定のログインに追加します。

見つかった権限に対して、以下のT-SQLコマンドを実行します。


                        USE [master]

                        GO

                        REVOKE <権限名> FROM public;

                        GO

注記：「public」ロールの場合、「View any database」と「Connect」が許可されます。

24. BUILTINグループをログインにする

ルールの説明：

WindowsのBUILTINグループがSQLログインではないことを確認します。

脆弱性：

BUILTINグループ（Administrators、Everyone、Authenticated Users、Guestsなど）には通常、非常に広範なメンバーシップが含まれており、SQL Serverインスタンスへのアクセスを必要なユーザーのみに許可するというベストプラクティスを満たしていません。これらのグループは、SQL Serverデータベースエンジンインスタンスへのいかなるレベルのアクセスにも使用しないでください。

可能な値：

どのグループも（BUILTINまたはユーザー定義のいずれであっても）、SQLログインにすることができます。

ベストプラクティス：

WindowsのBUILTINグループはSQLログインから削除すること。BUILTINグループのログインを削除する前に、同等の権限を持つ代替のADグループまたはWindowsログインが追加されていることを確認してください。そうしないと、SQL Serverインスタンスに完全にアクセスできなくなる可能性があります。

推奨：

GUIを使用して、以下の手順を実施します。

コンピューターの管理を開きます。
[ローカルユーザーとグループ]をクリックします。必要に応じて、必要なユーザーアカウントのみを含む制限付きのADグループを作成します。
SQL Server Management Studioを開き、データベースに接続し、左側のペインで[新しいログイン]を選択し、ADグループまたは個々のWindowsアカウントをSQL Serverログインとして追加し、必要な権限を付与します。
「<名前>」を置き換えた以下の構文を使用して、BUILTINログインを削除します。


                        USE [master]

                        GO

                        DROP LOGIN [<名前>]

                        GO

25. ローカルグループをログインにする

ルールの説明：

WindowsのローカルグループがSQLログインではないことを確認します。

脆弱性：

ローカルのWindowsグループをSQL Serverインスタンスのログインとして使用しないでください。ローカルのWindowsグループをSQLログインとして使用すると、OSレベルの管理者権限（SQL Server権限はなし）を持つユーザーがローカルのWindowsグループにユーザーを追加し、自分自身または他のユーザーにSQL Serverインスタンスへのアクセス権を付与できるという抜け穴が生じます。

可能な値：

どのWindowsグループでもSQLログインにすることができます。

ベストプラクティス：

WindowsのローカルグループはSQLログインから削除すること。ローカルグループのログインを削除する前に、同等の権限を持つ代替のADグループまたはWindowsログインが追加されていることを確認してください。そうしないと、SQL Serverインスタンスに完全にアクセスできなくなる可能性があります。

推奨：

GUIを使用して、以下の手順を実施します。

コンピューターの管理を開きます。
[ローカルユーザーとグループ]をクリックします。必要に応じて、必要なユーザーアカウントのみを含む制限付きのADグループを作成します。
SQL Server Management Studioを開き、データベースに接続し、左側のペインで[新しいログイン]を選択し、ADグループまたは個々のWindowsアカウントをSQL Serverログインとして追加し、必要な権限を付与します。
「<名前>」を置き換えた以下の構文を使用して、ローカルグループ名のログインを削除します。


                        USE [master]

                        GO

                        DROP LOGIN [<名前>]

                        GO

26. パブリックロール用のエージェントプロキシアクセス

ルールの説明：

「msdb」データベースの「public」ロールにSQLエージェントプロキシへのアクセスが許可されていないことを確認します。

脆弱性：

SQLエージェントプロキシへのアクセスを「public」ロールに付与すると、すべてのユーザーがプロキシを利用できるようになるため、高い権限が付与される可能性があります。これは、最小権限の原則に違反する可能性があります。

可能な値：

「public」ロールは、任意の数のプロキシにアクセスできる可能性があります。

ベストプラクティス：

エージェントプロキシの「public」ロールへのアクセスをすべて取り消すこと。プロキシから「public」ロールを取り消す前に、同等の権限を持つ代替のログインまたは適切なユーザー定義のデータベースロールが追加されていることを確認してください。そうでない場合、このアクセスに依存するSQLエージェントのジョブステップは失敗します。

GUIを使用して、以下の手順を実施します。

SQL Server Management Studioを開き、データベースに接続し、[SQL Server エージェント]を選択し、対象のプロキシを選択し、右クリックして[プロパティ]を選択し、アクセスを必要とする特定のセキュリティプリンシパルを追加します。
または、「sp_grant_login_to_proxy」T-SQLを使用してください。詳細は、Microsoft Learnを参照してください。
以下のT-SQLコマンドを使用して、「public」ロールから「<プロキシ名>」へのアクセスを取り消します。


                        USE [msdb]

                        GO

                        EXEC dbo.sp_revoke_login_from_proxy @name = N'public', @proxy_name = N'<プロキシ名>';

                        GO

27. パスワードの有効期限をチェックします

ルールの説明：

「Sysadmin」ロール内のすべてのSQL認証ログインに対して「CHECK_EXPIRATION」オプションが「ON」に設定されていることを確認します。

脆弱性：

有効にすると、Windowsで使用されるものと同じパスワード有効期限ポリシーがSQL Server内で使用されるパスワードに適用されます。有効にしない場合、使用中のパスワードが脆弱である可能性があります。

可能な値：

有効または「ON」
無効または「OFF」

ベストプラクティス：

設定値を「ON」にすること。これは、Windows認証ログインのみを使用するという推奨事項に従えないシステムに対する緩和策です。

推奨：

「CHECK_EXPIRATION」が「OFF」に設定されているログイン名に対して、以下のT-SQLコマンドを実行します。

ALTER LOGIN [<ログイン名>] WITH CHECK_EXPIRATION = ON;

28. パスワードポリシーをチェックします

ルールの説明：

すべてのSQL認証ログインに対して「CHECK_POLICY」オプションが「ON」に設定されていることを確認します。

脆弱性：

有効にすると、Windowsで使用されるものと同じパスワード複雑性ポリシーがSQL Server内で使用されるパスワードに適用されます。有効にしない場合、使用中のパスワードが脆弱である可能性があります。

可能な値：

有効または「ON」
無効または「OFF」

ベストプラクティス：

設定値を「ON」にすること。この設定はパスワード変更時にのみ適用されます。この設定は、既存の脆弱なパスワードの変更を強制するものではありません。そのため、既存のパスワードは手動で変更する必要があります。

推奨：

「CHECK_POLICY」が「OFF」に設定されているログイン名に対して、以下のT-SQLコマンドを実行します。

ALTER LOGIN [<ログイン名>] WITH CHECK_POLICY = ON;

29. エラーログファイルの数

ルールの説明：

「エラーログファイルの最大数」が12以上に設定されていることを確認します。

脆弱性：

SQL Serverのエラーログファイルは、消失から保護する必要があります。ログファイルは上書きされる前にバックアップする必要があります。より多くのエラーログを保持しておくことで、バックアップ前の頻繁なリサイクルによる消失を防ぐことができます。

可能な値：

すべての正の数値

ベストプラクティス：

設定値を「12以上」にすること。

推奨：

GUIを使用して、以下の手順を実施します。

SQL Server Management Studioを開きます。
オブジェクトエクスプローラーを開き、対象のインスタンスに接続します。
オブジェクトエクスプローラーの[管理]に移動して展開します。[SQL Server ログ]を右クリックし、[構成]を選択します。
[再利用する前に、エラーログファイルの数を制限する]にチェックが入っていることを確認します。
[エラーログファイルの最大数]が12以上であることを確認します。

または、「<NumberGreaterThanOrEqualTo12>」を置き換えた以下のT-SQLコマンドを実行します。

EXEC master.sys.xp_instance_regwrite N'HKEY_LOCAL_MACHINE', N'Software\Microsoft\MSSQLServer\MSSQLServer', N'NumErrorLogs', REG_DWORD, <NumberGreaterThanOrEqualTo12>;

30. デフォルトトレース

ルールの説明：

「Default Trace Enabled」サーバー構成オプションが「1」に設定されていることを確認します。

脆弱性：

デフォルトトレースは、アカウントの作成、権限の昇格、DBCCコマンドの実行などのデータベースアクティビティの監査ログを提供します。

可能な値：

有効または「1」
無効または「0」

ベストプラクティス：

設定値を「1」にすること。

推奨：

以下のT-SQLコマンドを実行します。


                        EXECUTE sp_configure 'show advanced options', 1; RECONFIGURE; EXECUTE sp_configure 'default trace enabled', 1; RECONFIGURE;

                        GO

                        EXECUTE sp_configure 'show advanced options', 0; RECONFIGURE;

31. ログイン監査

ルールの説明：

「ログイン監査」が「失敗したログインのみ」に設定されていることを確認します。

脆弱性：

この設定により、SQL Serverログインの失敗した認証試行がSQL Serverエラーログに記録されます。失敗したログインをキャプチャすることで、パスワード推測攻撃の検出または確認に使用できる重要な情報が得られます。成功したログインをキャプチャすることで、フォレンジック調査中にサーバーへのアクセスを確認できます。ただし、この監査レベル設定を使用して成功したログインもキャプチャすると、SQL Serverエラーログに過剰なノイズが発生し、DBAによる問題のトラブルシューティングが妨げられる可能性があります。

可能な値：

なし
失敗したログインのみ
成功したログインのみ
失敗したログインと成功したログインの両方

ベストプラクティス：

設定値を「失敗したログインのみ」にすること。

推奨：

GUIを使用して、以下の手順を実施します。

SQL Server Management Studioを開きます。
対象のインスタンスを右クリックし、[プロパティ]を選択して、[セキュリティ]タブに移動します。
[ログイン監査]セクションの[失敗したログインのみ]オプションを選択し、[OK] をクリックします。

または、以下のT-SQLコマンドを実行します。

EXEC xp_instance_regwrite N'HKEY_LOCAL_MACHINE', N'Software\Microsoft\MSSQLServer\MSSQLServer', N'AuditLevel', REG_DWORD, 2

注記：SQL Serverサービスを再起動します。

32. SQL Server監査

ルールの説明：

SQL Server監査が「失敗したログイン」と「成功したログイン」の両方をキャプチャするように設定されていることを確認します。

脆弱性：

SQL Server監査は、失敗したログインと成功したログインの両方をキャプチャし、アプリケーションイベントログ、セキュリティイベントログ、ファイルシステムのいずれかに書き込むことができます。セキュリティタブの従来の設定ではなく、監査を使用して成功したログインをキャプチャすることで、ERRORLOG内のノイズを削減できます。

可能な値：

監査アクションの種類が「AUDIT_CHANGE_GROUP」、「FAILED_LOGIN_GROUP」、および「SUCCESSFUL_LOGIN_GROUP」であるサーバーには、任意の数のサーバー監査が存在する可能性があります。

ベストプラクティス：

以下の監査名を持つサーバー監査の仕様が少なくとも1つ作成/存在すること。

AUDIT_CHANGE_GROUP
FAILED_LOGIN_GROUP
SUCCESSFUL_LOGIN_GROUP

推奨：

GUIを使用して、以下の手順を実施します。

SQL Server Management Studioを開きます。
オブジェクトエクスプローラーでSQL Serverを展開します。
[セキュリティ]フォルダーを展開します。
[監査]フォルダーを右クリックし、[新しい監査...]を選択します。
サーバー監査の名前を指定します。
監査先の詳細を指定し、[OK]をクリックしてサーバー監査を保存します。
[サーバー監査の仕様]を右クリックし、[新しいサーバー監査の仕様...]を選択します。
サーバー監査の仕様に名前を付けます。
[監査]ドロップダウンメニューで、作成したサーバー監査を選択します。
[監査アクションの種類]ドロップダウンメニューをクリックし、[AUDIT_CHANGE_GROUP]を選択します。
新しい[監査アクションの種類]ドロップダウンメニューをクリックし、[FAILED_LOGIN_GROUP]を選択します。
新しい[監査アクションの種類]ドロップダウンメニューをクリックし、[SUCCESSFUL_LOGIN_GROUP]を選択します。
[OK]をクリックして、サーバー監査の仕様を保存します。
新しいサーバー監査の仕様を右クリックし、[サーバー監査の仕様の有効化]を選択します。
新しいサーバー監査を右クリックし、[監査の有効化]を選択します。

または、「<Enter Audit Name Here>」と「<Enter Audit Spec Name Here>」を置き換えた以下のT-SQLコマンドを実行します。


                        USE master

                        GO

                        CREATE SERVER AUDIT <Enter Audit Name Here> TO APPLICATION_LOG;

                        GO

                        CREATE SERVER AUDIT SPECIFICATION <Enter Audit Spec Name Here> FOR SERVER AUDIT <Enter Audit Name Here> ADD (FAILED_LOGIN_GROUP), ADD (SUCCESSFUL_LOGIN_GROUP), ADD (AUDIT_CHANGE_GROUP), ADD (SUCCESSFUL_DATABASE_AUTHENTICATION_GROUP), ADD (FAILED_DATABASE_AUTHENTICATION_GROUP) WITH (STATE = ON);

                        GO

                        ALTER SERVER AUDIT <Enter Audit Name Here> WITH (STATE = ON);

                        GO

33. CLRアセンブリ許可

ルールの説明：

すべてのCLRアセンブリに対して「CLR Assembly Permission Set」が「SAFE_ACCESS」に設定されていることを確認します。

脆弱性：

CLRアセンブリ権限セットを「SAFE_ACCESS」に設定すると、アセンブリはファイル、ネットワーク、環境変数、レジストリなどの外部システムリソースにアクセスできなくなります。「EXTERNAL_ACCESS」または「UNSAFE」権限セットを持つアセンブリは、オペレーティングシステムの機密領域へのアクセス、データの窃盗や転送、基盤となるWindowsオペレーティングシステムの状態やその他の保護手段の変更に使用される可能性があります。

可能な値：

SAFE_ACCESS
EXTERNAL_ACCESS
UNSAFE

ベストプラクティス：

すべてのCLRアセンブリの権限を「SAFE_ACCESS」に設定すること。ただし、Microsoftが作成したアセンブリ（is_user_defined = 0）は、システム全体の機能に必要なため、このチェックから除外されます。本番環境への導入前に、テスト環境で修復策をテストし、アセンブリが「SAFE」権限設定でも設計どおりに機能することを確認する必要があります。

推奨：

以下のT-SQLコマンドを実行します。


                        USE <データベース名>;

                        GO

                        ALTER ASSEMBLY <アセンブリ名> WITH PERMISSION_SET = SAFE;

34. 対称鍵暗号アルゴリズム

ルールの説明：

system以外のデータベースで「Symmetric Key Encryption algorithm」が「AES_128以上」に設定されていることを確認します。

脆弱性：

Microsoftのベストプラクティスに従い、対称鍵暗号化アルゴリズムには、SQL Server AESアルゴリズムオプション（AES_128、AES_192、AES_256）のみを使用してください。アルゴリズム「DES」、「DESX」、「RC2」、「RC4」、「RC4_128」（SQL Serverの表記）は、強度が弱い、または非推奨とみなされており、SQL Serverでは使用しないでください。

可能な値：

DES
Triple DES
TRIPLE_DES_3KEY
RC2
RC4
128-bit RC4
DESX
128-bit AES
192-bit AES
256-bit AES

ベストプラクティス：

データベース内のすべての対称キーでは、暗号化アルゴリズムとして「AES_128以上」を使用すること。

推奨：

対称キーの変更に関する詳細は、Microsoft Learnを参照してください。

必要に応じて、以下のT-SQLコマンドを実行して対称キーを削除します。


                        USE <データベース名>

                        GO

                        DROP SYMMETRIC KEY <キー名>;

35. 非対称鍵サイズ

ルールの説明：

system以外のデータベースで「Asymmetric Key Size」が「2048以上」に設定されていることを確認します。

脆弱性：

Microsoftのベストプラクティスでは、非対称キーには少なくとも2048ビットの暗号化アルゴリズムを使用することが推奨されています。SQL Serverの非対称キー用「RSA_2048」暗号化アルゴリズムは、提供されている最高のビットレベルであり、最も安全な選択肢です。

可能な値：

512 bit
1024 bit
2048 bit

ベストプラクティス：

非対称キーのサイズを「2048 bit以上」に設定すること。

推奨：

非対称キーの変更に関する詳細は、Microsoft Learnを参照してください。

必要に応じて、以下のT-SQLコマンドを実行して非対称キーを削除します。


                        USE <データベース名>

                        GO

                        DROP ASYMMETRIC KEY <キー名>;