組織の開発者にローカルデスクトップやActive Directoryの管理者アクセスと権限を許可することは一般的ですか？
私は1000人以上のスタッフがいる会社で働いています。現在、Webベースのプロジェクト（約50人）に取り組むプログラミング開発スタッフがいます。
最近、セキュリティ上の懸念により、ITおよびセキュリティ部門は、マシンのローカル管理者アクセスを許可しない制限を実装しました。会社全体で、ワークステーションとサーバーの両方にWindows OSを実行しています。私は管理者を削除する決定に完全に同意しました、正直に言って、それは長い間遅れていると思いました（会社が患者データを扱い、HIPAAコンプライアンスを必要とするため）。残念ながら、私は彼らが決定を行き過ぎたと思います。私は、サブグループまたはADグループが、管理アクセスを保持するTechグループのような何かを行うために、管理アクセスを合法的に必要とするユーザー（プログラミングチームを除く）のために作成されると想定しました。ただし、これは当てはまりませんでした。唯一のグループが、ネットワークとヘルプデスクのスタッフのために特定の管理者グループを作成しました。
主な問題は、Web開発者がローカルの管理者アクセスを必要とするプログラムを実行しているため、残念ながら、管理者として実行しないと仕事ができないことです。サンプルプログラムには、Visual Studio for ASP.NET Web開発、MAMP for local development、composerなどが含まれます。これらのプログラムが管理アクセスを必要とする主な理由は、ローカルIISやコマンドラインなどを実行および変更する必要があるためです。
基本的に、ローカル管理者アクセスが削除されたときの短い通知がありました。約2日間、開発チームが働くことができるという点で水没し、私と他のチームリーダーは基本的にITスタッフに叫んで叫んで解決策を考え出した後、最終的に認めたサードパーティプログラムを見つけました。ローカルの管理者アクセス権がない場合でも、管理者が特定のプログラムを管理者として実行する機能を作成できるようにするパススルーとして機能します。
残念ながら、ローカル管理アクセスに使用するこのプログラムは信じられないほどバグが多く信頼性が低く、信頼できるソースからのものではありません。また、他に選択肢があまりないようです。 （私は私たちが使用するプログラムを開示したくないと思います。）
私の質問は、会社または企業でプログラマー/開発者のローカル管理者アクセスを許可しないことは一般的ですか？そして、そうすることが一般的な慣行である場合、開発者はローカル管理者として必要なプログラムをどのように実行しますか？
私たちのネットワーク環境に関するもう少しの情報（これは私がこれを追加したいと思った質問に本当に関連しているわけではありません）：
- AppBlockerを使用して、承認済みリストにないプログラムをブロックします
- 添付ファイルのスキャンやPDFへの変換などを行うメールセキュリティブロッカーを使用しています。
- すべてのワークステーションに少なくとも2つの主要なウイルス対策プログラムがあります。
- ネットワークとそのサーバーは非常に分離されており、ユーザーは正当にアクセスする必要がある特定のサーバー、フォルダー、データベースにしかアクセスできません。
これは、セキュリティに関心のあるソフトウェア会社からの1つのデータポイントです。これは同様の組織でよくあることです。
多くのネットワークがあります。それらは物理的に分離され、エアギャップがあり、異なる色分けされたネットワークケーブルを使用します。
各従業員には「管理」マシンがあり、インターネット（プロキシ経由）に接続して電子メールなどを行うことができます。すべてのユーザーは厳重にロックされ、厳格なデバイスとアクセス制御があります。
これに加えて、各開発者には「エンジニアリング」マシンがあります。これには完全な管理者アクセス権があり、ユーザーは好きなように操作できます。ただし、エンジニアリングネットワークにのみ接続されています（インターネットへのルートはありません）。
ほとんどのソフトウェア開発コンテキストではこれは極端と見なされますが、高いセキュリティと開発者の自由という相反する要件を持つ組織では、これは一般的な解決策です。
あなたの質問に答えるために、はい、開発者に管理者アクセスを許可することは一般的ですが、これは必ずしも情報セキュリティの問題を引き起こす可能性のあるマシンへの管理者アクセスを意味するわけではありません。
私の経験では、開発者が自分のマシンで管理者アクセス権を持つことは一般的です。彼らが自分のマシンで管理者アクセスを持つことはまた一般的ですではありません。ただし、後者の状況では、あまり摩擦なしで仕事を終わらせることができるように、一般的にいくつかの調整が行われます。
1つの非常に一般的な対応策は、ワークステーション上のハイパーバイザーへのアクセスです（VMWareの一部のバージョンか、Windowsに付属のHyper-Vのどちらか）。ハイパーバイザー内で必要に応じてVMを作成および破棄するために必要な特定の権限 （ Hyper-V / VMWare ）、ゲストOSに対する管理者権限を持つVMの作成を含みます。通常、これらのVMの一部は、常に実行されていなくても、存続期間が長くなります。これは、VM全体を最初から準備して、管理者権限を必要とするものの簡単なテストになります。
ハイパーバイザーは、そのVMのインターネットアクセスを許可するように構成されている場合とされていない場合があります。私はそれを両方の方法で見ましたが、個人的には、インターネットアクセスを許可することを強く推奨しています...少なくとも、私が最も経験のある開発の種類については。ただし、インターネットアクセスが許可されている場合は、企業ネットワークの他の部分とは別に、VMを専用のVLANに強制するように構成できます。これがHyper-VまたはVMWareを介して直接適用できるかどうかはわかりませんが、多くのネットワークスイッチのポートで802.1xを使用して、devloper VMを含む無許可のマシンから特定のVLANへのアクセスを防ぐことができます。次に、VMでvlanタグを設定する方法について開発者に小さなチュートリアルを提供し、スイッチポートで許可されるvlanタグを彼らに知らせることができます。技術的な対策ではなく、単にポリシーの布告としてのトレーニングによって、おそらくコンプライアンスを促進し、開発者がそれが重要であることを確認するために時折友好的な監査を行います。
そしてもちろん、これは、複数のVMを一度に実行するのに十分強力なマシンを開発者に提供することと一致しています。
私はかなり大規模な投資管理会社（約6000人の従業員）で働いており、開発者はローカル管理者アクセスのために承認するグループの1つです。ローカルのデスクトップ/ソフトウェアのコンプライアンスによって処理されるため、ソフトウェアをインストールしないように指示します。
また、ローカル管理者を必要とせずにメンバーがマシンの実行ポリシーを変更できるようにする開発者ADグループもあります。
私の経験では、ローカル管理者アクセスの許可と禁止は一般的ですが、後者の汚い回避策と同じくらい一般的です。 -それであなたは自分自身に尋ねるべきです：
ネットワークに対するどの脅威がローカル管理者権限によって悪化しますか？
答えは次のとおりです：[〜＃〜] none [〜＃〜]-ネットワーク内のリソースへのアクセスは、ユーザーごとに制限する必要があります。このユーザーが自分のマシンにローカルのroot、admin、またはmasterOfTheUniverseアクセス権がある。ユーザーがネットワークを爆破する権限を持っている場合、ローカルウイルスは管理者アクセスさえも必要とせず、ユーザーアカウントを使用してネットワークを爆破することができます。 -そして、ユーザーアカウントがネットワーク上の何かにアクセスできない場合、ローカル管理者権限はそれについて何も変更しません。
開発者が自分のマシンを責任を持って処理することを信頼する必要があります。また、会社の賢明なセキュリティ構成では、ローカルの管理者権限は1つのことだけに危険です：ローカルマシン。したがって、ローカル管理者に与えることによって受け入れる唯一のリスクは、開発者が自分のマシンを破壊することです（彼はすでにコーヒー1杯でこれを行うことができます）。
補遺：開発者には、必要に応じてローカル管理者権限を使用する可能性を与える必要があります。これは、セキュリティ保護されていない管理者アカウントで常にログインする必要があることを意味するわけではありませんが、毎回許可を求めることなく、必要なときにいつでも賢明に使用することを信頼する必要があります。
開発者がローカル管理者権限を持つべき理由
あなたの開発者はあなたがあなたのビジネスの中核業務の設計を委託する人々です。今日、ほとんどの企業はソフトウェアに大きく依存しているため、開発者は企業の非常に重要な部分を形成するための重要なリソースです。
まず、開発者はローカルマシン上で必要なすべてのものを構成、インストール、およびテストできるため、生産性が向上するという利点があります。彼は、ソフトウェアの特定の側面を試すために、特定のソフトウェア、ヘルパーツール、または通常とは異なる構成が必要な場合があります（たとえば、古いバージョンのOSで、または古いドライバー/ SDKでソフトウェアを実行します）。
次に、開発者にあなたがどのようにそれらを評価するかを示すことの（私の意見ではさらに大きい）利点があります。あなたは彼らを彼ら自身のマシンで信頼することを彼らに示します-あなたはあなたの開発者を、ベビーシッターなしで彼ら自身のマシンを管理できる責任あるIT好きな人々のように扱います。 （開発者がローカル管理者を取得しない多くの企業では、必要なすべてのインストール/構成について技術サポートまたはセキュリティを要求する必要があります。多くの場合、これらの技術サポート担当者は、上級リード開発者よりもソフトウェアについてあまり知らない、しかし彼らはまだ彼らが単に彼らの仕事をするために必要なことを頼む必要があり、それは非常にイライラすることがあります。）
私のキャリアでは、かなり小さな会社（100人未満）で、常にローカル管理者権限を持っていました。 ITによって保守されているが権利を持っている実際のデスクトップマシンを持っているか、または私たち自身が完全に管理しているあらゆる種類の仮想マシンを使用することが許可されていました。
ローカル管理者アクセスがなかった場合は、あらゆる種類の悪い「解決策」を試して、あなたの場合と同様に、セキュリティの低下につながります。これはそれらのケースの1つであり、その制限は実際にはその意図の逆につながります。
大規模な組織のかなり小さな部門（部門で〜100、完全な組織で〜3500）では、真ん中ソリューションを選択しました。
- sysadminsには2つのアカウントがあり、1つ（ローカルマシンでも非管理者）が非管理タスク（メール、ドキュメントの編集など）に使用され、もう1つはAD管理にのみ使用されるはずのAD管理者権限を持っています
- 他のすべてのユーザーは、管理者以外のアカウントを1つだけ持っていました
- 開発者（および一部のパワーユーザー）には、ローカルマシン管理者権限を持つローカルアカウントが提供されました。地方行政が必要な場合はめったに使われないはずだった。
開発者に管理者権限を拒否すると、生産性が低下する原因になり、どの組織にとっても直接的なコストがかかります。ローカルマシンの管理者権限をプライマリアカウントまたはセカンダリアカウントに付与するかどうかの選択は、管理者の操作の頻度によって異なります。
- 1日に数回を超える場合は、プライマリアカウントを使用することをお勧めします。
- 週に1回未満の場合は、セカンダリアカウントを使用します。
間にいる場合は、自分で選択してください...
私が大規模な組織で働いた経験では、開発者が開発固有のリソース以外のすべてに対する完全な権利を持つことは絶対に一般的ではありません。
あなたの組織は大小の境界にあるようです...
組織がより成熟した開発手法を開発する時がきたようです。
公平に言えば、この種の変更は、あなたのケースで行われたように、運用グループが開発チームを驚かせるべきものではありません。
セキュリティと開発者の生産性は、会社にとって互いに対立する必要はありません。コアビジネスネットワーク上のリソースにアクセスできないネットワーク上で開発アクティビティを実行することにより、この衝突を完全に回避できます。
とにかく、あなたはあなたの制作資産に対して開発をしていませんよね？
もしそうなら、そうすべきではありません-それはあなたの資産、特にそれらの利用可能性に重大なリスクをもたらします。
はるかに良い方法は、機能とデータセットの主要部分を複製する開発環境全体をセットアップすることです（会社の実際の個人に関する個人情報のようなものは公開しません）。この複製環境では、分離がかなり簡単になります。開発者は、この開発環境でマシンを完全に制御する必要があります。開発環境外の資産を完全に制御する必要はありません。
別の開発環境を実装するには、いくつかの方法があります。
- インターネットに接続されているかどうかに関係なく、完全に別個のハードウェア（ワークステーション、サーバー、ネットワークデバイスなど）
- 仮想化環境（仮想ネットワークを含む）;ハードウェアまたはクラウドサービスプロバイダーでホストされ、インターネットアクセスの有無にかかわらず
- 上記の2つのアプローチの組み合わせ
開発環境の内外で行う必要がある共有のために、ある種のブリッジを実装することもできます（まだ何らかのサービスをまだ使用していない場合）。
開発環境は、ほとんどのネットワークと同様に保護する必要があります。アクセス制御や基本的なセキュリティ対策を何も考えずに、すべてのコードと開発資産をオンラインに投げるだけではいけません。
また、いくつかの場所でこれをさらに一歩進めて、1つの環境ですべてのコードを記述し、それを統合テスト用に完全に別の別の環境にビルド/デプロイすることも確認しました。
まず最初に、何が「一般的」または「典型的」かは問題ではないことを学ぶ必要があります。理由は次のとおりです：通常、このような状況は恐ろしく処理されます。あなたはこの声明の最良のケースを作っています。
ローカル管理者アクセスが人（請負業者であれ従業員であれ）に必要である場合、それはセキュリティチーム/人-その特定の領域を担当する人の義務です-解決策を見つける。ここには、分離されたVLANの作成、仮想マシンなどのさまざまなソリューションがあります。
「私たちにもマシンの管理者権限があります」と聞くだけで、他の組織のセットアップを問い合わせても意味がありません。あなたと同じ正確なインフラストラクチャは見つかりません。重要なのは、セキュリティチーム/担当者が安全なソリューションを計画し、それをこの特定の組織のIT部門が実装することです。
実装されたソリューションが適切に機能せず、それでも機能しない場合は、セキュリティチームまたは担当者に再度ご相談ください。これが機能しない場合は、上司または契約者に持って行ってください。
あなたが今やっていることはお金を燃やすことであり、他には何もしていません。このゲームの他の参加者がこれまでにこれを理解していない場合、それは悪いことです。でもそうならいいです。
あなたが実際に抱えている問題は、有能なITが骨太のルールを施行しようとしていることです。あなたは本当に1つの選択肢しかなく、開発者に効果的な管理アクセスを与えます。
同じアドバイスが何度も何度も繰り返されているのを見続けます。つまり、開発者が管理者を持っているがインターネットを備えていない2番目のマシンになります。スイスチーズのセキュリティを確保したい場合は、この方法が適しています。一般的な開発者のコンピューターにインストールされているソフトウェアのリストは、通常、画面よりも長くなります。これらの多くには、更新を確認するためのオプションが1つしかありません。インターネットです。 WSUはそれらが存在することを認識していないため、WSUを介してパッチを適用することはできません。
議論が理解できないことは次のとおりです。開発者の個人アカウントへの違反は、出発点ではありません。それは大当たりです。そこから管理者に行く理由はありません。ブリーチャーは、バックドアを挿入するようにcodebadeを変更する能力を持っています。開発者のボックスで管理者を取得することは、それほど興味深いことではありません。
管理者を拒否したい場合、何を防御しますか？誰かがコードベースにアクセスしていますか？いいえ。誰かがそれを出発点として使用していますか？実稼働LANが開発ボックスから保護されていない場合は、何か問題があります。開発者がインストールすべきではないものをインストールしていますか？いいえ。開発者にはコンパイラがあり、コンパイラによって出力されたコードを実行します。これは、承認されていないソフトウェアの実行の定義でもある可能性があります。
開発者が管理者を取得しないというポリシーについての多くの話を聞いたことがありますが、開発者がセキュリティポリシーを打倒している間、ITが他の方法で見ている習慣があります。 ITの多くが知ることすらできないと聞いたことがあります。開発者のマネージャーの一部が開発者にセキュリティチェックをバイパスするように言っているのを聞いたことがあります。
遅かれ早かれ、組織は開発者に管理者のみを与えることを学びます。おそらく、実際には知らないうちにそうしたことにならないもののほとんど。
インターネットとローカルドメインに接続された1つのボックスで開発者にローカル管理者を与えるだけで、結果がどのようなものであっても対処できるように準備する方がはるかに賢明です。代わりに生産を保護してください。高レベルの特権でプロダクションにアクセスする必要のある人が少ないため、ロックダウンがより簡単になり、有能な組織がそれを習得します。
しかし、このような管理者を突然削除すると、ほとんどの場合、より重要な開発者が失われます。あなたはそれを望まない。
Windowsサイトについて話したいので、ほとんどの人のデータを上回る逸話があります。 Microsoftは開発者にローカル管理者を提供しています。 Windowsのメーカーは、価値のあるものにするために開発者に管理者を与えないことには十分な利点がないと結論付けました。したがって、同じことを行う必要があります。
機能する2つのアプローチを見てきました。
- 開発者にマシンへの管理者アクセス権を与えます。これが最も簡単で一般的なアプローチです。それは通常最良の選択です
- 開発者が管理者アクセスなしで作業できるようにすることを目的とした組織全体でチームを作成します。このチームは通常3〜4人です。コンテナーやVMを使用すると、開発者のハードウェア要件が劇的に増加することがわかります。そのため、すべての開発者に新しいハードウェアを購入するための予算を立ててください。展開するときは、早期導入者のチームから始めて、すべての開発者を管理者アクセス権のないマシンに徐々に移動します。このプロセスには少なくとも6か月かかります。
あなたがあなたの会社が今やっていることをしているなら、あなたの開発者は一ヶ月ほどそれを我慢し、それから新しい仕事を探し始めます。
これは基本的にコンテキスト、特に脅威モデルに依存します。
一部の組織では、開発者が開発ワークステーションを完全に制御できるようにし、独自のOSをインストールできるようにするのが一般的です。
一部の組織では、すべての開発をエアギャップ環境で行う必要があり、電子機器の出し入れはできません。
ほとんどの組織は、これらの2つの極端な中間にあります。開発環境が制限されるほど、開発者の生産性は低下し、最高の才能を失う可能性が高くなります。組織は、侵害された開発者ワークステーションの可能性と影響、およびこのリスクを軽減するために開発者の生産性を低下させるためにどれだけ進んでいくかを評価する必要があります。
私はしばらくの間、セキュリティを本当に信じている（またはそう思っている）会社で働いていました。
時々彼らはボーリングをするような社会的なイベントを企画しました。参加は無料でしたが、共有フォルダに配置されたExcelファイルのリストに自分の名前を追加する必要がありました。そのフォルダは社交イベント専用で、他には何もありませんでした。
だから、あなたはボウリングをしたいですか？あなたはあなたの名前をそのリストに加えたいですか？あぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁ適切な権限を要求する必要があります。
これは手順です：
- 会社のサイトを開く
- いくつかのモジュールを入力する準備ができているセクションを見つけます
- 「リリースシート」というドキュメントを見つけてダウンロードします
- 印刷する
- リクエストを記入し、署名してください
- 秘書に渡して
- 秘書はこれらのすべてのリクエストを翌日の朝にマネージャーに受け取ります
- 遅かれ早かれ、マネージャーはそれに署名します
- 秘書がそれをあなたに戻します
- この時点でスキャンできます
- ITがチケットを処理するために使用するサイトを開く
- 必要なものを（もう一度）記述したチケットを作成し、スキャンしたリリースシートを添付します。 1時間から2週間の緊急度を設定することを忘れないでください。
- 最終的にはITがそれを実行する（うまくいけば）
平均すると、完了するまでに3〜4日かかります。いくつかのケースでは、数週間です。本当に効率的ですか？ねえ、あなたは特定のフォルダへのアクセスを求めましたが、サブフォルダについて言及するのを忘れましたか？ハ！次のラウンドを獲得しました！そして、何を推測しますか？彼らはいくつかのQAプロセスに従っていたため、ドキュメントをたくさんの異なるフォルダに整理していました。 新しい同僚が来たとき、彼は簡単に週間必要なすべての権限を取得しようと試みました
今。
- マネージャーが署名内容を確認するのに面倒だと思いますか？確かに違います。彼らはリリースシートを認識しました、そしてそれだけでした。
- 秘書がずっとチェックしていたと思いますか？たぶん彼らは試しましたが、特定のマシンの特定のフォルダに読み取り/書き込み権限を与えることの意味を本当に理解できますか？確かに違います。
- ITは緊急性についていまいましいことをしたと思いますか？確かに違います。
では、このアプローチは何につながったのでしょうか？つまり、会社がこれまでに作成したすべてのものを盗む場合は、USBドライブを持ち込み、PCに接続するだけで済みます。その「Confidential_Documents」フォルダにアクセスできませんか？それを要求するだけで、彼らはそれに署名します。そして、それが緊急であるなら？ 「こんにちは、そのドキュメントが必要ですが、アクセスできません。パスワードを教えてもらえますか？」
つまり、この「セキュリティモデル」は信じられないほど遅く、不格好で、イライラさせられ、プロパティをまったく保護しませんでしたが、少なくとも誰も簡単にボウリングイベントの参加者を混乱させることはできませんでした（ 必須のxkcd ）。
その会社にならないでください。他の人が言ったように：それが一般的であるか（それが一般的であるか）尋ねるのではなく、それが理にかなっているかどうか尋ねてください。そして答えは、あなたの会社がお金を燃やすのが好きでない限り、いいえ、それはしません。
はい、いいえ-私たちの上級開発者は、必要に応じて昇格し、アプリケーション/更新をインストールすることを許可する個別の管理者アカウントを持っています。ただし、アカウントを使用してコンピューターにログインすることはできません。彼らの管理者アカウントは、ITチームを経由するよりも迅速なサポートを提供するために、通常の開発用コンピューターへの管理者アクセスも許可します。
これはすべて、アプリケーションのホワイト/ブラックリスト、強力なパスワードポリシー、リムーバブルデバイスの禁止、ゲートウェイプロキシ、DLPポリシー、厳格なAVルールなどと組み合わされます。彼らのマシンは定期的に監査され、ITチームの可視性は高いです。
個人的には、私は開発者がローカルの管理者アクセス権を持っていないことを望みます。 UACを必要とするアプリを調査し（必要なフォルダー、レジストリキーなどを見つけ）、UACプロンプトを軽減できますが、これには時間がかかり、調査が必要であり、すべての会社がこれを行うためのリソースを備えているわけではありません。したがって、私たちは彼らの中間で会い、双方向の信頼を期待しています。また、複数の企業製品を使用して多数のルールを適用しているため、ある程度の安心感があります。
短い回答：はい、一般的に、開発者やIT管理者など、選択したグループへのローカル管理者アクセス権を持っています。基本的に、通常のオフィスワーカーは1か月に1回、通常はそれよりもはるかに少ない時間で、管理者アクセスで1日の仕事がはるかに簡単です。
長い答え：状況によります...
一般ユーザーの場合、管理者アクセスには問題が発生する可能性が高く、リスクを相殺する利点がほとんどないことを理解するために、完全なリスク分析を実行する必要はありません。
ただし、開発者（および他のいくつかのグループ）にとっては、リスク分析は間違いなく正当化され、会社の事実、状況、リスク選好度、脅威状況に基づいて問題について適切な決定が求められます。 「ベストプラクティス」を指して、何もかもが入りきったブランクの動きをすることは、情報セキュリティの責任者が数字を実行するための時間や知識が不足しているために発生する警戒態勢です。事実に基づくリスク対応の決定。
それは必ずしもそれらが間違っていることを意味するわけではありません。完全な分析は、同じ結論に非常によくつながる可能性があります。
その時点では、あなたが書いたものから、それは不明です。適切なリスク分析を実行するように依頼し、専門家の知識を方程式の緩和コストのコストに追加し、失われた生産性と現在の測定のその他の影響を数値化することができます。これは、情報セキュリティの人々が特定するリスクと比較検討する必要があります。
関連する他の対策もあります。私が時々お勧めする1つの典型的な解決策（私は専門職の情報セキュリティアーキテクトなので、定期的にこれらの質問をされます）は、開発者ネットワークを通常のオフィスネットワークから分離して、リスクの高い領域を含めることです。開発者のマシンを十分に強化し、ローカルファイアウォールと最新のウイルス保護を主張すれば、通常の攻撃シナリオには問題ありません。会社が外部にさらされている場合は、開発者向けの追加の意識向上トレーニングを追加して、開発者が標的型攻撃の対象になりにくいようにすることもできます。
私は個人的に両方の種類の開発者環境を監視してきましたが、少しの努力で両方をうまく機能させることができます。確立された作業方法でプラグを引っ張るだけでそれがうまく処理されず、あなたが参加していたバックラッシュが予想されました。しかし、何が行われたかはわかっており、それに焦点を合わせずに未来に目を向けることはおそらく賢明です。
仮想マシンを使用してこの問題を解決しました。
すべての開発者は、管理者権限のない通常のユーザーアカウントを持っています。そのユーザーアカウントには、インターネットにアクセスできない仮想マシンがあります。仮想マシン内で、開発者は管理者権限でアプリケーションを実行できます。
これにより、インターネットアクセスと重要なデータを管理者権限の使用から分離しながら、閉鎖された環境で必要なプログラムを実行する方法を取得できます。
私はあなたのソフトウェア開発者と同じ船に乗っています。私たちの会社は最近、管理者権限を持つワークステーションから仮想マシンにアクセスしました。ワークフローに深刻な影響を与えていたので、IT部門が管理者として何かを実行するために記事を読んだだけでした。
管理が思いついたのは2つの仮想マシンアプローチでした。
私たちの仮想マシンの1つは基本的なビジネス電子メール、Webアクセス、およびMicrosoft Suiteを備えたマシンでした。これはコミュニケーションの必要性を満たしました。
他の仮想マシンにはローカル管理者権限がありましたが、-インターネットから完全に切断されましたでした。その方法では、そのマシンに何もダウンロードできませんでした。 （ただし、他のサイトからダウンロードして、ダウンロードをコピーすることもできます。）引き続き内部サイトにアクセスし、ビジュアルスタジオで使用するもの（ホワイト、シンボルなど）をホワイトリストに登録しました。
このアプローチにより、IT部門はセキュリティに関して満足すると同時に、管理者アクセスを戻すことができました。
唯一の欠点は、各マシンを独自のモニター上に置く必要があるため、1台のマシンだけでデュアルモニターを使用できないことです。
ネットワークを分離する
開発、テスト、本番、およびビジネスのための比較的分離された環境が必要です。これにより、開発者は必要な場所で特権を持つことができます。
適切な分離は、不正な変更を防ぎ、マルウェアの拡散を制限し、データの流出を妨げます。
どこで何が起こる？
開発
開発ネットワークは、コーディングが行われる場所です。開発者は、コードスニペットをテストしたり、テスト/製品への展開用にパッケージ化せずに何かを実行したりする場合に備えて、管理者権限を持っている必要があります。
コンピューターはIDE、ソースリポジトリ、およびアプリに必要なアプリ/フレームワークを実行します。専用のコラボレーションツールまたは他の開発者固有のアプリが妥当です。
テスト中
テストネットワークでは、コンパイル済みの出荷可能なコードがテストされます。開発者は管理者権限を持っている可能性がありますが、通常のシステム管理者がアプリケーションを展開する必要があります。
デプロイには、管理者が内部アプリの本番環境で維持する内容を反映する必要があります。それらは、外部アプリ用の顧客対応パッケージ（インストールウィザードとデジタル署名を含む）である必要があります（ただし、事故のリリースを防ぐためのテスト目的で別の署名を使用します）。
開発者はシステムログとデバッグアクセスを必要とすることがよくありますが、これが管理者権限を持たなければならない唯一の理由です。絶対に必要な場合を除いて、インストール、構成、およびテストに関与しないでください。
製造
本番ネットワークは、クライアントとパートナーにサービスを提供する場所です。正式な導入プロセスが存在する必要があるため、開発/テストネットワークに接続する理由はありません。
インターネット経由のマルウェアや偶発的な変更のリスクを最小限に抑えるために、開発/テスト/ビジネスネットワークのアカウントは、可能であれば本番環境にアクセスできないようにする必要があります。
理想的には、このネットワークは完全に分離されていますが、実稼働サーバーが販売、請求、スケジューリング、netops、およびプロジェクト管理のためのシステムとインターフェイスする必要がある世界では、これは不可能です。できる限り理想に近づいてください。私たちにできることはそれだけです。
ビジネス
これは、企業の主要な通信ネットワークです。
電子メール、Webブラウジング、およびパートナー接続はすべて、多数のリスクをもたらします。開発、テスト、および実稼働ネットワークは、これらのリスクから可能な限り隔離する必要があります。
詳細、詳細、詳細
組織が行き過ぎた可能性があります。柔軟で安全なネットワークアーキテクチャに不可欠な無数の詳細に対処するよりも、振り子を完全に揺り動かす方が簡単です。
次の場合、開発者は企業へのリスクを最小限に抑えて、マシンへの管理者アクセス権を持つことができます。
- インターネットアクセスには、権限のない個別のアカウントがあります
- 各環境で一意のアカウントが使用されます
- 制限付きのファイアウォールルール/ ACLが環境間に存在する
- ファイアウォール、Webプロキシ、IDS/IPSなどの標準的なセキュリティ対策が実施されている
開発者には4つのアカウントが必要です。
- インターネット上のリソースにアクセスするための特権のない開発者アカウント（ビジネスネットワークとの間を行き来したくない場合は面倒です）
- ワークステーションとテストコードを構成するための特権開発アカウント
- アプリケーションをデバッグするための特権付きテストアカウント
- 電子メール、Web、イントラネット用の特権のないビジネスアカウント
開発者が検証やQA作業を行う場合は、テスト環境で非特権アカウントも必要になる場合があります。
開発者は、実稼働ネットワークにアクセスしたり、ビジネスネットワークの管理者権限を持たないようにする必要があります。今のところこれが不可能な場合は、それらの役割を分離するか、厳密な変更管理プロセスを導入する必要があります。
MS-Windows NTは当初からマルチユーザーシステムシステムでしたが、そのような方法で操作することは本当に簡単ではなく、開発者（Micosoftを含む）は依然として権限分離の概念を無視する傾向があります。この種のアクセス制御は十分に文書化されておらず、トレーニングでは機能しない傾向があり、UIを介してアクセスすることがしばしば困難であり、監査が困難であり、分離を適用するためのパターン/ツールがない...
公平に言えば、Unix/Linuxシステムであっても、多くの開発者が実際のユーザーとサービスの両方に適切に権限分離を使用できないことに気づきます。しかし、どのプラットフォームでも、実装者が特権を分離する方法で障壁を設けることは、完全な（ローカル）管理者特権を与えるよりも、セキュリティの面でさらに非生産的です。
一方、MS-Windowsでの開発についてはほとんど知りませんが、Visual Studioを実行するにはlocal-admin特権が必要なのは驚くべきことです。そして、あなたが管理者アクセスを必要とする唯一の理由が サービスの停止/開始 またはそれらを再構成することである場合、私はあなたに多くの同情はありません-ローカルにそれらを与えることなく指定されたユーザーにこの機能を提供することは可能です管理者。 IIS7の大きな変更の1つは、 委任管理者 機能でした。そして、Apache、MySQL、PHPの再構成を委任するのは常に簡単でした。
ローカル管理アクセスが削除されたときの短い通知がありました
問題は、セキュリティチームが提供できないレベルの能力を目指しているようです（これは、私の経験ではvery一般的です）。彼らは、適切な影響評価を行い、生産性/セキュリティへの危害に対する緩和策を検討することなく、ポリシーの変更を課すべきではありませんでした。
すべてのワークステーションに少なくとも2つの主要なウイルス対策プログラムがある
これは、これらのシステムの整合性を保護するための非常にナイーブなアプローチであり、対処しなければならないことの絵を描きます。
世の中には選択肢があまりないようです
それについての議論に入るのは、おそらく現時点ではあまり生産的ではないでしょう。
全体的に、まるで地元のセキュリティチームと競争しているように聞こえます。彼らはあなたがあなたの仕事をするのに必要なことを理解していません、あなたは彼らの目的を達成する方法を理解していません。そして、どちらの側も交渉する気がないようです。既製のツールでこれを修正することはできません。
開発者がそれらの特権を乱用するほど役に立たない/悪意のある企業、または「ITとセキュリティ」部門が、誰もいない人を見る無知な冗談ばかで運営されている企業の開発者に対して、ローカル管理アクセスを拒否するのは典型的なことです彼らの内側の輪は、見た目を悪くするための明らかなセキュリティ脅威です。
Windowsに完全に優れた無料のウイルス対策プログラムが付属している場合、「ITとセキュリティ」部門も2つのウイルス対策プログラムを義務付けていることを考えると、問題が組織のどこにあるかを特定し、そこから作業できると確信しています。