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