私は10人の開発者がいるチームで働いています。バックアップ、ソフトウェアの自動ビルド、自動デプロイメントなどを実行するサーバーがセットアップされています。これらのサーバーの一部には、運用システムへのログインの詳細(自動展開に必要)などの重要な情報が含まれています。
これらのマシンに誰がアクセスできるかを制限して、誤ってパスワードが漏洩するリスクを減らしたいと考えています。これを行うために、機密資料を含むサーバーへのアクセスを許可された4人を含むグループをActive Directoryに作成し、これら4人のユーザーのみがログオンできるようにしました。
これらのサーバーの一部は、スケジュールされたタスクとWindowsサービスを実行して、バックアップ/展開を実行します。これらのタスク/サービスは、特定の「共有」ユーザーアカウントで実行されます。「buildacc」と呼びましょう。これは、ビルド/デプロイメントを実行するには、タスクがネットワーク内の共有リソースにアクセスする必要があるためです。そのため、このユーザーにサーバーへのアクセス権も与えました。
Windowsでスケジュールされたタスクを変更できるようにするには、4人の開発者全員がこの「buildacc」アカウントへのアクセス権を持っている必要があります。つまり、すべての開発者が共有パスワードを知り、変更されたときにお互いに通知する必要があります。の。
個人用アカウントを使用して、ビルド用のスクリプトなどのスケジュールされたタスクを実行することを検討しました。私たちが目にする欠点は、チーム内のすべてのメンバーがビルドスクリプトを変更し、実際にスケジュールされたタスクを構成したユーザーアカウントで新しいことを実行できることです。
この状況に対処するためのベストプラクティスはありますか?
Windows 2008R2システムと2008R2 ADを使用している場合、管理されたサービスアカウントを使用できます。
このtechnetブログエントリ は、管理されたサービスアカウントの使用方法のかなり良い要約を持っていますが、基本的な原則は次のとおりです。
管理されたサービスアカウントは、コンピューターに強く関連付けられ、自動的に管理されたパスワードを持つADアカウントです。パスワードを作成する必要はなく、誰もそれを知る必要はありませんが、それはADアカウントであるため、ネットワークACLに使用でき、シナリオに最適です。
ただし、スケジュールされたタスクにMSAを使用するには、コマンドラインを使用してタスクを作成する必要があります(詳細については、 this および this スレッドを参照してください)。
全体的に、あなたが前もってやったことは問題ありません。必要な権限が設定され、スケジュールされたタスクを実行するために使用される専用の「サービス」スタイルのアカウント。
この時点で、実際に行う必要があるのは次のとおりです。
buildacc
に変更します現時点では、これは内部ポリシーの問題にすぎません。スケジュールされたタスクが実際に変更されないようにセットアップする必要があります。 「test.exe」を実行している場合は、開発者にそのexeファイルを変更してもらいますが、スケジュールされたタスク自体は変更しないでください。 4人の開発者全員が本当にスケジュールされたタスクを変更するためのアクセス権を必要とする場合、あなたは単にあなたがいる場所で立ち往生しています...
編集:私はまた、サービスやサーバー全体でbuildacc
アカウントを自由に使用しすぎることにも注意してください。 「ビルド」のために厳密に保持し、バックアップやその他のサービスを専用のアカウントで実行することをお勧めします。
スケジュールされたタスクを実行するために使用されるアカウントの解決策としてMSAについて言及しているいくつかの回答を見つけましたが、この投稿の作成者が述べたように、彼らはWindows Server 2008 R2を使用しており、私の調査によるとMSAこのOSでは、スケジュールされたタスクの実行に使用できません。
ただし、Windows Server 2012では、gMSA(グループ管理サービスアカウント)を使用して、この 記事 で説明されているように、スケジュールされたタスクを実行できます。