誰もがsaログインを使用できるようにするのが悪い習慣なのはなぜですか？

MicrosoftでさえSQL Server認証モードの使用を推奨していませんが、アプリケーションではそれが必要です。

ユーザーにsaログインを直接使用させないで、代わりにWindows認証を使用し、それらのアカウント（またはアカウントグループ）のsysadmin特権を許可することがベストプラクティスであることを読みました。

• それは本質的に同じものではありませんか？長所/短所は何ですか？
• ベストプラクティスは、SQL Serverインスタンスのセキュリティをどのように向上させますか？
• これは本番インスタンスのみに適用されますか、それとも社内開発インスタンスにも適用されますか？

ここにはいくつかの異なる質問があるので、個別にノックアウトします。

「ユーザーがsaログインを直接使用せず、代わりにWindows認証を使用することがベストプラクティスであることを読みました」

ここでは、SAの概念と、SQL認証とWindows認証の概念という2つのことを混ぜています。

SQL認証は、すべてのSQL Serverに保存されているユーザー名とパスワードのリストです。SQLに格納されているという事実が最初の問題です。ログインのパスワードを変更する必要がある場合は、すべてのサーバーで変更する必要があります（または、異なるサーバーで異なるパスワードを維持する必要があります）。Windows認証を使用すると、ログインを一元的に無効にしたり、パスワードを変更したり、ポリシーを設定したりできます。

SQL認証の使用を選択した場合、SAは1つのSQL認証ログインにすぎません。AdministratorがWindows認証にあるように、これはデフォルトの管理者ユーザー名です。その1つのインスタンスにローカル超大国がありますが、すべてのインスタンスにまたがるグローバル超大国はありません。

「...これらのアカウント（またはアカウントグループ）のsysadmin特権を許可します。」

どの認証方法を選択する場合でも、理想的には最小限の特権の原則に従うことをお勧めします。仕事を遂行するために必要な最低限の権利を人々に付与することです。

それらを単なるログインと考えないでください-彼らはあなたを解雇することができる人々です。データベースを誤って削除したり、バックアップジョブを無効にしたりしても、デフォルトではSQLがだれが何をしたかを追跡しないため、解雇されません。あなたはそれが起こるだろうから解雇されるだろうし、あなたは誰がそれをやったかを言うことができないだろう。

「ベストプラクティスは、SQL Serverインスタンスのセキュリティをどのように向上させますか？」

次の2つのことを行います。

1. 人がサーバーを破壊するのを防ぐ
2. 彼らがサーバーを壊したとき、誰がそれをしたのかを正確に特定できるようになる

最初の方法は、最小限の特権の原則で達成されます。人々に必要な権限のみを与え、それ以上は与えません。

2番目の方法は、各ユーザーに独自のログインを許可し、共有ログインを許可せず（全員が同じユーザー名/パスワードを使用できるようにするなど）、理想的にはログインを監査します。おそらく苦痛なので最後の部分はすぐには行いませんが、誰かがデータベースを削除し、上司がその理由を知りたがった後に後で監査を追加できるように、断片を最初に配置しましょう。

あなたが考えていることは知っています。「しかし、我々はアプリをコーディングしているので、アプリにはログインが必要です。」はい、アプリケーションに独自のログインを提供します。開発者はそのパスワードを知る必要がありますが、そのログインは権限を剥奪されて、誰もがそれを使用したくないでしょう。たとえば、db_datareaderロールとdb_datawriterロールのみに必要な場合がありますが、それ以外は必要ありません。そうすれば、データの挿入、更新、削除、選択が可能ですが、必ずしもスキーマの変更、インデックスの追加、ストアドプロシージャの変更などはできません。

「これは本番インスタンスにのみ適用されますか、それとも社内開発インスタンスにも適用されますか？」

私は通常、人々が物事を壊すことを心配しているので、開発インスタンスにも同じように適用されると思います。開発中のサーバーを壊すのが大好きです。そしてもちろん、本番環境に移行するために変更のリストをまとめるとき、特定のインデックスが本当にアプリに不可欠であるかどうか、または一部のボーンヘッドがデータベースチューニングアドバイザーを実行してすべての変更を適用するように指示したかどうかを知る必要があります。適切な許可は、その痛みを軽減するのに役立ちます。

実際、このホワイトペーパーを読んだ場合：SQL Serverの職務分離ホワイトペーパー

それはことを教えてくれますNO ONEが自分のアカウントにシステム管理者権限を使用する必要があります。毎日のアクセスアカウントには、明示的なsysadmin権限ではなく、最小限のアクセス権を付与する必要があります。それらが与えられると、CONTROL SERVERは実際にはsysadminに近いため、必要のない場合でもアクセスを拒否/取り消しできます。ITコンプライアンス基準を満たす必要がある場合は、だれにもsysadmin権限を許可することが問題になります。ほとんどの標準では、sysadminロールの最小限の使用が必要です。

OSのビルトイン管理者アカウントと同じように、「sa」アカウントを無効にして名前を変更します。緊急時にのみ使用されます。

開発者には通常、開発環境への完全なアクセス権が付与されます。次に、プログラムを実稼働前のインスタンスに移動する場合、アクセスは最小限またはゼロにする必要があります。生産中のように。それは完璧な世界です。しかし、もしあなたがその中にいなくて、あなたの開発者があなたが必要とするよりも高い特権を持っているなら、私は彼らのアカウントを完全に監査します。私は彼らがすることすべてをある程度キャプチャします。したがって、本番サーバー上で何かがうまくいかない場合は、戻ってそれらが何をしたかを正確に知ることができます。

外部の規制管理または標準（SOX、PCIなど）の対象となる場合、

• 監査に失敗します
• 毎月のPCIチェックで失敗している

開発者は、開発専用のネットワークSQL Serverにdb_ownerを用意する必要があります。

SQL Serverがすべて標準ビルド（つまり、同じサービスアカウント）でネットワーク上にある場合、saを使用すると、それらすべてに権限が付与されます。

サービスアカウントがローカル管理者である場合、開発者もサーバーを完全に制御できます。

利点はありません。

sa = sysadmin

saでログインすると、ユーザーは次のすべてを実行できます。-データベースの削除と作成-データベース内のオブジェクトの変更-ログインの削除と作成-パスワードの変更-すべてのデータの削除

Windowsアカウントにsysadmin特権を付与すると、同じことが実現します。

リストは続きますが、これにより、非管理者がsaを使用することを決して許可しないといういくつかの正当な理由が得られるはずです。

アプリを動作させるために必要な最低限の権限を持つウィンドウまたはSQLアカウントを作成する必要があります。（つまり、ログイン、ストアドプロシージャおよびビューへのアクセス）

ベストプラクティスは、強力なパスワードを保存して忘れることです。

現時点では、SAアカウントを弱くするべきではないという2つの選択肢があります。SAの弱い/空のパスワードを持っている場合、悪意のある人（それを「友好的な同僚」に翻訳します）は次のことができます。

• xp_cmdshellシステムプロシージャを有効にし、Sql Serverサービスアカウントの権限を使用して、ローカルボックスに損傷を与えます（ファイルの作成/削除）。SAのセキュリティが低いということは、実際にはインスタンスの設定についてあまり言及していませんが、サービスユーザーが悪い慣習（管理者であることなど）に従う可能性があることを意味する可能性があります。

• インスタンスでメールを有効にし、小さな迷惑メールスクリプトを早送りします（インターネットプロバイダーまたは同僚との間に何らかの問題を引き起こす可能性があります..メールの送信先によって異なります;-)）;

データベース、ログインなどを削除できるという明らかな事実は指摘しません。

• それは本質的に同じものではありませんか？長所/短所は何ですか？

• 必ずしもそうではありません。たとえば、ラップトップのSQL Serverインスタンスでは、Windows認証とSQL認証の違いは、Windows認証は自分のドメインの外部では使用できないため、理論的には外部攻撃者がSQLアカウントのみを使用できることを意味しますアカウント。ユーザーは、コーヒーを飲んでいるショッピングモールの隣のラップトップをスキャンし、SQLインスタンスがインストールされて起動していることを確認し、無料で楽しむことができます。それは頻繁に起こる可能性があるということではありません...しかし、それは可能性です:-)。

• ベストプラクティスは、SQL Serverインスタンスのセキュリティをどのように向上させますか？

• この世界のすべてのベストプラクティスがその仕事をしているように..そうでなければ起こり得るマイナス面の可能性を減らします（例えば：身体活動を行うベストプラクティスはあなたが私のように..カウチポテトになる可能性を減少させます）。

• これは本番インスタンスのみに適用されますか、それとも社内開発インスタンスにも適用されますか？

• 少なくとも本番環境で、セキュリティのベストプラクティス（環境のニーズに合わせてテストおよび変更）を実装することをお勧めします。しかし、開発中に実稼働データ（sensitive..etc）も使用する場合は、開発プラクティスも変更する必要があることを強く示しています。

最後の質問に対処するために、すべての開発データベースでSAアカウントを使用します（パスワードは「sa」です！）。

ただし、データを保存せず、データを生成しないことに注意することが重要です。当社のデータベースは、C / C ++アプリケーションのデータストアにのみ使用されます。これらの開発データベースには純粋にテストデータが含まれており、頻繁に作成、削除、変更などが行われます。\

また、同様に重要なことは、すべての開発データベースが開発マシンにインストールされることです。（少なくとも開発者ごとに1つのコピー！）だから誰かがインストール全体を台無しにした場合、台無しになったのは他の誰もいません。

データベース、テーブル、およびデータが実際に一貫性があり安全であることを保証したい環境になったら、しっかりとした強固なSAパスワードが必要です。これを弱くすると、誰でも誰でもあなたのデータに完全にアクセスでき、データベースを完全に破壊できます。

純粋にテストデータが含まれていることをデータベースの独自のコピーを持つ開発者の束のために、私はまだ強いSAアカウントを維持するための固体の引数を見つけるためには至っていません。

指定されたデフォルトのSQL Serverシステムセキュリティパラメータはすべて変更する必要があります。認証に混合モード（Windows認証とSQL Server認証の両方を有効にする）を使用しないことをお勧めします。代わりに、Windows認証のみに切り替えます（Windowsパスワードポリシーが適用されます）-パスワードの長さ、有効期間、および履歴を確認します。SQL Server認証とは異なるWindowsパスワードポリシーの機能はログインロックアウトです-連続して何度もログオンに失敗すると、ログインがロックされ、それ以上使用できなくなります

一方、SQL Server認証はブルートフォース攻撃の試行を検出する方法を提供しません。さらに悪いことに、SQL Serverは多数の高速ログイン試行を処理するように最適化されています。そのため、特定のSQL ServerシステムでSQL Server認証が必須の場合は、SAログインを無効にすることを強くお勧めします