開発者は自分のPCで管理者権限を持つ必要があります


135

開発者はPCの管理者権限を持っている必要がありますか、それともパワーユーザーに十分なアクセス権を与えているのですか?

いくつかのコメント:

  • インストールが必要な新しいアプリケーションを試したい場合は、仮想マシンで試し、後でネットワーク管理者にインストールしてもらうことができます。それでうまくいくと思いますか?
  • 管理者権限を必要とする開発者がPCで行う必要があることはありますか?

私たちは5人の開発者のチームであり、Webアプリケーションを構築しています


116
仕事に行って、自分のマシンに対する管理者権限がないことに気付いた場合、翌日戻ってくることはありません。開発者の生活をより困難ではなく、より簡単にします。
アナカタ2009

29
この質問は、選択バイアスの影響を受けます。開発者のマシンをロックダウンする必要がある場合がありますが、この種の応答は、開発者向けのサイトでは決して投票されません。
romandas 2009年

5
人が考えるよりも一般的ではありません。ほとんどの場合、根本的な問題は機密データです。たとえば、スイスの銀行機密法は、開発者が実際の顧客データを見るのを妨げる傾向があります(アカウントの調整は読者の練習問題として残されています)。この場合、問題はマシンをロックダウンすることではなく、開発作業用にサニタイズされたデータセットを提供することです。他のほとんどの状況は、規制要件(分類されたデータの使用など)または自己奉仕CYAのいずれかです。
ConcernedOfTunbridgeWells

12
同じ質問がServerFaultでどのように展開されるのか...(@romandas)
Ben Mosher

4
@BenMosher:ここにあなたの答えだ:serverfault.com/questions/232416/...
kmote

回答:


228

答えは「はい」です。開発者は、アイテムをテストし、ソフトウェアをインストールし(開発しているもののインストールプロセスをテストするため)、レジストリについて調べ、管理者権限なしでは適切に機能しないソフトウェアを実行するために、システム構成を操作する必要があります(いくつかの項目をリストします)。管理作業を行うために必要な、開発作業に不可欠な他の多くのタスクがあります。

開発スタッフが必ずしも本番システムへのrootアクセス権を持っているわけではないことを念頭に置いて、ローカルPCの管理者権限は本番システムのセキュリティを大幅に損なうことはありません。ローカルPCへの管理アクセスを、それを必要とするスタッフがローカルPCに制限する正当な運用上の理由はほとんどありません。

ただし、管理アクセスを提供する最も重要な理由は、侵害された、または二流の開発環境をセットアップすると、開発スタッフにメッセージが送信されることです。

「私たちはあなたの仕事をほんの少しだけ評価します。私たちは正当な理由なしにあなたの仕事をするあなたの能力を著しく妥協する用意があるからです。実際、私たちはこれを私たち自身の呪いをカバーするために行うこと、非常に官僚主義の気まぐれに足を踏み入れること、または私たちが単に気になることができないので、非常に満足しています。それはまさに最良のケースです。最悪のケースは、私たちが実際にコントロールフリークの一種であり、それを私たちの仕事のやり方や、何をすべきか、何をする必要がないかを伝えるための私たちの有力者だと見なしている場合です。与えられたものをやり直し、仕事を得たことに感謝しなさい。」

一般に、開発スタッフに二流(基本的に欠陥のあるものはもちろん)の作業環境を提供することは、有能な人材を維持できない、スタッフの離職率が高い、士気が低い、質の低い出産など、スタッフを怒らせるという自然な結果のレシピです。特に官僚的な気まぐれにうろついているような倍音がある場合、そうするためにあなたの道を外れることは無責任です。

スタッフの離職率は、スタッフの入れ替えにかかるコストだけではないことに注意してください。スタッフの離職の最も深刻なコストは、残っているもののほとんどが、より良い仕事を得ることができない枯れ木であることです。時間が経つと、影響を受ける部門の機能が低下します。業界が十分に近い場合は、評判を得ることもできます。

注意すべき1つの点は、管理特権は、Windowsの場合よりも、unix-oidまたはメインフレームシステムでの開発の問題のはるかに少ないことです。これらのプラットフォームでは、ユーザーはシステム全体の権限を必要とせずに、自分のドメインではるかに多くのことができます。あなたはおそらくまだ開発者にrootまたはsudoアクセスを必要とするでしょうが、これがないと足りなくなることはそれほど多くありません。この柔軟性は重要ですが、コンピュータサイエンスの学校でUNIX派生のオペレーティングシステムが引き続き人気を博している理由としてはあまり知られていません。


3
管理者権限を持つこととすべてを管理者権限で実行することには違いがあります:)多くの開発者はもちろん管理者権限を必要とします。ただし、ローカルシステムで管理者権限を使用してすべてをインタラクティブに実行することは、最低限の特権ではありません。これは、開発者がアクセスできる本番システムに対する攻撃を可能にし、侵害されたローカルPCは攻撃者に同じアクセス権を与えます。これは思ったより簡単です。セキュリティは、レイヤーごとの問題であり、プロセスごとの最小特権とユーザートレーニングの問題です。すべてのデバイスのセキュリティを尊重することが唯一の方法です。vimeo.com
Oskar Duveborn

私は開発者にローカル管理者権限を与えることを提案していますが、「ローカルPCの管理者権限は本番システムのセキュリティを大幅に損なうことはありません」と言っても、環境に依存します。ほとんどのIT担当者が懸念しているのは、会社全体に広がる可能性のあるマルウェア/ウイルスを含むソフトウェアをインストールするか、誰かがローカルマシンを侵害し、機密データファイルがローカルまたはローカルデータベースに保存されている場合です。完璧な世界では、開発者はHIPAA / PCIデータファイルにアクセスできず、すべての開発データベースはクリーンな状態でスクラブされますが、そうではないことはわかっています。
L_7337 2018

87

開発者は、使用しているマシンを完全かつ完全に制御する必要があります。ほとんどのデバッグツールは、ビルドしているアプリケーションのランタイムにフックするために管理者権限を必要とします。

さらに、開発者は頻繁に新しいものをダウンロードして試します。ネットワーク管理者が来て何かをインストールする必要があるなどの追加の手順を追加すると、開発者が不満を抱き、ネットワーク運用担当者にとってすぐに地獄になります。

とはいえ、彼らはネットワークではなく、そのボックスの管理者である必要があります。


5
私が管理者権限を持つ開発者と遭遇した最大の問題は、あなたがあなたのローカルコンピュータのリソースに対して持っている権利を当然のことと思っていることです。非常にくだらないソフトウェアの結果-C:\ Program Filesへの書き込み、HKLMへの書き込みなど。ワークステーションでは、おそらく、そうでない場所でのテストが必要です。
SqlRyan 2009年

4
@rwmnau:それはウェブ開発には当てはまりません。また、通常の権限でQAを実行すると、問題がすぐに明らかになります。
NotMe 2009年

2
VMを利用可能にして、管理者権限なしでdev-testログインを行うことは、ソフトウェアが通常のユーザー権限で実行されることをテストするための良い方法です。
ConcernedOfTunbridgeWells

このような管理者のみの権限でリリースされたソフトウェアは、非常に質の悪い(またはまったくない)QAプロセスを通過しました。ソフトウェアは実際の環境でテストする必要があるため、QAで早期に把握し、開発者が見落とす問題を修正する必要があります。正しい?

2
@rwmnau-自分の能力に見合う開発者はこれを完全に認識していますが、答えは開発マシンをロックダウンすることではありません。これらの問題を解決するために都合の良いときにプロジェクトを展開できるテスト環境を提供することです。
スペンサールポート

48

はいといいえ。

はい、システムのサポートに煩わされる時間を大幅に節約できます。

いいえ、ユーザーは持っていないので、頼りにしないでください。

私たちは管理者権限で開発し、なしでテストします。これは正しく機能します。


11
妻は自分のコンピューターで管理者以外のアカウントを要求する必要があったため、ユーザーができることを確実に実行できるようにしました。あなたのポリシーは正確です(したがって賛成です)。
David Thornley、

1
正確には、devにはadmin、test、QAにはユーザーが必要です。
ワトソン博士

私はあなたにこれ以上同意することはできません!管理者アクセスは開発に最適ですが、ほとんどのユーザーはそれを持ちません(企業ソフトウェアを開発する場合... ITは通常、かなりうまくロックします)。
パルスヘッド2009

18

上記のすべての理由により、ローカル管理者はい。「できる」という理由でネットワーク管理タスクに必然的に引き込まれるため、ネットワーク管理者はいいえ。開発者は開発している必要があります。ネットワーク管理は、まったく別の仕事です。


15

開発者は通常、平均的な人がしないことを行う必要があるため、通常は管理者アカウントを持っている必要があります。ぎこちないフープを乗り越えさせると、時間を浪費し、意気消沈します。セキュリティの高い状況では例外が発生する可能性がありますが、管理者アカウントで誰かを信頼できない場合は、その人のコードを信頼できないはずです。

また、ユーザーと同じ権限の利用可能なアカウントが必要です(ユーザーのプールに異なる権限ステータスがある場合は複数のアカウント)。そうでなければ、彼らは単に何かクールなものを開発し、それを配備して、それがユーザーにとって機能しないことに気付くかもしれません。

また、管理者アカウントでコンピューターを台無しにする方法が多すぎます(そうです、私はやった)。IT部門は、開発者のコ​​ンピューターを迅速に修正できない場合、コンピューターのイメージを再作成するというポリシーを必要としています。契約したある場所で、自分の管理者アカウントを取得するためにそのポリシーのコピーに署名する必要がありました。

これはかなりWindows固有の答えです。Linuxやその他のUnix-yシステムでは、開発者はユーザーアカウントだけで問題を解決できることが多く、テスト用に別のアカウントを必要としないことがよくあります(sudoを実行できるアカウントがあれば、いつ使用しているかがわかります。 sudo、ただし同じグループ権限を持つものが必要な場合があります)、OSに非常に大きな損害を与える可能性があるため、同じITポリシーが必要です。


4
「セキュリティの高い状況では例外が発生する可能性がありますが、管理者アカウントで誰かを信頼できない場合は、そのコードを信頼できないはずです。」-それは素晴らしい考えです、ありがとう!
ユーザー

どちらの方法でもコードを信頼することはできません。すべてについてピアレビューされたコードを実行する必要があります。そして、それはインストールについても理にかなっていると思います。インストールしようとしているソフトウェアを誰かに「ピアレビュー」してもらいます。
ティム

10

はい、Half-Life 1(および関連するすべてのMod:カウンターストライク、敗北の日など)がWindows NT、2000、XPなどで適切に機能するには、管理者権限(少なくとも最初の実行では)が必要です。 。

そして、どのような開発者が昼食時にCounter Strikeをプレイしませんか?(確かにくだらないもの)


10

マシンの管理者権限なしで開発しなければならないという苦痛に耐えてきたので、私の答えは「はい」に過ぎない可能性があります。それは不可欠です。


8

絶対に!夜間に映画をダウンロードするために、ダウンロードマネージャーを他にどのようにインストールしますか?

時々、開発者はいくつかのアイデアをテストするためにシステムに何かをインストールしたり何かを変更したりする必要があります。何かを変更する必要があるたびに管理者に連絡する必要がある場合は不可能です。

また、管理者の中には、日常的に少しでも物事に依存するために可能なすべてのことをやり直す傾向があるという個人的な見解もあります。つまり、仕事を確保するために何が必要でしょうか。他のユーザーを怒らせる?答えはありません。しかし、常識はここでは見られません。

前回私のPCに問題があったとき、私はシステムの復元に積極的に参加し、管理者とチームで作業するいくつかの提案をしました、または私は考えました...管理者は非常に怒り、教えようとしたと非難しました彼またはルールを再定義します。他の同僚の間で私たちの部屋でそれほどクールではなかったので、彼のエゴだけだったと思います。


これ以上は同意できません。6年間システムエンジニアになってから、何かを修正するためにヘルプデスクに電話をかけなければならないのは辛いことです。
マシューホワイト

8

答えは、開発者は2台のマシンを持っている必要があるということです。

  • 管理者権限と十分なパワー、メモリ、画面サイズ、移植性、およびADMIN権限を備えた開発の1つ。企業のウイルス対策ソフトウェアがロードされていますが、自動リセットポリシーで必要な場合は開発者が設定できます。

  • 企業の負荷、ポリシー、管理者以外のユーザー権限などを備えた1つの企業。開発者の中には、管理者権限ですべてのユニットテストを行うという嫌な癖があるため、リリースモードアプリケーションのユニットテストにこれを使用できます。


9
素晴らしいアイデアです...しかし、ほとんどの企業は、「良い」マシンを1つも2つも提供しません。
マシューホワイト

1
「標準」ビルドのVMで2番目のマシンを実行できます。これは、開発ネットワークが独自のドメインに分離されている場合に特に役立ちます。メインドメイン上の別の本番VMにより、開発者はネットワークリソースにアクセスできます。
ConcernedOfTunbridgeWells

5

質問を逆にすると答えるのが簡単になると思います。開発者から管理者権限を削除する必要がありますか?利益は何ですか?

しかし、実際には、答えはあなたのコンテキスト、環境に依存すると思います。小規模な新興企業は、ISO認定の政府機関に対して別の答えを持っています。


5

はい。ただし、より制限された環境でソフトウェアを実行するときにユーザーが直面する制限に注意する必要があります。開発者は、リソースと権限が制限された「一般的な」環境に簡単にアクセスできる必要があります。過去に私はビルドプロセスの一部としてこれらの「典型的な」システムの1つ(多くの場合、自分のワークステーション上のVM)にビルドをデプロイすることを組み込んだので、ソフトウェアが最終的にどのように機能するかを常にすばやく感じることができました。ユーザーのマシン。

プログラマーには、管理者以外のユーザー向けのソフトウェアを作成する際の厳格な規則を知る責任もあります。常にアクセスを許可(または禁止)されているシステムリソースを正確に把握している必要があります。これらのリソースを取得するために使用されるAPIを知っている必要があります。

「私のマシンで動作する」という言い訳は決してありません!


5

システム管理者として、私は自分のワークステーションでローカル管理者権限を持つ開発者全員です。可能な場合は、ほとんどのことを標準の「ユーザー」レベルのアカウントで行い、別の「管理者」アカウントを使用して変更を加えたり、アプリをインストールしたりすることは悪い考えではありません。でる。また、本番環境にリリースするときにエンドユーザーがジャンプしなければならないセキュリティの問題を思い出させることも役立ちます。

余談ですが、[クリーン]システムまたはVMを用意することもお勧めします。これにより、システムを微調整することにより、適切にテストし、「システムで問題なく動作する」シナリオに陥らないようにすることができます。


3

パワーユーザーなし

まず第一に、パワーユーザーは基本的には管理者です。つまり、ユーザーをパワーユーザーに「制限」しても、システムのセキュリティは向上しません。あなたも管理者である可能性があります。

通常のユーザーとして対話的にログオンする

第2に、当然、開発者は開発者のマシン(およびサーバーと第2のボックスなど)への管理アクセスを必要としますが、通常の開発またはテスト中に管理者として対話的にログオンすることはできません。このアプリケーションとほとんどのアプリケーションには、通常のユーザーアカウントを使用してください。

管理者として本気で[ブラウザ、プラグイン、IM、電子メールクライアントなどを挿入]を実行したくない。

必要なときにrootアクセス権を持っている場合でも、通常はLinuxボックスにrootとしてログオンしません。

別の個人管理者アカウントを使用する

開発者に自分のマシンへの個別の個人管理者アカウント(できればドメインアカウント)を提供します。個人管理者アカウントは、他の開発/テストサーバーおよび管理者アクセスが必要なボックスの有効な管理者でもあります。

「別のユーザーとして実行」およびVista + UACを使用してプロンプトまたはプロンプトを要求し、必要な場合にのみタスクとプロセスの管理資格情報を入力します。スマートカードなどのPKIを使用すると、資格情報を頻繁に入力する負担を大幅に軽減できます。

誰もが幸せです(または?;)

次に、アクセスを監査します。このように、追跡可能性があり、特定の開発/テストサーバーでターミナルサービスセッションを使用しているユーザーを簡単に見つける方法が用意されています...

確かに、ローカル管理者権限を決して必要としない開発作業は確かにあります。ほとんどのWeb開発のように、展開は別のサーバーまたは仮想マシンに対してテストされ、ローカルデバッグに使用されるcassiniなどは通常のユーザーとして実際に実行されます。


2
あなたは言っています:彼らに管理者としてログオンすることを許可しないでください、しかし彼らがそれを必要とする何かをする必要がある場合に備えて彼らにキーを与えます。私はUACに関してMSのサイトでこれと同じがらくたを読みました、そしてそれは開発者が一日に何百もすることに関して真の考慮が完全に欠如していることを示しています。
NotMe 2009

2
UACは、普通の人が自分の足で撃たないようにするために設置されました。開発者がこれを行う場合、彼を恥じます。彼が継続的にそれを行う場合、彼は別の仕事の行を見つける必要があります。
NotMe 2009

管理者としてログインするために、私たちが実際にそれらに「許可」するキーをそれらに与える場合。日常の作業でそれを行うのは決して良いことではありません。オタク、コーダー、または管理者であるという理由だけで、これが通常または必要であると人々が考える理由は、私を超えています。
Oskar Duveborn 2009

現代のシステム管理者が1日に何をするかを目にしたことがあれば、管理アクセスと代替資格情報の入力の必要性は、これまでにないハードコアシステムレベルのコーダーよりはるかに高いことに気付くでしょう。それでも、日常のタスクに管理者としてログオンすることはなく、問題なく動作します。
Oskar Duveborn 2009

UNIXシステムを管理しているときでも、通常はrootとしてUNIXシステムにログオンしないので、開発者であっても、なぜWindowsシステムでそれを行うのでしょうか。それは意味がありません。Skypeのようなランダムなアプリをすべて実行したり、高いシステム権限で何を実行したりしても、控えめに言っても無知です。必要なアプリだけを昇格させます。
Oskar Duveborn 2015年

3

私は主に* nixの世界で働いており、標準モデルでは、開発者が(sudoまたはを介してsu)通常の非特権ユーザーアカウントで作業し、必要に応じて管理者特権にエスカレーションできます。

対応するWindowsの配置がどうなるかはわかりませんが、これは私の経験では理想的なセットアップです。

  • 一方では、オンデマンドで管理者権限を使用できるようにすることで、開発者は必要に応じてワークステーションをフルに活用できます。

  • 一方、Windowsソフトウェアには、すべてのユーザーが管理者権限を持っていると想定してきた長い歴史があり、管理者以外のユーザーに対しては多くのプログラムが実行されません。Windowsのセキュリティ問題の多くは、コンピューターを確実に使用できるようにするには、すべてのユーザーが管理者である必要があるという暗黙の要件に直接起因しています。 これは変更する必要があり、管理者以外のユーザーに対してソフトウェアを確実に実行する最も効果的な方法は、開発者が管理者以外のユーザーとしてソフトウェアを実行することです。


過去5〜10年間、通常のユーザーとして実行できないビジネスアプリケーションに遭遇したことはないと思います。かつて私がBOFHになり、その場所のすべてのユーザーは、2001年以降、すべてを通常のユーザーとして実行することを余儀なくされました。そのようなレガシーアプリが実行された場合(サンドボックスでそれをだます)、最近のWindowsバージョンに適用される自動shimもあり、私の日常の開発作業では、アタッチする必要があるときに昇格されるのはVisual Studioだけですデバッグのために他のプロセスに。
Oskar Duveborn 2015年

3

[英語は私の母国語ではありません。最善を尽くします:)]

個人的な経験(私はc ++ / SQL開発者です):

私は以前の仕事で私のWindowsマシンの管理者でした。また、実稼働環境データベースを含むデータベースに対するdbo(dbaではなく)権限も持っていました。2年半で、8人の人々がこれらのクレイジーな高い権利を手に入れました... 実際、dbを手動で更新することで、多くの問題を解決しました。ホットフィックスと開発者のために、多くのことを本当に迅速に行うことができました。

今、転職しました。私は自分のWindowsマシンの管理者になりました(たくさん泣きました)。ただし、devサーバーは、sshを使用して接続するRed Hatサーバーです。Qtをインストールしようとするのは、拷問、割り当て制限、スペース制限、実行権、書き込み権でした。ようやくあきらめて、管理者に代行してくれるように頼みました。2週間後、まだ何もインストールされていません。私は新聞を読むこととalt + tabヒットで本当に速くなっています。

私のソフトの開発者だけがこのマシンを使用するため、私は管理者権限を求めました。

->回答:「プロセスがある場合は、あなたがやりたいことを何もしないようにしてください。製品で一度正常に実行する必要があります」。

->テクニカルマネージャー以外に説明しようとしています。「本番環境またはUAT環境では、管理者権限は一切ありません。ただし、私の開発マシンは異なります。ソフトウェアの代わりに椅子を構築する場合、私ができることを教えてください。私のワークショップは椅子が使用される場所のように見える必要があるため、ワークショップに必要なツールは何も入れません。実行可能なパッケージをuatに渡します。それらを構築するために使用したライブラリとツールは、エンドユーザーやパッケージをインストールする人。」

今日も待っています。私は解決策を見つけ、開発環境を開き、お気に入りのオンライン裁判官に行き、自分自身に挑戦しました。誰かがあなたの画面を見ると、彼はあなたにプログラミングを仕掛けます。;)


2

これには2つの方法で答えることができます。はい、いいえ、またはそれは依存します。-私はもっと曖昧にできますか?...

彼らが自分の仕事をすることが必要かどうかによって異なります。その場合は、コンピュータに対する管理権限を付与します。そうでない場合はしません。すべてのソフトウェア開発が管理者権限を持つエンジニアを必要とするわけではありません。

はいといいえはあなたの意見に依存します。一部のエンジニアは自分のコンピューターをドメインと見なしており、それらはドメインの規則です。他の人は責任を望んでいません。

私は管理者権限のない会社で働いていました。管理者権限を必要とする何かをする必要があるときはいつでも、ヘルプデスクに連絡しなければならず、再起動するまで一時的な管理者権限を与えられました。これは時々苦痛でしたが、それがそうだったので私はそれと一緒に暮らしました。私は自分のコンピューターに対する完全な管理者権限を持つ場所でも働いています。これは、OSを起動するソフトウェアをインストールし、コンピューターをヘルプデスクに連れて行ってハードドライブのイメージを再作成させる必要があったときを除いて、すばらしいものでした。

私は個人的に、エンジニアは自分のコンピューターの管理者権限を持っている必要があると感じていますが、それを台無しにすると、新しいベースラインイメージがリロードされ、元のベースライン以降に行われたすべてが失われることを理解しています。ただし、会社の全員が自分のコンピューターの管理者権限を持っている必要があるとは思いません。経理、管理アシスタント、およびその他の部門は、実際にはそれらの権利を持っている必要はないので、付与されるべきではありません。


私は、ある会社の請負業者でしたが、管理者権限を取得するために、ITスタッフが自分のコンピューターを修正するのに10〜15分しか費やさず、完全なワイプと再実行を行うという承認に署名する必要がありました。 -画像。それは私には公平に思えました。
David Thornley、

同意した。大きな力には大きな責任が伴います。
CraigTP 2010年

2

ht tp://msdn.microsoft.com/en-us/library/aa302367.aspx

私の経験では、私たち(コーダー)と彼ら(セキュリティ)の間の妥協が常に必要です。認めます(嫌いですが)、上記のMicrosoftの記事にはメリットがあります。私は何年もプログラマーであるので、私は別のデバッガーをインストールする必要があるという苦痛を経験しました。それは私に私の仕事を成し遂げる方法で創造的に考えることを余儀なくさせました。何年にもわたってセキュリティチームとの戦い(およびいくつかの議論)を経て、デスクトップを含むすべての領域をセキュリティで保護する必要があるという彼らの仕事を理解しています。最も単純なQuicktimeアプリであっても、毎日発生する脆弱性を示してくれました。クイックユーティリティをインストールしたり、ローカルIISを微調整したりするときに、深刻なセキュリティ問題を引き起こす可能性があるたびに、彼らの不満を感じることができます。別の開発者が缶詰になるのを見るまで、私はこれを完全に理解しませんでした。彼はデバッグを試みていて、何百人もの人にウイルスを(そしてそれから)与えるためにSymantecをシャットダウンすることになりました。めちゃくちゃでした。何が起こったのかを「セキュリティ責任者」(セキュリティ担当者)の一人に話していると、彼が「そう言った...」とだけ言いたがっていたことがわかりました。

私たちのセキュリティヘッド(まあ、少なくとも私のもの)は会社を保護したいだけなのです。良いニュースは、妥協点を見つけたということです。私は自分の仕事を成し遂げることができ、secheadは安全なネットワークでクールです!

信条


1

はい。侵入者や一部の熟練した悪意のあるユーザーにドメインの侵害の足がかりを与えたい場合は、そうです。

つまり、低レベルのアカウントの侵害>管理者の検索-> Mimikatz->権限の昇格->ドメイン管理者。

したがって、通常のユーザーは管理者であってはなりません。

また、マイクロソフトはUACはセキュリティの境界ではないと述べているため、UACをそのように使用しないでください。利用可能なUACのさまざまな現実世界のバイパスがあります。

職務の一環として管理者が必要な場合は、一般的な使用やインターネットアクセスではなく、ソフトウェアのインストールにのみ使用する個別のドメインローカル管理者ユーザーアカウントを付与します(自分のマシンに対する管理者権限のみ)。これには、より厳しいパスワードポリシーが必要です(たとえば、15文字以上の長さ)。これにはRunas機能を使用する必要があります。

通常のユーザーアカウントが管理者である環境は、セキュリティ障害の原因になります。


0

うわー、この質問は確かにいくつかの興味深い答えを開くでしょう。返信で私はよく使われているものを引用します-'It Depends' :)

中小企業では、これは単に実用的であることの問題にすぎないかもしれません。また、開発者は技術的に最も熟練している可能性が高いため、自分のマシンを管理することは理にかなっています。

個人的に、私は必要なときに使用できる「管理者アカウント」のファンです。つまり、「Run As ..」です(このアプローチは、原則として、UACと基本的には非常に似ていることに気づきました)。

デスクトップソフトウェアを開発している場合、開発者がエンドユーザーが経験する制限、つまり制限付きまたは制限付きの権利の範囲内で作業することは悪い考えではありません。制限付きの権利の下でソフトウェアをビルドする場合、同じアクセス許可のセットを与えられた場合にターゲットユーザーが直面するのと同じ問題に遭遇する可能性が高いです。

そうは言っても、優れたテストラボや適切なQAチームがある場合は、特にALMの練習が半分以上ある場合は、これは問題になるかもしれません。

最後に、主に自分と自分のスキルを信頼しているため、UACなしで開発しました。チーム環境では、私はそれを投票にかけます。大規模な組織では、このような自由がない場合があります。エンタープライズ管理者は、最終的な発言権を持っていることがよくあります:)


0

私の会社では、開発者、エンジニア、および上司(会社の所有者)がローカル管理者特権を持っています。私の上司には、迷惑なバスに見舞われた(または辞めた)場合に備えて、ネットワーク管理者特権もあります。他のすべての人がロックされます。

sysadminとして、このセットアップにより、特に承認されていないソフトウェアがインストールされた場合に、時々少し悲しみを感じました。しかし、開発者のバックグラウンドから来て、私はパワーユーザーが環境をより詳細に制御する必要性を理解しているため、表面化する可能性のある時折の癖や問題に我慢します。私は彼らのワークステーションの定期的なバックアップを実行します-念のために。

ちなみに、私はボスが他の誰よりも物事をいじくり回すことに多くの問題を抱えてきました。「象はどこに座っているの?どこにでも好きな場所に!」という古い質問のようなものです。しかし、彼が本質的に「バックアップ」システム管理者である小さな会社では、あまり選択肢がありません。


-1

それは、開発者のスキルと、コンサルタントかどうかによって異なります。

私は、経験豊富で信頼できる開発者が、自分の生産性を損なわない限り、自分のPCでやりたいことを何でもする権利を持っていることは理にかなっていると思います。


6
なぜ正社員ではなくコンサルタントの手を縛るのですか?彼らは両方とも同じ仕事をしていませんか?あなたは彼らのためにより多くを支払う可能性があるとしても、あなたはコンサルタントからより少ないことを期待していますか?これは本当にばかげているようです。さらに、開発者が自分のマシンを実行し続けることができない場合、新しいジョブが必要になります
NotMe

-1

Windows XPでは誰もが日常的に管理者アカウントを使用するべきではありません。管理者である必要がある場合はVistaで少なくともUACを有効にする必要があります。特にWeb開発者、およびInternet ExplorerでWebを閲覧する他の開発者。

あなたができることは、開発者に通常のユーザーアカウントを使用させることですが、必要に応じて使用できるように、PCの管理者である2番目のアカウントを与えます(実行)。私は彼らがウェブ開発を言ったことを知っていますが、Windows開発の場合、ソフトウェアは管理者としてではなく、通常のユーザーアカウントを使用してテストする必要があります。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.