SQL Server 2000 SP3 セキュリティ機能と推奨事例

サーバーの物理的なセキュリティを確認します。

脆弱なサービスが他のサービスを危うくするために使用される危険性を軽減するために、サービスを分離します。

ドメイン コントローラに SQL Server をインストールしません。

独立したSQL Server サービスは個別の Windows アカウントで実行します。

多層環境では、Web ロジックとビジネス ロジックを別のコンピュータで実行します。

NTFS を使用します。

重要なデータ ファイルには RAID を使用します。

常に、最新の Service Pack とセキュリティ修正プログラムをインストールします。

SQL Server との接続に Windows 認証を要求します。

インストール後に以下のファイルを削除またはアーカイブします。既定のインスタンスの場合は、<systemdrive>:\Program Files\Microsoft SQL Server\MSSQL\Install フォルダ、名前付きインスタンスの場合は、<systemdrive>:\Program Files\Microsoft SQL Server\ MSSQL$<Instance Name>\Install フォルダの sqlstp.log、sqlsp.log、および setup.iss。

現在のシステムが SQL Server 7.0 からアップグレードされている場合は、以下のファイルを削除します。%Windir% フォルダの setup.iss と Windows Temp フォルダの sqlsp.log。

ログイン監査レベルを [失敗] または [すべて] に設定します。

Windows 認証を要求するように設定されているサーバーでも、sa アカウントに強固なパスワードを割り当てます。

SQL Server セキュリティ モデルを使って作業することを理解します。

ユーザーの環境に必要なサービスや機能を実行することによって攻撃にさらされるシステムの公開部分を少なくします。

すべての SQL Server アカウントに複雑なパスワードを使用していることを確認します。

既定では、sysadmin ロールのメンバだけが xp_cmdshell を実行できます。この既定の設定を変更すべきではありません。

xp_cmdshell の実行権限を sysadmin ロールのメンバではないユーザーに許可しません。

権限の管理を単純化するために、ユーザーを SQL Server ロールまたは Windows グループにまとめます。

分散クエリをサポートする環境に SQL Server をセットアップするときは、リモート サーバーではなく、リンク サーバーを使用します。

分散クエリを必要とするログインだけにリク サーバーへのアクセスを許可します。

sysadmin 固定サーバー ロールのメンバ以外のすべてのユーザーには、SQL OLE DB, 以外のすべてのプロバイダでのアドホック データ アクセスを無効にします。

信頼関係のあるプロバイダでのみアドホック データ アクセスを許可します。

SQL Server サービスに関連付けられたアカウントを変更する必要がある場合は、SQL Server Enterprise Manager を使用します。

複数のサービスを変更する場合は、Enterprise Manager を使用して、各サービスに個別に変更を適用する必要があります。

毎週の保守スケジュールに MBSA を追加し、MBSA が作成するすべてのセキュリティの推奨事項を追加します。

固定サーバー ロールと固定データベース ロールを定期的にスキャンし、そのメンバシップが信頼できる個人だけに割り当てられていることを確認します。

サーバー レベルでデータベース ユーザーとログインの間のマッピングが正しいことを確認します。

report オプションを指定した sp_change_users_login を定期的に実行し、マッピングが期待通りであることを確認します。

sp_dboption を使用して、複数データベースの組み合わせ所有権が有効になっているデータベースを列挙し、検証します。

管理している SQL Server のすべてのバージョン、エディション、および言語のインベントリを管理します。

インベントリに MSDE のインスタンスを含めます。

Microsoft Web サイトから入手できる SQL Scan と SQL Check を使用して、ドメイン内の SQL Server のインスタンスをスキャンします。

実稼動システムの構成と同じテスト構成を管理し、新しい修正プログラムをテストできるように準備します。

実稼動システムに適用する前に、修正プログラムを注意深くテストします。

比較的小さなテスティングでは開発システムに修正プログラムを適用することを検討します。

権限の管理を単純にするために、1 つのデータベース内では所有権の継承を使用します。

できる限り、複数データベースの組み合わせ所有権の使用は避けます。

複数データベースの組み合わせ所有権を使用する必要がある場合は、その 2 つのデータベースが常に 1 つの管理単位として配置されることを確認します。

サーバーへの暗号化された接続を有効にし、暗号化された接続だけを許可することを検討します。

SQL Server 認証を許可しているときは、IPSec を使用してネットワーク層を暗号化するか、SSL を使用してセッションを暗号化するかのいずれかを強くお勧めします。

ユーザー入力をサーバーに転送する前に、すべてのユーザー入力を検証することにより、SQL インジェクションに対して保護します。

ユーザー入力をサーバーに送信するアカウントに最小限の特権だけを許可することによって、損傷を受ける可能性のある範囲を制限します。

最低限必要な特権を使って、SQL Server 自体を実行します。

アプリケーション サーバーのすべてのユーザーがデータベース サーバーに有効な Windows ログインを持つ必要があり、委任が有効になっている必要があります。

この事例で相互作用するすべてのシステムは、ドメイン コントローラも含めて、Windows 2000 以上を実行している必要があります。

アプリケーションを実行するアカウントは委任に対して信頼されている必要があります (つまり、このアカウントに対して Active Directory のオプション [アカウントは委任に対して信頼されている] がオンになっている必要があります)。

クライアント アカウントを委任できる必要があります (Active Directory ユーザー アカウント オプション [アカウントは重要なので委任できない] がオフになっていることを確認します。

アプリケーション サービスは、有効なサービス プリンシパル名 (SPN) を持つ必要があります。

注 セキュリティ計画が、データベース サーバーへの最小限のユーザー アクセスを要求するとき、または委任を禁止するポリシーを持つ企業では、企業間またはインターネット規模のインストールでの完全提供はお勧めしません。

層間に Windows 認証を使用できないときは、ログイン シーケンスに SSL 暗号化を要求する必要があります。セッション全体を暗号化することをお勧めします。

格納する必要のある資格情報を暗号化するために、DPAPI も使用する必要があります。

ACL で保護されたレジストリ キーに暗号化した資格情報を格納する必要があります。

開発チームのメンバが以下の主要なセキュリティの問題点を理解していることを確認します。現在の脅威、セキュリティの傾向、セキュリティ環境の変化、および攻撃の事例。

すべての開発者とテスタに関連するセキュリティ トレーニングを要求します。

クロスサイト スクリプティング、バッファ オーバーフロー、SQL インジェクション、危険な API などの問題点の認知度を上げます。

製品に適用される特定のカテゴリの脅威を識別します。たとえば、サービスの拒否、特権の昇格、なりすまし、データ改ざん、情報開示、否認などです。

コンポーネントごとに、製品に対するセキュリティの脅威を分析します。

製品に基づいたセキュリティの脅威のチェックリストを作成します。

製品開発サイクルのすべての段階 (設計からテストまで) にセキュリティ レビューを追加します。