開発者はPCの管理者権限を持っている必要がありますか、それともパワーユーザーに十分なアクセス権を与えているのですか?
いくつかのコメント:
- インストールが必要な新しいアプリケーションを試したい場合は、仮想マシンで試し、後でネットワーク管理者にインストールしてもらうことができます。それでうまくいくと思いますか?
- 管理者権限を必要とする開発者がPCで行う必要があることはありますか?
私たちは5人の開発者のチームであり、Webアプリケーションを構築しています
開発者はPCの管理者権限を持っている必要がありますか、それともパワーユーザーに十分なアクセス権を与えているのですか?
いくつかのコメント:
私たちは5人の開発者のチームであり、Webアプリケーションを構築しています
回答:
答えは「はい」です。開発者は、アイテムをテストし、ソフトウェアをインストールし(開発しているもののインストールプロセスをテストするため)、レジストリについて調べ、管理者権限なしでは適切に機能しないソフトウェアを実行するために、システム構成を操作する必要があります(いくつかの項目をリストします)。管理作業を行うために必要な、開発作業に不可欠な他の多くのタスクがあります。
開発スタッフが必ずしも本番システムへのrootアクセス権を持っているわけではないことを念頭に置いて、ローカルPCの管理者権限は本番システムのセキュリティを大幅に損なうことはありません。ローカルPCへの管理アクセスを、それを必要とするスタッフがローカルPCに制限する正当な運用上の理由はほとんどありません。
ただし、管理アクセスを提供する最も重要な理由は、侵害された、または二流の開発環境をセットアップすると、開発スタッフにメッセージが送信されることです。
「私たちはあなたの仕事をほんの少しだけ評価します。私たちは正当な理由なしにあなたの仕事をするあなたの能力を著しく妥協する用意があるからです。実際、私たちはこれを私たち自身の呪いをカバーするために行うこと、非常に官僚主義の気まぐれに足を踏み入れること、または私たちが単に気になることができないので、非常に満足しています。それはまさに最良のケースです。最悪のケースは、私たちが実際にコントロールフリークの一種であり、それを私たちの仕事のやり方や、何をすべきか、何をする必要がないかを伝えるための私たちの有力者だと見なしている場合です。与えられたものをやり直し、仕事を得たことに感謝しなさい。」
一般に、開発スタッフに二流(基本的に欠陥のあるものはもちろん)の作業環境を提供することは、有能な人材を維持できない、スタッフの離職率が高い、士気が低い、質の低い出産など、スタッフを怒らせるという自然な結果のレシピです。特に官僚的な気まぐれにうろついているような倍音がある場合、そうするためにあなたの道を外れることは無責任です。
スタッフの離職率は、スタッフの入れ替えにかかるコストだけではないことに注意してください。スタッフの離職の最も深刻なコストは、残っているもののほとんどが、より良い仕事を得ることができない枯れ木であることです。時間が経つと、影響を受ける部門の機能が低下します。業界が十分に近い場合は、評判を得ることもできます。
注意すべき1つの点は、管理特権は、Windowsの場合よりも、unix-oidまたはメインフレームシステムでの開発の問題のはるかに少ないことです。これらのプラットフォームでは、ユーザーはシステム全体の権限を必要とせずに、自分のドメインではるかに多くのことができます。あなたはおそらくまだ開発者にrootまたはsudoアクセスを必要とするでしょうが、これがないと足りなくなることはそれほど多くありません。この柔軟性は重要ですが、コンピュータサイエンスの学校でUNIX派生のオペレーティングシステムが引き続き人気を博している理由としてはあまり知られていません。
開発者は、使用しているマシンを完全かつ完全に制御する必要があります。ほとんどのデバッグツールは、ビルドしているアプリケーションのランタイムにフックするために管理者権限を必要とします。
さらに、開発者は頻繁に新しいものをダウンロードして試します。ネットワーク管理者が来て何かをインストールする必要があるなどの追加の手順を追加すると、開発者が不満を抱き、ネットワーク運用担当者にとってすぐに地獄になります。
とはいえ、彼らはネットワークではなく、そのボックスの管理者である必要があります。
はいといいえ。
はい、システムのサポートに煩わされる時間を大幅に節約できます。
いいえ、ユーザーは持っていないので、頼りにしないでください。
私たちは管理者権限で開発し、なしでテストします。これは正しく機能します。
上記のすべての理由により、ローカル管理者はい。「できる」という理由でネットワーク管理タスクに必然的に引き込まれるため、ネットワーク管理者はいいえ。開発者は開発している必要があります。ネットワーク管理は、まったく別の仕事です。
開発者は通常、平均的な人がしないことを行う必要があるため、通常は管理者アカウントを持っている必要があります。ぎこちないフープを乗り越えさせると、時間を浪費し、意気消沈します。セキュリティの高い状況では例外が発生する可能性がありますが、管理者アカウントで誰かを信頼できない場合は、その人のコードを信頼できないはずです。
また、ユーザーと同じ権限の利用可能なアカウントが必要です(ユーザーのプールに異なる権限ステータスがある場合は複数のアカウント)。そうでなければ、彼らは単に何かクールなものを開発し、それを配備して、それがユーザーにとって機能しないことに気付くかもしれません。
また、管理者アカウントでコンピューターを台無しにする方法が多すぎます(そうです、私はやった)。IT部門は、開発者のコンピューターを迅速に修正できない場合、コンピューターのイメージを再作成するというポリシーを必要としています。契約したある場所で、自分の管理者アカウントを取得するためにそのポリシーのコピーに署名する必要がありました。
これはかなりWindows固有の答えです。Linuxやその他のUnix-yシステムでは、開発者はユーザーアカウントだけで問題を解決できることが多く、テスト用に別のアカウントを必要としないことがよくあります(sudoを実行できるアカウントがあれば、いつ使用しているかがわかります。 sudo、ただし同じグループ権限を持つものが必要な場合があります)、OSに非常に大きな損害を与える可能性があるため、同じITポリシーが必要です。
絶対に!夜間に映画をダウンロードするために、ダウンロードマネージャーを他にどのようにインストールしますか?
時々、開発者はいくつかのアイデアをテストするためにシステムに何かをインストールしたり何かを変更したりする必要があります。何かを変更する必要があるたびに管理者に連絡する必要がある場合は不可能です。
また、管理者の中には、日常的に少しでも物事に依存するために可能なすべてのことをやり直す傾向があるという個人的な見解もあります。つまり、仕事を確保するために何が必要でしょうか。他のユーザーを怒らせる?答えはありません。しかし、常識はここでは見られません。
前回私のPCに問題があったとき、私はシステムの復元に積極的に参加し、管理者とチームで作業するいくつかの提案をしました、または私は考えました...管理者は非常に怒り、教えようとしたと非難しました彼またはルールを再定義します。他の同僚の間で私たちの部屋でそれほどクールではなかったので、彼のエゴだけだったと思います。
答えは、開発者は2台のマシンを持っている必要があるということです。
管理者権限と十分なパワー、メモリ、画面サイズ、移植性、およびADMIN権限を備えた開発の1つ。企業のウイルス対策ソフトウェアがロードされていますが、自動リセットポリシーで必要な場合は開発者が設定できます。
企業の負荷、ポリシー、管理者以外のユーザー権限などを備えた1つの企業。開発者の中には、管理者権限ですべてのユニットテストを行うという嫌な癖があるため、リリースモードアプリケーションのユニットテストにこれを使用できます。
はい。ただし、より制限された環境でソフトウェアを実行するときにユーザーが直面する制限に注意する必要があります。開発者は、リソースと権限が制限された「一般的な」環境に簡単にアクセスできる必要があります。過去に私はビルドプロセスの一部としてこれらの「典型的な」システムの1つ(多くの場合、自分のワークステーション上のVM)にビルドをデプロイすることを組み込んだので、ソフトウェアが最終的にどのように機能するかを常にすばやく感じることができました。ユーザーのマシン。
プログラマーには、管理者以外のユーザー向けのソフトウェアを作成する際の厳格な規則を知る責任もあります。常にアクセスを許可(または禁止)されているシステムリソースを正確に把握している必要があります。これらのリソースを取得するために使用されるAPIを知っている必要があります。
「私のマシンで動作する」という言い訳は決してありません!
システム管理者として、私は自分のワークステーションでローカル管理者権限を持つ開発者全員です。可能な場合は、ほとんどのことを標準の「ユーザー」レベルのアカウントで行い、別の「管理者」アカウントを使用して変更を加えたり、アプリをインストールしたりすることは悪い考えではありません。でる。また、本番環境にリリースするときにエンドユーザーがジャンプしなければならないセキュリティの問題を思い出させることも役立ちます。
余談ですが、[クリーン]システムまたはVMを用意することもお勧めします。これにより、システムを微調整することにより、適切にテストし、「システムで問題なく動作する」シナリオに陥らないようにすることができます。
まず第一に、パワーユーザーは基本的には管理者です。つまり、ユーザーをパワーユーザーに「制限」しても、システムのセキュリティは向上しません。あなたも管理者である可能性があります。
第2に、当然、開発者は開発者のマシン(およびサーバーと第2のボックスなど)への管理アクセスを必要としますが、通常の開発またはテスト中に管理者として対話的にログオンすることはできません。このアプリケーションとほとんどのアプリケーションには、通常のユーザーアカウントを使用してください。
管理者として本気で[ブラウザ、プラグイン、IM、電子メールクライアントなどを挿入]を実行したくない。
必要なときにrootアクセス権を持っている場合でも、通常はLinuxボックスにrootとしてログオンしません。
開発者に自分のマシンへの個別の個人管理者アカウント(できればドメインアカウント)を提供します。個人管理者アカウントは、他の開発/テストサーバーおよび管理者アクセスが必要なボックスの有効な管理者でもあります。
「別のユーザーとして実行」およびVista + UACを使用してプロンプトまたはプロンプトを要求し、必要な場合にのみタスクとプロセスの管理資格情報を入力します。スマートカードなどのPKIを使用すると、資格情報を頻繁に入力する負担を大幅に軽減できます。
次に、アクセスを監査します。このように、追跡可能性があり、特定の開発/テストサーバーでターミナルサービスセッションを使用しているユーザーを簡単に見つける方法が用意されています...
確かに、ローカル管理者権限を決して必要としない開発作業は確かにあります。ほとんどのWeb開発のように、展開は別のサーバーまたは仮想マシンに対してテストされ、ローカルデバッグに使用されるcassiniなどは通常のユーザーとして実際に実行されます。
私は主に* nixの世界で働いており、標準モデルでは、開発者が(sudo
またはを介してsu
)通常の非特権ユーザーアカウントで作業し、必要に応じて管理者特権にエスカレーションできます。
対応するWindowsの配置がどうなるかはわかりませんが、これは私の経験では理想的なセットアップです。
一方では、オンデマンドで管理者権限を使用できるようにすることで、開発者は必要に応じてワークステーションをフルに活用できます。
一方、Windowsソフトウェアには、すべてのユーザーが管理者権限を持っていると想定してきた長い歴史があり、管理者以外のユーザーに対しては多くのプログラムが実行されません。Windowsのセキュリティ問題の多くは、コンピューターを確実に使用できるようにするには、すべてのユーザーが管理者である必要があるという暗黙の要件に直接起因しています。 これは変更する必要があり、管理者以外のユーザーに対してソフトウェアを確実に実行する最も効果的な方法は、開発者が管理者以外のユーザーとしてソフトウェアを実行することです。
[英語は私の母国語ではありません。最善を尽くします:)]
個人的な経験(私はc ++ / SQL開発者です):
私は以前の仕事で私のWindowsマシンの管理者でした。また、実稼働環境データベースを含むデータベースに対するdbo(dbaではなく)権限も持っていました。2年半で、8人の人々がこれらのクレイジーな高い権利を手に入れました... 実際、dbを手動で更新することで、多くの問題を解決しました。ホットフィックスと開発者のために、多くのことを本当に迅速に行うことができました。
今、転職しました。私は自分のWindowsマシンの管理者になりました(たくさん泣きました)。ただし、devサーバーは、sshを使用して接続するRed Hatサーバーです。Qtをインストールしようとするのは、拷問、割り当て制限、スペース制限、実行権、書き込み権でした。ようやくあきらめて、管理者に代行してくれるように頼みました。2週間後、まだ何もインストールされていません。私は新聞を読むこととalt + tabヒットで本当に速くなっています。
私のソフトの開発者だけがこのマシンを使用するため、私は管理者権限を求めました。
->回答:「プロセスがある場合は、あなたがやりたいことを何もしないようにしてください。製品で一度正常に実行する必要があります」。
->テクニカルマネージャー以外に説明しようとしています。「本番環境またはUAT環境では、管理者権限は一切ありません。ただし、私の開発マシンは異なります。ソフトウェアの代わりに椅子を構築する場合、私ができることを教えてください。私のワークショップは椅子が使用される場所のように見える必要があるため、ワークショップに必要なツールは何も入れません。実行可能なパッケージをuatに渡します。それらを構築するために使用したライブラリとツールは、エンドユーザーやパッケージをインストールする人。」
今日も待っています。私は解決策を見つけ、開発環境を開き、お気に入りのオンライン裁判官に行き、自分自身に挑戦しました。誰かがあなたの画面を見ると、彼はあなたにプログラミングを仕掛けます。;)
これには2つの方法で答えることができます。はい、いいえ、またはそれは依存します。-私はもっと曖昧にできますか?...
彼らが自分の仕事をすることが必要かどうかによって異なります。その場合は、コンピュータに対する管理権限を付与します。そうでない場合はしません。すべてのソフトウェア開発が管理者権限を持つエンジニアを必要とするわけではありません。
はいといいえはあなたの意見に依存します。一部のエンジニアは自分のコンピューターをドメインと見なしており、それらはドメインの規則です。他の人は責任を望んでいません。
私は管理者権限のない会社で働いていました。管理者権限を必要とする何かをする必要があるときはいつでも、ヘルプデスクに連絡しなければならず、再起動するまで一時的な管理者権限を与えられました。これは時々苦痛でしたが、それがそうだったので私はそれと一緒に暮らしました。私は自分のコンピューターに対する完全な管理者権限を持つ場所でも働いています。これは、OSを起動するソフトウェアをインストールし、コンピューターをヘルプデスクに連れて行ってハードドライブのイメージを再作成させる必要があったときを除いて、すばらしいものでした。
私は個人的に、エンジニアは自分のコンピューターの管理者権限を持っている必要があると感じていますが、それを台無しにすると、新しいベースラインイメージがリロードされ、元のベースライン以降に行われたすべてが失われることを理解しています。ただし、会社の全員が自分のコンピューターの管理者権限を持っている必要があるとは思いません。経理、管理アシスタント、およびその他の部門は、実際にはそれらの権利を持っている必要はないので、付与されるべきではありません。
ht tp://msdn.microsoft.com/en-us/library/aa302367.aspx
私の経験では、私たち(コーダー)と彼ら(セキュリティ)の間の妥協が常に必要です。認めます(嫌いですが)、上記のMicrosoftの記事にはメリットがあります。私は何年もプログラマーであるので、私は別のデバッガーをインストールする必要があるという苦痛を経験しました。それは私に私の仕事を成し遂げる方法で創造的に考えることを余儀なくさせました。何年にもわたってセキュリティチームとの戦い(およびいくつかの議論)を経て、デスクトップを含むすべての領域をセキュリティで保護する必要があるという彼らの仕事を理解しています。最も単純なQuicktimeアプリであっても、毎日発生する脆弱性を示してくれました。クイックユーティリティをインストールしたり、ローカルIISを微調整したりするときに、深刻なセキュリティ問題を引き起こす可能性があるたびに、彼らの不満を感じることができます。別の開発者が缶詰になるのを見るまで、私はこれを完全に理解しませんでした。彼はデバッグを試みていて、何百人もの人にウイルスを(そしてそれから)与えるためにSymantecをシャットダウンすることになりました。めちゃくちゃでした。何が起こったのかを「セキュリティ責任者」(セキュリティ担当者)の一人に話していると、彼が「そう言った...」とだけ言いたがっていたことがわかりました。
私たちのセキュリティヘッド(まあ、少なくとも私のもの)は会社を保護したいだけなのです。良いニュースは、妥協点を見つけたということです。私は自分の仕事を成し遂げることができ、secheadは安全なネットワークでクールです!
信条
はい。侵入者や一部の熟練した悪意のあるユーザーにドメインの侵害の足がかりを与えたい場合は、そうです。
つまり、低レベルのアカウントの侵害>管理者の検索-> Mimikatz->権限の昇格->ドメイン管理者。
したがって、通常のユーザーは管理者であってはなりません。
また、マイクロソフトはUACはセキュリティの境界ではないと述べているため、UACをそのように使用しないでください。利用可能なUACのさまざまな現実世界のバイパスがあります。
職務の一環として管理者が必要な場合は、一般的な使用やインターネットアクセスではなく、ソフトウェアのインストールにのみ使用する個別のドメインローカル管理者ユーザーアカウントを付与します(自分のマシンに対する管理者権限のみ)。これには、より厳しいパスワードポリシーが必要です(たとえば、15文字以上の長さ)。これにはRunas機能を使用する必要があります。
通常のユーザーアカウントが管理者である環境は、セキュリティ障害の原因になります。
うわー、この質問は確かにいくつかの興味深い答えを開くでしょう。返信で私はよく使われているものを引用します-'It Depends' :)
中小企業では、これは単に実用的であることの問題にすぎないかもしれません。また、開発者は技術的に最も熟練している可能性が高いため、自分のマシンを管理することは理にかなっています。
個人的に、私は必要なときに使用できる「管理者アカウント」のファンです。つまり、「Run As ..」です(このアプローチは、原則として、UACと基本的には非常に似ていることに気づきました)。
デスクトップソフトウェアを開発している場合、開発者がエンドユーザーが経験する制限、つまり制限付きまたは制限付きの権利の範囲内で作業することは悪い考えではありません。制限付きの権利の下でソフトウェアをビルドする場合、同じアクセス許可のセットを与えられた場合にターゲットユーザーが直面するのと同じ問題に遭遇する可能性が高いです。
そうは言っても、優れたテストラボや適切なQAチームがある場合は、特にALMの練習が半分以上ある場合は、これは問題になるかもしれません。
最後に、主に自分と自分のスキルを信頼しているため、UACなしで開発しました。チーム環境では、私はそれを投票にかけます。大規模な組織では、このような自由がない場合があります。エンタープライズ管理者は、最終的な発言権を持っていることがよくあります:)
私の会社では、開発者、エンジニア、および上司(会社の所有者)がローカル管理者特権を持っています。私の上司には、迷惑なバスに見舞われた(または辞めた)場合に備えて、ネットワーク管理者特権もあります。他のすべての人がロックされます。
sysadminとして、このセットアップにより、特に承認されていないソフトウェアがインストールされた場合に、時々少し悲しみを感じました。しかし、開発者のバックグラウンドから来て、私はパワーユーザーが環境をより詳細に制御する必要性を理解しているため、表面化する可能性のある時折の癖や問題に我慢します。私は彼らのワークステーションの定期的なバックアップを実行します-念のために。
ちなみに、私はボスが他の誰よりも物事をいじくり回すことに多くの問題を抱えてきました。「象はどこに座っているの?どこにでも好きな場所に!」という古い質問のようなものです。しかし、彼が本質的に「バックアップ」システム管理者である小さな会社では、あまり選択肢がありません。
それは、開発者のスキルと、コンサルタントかどうかによって異なります。
私は、経験豊富で信頼できる開発者が、自分の生産性を損なわない限り、自分のPCでやりたいことを何でもする権利を持っていることは理にかなっていると思います。
Windows XPでは誰もが日常的に管理者アカウントを使用するべきではありません。管理者である必要がある場合はVistaで少なくともUACを有効にする必要があります。特にWeb開発者、およびInternet ExplorerでWebを閲覧する他の開発者。
あなたができることは、開発者に通常のユーザーアカウントを使用させることですが、必要に応じて使用できるように、PCの管理者である2番目のアカウントを与えます(実行)。私は彼らがウェブ開発を言ったことを知っていますが、Windows開発の場合、ソフトウェアは管理者としてではなく、通常のユーザーアカウントを使用してテストする必要があります。