開発者として、また開発チームのIT管理/サポートで働いていたので、完全にロックダウンされた環境から完全に非完全な環境まで、さまざまなタイプの環境に遭遇しました。私の限られたサポート経験では、ロックダウンされていないマシンでサポートする努力は少なく、これは確かに簡単だと感じましたが、もちろんこれはバイアスになる可能性があります。ITサポートの観点から見た見解を知りたいのですが、ロックダウンされていないマシンを持っている開発者をサポートするのは本当に難しいですか？
回答:
開発者のマシンをロックダウンしない最大の問題は、開発するソフトウェアを実行するには完全な管理者権限が必要になることです。開発者のアクセスは、実行する必要がある環境と同じである必要があります。「自己サポート」または「自己インストール」が必要な場合は、管理を行うときに使用する必要がある別の管理者アカウント（Bruce.adminなど）を与えますものですが、日々使用されていません。
彼らの塩に値するまともなUNIX管理者が日常の非管理作業のためにrootアカウントを使用することはないように。
ほとんどの開発者は技術的に賢く、彼らが何をしているかを知っています。多くの場合、多くの専門アプリをインストールする必要があり、これを行うための許可を得なければならず、ITをダウンさせて追加することは、特に大企業で双方にとって非常にイライラすることがあります。
マシンにソフトウェアをインストールすることに関して、彼らが望むことをできるようにすることが最善の方法であることがわかりましたが、サポートされていないもので問題が発生した場合、彼らは自分で対処します。ほとんどの開発者はこれに満足しており、とにかく自分のマシンの世話をすることを好む。
IEとオープンワードのみを使用するようにアカウンティングで誰かをロックダウンすることは問題ありませんが、4種類のブラウザーをインストールする必要があり、問題を解決するためにアプリをすばやくインストールする必要がある開発者にとっては面倒です。
私の経験では、多くの技術知識を持っているため、開発ショップ、ITサプライヤなど、従業員を信頼し、インストールしたいものを決定できる企業は、はるかに幸せであり、ITを煩わせません
開発者のマシンをロックダウンするメリットについての活発な議論については、このStackoverflowの投稿を参照してください。（免責事項：受け入れられた答えを書きました）。
システム管理者の観点から見ると、実稼働システムへのアクセスは機密性が高いため、業務に必要なユーザーにアクセスを制限する必要があります（これには、アプリケーションのティア3サポート責任を持つ開発者が含まれます）。開発用PCまたは開発用サーバーに対するローカル管理者権限は、運用システムのセキュリティを大きく損なうことはありません。
必要に応じて、マシンの再構築に使用できるイメージを作成します。SQL Serverの開発版、Visual Studio、Cygwin、MikTex、およびその他のアプリを手動でインストールするのは非常に時間がかかります。これらの大きなアプリがインストールされたイメージは、マシンのイメージを大幅に変更する必要がある場合に、かなり価値があります。
開発の観点から見ると、マシンのほとんどの問題を修正でき、通常はネットワークサポートスタッフの助けが必要になるのはごくまれです。過度に制限された環境では、開発者が完全に自分で実行できる作業を行うために、偽の開発サポートトラフィックが生成される傾向があります。
開発者が多くの管理作業を行う必要がある傾向がある別の場所は、開発環境をホストするデータベースサーバーです。ほとんどの開発者は、日常のDBAタスクを簡単に学習でき、とにかくこれに関する実用的な知識を得る必要があります（原則としてIMHO）。開発サーバー上の過度に制限的な管理者アクセスポリシーは、多くの方法で足を踏み入れることができます。
スクラッチ開発ネットワークは、配置できる場合、非常に良いアイデアです。必要に応じて、実稼働サーバーからファイアウォールを作成できます。
開発者が本番環境の構造を簡単に複製できる場合、導入テストの文化を促進し、フープを介さずに統合テストを合成できます。これにより、製品のリリースと展開の品質が向上する傾向があります。
本番環境をエミュレートできることは、本番の展開とサポートの問題に対する認識も高めます。開発スタッフが本番環境でアプリケーションがどのようにサポートされるかを考えることを奨励します。これはおそらくこれを念頭に置いて構築されたアーキテクチャを奨励するでしょう。
このネットワークにドメインコントローラーがある場合、メインドメインコントローラーとそのアカウントを信頼するように信頼関係を確立できます。この信頼関係は相反する必要がないため、実稼働ネットワークインフラストラクチャのセキュリティを損なうことはありません。これにより、信頼できない開発ネットワークを使用できますが、開発者はExchangeアカウントやファイルサーバーなどのドメイン認証されたリソースにアクセスできます。
開発者は、フープを飛び越えることなく、実験のための合理的な範囲を持っている必要があります。この作業の経路に政治的障害を置くことは、政治的には便利だが、長期的な（そしてしばしば認識されない）技術的負債を生む絆創膏の解決を促す傾向がある。システム管理者またはサポートアナリストとして、誰がピースを手に入れるかを推測します...
これは、UnixまたはLinux環境での問題ではないことを付け加えます。ユーザーは自分の環境をかなり大きくカスタマイズでき.profileます。自分の/home/bloggsj/binディレクトリの下にあるものをコンパイルしてインストールして、心から喜ぶことができます。「ローカル管理者権限」は主にWindowsの問題ですが、Unixでのルートアクセスが必要なものがまだいくつかあります。
私が今まで見た中で最も賢明なオプションは（両方の側で-今でも）-単にロック解除され、サポートされていないものです。彼らに自由を与え、彼らが台無しになれば、彼らが得ることができるのは標準的なイメージで再舞台することだけです...。そのような状況では、何らかの形で「信頼できない」ネットワークにそれらを配置することをお勧めします。
開発者のデスクトップをロックするという（非）感覚に関しては、すべてのロックは生産性を妨げるだけであると確信しています。
答えは本当に：単純なyesまたはnoの答えはありません。しかし、セキュリティは、少なくとも開発者ユーザーにとっても他のユーザーにとっても重要です。
一方で、はい開発者は技術的にもっと精通している傾向があります。一方、彼らの仕事はしばしばストレスの多い仕事であり、彼らの開発マイルストーンは、自分のシステムを安全な環境として維持するために必要な特別な注意よりも優先される可能性があります。これは開発者の批判ではありません。それは彼らの日々の義務の率直な考慮です。
開発者にシステムへの完全で自由なアクセスを提供する場合は、次の追加の対策を検討する必要があります。
開発システムをロックダウンする場合は、次のことを考慮する必要があります。
いずれにしても、開発者は特別なケースであり、何らかの追加サポートが必要であることを認める必要があります。あなたがこれのために予算を組んでいないなら、問題はたぶん今苦しんでいます...または将来にあります。
サイドノートとして、私は非常によく似た議論がsysadminsで起こるのを見ました。少なくとも2つの異なるジョブで、システム管理者がシステムをロックダウンするか、少なくとも2つのログイン（root / admin特権を持つもの;なしの1つ）を使用するよう提案されたときに、システム管理者が非常にひどく議論しています。多くのシステム管理者は、決してロックダウンされるべきではないと感じており、そのような対策に激しく反対しました。遅かれ早かれ、何らかのロックダウンを嫌う管理者がセキュリティインシデントを起こし、この例は私たち全員に教育的な効果をもたらすでしょう。
以前は、常に管理者権限で実行していたシステム管理者の一人でした。デュアルアカウントに変更を加えて、必要に応じて昇格させたとき、最初の数か月間は非常にイライラしていました。しかし、クラウドのシルバーライニングは、通常のアカウントがユーザーに課したのと同じ制限の下で生きていたときに、管理しているシステムのセキュリティについて多くのことを学んだということでした。それは私をより良い管理者にしました！同じことが開発者にも当てはまると思います。そして幸いなことに、Windowsの世界ではUACがあります。これにより、制限付きユーザーとして実行しやすくなり、必要な場合にのみ昇格できます。
個人的には、だれかが何らかのセキュリティ慣行を上回っているとは思わない。全員（sysadmins、devs、上級管理職を含む）は、十分なセキュリティ手順と監視を受け、彼らをつま先で保つ必要があります。別の言い方をすれば、会社のシステムとデータは保護するだけの価値はないということです。
別の言い方をしましょう。Mark Russinovichがルートキットに取り込めるなら、誰でもできます！
少数の開発者がいる場合、開発サーバーを提供するアプローチは可能性がありますが、開発者のフロア全体がある場合は、管理者権限を付与することにはまったく反対です。
問題は、開発者がフロア全体に行き着き、各開発者が何をするかということです。通常、ほとんどの開発者はセキュリティを意識することさえせず、アプリを機能させたいだけです。次に、「開発フェーズが完了しました。開発環境をテスト、プリプロド、およびプロドに複製してください」というリクエストが表示されます。
彼らはまた、ランダムなジャンク（ひどくパッケージ化されたソフトウェア）をインストールする習慣を身につけ、それから他の層の数十台のサーバーにインストールするようあなたに委任します。
ポリシーを非常に単純にします。
suかsudoNOシェルアクセスを持つことにロックダウンされます-アプリケーションのユーザーには。（これは、会計/監査用です）。sudoersます。その時点で、コマンドがファイルに追加されます。
上記は何よりも、プロジェクトをテストおよび上記のサーバーに移すとき、許可されるものと許可されないものについて考えさせます。
開発者のマシンをロックダウンするには、それ以上の労力が必要です。管理者権限なしではほとんど何もできないため、生産性に深刻な悪影響を及ぼします。もちろん、最終的にはシステムが台無しになりますが、IT部門は開発で使用されるすべてのサードパーティツールをサポートしていません。
したがって、Vincent De Baereが示唆したように、最善のアクションは、イメージからシステムを復元することです。もちろん、環境を復元する必要がありますが、それはITの問題ではありません。N回発生した場合、その人を一種の「ブラックリスト」に入れて、はい、しばらくの間彼の管理者権限を削除できます。
いずれにせよ、環境は、感染した（または台無しになった）マシンが他のマシンにまったく影響を与えないように、またはスパムや何かを送信しないように（つまり、今すぐ）明らかなことを言っているだけです、ごめんなさい）。
まあ、それは部分的にあなたが実行している環境（例えば、Linux対Windows）に依存するかもしれません。ただし、Windows環境を想定すると、開発ソフトウェアの一部は動作するために昇格されたアクセス許可を必要とするため、通常、それが価値があるよりも多くのトラブルです。たとえば、Visual Studioには管理者のアクセス許可が必要であることがわかっているため、仕事の必要な部分で誰かがフープを飛び回る利点はありません。
ただし、会社が物事をロックダウンする必要がある場合、最善策は、すべての開発者が自分のシステム上の仮想マシンに夢中になる可能性が高いことです。一部の人はこれをあまり好きではないかもしれませんが、ワールド（たとえば、制限のある通常のデスクトップおよび完全にカスタマイズ可能な環境）。
更新 -Windows側の注意点はもう少しありますが、管理者権限を必要とするVisual Studioは少し時代遅れであり、必要なアクセス許可（PDFファイル）を明示的に設定する方法があります。しかし、私がこれを知っているほとんどの開発者がVisual Studioだけでなく追加のツールを使用する傾向があり、それらのすべてがアクセス許可に関して必要とするものを予測するのが難しいことがあるという点で、これが私のオプションを変更するとは思わない。
私は（自分自身として）自分の機械、つまり意味を完全に制御することを好みます。必要に応じて管理者として実行します。
開発者がコンピューターへのフルアクセスを許可される前に、特別なトレーニングを提供できます。それらにいくつかのルールを設定すると、たまに監査を行い、ベストプラクティスに従っているかどうかを確認できます。
ほとんどの場合、IT管理者/ ITサポートの観点からITインフラストラクチャ、セキュリティ関連のもの、さらに高度な権限で開発しない理由について詳しく知る必要があります。（そして、あなたがそうしないことを確認する方法...）
「コンピューターについて知っておく必要があることをすべて知っていると言っても、盲目的に私たちを信用しないでください」;-)
ネットワーク、ドメインおよびアカウントのもの、非開発ツールのソフトウェアインストールなどでそれらをサポートする必要があります。
私の経験では、ロックダウンされたマシンのみを必要とするユーザーと、管理者アクセスを必要とする他のユーザー（開発者、科学者）の間でほぼ均等に分割されたユーザー人口です。ハイエンドの人々は多くの異なるソフトウェアを使用し、一部は社内、一部は使用しませんでしたが、多くは管理者が実行する必要があり、彼らの仕事は多くのパッケージを使用する必要があったため、人々ができるようにしたそれ自体。
次のプロセスになりました。
管理者権限を持つすべてのユーザーを「信頼されていない」VLANに配置したかったのですが、それを達成することはできませんでした。