如何安全地合并三个大型银行的网段:共享技巧

不久前,在VTB品牌下,三大银行合并:VTB,前VTB24和前莫斯科银行。 对于外部观察员来说,合并后的VTB银行现在可以作为一个整体工作,但是从内部看,一切看起来都更加复杂。 在本文中,我们将讨论创建集成的VTB银行的统一网络,共享有关组织防火墙交互,连接和组合网段而不中断服务的生活技巧的计划。



分散的基础架构之间的交互困难


目前,VTB的运营受到三个传统基础架构的支持:莫斯科前银行,前VTB24和VTB本身。 他们每个人的基础设施都有自己的一组网络边界,在边界上有防护设备。 在网络级别集成基础架构的条件之一是存在一致的IP寻址结构。

合并后,我们立即开始对齐地址空间,现在已接近完成。 但是该过程既耗时又快速,并且组织基础结构之间的交叉访问的截止日期非常紧张。 因此,在第一阶段,我们通过对多个主要安全区域进行防火墙保护的方式,将不同银行的基础架构保持原样相互连接。 根据此方案,为了组织从一个网络外围到另一网络外围的访问,有必要通过许多防火墙和其他保护手段来路由流量,并使用NAT和PAT技术在资源和用户的联合地址处广播。 此外,所有交界处的防火墙都在本地和地理上保留,在组织交互和建立服务链时必须始终将其考虑在内。

这样的方案非常实用,但是您肯定不能称其为最佳方案。 同时存在技术和组织问题。 有必要协调和记录其组件分散在不同基础架构和安全区域中的许多系统的交互。 同时,在基础架构转换过程中,有必要针对每个系统快速更新此文档。 进行此过程会极大地加载我们最宝贵的资源-高素质的专家。

链路上流量的增加,安全工具的高负载,组织网络交互的复杂性,无法在不进行地址转换的情况下就无法创建某些交互的技术问题被表达出来。

流量倍增的问题主要是由于许多安全区域通过不同站点上的防火墙相互影响而引起的。 无论服务器本身的地理位置如何,如果流量超出安全区域的范围,它将通过可能位于其他位置的一系列安全功能。 例如,我们在一个数据中心中有两台服务器,但一台在VTB的外围,另一台在前VTB24网络的外围。 它们之间的流量不会直接通过,而是会穿过可在其他数据中心处于活动状态的3-4个防火墙,并且流量将被传递到防火墙,并通过中继网络多次返回。

为了确保高可靠性,我们需要每个防火墙有3-4份副本-一个站点以HA群集的形式出现在两个站点上,另一个站点以一个或两个防火墙出现在另一个站点上,如果主防火墙集群或整个站点中断,流量将切换到该防火墙。

我们总结一下。 三个独立的网络是一堆问题 :过度的复杂性,对额外昂贵设备的需求,瓶颈,冗余困难以及因此基础设施的运营成本高昂。

通用整合方式


由于我们决定进行网络体系结构的转换,因此我们将从基本内容开始。 让我们从头到尾,首先分析业务,申请人,系统工程师和安全人员的需求。

  • 根据他们的需求,我们设计安全区域的目标结构以及这些区域之间的互连原理。
  • 我们将这种区域结构强加给主要消费者(数据中心和大型办公室)的地理位置。
  • 接下来,我们形成传输MPLS网络。
  • 在此之下,我们已经将提供服务的主网络引入了物理层。
  • 我们选择边缘模块和防火墙模块的放置位置。
  • 在确定目标情况之后,我们制定并批准从现有基础结构到目标基础结构的迁移方法,以使该过程对工作系统透明。


目标网络概念

我们将拥有一个主要的骨干网-这是一个基于光纤通信线路(FOCL),无源和有源信道形成设备的电信传输基础设施。 它还可以使用xWDM光通道致密化子系统,并可能使用SDH网络。

基于主要网络,我们正在构建所谓的核心网络 。 它将具有一个地址计划和一组路由协议。 核心网络包括:

  • MPLS-多服务网络;
  • DCI-数据中心之间的链接;
  • EDGE模块-各种连接模块:防火墙,合作伙伴组织,Internet通道,数据中心,LAN,区域网络。

我们根据分层原则创建一个多服务网络,并分配中转(P)和结束(PE)节点 。 在对当今市场上可用设备的初步分析中,很明显,将P节点的级别转移到单独的设备比在一个设备中组合P / PE功能更经济可行。

多服务网络将具有高可用性,容错能力,最小收敛时间,可伸缩性,高性能和功能性,尤其是IPv6和多播支持。

在构建骨干网络期间,我们打算放弃专有技术 (在不影响质量的情况下,在可能的情况下),因为我们将努力使解决方案具有灵活性,而不是与特定供应商联系在一起。 但是同时,我们不想从各个供应商的设备中创建“醋汁”。 我们的基本设计原则是,在使用数量最少的供应商设备时,提供最大数量的服务。 除其他事项外,这将使得使用有限的人员来组织网络基础结构的维护成为可能。 新设备必须与现有设备兼容,以确保无缝迁移过程,这一点也很重要。

该项目框架内的VTB,ex-VTB24和ex-莫斯科银行网络安全区的结构计划进行完全重新设计,以合并功能重复的网段。 计划了具有通用路由规则和网络访问统一概念的安全区域的统一结构。 我们计划使用在两个主要位置隔开的单独的硬件防火墙在安全区域之间执行防火墙。 我们还计划基于标准化的动态路由协议在两个不同的站点上独立实现所有边缘模块,并在它们之间实现自动冗余。

我们通过一个单独的物理网络(带外)组织核心网络设备的管理。 将通过身份验证,授权和计费(AAA)的一项服务来提供对所有网络设备的管理访问。

为了快速发现网络中的问题,能够从网络中的任何点复制流量进行分析并将其通过独立的通信通道传递到分析仪非常重要。 为此,我们将为SPAN流量创建一个隔离的网络,借助该网络,我们将收集,过滤流量并将其传输到分析服务器。

为了使网络提供的服务和分配费用的可能性标准化,我们将引入一个带有SLA指标的目录。 我们继续进行服务模型,其中考虑了网络基础结构与应用任务的互连,控制应用程序的元素的互连及其对服务的影响。 而且该服务模型由网络监控系统支持,因此我们可以正确分配IT成本。

从理论到实践


现在,我们将下一层,向您介绍新基础架构中可能对您有用的最有趣的解决方案。

资源林:详细信息


我们已经使哈布罗夫斯克居民熟悉了VTB资源林。 现在尝试给出更详细的技术说明。



假设我们有两个(为简单起见)不同组织的网络基础结构需要合并。 通常,在每个基础架构中,在一组功能网络网段(安全区域)中,可以区分主要工业系统所在的主要生产网段。 我们将这些生产区域连接到锁定段的特定结构,我们将其称为“资源林” 。 这些网关段发布可从两个基础结构获得的共享资源。

从网络的角度来看,资源林的概念是创建一个由两个IP VPN组成的网关安全区域(对于两个存储库而言)。 这些IP VPN在它们之间自由路由,并通过防火墙连接到生产网段。 这些段的IP地址是从不相交的IP地址范围中选择的。 因此,从两个组织的网络向资源林的路由成为可能。

但是,从资源林到工业部门的路由选择时,情况要更糟一些,因为其中的寻址经常相交并且不可能形成一个表。 要解决此问题,我们仅需要资源林中的两个段。 在资源林的每个部分中,都将一条默认路由写入“其”组织的工业网络。 也就是说,用户可以访问而无需将地址转换为资源林的“自己的”部分和通过PAT转换为另一部分的地址。

因此,如果沿着防火墙绘制边界,则资源林的两个部分代表一个网关安全区域。 它们每个都有自己的路由:默认网关面向“其”存储库。 如果我们将资源放置在资源林的某个部分中,则相应银行的用户无需NAT就可以与它进行交互。

没有NAT的交互对于许多系统来说非常重要,首先,对于Microsoft域交互来说,毕竟-在资源林中,我们拥有用于新公共域的Active Directory服务器,这两个组织都建立了信任关系。 同样,在没有NAT交互的情况下,需要诸如Skype for Business,ABS“ MBANK”等系统以及许多其他各种应用程序,服务器才能返回到客户端的地址。 如果客户端位于PAT后面,则将不再建立反向连接。

我们在资源林的各部分中安装的服务器分为两类:基础结构(例如,MS AD服务器)和提供对某些信息系统的访问。 我们将最后一种服务器称为数据市场。 店面通常是Web服务器,其后端已经位于在资源林中创建该店面的组织的生产网络中的防火墙之后。

以及访问发布资源时如何对用户进行身份验证 ? 如果我们只是为另一个域中的一个或两个用户提供对某些应用程序的访问权限,那么我们可以在他们的域中为他们创建单独的帐户以进行身份​​验证。 但是,当我们谈论基础设施的大规模合并(例如5万个用户)时,为他们启动并维护单独的交叉帐户是完全不现实的。 出于安全原因以及因为需要在相交地址空间的情况下使PAT用户成为可能,也不总是可能在不同组织的林之间建立直接信任。 因此,为了解决统一用户身份验证的问题,在资源林的外围创建了一个由一个域组成的新MS AD林。 在这个新域中,用户在访问服务时进行身份验证。 为了使之成为可能,在新目录林和每个组织的域目录林之间建立了双边目录林信任。 因此,任何组织的用户都可以在任何发布的资源上进行身份验证。



获取网络集成


在我们通过资源林的基础架构建立了系统的交互并消除了严重的症状之后,就该进行网络的直接集成了。

为此,在第一阶段,我们将三个存储库的产品部分连接到一个功能强大的防火墙(逻辑上统一,但实际上在不同站点上保留了许多次)。 防火墙提供了不同银行系统之间的直接交互。

使用前VTB24,在组织系统之间的任何直接交互之前,我们已经设法对齐地址空间。 在防火墙上形成路由表并打开适当的访问权限后,我们能够确保两个不同基础结构中的系统之间进行交互。

在前莫斯科银行的帮助下,组织应用交互时的地址空间未对齐,我们不得不使用相互NAT来组织系统交互。 使用NAT产生了许多DNS解析问题,这些问题可以通过维护重复的DNS区域来解决。 另外,由于NAT,许多应用程序系统的操作存在困难。 现在,我们几乎消除了地址空间的交集,但是我们面临这样一个事实,即许多VTB和前莫斯科银行系统紧密地绑在一起,以便在翻译后的地址进行通信。 现在,我们需要将这些交互迁移到真实的IP地址,同时保持业务连续性。

取消NAT


在这里,我们的目标是确保系统在单个地址空间中的运行,以便进一步集成基础结构服务(MS AD,DNS)和应用程序(Skype for Business,MBANK)。 不幸的是,由于某些应用程序系统已经在转换后的地址处相互绑定,因此需要与每个应用程序系统单独工作以消除特定交互的NAT。

有时,您可以使用这样的技巧 :在转换后的地址和真实地址下同时设置同一台服务器。 因此,应用程序管理员可以在迁移之前在真实地址上测试工作,尝试自行切换到非NAT交互,并在必要时进行回滚。 同时,我们使用数据包捕获功能监视防火墙,以查看是否有人通过转换后的地址与服务器进行通信。 一旦此类通信停止,我们与资源所有者达成协议,就停止广播:服务器只有真实地址。

不幸的是,在解析NAT之后,有一段时间需要在功能相同的网段之间维护防火墙,因为并非所有区域都遵循相同的安全标准。 在对段进行标准化之后,段之间的防火墙将被路由替换,并且功能相同的安全区域会合并在一起。

防火墙功能


让我们继续讨论互联网络防火墙的问题。 原则上,这对于需要同时提供保护设备的局部和全局容错功能的任何大型组织都非常重要。



让我们尝试概括地说明防火墙保留的问题。 我们有两个站点:站点1和站点2。有几个(例如,三个)MPLS IP VPN通过状态防火墙相互通信。 该防火墙需要在本地和地理上保留。

我们不会考虑防火墙本地备份的问题;几乎所有制造商都可以将防火墙组装到本地HA群集中。 至于防火墙的地理保留,实际上没有厂商可以立即完成此任务。

当然,您可以跨L2跨多个站点“拉伸”防火墙群集,但是此群集将代表一个单点故障,并且我们解决方案的可靠性不会很高。 因为有时群集会由于软件错误而完全冻结,或者由于站点之间的L2链接中断而陷入裂脑状态。 因此,我们立即拒绝在L2上扩展防火墙群集。

我们需要提出一种方案,如果防火墙模块在一个站点上发生故障,则会自动过渡到另一个站点。 这是我们的方法。

当活动群集位于同一站点上时,决定坚持使用“活动/备用”地理保留模型。 否则,我们会立即遇到非对称路由的问题,这对于大量的L3 VPN来说很难解决。

活动防火墙群集必须以某种方式表明其正确操作。 作为信令方法,我们选择了从防火墙到带有/ 32掩码的测试(标志)路由网络的OSPF公告。 站点1上的网络设备监视从防火墙发出的此路由的存在,并在可行时激活到该防火墙群集的静态路由(例如0.0.0.0 / 0)。 然后,将此静态默认路由(通过重新分发)放入BGP MP协议表中,并在整个骨干网中分发。 , OSPF , , IP VPN.

, , , .

1 - , , 1 , 2 — . , , VPN' . , , , .

, active/standby. active-. , . , (, IP- ). . . .

L3 , . .


. , , — , , . L3-, .

, IP-. MPLS VPN. MPLS VPN «IN» VPN «OUT». VPN HUB-and-spoke VPN. Spoke HUB' VPN, .

«IN» - Spoke VPN' VPN. «OUT» Spoke VPN' .

MPLS VPN «IN». VPN . VPN HUB-VPN «IN» . . , Policy Based Routing. VPN «OUT», VPN «OUT» Spoke-VPN.



VPN, . MPLS import / export HUB VPN.

VPN , — , VLAN, ..

结论


, , . , , , . .

Source: https://habr.com/ru/post/zh-CN439046/


All Articles