複数のサーバーでサービスアカウントを共有する場合、どのようなリスクがありますか？
SQL Serverサービスアカウントにドメインアカウントを使用しています。場合によっては、論理的または主題的に関連する複数のサーバーがある場合、それらすべてのサービスアカウントに同じドメインアカウントのセットを使用します。各サーバーのユーザーアカウント権限は異なる場合がありますが、通常は多くの重複があります。
私の質問の要点は次のとおりです：1つのインスタンスにアクセスできるが、他のインスタンスにはアクセスできないユーザーは、共有サービスアカウントを悪用して他のサーバーにアクセスできますか？
これが私が対処しようとしている特定の状況です：
- デフォルトのSQLインスタンスを持つ2つのサーバーがあり、それらをorg-sql-1とorg-sql-2と呼びます。
- 私は各サービスにドメインアカウントを使用しているので、mydomain\orgDBService、mydomain\orgAgentServiceなどがあります（厳密に関連しているのかどうかはわかりませんが、単一のすべてのサービスのアカウント）。
- しかし、これらのドメインアカウントを両方のサーバーで再利用しているため、たとえば、org-sql-1とorg-sql-2の両方のデータベースサービスは、mydomain\orgDBServiceの下で実行されます。
特定のユーザーのアクセス許可が異なる場合でも、これらのサーバーには共通の目的とユーザーベースがあるため、これまで、セキュリティへの影響について特に疑問に思ったことはありません。
次に、3つ目のインスタンスを追加します。これをorg-sql-rptと呼びます。これは他のテーマとうまく適合していますが、重要な違いが1つあります。次のように、外部パートナー（つまり、組織の従業員ではない）がこのサーバーにアクセスできるようにします。
- その資格情報は、いくつかのデータベースを所有します（db_ownerに属します）。
- ただし、サーバーの役割（もちろん、パブリック以外）には属しません。
- 彼らは、このサーバーを稼働させる前に、限られた時間、OSデスクトップへの管理者アクセス権を持つ場合があります。
- 彼らはサービスアカウントのパスワードを知りません。
そのため、この新しいインスタンスのサービスアカウントとしてドメインアカウントを再利用することについて心配する必要がありますか？この人がorg-sql-rptの正当な認証情報を使用してorg-sql-1またはorg-sql-2にアクセスできるリスクはありますか？ （つまり、異なるサービスアカウント認証情報を使用することで軽減できるリスクはありますか？）
それとも、他の理由でこれは一般的に悪い考えですか？
[〜＃〜]編集[〜＃〜]
新しいインスタンスは、データベース、統合、およびレポートサービスをホストします（現時点では少なくとも）。分析サービスはありません。
外部ユーザーには昇格されたデータベース特権がありますが、明示的なインスタンス権限はありません。たとえば、ログイン、ジョブ、レポートを作成することはできません。
リスクを軽減するには、各マシンのサービスごとに個別のアカウントを作成する必要があります。必要なアカウントを作成するために必要な作業のレベルは非常に最小限ですが、Microsoftの推奨によると、これを行わないことに伴うunknownリスクは非常に高いです。
マイクロソフトのベストプラクティスでは、すべてのサービスに個別のサービスアカウントを使用することをお勧めします。
詳細は http://msdn.Microsoft.com/en-us/library/ms144228.aspx#isolated_services を参照してください。
主なポイントは次のとおりです。
サービスの分離
サービスを分離すると、侵害された1つのサービスが他のサービスを侵害するために使用されるリスクが軽減されます。サービスを分離するには、次のガイドラインを考慮してください。
個別のWindowsアカウントで個別のSQL Serverサービスを実行します。可能な限り、SQL Serverサービスごとに、権限の低いWindowsまたはローカルユーザーアカウントを使用してください。詳細については、「Windowsサービスアカウントとアクセス許可の構成」を参照してください。
SQL Serverのセキュリティ保護について話しているKBにも、サービスアカウントを適切に構成する方法が記載されています。
http://support.Microsoft.com/kb/216072
サービスアカウントを選択するときは、最小限の特権の原則を考慮してください。サービスアカウントには、ジョブを実行するために必要な権限のみが必要で、それ以上の権限は必要ありません。また、アカウントの分離についても考慮する必要があります。サービスアカウントは互いに異なるだけでなく、同じサーバー上の他のサービスでも使用できません。 SQL Serverサービスアカウントまたはサービスグループに追加の権限を付与しないでください。アクセス許可は、グループメンバーシップを通じて付与されるか、サービスSIDに直接付与されます（サービスSIDがサポートされている場合）。詳細については、Books Onlineのトピック「Windowsサービスアカウントの設定」を参照してください。
Technetの記事 http://technet.Microsoft.com/en-us/library/ms143504.aspx に、Windowsサービスアカウントとアクセス許可の構成というタイトルの記事があります。
セキュリティ上の注意：可能な限り低いユーザー権限を使用して、SQL Serverサービスを常に実行してください。可能な場合は、MSAまたは仮想アカウントを使用します。 MSAと仮想アカウントが不可能な場合は、SQL Serverサービスの共有アカウントではなく、特定の低特権ユーザーアカウントまたはドメインアカウントを使用します。異なるSQL Serverサービスに個別のアカウントを使用します。 SQL Serverサービスアカウントまたはサービスグループに追加の権限を付与しないでください。アクセス許可は、グループメンバーシップを通じて付与されるか、サービスSIDに直接付与されます（サービスSIDがサポートされている場合）。
上の段落の「MSA」は、Windows 7またはWindows Server 2008 R2以上へのインストールのデフォルトである「管理されたサービスアカウント」を指します。管理されたサービスアカウントは、各マシンに固有の事実です。
次のように、外部パートナー（つまり、組織の従業員ではない）がこのサーバーにアクセスできるようにします。
その資格情報は、いくつかのデータベースを所有します（db_ownerに属します）。
複数のインスタンスでサービスアカウントが同じであることに伴う懸念は、外部エンティティが権限を非常に簡単にエスカレートできることです。外部エンティティがdboにあることを考えると、ハッキングしてsysadminに昇格するリスクが開かれています。 DBOエスカレーション
次の懸念事項は、ローカル管理者アクセス権を持つユーザーがいる場合です（期間はここでは重要ではありません）。システム管理者として（SQLサーバーへのログインがなくても）簡単に自分自身を追加したり、saパスワードを変更したりすると、脅威が続行されます。そこ。これを行う方法に関する記事があります。
これらのエクスプロイトに基づいて、インスタンスごとに異なるサービスアカウントとパスワードを使用します。その外部エンティティが1つのサーバーから次のサーバーに移動するのをできるだけ難しくします。