グループメンバーにSysAdminサーバーの役割を提供するActive Directoryグループに関するベストプラクティス情報やアドバイスを見つけるのに苦労してきました。私は、SQLの50〜100インスタンスの唯一のSQL Server DBAである新しい仕事にいます。 SysAdminサーバーの役割を持つ他の(ネットワーク)システム管理者が1人います。将来的には他にも存在する可能性があります(DBAの場合もそうでない場合もあります)。
2つのオプションを描いています。
オプション1:Active Directoryにグループを作成し、必要に応じて自分自身と他のグループをグループに追加し、ADグループの各SQL ServerインスタンスにSQL Serverログインを作成し、ログインにSysAdminサーバーロールを付与します。
これは便利で、ある程度の柔軟性があります。しかし、それは巨大なセキュリティリスクのようです。私はDBAとして、ADグループに参加する(またはグループから除外する)人物を完全に制御することはできません。現在、各SQL Serverインスタンスには、SysAdminロールを持つ少数のログインがあります。私、ネットワークシステム管理者、およびsaを除くすべてのユーザーからSysAdminを削除します。このタスクを実行してオプション1を実装した場合、私は最終的にはどこから始めたのかと同じです。
オプション2:各SQL Serverで個別のWindows認証(ADアカウント)ログインを使用し、各SysAdminサーバーロールを付与します。
これはそれほど便利ではありませんが、SysAdmin特権を持つのは2人のユーザー/ ADログインだけです。どちらもSysAdminロールのメンバーシップを他のユーザーに付与しない限り、一定のレベルの順序が存在するはずです。
どのオプションが望ましいですか?私が見落とした他のオプションはありますか?
自分の質問に答えるのは嫌ですが、オプション2を選択することにしました。 PCI DSSコンプライアンス に関連していますが、ようやくいくつかの "ベストプラクティス"情報を見つけました。いくつかの優れた推奨事項を含む優れた資料でした。すべてを実装することはできません。それらのうち、私はPCI監査に合格することは決してないかもしれませんが、私はセキュリティを最も確実に改善します。その価値について、以下にSYSADMIN
ロールに関連する推奨事項を示します。
カード会員データへのアクセスを制限する重要なステップは、sysadminサーバーロールに割り当てられる特権ユーザーの数を制限することです。既定では、BUILTIN/AdministratorsグループはSQL Server 2008 R2のsysadminロールのメンバーではありません。 PCI DSSは、「最小特権」アクセスモデルのベストプラクティスの概念を直接サポートしているため、以下をお勧めします。
- Sysadminロールのメンバーは、個々のWindowsログインを使用してのみログインする必要があります
- Sysadminロールに割り当てられるユーザーの数は最小限である必要があります
- Sysadminロールは、職務に基づいて割り当てる必要があります
- SysadminロールのWindowsログインのメンバーには、マップされたADグループではなく、SQL Serverへのアクセス権を個別に付与する必要があります
- SysadminロールのメンバーはローカルのWindows管理者であってはなりません
- Sysadminロールのメンバーは、SQL Serverサービスがアクセスできるサーバー上のフォルダーやファイル共有、データファイルやログファイルを含むフォルダー、データベースや暗号化キーをバックアップできるディレクトリなどにアクセスできないようにする必要があります
- Windowsのローカルまたはドメイン管理者には、SQL Serverへのsysadminアクセスを許可しないでください。
個々のアカウントは、管理がはるかに難しくなります。アクセスをより細かく制御できますが、Active Directory管理者を除外することはできません。サーバーのローカル管理者権限を付与されたユーザー インスタンスへのsysadminアクセスを取得できます 。また、非常に優れたDBAがかつて私に言ったように、ドメイン管理者を信頼できない場合は、大きな問題を抱えています。
ADグループへのアクセスを抽象化することにより、次の2つの利点があります。