答えは次のとおりです。共同開発のオンラインサービスに登録する（GitHub、Slack、Evernote、Wunderlist ...）。 しかし、大企業が、たとえば顧客データや財務情報を扱っていて、インターネットサービスで信頼できない場合はどうでしょうか？ 唯一の解決策は、ネットワーク内に分散開発インフラストラクチャを展開することです。
しかし、速度と利便性を損なうことなく、データとプロセスの安全性を確保するためにこれをどのように行うのでしょうか？ この記事ではこの質問に答えようとします。
この記事ではネットワークテクノロジーや情報セキュリティに焦点を当てないことをすぐに予約したいと思います。これには多くの専門文献があります。 むしろ、許容できるレベルのセキュリティの脅威でユーザーの利便性を最大化するためにこれらのテクノロジーを使用する原則について説明します。
典型的な大企業インフラ
最初に、典型的な大企業のネットワークインフラストラクチャが通常どのように見えるかを説明します。
本社があり、そこに経営陣、主要な従業員、貴重な情報を備えたデータセンターがあります。 すべての職場は本社の企業ネットワークに接続されており、データセンターサーバーも本社ネットワークに接続されています。 他の都市の支社のサブネットは、物理的/多くの場合仮想チャネルを介して本社ネットワークから接続されています。
企業ネットワークからでも、インターネットアクセスはほとんどの場合制限されているか、完全に無効になっています。 セキュリティ上の理由と、従業員の労働時間に関する「注意」のため。 この制限は、フィルタリングプロキシサーバー、またはインターネットにアクセスできるブラウザーが開かれているセキュリティで保護されたサーバーのリモートデスクトップを通じて機能します。
一般的に、典型的な大企業では、従業員がオフィスを離れた/病気になった/休暇に入った場合、通常は企業ネットワークに接続する機会がありません。 また、インターネットへのアクセスの制限を考慮すると、インターネットサービスを効果的に使用することもできなくなります。 通信手段のうち、携帯電話のみが残っています。
この場合の対処方法
ネットワークインフラストラクチャの変革
以下は、より効率的なコミュニケーションと従業員の分散作業を可能にするために、インフラストラクチャを改善するための実用的な手順です。
従業員の動員
現在、スマートフォン、タブレット、ラップトップが私たちの生活にしっかりと入っています。 したがって、変換を開始するための最適なオプションは、モバイルデバイスで従業員のための追加の職場を編成することです。 潜在的なハッキングやアクセス不能のリスクを評価するには、インターネットからアクセスできる内部サービスを決定する必要があります。 たとえば、次の候補があります。
- 予約カレンダー
- 会議室の予約、
- タスクリスト
- 連絡先リスト
- 仕事用メール。
そのような移動式の場所がオフィスの文房具に取って代わることは決してないことは明らかです。 しかし、これは少なくとも分散作業の方向に向けたものです。
これは当然のことのように思えますが、従業員用のWi-Fiネットワークがオフィスにあるはずです。 さらに、必ずしも企業ネットワークへのアクセスではなく、完全なインターネットアクセスが必要です。 オフィスにWi-Fiが存在することで、モバイルデバイスが機能するようになります。また、固定ワークステーションからの不便なインターネットアクセスの問題を解決できる可能性があります。 そして、分散作業にインターネットサービスを使用することがより現実的になります。
しかし、従業員がそれでもモバイルデバイスの会議カレンダー以外のものを望んでいる場合はどうでしょうか。
企業ネットワークへの外部アクセス
情報セキュリティの観点から、もう一度前のポイントに戻りたいと思います。
企業が企業ネットワークのサービスをインターネットに公開すると、すぐに次の攻撃に対して脆弱になります。
- DDoS ：インターネットからの多数の同時リクエストにより、サービスのパフォーマンスが混乱する可能性があります。
- 認証 ：従業員が会社のユーザー名とパスワードを使用してサービスにアクセスする場合、攻撃者はそれを取得して、他のより危険なサービスにアクセスすることができます。 または、最も単純な場合、不正なパスワードの試行回数を使い果たしてアカウントをブロックします。 アカウント名が何らかのアルゴリズム（login001、login002 ...）に従って順番に生成される場合、被害者だけでなく、選択したすべてのログインもブロックできます。
- サービスハッキング ：さまざまな脆弱性により、攻撃されたサービスのインフラストラクチャを押収し、他のより重要な内部サービスのインフラストラクチャに対する攻撃を継続する可能性があります。
潜在的な攻撃者の数を減らすための適切なソリューションは、追加の保護を備えた安全なチャネルを介してインターネット上にサービスを配置することです。
二要素認証
たとえば、ワンタイムSMSパスワードまたは物理/ソフトウェアトークンからのキーを使用してシステムにログインすることの確認が適しています。 この場合、攻撃を整理するために、攻撃者は被害を会社のセキュリティサービスに報告する時間があるまで、被害者の携帯電話またはトークンを手に入れる必要があります。
安全なVPNトンネル
前のオプションに加えて、VPNテクノロジーを使用して内部サービスにアクセスすると便利です。 トラフィックの暗号化に加えて、この技術は追加の検証要素を導入します-VPN接続を作成するとき、イニシエーターはユーザー名+パスワード/証明書を必要とします。
リモートデスクトップ
「リモートデスクトップ」の原則に基づいて、企業ネットワークへのアクセスを整理するオプションもあります。 つまり、インターネットからのアクセスはサービスではなく、このサービスにアクセスできる安全なサーバーのデスクトップに与えられます。 このアプローチは仕事上あまり便利ではありません。なぜなら、 実際、リモートデスクトップ（ファイル、ブラウザーのブックマーク、クリップボードなど）とローカルラップトップの2つの分離されたワークスペースを取得します。 リモートデスクトップに完全に切り替えるオプションがありますが、リモートサーバーは十分に強力で安定している必要があります。また、それを操作するためのインターネット接続チャネルも必要です。
企業ネットワークアーキテクチャ
その後、疑問が生じます-VPNまたはリモートデスクトップ経由で企業ネットワーク全体を開いてみませんか？ そして、世界中のどこからでも従業員全員がラップトップを使えるようにしてみませんか？
それでも、戦略的情報の潜在的な漏洩は、大企業にとって大きなリスクです。 特に、従業員が海外のどこかで職場のラップトップを使用している場合。 または、それにもかかわらず、従業員の認証ツールが危険にさらされました。
さらに、多くの場合、DevOpsプラクティスに基づいて新製品を開発するために、チームのすべてのメンバーがネットワーク全体に完全にアクセスする必要はまったくありません。 テストサイトと隣接するインフラストラクチャにアクセスできれば十分です。
ネットワークセグメンテーション
したがって、重要なタスクは、戦略的に重要なネットワークリソースへのアクセスと、チームが日常業務で使用する重要度の低いネットワークリソースへのアクセスを区別できるようにすることです。
差別化の主な原則は、ネットワークセグメンテーションです。つまり、ネットワークレベルで特定のサービスへのアクセスを制限します。 大企業では、この原則はしばしば無視されます。これは、インフラストラクチャの異なる部分間でネットワークアクセスを開く時間を無駄にしないために、単一のネットワーク空間でネットワークインフラストラクチャ全体を拡大する方が簡単だからです。 この場合、外部から1台のサーバーをキャプチャすると、残りのすべてのリソースが危険にさらされます。
したがって、セグメンテーションの原則-外部からのアクセスがあるリソースは、分離されたネットワークセグメントにある必要があります。
セグメントアクセス
これは、これらのサービスが企業ネットワークの一部のリソースへのアクセスを引き続き必要とする場合にどうするかという疑問を投げかけます。 たとえば、タスク管理サービスは、新しいタスクの通知を送信するために企業のメールサーバーにアクセスする必要があります。 この場合、アクセスは開かれますが、特定のアドレスとポートのみにアクセスされます。 そのため、タスク管理サービスを取得した場合の最大の損害は、SPAMメーリング、または同じDDoSを介したメールサービスへのアクセス不能です。 もちろん、これらは不快なシナリオですが、少なくとも戦略的な情報は出ません。
制御ポート
ハイジャックされる可能性のある外部サービスからの攻撃から内部サービスをさらに保護するには、内部ネットワークの「制御」ポートを開かないことをお勧めします。 つまり、サーバー（SSH、Telnet、RDP、FTPなど）へのフルアクセスを取得できるものです。
最も理想的なオプションは、内部ネットワークへのアクセスをまったく開かないことです。 そして、代わりに、内部ネットワークから外部への逆アクセスのみを開きます。 たとえば、レターを送信するために、非送信システムはメールシステムに要求を行いますが、逆にメールシステムは分析のために送信された蓄積されたレターのキューを参照します。
セグメントへのユーザーアクセス
次の質問は、外部アクセスに必要な隔離されたセグメントの数です。 最も安全なオプションは、サービスごとに1つのセグメントです。 この場合、このサービスをキャプチャすると、近隣のサービスは影響を受けないか、最小限の影響しか受けません。 ただし、これには、ネットワークセグメントを作成し、それらの間のアクセスを開くための追加のオーバーヘッドが伴います。
したがって、最もバランスのとれたオプションは、同様のサービスを共通のセグメントに結合することです。 たとえば、タスク管理システム、ソースコード、ナレッジライブラリ。 それらはすべて、メールサーバー、ユーザー認証サーバー、データベースサーバーなど、他のサービスへの同じアクセスを必要とします。
その結果、それらを共通のネットワークセグメントに配置することに加えて、外部サービスへのアクセスを個別に（個々のサービスから）ではなく、大量に（ネットワークセグメント全体から）開くことが論理的に思えます。 これにより、このセグメントのサービス数が増加した場合にネットワークアクセスを開く時間を節約できます。
必要な数のネットワークセグメントとその中のサービスが準備できたら、異なるネットワークセグメントへの外部アクセスを制限することをお勧めします。 言い換えれば、ユーザーがサービスを本当に必要とするセグメントのみにユーザーを許可することです。
データの非個人化
チームが開発のために引き続き製品のインフラストラクチャにアクセスする必要がある場合
通常、製品開発はテストサイトで行われ、最も危険なのはユーザーデータ/財務情報です。 奇妙なことに、データ自体は開発には必要ありません。通常、匿名コピーが非常に適しています。 多数の非個人化方法がありますが、最も簡単な方法は、姓、電話番号、その他の顧客情報を同様の文字セットに置き換え、意味のないものにすることです。
次は？
大規模な組織でこれらの難しい手順を実行したと仮定します。サービスを分離されたセグメントに移動し、ネットワークアクセスを開き、匿名化されたデータにします。 次は？
残念ながら、従業員は非常に保守的であり、新しいインフラストラクチャへの移行を希望しません。 良くも悪くも、新しいだけではありませんが、古いものに慣れています。 そして、彼らにとっての移行はプロジェクトの追加費用であり、利点はオフィスの外で働く潜在的な機会であり、誰にとっても興味の対象ではないかもしれません。
または、チームでさえ新しいインフラストラクチャに切り替えて落ち着き始めましたが、古いものはどこにも行きませんでした。 そして、常にラップトップから固定された職場に戻り、古い方法で何かをする誘惑があります。
チーム人工分離
チームをオフィスから削除する必要があります。別の都市ではなく、コワーキング/アンチカフェ/他のオフィスでもできません。 ただし、2つの必須条件があります。新しい場所では、企業のローカルネットワークは存在しません。 そして、新しいオフィスは古いオフィスから徒歩圏内にあるべきではありません。 両方の条件は、古いインフラストラクチャに戻る可能性を完全に排除します。 そして、新しいインフラストラクチャが十分に準備されている場合、チームは古いオフィスから完全に独立して、さらにボーナスとして-さらに統合された古いオフィスに戻ります。
合計
この記事を要約すると、私自身の経験から、最大かつ最も安全な企業でさえ、従業員の分散開発の条件を作成できると確信できます。 上で述べたいくつかのことについて、単純で合理的な技術的および組織的原則を実装することだけが必要です。
あなたの経験から何か追加することがあれば、コメントを書いてください！