SQLの「sa」アカウントが本来使用されていない方法で使用されていることが判明したため、すべてのSQLインスタンスでsaパスワードを変更しています。
(SQL 2005から2017までのサーバーが混合認証モードで実行されています。すべてのユーザーとアプリケーションshouldはドメインアカウントまたはnon-sa SQLアカウントのいずれかを使用して接続しています。監視を行っていますが、見つかりませんでした他のアプリ、ユーザー、またはsaアカウントを使用する非内部spid)
いくつかの質問:
Q1:saパスワードの変更にはSQLの再起動が必要ですか?
Saアカウントのパスワードを変更した後、SQLサービスの再起動が必要であるといういくつかの参照を見つけました。
本当?または、認証モードを変更する場合のみですか?または、私が日常的にsaとしてログオンする場合のみ?
このSQL Serverセントラルスレッド 変更すると、既存のSQLエージェントジョブやその他のものに影響を与える可能性があることさえ示唆しています。それは心配ですか?または、誰かがSAアカウントをSSISパッケージまたは何かにハードコーディングした場合のみですか?
(必要に応じて、SQLサービスとSQLエージェントサービスにはドメインアカウントを使用し、SSISパッケージまたはPowerShellスクリプトを呼び出すジョブにはドメインプロキシアカウントを使用します。)
Q2:saパスワードを「通常の」方法で変更できますか?
他のアカウントと同じようにリセットできますか? SSMSの使用、またはより可能性の高い方法:
ALTER LOGIN sa WITH PASSWORD = 'newpass';
それとも、計画的なダウンタイムを必要とするシングルユーザーモードまたは何かに入る必要がありますか? (「sa」として接続されている間ではなく、ドメインアカウントからこれを実行することに注意してください。)
Q3:このパスワードローテーションを定期的に実行する必要がありますか?それとも問題が見つかったときだけですか?
これは推奨される「ベストプラクティス」ですか?
Q1:saパスワードの変更にはSQLの再起動が必要ですか?
いいえ。ただし、認証モードを変更すると変更されます。パスワードを変更するだけで、認証モードはすでに混合に設定されているので、パスワードを変更するだけで十分です。
Q2:saパスワードを「通常の」方法で変更できますか?
はい、それは単なる別のSQLログインアカウントです。
Q3:このパスワードローテーションを定期的に実行する必要がありますか?それとも問題が見つかったときだけですか?
正直に言うと、SAログインを無効にして名前を変更します。この方法では、ログインはまったく使用されません。高度な特権のログインが必要な場合は、必要に応じてログインを作成できます。 。
これは、馬がすでに問題を解決した後、納屋の扉を閉めることです。
インスタンスを構築したときに、saアカウントの名前を変更して無効にしておく必要があります。
Windowsシステムの管理者やSQL Serverのsaなど、よく知られたアカウントを持っている場合は常に、アカウントを保護するために特定の手順を実行する必要があります。 saで何をすべきかを具体的に見てみましょう:
推測しにくいパスワードを設定します。
Saの名前を変更します。
Saを無効にします。
Saという名前の他のアカウントが存在しないことを確認します。
SQLアクセスを取得する緊急の方法として「sa」アカウントを保持している場合、より安全な方法があります。 システム管理者がロックアウトされたときにSQL Serverに接続する ネットワークアカウントにアクセスできない場合は、SQLに接続できないという大きな問題が発生します。