開発者に自分のPCの管理者権限を与えることのリスク
社内のIT部門を説得して、新しい開発者チームに自分のPCの管理者権限を与える必要があります。これはネットワークにセキュリティリスクをもたらすと彼らは考えているようです。なぜこれが起こるのか誰でも説明できますか？リスクは何ですか？ PCにソフトウェアをインストールする機能を必要とする開発者のために、IT部門は通常何を設定しますか。
この質問は今週のITセキュリティ質問でした。
詳細については、2012年6月8日ブログエントリをお読みください。または自分で送信今週の質問。
私が（契約開発者として）働いてきたすべての場所で、開発者にはデスクトップのローカル管理者権限が与えられます。
理由は次のとおりです。
1）開発者ツールセットは非常に定期的に更新されることがよくあります。グラフィックライブラリ、コードヘルパー、ビジュアルスタジオの更新。彼らはインストールする必要のある更新をほぼ毎週出すことになります。デスクトップサポートは通常、すべての開発マシンに更新されたソフトウェアをインストールするために毎週20チケットを取得するのに非常に疲れています。
2）デバッグ/テストツールが機能するには、管理者権限が必要な場合があります。管理者アクセスがないことは、開発者がコードのデバッグ作業を行うことができないことを意味します。マネージャーはそれを好まない。
3）開発者はセキュリティを意識する傾向があるため、危険なマルウェアを実行/インストールする可能性は低くなります。明らかに、それはまだ起こりますが、すべての開発者は通常、作業を実行するために、より高いレベルのアクセス権を持っていると信頼できます。
これは、開発チームが開発を期待されているソフトウェアの種類に一部依存します。ソフトウェアの種類によっては、管理者権限がなくても開発しやすいソフトウェアもあります。
たとえば、多くの管理者権限を必要とせずに、すべてローカルでインストールされた（通常はポート8080でテストされた）Mavenアーティファクトを含むEclipseなどを使用して、かなりの量のWebベースのJava開発を行うことができます。 （特定のポートを開く必要がある場合があります。）ハードウェアへのアクセスを必要とするツールの開発は、管理者権限なしでは不可能であることが判明する可能性があります。これは、Web開発の場合でも、最初からテストマシンを再構築できるようにすることをお勧めします（通常はVM）。管理者権限が必要な場合があります。
これが信頼に関するものである場合（つまり、開発チームの一部のメンバーが悪意を持っている可能性がある場合）、とにかく問題があります。特定の権利を承認または拒否するシステム管理者が、自分が書いたコードが何をしているかを詳細に確認できる可能性は低いです。もちろん、開発チームに本番環境サービスへの無制限のアクセス権を与えたり、必要以上のマシンで管理者アクセス権を与えたりする必要があるという意味ではありません。リスクを軽減するメカニズムを用意することは良いことですが、組織が機能するには、ある程度の基本的な信頼が必要です。開発チームを別の物理ネットワークに配置することは、信頼の問題や起こり得る間違いを軽減するための最初のステップです。
管理アクセス権を持つ誰かがいることによる典型的なリスクは、ネットワーク上のパケットをキャプチャできることです。これは、開発されたものの性質によっては、受け入れる必要があるリスクです。 Wiresharkなどのツールは、開発に役立つ場合があります。組織内でも、ITまたはIT以外の人々は、可能であればSSL/TLSを有効にしてサービスを使用する必要があります。これにより、盗聴やMITM攻撃を防ぐことができます。
開発者に管理者アクセスを与えない場合、いくつかの欠点を考えることができます（本当に必要ない場合を除きます）。
それはあなたの組織の開発者とシステム管理者の間に「彼ら対私たち」の文化を作り出すかもしれません。これはすでに多くの場所に存在していますが、一般的には良いことではありません。各チームは、他のチームを苦痛と見なす可能性があります。セキュリティは純粋に技術的な問題ではなく、人間の相互作用の問題でもあります。人間との良好なコミュニケーションは、実際のセキュリティの観点からだけでなく、組織全体の全体的な目標にも役立つはずだと思います。 （私は常に直接話すの後、顔のないチケットに返信するのではなく、問題を解決する必要があるシステム管理者に、より良い解決策を見つけることができることを発見しました。）
人間の本性は、人々が限られたときに創造的になるようなものですが、必ずしも正しい方法ではありません。開発者は、組織内で課せられた制限を回避するためにかなりの労力を費やして（多くの場合は成功して）しまうことに気付くでしょう。彼らは代わりに彼らが何をするつもりであるかについて彼らの創造性を使うべきです。
ITシステムは複雑であり、デバッグは暗い芸術です。ライブラリXYZバージョンa.b.c_13およびa.b.c_24に対して製品をデバッグする必要がある場合、開発者は各バージョンをインストールおよびアンインストールできる必要があり、管理者アクセスが必要になる場合があります。バージョン番号に依存するバグを追跡することは、すでにそうであるようにすでに迷惑です。チケットを上げて、誰かが正しいバージョンをインストール/アンインストールするまで（おそらく数時間または数日）待つ必要がある場合、それは悪夢になります：「彼らと私たち」の文化的な問題が増加し、さらに重要なことに、コストがかかります組織にもっと。これは、リスク/コスト評価の観点から考えることができます。
リスクはアクセスの増加する機能です
ITチームの同僚の恐れを説明するリスク計算の単純なルールがあります。オペレーティングシステムへのアクセスが多いほど、エラーや攻撃の影響が大きくなります。
たとえば、同僚の1人、たとえばボブが標準的なフィッシング攻撃で攻撃された場合、ボブアカウントはサイバー犯罪者が利用でき、数分以内にインターネットで販売されます。 Bobアカウントに管理者権限がある場合、このアカウントを使用してインターネットに大規模にスパムを送信し、フィッシング攻撃で他のアカウントを大規模に盗むため、非常に迅速（数分以内）にあなたのバックドアが開かれます。ネットワーク（Bobアカウントは管理者アカウントであるため可能です）（ssh、VNC、VPN...などのツールを介して）BobのPCの完全なリモートコントロールを許可します。 。内部PCから、特権アカウントから開始されたこの攻撃は、ファイアウォールを破壊し、ウイルス対策、スパム対策保護を停止することができます。
悪が中にある。
あなたの最高のネットワーク管理者、システム管理者、またはセキュリティ管理者でさえ、この破損したPCを何ヶ月も放置されないままにする可能性があります（Stuxnetを参照）。
誤ったリスクの軽減
開発者の同僚が作業しているOSの管理に長けていて、コンピューターに物理的にアクセスできる場合、このリスクの違いはゼロです。
任意のOSのエンジニア
管理者権限を自分に付与できる
彼がコンピュータに物理的にアクセスできる場合。
任意のOSで管理者アクセスをブロックすることは、管理者特権と通常のユーザー特権を区別できないユーザーにとって有効なリスク削減アプローチです。ここに私があなたの開発者チームの同僚に尋ね、彼らのリスクの認識に基づいて行動する重要な質問があります：
「許可された場合、何を処理しますか
OSの管理者権限？ "
リスクを認識するのに十分であれば、必要なアクセスを取得するのに十分です。その場合、この管理者アクセスを拒否してもリスクは軽減されません。注意：彼らが簡単に取得できるアクセスを拒否すると、会社全体として付随的なリスクがあります：彼らはそれを汚い方法で行い、彼らは無法者として振る舞い、彼らは助けを求めることができなくなり、彼らは彼らを助けますあらゆる事故をカバーする必要があります。
あなたは彼らに彼らのワークステーションと彼らが望む他のものへのローカル管理者権限を与えます。開発環境は常にメインネットワークから分離されています。開発者の環境でメインネットワークに害を及ぼさないようにしながら、必要なセットアップを提供することはITの仕事です。事前に計画を立て、経営陣と協力して、これを達成するために必要な機器/ソフトウェアを購入します。
以前の回答やコメントで言及されていないいくつかのことは、最小限の特権で作業している開発者にとって議論になるでしょう：
作業している業界によっては、従業員が自分のワークステーションで特権を昇格することを制限する法的または規制上の理由がある場合があります。開発者への管理アクセスを許可すると、組織がコンプライアンス違反のリスクにさらされる可能性があります。
昇格された特権でコンポーネントが開発されると、それらの特権を持たない他の環境への展開中に障害が発生するリスクがあります。開発者は、他の環境には存在しないローカルマシンに誤ってライブラリをアップグレードまたは追加した可能性があり、コンポーネントはそれらのライブラリの特定のバージョンに依存している可能性があります。また、コンポーネントが他の環境で実行されるユーザーアカウントには、高度な権限で作業する開発者が想定した必要なデータベースまたは他のアクセス権がない可能性があります。これは過去に何度も見られました。展開が失敗した理由が明らかな場合もあれば、そうでない場合もあります。解決できない場合は、すべてをロールバックする必要があります。
開発者がオープンソースツールまたはライブラリをインストールして開発に使用する場合、特に「コピーレフト」の条件がライセンスの一部である場合、開発したソフトウェアの最終的な配布方法に意図しないライセンス制限が生じる可能性があります。オープンソースのツールやライブラリの使用には何の問題もありません。それは意図的なものにすぎません。開発者は、ライセンスに厳密なコピーレフトの条件があり、実際には読む前に使用していないオープンソースコンポーネントを使用したため、配信時にすべてのソースコードをコミュニティにリリースする必要があることを納品時に知りたくないそれをインストールしました。
私が見てきたことの1つは、開発者に最小限の特権で作業してもらい、指定された期間、管理者特権を要求できるようにすることです。次に、この「ファイアコール」要求は昇格された特権を要求し、記録して監視し、要求された時間の終わりに自動的にリセットされます。
答える質問がいくつかあります。
- これらの開発者が毎日使用する必要のあるアプリケーションには、管理者特権が必要です。これらのアプリケーションをセットアップして、そうでない場合はありますか？
- これらの開発者が日常の簡単なタスクを実行するために管理者特権を必要とする理由は何ですか？これを回避する方法はありますか？
- これらの開発マシンはインターネットに接続されていますか？
質問は、リスクとは何かではなく、開発者が管理者アカウントを作成する必要がある理由は何であるか（答えることができます）にする必要があります。 「パワーユーザー」アカウントを使用して、必要なことを正確に実行できるようにするだけでなく、ネットワークに害を及ぼす能力を制限することもできます。
これらのマシンがインターネットに接続されている場合、これらのマシンに何かを実行したりインストールしたりする能力があるため、大きなリスクが発生します。これらの開発者はよく開発者であり、セキュリティの専門家ではありません。ネットワークをマルウェアにさらすミスを犯すかどうかは問題です。
たとえば、Googleを見てみましょう。 Googleの従業員は、MSNメッセンジャーウィンドウに含まれるリンクをクリックし、Microsoftによって既に修正されているエクスプロイトを利用するマルウェアをダウンロードし、ネットワーク全体に感染しました。
リンクをクリックしてGoogleの従業員がこの質問とは何の関係もないことを追加する必要があります。それは指摘することでした。人々は間違いをするので、公開者を制限します。
開発者がコンピュータをインストールする機能を提供することに関連するセキュリティリスクは多数あります。これが私が反対する理由です（システム管理者として話す）
1）セキュリティのベストプラクティスの潜在的な違反-セキュリティの8つのルールの1つは、最小限の特権のルールです-従業員には、タスクを完了するために必要なものへのアクセスのみを許可します。誰かが彼らの仕事をするためにソフトウェアをインストールするために彼らの開発者には管理者アクセスが必要であると私に言ったなら、私は「なぜ私のスタッフの一人が彼らのためにそれをインストールできないのか？」ソフトウェアのインストールを一元化することにより、IT部門はどのソフトウェアがどのマシン上にあるかを正確に把握できます。
2）法的理由-おそらく、開発者の1人が立派な倫理を下回っており、海賊版ソフトウェアをインストールすることにしました。そのソフトウェアはおそらくマルウェアだらけであるだけでなく、コンピューター上の海賊版ソフトウェアに捕まった場合、訴訟のためにワームの缶を開けます。 IT部門はそれらのコンピューターに対して責任があると見なされ、そのため、コンピューターを監査し、ライセンスが各ソフトウェアのTOSに準拠していることを確認する責任があります。 IT部門に迷惑をかけずに独自のソフトウェアをインストールできるという点で、開発者にとっては便利ですが、IT部門のために多くの作業を作成します。
3）マルウェアの意図しないインストール-前述のとおりですが、これは十分に無害な場合があります。マルウェアをインストールできるようにユーザー権限を昇格させると、感染したPDF電子メール経由で取得したファイル、またはダウンロードによってドライブを開いて、マルウェアの影響を受けやすくなります。ユーザーがアクセスできないように制限してください。ソフトウェアをインストールすると、マルウェアの脅威を軽減するのに役立ちます。
4）悪意のある活動-ポイント2と同様ですが、開発者の1人がバックドアをインストールしたり、ネットワーク上の別のセキュリティ脅威を意図的に開いたりすることはありません。彼らが解雇されたり、上司が怒り狂ったりした場合に、多くのIT専門家が復讐のためにこれを行うことに驚くでしょう。
全体として、私はそれに反対しなければならないでしょう。ソフトウェアをインストールすることでITに常にバグが生じるのを防ぐことで時間を節約できると人々は主張するかもしれませんが、私は「ユーザーが自分のソフトウェアをインストールできるようにすることによって生じるセキュリティホールをパッチするよりもそれを行うのにかかる時間は短い」と反論します。 。これがISが必要であると考えられる場合、それらは実際には外部の世界に直接アクセスできないネットワーク上に置かれるべきです。
回避策は、ドメインに接続されていない仮想マシンをインストールすることです。それはかなり面倒ですが、それは政策によって完全に不自由になるよりはましです。