デスクトップ アプリケーションを SQL Server に直接接続していますが、SQL Server をインターネットに直接公開すべきではないという投稿はたくさん見かけますが、その理由を述べているものはありません。背景:
- スケーラビリティ、負荷分散、その他のパフォーマンス基準は、私のシナリオでは問題ではありません
- 私のアプリは、複数のユーザーがデータを共有できるように、ローカル（ローカル SQL Server を使用）またはリモート リポジトリで動作する必要があります（ホストされた SQL Server、これが私の質問です）
SQL Azureへの接続は、標準的なリモートSQL Server（http://www.windowsazure.com/en-us/develop/net/how-to-guides/sql-database/#using-sql-server）
ポートを開くと脆弱性が生じることは理解していますが、それが唯一の理由ではないはずです。何か見落としているに違いありませんが、何が見落としているのかわかりません。
アプリケーションの下半分を Web サービスとしてデプロイする以外の実際の代替手段は何ですか?
答え1
理由はいくつかありますが、最も関連性が高いのは、SQL サーバーとネットワーク セキュリティの両方の経験がない人は、よくある間違いを 1 つ以上犯す可能性が高いということです。
たとえば、デフォルトの sysadmin アカウントであり、SQL サーバーを完全に制御できる「sa」SQL ログインを使用して接続できます。
または、弱いパスワードを持つ別の SQL Server ログインを使用している可能性があります。その場合、攻撃者はブルート フォース攻撃を試み、権限を昇格することができます。
または、デフォルトの読み取り専用ユーザー アカウントを (このアプリケーションまたは他のアプリケーションに対して) 有効にしたままにしておくと、攻撃者やエクスプロイト スクリプトによってアクティブにスキャンされ、データベースからデータを取得できるようになります。
最も基本的なリモート攻撃から身を守るための良い対策をいくつか紹介します。
- 信頼できるIPとクライアントへの接続を制限する
- 可能な限りWindows統合認証を使用し、弱いパスワードによるログインを無効にします。
- SQL Server 認証を使用する必要がある場合は、sa ログインの名前を変更/無効にし、すべてのログインに強力なパスワード (10 文字以上) を設定します。