ある銀行、ヨーロッパの主要銀行グループのロシア支店は、ネットワークをセグメント化するタスクを設定しました。 そのサーバーはデータセンターにありました。 作業の開始時には、顧客は適切な金融業務のための独立したインフラストラクチャと、いくつかの大きなノードと多くのブランチのために物理的に分離されたユーザーの大規模なピアツーピアネットワークを持っていました。 前者は時計のように機能し、後者は困難を伴いました。 さらに、個人データに関する152-の要件に基づく内部再編成はまだ始まったばかりです。
新しいネットワークをより適切に編成する方法を理解するために、それらのIPアドレスとサービスの一致を要求しました。 より正確には、最終的には、トラフィックが何をどこで運転しているかを示すマップが必要であったため、何を許可し、何を禁止するかが明確になりました。
この時点で、ISはそのような文書を提出できないと述べた。 そして、彼らはトラフィックマップを自分で収集することを提案しました。これは、第一に、彼ら自身がネットワーク上で何が起こっているかの実際の状況に関心があり、第二に、ネットワーク上のトラフィックとアプリケーションの説明がこれまでのところ彼らの計画にのみあるためです。 簡単に言えば、彼らの姿は、ネットワーク上のトラフィック交換の状況を実現する絶好の機会でした。ITが何かを接続し、それについてISに通知するのを忘れたことがよくあるようです。
そこで、すべてのネットワークトラフィックの分析を開始しました。
最初の段階：「敵か味方か」
「左」のトラフィックから「良い」トラフィックが少し早く切断され、ミラーリングモードで接続されるように、機器を持ち込みました。 これは、設定が正しく機能するかどうかをトラフィックの完全なコピーで事前に判断できる標準機能です。 このモードでは、何がカットされ、何がカットされていないかを確認できます。 私たちの場合、遮断するものは何もありませんでしたが、最初にアプリケーションを識別し、統計を収集し、トランザクションをマークする必要がありました。
2週間のトラフィックの95％がルールに該当する瞬間に実装に同意しました。 残り（原則として、数キロバイトの小さな1回限りのトランザクション）は数千単位で測定され、タイピングは困難でした。 彼の人生をこのトラフィックの研究に費やすことができます：それは無限の非周期的な部分のように振る舞いました-それは常に変化していました。 これらのささいなことで何かがうまくいかない場合（ユーザーサブネットで思い出します）、ファイアウォールの新しいルールが必要であると想定されていました。 説明されているすべてのトラフィックは、ファイアウォールのアクセス許可に追加されました。 何か新しいものが登場した場合、デフォルトで切断され、分析のためにITチームと情報セキュリティの専門家に提供されます。
彼らは情報を収集し始めました-誰がどこへ、どのプロトコルで行きます。 最初の週の結果によると、IPアドレスとそれらへのトラフィック量を示すテーブルがありました。 一般的な接続を監視して、完全なネットワークプロファイルを構築し始めました。 アプリケーションの動作として定義した各接続は、ITチームによって既知のサービスとして（要求に応じて）指定されました。 99％の場合-正常かつ正しく。
動物園には多くの驚きがありました。 さらに重要なことは、大量のトラフィックでさえ非周期的に動作し、一部のサービスはすぐに遠く離れて表示されることです。 4週間後、その週の結果に続いて表の95％に達し、3か月後、新しい週に予期しない結果が出なかったことを達成しました。
1週間、およそテラビットのトラフィックがファイアウォールを通過しました。 性質はかなり頻繁に変化し、トラフィックが決定されると、新しいルールセットが常に必要になりました。 たとえば、数週間の間、IPアドレスのグループの1つへのトラフィックがなかったため、予期せずに送信されました。 結局のところ、これらはビデオ監視データを備えたサーバーでした。おそらく、私たちの巨大な国のどこかでしつこい人がいて、中央オフィスからのビデオを突破するのに数週間かかりました。 当然、これによりネットワークにかなりなじみのない負荷が発生しました。 または、たとえば、数週間ごとにバックアップでファイルウォッシュを破棄するブランチが1つあったため、1週間にわたって、この重要な操作を彼のためにキャッチできないことがありました。
警備員は、サービスをクリティカルリスクとそうでないリスク、つまり優先リスクに分けました。
第二段階：共有方法
結果は大きなマトリックスであり、実際にはファイアウォールのルールが含まれていました。 ところで、非常に便利なスクリプトを作成しました。これは、情報セキュリティおよびITチーム用のXLSファイルから、何に署名した後、ファイアウォールに実装するための一連のルールを直接実行しました。 Excelのテーブルにプラスを付けて-トラフィックを許可し、マイナスを付けて-削減しました。
トラフィックの95％をカバーする予測動作モードが（ミラー接続の一部として）実際のものと一致し始めると、トラフィックを決定する作業が完了したことが明らかになりました。 警備員は、彼らが何をどこに向かっているのかに関する一連の文書を受け取りました（そして、誰かが彼らのためにそれをすべて整理してくれたことを非常にうれしく思いました）。 また、ITサービスは、妥当な時間で指標を達成できたことに非常に満足していました。
ここで、ネットワークを分割する必要がありました。 そのような場合には、いくつかの基本的なアプローチがあります。
- 地理的に古典的な：各オフィスには独自のサブネットがあり、それらは地域のサブネットに結合されてから、会社の一般的なネットワークに入ります。
- レガシーアプローチ、「既存のネットワークプロジェクトによる」。 これは合理的なこともありますが、原則として、大企業にとっては松葉杖で海を脅かしています。 事実、歴史的には、たとえば、モスクワとペテルブルグの1〜4階のオフィスは1つのネットワークであり、5階とエカテリンブルクは別のネットワークであることがわかります。 3階には、5台目のプリンターを使用する権利があります。
- 簡略化されたセグメンテーション：1つのサブネットに重要なトップとすべて、ユーザーは別のサブネットに。
- アトミックセグメンテーションでは、各サブグループに独自のサブネットが割り当てられます。 たとえば、2〜3人が部屋に座って、1つのもの-一度サブネットのメンテナンスだけに従事しています。 隣人は2つのサブグリッドなどです。 実際、これは警備員にとっての楽園です。警備員は人をコントロールするのが最も便利ですが、それをサポートする必要がある人にとっては地獄です。
- 機能のセグメンテーション：ユーザーは、（地理に関係なく）できることとできないことに従って団結します。つまり、実際には6〜10の主要な役割が与えられます。
ネットワークは当然、都市とは独立してアドレス指定を設定できるため、デバイスが互いに近くにあると「見た」ため、従来のアプローチと地理をすぐに放棄しました。 簡素化されたセグメンテーションが単純化されすぎました。 機能的（役割）であり、重大なケースであるアトミックです。 当然、セキュリティチームはサブネットへの最大限の分割を選択しました。 エクスペリエンスを設定し、構成が何回成長するかと、それをサポートする方法を示しました。 彼らは考えて、役割システムを作る許可を得て帰りました。
人材派遣を提供する人事部を募集しました。 ITおよびISとともに、各従業員の役割を決定し、その従業員にサブネットを割り当てました-そして、再び「大きな鉄片」のルールに追加しました。 繰り返しますが、2、3週間、ミラートラフィックを調べて、すべてが正しく処理されているかどうかを確認しました。
「人間」の役割に加えて、「プリンター」グループへのプリンター、「サーバー」グループへのサーバーなど、他の役割もありました。 各リソースは、まだビジネスプロセスにとって重要であると評価されています。 たとえば、ファイル共有、DNS、およびRadiusサーバーは通常のものとして認識され、そのサーバーの障害は、たとえば経理部門に「置かれ」ましたが、重大でした。
ステージ3：実装
新しい情報を受信するたびに、「人間が読める」XLSからの奇跡的なスクリプトを使用してファイアウォールのルールに入力するだけなので、常に最新のネットワークポリシーがありました。 ファイアウォールはミラーモードのままでした。つまり、すべてのトラフィックを静かに通過させましたが、戦闘モードでは遮断されるように、ITとISのコピーに表示しました。 関係するすべてのものがすべての人に合うようになった瞬間、ITチームは週末に作業するための窓口を指定しました。 なぜ週末に-驚いた場合、プレスリリースが機能しないように。
サプライズは発生しませんでしたが、切り替えは予想通りでした。 設定を含むエグゼクティブドキュメントを作成し、システムを運用しました。
少し戻って、この段階では、たった1つの小さな困難がありました。ITチームは、ファイアウォールが自分のネットワークノードであると信じ、それを操作しました。 セキュリティガードは、これをアクセス制御ノード（データ用のACSのようなもの）と見なし、デバイス全体であると考えました。 幸いなことに、ハードウェア上で必要な役割を両方とも設定しました。セキュリティガードはネットワーク構成に影響を与えず、ITチームは情報セキュリティのために予期せず新しい権限を規定できません（実際、このような場合、セキュリティガードは最新のトラフィックマップを必要としました-多くのことが「ホットベータ」で行われ、永久に本番のままでした）。
最終的なスケジュールは次のとおりです。
| ステージ名 | 期間 | 解説 |
|
技術的および商業的提案の準備 |
1週間 |
インテグレーターにとっては非常に高速です。 |
|
契約調印 |
1週間 |
銀行にとっては非常に高速です。 |
|
設計文書の開発 |
1ヶ月 |
+ドキュメントの調整を含む、顧客との調整時間（これは |
|
機器の設置と試運転 |
3週間 |
作業は顧客の4つのサイトで合意された「ウィンドウ」で実行されたため、プロセスにはこのような時間がかかりました。 |
|
試運転 |
3ヶ月 |
目標を達成するために、ITUでルールを設定するための反復プロセスを実行する必要がありました。 |
|
最終テスト、試運転 |
1日 |
切り替え |
結果のアーキテクチャ：
主な鉄片はパロアルト3020です。4つのサイトに6つあります。 大規模なオフィス（フェイルオーバークラスターで接続）に2つ、データセンターに1つ（これらは銀行のITインフラストラクチャがある2つのデータセンターです）。 データセンターでは、2つのデータセンターのアーキテクチャ自体が本質的に大きなクラスターであるため、ファイアウォールはクラスターではなく透過モードで接続されます。
参照：
- Aeroexpressネットワークのリファクタリング （急成長企業の好例）
- 私たちのチームの物語
- 私のメールはAVrublevsky@croc.ruです
顧客の要件をネットワークルールに変換するためのスクリプトコードは、エンジニアと手をつないで行きました。これは素晴らしいことです。時間を節約できます。