組織の開発者にローカル管理者アクセスを許可することは一般的ですか?

私は約1000人以上のスタッフを抱える会社で働いています。私たちは現在、Webベースのプロジェクト(約50人)に取り組むプログラミング開発スタッフを擁しています。

最近、セキュリティ上の懸念から、ITおよびセキュリティ部門では、ローカル管理者によるコンピュータへのアクセスを許可しない制限を設けました。会社全体では、ワークステーションとサーバーの両方にWindows OSを実行しています。私は、アドミンを削除するという決定に完全に同意しました。正直に言うと、(会社は患者データを扱い、HIPAAコンプライアンスを必要としているので)遅すぎると思いました。残念ながら、私は彼らが決断を下しすぎたと思います。サブグループまたはADグループは、自分の仕事をするために合法的に管理者アクセスを必要としていたユーザーのために作成されるものとしました(私のプログラミングチームより)管理者アクセスを保持するTechグループのようなもの。ただし、そうではありませんでした。唯一のグループが、ネットワークおよびヘルプデスクのスタッフ用に特定の管理者グループを作成しました。

主な問題は、Web開発者として、ローカル管理者アクセスを必要とするプログラムを実行していて、残念ながらそれらが管理者として実行されていないと私たちの仕事ができないことです。サンプルプログラムには、ASP.NET Web開発用のVisual Studio、ローカル開発用のMAMP、作曲家などが含まれます。これらのプログラムに管理者アクセスが必要な主な理由は、ローカルIISの実行と変更、コマンドラインなどが必要だからです。

基本的には、ローカル管理者アクセス権が削除された時期についての短い通知がありました。開発チームが仕事をできるようになるために水で死んでから約2日後、私と他のチームリーダーは基本的にITスタッフに叫んで叫んで解決策を思いついた。ローカルの管理者アクセスがなくても、管理者が特定のプログラムを管理者として実行する機能を作成できるようにするためのパススルーとして機能します。

残念ながら、私たちがローカル管理者アクセスに使用するこのプログラムは信じられないほどバグが多く信頼性が低く、信頼できるソースからのものではないため、他に代わるものはあまりないようです。 (私たちが使っているプログラムは公開したくない)

私の質問は、プログラマー/開発者に企業や企業でのローカル管理者アクセスを許可しないのが一般的なことですか?それがそうするのが一般的なやり方であるならば、開発者はローカル管理者として彼らが必要とするプログラムをどのように実行しますか?

私たちのネットワーク環境についてのもう少しの情報(それは私がこれを追加したいと思った質問に実際に関連しているというわけではない)

  1. 承認済みリストにないプログラムをブロックするには、AppBlockerを使用します。
  2. 添付ファイルをスキャンしてPDFに変換するなどの処理を行う電子メールセキュリティブロッカーを使用しています。
  3. すべてのワークステーションに少なくとも2つの主要なウイルス対策プログラムがあります。
  4. ネットワークとそのサーバーは非常に隔離されており、ユーザーは特定のサーバー、フォルダー、およびデータベースにしかアクセスできない。合法的にアクセスする必要がある。
113
私の職場では、常に管理者権限を持っていました。ある会社は私たちからこれを取り除こうとしましたが、開発者が欲求不満になるだけでなく、単に働くのをやめたことを理解した後にそれをかなり速く止めました。彼らがしたくなかったからではなく、彼らはもう働けなくなったからです。だから少なくとも私の個人的な経験から(ドイツ語で)、開発者のために管理者アクセス権を持つことはかなり一般的です。 (私はSOMEの開発者達から、彼らが強力なセキュリティ環境の妥協としてVMを(管理者権限で)使用しなければならないことを知っています
追加された 著者 Majin Magu,
私は防衛産業の契約プログラマーです。私が働いている会社はすべて、セキュリティ上の理由から実行されたアクションを記録しながら、一時管理者権限を与えるプログラムを持っています。あなたの質問に答えるには:「それは一般的ですか?」 - はい、しかしそれは本当に明確に定義されたセキュリティ問題です(違反は意図されていません)
追加された 著者 JW.,
ローカル管理者として実行しているソフトウェア開発者にとっての1つの欠点は、あなたがそのような権利を持っていない場合にのみ起こるエンドユーザー問題に遭遇することは決してないということです。私は個人的にこれが何度も起こるのを見ました。
追加された 著者 Benjamin Podszun,
ユーザ/グループにhttp:// +:80 /へのアクセスを許可するようにWAASエンドポイントを設定してみましたか。 "netsh http add urlacl"のGoogle ...
追加された 著者 Haakon,
逸話:私は、このようにして本物の有能なセキュリティを持っていた従業員のやり方を封じ込める会社で働いたことは一度もない。私がそのために働いていた会社はどれも基本的に失敗しましたが、従業員のための仕事を非常に困難にしました。私は二度とそのような会社で働くことは決してないだろうとも言います。官僚的な時間の無駄に対処するよりも、実際には意味のある仕事をしたいと思います。
追加された 著者 idrosid,
@atdre有能なエンジニアを雇います。その上、物事が正しく設定されているならば、あなたがただ不平を言ったことのどれも本当の危険性がありません。
追加された 著者 idrosid,
注意してください、アカウントが管理者でない場合、いくつかの開発ツールは動作しません。これは、ソフトウェアツールが古くなるほど、より当てはまる傾向があります。
追加された 著者 alexis.kennedy,
あなたがappdevに彼らのマシンをladminさせるなら、彼らは不正確なFTP、RSH、Webmin、ジェンキンス、Tomcat、ColdFusion、JBoss/WildFly、Splunkd、ElasticSearchなどをインストールするでしょう - そしてそれらは決してアップグレードしないでしょう。 SimpleHTTPServer、SMB、AFP、NFSのいずれか、あるいはその両方をネットワーク経由でローカルファイルシステムへの読み書きアクセスを許可するように設定し、それらの共有フォルダにシェルスクリプトと重要な情報を残す。それらはデータベースやネットワークソケットにバインドできるものなら何でも同じことをするでしょう。
追加された 著者 Rufo Sanchez,
@ブラッド:過去300人ほどの従業員、これは不可能です。サイバーセキュリティの専門家でさえ、ジェネリックフィッシングやスピアフィッシングの犠牲になるという強力な証拠があります。あなたが財政的に動機付けられた俳優、または国民国家を1人の人物に対してピットするとき - それは通常洞窟を掘る人です。いや、それはいつもです。 Windows Server Forest環境でアクセスが拡大するリスクを減らすための適切な "セットアップ"はありません。マイクロソフトでも販売していません。
追加された 著者 Rufo Sanchez,
Idk、あなたは素晴らしいアイデアを持っています、しかし私はそれらがうまく実行されるのを見たことがありません。とにかくJitJeaを実装するのが最善だと思います。特にワークステーションへのローカル管理者や大規模なネットワークへのドメイン管理者/グループではありません。
追加された 著者 Rufo Sanchez,
開発者は解決策ではなく問題として開発者を見ているので(明らかにあなたの上司は聞かれなかったり無視されたりしていなかった)他の場所でより開発者に優しい環境を探すことを私は提案する。そして私たちはStackexchangeに参加しているので、私たちの素晴らしい創設者は強い意見
追加された 著者 Kromster,
私はあなたが本当に「典型的」かどうかを尋ねたいとは思わない。それどころか、それは正当化できるものであり、コスト/利益は何ですか?私の経験では、大規模な組織がこれを試すのはやや一般的です。コストはかなり高く、開発者にとっては生産性に大きな影響を与えますが、「セキュリティ担当者」はSEP分野に囲まれているため、通常は気にしません(Else's Problem)。あなたがこれを取り除きたいのであれば、これは典型的なものではなく、むしろそれがEXPENSIVEであることを見つけようとして勝つことはまずないでしょう。企業は高価ではない。
追加された 著者 Steve Sether,
@Jacco私はもっと同意できなかった。私はこれを行った組織のために働いていました、そしてそれはまさにあなたが話しているその摩擦を生み出しました。 Big Evil Corpがこれを実装しようとしたとき、私の最初の考えはフェンスを飛び越えることに集中しました。中途半端な熟練開発者なら誰でも、手間をかけずにこの種のフェンスを飛び越えるための半ダースの方法を思いつくことができます。
追加された 著者 Steve Sether,
1つのシステム上に2つの別々のアンチウイルスプログラムを持つことは、ほぼ確実に良いよりも害を及ぼすでしょう。 AVソフトウェア自体の脆弱性にさらされる危険性が2倍になると同時に、影響を受けるコンピュータの速度を大幅に低下させる一方で、検出されることはごくわずかです。
追加された 著者 Valerie Anderson,
@Jacco自社のマシンで開発者を信用しないことと、自社のサーバー上で実行するカスタムコードを開発し、機密性の高いエンドユーザー情報を処理することを信頼することの認識の不一致は言うまでもありません。彼らが保護なしで彼らのマシンからウイルスを守ることができないなら、私は彼らが私のアプリケーションを開発して欲しくないと思いません。
追加された 著者 jpmc26,
@Neilはい、あなたは、iisマネージャを開くためにも、あるいはiisワーカープロセスにデバッガをアタッチするためにも、ローカル管理者である必要があります。
追加された 著者 Obviously_Anon,
@Neilアプリケーションを別のコンピュータにデプロイしてワークステーションに接続する必要がある場合など、IIS Expressを使用できない場合を除きます。
追加された 著者 Obviously_Anon,
@Neilそれは統合の問題ではありません。あなたがアプリを実行している開発者が彼がコミットする前にそれをテストするためにローカルに取り組んでいると思わない限り、「統合」です。ローカル管理者を必要とする開発者がやらなければならないことが他にもたくさんありますが、ローカル管理者を持たないことは本番になるための重大な障害です。しないでください。
追加された 著者 Obviously_Anon,
ITと開発の間の摩擦を促進する企業ポリシーは危険なポリシーです。 IT部門のセキュリティへの取り組みを深刻に損なう可能性がある人々のグループが1つあれば、それは開発者になります。優れた企業方針は、ITと開発部門がその総合的な知識を組み合わせて全体的なセキュリティを強化することです。 ITに開発の障壁を強いることは、この結果には逆効果です。十分なインセンティブがあれば、人々は創造的な回避策を探し始めるでしょう。開発者による独創的な回避策は、セキュリティ全体にとって有害で​​す。
追加された 著者 Brythan,
@matwonk問題がどのように発生したかについてお知らせください
追加された 著者 Brythan,
同じ質問ではありませんが、非常に関連しています。私は反対側にいました(ITに関するもの、そしてITの人々はしばしばそのような狂ったポリシーに同意しません): security.stackexchange.com/questions/135359 /…
追加された 著者 grochmal,
いまいましい価値のある開発者なら誰でも物理的にアクセスできるマシン上でrootアクセスを得るでしょう:)
追加された 著者 Navin,
私が過去にこれに対処した方法は、年長のITセキュリティの人々の上にいるボス/ディレクターにかなり基本的なアピールをすることです。 「問題を抱えています。作業を完了できないことを意味しますが、解決策を特定し、それを実装するにはあなたの承認が必要なだけです」。おかしなことに、会社が常にお金を稼ぐことの必要性は、ITセキュリティの人々が彼らの厳格な措置を正当化するために発明している実存的な脅威を打ち負かしています。しかし、これを実行しながら常に快適に - あなたは長期的に、あなたの側にITセキュリティチームを望んでいます。
追加された 著者 user128064,
@atdreそれは完全に可能です、あなたはただ自分自身をより良く組織化する必要があります。私が巨大なソフトウェアショップで働いていたとき、すべてのプロジェクトはIT関連の問題では完全に分離された「仮想企業」でした。全員を常に同じネットワークに参加させる必要はありませんでした。それは不思議に働きました。仕事を犠牲にしたり、中央サーバーへのアクセスを設定しなくても、チームをどこにでも移動できるという利点もありました。
追加された 著者 T. Sar,
@atdreまた、インフラストラクチャを完全に分離することで、必要に応じて各チームでアップグレードやさまざまな設定を実行できます。 ITチームも「仮想企業」ごとに区画化されていたため、各専門家も常に気を配ることができませんでした。
追加された 著者 T. Sar,
デバッグに必要なことがあります。たとえば、ローカル管理者権限なしでVisual Studioを使用している場合は、別のユーザーの下で開始されたプロセスをデバッグすることはできません。しかし、会社は、特定のユーザーに対してワークステーションの一時的なローカル管理者権限を要求するようにプロセスを設定できます。
追加された 著者 Confutus,
注:Visual Studioで "管理者として"実行することを許可した場合、ユーザーは "管理者として"コードを実行できます。管理者権限を持つコードは、SeDebug権限を必要なセキュリティトークンに割り当てることができるため、開発者はマシンを完全に制御できます。
追加された 著者 Galaxy,
誤解を検討することさえできません。つまり、ウイルス対策製品を追加すると、システムのセキュリティが強化されます。
追加された 著者 Galaxy,
多くの企業では、開発者もシステム管理者を兼ねているため、当然特権を持つことになります。
追加された 著者 Charlotte Vandersleyen,
これは、実は私が就職の面接でよく尋ねる質問の1つです。答えが「いいえ」、開発者にはローカル管理者権限が許可されていない、そしてそれ以上先に進むことは丁寧に拒否します。
追加された 著者 user149010,
これはセクターによって大きく異なります。銀行、軍事、公益事業 - それらはすべて、他のほとんどのものよりはるかに制限的である可能性が高いです。ソフトウェア工学は、あなたがあらゆる産業に移行できるスキルですが、それ自体が必ずしも産業ではありません。
追加された 著者 user155848,
あなたは(本当に)ASP.NET/IISを使うために管理者アクセスが必要ですか?私は10年間それらのプロジェクトを開発してきました、そして管理者アクセスを必要としませんでした。私は(同じコードベースで)それを主張する開発者と仕事をしましたが、それは彼らが(ひどく)自分で書いた「ツール」を持っているからです。
追加された 著者 Dan Roberts,
@AndyまたはIIS Expressを使用してください。
追加された 著者 Dan Roberts,
あなたのP45を取得するためにあなたにHRへの短い旅行をするでしょういくつかの場所で@Navin。はい、そうです !
追加された 著者 Dan Roberts,
@Andyそれは開発というよりはむしろ統合問題のように思えます。開発作業の100%は管理者権限なしで実行できます。
追加された 著者 Dan Roberts,

19 答え

これは、セキュリティに関心があるソフトウェア会社からの1つのデータポイントです。私はこれが同様の組織で一般的であることを知っています。

たくさんのネットワークがあります。それらは物理的に分離され、空隙があり、色分けされたさまざまなネットワークケーブルを使用しています。

各従業員は電子メールなどを送信するために(プロキシ経由で)インターネットに接続できる「管理」マシンを持っています。

これに加えて、各開発者は「エンジニアリング」マシンを持っています。これには完全な管理者アクセス権があり、ユーザーは自分が好きなことをすべて実行できます。ただし、それはエンジニアリングネットワークにのみ接続されています(インターネットへの経路はありません)。

ほとんどのソフトウェア開発のコンテキストでは、これは極端と見なされる可能性がありますが、高いセキュリティと開発者の自由という矛盾する要件がある組織では、これは一般的な解決策です。

あなたの質問に答えるために、はい、開発者に管理者アクセスを許可するのが一般的ですが、これは常に情報セキュリティ問題を引き起こす可能性があるマシンへの管理者アクセスを意味するわけではありません。

110
追加された
@デデュプリケータはどうですか?あなたはUSBドライブを介して十分に簡単に物をコピーすることができます。迷惑メールをランダムにクリックしてすべてをインストールするのではなく、実際に必要なものについて考えることができます。管理者アクセス権がないため、ダウンロード内容をまとめて整理することができたので、インストール内容を選択することができます。
追加された 著者 plusplus,
安全でなくても@Flater、
追加された 著者 plusplus,
+1私が働いていたInfosec/A/Vベンダも同様にやったのです。彼らはネットワークのセグメンテーションをかなり真剣に受け止めました - それは開発マシンを製品/内部インフラストラクチャネットワークに差し込むことは終端不可能な攻撃でした、そして私はそうするために一人以上の開発者を任命しなければなりませんでした。それでも、それが問題への最も良い、開発者に優しいアプローチであると思います - 「ここにあなたのdevネットワーク上のあなたのdevラップトップがあります。 」
追加された 著者 Shawn,
国防総省の請負業者で働いているとき、私は幾分似たような設定で働かなければならなかったでしょう。その場合私のメインの開発マシンはメインのネットワーク、インターネットに接続され、そしてローカル管理者を持っていました。生産機械は施錠されたドアの向こう側から世界から空襲され、そして大規模に施錠された。私の開発/初期テストの大部分を実行できるようにすることで、通常、痛みが大幅に軽減されましたが、使用可能なアンクラスデータセットを作成することが不可能であり、すべてをハイサイドで行う必要がありました。それはインターネットに接続されたPCへの少なくとも20フィートの歩行であり、そしてdevにハードコピーxferだけだったのでそれは悲惨だった。
追加された 著者 Brendan Long,
@Nelsonそのアプローチは実際にはとても苦痛になります。今日では、開発をスピードアップするためにフレームワークを使用するのが一般的です。最近のフレームワークの多くは多くのライブラリに依存しており、それらをUSBデバイスに保存するために、使用しているフレームワークの正確な依存関係を特定するのは複雑でエラーが発生しやすくなります。あなたはまた、そのように重要なセキュリティツールへのアクセスを失います。最近のパッケージマネージャの中には、依存関係にセキュリティ警告があるかどうかを自動的に確認し、そうである場合はそれらをアップグレードすることができます。別のマシンでそれを実行する必要がある場合は、そのマシンが事実上の開発マシンになります。
追加された 著者 Valerie Anderson,
+1、当社の一部の開発チームは同じ方法を使用しています。開発用ネットワークにエアギャップはありませんが。 VLANを使用して処理します。
追加された 著者 Philipp,
@NickTのソースコードリークは、通常、二次的な問題です。または多くの組織では、まったく心配する必要はありません。それらのソフトウェアは非常に特殊化されているため、彼ら/クライアント以外には価値がありません。すべての人に影響を与える危険性は、意図的でないマルウェアの拡散です。完全な管理者権限で実行されており、IT部門によって検証されていないソフトウェアを使用してインターネットにアクセスするマシンは、マルウェアのようなものです。
追加された 著者 Philipp,
率直に言って、このポリシーが導入された瞬間に私は私の通知に手渡すつもりです。
追加された 著者 Abdul,
あなたの「エンジニアリングネットワーク」は本当に本番ネットワークですか。実際には、ドキュメントを読むためのボックスと、コーディングするためのボックスの2つのボックスが必要ですか。それが開発/テストネットワークであるならば、私はコードを入手する攻撃者の心配、潜入について混乱しますか?コードの説明(あなたの開発者は約5秒でそれを回避するでしょう)?本番ネットワークの場合は、おそらくエンジニアがアクセスできないようにすることができます(QA/opsがprodに展開されます)。
追加された 著者 The Lazy DBA,
私の職場では、USB(およびその他のリムーバブルメディア)は無効になっています(仕事用に限られた時間だけdevデバイスのホワイトリストが許可されます) Webを閲覧できる権限の低いユーザー。 2台のマシンは必要ありません。
追加された 著者 Landmaster,
うーん、インターネットに接続していない開発マシンはかなり厳しい制限のようです。
追加された 著者 Deduplicator,
このような展開を目にするほとんどの場所は、ユーザーマシンの概念をはるかに超えてアカウントの概念を十分に超えています。これらはすべて、共有ストレージを使用してVMまたはネットワーク全体の管理アカウンティングを運用します。あなたの管理PCはNASへのRWアクセスを簡単に持つことができ、あるいは部屋ごとに一つのクライアントを走らせることだけが許可されているVM VPN/SSHターゲットになることができます。これは通常、ITが任意のシステムからadminにアクセスでき、Devsがそれを介してインストールを実行できますが、最初にstdユーザーアカウントからログインしてAdminユーザーを識別する必要があるので理想的です。
追加された 著者 Jack,
オープンWebへのアクセスをブロックするのはもちろん狂気ですが、セキュリティを維持しながら管理環境に専念したいのであれば、サンドボックス化された管理アクセスを許可するためにIT側でスイートを仮想化する必要があります。これにより、管理作業を最大限に行うことができますが、VMの外部のアクセス制御に制限され、共有ストレージにウイルスが感染するのを防ぐことができます。
追加された 著者 Jack,
@Nelson、実際には、セキュリティを向上させるために、エンジニアリング環境のすべてのUSB使用ポートを無効にする必要があります。これらは本質的に安全ではありません。はるかに便利で安全なのは、外部アップデートの管理されたダウンロードを可能にするためのデータダイオードの使用でしょう。 ja.wikipedia.org/wiki/Unidirectional_network
追加された 著者 MathEW,
@ネルソン:USBメモリにコピーしたものが安全であることをどのように確認できますか。あなたは明らかに管理からエンジニアリングへのコピーを許可する必要がありますが。 を管理マシンにコピーすることを許可しますか。両方を許可すると、スティック上で交換されるデータは(2台のマシン間で)物理的なネットワークケーブル上で交換されるデータと同じくらい安全であるため、処理は遅くなります。
追加された 著者 user180510,
これは軽くする決断ではありません。開発にはかなりの影響があります。それが不可能であると言っているのではなく、結果のいくつかを指摘するだけです。 nuget/npmパッケージなどの技術的なもの(あなたはリアルタイムでパブリックフィードにアクセスすることはできず、すべてを手動でコピーする必要があるでしょう)だけでなく、もっと簡単な問題(開発者はもうStackOverflowからコピー/貼り付けることはできません)。ここで実際には、コードを吟味することが必要であることに同意したとしても(すべてのことを手動で入力しなければならないことは効率的な作業にはつながらないでしょう)。
追加された 著者 user180510,
従業員用に2台目のPC /ラップトップを購入しなければならないことは、人々の生産性を低下させるためのかなり高価な方法のようです。
追加された 著者 public wireless,

私の経験では、開発者が自分のマシンで管理者アクセス権を持つのは一般的です。自分のマシンで管理者アクセス権を持つことは、ありません 共通です。しかし、後者の状況では、多少の摩擦をせずに仕事を終わらせることができるように、一般的に配慮がなされています。

非常に一般的な宿泊施設の1つは、ワークステーション上のハイパーバイザー(Windowsに付属のVMWareまたはHyper-Vのいずれかのバージョン)へのアクセス、およびそのハイパーバイザー内のVMの作成と破棄に必要な特定の権限です。必要に応じてHyper-V / VMWare(作成も含む)ゲストOSに対する管理者権限があるVM。通常、これらのVMの一部は、稼働していなくても長寿命になります。管理者権限を必要とするもので簡単なテストを行うためだけにVM全体を準備する必要はありません。

ハイパーバイザーは、そのVMに対してインターネットアクセスを許可するように設定されている場合とされていない場合があります。個人的にはインターネットへのアクセス を許可することを強くお勧めしますが、少なくとも私が最も経験を積んだ開発の種類については、両方の方法で見ました。しかし、インターネットアクセスが許可されている場合は、他の企業ネットワークとは別に、少なくともVMを専用のVLANに強制するように設定することができます。これがHyper-VまたはVMWareを介して直接適用できるかどうかはわかりませんが、多くのネットワークスイッチのポートで802.1xを使用して、不正なVMを含む不正なマシンから特定のVLANへのアクセスを防ぐことができます。その後、VMにvlanタグを設定する方法について開発者向けの簡単なチュートリアルを行い、どのvlanタグをスイッチポートで使用できるようにするかを開発者に知らせます。私はまた、これが技術的な手段を介するのではなく、単に政策指針として実施されているのを見た。

そしてもちろん、これは一度に複数のVMを実行するのに十分強力なマシンを開発者に提供することと同時に起こります。

66
追加された
これは良い解決策 - とても良い解決策 - のように思えますが、それが実際にそのように機能するかどうかを知るのに十分なWindows admin-fooはありません(特定の特権や一般的な権限なしにVMを起動する権限) local admin privs) - IMOのこの答えは、いくつかのドキュメント/ホワイトペーパー/クックブックの項目へのリンクを使用するか、またはこれを確認するようなものにすると、はるかに改善される可能性があります。
追加された 著者 Grant Collins,
はい、素晴らしいリンクです。ベンアームストロングは行くべき男です!さらにVLANの詳細についても説明します。
追加された 著者 Grant Collins,
VMは開発者に他の利点も提供します。 1台の物理コンピュータで複数のVMをホストし、さまざまなOSバージョンまたはテスト対象ソフトウェアのバージョンを実行できます。それらは使い捨てであるので、選ばれたチェックポイントに戻ることによってテストを繰り返すことはより簡単です。
追加された 著者 Raedwald,
@ davidbak良いですか?
追加された 著者 Phonon,
@davidbak私は管理者権限を持たずに、ハイパーバイザー(VirtualBox)をインストールしたマシンで作業しました。
追加された 著者 Naoise Golden,

私はかなり大規模な投資運用会社(約6000人の従業員)で働いています。開発者は、ローカル管理者アクセスを承認しているグループの1つです。ローカルデスクトップ/ソフトウェアコンプライアンスによって処理されるので、ソフトウェアをインストールしないように彼らに言います。

また、ローカル管理者を必要とせずにメンバーが自分のマシン上で実行ポリシーを変更できるようにするDevelopers ADグループもあります。

44
追加された
@Steve - 残念ながらそれはあなたが何人かの極端な警備員から得られるのと同じくらい誤って極端な見方です。組織を内部からの脅威から守ることは妄想ではありません。実際、多くの人にとってそれは彼らの存在に対する最大の脅威です。
追加された 著者 Rory Alsop,
@ TomK。それは実際の質問に答えます、「なぜ私の組織は私の人生を非常に、非常に困難にしているように思われますが、それはどうしてよいのでしょうか。 OPは明らかにこの(かなり率直に言って奇妙で偏執的な)習慣を彼の世界観に当てはめようとしている。人々は、彼らの組織がどのようにして妄想的なセキュリティの人々と開発者の現実のニーズとのバランスをとってきたかを指摘しようとしています。
追加された 著者 Steve Sether,
これは質問に答えません。これが「典型的」なのかどうか、またその理由は説明しません。
追加された 著者 Sean,

私の経歴では、かなり小さな会社(100人以下)で、私たちは常に地方の管理者権限を持っていました。私たちは、ITによって管理されているが権利を得た本物のデスクトップマシンを持っているか、あるいは私たちが自分たちで完全に管理しているあらゆる種類の仮想マシンを持つことを許されました。

If we had not local admin access, we would try all sorts of bad "solutions" which, as in your case, leads to less security. This is one of those cases, that restrictions actually lead to the opposite of their intention.

27
追加された
@ TomK。何が典型的な調査ではないのかを知る方法はないので、質問のその部分に答えることは起こりそうもない。
追加された 著者 Obviously_Anon,
@ TomK。それらの調査または調査は、たとえ存在するとしても、がらくたでしょう。あなたが言ったように、それはただ「典型的」であるかもしれないもののコレクションであり、そして何かが典型的であるという理由だけでそれが正しい道を行くことを意味しない。
追加された 著者 Obviously_Anon,
これは質問に答えません。これが「典型的」なのかどうか、またその理由は説明しません。
追加された 著者 Sean,
@ PeterA.Schneider:正解です。通常、1人のユーザーが経験だけでこのような世界的な質問に正直に答えることはできません。しかし幸いなことに、「ベストプラクティス」と呼ばれるものが書き留められ、精査の対象となることがあります。他の可能性は研究か記事です。 「私にとって、これはこのようなものです」と言っているだけでは不十分です。
追加された 著者 Sean,
@アンディ正しい。これらの調査や研究は科学者によって、あるいはしばしば私が述べたようにベストプラクティスを開発するコンサルタントによって行われます。これらのベストプラクティスや研究を引用することは正当な答えとなります。
追加された 著者 Sean,
@ TomK。これは部分的に部分的に答えます。 10人中10人が "私はいつも管理者権限を持っています"と言ったら、それが一緒です。このような世界的な質問に正規的に答えることはできません。一つ一つの答えは、ある程度の逸話であり、ジョーが言ったように「データポイント」です。 (ジョーは、「私はこれが他の起源で一般的であることを知っている」と主張し、「私が知っているもの」を付け加えていない。)
追加された 著者 Bobas_Pett,

大規模な組織の中ではかなり小さい部署(部署内で最大100件、完全組織内で最大3500件)では、中規模ソリューションを選択しました。

  • sysadminsには2つのアカウントがありました。1つ(ローカルマシンでも非管理者)は管理目的以外のタスク(メール、ドキュメントの編集など)に使用され、もう1つはAD管理にのみ使用されると考えられる
  • 他のすべてのユーザーは管理者以外のアカウントを1つだけ所有していました。
  • 開発者(および一部のパワーユーザー)には、ローカルマシンの管理者権限を持つローカルアカウントが提供されていました。地方行政が必要とされるときにはめったに使われないと思われた。

管理者権限を開発者に拒否すると、生産性が低下する原因になります。そのため、組織にとっては即座にコストがかかります。ローカルアカウントの管理者特権をプライマリアカウントまたはセカンダリアカウントに付与するかどうかは、管理者の操作頻度によって異なります。

  • 1日に数回を超える場合は、プライマリアカウントを使用することをお勧めします。
  • 1週間に1回未満の場合は、予備のアカウントを使用します。

あなたが間にあるならあなた自身を選んでください...

27
追加された
考慮事項:ADアカウントのインターネットアクセス量。私の職場では、私のADは事実上インターネットにアクセスできません(Visual Studioのアップデートは除く)。私はinternet/download/etcに私の正規アカウントを使わなければなりません。
追加された 著者 julionc,
私達は今日これについて私達のITチームとミーティングをしました、そしてこれが彼らが私達のために思いついた解決策であるという理由だけで私はこの答えを回答済みとしてマークすることに傾いています。
追加された 著者 David,
うん、これもやった。私たちのADの管理者アカウントもすべてのマシン上でローカルの管理者権限を持っていましたが(ドメイン/広告の一部でした)
追加された 著者 Sami Liedes,

私の経験では、ローカル管理者アクセスを許可したり許可しなかったりするのが一般的です。 - だからあなたは自分自身に尋ねるべきです:

あなたのネットワークへのどの脅威がローカル管理者権限によって悪化させられますか?

NONE - ネットワーク上のリソースへのアクセスはユーザーごとに制限する必要があります。このユーザーにローカルのroot、admin、またはmasterOfTheUniverseのアクセス権がある場合は、まったく関係ありません機械。ユーザーがあなたのネットワークを爆破する権限を持っていれば、ローカルウイルスは管理者アクセスさえ必要としません、それはあなたのネットワークを爆破するためにユーザーアカウントを使うことができるだけです。 - そしてユーザーアカウントがあなたのネットワーク上の何かにアクセスできない場合でも、ローカル管理者権限はそれについて何も変更しません。

あなたは自分のマシンを責任を持って取り扱うよう開発者に信頼しなければなりません - そしてあなたの会社の賢明なセキュリティ設定ではローカル管理者権限はただ一つ危険なことです:ローカルマシン。そのため、ローカルの管理者に配布することで受け入れる唯一のリスクは、開発者が自分のマシンを壊したことです(彼はすでにコーヒー1杯でできる)。

Addendum: You should grant your developers the possibility to use local-admin rights whenever they need to. This doesn't mean they should be logged in with an unsecured admin-account all the time, but you should trust them to use it sensibly whenever they need it - without asking for permission every time.

開発者がローカルの管理者権限を持つべき理由

あなたの開発者は、あなたがあなたのビジネスの中核業務の設計を委託する人々です。今日のほとんどの企業はソフトウェアに非常に依存しているため、開発者はあなたの会社の非常に重要な部分を形作るための重要なリソースです。

まず、開発者は自分のローカルマシン上で必要なものすべてを設定、インストール、およびテストすることができるため、生産性が向上するという利点があります。彼は自分のソフトウェアの特定の側面を試すために特定のソフトウェア、ヘルパーツール、または珍しい構成を必要とする場合があります(例えば、古いバージョンのOSまたは古いドライバー/ SDKでソフトウェアを実行する)。

第二に、あなたが開発者にあなたがそれらをどのように評価するかを示すことの(私の考えではもっと大きい)利点があります。あなたは彼らがあなた自身のマシンでそれらを信頼することを彼らに示します - あなたはあなたの開発者を、ベビーシッターなしで彼ら自身のマシンを管理できる責任あるITに精通した人々のように扱います。 (開発者がローカル管理者にならない多くの企業では、彼らが必要とするすべてのインストール/設定のために技術サポートかセキュリティを求めなければならないでしょう。しかし、彼らはまだ彼らが単に彼らの仕事をするために必要なもののために物乞いしなければならない、それは非常にイライラさせることができる。)

16
追加された
@Downvoterは、私の答えをどのように改善できるのか、それともまったく間違っていると思うのかをコメントしてください。
追加された 著者 Tim Jansen,
@JamesSnell私は徹底的な防衛の擁護者ですが、ローカルハードウェアを除いて、ローカルの制限されたアカウントが価値のあるものをセキュリティで保護しているとは思えません。ビジネス上の価値のあるものはすべてユーザー権限でアクセスできます xkcd.com/1200
追加された 著者 Tim Jansen,
私にとっての詳細な防御には、暗号化されたハードドライブ、ローカルアカウントの強力なパスワード、安全なハードウェアモジュールなどがあります。
追加された 著者 Tim Jansen,
@JamesSnellマシンはどのように保護されていますか?マシンに対するユーザー権限を持つ攻撃者は、ネットワークに対して本格的な攻撃を仕掛けるのに十分です。ラップトップは、管理者権限がなくてもすでに感染ホストになっている可能性があります。
追加された 著者 Tim Jansen,
@JamesSnell皮肉なことに、彼らはローカルの管理者権限なしでインストールできるIDE ;-)しかし、私はあなたの論点を見ます:はいそれは潜在的な攻撃面を広げますが、ほんの少しだけです。そして、あなたの開発者がローカル管理者になってそれを回避するための「ヘルパーツール」をダウンロードしないのであれば、もっと攻撃的な面がある可能性があります。 - 開発者が彼らのマシンをより信頼できるものではなく、責任をもって信頼しているものであれば、もっと責任を持って使用する場合の調査を希望します。
追加された 著者 Tim Jansen,
あなたが彼を信頼するのであれば、@ JamesSnellすべての開発者がそうであるように、彼自身の自由意志がそうであるように。ローカル管理者は、「常にルートを使用する」という意味ではありませんが、「必要なルートを使用する可能性がある」という意味です。
追加された 著者 Tim Jansen,
これを明確にするために答えを編集する必要があるかもしれません - 開発者は通常セキュリティで保護されたアカウントを使用しますが、必要に応じてフォームに記入して許可を求めることなくローカル管理を有効にするオプションそして私は彼らがこの特権を賢明で控えめに使うことを信頼する
追加された 著者 Tim Jansen,
つまり、この答えは最低特権の原則と徹底的な防御の概念全体に違反しています。ローカル管理者を制限する理由は、通過する攻撃を軽減するのを助けることであり、善良な開発者はそれを理解するでしょう。明らかな必要性があるところでそれは別の野球の試合です、それはしばしば昇格された特権の使用が一時的であるようにそれは別のローカル管理者アカウントで満たされることができます。しかしOPは彼らがWeb開発者であると言っているので、ローカル管理者権限の必要性はほとんどないはずです。 security.stackexchange.com/a/190182/17321 をご覧ください。
追加された 著者 Martin Spamer,
@Falco - 重要なのは、このマシンがさらなる攻撃を仕掛けるためのプラットフォームとして使用されるのを防ぐことです。
追加された 著者 Martin Spamer,
@ファルコ - それは攻撃面を縮小します、あなたはリンクされた答えを読んでいませんでしたか?さらに... theregister.co.uk/2018/07/25/developers_malware_vectors
追加された 著者 Martin Spamer,
@ファルコ - それは信頼の問題ではありません。私は自分のシステムをこのように動かしています。必要のないときは自分の権利を制限します。
追加された 著者 Martin Spamer,
@JamesSnell Visual Studioにはローカル管理者権限が必要です。これは(imo)大きな理由です。VisualStudioを使わずに開発してもうまくいかないからです。あなたのコメントの残りの部分に同意しない、ローカル管理者権限の必要性だけ。
追加された 著者 user180588,

大規模な組織で働いている私の経験では、開発者が開発固有のリソース以外のものに対する完全な権利を持つことは絶対に一般的ではありません。

あなたの組織は大小の境界線にあるように見えます。

あなたの組織がもっと成熟した開発方法を開発する時が来たようです。

公平に言うと、この種の変更は、運用チームが開発チームを驚かせるものではありません。

セキュリティと開発者の生産性は、あなたの会社のために互いに対立する必要はありません。コアビジネスネットワーク上のリソースにアクセスできないネットワーク上で開発作業を行うことで、この衝突を完全に回避できます。

あなたはとにかくあなたの生産資産に対して開発をしていませんね。

あなたがそうであるならば、あなたはそうであるべきではありません - それはあなたの資産、特にそれらの利用可能性に重大なリスクをもたらします。

もっと良いやり方は、(社内の実際の個人に関する個人情報のようなものを公開することなく)機能とデータセットの重要な部分を複製する開発環境全体をセットアップすることです。この複製された環境は分離をかなり簡単にします。この開発環境では、開発者はマシンを完全に制御する必要があります。開発環境の外で資産を完全に管理する必要はありません。

個別の開発環境を実装する方法はいくつかあります。

  • インターネットに接続されているかどうかに関係なく、完全に独立したハードウェア(ワークステーション、サーバー、ネットワークデバイスなど)
  • 仮想化環境(仮想ネットワークを含む)ハードウェア上またはクラウドサービスプロバイダ上で、インターネットアクセスの有無にかかわらずホストされている場合
  • 上記の2つのアプローチの組み合わせ

開発環境に出入りする必要がある共有のために、ある種のブリッジを実装することもできます(まだある種のサービスをまだ使用していない場合)。

開発環境は、ほとんどのネットワークと同じように保護する必要があります。アクセス制御や基本的なセキュリティ対策を考えずに、すべてのコードと開発資産をオンラインにしないでください。

また、これを一歩進めて1つの環境ですべてのコードを作成し、それを統合テスト用に別の完全に別の環境に構築/デプロイする場所もあります。

12
追加された
GDPR時代には、開発者をプロダクションシステムから遠ざけることは、ほとんど法的義務です。法律の良いところは、社内の方針に勝ることです。
追加された 著者 Martin Marconcini,

あなたの答えを読んだり、あなたの意見を交換したりするのに巨大で大胆なテキストは必要ありません。

追加された 著者 Luc,
私自身の答えを書くのではなく、私はこれを土台にしたいと思います。私の仕事では、1)開発サーバー、2)その他の非プロダクション(QA、TSTなど)サーバー、3)プロダクションを区別します。開発者は、開発作業を行うための管理者アクセス権を持つことができますが、コードや他のアセットをパッケージ化して他の非prod環境にデプロイするために提供すること終わり。グループ2の目的に反するProdとの違いを導入しているそれらのグループ2システムにもそれらを望みません。
追加された 著者 KS.Pan,
これは正しい答えです。開発者は開発ワークステーションへの管理者アクセス権を持つべきですが、それらのワークステーションからの本番システム、機密データを含むDBへのアクセス権を持ってはいけません。
追加された 著者 Galaxy,

まず第一にあなたはそれが「共通」または「典型的」なものは何でも問題ではないということを学ぶ必要があります。 通常そのような状況は恐ろしく処理されます。あなたはこの声明のために最良のケースを作っています。

ローカル管理者アクセスがある人(請負業者であろうと従業員であろうと必要)であるならば、解決策を見つけることはセキュリティチーム/人(その特定の分野を担当する人)の義務です。 。さまざまな解決策があります。隔離VLANの作成、仮想マシンなどがここで命名されました。

「私たちには自分のマシンに対する管理者権限もあります」と聞くためだけに他の組織の設定について調べることは意味がありません。あなたのインフラと全く同じものではないインフラを見つけることはできません。重要なことは、セキュリティチーム/個人が安全なソリューションを計画し、それをIT部門がこの特定の組織に実装することです。

実装されたソリューションが適切に機能せず、それでも作業できないままになっている場合は、セキュリティチーム/担当者に再度提案します。これでうまくいかない場合は、上司または契約先に連絡してください。

あなたが今やっていることはお金を燃やすことであり、他には何もありません。このゲームの他の参加者が今までにこれを考え出していないならば、それは悪いです。しかし、そうしてもいいのです。

10
追加された
質問に答えないことと別の見方をすること、または別の観点から問題をOPに示すこととの間には違いがあります。
追加された 著者 Sean,
Marcelの答えについて述べたので、現実には、あなたのの回答は質問に答えておらず、実際にはそうすることを明確に拒否しているようです。 OPに別のより関連性のある質問をするように促したい場合は、コメントでそれを行うことを検討してください。
追加された 著者 Bobas_Pett,

これは根本的に文脈、特にあなたの脅威モデルに依存します。

一部の組織では、開発者が自分のOSをインストールできるようにするために、開発ワークステーションを完全に制御することが一般的です。

いくつかの組織では、すべての開発は空中環境で行われなければならず、電子機器を出し入れすることはできません。

ほとんどの組織は、この2つの両極端の中間にあります。開発環境が制限されればされるほど、開発者の生産性は低下し、自分の最高の才能を失う可能性が高くなります。あなたの組織は、侵害された開発者ワークステーションの可能性と影響、そしてこのリスクを軽減するために開発者の生産性をどの程度低下させることを望んでいるかを評価する必要があります。

7
追加された

あなたが実際に抱えている問題は、有能なITが骨のあるルールを執行しようとしていることです。あなたには本当に唯一の選択肢があります。開発者に効果的な管理者アクセスを与えます。

私は同じアドバイスが何度も何度も繰り返されているのを見続けています。それは開発者がadminを持っているがインターネットを持っていない2台目のマシンに帰着するということです。あなたはスイスチーズのセキュリティを確保したいのならそれが進むべき道です。典型的な開発者のコ​​ンピュータにインストールされているソフトウェアのリストは、通常画面より長いです。これらの多くは更新をチェックするための唯一の選択肢を持っています - インターネット。 WSUはそれらが存在することを認識していないため、WSU経由でパッチを適用することはできません。

これは議論が理解していないことです:開発者の個人的なアカウントに違反することは開始点ではありません。それは大当たりです。そこから管理者になる理由はありません。違反者は、バックドアを挿入するためにコードベースを変更することができます。開発者の立場で管理者を獲得してもそれほど面白くありません。

あなたが管理者を拒否したいときあなたは何に対して防御していますか?誰かがコードベースにアクセスしますか?いいえ。誰かがそれを出発点として使用していますか?あなたの本番LANがあなたの開発用ボックスから保護されていないのなら、あなたは何か問題を起こしています。開発者はインストールすべきではないものをインストールしますか?いいえ。開発者はコンパイラを持っており、コンパイラによって出力されたコードを実行します。これは未承認のソフトウェアを実行していることの定義かもしれません。

私は、開発者が管理者にならないというポリシーについて多くの話を聞いたことがありますが、開発者がセキュリティポリシーを覆す一方で、ITのやり方が逆になっているようです。私はもっ​​と多くのITが見つけることさえできないと聞いたことがあります。私は、セキュリティチェックを迂回するように開発者に指示している開発者のマネージャの一部を聞いたことがあります。

遅かれ早かれ、組織は単に開発者に管理者を与えることを学びます。たぶん実際にそれを知らずにそうしたのではないだろうもののほとんど。

インターネットとローカルドメインに接続された1つのボックスでdevs local adminを与えることがはるかに賢明です。代わりに生産を保護してください。高いレベルの特権でプロダクションにアクセスする必要がある人が少なくなるため、ロックダウンはより簡単になり、有能な組織はそれを行うことを学びます。

しかし、突然このような管理者を奪うことはほとんど常により重要な開発者の損失をもたらします。あなたはそれを望んでいません。

あなたはWindowsサイトについて話をしたいので、ほとんどの人々のデータを上回る1つの逸話があります。マイクロソフトは、その開発者にローカル管理者を与えます。 Windowsのメーカーは、それを価値のあるものにするために開発者にadminを与えないことに十分な利益がないと結論付けました。したがって、あなたは同じことをするべきです。

6
追加された

私はうまくいく二つのアプローチを見ました。

  1. 開発者に自分のマシンへの管理者アクセス権を付与します。これが最も簡単で一般的な方法です。通常はこれが最善の選択です。
  2. 開発者が管理者権限なしで作業できるようにすることを仕事全体とするチームを組織内に作成します。このチームは通常3-4人です。コンテナやVMを使用するにつれて開発者のハードウェア要件が劇的に増加することがわかります。そのため、すべての開発者にとって新しいハードウェアを購入するための予算が必要です。あなたがロールアウトするとき、初期の採用者のチームから始めて、そして徐々に管理者アクセスなしであなたの開発者全員をマシンに移してください。この手続きには少なくとも6か月かかります。

あなたの会社が今していることをやるのであれば、あなたの開発者は1ヶ月かそこらのためにそれを我慢しますそれから新しい仕事を探し始めます。

5
追加された
開発ツールが何らかの管理者アクセス権を必要とするのはまったく無理です。必要なものが何であれ、開発者用ボックスの設定と保​​守を担当するITチームは、インフラストラクチャのセキュリティを犠牲にすることなくツールが機能するようにソフトウェアを再構成したり適切なインタフェースを仮想化したりできるはずです。
追加された 著者 Mike Caron,
@UEFI:その代わりに、ウイルスをインストールするたびに開発者のマシンを再イメージ化し、失われた開発時間と起こりうる資産の損失に対処するために人々を雇う必要があります管理者以外のユーザーが自分のプロセスをデバッグする
追加された 著者 Mike Caron,
@UEFI:いいえ。JSはユーザーアカウントの特権ドメインでは動作しない埋め込み言語です。ブラウザによって実装された複雑な特権ドメインで動作します。ブラウザのサンドボックスエスケープの脆弱性の下で、他のプロセスをデバッグするためのベクトルが存在することは本当です(しかしサンドボックスエスケープの場合にあなたを攻撃するためのより良いベクトルが既にあります)。そのため、強化するためには、デバッガアタッチポリシーを設定可能にし、それを使用することに興味がないユーザには無効にすることが有用です。しかし、これは特権モデルの本質的な側面ではありません。
追加された 著者 Mike Caron,
3-4人、フルタイム?それは私がよりよく使うことができると思うたくさんのお金です。そして、開発者に管理者権限を与えることが最良の選択だと思う理由を詳しく述べたいと思うかもしれません。
追加された 著者 Luc,
@Luc多くの開発ツールは、ローカル管理者権限に大きく依存しています。例えばMS Visual Studioは、正しく実行するためにすべてのローカル管理者特権を必要としませんが、特定の管理者特権を必要とします。デバッグのためのDEBUG_SE、サービスをうまく管理するためのサービス管理、データベースのための権利の作成、そして私は何年もの間続けることができました。開発者がデータベーススクリプトを実行できない、アプリケーションをデバッグする、またはサービスをインストールすることができない理由を検出することは、非常に時間がかかる可能性があります。
追加された 著者 Jeff,
@R ..私は定期的にプログラムを起動し、そのプログラムにデバッガをアタッチして内部状態を読み取り、実行を一時停止して任意のコードを実行できるようにします。これには管理者アクセス権が必要です。あなたが私がこれをするのを禁じれば私の生産性は落ちるでしょう。
追加された 著者 jagsler,
@Lucそれはより安いのでdevsに管理者アクセスを与える方が良いです。つまり、開発者のマシンを動かし続け、セキュリティポリシーに不満を抱くために、フルタイムで3〜4人を雇用する必要はありません。
追加された 著者 jagsler,
@R ..それでは、私のWebブラウザでjava-scriptを実行すると、自分のシステム上の他のプログラム(パスワードマネージャなど)の内部状態にアクセスできるようになるはずです。セキュリティ上の問題はありません。
追加された 著者 jagsler,
@R 'devops'について読みたいと思うかもしれませんが、現代の開発者は管理者アクセスを望んでいるという非常に合理的な動機があることに気付くでしょう。個人的には、自分のマシンを制御できないことが大きな赤い旗です。前もって言われれば、私はあなたの求人を断ります、そうでなければ、私の最初の2週間は私の最後になります。
追加された 著者 Douwe,

はい、いいえ - 私たちの上級開発者は、必要なときに昇格させてアプリケーション/アップデートをインストールすることを許可するために、別々の管理者アカウントを持っています。ただし、そのアカウントでコンピュータにログインすることは許可されていません。彼らの管理者アカウントはまた、通常の開発用コンピュータへの管理者アクセスを許可し、ITチームを介するよりも迅速なサポートを提供します。

これはすべてアプリケーションホワイト/ブラックリスト、強力なパスワードポリシー、リムーバブルデバイスの禁止、ゲートウェイプロキシ、DLPポリシー、厳格なAVルールなどと組み合わされています。彼らのマシンは定期的に監査されており、ITチームの可視性は高いです。

個人的には、私は開発者がローカルの管理者アクセス権を持っていないことを望みます。 UACを必要とするアプリ(それが必要とするフォルダ、キーなどを見つける)を調べ、UACプロンプトを軽減することはできますが、時間と研究が必要であり、すべての企業がこれを行うためのリソースを持っていません。それで、私達はそれらに中途半端に会い、双方向の信頼を期待します。また、複数のコーポレート製品を使用して多数のルールを実施しているため、ある程度の安心感があります。

4
追加された
これは質問に答えません。これが「典型的」なのかどうか、またその理由は説明しません。
追加された 著者 Sean,

私はしばらくの間、セキュリティを本当に信じる会社のために働いていました(あるいは彼らはそう考えています)。

時々ボウリングをするような、彼らは社会的なイベントを企画するでしょう。参加は無料でしたが、共有フォルダに置かれたExcelファイルのリストに自分の名前を追加する必要がありました。そのフォルダは社交イベント専用で、他には何もありません。

それで、あなたはボーリングをしたいですか?あなたはあなたの名前をそのリストに追加したいですか? Ohhhhhhhhhh、親愛なる…誰もがそのファイルを編集できるようにしているわけではありませんね適切な権限を要求する必要があります。

これが手順です。

  • 会社のサイトを開く
  • いくつかのモジュールを入力する準備ができているセクションを探します
  • 「リリースシート」という文書を探してダウンロードします。
  • 印刷する
  • あなたの要求を記入して署名します
  • 幹事に渡します
  • 幹事は、翌日の朝にこれらの要求をすべて管理者に伝えます。
  • 遅かれ早かれマネージャーが署名します
  • 秘書があなたに返却します。
  • この時点でスキャンできます
  • チケットを処理するためにITが使用するサイトを開く
  • 必要なものを説明したチケットを作成し、スキャンしたリリースシートを添付します。緊急性を1時間から2週間に設定することを忘れないでください。
  • 最終的にはITが(うまくいけば)それを行います

On average, it would take 3-4 days to get it done. In some cases, weeks. Really efficient, eh? Hey, you asked for access to a certain folder but forgot to mention the subfolder? HA! You've won another round! And, guess what? Since they were following some QA process, they were organizing documents in a lot of different folders. When a new colleague came, he could easily spend weeks trying to get all the permissions he needed.

今すぐ

  • 管理者は、署名している内容を確認するのに面倒を感じていましたか。確かに違います。彼らはリリースシートを認識しました、そしてそれはそれでした。
  • 秘書はもっとチェックしていたと思いますか?たぶん彼らは試したが、彼らは私に特定のマシン上の特定のフォルダに対する読み書き許可を与えることの意味を本当に理解することができるだろうか?そうではありません。
  • ITが緊急性について気を悪くしたと思いますか。そうではありません。

それでは、このアプローチは何につながったのでしょうか。会社がこれまでに作ったものすべてを盗もうと思ったら、USBドライブを持ってきてそれをあなたのPCに接続しなければならなかった。その "Confidential_Documents"フォルダにアクセスできない?それを要求するだけで、彼らはそれに署名します。そしてそれが緊急の場合? 「こんにちは、その文書が必要ですが、アクセスできません。パスワードを教えてください。」

それで、この「セキュリティモデル」は信じられないほど遅く、不格好でイライラし、そして彼らの財産をまったく保護しませんでしたが、少なくとも誰もがボーリングイベントに参加者を混乱させることは容易にできませんhttps://xkcd.com/1200/ "rel =" nofollow noreferrer ">必須のxkcd )。

その会社にならないでください。他の人が言っているように、それが一般的であるかどうかを尋ねるのではなく、それが理にかなっているかどうかを尋ねなさい。そして答えは次のとおりです。いいえ、あなたの会社がお金を燃やすのが好きでない限り、そうではありません。

4
追加された

私はあなたのソフトウェア開発者と同じ船に乗っています。当社は最近、管理者権限のあるワークステーションからなしで仮想マシンにアクセスしました。私たちのワークフローに大きな影響を与えていたので、私は自分自身を管理者として実行するためにIT部門の記事を読む以外に何もしていないことに気づきました。

経営陣が思い付いたのは 2台の仮想マシンのアプローチでした。

当社の仮想マシンの1つは、Eメール、Webアクセス、およびMicrosoft Suiteを搭載した基本的なビジネスマシンでした。これはコミュニケーションの必要性を満たしました。

他の仮想マシンはローカル管理者権限を持っていましたが、インターネットから完全に切断されています。そういうわけで、私たちはそのマシン上で何かをダウンロードすることができませんでした。 (他のサイトからダウンロードしてダウンロードしたものをコピーすることもできますが)内部サイトにアクセスし、ビジュアルスタジオで使用されるいくつかのこと(Nuget、Symbolsなど)をホワイトリストに登録しました。

このアプローチにより、IT部門はセキュリティに関しても満足したままになり、同時に管理者アクセスも許可されました。

唯一の悪い点は、各マシンをそれぞれ独自のモニタに配置する必要があるため、1台のマシンにデュアルモニタを使用できないことです。

3
追加された

Short answer: Yes, it is common to have local admin access to selected groups, such as developers or IT admins. Basically, people whose day job is a lot easier with admin access while the usual office worker would need it at most once a month and typically much less than that.

Long answer: It depends...

一般ユーザーの場合、管理者アクセスには問題が発生する可能性が多く、そのリスクを相殺する利点はほとんどないことを理解するために完全なリスク分析を実行する必要はありません。

ただし、開発者(および他の少数のグループ)にとっては、リスク分析は確実に保証されており、会社の事実、状況、リスク選好、および脅威の状況に基づいて、問題に関する適切な決定が求められます。 「ベストプラクティス」を指し示し、空白の固定サイズの移動を行うことは、情報セキュリティを担当する人が数字を実行して思いつくための時間や知識を欠いていることが原因で発生する問題です事実に基づくリスク治療の決定。

That doesn't necessarily mean that they are wrong. A full analysis could very well lead to the same conclusion.

あなたが書いたものからあなたがいる時点で、それは未知数です。あなたは適切なリスク分析を行うことを求めることができます。あなたの専門知識を方程式の緩和コストの側面に加え、失われた生産性と現在の測定の他の効果を数えます。これは、情報セキュリティ担当者が特定するリスクと比較検討する必要があります。

関連する他の対策もあります。私が推奨する典型的な解決策の1つ(私は職業上の情報セキュリティアーキテクトです。定期的にこれらの質問を受けます)は、開発者ネットワークを通常のオフィスネットワークから切り離して、リスクの高い領域を含めることです。開発者のコ​​ンピュータを十分に強化し、ローカルのファイアウォールと最新のウイルス対策を要求すると、一般的な攻撃のシナリオに対しては問題ありません。あなたの会社が外部からのエクスポージャーを持っている場合は、開発者が標的型攻撃に狙われないように、開発者向けの追加の意識向上トレーニングを追加することもできます。

私は個人的に両方の種類の開発者環境を監督しました、そして少しの努力で両方がうまく働くようにすることができます。確立された作業方法でプラグを引っ張るだけではひどくそれを処理できず、あなたが参加していた反発は予想されることでした。しかし、行われたことは行われており、それに焦点を合わせずに将来を見据えるのはおそらく賢いことです。

3
追加された

仮想マシンを使用してこの問題を解決しました。

どの開発者にも、管理者権限のない通常のユーザーアカウントがあります。そのユーザーアカウント内には、インターネットにアクセスできない仮想マシンがあります。仮想マシンの内部では、開発者は自分のアプリケーションを管理者権限で実行できます。

このようにして、必要なプログラムを閉鎖環境で実行する方法を得ながら、インターネットアクセスと重要なデータを管理者権限の使用から切り離すことができます。

3
追加された
OPが開発環境を実行するために(ローカル)管理者特権を必要とすると仮定しましょう。たとえば、上記のMicrosoft Visual StudioおよびSQL Management Studioは管理者権限に大きく依存しています。これらのソフトウェアが(更新、オンラインヘルプ、ソース管理、そして私が何年にもわたって続けることができるという点で)大きく依存しているもう1つのものは、インターネット接続です。インターネットに接続せずに(ローカル)管理者権限を提供するVMを使用することは、ハードな場所でロックを切り替えることを意味します。
追加された 著者 Jeff,

MS-Windows NTは創業以来マルチユーザーシステムシステムでしたが、そのような方法でそれを操作するのは本当に簡単ではありません、そして開発者(Micosoftを含む)はまだ特権分離の考えを無視する傾向があります。この種のアクセス制御はあまり文書化されておらず、トレーニングでは機能しない傾向があり、多くの場合UIからアクセスするのが難しく、監査するのが難しく、分離を適用するためのパターン/ツールがありません。

公平性のために、たとえUnix/Linuxシステム上でさえ、私は実ユーザーとサービスの両方のために特権分離を適切に使用していない多くの開発者を見ます。しかし、どのプラットフォームでも、実装者が特権を分離する方法に障壁を設けることは、完全な(ローカル)管理者特権を与えるよりもセキュリティにとってさらに非生産的です。

一方、MS-Windowsでの開発についてはほとんど知りませんが、Visual Studioを実行するにはlocal-admin特権が必要であることは驚くべきことです。そしてあなたが管理者アクセスを必要とする唯一の理由がサービスの停止/開始、またはサービスの再設定をしても、同情はあまりありません。指定されたユーザーにローカル管理者を与えずにこの機能を提供することは可能です。 IIS 7の大きな変更点の1つは、管理権限を委任します。そして、Apache、MySQL、そしてPHPの再構成を委任するのはいつも簡単でした。

ローカル管理者アクセス権がいつ削除されたかについての短い通知がありました

問題はセキュリティチームが彼らが達成できないレベルの能力を目指すことであるように思えます(これは私の経験では非常に一般的です)。適切な影響評価を行わず、生産性/セキュリティへの悪影響を軽減することを検討せずに、ポリシーを変更してはいけません。

すべてのワークステーションに少なくとも2つの主要なウイルス対策プログラムがあります

それはこれらのシステムの完全性を保護するためのとても素朴なアプローチであり、あなたが対処しなければならないことの絵を描きます。

他に選択肢はあまりないようです

それについての議論に入っても、おそらく現時点でそれほど生産的にはならないでしょう。

全体的には、あなたがあなたの地元のセキュリティチームと競争しているかのように聞こえます。彼らはあなたがあなたの仕事をするために必要なものを理解していない、あなたは彼らの目的を達成する方法を理解していない。そしてどちらの側も交渉を望んでいないようです。市販のツールでこれを解決することはできません。

2
追加された
....そして、私はなぜ私がマイクロソフトウィンドウズでプログラミングをするのを避ける理由を思い出しました:)
追加された 著者 bpapa,
事実上正しくありません。 Visual Studioはローカル管理者権限なしで実行されます。実際、これがデフォルトです。また、開発者アカウントにデバッグ権限を割り当てると、Visual Studioはそれほど頻繁に管理者権限に昇格する必要がなくなります。それは完全に避けられますか?いいえ、ドライバ開発者は絶対に例えば管理者アクセスを必要とするでしょう。
追加された 著者 Martin Marconcini,
Visual Studioがこれらの管理者権限を持つ理由の1つは、IISが伝統的にシステムアカウントで実行されている他のユーザが所有するプロセスのデバッグを可能にすることです。開発者が別のプロセスをデバッグするとすぐに彼らはウイルスチェッカーなどを無効にすることができます90%で削除ヘッドが遅くなることは彼らから珍しいことではありません。したがって、開発者にデバッガを使用させないことと開発者を信頼することの間の選択.....
追加された 著者 Gowri,
@ mg30rg:DEBUG_SEは実際には「他人のプロセスをデバッグする」という意味です。
追加された 著者 Joshua,
@ mg30rg:開発者が通常adminとして実行されるコードに取り組んでいるのであれば真、しかし彼はとにかくadminを持っています。
追加された 著者 Joshua,
@ mg30rg:Kestrelにより廃止されました。現在は開発者の名前で実行されています。
追加された 著者 Joshua,
Visual Studioは管理者権限なしでは実行できますが、場合によっては管理者権限なしでは正しく実行できません。はい、正しく実行するためにすべてのローカル管理者権限が必要ではありませんが、特定の管理者権限が必要です。デバッグのためのDEBUG_SE、サービスをうまく管理するためのサービス管理、データベースのための権利の作成、そして私は何年もの間続けることができました。もちろん、セキュリティチームに連絡して、日常的に必要な特定の権限を要求することもできますが、その呼び方を知っていますか?生産性殺人
追加された 著者 Jeff,
@Joshuaそして、例えばシステムアカウントで実行されているWindowsサービスをデバッグするために何が必要だと思いますか?このシナリオは、Windows開発では珍しいことではありません。
追加された 著者 Jeff,
@ Joshua Mキー、そしてASP.Net開発はどうですか?そのためには、Network Serviceアカウントで実行されているIISサービスによって開始され実行されているプロセスをデバッグする必要がありますか?
追加された 著者 Jeff,
@Joshua KestrelはほとんどIISではありません。
追加された 著者 Jeff,

ネットワークを隔離する

開発、テスト、本番、およびビジネスのための環境は比較的隔離されている必要があります。これにより、開発者は必要な場所に特権を持つことができます。

適切な分離は、許可されていない変更を防ぎ、マルウェアの拡散を制限し、データの流出を防ぎます。

何が起こる?

開発

The 開発 network is where coding takes places. Developers should have administrative rights in case they want to test code snippets or run something without packaging it for deployment to test/prod.

コンピュータはIDE、ソースリポジトリ、そしてあなたのアプリに必要なアプリ/フレームワークを実行します。専用のコラボレーションツールや他の開発者向けアプリが妥当です。

テスト

The テスト network is where compiled, ready-to-ship code is tested. Developers may have admin rights, but regular system admins should be deploying applications.

Deployments should reflect what the admins will maintain in 製造 for internal apps. They should be customer-ready packages for external apps (including install wizard and digital signatures, albeit using a separate signature for テスト purposes to prevent accident releases).

Developers often need system logs and debug access, and these are the only reasons they should have admin rights. They should not be involved with installation, configuration, and テスト unless absolutely necessary.

製造

The 製造 network is where you provide services to clients and partners. Since a formal deployment process should exist, there is no reason for it to connect to your dev/test networks.

To minimize risks of internet-borne malware and accidental changes, accounts from the dev/test/ビジネス networks should have no access to 製造 if possible, which translates to limited permissions with occasional arguments in practice.

Ideally, this network would be completely isolated, but in practice this is impossible in a world where 製造 servers must interface with systems for sales, billing, scheduling, netops, and project management. Get as close to the ideal as you can; it's really all we can do.

ビジネス

これは企業にとっての主要な通信ネットワークです。

Email, web browsing, and partner connectivity all bring a host of risks. Your 開発, テスト, and 製造 networks should be isolated from these risks to the maximum extent possible.

詳細、詳細、詳細

あなたの組織が行き詰まった可能性があります。柔軟で安全なネットワークアーキテクチャに不可欠な無数の詳細を扱うよりも振り子を完全に振り回す方が簡単です。

次の場合、開発者は企業へのリスクを最小限に抑えながら、自分のマシンに管理者アクセス権を持つことができます。

  1. インターネットにアクセスするための特権のない個別のアカウントがあります
  2. 各環境で一意のアカウントが使用されている
  3. 制限されたファイアウォールルール/ ACLが環境間に存在する
  4. ファイアウォール、ウェブプロキシ、IDS/IPSなどの標準的なセキュリティ対策が実施されている

あなたの開発者は4つのアカウントが必要になります。

  • Unprivileged dev account to access resources on the internet (if they do not want to hop back and forth from the ビジネス network, which is onerous)
  • Privileged dev account to configure workstation and test code
  • Privileged test account to debug applications
  • Unprivileged ビジネス account for email, web, intranet

開発者に何らかの検証やQA作業を行わせる場合は、テスト環境に特権のないアカウントも必要になるかもしれません。

Developers should have no access to the 製造 network and no administrative privileges on the ビジネス network. If this impossible for the moment, then those roles should be separated or else a rigorous change control process should be put in place.

2
追加された

それは彼らの特権を悪用する開発者がとても無用/悪意のある、または誰もが見ていない見知らぬニー・ジャークの馬鹿によって運営されている開発者にローカル管理者アクセスを拒否させるのが典型的です。それらを悪く見せるための明らかなセキュリティ脅威としての彼らの内側の円。

あなたの "ITとセキュリティ"部門がまたWindowsが完全に良い無料のものと来るとき2つのアンチウイルスプログラムを要求することを考えると、私はあなたがあなたの組織のどこに問題があるのか​​を決めてそこから働くことができると確信しています。

0
追加された