開発者はPCの管理者権限を持っている必要があります
開発者はPCの管理者権限を持っているべきですか、それともパワーユーザーに十分なアクセス権を与えているのでしょうか？
いくつかのコメント：
- インストールが必要な新しいアプリケーションを試してみたい場合は、仮想マシンで試して、後でネットワーク管理者にインストールしてもらうことができます。それはうまくいくと思いますか？
- 開発者がPCで管理者のアクセス許可を必要とすることを行う必要がありますか？
5人の開発者からなるチームであり、Webアプリケーションを構築します
答えは「はい」です。開発者は、アイテムをテストし、ソフトウェアをインストールする（他に何もない場合は、開発中のあらゆるもののインストールプロセスをテストする）システムレジストリを調べ、管理者権限がないと正しく動作しないソフトウェアを実行するために、システム構成を使用する必要があります（ちょうどいくつかのアイテムをリストします）。開発作業に不可欠な他のタスクのホストがあり、管理タスクを実行する必要があります。
開発スタッフが必ずしも本番システムへのルートアクセス権を持っているわけではないことを念頭に置いて、ローカルPCの管理者権限は本番システムのセキュリティを大きく損なうことはありません。仕事をするのに必要なスタッフのローカルPCへの管理者アクセスを制限する正当な運用上の理由はほとんどありません。
ただし、管理アクセスを提供する最も重要な理由は、妥協した開発環境または二流の開発環境をセットアップすると、開発スタッフにメッセージが送信されることです。
「私たちはあなたの仕事をあまり評価していないので、正当な理由もなくあなたの仕事をする能力を著しく損なう用意ができています。実際、私たちはこれを喜んで、最悪のケースは、私たちが本当にあなたが仕事をする方法とあなたが何をするかを伝えることを私たちの特権として見ているタイプのコントロールフリークであるということですまたはそれをする必要はありません。あなたが与えられたもので間に合わせて、あなたがまったく仕事を得たことに感謝してください。 '
一般的に、開発スタッフに二次的な（基本的に欠陥のある作業環境はもちろん）労働環境を提供することは、有能な人材を維持できない、スタッフの離職率が高く、士気が低く、質の低い配給ができないという自然な結果のレシピです。特に官僚的な気まぐれにうんざりしている場合は、無責任です。
スタッフの離職は、スタッフの交代にかかるだけではありません。スタッフの離職の最も深刻なコストは、残っているもののほとんどがより良い仕事を得ることができない枯れ木になるということです。時間が経つにつれて、影響を受ける部門の機能が低下します。業界が十分に近い場合は、評判を得ることもできます。
注意すべき点の1つは、Unix-oidシステムまたはメインフレームシステムでの開発では、Windowsに比べて管理者特権の問題がはるかに少ないことです。これらのプラットフォームでは、ユーザーはシステム全体の権限を必要とせずに自分のドメインではるかに多くのことを実行できます。おそらく開発者にルートまたはSudoアクセスを引き続き必要とするでしょうが、これがないと、あまり頻繁にアクセスできなくなります。この柔軟性は重要ですが、コンピューターサイエンスの学校でUNIXから派生したオペレーティングシステムが引き続き人気を博している理由としてはあまり知られていません。
開発者は、使用しているマシンを完全かつ完全に制御する必要があります。ほとんどのデバッグツールは、作成中のアプリケーションのランタイムにフックするために管理者権限を必要とします。
さらに、開発者は頻繁に新しいものをダウンロードして試してみます。ネットワーク管理者が来て何かをインストールする必要があるなどの追加の手順を追加すると、開発者は単にイライラし、ネットワーク運用者にとってはすぐに命を落とすでしょう。
つまり、彼らはネットワークではなくTHEIRボックスの管理者でなければなりません。
はいといいえ。
はい、それはシステムサポートを煩わせる多くの時間を節約します。
いいえ、ユーザーは持っていないので、頼りにしないでください。
管理者権限で開発し、なしでテストします。それは正しく機能します。
上記のすべての理由で、ローカル管理者はい。ネットワーク管理者は、「彼らができる」ためにネットワーク管理タスクに必然的に引き込まれるためです。開発者は開発中です。ネットワーク管理はまったく別の仕事です。
開発者は通常、普通の人にはできないことをする必要があるため、通常は管理者アカウントを持っている必要があります。厄介なフープを飛び越えさせると、時間を無駄にし、士気を低下させます。高度なセキュリティの状況では例外が発生する場合がありますが、管理者アカウントで誰かを信頼できない場合、そのコードを信頼できないことは確かです。
また、ユーザーと同じ権限の利用可能なアカウント（ユーザーのプールの権限ステータスが異なる場合は複数のアカウント）も必要です。それ以外の場合、彼らは単にクールなものを開発して展開し、それがユーザーにとって機能しないことがわかります。
また、管理者アカウントでコンピューターを台無しにする方法が多すぎます（はい、私はやったことがあります）。 IT部門には、開発者のコンピューターをすぐに修正できない場合、開発者のコンピューターのイメージを再作成するというポリシーが必要です。私が契約したある場所で、管理者アカウントを取得するためにそのポリシーのコピーに署名する必要がありました。
これはかなりWindows固有の答えです。 Linuxや他のUnix-yシステムでは、開発者はユーザーアカウントのみで対応できることが多く、テスト用に別のアカウントは必要ありません（Sudoで使用できるアカウントがあれば、いつ使用しているかがわかります） Sudoですが、同じグループ権限を持つものが必要な場合があります）、OSに非常に簡単に非常に大きなダメージを与える可能性があるため、同じITポリシーが必要です。
はい、Half-Life 1（および関連するすべてのMOD：カウンターストライク、敗北の日など）は、Windows NT、2000、XPなどで適切に動作するために管理者権限（少なくとも1回目の実行の場合）が必要です。 。
また、昼食時にCounter Strikeをプレイしないのはどのような開発者ですか？ （確かにくだらないもの）
マシンの管理者権限なしで開発しなければならないという苦痛に耐えたので、私の答えはイエスだけになります。それは不可欠です。
絶対に！夜に映画をダウンロードするために、他にどのようにダウンロードマネージャーをインストールしますか？
時々、開発者は何らかのアイデアをテストするために、何かをインストールしたり、システムに何かを変更したりする必要がある場合があります。何かを変更する必要があるたびに管理者に電話しなければならない場合は不可能です。
私の個人的な見解では、管理者の中には、日々の小さなことでも彼らに依存するために、可能な限りすべてをきつく締める傾向があるというものがあります。他のユーザーを怒らせますか？答えはありません。しかし、ここでは常識は見られません。
前回PCに問題があったとき、システムの復元に積極的に参加し、管理者とチームで作業することを提案しました。彼またはルールを再定義します。彼は他の同僚の間で私たちの部屋でそれほどクールに見られなかったので、それはただ彼のエゴだったと思います。
答えは、開発者には2台のマシンが必要です!!
開発者は、管理者権限と十分な電力、メモリ、画面サイズ、移植性、および管理者権限を持ち、企業のウイルス対策ソフトウェアがロードされていますが、自動リセットポリシーで必要な場合は開発者が構成できます。
一部の開発者は管理者権限ですべてのユニットテストを行うという厄介な習慣があるため、開発者はこれを単体テストリリースモードアプリケーションに使用できます。
質問を逆にすると、答えやすくなります。開発者から管理者権限を削除する必要がありますか？ゲインとは何ですか？
しかし実際には、答えはあなたのコンテキスト、環境に依存すると思います。小規模な新興企業は、ISO認定の政府機関に対して別の答えを持ちます。
はい。ただし、より限られた環境でソフトウェアを実行する場合にユーザーが直面する制限を認識する必要があります。開発者は、限られたリソースと権限で「典型的な」環境に簡単にアクセスできる必要があります。以前は、ビルドプロセスの一部として、これらの「典型的な」システムの1つ（多くの場合、自分のワークステーションでVM））にビルドをデプロイすることを組み込んでいました。ソフトウェアがエンドユーザーのマシンでどのように機能するかについて。
また、プログラマーは、管理者以外のユーザー向けのソフトウェアを作成する際の厳格なルールを知る責任があります。アクセスを常に許可（または禁止）しているシステムリソースを正確に把握する必要があります。これらのリソースを取得するために使用されるAPIを知っている必要があります。
「私のマシンで動作する」という言い訳は決してありません！
システム管理者として、私は自分のワークステーションでローカル管理者権限を持つ開発者向けです。可能な場合、標準の「ユーザー」レベルのアカウントでほとんどのことを行ってから、別の「管理者」アカウントを使用して変更を加えたり、アプリをインストールしたりするのは悪い考えではありません。でる。また、本番環境にリリースする際にエンドユーザーがジャンプする必要があるセキュリティがどのようなものであるかを思い出してください。
また、[クリーン]システムまたはVMを使用して、システムを微調整することで適切にテストし、「私のシステムで正常に動作する」シナリオに入らないようにすることをお勧めします。
[申し訳ありませんが、英語は私の母国語ではありません。最善を尽くしています:)]
個人的な経験（私はc ++/SQL開発者です）：
私は以前の仕事でWindowsマシンの管理者でした。また、本番環境のデータベースを含むデータベースのdbo（dbaではなく）権限も持っていました。 2年半で8人がこれらのクレイジーな高い権利を持ちました...トラブルはありませんでした。実際、dbを手動で更新することで多くの問題を解決しました。ホットフィックスと開発者のために、多くのことを本当に迅速に行うことができました。
今、私は仕事を変えました。私は（たくさん泣いて）Windowsマシンの管理者になりました。しかし、devサーバーは、sshを使用して接続するRed Hatサーバーです。 Qtのインストールは、拷問、クォータ制限、スペース制限、実行および書き込み権限でした。やっとgaveめ、管理者に依頼してくれました。 2週間後もまだ何もインストールされていません。新聞の読み上げとAlt + Tabキーを押すのが本当に速くなっています。
私のソフトの開発者だけがこのマシンを使用しているため、管理者権限を要求しました。
->回答：「プロセスが存在する場合、あなたがやりたいことは何でもしない。prodで一度実行する必要がある」。
->技術管理者以外の人に説明しよう：「本番環境またはUAT環境では管理者権限は一切ありません。ただし、開発マシンは異なります。ソフトウェアの代わりに椅子を構築する場合、できることを教えてください。ワークショップは椅子が使用される場所のように見える必要があるため、ワークショップに必要なツールを入れないでください？実行可能パッケージをuatに提供します。それらを構築するために使用したライブラリとツールはエンドユーザーには見えませんパッケージをインストールする男。」
今日もまだ待っています。私は解決策を見つけ、開発環境を開き、お気に入りのオンライン裁判官に行き、自分自身に挑戦します。誰かがあなたのスクリーンを見るとき、彼はあなたにプログラミングを奪い取っているでしょう。 ;）
パワーユーザーなし
まず第一に、パワーユーザーは基本的に管理者です。したがって、 "limited"パワーユーザーに対するユーザーはシステムのセキュリティを強化しません。管理者である可能性があります。
通常のユーザーとして対話的にログオンします
2番目に、もちろん開発者は開発者のマシン（およびサーバーと2番目のボックスなど）への管理アクセスを必要としますが、もちろん通常の開発またはテスト中に管理者として対話的にログオンする必要はありません。このアプリケーションとほとんどのアプリケーションに通常のユーザーアカウントを使用します。
管理者として[ブラウザ、プラグイン、IM、電子メールクライアントなどを挿入する]を真剣に実行したくない場合。
必要なときにrootアクセスを持っている可能性が高い場合でも、通常はLinuxボックスにrootとしてログオンすることはありません。
別の個人管理者アカウントを使用する
開発者に、自分のマシンへの個別の個人管理者アカウント（できればドメインアカウント）を提供します。これは、管理アクセスが必要な他の開発/テストサーバーおよびボックスの有効な管理者でもあります。
「実行」およびVista + UACを使用して、プロンプトまたは要求を要求し、必要な場合にのみタスクとプロセスの管理者資格情報を入力します。スマートカードなどのPKIを使用すると、資格情報を入力する際の負担を大幅に軽減できます。
誰もが幸せです（または？;）
次に、アクセスを監査します。この方法では、トレーサビリティがあり、今アクセスする必要がある特定の開発/テストサーバーでターミナルサービスセッションを使用しているユーザーを簡単に見つけることができます...
確かに、ローカル管理者権限を必要としない開発作業は間違いなくあります-展開が別のサーバーまたは仮想マシンに対してテストされ、cassiniまたはローカルデバッグに使用されるものはすべて通常のユーザーとして実際に実行されるほとんどのWeb開発のように.
私は主に* nixの世界と、開発者が管理者にエスカレートする（Sudoまたはsuを介して）通常の非特権ユーザーアカウントで作業する標準モデルで作業しています必要に応じて/特権。
同等のWindowsの配置がどうなるかはわかりませんが、これは私の経験では理想的なセットアップです。
一方で、管理者権限をオンデマンドで利用できるようにすると、開発者は必要に応じてワークステーションを最大限に活用できます。
一方、Windowsソフトウェアには、すべてのユーザーが管理者権限を持っていると仮定してきた長い歴史があり、多くのプログラムは非管理者ユーザーに対しては実行されません。 Windowsのセキュリティ問題の多くは、コンピューターを確実に使用できるようにするために、すべてのユーザーが管理者である必要があるという暗黙の要件から直接生じます。 これは変更する必要がありますおよび管理者以外のユーザーに対してソフトウェアを実行するための最も効果的な方法は、開発者が管理者以外のユーザーとしてソフトウェアを実行することです。
ht tp：//msdn.Microsoft.com/en-us/library/aa302367.aspx
私の経験では、私たち（コーダー）と彼ら（セキュリティ）の間の妥協が常に必要です。私は認めますが（嫌いですが）、上記のMicrosoftの記事にはメリットがあります。私は長年プログラマーであったため、別のデバッガーをインストールするだけで苦痛を経験しました。仕事をどうやって成し遂げるのか、創造的に考えるようになりました。私たちのセキュリティチームとの長年の戦い（およびいくつかの議論）の後、デスクトップを含むすべての領域を保護する必要があるという彼らの仕事を理解しています。彼らは、最も単純なQuicktimeアプリであっても、毎日の脆弱性が現れることを示してくれました。クイックユーティリティをインストールしたり、ローカルのIISを調整したりするたびにフラストレーションが発生することがあります。深刻なセキュリティ問題を引き起こす可能性があります。 。彼はデバッグしようとしていたが、何百人もの人々にウイルスを手に入れる（そしてそれからGIVEする）ためにシマンテックを停止させた。それは混乱だった。彼はただ「あなたにそう言った...」と言いたかったのがわかりました。
私たちの副部長（少なくとも私のもの）はただ私たちの会社を守りたいだけだということを学びました。良いニュースは、妥協点を見つけたということです。安全なネットワークで仕事を終わらせることができ、副次官たちはクールです！
信条
これには2つの方法で答えることができます。はい、いいえ、またはそれは異なります。 -もっと曖昧にできますか...
彼らが仕事をすることが必要かどうかによります。その場合は、コンピューターの管理権限を付与します。そうでない場合はしないでください。すべてのソフトウェア開発でエンジニアに管理者権限が必要なわけではありません。
はいといいえはあなたの見解に依存します。一部のエンジニアは、自分のコンピューターを自分のドメインと見なしており、自分のドメインのルールです。他の人は責任を望まない。
私は管理者権限を持っていない会社で働いており、管理者権限を必要とする何かをする必要があるときはいつでもヘルプデスクに電話しなければならず、再起動するまで一時管理者権限を与えられました。これは時々苦痛でしたが、それがそうだったので、私はそれで生きました。また、自分のコンピューターの完全な管理者権限がある場所で働いています。これは、OSに接続するソフトウェアをインストールし、コンピューターをヘルプデスクに移動してハードドライブのイメージを再作成する必要がある場合を除いて、すばらしいことでした。
個人的には、エンジニアにはコンピューターの管理者権限が必要だと感じていますが、それを台無しにすると新しいベースラインイメージがリロードされ、元のベースライン以降に行われたものがすべて失われることを理解しています。ただし、会社の全員が自分のコンピューターの管理者権限を持つべきだとは思いません。経理、管理アシスタント、およびその他の部門には、これらの権限を付与する必要がないため、付与するべきではありません。
うわー、この質問は確かにいくつかの興味深い答えに開かれます。返信で私はよく使われる引用-'It Depends' :)
中小企業では、これは単に実用的な問題である可能性があります。また、開発者は技術的に最も熟練している可能性が高いため、自分のマシンを管理することは理にかなっています。
個人的に、私は必要なときに使用できる「管理者アカウント」のファンです。つまり、「Run As ..」（このアプローチは原則としてUACと非常に似ていることに気づきました）。
デスクトップソフトウェアを開発している場合、開発者がエンドユーザーの経験する範囲内で作業することは悪い考えではありません。つまり、制限された権利または制限された権利です。制限された権限でソフトウェアを構築する場合、同じアクセス許可セットを与えられたターゲットユーザーが直面するのと同じ問題に遭遇する可能性が高くなります。
とはいえ、優れたテストラボや適切なQAチームがいる場合は、これが重要なポイントになる可能性があります。特に、半分ほどのALMプラクティスがある場合はなおさらです。
だから最後に-私はUACなしで開発します。主に私は自分自身と私のスキルを信頼しているからです。チーム環境では、投票に参加しました。大規模な組織では、この自由がない場合があります。多くの場合、エンタープライズ管理者は最終決定権を持っています:)
私の会社では、開発者、エンジニア、上司（会社の所有者）にローカル管理者権限があります。上司にはネットワーク管理者の特権もあります。万が一その邪魔なバスにぶつかった（または辞めた）場合に備えてです。他の全員がロックダウンされます。
システム管理者として、特に未承認のソフトウェアがインストールされた場合、このセットアップは時々私を少し悲しませました。しかし、開発者のバックグラウンドから、私はパワーユーザーが自分の環境をより細かく制御する必要があることを理解しています。念のため、ワークステーションの定期的なバックアップを行っています。
ちなみに、私は他の誰よりも上司が物事をいじくり回すことに多くの問題がありました。昔の質問のように、「象はどこに座るのか？どこでも好きなところに！」しかし、彼が本質的に「バックアップ」システム管理者である小さな会社では、多くの選択肢はありません。