Windows管理者のアクセスを制限する
SQL Serverのベストプラクティス が言うように、「Windows認証モードはSQL認証より安全です」。そして今、私は知りたい：Windows管理者権限を持つユーザーからSQL Serverを保護する方法はありますか？
番号。
ユーザーがボックスのWindows管理者である場合は、ボックス上のすべて（SQL Serverを含む）を所有していると想定します。 Windows管理者権限を使用すると、適用対象の保護（ユーザー名を識別するログオントリガーなど）を 他のユーザーになりすます（NT AUTHORITY\SYSTEMを含む）をバイパスすることは簡単です。すべてのローカルSQL Serverインスタンス ）。監査も簡単に無効にできるため、あまり役に立ちませんが、念のために用意しておく必要があります。
誰かを信頼していない場合は、Windows管理者権限、期間を与えないでください。
いいえ、ローカル管理者がSQL Serverインスタンスにsysadminアクセスするのを完全に防ぐことはできません。
インスタンスが シングルユーザーモードで再起動 の場合、明示的なログインがなくても、ローカル管理者にsysadmin特権を許可するようにSQL Serverがハードコーディングされています。これが存在する理由は、インスタンスからロックアウトされる可能性があるため、回復の目的です。
そうは言っても、アクセスを制限するインスタンスがマルチユーザーモードで実行されている間（サービスの中断なし）はそれほど難しくありません。アーロンが述べたように、ローカル管理者は偽装することができますNT AUTHORITY\SYSTEM。これには、SQL Server 2008で作成されたsysadminレベルのログインがあります。これは exploited にすることができ、サーバーの実行中にsysadminアクセスを回復します。 （注：SQL Server 2012では、このログインはsysadminではなくなりました。）このログインの用途（アップグレード/ホットフィックスなど）は正確にはわかりませんが、これらのイベント中以外は無効にしても安全です。他のなりすましのログインがない場合は、アクセスを拒否するにはそれで十分です。繰り返しますが、インスタンスが実行されている場合のみ、中断されません。
SQL 2008および2012のデフォルトでは、Windows管理者はSQL Serverにデフォルトでアクセスできません。 Windows管理者（ドメイン管理者またはローカル管理者のいずれか）がアクセスできるようにするには、ログインに明示的にアクセス権を付与するか、ユーザーが所属するグループにSQL Server自体の権限とともにアクセス権を付与する必要があります。インスタンスを設定するとき、1つのActive Directoryログインまたはグループを管理者として指定する必要がありますが、そのログイン/グループはドメイン内の誰でもかまいません。
SQL 2005では、BUILTIN\Administrators sysadminアクセス権を持つグループ。このグループは、ローカル管理者sysadminにSQL Serverへのアクセスを許可します。このグループはSQL Serverから削除でき、削除することがベストプラクティスと見なされていました。
そうは言っても、Windows（ローカルまたはドメイン）がSQL Serverが存在するサーバーに影響を与えるのを防ぐ方法はありません。つまり、管理者はサービスやOSレベルの構成、ディレクトリセキュリティの変更、その他のOSレベルのタスクに影響を与えることができます。結局、これが彼らがWindows管理者である理由です。
一般に、SQL ServerとWindowsの両方の管理者を信頼する必要があります。 Windows管理者はSQL Server内でタスクを実行したりデータにアクセスしたりすることはできませんが（デフォルトでは）、SQL Serverが存在する環境を制御します。それらのロールに誰を割り当てるかについて注意する必要があります。