有能な開発者のための会社のコンピューター、それらをどのように扱うことができますか？

Question

これはフォローアップです会社のコンピュータを使用するように要求される正当な理由があります。主に、いくつかの特定の状況で大きな問題が発生するためです。

私が組織のセキュリティエンジニアの立場にあった場合、会社のコンピューターのみを使用するというポリシーを明確に定めます。これは理にかなっており、企業データだけでなく従業員の責任も保護します。

しかし、そのようなポリシーが私を悩ませる1つのケースがあります。有能な開発者（私はジュニア開発者について話しているのではなく、中高年レベルの開発者について話している）は潜在的に彼の作業マシンを持っています：

17個のデータベースエンジン。
20個のDockerコンテナ。
10個のテスト仮想マシン（qemuなどを使用するとします）。

これは、新興企業と新興企業（数年生き残った新興企業）で非常に一般的なシナリオです。さらに、この開発者はおそらく新しいテクノロジーをテストするため、毎週、Dockerコンテナーと仮想マシンを変更します。

この開発者にセキュリティエンジニアを紹介して毎回新しいソフトウェアをインストールするよう要求することは、完全に非現実的です。さらに、会社にはそのような開発者が複数いるため、一般的な会社が管理するすべての人のコンピュータを使用すると欠点が生じます。

たとえば、6人のそのような開発者のコンピューターを維持することは、有能なセキュリティエンジニアにとってフルタイムの仕事です。
チームの作業時間の50％がセキュリティエンジニアを待つことなので、これらの開発者のマネージャーはひどく怒ります。

一方、開発者がマシンを自由に使用できるようにすることは危険です。1つの不正なDockerコンテナまたは仮想マシンであり、内部関係者がいます。これらの開発者のコンピューターは、一般的なユーザー（たとえば、スプレッドシートソフトウェアを使用するマネージャー）よりもより危険であるとさえ言えます。

有能な開発者のための賢明なポリシーをどのように作成しますか？

ここに私が考えることができる（または過去に見た）他のいくつかの解決策があります、それらのほとんどはかなり悪いものでした：

開発マシンからのインターネットアクセスを禁止します。
- ドキュメントを読むにはインターネットアクセスが必要です。
- 多くの場合インターネット上にあるリポジトリにアクセスする必要があります。
開発者に、インターネット用と開発マシン用の2つのコンピューターを提供します。
- 生産性の低下に関する苦情：入力Alt+2ブラウザを取得する方が、別のコンピュータに切り替えるよりも高速です。
- リポジトリへのアクセスは面倒です。1つの場所でダウンロードして、他の場所にコピーしてください。
- セキュリティを回避して両方のマシン間をUSBベースの接続にすることを開発者に奨励します。これにより、開発者は1台のコンピューターから作業できるようになります（複数回発生することを確認しました）。
開発をサーバーに移動します（つまり、デスクマシンでの開発ではありません）。
- これは、同じ問題をより深く移動しているだけであり、不正なコンテナがサーバー上にあります。
- 開発者が自分のマシンで好きなことをできるようにするよりも間違いなく悪い。

もっと良い方法があるはずです。

paj28 · Accepted Answer

個別の開発と生産

開発者に自分のワークステーションのローカル管理者/ルート権限を与えることは通常の慣行です。ただし、開発者は開発環境にのみアクセスでき、ライブデータにはアクセスできません。運用にアクセスできるシステム管理者は、はるかに制御されたワークステーションを持つべきです。理想的には、sys-adminワークステーションがインターネットにアクセスできないようにする必要がありますが、これは実際にはまれです。

私が見たバリエーションは、開発者がロックダウンされた企業ビルドを持っているが、仮想マシン内で好きなようにできることです。ただし、VMはパフォーマンスが低下し、セキュリティ上の利点はそれほど大きくないため、これは開発者にとって煩わしい場合があります。そのため、開発者が自分のワークステーションに完全にアクセスできるようにするのが一般的です。

coteyr · Answer

したがって、この答えは開発者の観点からのものです。心に留めておきます。

まず、自分のマシンに「ローカル管理者」権限がないことは、他の場所で仕事を探す必要があることを示しています。新しい依存関係またはツールを更新（またはテスト）する必要があるたびに許可を求める必要がある場合、コードを記述し、さまざまな操作を行い、ツールチェーンを維持することはほぼ不可能です。それで、これが許可レベルIです必須。私は通常、はしごの上でかなり高い位置にいることを覚えておいてください。

ローカルマシン全体の完全な管理者
すべての開発およびテスト用ハードウェア全体の完全な管理者
本番サーバーへの管理者アクセスのある程度のレベル（これは注意が必要ですが、すべてを必要とするわけではありませんが、本番環境で発生する問題を診断して修正するのに十分であり、実際にコードをデプロイするのに十分です）通常、このレベルのアクセスは時間とともに進化しますが、ログファイルから始まります。

それより少ない場合は、新しい開発者を探すことができます。

とはいえ、そのレベルのアクセスには多くのリスクが伴います。したがって、私が通常お勧めするのは、別のネットワークです。すべての開発者の「もの」を独自のネットワークに配置します。独自のAD、独自のファイルホスティング、独自のすべてを備えており、運用ネットワークと通信することはありません。（ただし、インターネットに接続させてください）

はい、これはハードウェア（またはVPS）の複製を意味しますが、いずれにしてもテストにはそれが必要です。はい、それはアップグレードまたは管理時のオーバーヘッドが少し増えることを意味しますが、ここでもテストに必要です。また、「ADサーバーをアップグレードすると、Xソフトウェアはどうなりますか」を表示する場所も必要です。この種のテストに対応できるテストマシンのネットワーク全体が用意されていることを確認してください。

私が（優れたITチームの助けを借りて）正常に実装したものは、別のVLAN for all dev "stuff"と、devがフルアクセスできる単一のVPSホストで、そのホストには、ITによってセットアップされ、企業のADサーバーのより小さなバージョンのように見えるADサーバーがあります。次に、Webサーバーなどを実行するためのドキュメントとガイドラインのセットです。DNSサーバーとはxyzサーバーが実行するものを実行する必要があります。次に、「開発」の一部は、これらのVPSをインストールして使用するために構成することです。そのVLAN上のすべては、本番環境から完全に分離され、外部と見なされます最後に、アクセスする必要のあるアセット（メールなど）に一連の「パンチスルー」が作成されます。通常、これは外部にいるかのように処理され、これらのツールのリストは非常に少なかったです。

Ray · Answer

開発者の観点から：

あなたの仕事は変更を防ぐことです（既知のバグや脆弱性は未知のものよりも優れていますよね？）が、私のものは変更することです。これは私たちを行き詰まりに陥らせます。私の仕事は、物を作成/変更することです。あなたの方針がそれを妨げるなら、他の障害と同様に、私の仕事の一部はそれを回避する方法を見つけることです。

どちらがより危険だと思いますか、開発に必要なものへのアクセスを許可した開発者、またはすべての防御策を回避する方法を学ぶことによってそのアクセスを取得した開発者ですか？そして、あなたが協力しなければならないときに、なぜあなたとあなたの会社はあなたとあなたの開発者にこの戦争と戦うためにお金を払っているのですか？

簡単な答えは、開発者が仕事に必要なものにアクセスできるようにすることです。そして、彼らと話してください。より複雑なポリシーが必要となるまれな状況（主要な法的結果を伴うクリーンルームリバースエンジニアリング、または極秘機密データの取り扱い）がある場合があります。しかし、ほとんどの場合、それほど大きな問題ではありません。戦争を始めて開発者を敵にすると、彼らはあなたが彼らと協力する場合よりも離れるか、はるかに危険になります。

賢明な対策には、開発用ラップトップで本番データベースのダンプを許可しないことが含まれます（偽のデータを使用したデータベースのテストのみ）。そうすれば、ラップトップが盗まれても、機密データが失われることはありません。しかし、開発者がデバッグする必要がある場合でも、制御された環境のどこかにある本番データベースのコピーにアクセスする必要があります。

インターネットアクセスを制限するのはばかげています。また、開発者全員に羽ペンとインクで紙にコードを書くように要求することもできます。

開発者と話し合って、重要なデータを安全に保つために必要なセキュリティを維持しながら、仕事に必要なことを彼らに提供する方法を見つけてください。詳細は、会社と、処理しているデータによって異なります。しかし、それは厳格な措置を必要とする可能性は低いです。

Lucas Kauffman · Answer

セキュリティエンジニアはコンピューターを保守しません。それがサービスデスクの役割です。あなたの場合、あなたは彼に3つのツールをインストールするように要求します：

ハイパーバイザー
ドッカー
データベースソフトウェア

そこから、彼は好きなだけ開発用のマシンを追加したり削除したりできます（介入するためにセカンドエンジニアを必要としません）。あなたの「ローグコンテナ」に関して。一般に、コンテナーを別のサーバーにデプロイするのではなく、コードリポジトリからコードをプルするか、コンパイルされたコードの署名済みバイナリをダウンロードするDockerファイルをデプロイします（これはさらに安全です）。

不正の観点からは、攻撃者がアクセスしてコードを追加することしか想像できません。このため、SDLCのすべてのステップでセキュリティを組み込み、すべてのコードが少なくとも別の開発者によってレビューまたは通過される前に、ツリーをプッシュする必要があります。さらに、コードスキャナーを統合して、疑わしいまたは脆弱なコードスタブを自動的にスキャンすることもできます。

3番目の点では、それは実際に依存します。 Riot Gamesのような企業はまさにそれを行っています。彼らは、インテリジェントな個人を制限すると、それらの個人がコントロールを回避することにつながることがわかりました。そのため、彼らは簡単なルールと効果的な意識向上トレーニングを使用して、セキュリティを常に心に留め、完全な管理者権限を与えることにしました。彼らは、注意すべき点と注意すべき点を述べた小さなカードを配った。

Martijn Heemels · Answer

私たちは開発者に彼らのコンピューターへの管理アクセスを与え、彼らにルールが何であるかを知らせます。ほとんどはLinuxを実行していますが、Windowsにもいくつかの開発者がいます。彼らは全員、ドキュメントやデザインなどを（より具体的な権限を持つ）ファイル共有に保存し、ソースコードをGitサーバーにプッシュすることを知っています。

彼らはまた、私が彼らのOSの問題を修正するために多くの時間を費やさないことを知っています。彼らのコンピュータが誤作動した場合、私たちはしばしばそれを拭いてOSを再インストールします。一般的なアプリケーションと設定はPuppetを介して自動的にインストールされ、残りは自分で行う必要があります。それらのほとんどは、ドットファイル（環境の設定と設定）を含むGit-repoを持っています。

彼らがそのような場合に失う時間は、彼らのほとんどにとって十分な動機です。彼らはOSの修正をいじるのではなく、仕事をやりたいと思っています。ローカルでしか保存されていなかったために重要な仕事を失うと、同僚や上司から眉をひそめられます。

Webサイトやアプリケーション（DNSベースのマルウェア対策フィルターを除く）はブロックしませんが、違法なソフトウェアなどに関する企業ポリシールールがあります。私たちは、ほとんどの場合、仲間の圧力に依存しています。 Facebookで時間を過ごす人々は生産的ではなく、長続きしません。私たちのポリシーの多くは名誉システムに基づいており、それはうまく機能しているようです。

James_pic · Answer

これは基本的にコンテキストに依存します。次の2つの設定を考えてみます。どちらも私が実際に遭遇したものです。

開発者は、自分のオペレーティングシステムのインストールも含め、所有するマシン、または完全なアクセス権を持つマシンで作業します。アプリケーションの記述方法に制限はありません。 VPNを含むネットワークに接続されているときはいつでも、SSHで本番システムにアクセスできます。
すべての開発は、開発者が電子デバイスを持ち込むことを許可されていない、エアギャップ開発ラボで行われます。すべてのコンピュータには、許可されたソフトウェアがすべてプリインストールされています。展開可能なアーティファクトは、展開を担当する別のチームに物理メディアで安全に配信されます。

これらの設定はどちらも、組織が直面した脅威とプロジェクトのニーズを考慮して、状況に応じて適切でした。

ここには根本的なトレードオフがあります。最初の可能性から2番目の可能性に向かって移動すると、生産性が低下します。アプリケーションを制御できる人は誰でも信頼できる立場にいます。あなたが彼らに信用できないものは、あなたがそれなしでやらなければならないこと、または誰かが行うためのハンドオーバープロセスを作成することです。生産性を低下させずに信頼を取り消すことはできません。

mgjk · Answer

これは、開発しているソフトウェアの種類と組織の規模によって異なります。

小さな会社の1人のロックスター開発者のワークステーションでは、エグゼクティブレベルのセキュリティ例外を使用します。リスク（IT、エグゼクティブ、仲間の開発者の煩わしさを含む）について議論する必要がありますが、最終的には、ロックスターがうまくいかなければ、おそらく別の会社に移動するでしょう。これらの人たちは摩擦を許容しません、彼らがそれに遭遇した場合、彼らは簡単により興味深い職場を見つけることができます。

Uber-workstationよりも典型的なシナリオは、運用がVMの存続を管理する開発クラスターを持ち、環境はIDS/IPSで監視され、インターネットアクセス（開発クラスター上）は制限されていますが、必要に応じて開かれます。たとえば、ドキュメンテーションの場合...開発作業に関連するすべてのテクノロジーソースをホワイトリストに登録しても問題はありません。とにかく、開発者はコードを思い通りに取り込むことはできません。彼らはソースを文書化し、奇妙なライセンスを検証する必要があります。

あなたがロックスターの耳を手に入れることができれば、彼は要件をオペレーションとエグゼクティブにプッシュし、クラスターとプロセスを設計し、開発チームを必要に応じて教育するのを助けることができます。

予算があり、開発者が消極的である場合...私見、あなたはロックスターを扱っていませんが、歌姫と彼らの愚痴はそのエグゼクティブリスクのサインオフまで持ち越されるべきです。

難しいのはマシンの寿命を管理することと、開発者の後付けが「操作のような」開発者生産システムにならないようにすることです。しかし、これは開発者のワークステーション上のVMよりもはるかに簡単です。

Tim X · Answer

この質問は、いくつかの興味深い質問と課題を提起します。開発者として長年働いた後、セキュリティに移行した人として、応答やコメントで表明された多くの議論や見解を高く評価できます。残念ながら、正しい解決策は組織のコンテキスト、リスクへの露出、およびリスク選好度に依存するため、明確な答えはありません。

セキュリティは絶対的に測定できるものではありません。絶え間なく絶対的に話し、特定のポリシーを強制することを主張するセキュリティ担当者に遭遇したときはいつでも、経験不足または無能です。セキュリティエンジニアの役割は、ビジネスプロセスを促進することであり、プロセスを妨げることではなく、関連するセキュリティリスクによって通知されるビジネス上の決定が行われるようにすることです。優れたセキュリティエンジニアは、スタッフがポリシーを回避する方法を見つけるため、スタッフの仕事を妨げるポリシーは必ず失敗することを知っています。多くの場合、これらの回避策はさらに安全性が低くなります。組織内のさまざまな役割を理解し、ポリシーがその役割に必要なものをサポートするだけでなく、良い習慣を奨励し、悪いものを阻止するように構成されていることを確認するのは、セキュリティマネージャーの責任です。これは、特に大規模な組織では難しい場合があります。同時に、組織内の開発者やその他の人は、特定のポリシーが必要な理由を理解するために、関連するすべての情報がない可能性があることも認識する必要があります。多くの場合、開発者や他の人たちは、セキュリティエンジニアを、仕事を遂行するために何が必要かを理解していない障害または干渉する官僚と見なしています。

多くの場合、これらの問題に対処する方法はコミュニケーションです。開発者に無意味だと思われるいくつかのポリシーが邪魔になっているため、私は頻繁に開発者に不満を感じてきました。座って問題について話し合うと、通常、多くのことが起こります。

開発者がポリシーを誤って解釈したか、誤った仮定をポリシーに読み込んだため、ポリシーがそうでないものをポリシーが妨げていると考えられます。これは、多くの場合、明確さを改善するためのポリシーのレビューにつながります
セキュリティエンジニアは、適切なセキュリティ管理を維持する方法で満たす必要がある正当なビジネス要件に気づきます。これにより、ポリシーが見直される可能性があります。
開発者は、当初は明らかではなかった他の要件やリスクに気づきます。これにより、開発者は要件を満たすための代替ソリューションを特定することがよくあります
組織の許容されるリスク選好度（つまり、許容されるリスクのレベル）の範囲内の方法では、どちらの当事者も満足できるように解決できない問題が特定されます。この状況では、通常、問題が経営陣レベルにエスカレーションされて決定されます。これを行うことの難しさは、組織の規模と構造に依存します。決定が下されたら、開発者とセキュリティエンジニアの両方が、最高のソリューションを見つけるために、経営陣が設定したパラメータ内で作業する必要があります。

生産性のレベルに悪影響を与えるポリシーに批判的である多くの応答がありました。開発者はそのような懸念を提起する必要がありますが、結局のところ、彼らはエグゼクティブが下す決定を受け入れるか、または別の雇用者を探す必要があります。あなたがよりよく知っていると仮定したり、ポリシーを無視する特別な権利があると仮定することは、あなたとあなたの雇用者の両方にとって傲慢で危険です。あなたが正しいと確信しているなら、あなたは経営陣を説得することができるはずです。できない場合は、あなたが思っているほど良くないか、説得力のある議論を提示するための十分なコミュニケーション能力が不足しているか、すべての情報を所有していないか、または無能な雇用主のために働いています。業界で35年が経過し、ディルバートがあなたを考えるように導くかもしれないにもかかわらず、後者はあなたが期待するほど一般的ではありません。この分野での最も一般的な紛争の原因は、コミュニケーション不足と情報不足によるものです。

開発者（そして私が罪を犯している人）の間の一般的な失敗は、特定のタスクまたは目的に集中しすぎて、チームリーダー、マネージャー、および経営幹部も管理する必要がある全体像を見逃してしまうことです。開発者に多くの自由と信頼が与えられた結果、高レベルの生産性がもたらされたが、他の問題が発生した環境-主要な開発者が長期間病気になったり、病気になったりして他に誰もいない状況すべてが独自に構成および管理されたデスクトップ上にあるか、標準のセットアップ/構成がないために簡単に再現できない困難な問題をデバッグしようとしたり、開発者が誤って去ったために起こり得るセキュリティ違反に対処したりするため、開発中の標準的なセキュリティコントロールが欠けている実行中のサービス。特定のドメインまたはテクノロジーに焦点を当てた開発者であることは、他のすべての専門知識を保証するものではありません。私が今まで一緒に働いた中で最高の開発者の何人かは、環境のセキュリティや管理に関しては最悪のものでした。これは、おそらく部分的には特定の問題に焦点を当てているためであり、より単純には容量のためです。私たちの誰もがすべてを横断する能力を持っているわけではありません。私たちがそうではない領域を専門とする人々に委ねることが時には重要であることを認識する必要があります。

変化する環境

デスクトップで実行できることを制限するポリシーの主な理由の1つは、ローカルネットワーク内のデスクトップはネットワーク外のデスクトップよりも高いレベルの信頼を持っているという根本的な仮定によるものです。従来、これらはファイアウォールやその他の境界防御の内側にあり、情報リソースへの移動アクセス権を持っています。つまり、リスクが高くなるため、より多くのセキュリティ管理が必要になります。制限的なポリシー/慣行のその他の理由には、サポートコストを削減し、一貫性を高めることができる環境の標準化が含まれます（プラットフォーム/ OSに依存するアプリケーションが多い場合は特にそうでした-AtiveXまたは特定のバージョンを必要とするすべての恐ろしいアプリケーションを思い出してくださいIE）。

仮想マシンとコンテナ、クラウドサービスとコモディティITサービスの増加、およびネットワーク容量の増加により、このスレッドで発生した問題の多くが無関係になる可能性のある多くの変更が発生しています。特に、ゼロトラストネットワークへの移行には、大きな変化が見られるでしょう。ゼロトラストネットワークでは、ネットワーク内のデバイスは、ネットワーク外のデバイスと比較して、特別な追加の信頼レベルがあるとは見なされません。適切なIPアドレスを持っているからといって、リソースにアクセスすることはできません。代わりに、信頼はユーザーとデバイス情報の組み合わせに基づいています。アクセスできるものを決定するポリシーは、資格情報と接続元のデバイスによって決定されます。そのデバイスがどこにあるかは関係ありません。これは、BYODの増加と労働力の移動性の増加、地理的な場所ではなく敷居/能力に基づいてスタッフを雇用する要求の増加にはるかによく適合するモデルでもあります。

デバイスに関連付けられている「信頼」のレベルを削除すると、デバイスに適用できるものを制御する必要がなくなります。特定のプロファイルをサポートするためにデバイスが依然として必要な場合があります。たとえば、デバイスがWindowsを実行している場合、だれもがリソースにアクセスすることを拒否する可能性がありますXPなど。ただし、デバイスについてはあまり気にしません。同様に、デバイスで直接行う作業はそれほど多くありません。ある程度、デバイスはシンクライアントのようになります。リモートでホストされているVMとコンテナを使用します。これだけではすべての問題が解決されず、それらの一部をローカルデスクトップからリモートVMまたはコンテナに移動するだけのように見えるかもしれません。ただし、これをさまざまなDevOpsスタイルのオーケストレーションと組み合わせると、開発者が強化された特権を必要とする理由の多くはは削除されます。たとえば、本番システムへのアクセスは必要ない場合があります。新しいコードのプロモーションは、調整された継続的インテグレーションシステムを通じて処理され、問題をデバッグする必要がある場合は、VMまたはプロダクションの正確なクローンであるコンテナシステム。

これらの変更のどれも魔法のように何かを解決することはありませんが、潜在的にそれほど複雑ではない、より柔軟なツールとソリューションの幅広い範囲を提供します。複雑さを軽減すると、セキュリティ管理がはるかに容易になります。セキュリティ管理が容易になると、業務を遂行する上での意図しないまたは不必要な制限や障害が少なくなります。ただし、結局のところ、重要な要件は

1つのサイズがすべてに当てはまるわけではないことすべてによる認識。組織の文脈の中ですべてを評価する必要があります。
組織のニーズを最優先する意欲。
良好な双方向通信。
すべての当事者が相互に受け入れ可能であり、かつ解決できる解決策に取り組む意欲
すべての当事者が妥協する意欲
システム内で作業し、組織の要件に合うようにワークフローまたは優先する方法を調整する意欲

Lucas · Answer

私は開発者でもあり、ここに私の意見があります：

問題はあなたが考えるよりも悪い

スプーンはありません

開発はソフトウェアではありません。開発とは、製品、サービス、プロセスを作成または改善することです。ソフトウェアは重要なギアですが、それだけではありません。優れた開発者は、どのソフトウェアコンポーネントを作成するか、またどのヒューマンロジスティックスリスク管理プロセスを提案するかを知るために、より広い意味でプロセスを定義します。実装されていない人間、ロジスティック、紙のプロセスに依存するソフトウェアシステムを開発しても意味がありません。

開発はルールを定義しているため、開発にルールはありません。これが、開発をセキュリティで保護するための最悪の環境にしている理由です。

しかし、それは一部の統制が確立されるべきではないという意味ではありません。それどころか、多くのコントロールは開発チーム自身が設定する必要があります。

エンジニアリングプロセス

トップダウンプロセスでビジネスとテクノロジーの分離を主張する企業があります。これは実際に非常に人気があります。なぜなら、技術的な知識を持たないビジネスマンがトップであるべきだと示唆しているからです。 怠惰な人々はそれが大好きです。しかし、エンジニアリングでは、トップダウン設計は単に機能しません。 Feyman（1985）大統領委員会でチャレンジャーの爆発を分析した記事について、素晴らしい記事を作成しました。基本的にトップダウンプロセスのエンジニアリングは、最終的に会社を壊します。そして、私の市場経験はこの理解を強化します。

チャレンジャー爆発はその好例です。 Nasaのマネージャーは、氷点下60度未満でも柔軟性を維持できるゴムを開発したことを調査委員会でカメラで証言しています。委員の1人が行った簡単な高校の物理実験（クランプで押された氷水にゴム成分を入れます）と矛盾したもの。このゴム部品はブースターが爆発しないように柔軟である必要があるため、良い例でした。それを行うには夏の気温が必要だったので、ブースターは夏にしか機能しませんでした。単一のコンポーネントの特性は、製品全体の目に見える特性を定義し、非常に制限的です。

エンジニアリングはボトムアップで行う必要があります。プロセスを精緻化してそれらを軽減するには、各コンポーネントの制限と弱点を知る必要があるからです。多くの場合、緩和プロセスはソフトウェアではなく、製品のコストに影響します。個々のコンポーネントの特性と制限により、製品、サービス、プロセスの特性が定義されることを意味します。

トップダウンプロセスは根本的に壊れています。紙にこの哲学を採用する多くの企業は、まだいくつかの市場での成功を収めています。しかし、ダウンして、彼らの大きくて最も成功したプロジェクトを調査すると、彼らは通常の会社の規則の外で実施されたことがわかります。エンジニアリングに関する深い知識と市場に関するビジョンを持つ1人が非公式に権限を与えられると、最大の成功が得られます。これは非公式に行われるため、経営陣はトップダウンプロセスが機能すると考えています。彼らは他のすべてのチームが無能であることをブランド化します。「トップフェーズ」を去ったときの最初のプロジェクトの概要が完全に無視され、構築された製品、サービス、およびプロセスを記述していないという事実に目を向けません。

マネージャーは、月末までにテレポートデバイスを設計することを定義できます。これにより、旅行ビジネスで高い利益が得られると結論付けましたが、それでは実現しません。トップダウンプロジェクトはそのようなものであり、技術的に適切ではない期待を設定します。

誤解しないでください。多くの角度から問題を見るのは良いことです。ボトムアップ、トップダウン、SWOTなどは分析に適していますが、真のエンジニアリング作業はボトムアップです。技術的な実行可能性がなければ、真の目標はありません。

開発セキュリティ

ソフトウェア開発者は会社のソフトウェアを定期的に変更することを覚えておかなければなりません。それにより、誰でも画面に表示される内容を変更したり、自動メールを自分自身を含むすべての人に送信したり、バックドアを開いて彼らがやりたいことをする。開発者として雇われた犯罪者が会社に重大な損害を与える可能性があることを意味します。

それよりも最悪の場合、ソースコードリポジトリの証拠を強制しない企業が多く、採用された開発者は、指定されたソースとは異なるバイナリを提供できます。これにより、犯罪者の開発者は会社のシステムをハイジャックすることができます。彼らが雇われなければ、物事はすぐに機能しなくなります。

私にとって、開発セキュリティは以下に焦点を当てるべきです：

ソースコードのバージョン管理：必要なソースコードとサードパーティのコンポーネントが安全な場所に保存されるようにします。
分業戦略：ジュニアおよびテンポラリーの開発者は、ソースコードとデータへのアクセスを制限する必要があります。ジュニア開発者がすべてのシステムの内部の仕組みを理解し、それを利用できるようにするために、変更するコンポーネントにアクセスするだけで済みます。
コア開発者を信頼する：シニア/コア開発者は、すべてを知っていて、すべてにアクセスでき、タスクを計画して配布し、深刻な問題を診断する必要があります。このコアは、開発と本番の両方ですべてにアクセスできる必要があります。彼らは、セキュリティポリシーの開発におけるあなたのパートナーです。コア開発者が会社を所有していることを受け入れる必要があります。私の古い上司は、「私たちは幸運なことに、ルーカスが私たちの側にいて、反対側にいると彼は私たちを破壊するだろう」と言いました。コア開発者は、必要に応じて多くの損害を与える可能性があり、それを防ぐことができるファイアウォールと本番管理はありません。
ファイアウォールを介して環境を分離する：開発ネットワークをテストネットワークから本番ネットワークから分離します。会社でネットワーク10.1を定義しました。開発として、10.2テストおよび10.3として。生産として。 10.2および10.3ネットワークは、企業のCVSを介してのみコードを受信し、adminコマンドで自動的にそれらを構築します。それは小さなスタートアップであり、私はプロダクションチームと開発チームにいましたが、私自身の過ちを回避するためにいくつかの官僚機構を作りました（開発者はあなたの最高の味方になることができます）。また、ネットワークごとに端末の色を変更しました。本番サーバーに接続すると、端末の背景は赤、テストは黄色、開発は緑でした。私のサーバーはすべて同じ構成を使用していたため、プロンプトが開いていると混乱しやすくなりました。私の経験では、ほとんどの問題は、テストが不十分なソフトウェアと新しいソフトウェアのインストールに起因しています。明確にするために：私の意見では、あなたはどこにいるのですか？アクセスとは関係ありませんが、セキュリティです。
熟練したテスト開発者を雇う：テストの重要な側面は、企業が直面する問題にとって意味のある、大量の適切なシミュレーションデータを用意することです。モンテカルロシミュレーションは、他の開発者にとって意味があり、より強力で回復力のあるソフトウェアとプロセスにつながる可能性のある大きなデータセットを生成するのに適しています。私には「本番」の障害はありません。開発者は常に責任があります。メンテナンスタスクと不測の事態を記述する必要があります。ソフトウェアは弾力性がなければなりません。
ソースコードのレビュー：変更を受け入れる前に、ソースコードをレビューしてもらいます。すべてのプロジェクトはソースコード管理で分岐し、マージを確認する必要があります。ソースコードのレビューは、マルウェアの検出、アクセスのエスカレーション、アクセスプロファイル、およびソースコードが何を意味し、何をすべきかについての適切な説明のみを気にする必要があります。コードの品質は、ソースコードのレビューではなく、テストによって保証されます。これは、ほとんどのオープンソースプロジェクトで実際に動作しています。
テストポリシーテストは、フレームワークというよりも企業文化です。一部の企業は市場フレームワークを採用し、いくつかのテストを行っていますが、そのコードの品質は悪いです。これは、有意義なテストを設計できる人材が必要なために起こります。実際、開発はテスト駆動になる必要があります。他に安全な開発方法はありません。そして興味深いのは、人間、購入、コンサルティングのすべてもテストする必要があるということです。ベンダーは自社の製品が完璧に機能すると主張することがよくありますが、完璧な製品はまだ見つかりませんでした。
ポリシーは監視されなければ意味がありません。私が知っている1つの会社には、すべてのデータベーステーブルに属性レベルの説明が必要であるという官僚制があります。属性の95％は、「$ {table name}の$ {attribute name}」と記述されています。属性が実際に何であるか、どの値が保持されるかなどについては説明しません。
適切な報酬と作業環境。スキルと性格の両方で優れた開発者を獲得するには、優れた報酬ポリシーが必要です。もちろんお金は重要ですが、十分ではありません。また、見通し/安定性、真の認識、および良好な作業環境も必要です。たとえば、人々が小さなアパートに住んでいるニューヨークの開発オフィスの代わりに、同じ補償でより大きな家と仕事へのより近くを可能にする小さな都市を選択できます。より大きなコンピューター、優れた実験室は、テクノロジー愛好家にとってもプラスです。
データセキュリティ多くのアクティビティには機密の本番データが必要であり、特別なラボでアクセスする必要があります。情報が公開されている場合や機密情報でない場合を除いて、物理的なアクセスが制御された適切な場所にラボを配置するのがおそらく最善のポリシーです。一部のシミュレートされたデータのみを、機密性のない個人のラップトップおよびコンポーネントに置くことを許可します。それは可能です。たとえば、私は、45億レコードの、アクセス頻度の高いデータアーカイブを企業向けに開発しました。私は自宅でそのために会社のデータをまったく使用しませんでした。コードを送信したところ、最初の試行で期待どおりに機能しました。ハードウェア障害と本番環境の移行を除いて、10年間で100％の可用性を実現しています。開発者がソースコードを持ち歩くリスクは関係ありません。この特定のシステムの開発には3か月かかりましたが、この時間の大部分は、コンポーネントのパフォーマンスの制限を理解することでした。これは私の頭の中の知識です。ソースコードがなくても、このソリューションを約1週間で再開発できます。
強力なログは、何かをした全員を知るために重要です。ここでの最良の方法は、フレームワークによって生成されるログ、短時間の詳細画面のログ、長時間のアクセスとアクティビティのログ、さらには企業ログです。画面にアクセスするたびに重要なシステムログを記録します（画面のデザインを含む）。重要なリソースの一部は、データベース自体のトリガーによってログに記録する必要があり、重要なテーブルまたはリソースには、ソースコード監査のフラグを設定する必要があります。
-ログスクリーニングは手作業で行うのは困難です。重要なことを確認するためにログにフィルターをかける方法を学びます。非常に便利なフィルターの1つは、苦情レポートとユーザーアクセスおよびアクティビティをクロスさせることです。十分なログがある場合は、偶然が表示されます。たとえば、問題が発生する前に、user1は常にログインします。

プロダクションにアクセスしないことについて

開発者がコードを送信して自分のユーザーの特権情報を表示しないようにするために、ユーザーがいるので開発者が本番システムにアクセスしないことを要求するルール。これは非常に弱いセキュリティ対策であり、ソースコード監査で簡単に検出できると思います。それを回避する簡単な方法がいくつかあります。

開発者と1人の低賃金の従業員。
自分に電子メールを送信します。
システムのバックドアを開きます。

バックドア、アクセスのエスカレーション、マルウェアを探すソースコード監査は、より生産性が高いようです。それは彼らが彼らのエクスプロイトをテストしているときに悪い開発者を特定してそれらを解雇することを可能にします。もちろん、熟練した開発者はエクスプロイトを一目で隠すことができるため、言語と変数名をわかりやすく使用することが重要です。特別なパフォーマンスまたは難読化を必要とするアプリケーションの文書化されたポイントでのみ、奇妙なソリューションに頼ってください。たとえば、1 << 4は1 * 16と同じです。これは、言語自体がこの最適化を行わず、それが発生するポイントがパフォーマンスのボトルネックである場合にのみ意味があります。シンボリック言語が多すぎると、これと同じ理由で良くありません。ソースコードは、どのオタクでも読めるようにする必要があります。

問題はあなたが考えるよりも最悪です

開発者が引き起こす可能性のある最も簡単で最悪の損害は、ツールのインストールとは関係ありません。開発環境が管理されている場合でも、会社が強力なファイアウォール、ソースコードリポジトリ、ソースコードリポジトリとコードレビューのみに基づくビルドを備えていなければ、ほとんど違いはありません。

TTT · Answer

私はコンサルタントとしてさまざまな会社で働いてきましたが、そのうち2社だけが開発者にマシンへの管理者アクセスを許可していませんでした。 1つは小さな会社、もう1つは非常に大きな会社でした。

小さな会社で私は管理者アクセスを要求し、その理由を約60秒間説明し、すぐに与えられました。

ある大企業で、管理者アクセスを要求しましたが、彼らは私がそうすべきであることに同意しても、会社のポリシーはそれを禁止し、変更することはできないと言われました。それで、IT担当者の1人がやって来て、私のマシンにローカル管理者アカウントを作成し、それにパスワードを設定してもらいました。それ以来、管理者になる必要があるときはいつでも、ローカル管理者としてマシンにログインしたり、runasを使用してVisual Studioを起動したり、管理ユーザー（IISなど）で実行する必要があるサービス/アプリケーションを起動したりできます。これは、組み込みの「管理者として実行」を選択するよりも悪くありません。幸いなことに頻繁に発生することはありませんが、それはわずかに遅いです。

Ivan · Answer

ここでのより大きなセキュリティ問題は、マルウェアではなくIPの流出であることを覚えておいてください。後者に対処するためにIDS/IPSを配置して、問題のないものにすることをお勧めします。

以下の条件が整っていれば、開発機器への管理者アクセス権を付与してもかまいません。

Anti-eDLP（ネットワーク、USBなど）
IDS/IPS
MITM NTLM認証済みの企業プロキシ。すべての接続を強制し、DLP違反を監視します。
デスクトップ上のすべての仮想化ソフトウェアを拒否します。 VMが必要な場合は、マネージドクラウドからVMをプロビジョニングします。これにより、すべてのVMが、上記のツールを使用して、古い標準化された同じイメージを実行します。
ネットワークレベルでの外部ソフトウェアリポジトリへのアクセスをブロックします（これは、pip、git、maven、apt、yast、zypper、その他すべてを不自由にします）。
Github、codeplex、および他の150のコード共有サイトすべてへのアクセスをネットワークレベルでブロックする
ネットワークレベルですべての9000以上のファイル共有サイトへのアクセスをブロックする
P2Pへのアクセスをブロック...など...

私の雇用主はこれ以上のことすべてを行います。とにかく、かなりの数の同僚が、自宅で時間外に自分の個人用機器を開発し、サイドチャネルを介してフェンスを越えて、障害のあるインフラストラクチャを迂回するだけにしています。個人的には、とにかく私を解雇するようなことをするために文書化されていない追加の20時間を無駄にするよりも、飲酒と犬の鎮静剤の過剰摂取の夢を見ながら夜を過ごしたいです。

コンピューターサイエンス（ひいてはソフトウェアエンジニアリング）を科学と見なします。科学実験は無菌状態で行われ、変数を制御下に保ちます。環境要因のために物事が期待どおりに機能しない障害のある環境で開発することは科学的ではありません。経験から言うと、うまく設計されたソフトウェアをそこから得ることはできません...社内で開発されたものはすべて壊れており、サードパーティのソリューションへの支出が増えます。

開発者は、開発に無菌環境が絶対に必要です。さまざまなセキュリティ制御によってgremlinsが開発および本番環境アーキテクチャに導入された回数はわかりません。したがって、管理された無菌のクラウドベースの開発環境が本当に唯一の方法です行く。「それは実験室で機能しました、問題は外的なものでなければなりません。」

プロビジョニングを許可するVMが貧弱でないことを確認するだけでよく、OpenStackまたはAWSでプロビジョニングプロセスを自動化して、開発者がスケーリングのニーズを満たすために何日も待たないようにする必要があります。それらすべてを集中管理することで、大量の監査制御が可能になり、率直に言って、開発者が自分の機器で行うよりもパフォーマンスが向上します。

Tyler Durden · Answer

私はオプション＃2のファンです：別のコンピューターを持っています。

専有情報を備えた会社のマシンをインターネットに接続できるようにすることで、ハッカーへの扉が開かれます。また、従業員が違法な目的で会社のデータを盗み出すことがはるかに容易になります。

従業員がインターネットリソースにアクセスするために特別なマシンを使用する必要がある場合、非常に安全なデータの侵入と漏洩の制御されたパスが作成されます。また、私が今行っているように、従業員がWebをむやみにブラウジングしたり、インターネットフォーラムで時間を浪費したりするのを防ぎます。

Drunken Code Monkey · Answer

管理者として、この問題はSaaSアプローチによって完全かつ完全に解決されます。すべての異なる環境を仮想化し、クライアントの数に適したサーバーラックに配置して、リモートアクセスを構成します（ RDP、ターミナルサービス、またはその他...）これですべてがサーバー上にあり、すべてのユーザーに対して維持する必要があるのは、各環境の1つだけです。