私の組織では、サービスアカウントに関して相反する考え方があります。これは、SharePointデータベースを実行することのみを目的としてSQLServerを展開することを望んでいるためです。
あるグループは、サーバーアプリケーションごとおよび環境(本番、UAT /テスト、開発など)ごとに異なるサービスアカウントを使用する必要があると考えています。したがって、この例では、SharePointの各SQL Serverインストールには、prod、UAT、およびdev用の独自のサービスアカウントがあります。その理由は、セキュリティと環境間の干渉の防止です。
別の人は、サービスアカウントは本番環境とテスト環境の間で共有する必要があると考えています。したがって、この例では、prod、UAT、およびdev全体に1つのSQLServerサービスアカウントがあります。 (異なるサーバーアプリケーション間でそのアカウントを共有するかどうかはわかりません。)変更するパスワードが少なくなり、複雑さが軽減されるため、セキュリティが再び確保されます。
セキュリティ、稼働時間と信頼性、ミスからの保護、リスク管理などを考慮して、推奨されるアプローチは何ですか?
ありがとうございました!
最初のグループに従います。このグループには、環境とサーバーアプリケーションごとに個別のサービスアカウントがあります。
主な理由はセキュリティですが、もう1つの理由は、セキュリティの変更が必要なテストまたは開発で作業が行われている場合、それが本番環境にまったく影響を与えていないことがわかっていることです。
ぜひ、開発環境とUAT /テスト環境で同じサービスアカウントを共有してください。しかし、生産は別々にしてください。他の回答ですでに強調されている変更管理の問題を除けば、開発およびテスト担当者は、通常のイベントの過程で本番システムにアクセスするビジネスを行うべきではありません。
確かに、セキュリティ上の懸念から、アプリケーション/サービスごとに1つのアカウントが必要になる傾向があります。ただし、prod、UAT、およびdevのアカウントが異なるレベルに進む必要はないと思います。これは、アプリケーションをデプロイしたときに構成を変更する必要があり、それがエラーの原因となる可能性があることを意味します。
編集:私はBravaxの答えを見たばかりで、彼はライブシステムに影響を与えない開発アカウントへの変更について有効なポイントを上げています。