SAアカウントおよびその他の既知のアカウント名がセキュリティにもたらすセキュリティ上の脅威は何ですか？

saなどの既知のアカウント名は、データベースにセキュリティ上の脅威をもたらしますか？SQL ServerでWindows認証を使用する場合、同じパスワードポリシーが適用されますか（5回後にアカウントロックアウトを行うように設定されている場合）？

saなどの既知のアカウント名は、データベースにセキュリティ上の脅威をもたらしますか？

既知の名前を持つ「神」のユーザーアカウントは、一般的に、あまり知られていない名前を持つ神のユーザーよりも悪い考えと見なされます。攻撃者がユーザー名とパスワードではなくパスワードを推測するだけでよいので、ブルートフォース攻撃が少し簡単になります。

また、とにかく神のユーザーがいるのは危険です。一般的には、特定のユーザーに必要な操作に対して特定の権限を与える方がよいでしょう。この種の特権ベースのセキュリティは、後で環境に組み込むよりも、ゼロから実装する方が簡単です。

SQLサーバーで必要に応じてsaを無効にし、特定のユーザーに特定の管理者権限を与えることは、Linuxなどでroot必要に応じて管理者権限を無効にして渡すことと基本的に同じsudoです。saLinuxへのrootアクセスを設計するのと同じように、何かがうまくいかず、ユーザーが操作（および問題を修正）するために必要なすべての権限を落としてしまう場合は、マシンに直接接続すると、いつでも再び有効にすることができます。ボックスへの物理的なアクセス権がある場合はボックス-アカウントを無効にすることは特効薬ではありません（ただし、攻撃者がマシンに物理的にアクセスするか、RDCまたはSSHを介して完全な管理アクセス権を取得すると、すべての賭けが無効になります）。

SQL ServerでWindows認証を使用する場合、同じパスワードポリシーが適用されますか（5回後にアカウントロックアウトを行うように設定されている場合）？

Windows統合認証を使用する場合、SQLサーバーはアカウントロックアウトなどを制御できません。WindowsサーバーをSQLユーザーにマップし、ユーザーが適切な資格情報を提供したことをOSに保証するように要求します。対話型の人間のユーザーの場合、これは、ユーザーがSQL Serverにログインしたときではなく、ユーザーがWindowsで認証しようとしたときにロックアウトが発生することを意味します。

デフォルトの管理ユーザー（admin / root / postgres / sa / etc）が実際にシステムに存在しないようにすることは悪い考えではありません。特権アカウントは、常に別の名前で作成できます。

他に何もない場合、システムを悪用しようとする人々は、ブラインドで作業している場合ほど簡単な時間はありません（例：対話型シェルがなく、コマンドからの直接出力を確認できないSQLインジェクション）

アカウントのロックアウトについては、誰かがあなたのマシンにログインしようと試みることができるほど遠くまで到達できた場合、特にユーザーからの直接ログインを許可しない限り、すでに戦いに負けています。個人的には、ロックアウトは大部分は好きではありません。誰かがユーザーの名前を取得できた場合、誰かがサービス拒否を作成することができるためです。（そして、スーパーユーザーを締め出すのは楽しいですか？）

私はCISベンチマークを検討することをお勧めします...彼らはすべてのデータベースについてそれらを持っているわけではありませんが、彼らはOracle、MS SQL、DB2およびMySQLのための推奨事項を持っています。あなたが何か他のものを走らせているなら、それでも彼らが推薦する一般的な種類のものを見る価値がある。

他の人がこれに言及しているのを見なかったので、追加します。SQL Server 2005以降では、サーバーがドメインの一部であり、ドメインにパスワードポリシーがある場合、SQLログインにパスワードポリシーを適用することができます。これには、パスワードの複雑さの要件と、ログイン時にパスワードの変更を強制する機能が含まれます。

これにより、SQL 2005+で動作するように更新されておらず、安全でないパスワードでSQLログインが作成されない一部のソフトウェアインストーラーで問題が発生する場合があります。

SQL Serverで使用される認証モードには、Windows認証と混合モードの2つがあります（Windows認証とSQL Server認証の両方を有効にします）

最初のモードは、攻撃者が有限回数の攻撃を試みた後、ログインロックアウト（アカウントロックアウトポリシー機能）に遭遇する可能性が高いため、ブルートフォース攻撃に対して脆弱ではありません。ブルートフォース攻撃を不可能にするため、Windows認証モードを使用している場合、すべての実稼働環境はロックアウトポリシー機能を利用する必要があります。

SQL Server認証のブルートフォース攻撃の脆弱性に関しては、状況はそれほど好ましいものではありません。SQL Server認証には、システムがブルートフォース攻撃を受けていることを検出できる機能はありません。さらに、SQL Serverは、SQL Server認証資格情報の検証に関して非常に応答性が高くなります。このような攻撃を示す可能性のある全体的なパフォーマンスが低下することなく、繰り返しの積極的なブルートフォースログイン試行を簡単に処理できます。これは、SQL Server認証がブルートフォース攻撃によるパスワードクラッキングの完全なターゲットであることを意味します

また、ブルートフォース手法は、新しく導入された暗号化とパスワードの複雑さの手法ごとに進化しています。たとえば、レインボーテーブル（文字の可能なすべての組み合わせの暗号化ハッシュ値を元に戻すための事前計算されたテーブル）を使用する攻撃者は、ハッシュされたパスワードを簡単かつ迅速に解読できます

SQL Serverをブルートフォース攻撃から保護するには、次のことを考慮する必要があります。

• SQL Server認証モードを使用しない-攻撃者にWindows認証を介してログインロックアウトを強制する
• SQL Server認証モードを使用する必要がある場合は、SAログインを無効にするか削除します。これにより、攻撃者はユーザー名とパスワードの両方を推測してペアにする必要があります。

saアカウントを有効にすると、SQL Serverで何でも実行できます。攻撃者がこのアカウントに侵入した場合、SQL Serverインスタンス（および場合によってはホストOS）で必要なことを何でも実行できます。

SA（および他のよく知られたアカウント名）は、ハッカーが攻撃できるよく知られたポイントです。Oracleのパスワードの一部は十分に文書化されていなかったため、デフォルトのパスワードが常に変更されるとは限りませんでした。SQL ServerでSAアカウントを制御したら、それが実行されているサーバーを制御し、任意のコードを実行したり、必要なものをインストールしたりできます。私のカウボーイ時代に、SQL ServerもホストしているWebサーバーにActiveXコントロールをインストールすることを許可されなかった（記入する必要のなかった書類が必要だった）ので、xp_cmdshellを使用してコントロールをコピーしてインストールしました。