presentation zone network

CMS Multi Zone Architecture

Introduction

The CMS TRA specifies a zone architecture that provides defense against security attacks and implements layers of challenges to ensure only authorized access to CMS resources. The services framework details the functions provided by each of the service types, and these services are represented by zones in the CMS multi-zone architecture. In general, the service names match the zone terminology (e.g., Data Services and Data Zone) except for Edge services which corresponds to the Presentation Zone. As the use of cloud platforms and cloud services (such as content delivery networks) have become more prevalent within CMS, the term 'Edge Services' has been adopted to represent the services that front and protect CMS internet-facing resources.

The multi-zone architecture is focused on protecting CMS assets via security challenges and enforcing defense-in-depth principles. Zones are a way of grouping and sharing resources based upon a shared security posture. Distinct zones generally exist in legacy data centers but are not as prevalent in cloud implementations where virtual resources, such as network, compute, storage are usually are project based implementations and there is tight integration with other cloud service provider (CSP) provided services. CMS does not require distinct zones for protecting assets, but it does require that data is protected by at least three security challenges. This is a minimum requirement, as additional security measures may be helpful in reducing the risk of a security breach. In addition, the security measures should not be housed on the same resource. This is done to ensure that if one resource is compromised, other security measures are in place to thwart an attack.

The following subtopic will diagram and discuss the multi-zone architecture, detailing the relationship between the zones and the services framework. Note that the depiction is reminiscent of the CMS three-zone architecture as the three-zone model is one instance of the CMS multi-zone architecture. This is a result of the physical nature of the three-zone architecture and its implementation with CMS data centers. The services framework and multi-zone architecture is applicable to cloud environments, where the delineation of the zones is not as obvious. Cloud implementations that utilize a combination of CSP services and CMS services obscure specific zones implemented by the system developer. The specific zone is not as significant to the design as the need to implement challenges to protect CMS assets.

After the discussion of the multi-zone architecture, examples of typical use cases are provided that demonstrate how the function could be implemented in the three-zone architecture as well as the cloud. These examples will support the reader's understanding of the architecture and security requirements. Please note, since system requirements and design vary greatly, these examples are to demonstrate the principle of protecting system assets, but the specific example may not apply to every system design. It must be stressed that the system developers should work with their ISSO in developing and implementing protections to CMS assets.

Zone Architecture

CMS defines a zone as “a portion of the network isolated by firewalls that serves a specific business function”. These firewalls may be physical or virtual, or implemented by other means (e.g. Security Groups in AWS, Network Security Groups in Microsoft Azure, etc).

CMS data centers have typically utilized a three-zone architecture design. While CMS does not dictate the actual number of zones, in CMS data centers the common practice was the implementation of three zones based around data, application and edge services. As a result of the hierarchical nature of the implementation, using specific zones allowed for ‘like’ services to communicate (e.g., application to application service) in and between data centers as long as the CMS network was utilized. In addition, this implementation method also allowed for services to communicate with other services one layer below their own (e.g., edge services to application). Therefore, data services are not directly accessible from outside a CMS data center. Services on the same level are assumed to have passed through the same levels of security and may be accessed directly, although common practice is to restrict consumers of a service to just those components that require the use of the service. Systems implemented in the cloud do not generally have this distinct segmentation and assumptions about the security posture do not exist.

In today’s more dynamic, elastic, and transient cloud environments, the multi-zone architecture is still relevant, but the security challenges may be implemented within Cloud Service Provider (CSP) services or within resources implemented by the CMS development organization. Clouds, microservices, software defined networks, and other emerging technologies present new paradigms for application architecture and often favor new design patterns for performance, security, and cost avoidance. Also, applications may resemble a fabric of services running on a dynamically changing cloud of virtual resources connected through networks often more defined by permissions than wires. These newer cloud environments and implementations rely upon CSP’s services which leads to a collaboration between the CSP and system implementor for implementing security.

CMS Processing Environments are composed of one or more of the following zones to provide Defense-in-Depth, as depicted in the CMS TRA Multi-Zone Architecture figure below:

Presentation Zones (PZ) – Edge services that support the presentation of content. Presentation Zones are accessible to external networks via firewalls through a Trusted Internet Connection (TIC).

Application Zones (AZ) – Application services which support business logic for applications and creating dynamic user presentations.

Data Zones (DZ) – Data services that contain data and data services used by applications.

Management Zone – To support specialized services, such as Public Key Infrastructure (PKI), Domain Name System (DNS) services, and system management services.

Security Zone – A shared mediation service to support security services.

As the CMS TRA Multi-Zone Architecture diagram shows, the Presentation Zone controls the ingress and egress of all external communications into the CMS Processing Environment. The Application and Data Zones may communicate with corresponding Application Zones and Data Zones in other CMS data centers only. CMS has the capability of communicating from a zone in a CMS data center to a CMS cloud environment. Application and Data Zones would be allowed to communicate to equivalent zones in the cloud. These equivalent zones would be part a CMS private subnet within the CMS enclave at the service provider.

In the CMS vernacular, a Management or Security Zone is a network segment whose primary function is in support of security or infrastructure, and typically provides services to all the other zones. These Zones generally follow the same rules as other zones though there are a few additional rules. A data center may choose to group infrastructure functions into more zones than those listed here. Note : CMS TRA Multi-Zone Architecture represents the conceptual connections between zones and does not depict network implementation such as Trusted Internet Connections (TIC) integration and Virtual Routing and Forwarding (VRF), which are covered in more detail in TRA Network Services.

Transactions within a zone are permitted without restriction unless the traffic is firewalled between data centers. Transactions traversing the zones are controlled and protected via firewalls and other security mechanisms. This multi-zone architecture allows CMS to monitor and control business application transactions within and between zones. The Transport and Management Zones provide infrastructure and supervisory services to manage the core zones.

Presentation Zone

The Presentation Zone contains the front-end components of applications. The Presentation Zone receives requests from external sources, performs data validation, and proxies the requests to the Application Zone for processing. No business logic or database processing is performed on Presentation Zone servers. The Presentation Zone function is to proxy communication requests to the Application Zone (i.e., application-related connections must originate in the Presentation Zone). It is also the zone where business applications first receive data from external sources and is therefore the first zone to challenge requests for validation, authorization, and malicious content.

For outbound communications, the Presentation Zone is the last zone traversed before reaching the Internet.

Application Zone

The Application Zone contains the business logic components of an application. It receives requests from the Presentation Zone and requests necessary data from Data Zone components. The Application Zone can host proxy services to the Data Zone.

The Data Zone contains all data sources, including data stores supporting directory services, authentication functions, data lakes and meshes as well as the applications’ operational databases. All interactions between the Application Zone and the Data Zone must use mediation and data access services. CMS permits the use of database-stored procedures that may reside on database servers in the Data Zone.

Management Zone

The Management Zone provides services to all zones and includes such functions as:

DNS servers

Backup servers

Remote Access Services

System monitoring applications

Asset/vulnerability management

Application deployment functions

System configuration management function

The specific services provided by the Management Zone will vary from data center to data center. Projects are encouraged to discuss specifics with their data center provider. The Management Zone is the appropriate zone for hosting development and operations automation, such as DevOps deployment components.

Security Zone

The Security Zone provides services to all zones and includes such security functions as:

Security monitoring and response

Network and Host Intrusion Detection Systems (NIDS/HIDS)

Intrusion Protection Service (IPS)

Recording and monitoring of system, security, and audit logs

Antivirus monitoring and analysis of server based anti-malware agent

Enterprise-level security monitoring by integrating with the CMS Cybersecurity Integration Center (CCIC)

Applying Zoned Architecture

As described above, CMS implements defense-in-depth principles in a multi-zoned architecture. In the subtopic above, we talked about defense-in-depth and how each zone within the architecture contributes to protecting CMS resources.

In the cloud, the definitive lines between zones are not as clearly defined, and utilizing services from the cloud providers further obscures the responsibility for implementing defense-in-depth. Firewalls may not be implemented, but the team may use security groups (in AWS environments) or their equivalent within their respective cloud for controlling access and flow through the system. CMS requires at least three challenges before allowing access to sensitive data. In the cloud environment, these challenges may not be as clearly separated into zones as CMS data centers would support. The reader should take ‘three’ challenges as a minimum to implement security needs. As such, the implementor should strive to deliver the most secure implementation, limiting risk, that resources can support.

We will detail some common implementations within the cloud environment below and discuss how defense-in-depth can be implemented. Remember these examples are to demonstrate possible implementations and the implementor should work with their ISSO to validate the security adequacy of the design. Note that the current practice is for CMS cloud engineers to provide the implementor with a private and public subnet. The implementor creates the zones or the defense-in- depth using this model. For example, the application zone and data zone could be implemented within the private subnet, controlling flow and access using security groups.

Example 1 – API Implementation

In this example, the implementor desires to implement an API to access CMS sensitive data for users external to CMS. The API endpoint should be protected by a Web Application Firewall (WAF) which may implement one or more of the security challenges and mediation principles (e.g. Geo fencing). A typical implementation would include:

• Multifactor authentication prior to accessing the APIs that front sensitive data
• Authorization that the user has adequate permissions/roles to access the API. This could be accomplished using a directory.
• The API endpoint should obfuscate (see Mediation Principles ) the data access details to avoid providing the end user with any type of information regarding the type of database, location, etc.

The diagrams below depict the zonal mapping of the API example to a CMS data center implementation and a cloud model where the implementation is supported with cloud services. Amazon Web Services (AWS) is used in the example, but the example holds for any CMS approved cloud. Please note that in the cloud example, we do not explicitly name the presentation and application zones. In this example, the implementation utilizes services provided by the cloud service provider (CSP). While not explicitly named, the reader can infer the web application firewall is analogous to the presentation zone and the API gateway to the application zone.

Additional security challenges/features may be implemented depending on the risk posture of the system. For example, data masking can provide additional security as well as configuring the desktop/tool to limit the ability of the user to download or obtain the data.

Sharing Components and Capabilities

The following definitions are critical to understanding the components of the CMS Processing Environments. These definitions apply to all virtual and physical components of information processing systems:

Dedicated components – are those physical resources provided exclusively for CMS Environments.

Shared component – means the physical or virtual component is shared among multiple tenants in a data center, in a virtualization hosting system, or in a community or public cloud environment. Details of CMS cloud shared services are available at CMS Cloud Services .

Independently managed component – means the physical or virtual component is independently usable and managed by CMS, in isolation from other tenants.

Third-Party Websites and Applications – are web-based technologies (covered within the CMS ARS) that are not exclusively operated or controlled by HHS. The CMS TRA covers TPWAs linked to or accessed by CMS applications.

Single-purpose component – means the physical or virtual component is a standalone custom or commercial device or appliance product (including hardware, firmware, software, and/or operating system) designed for a specific purpose, and not to perform general purpose processing. An example would be a firewall appliance that consists of firewall software running on a virtual machine (VM) with a highly customized operating system that is designed to run only the firewall application.

Network Connectivity and Trust Boundaries

CMS data centers and the CMSNet connections between them are within the CMS security perimeter and currently operate with an elevated level of trust. The movement towards newer security models such as zero trust will continue to reduce the inherent trust at the network connectivity level, and best practice is to authenticate all network connections. Although individual data centers may connect to the untrusted Internet, connections between CMS data centers should preferably traverse CMSNet. Connections to external entities must be covered by an Interconnection Security Agreement (ISA) approved by the CMS Authorizing Official.

CMS Data and CMS Sensitive Information

The CMS TRA uses the term “CMS Sensitive Information” as defined in the Risk Management Handbook , Volume I Chapter 10, CMS Risk Management Terms, Definitions, and Acronyms available for download from CMS Cybergeek and Executive Order 13556 -- Controlled Unclassified Information . It is the responsibility of the business owner, in consultation with their Group Director (GD), Information Systems Officer (ISO), Information Systems Security Officer (ISSO), Cyber Risk Advisor (CRA), Chief Information Security Officer (CISO), Administrative Officer (AO), Data Guardian, and Privacy subject matter expert to determine what data are sensitive. This includes all data that require protection due to the risk and magnitude of loss or harm, such as PII, PHI, and Federal Tax Information (FTI).

There are some system data elements in ATO(ed) environments that should always be considered sensitive:

Passwords and private keys, including application programming interface (API) keys and other keys used to access or configure sensitive CMS data, services, or IT resources

Final release of code, executables, and configuration files that will be or are deployed in ATO(ed) environments

Configuration “Reference Data” such as configuration files or metadata used for configuring virtual resources and services in ATO(ed) environments

Internal network addresses, and unique addressable device identifiers—such as Media access control (MAC) addresses, Virtual Machine identities (ID), etc. in ATO(ed) environments

The Privacy Impact Assessment (PIA) is a critical tool for spotting privacy risks and compliance with federal regulations or laws, tracking implementation of privacy controls, identifying instances where CMS collects or handles Personally Identifiable Information (PII) and/or Protected Health Information (PHI) and for identifying CMS systems subject to the Privacy Act of 1974.  PIAs must be conducted as part of the ATO process for CMS IT systems, and must be reviewed at least every three years and/or upon a major change to the IT system or electronic information collection. For additional information, reference the CMS Privacy Impact Assessment (PIA) Standard Operating Procedures and ARS SC-7(24) - Personally Identifiable Information.

Designating High Value Assets

A High Value Asset (HVA) is an asset used as a mission-critical information resource supporting infrastructure providers and suppliers or partnering organizations. The unauthorized disclosure, modification, destruction, or disruption of access to this information could be expected to have a severe or catastrophic adverse effect on organizational operations, organizational assets, or individuals.

The business owner of a CMS information system must categorize the system in accordance with Federal Information Processing Standards (FIPS) 199, and document the system attributes used to identify PII, PHI, and HVAs. The CIO determines whether a system is an HVA. If the CMS CIO identifies a system as a High Value Asset, an HVA Designation Letter must be on file. Please refer to TRA Network Services, Cyber Security Operations / Risk Management for more information.

General Distribution / Unclassified Information

Language selection

• Français fr

Note to readers

This publication does not currently meet the Government of Canada's Web Standards. The information remains valid.

Network security zoning - Design considerations for placement of services within zones (ITSG-38)

From: Canadian Centre for Cyber Security

Practitioner series

May 2009 | Practitioner series

Alternate format : Network security zoning - Design considerations for placement of services within zones (ITSG-38) (PDF, 1.29 MB)

The Network Security Zoning is an unclassified publication, issued under the authority of the Chief, Communications Security Establishment Canada (CSEC).

For further information or suggestions for amendments, please contact CSEC's IT Security Client Services by e-mail at [email protected] or call 613-991-7654 or 613-991-8495.

• Effective Date

This publication takes effect on (01/03/2009).

Originally signed by

Gwen E. Beauchemin Director, IT Security Mission Management

© 2009 Government of Canada, Communications Security Establishment Canada

Table of Contents

Executive summary, revision history, 1.1 background, 1.2 purpose, 1.4 audience, 2.1.1 public zone, 2.1.2 public access zone, 2.1.3 operation zone, 2.1.4 restricted zone, 2.2.1 physical implementation of perimeters (or zips), 4.1 internet services network example, 4.2 departmental network zone architecture example, 4.3.1 public zone, 4.3.2 public access zone, 4.3.3 operations zone, 4.3.4 restricted zone, 4.3.5 management restricted zone, 4.3.6 application tier internet services restricted zone, list of abbreviations, bibliography, list of services, services locations in the internet services network, services locations in the departmental networks, list of figures, figure 1: sample architecture using itsg-22 zones, figure 2: zone interface points, figure 3: how a paz zip works, figure 4: zips create a perimeter, figure 5: perimeter, figure 6: perimeters, zips, and sample physical implementation equivalency, figure 7: context for internet services network zone architecture, figure 8: context for departmental network architecture, figure 9: departmental network zone architecture, figure 10: internet services network zone architecture, figure 11: departmental network communications flows, figure 12: internet services network architecture.

This guideline is intended to assist network architects and security practitioners with the appropriate placement of services (for example, domain name service, email service, and web proxy service) into network security zones.

A service is a logical construct that represent a set of functional requirements in an information technology architecture. These functional requirements can be simple such as providing resolution of domain names, or complex such as processing and transmitting email. Services can be physically implemented in many ways, for example, a single process on server, multiple processes on a virtual machine, or distributed processes among pool of servers.

Concepts used in this document are based on the Baseline Security Requirements for Network Security Zones in the Government of Canada (ITSG-22), which describes the concepts of network security zones and specifies baseline security requirements for zone.

The network security zones in ITSG-22 covered in this guideline are:

• Public Zone
• Public Access Zone
• Operations Zone
• Restricted Zone

To assist in determining the appropriate placement of services, two typical logical zone architectures are illustrated: Internet Service network zone architecture and Departmental network zone architecture.

The primary purpose of the Internet Services network is to provide Unclassified (Protected B and below) business application delivery via the Internet to the public.

The primary purpose of the Departmental network is to deliver Unclassified (Protected B and below) business applications to public servants.

This document is a companion to Baseline Security Requirements for Network Security Zones in the Government of Canada (ITSG-22). This document is an input into the design process not a prescriptive design for all GC networks. The examples described in this guideline are examples only and should not be copied verbatim in any network design.

• Document Number: ITSG-38
• Title: Network Security Zoning
• Release Date: May 2009

1 Introduction

An element of the design for an IT security infrastructure is the zoning, which segments similar information technology assets (hardware, software, and data) into logical groupings that have the same security policies and security requirements.

A zone, as defined and used in this guideline, is a construct to define standard baseline security requirements that if adopted by GC departments will lead to consistency in their implementation of network security. It demarcates a logical area within a networking environment with a defined level of network security. Zones define the network boundaries and their associated perimeter defence requirements by:

• defining the entities which populate zones;
• identifying discrete entry points;
• monitoring and filtering network traffic at entry points;
• monitoring the state of the network; and
• authenticating the identity of network entities.

This document is a companion to the CSEC publication, Baseline Security Requirements for Network Security Zones in the Government of Canada (ITSG-22), which describes the concepts of network security zones and specifies baseline security requirements for zones.

The purpose of this document is to assist network architects and security practitioners with the appropriate placement of infrastructure services (for example, domain name service, email service, and web proxy service) into zones. To assist in the understanding of appropriate placement of infrastructure services, two typical logical zone architectures are illustrated:

• Internet Service network zone architecture;
• Departmental network zone architecture.

The primary purpose of the Internet services network is to provide Unclassified (Protected B and below) business application delivery via the Internet to the public.

The primary purpose of the Departmental network delivers Unclassified (Protected B and below) business applications to public servants.

The scope of this document is limited to network security zones, zone interface points (ZIPs), perimeters, and infrastructure services required for the design of zoning architecture (logical) that does not constrain the physical design.

This document addresses the following zones as specified in ITSG-22 [Reference 1] :

• Public Zone (PZ);
• Public Access Zone (PAZ);
• Operations Zone (OZ); and
• Restricted Zone (RZ).

This document is written for network architects and security practitioners within the Canadian federal government.

Zoning is used to mitigate the risk of an open network by segmenting infrastructure services into logical groupings that have the same communication security policies and security requirements. The zones are separated by perimeters (Zone Interface Points) implemented through security and network devices.

Zoning is a logical design approach used to control and restrict access and data communication flows only to those components and users as per security policy. A new zone is defined by a logical grouping of services under the same policy constraints, driven by business requirements. When a new set of policy constraints are established, then a new zone is required.

Baseline Security Architecture Requirements for Network Security Zones in the Government of Canada (ITSG-22) identifies seven zones, however this guideline only covers the four most common zones shown in Figure 1 :

Sample Architecture using ITSG-22 Zones

Each zone has the following fundamental characteristics:

• Every zone contains one or more separate, routable networks;
• Every separate, routable network is contained within a single zone;
• Every zone connects to another zone via a perimeter that contains zone interface points (ZIPs); and
• The only zone that may connect to the public zone is the PAZ.

Zones where all components are entirely within or under the control of the GC department are considered controlled zones. In the case where the GC does not control all zone components, the zone is considered uncontrolled.

Data communications entering and leaving a zone must conform to the data communication control requirements set by the policy for that zone.

A zone is a construct to define standard baseline security requirements that if adopted by GC departments will lead to consistency in their implementation of network security. It demarcates a logical area within a networking environment with a defined level of network security. Zones define the network boundaries and their associated perimeter defence requirements. As described in ITSG-22, zones achieved these network boundaries by:

• Authenticating the identity of network entities.

The public zone is entirely open and includes public networks such as the public Internet, the public switched telephone network, and other public carrier backbone networks and services. Restrictions and requirements are difficult or impossible to place or enforce on this zone because it is normally outside the control of the GC. The public zone environment is assumed extremely hostile. [Reference 4]

A PAZ mediates access between operational GC systems and the public zone. The interfaces to all government on-line services should be implemented in a PAZ. Proxy services that allow GC personnel to access Internet-based applications should be implemented in a PAZ, as should external e-mail, remote access, and extranet gateways. [Reference 4]

A demilitarized zone (DMZ) is a component within a PAZ and is not discussed in this guideline.

An OZ is the standard environment for routine GC operations and is where most end-user systems and workgroup servers are installed. With appropriate security controls at the end-systems, this zone may be suitable for processing sensitive information; however, it is generally unsuitable for large repositories of sensitive data or critical applications without additional strong, trustworthy security controls that are beyond the scope of this guideline.

Within an OZ, traffic is generally unrestricted and can originate internally or from authorized external sources via the PAZ. Examples of external traffic sources include remote access, mobile access, and extranets. Malicious traffic may also originate from hostile insiders, from hostile code imported from the public zone, or from undetected malicious nodes on the network (for example, compromised host, or unauthorized wireless attachment to the Zone). [Reference 4]

An RZ provides a controlled network environment generally suitable for business-critical IT services (that is, those having medium reliability requirements, where compromise of the IT services would cause a business disruption) or large repositories of sensitive information (for example, a data centre). It supports access from systems in the public zone via a PAZ. [Reference 4]

2.2 Zone Interface Point (ZIP)

A ZIP provides a network interface between a zone and another zone. ZIPs are the logical construct used to describe the controlled interfaces connecting the zones. ZIPs enforce zone data communication policy through perimeter security measures. ZIPs are only discussed in this guideline to bridge the understanding from ITSG-22 ZIPs to perimeters.

ZIPs have the following fundamental characteristics:

• Every ZIP controls inbound data communication;
• ZIPs implement the security policy of their respective zones; and
• All data communication must be through a ZIP Footnote 1 .

The exception to these characteristics is the ZIP required between the PZ and PAZ. The PAZ ZIP must enforce the zone policy requirements for both inbound and outbound traffic because the GC has no control over the PZ and there is no PZ ZIP. This key point is illustrated in Figure 3 below.

In this guidance, a logical construct called a perimeter contains the ZIPs.

As shown in Figure 4 below, the perimeter contains both ZIPs (OZ and RZ ZIPs) and controls the data communication in both directions.

A perimeter is composed of security devices and network devices and represents the ZIPs of each adjacent zone as shown in Figure 5 below.

Using the concept of a perimeter that contains the two ZIPs simplifies the architecture diagrams, but does not change the requirements of ITSG-22 to control data communication in both directions (inbound and outbound) for each zone.

Physical implementations of perimeters (or ZIPs) can be accomplished using a single component or a combination of components as shown in Figure 6 . Figure 6 also shows the perimeter is equivalent to the two ZIPs (for example, RZ connecting to the OZ) and the sample physical implementation (for example, firewall, IPS, IDS, and Routers). For example, a router (a network device) may implement part of the perimeter, but it must be used in conjunction with an intrusion prevention system (a security device) and other security devices, which together provide appropriate security safeguards.

Physical representations provided in Figure 6 are examples only and do not indicate a preference of design or approach.

A service can be accessed from other adjacent zones and not just the zone in which it resides.

The following list of services represents the most typical required for an IT infrastructure. The list is not exhaustive.

4 Placement of Services

This section presents the Internet services network zone architecture and the Departmental network zone architecture to illustrate the placement of services.

The example architectures describe the purpose of the network, placement of services, context of the zones within the network zone architecture, and communication policies implemented in the perimeters.

The primary purpose of the internet services network is to provide Unclassified (Protected B and below) business application delivery via the Internet to the public. The Internet services network, illustrated in Figure 7 , is built with four controlled zones consisting of the following:

• Data tier services RZ;
• Application tier internet services RZ;
• Management RZ; and
• the PAZ that connects to the PZ (Internet, SCNet).

In this architecture, business applications are hosted within GC departments and accessed by the public through the Internet and the SCNet.

In section 3 , a list of services was defined. For the Internet services network zone architecture, the following service are typically required:

• External Domain Name Service
• Email Proxy Service
• Reverse Proxy Service
• Presentation Tier Internet Service
• Internal Domain Name Service
• Time Service
• Authentication Service
• Email Service
• Application Tier Internet Service
• Data Tier Internet Service
• Auditing Service
• Backup Service
• IT Administration Service
• Security Administration Service

In the list below, the placements of services in the four zones of Internet Services Network are listed.

Application Tier Internet Services RZ

Data tier rz, management rz.

The departmental network delivers Unclassified (including Protected A or Protected B) business applications to public servants. The departmental network is built with the following zones:

• the PAZ that connects to the public zone.

The network zone architecture for the departmental network is illustrated in Figure 8 , where business applications are hosted within GC departmental networks and accessed by public servants. The public servants typically access their business applications from within their departmental network, or over the Secure Channel Network (SCNet) Virtual Private Network (VPN).

In section 3 , a list of services was defined. For the departmental network zone architecture, the following services are required:

• Application Authentication Service
• Critical Data Service
• Data Service
• Desktop Service
• Extranet Service
• Forward (Web) Proxy Service
• Internal Intranet Service
• Voice over IP Service

In the list below, the placement of service in the four zones is shown for the departmental network:

• Forward (Web) Proxy
• Remote Access Service
• Data Services
• Voice Over IP Service
• Critical Data Services

4.3 Context for Departmental and Internet Services Networks

For the zone architecture for Departmental and Internet services networks, each zone has a specific purpose and defined set of characteristics. In the following sub-section, the four types of zones will be described in the context of the Departmental network zone architecture and Internet services network zone architecture. These architectures are illustrated in Figure 9 and Figure 10 respectively.

Public zones are part of the global information infrastructure (Internet). Public carrier backbone networks like the Secure Channel Network and private lines are considered uncontrolled and are therefore treated as public zones because these networks are not owned, managed, and physically controlled by the GC.

4.3.2.1 Usage

The public access zone (PAZ) contains internet related services for external clients. It does not retain any sensitive information, but passes it across the network to other zones. Sensitive information is stored in other zones that are not directly connected to the public zone. The PAZ perimeter to the public zone implements security safeguards that protect PAZ services in the controlled zones (PAZ, OZ, and RZ).

4.3.2.2 Communication Policy to/from the Public Zone

All inbound communication terminates at a service such as a proxy service or email service within the PAZ after being processed at the perimeter.

All other inbound communication that does not terminate at an IT service within the PAZ is blocked.

In some circumstances there may be no proxy service available to terminate specific protocols in the PAZ. This circumstance applies primarily, but not exclusively, to encrypted protocols such as TLS (Transport Layer Security) and SFTP (Secure File Transfer Protocol). A risk assessment should be performed to determine the risks associated with terminating such traffic in the OZ, and the requirement for additional security controls.

All inbound and outbound communication to the public zones should be restricted by blocking network addresses using a black list. Black lists contain a list of public zone network addresses which are unallocated, or are a well-known source of malicious data and/or communication. Black lists are provided through commercial vendors, carriers, and government agencies.

All outbound communications must be filtered so that only valid internal department address ranges are allowed to communicate to the PZ.

4.3.2.3 Communication Policy to/from the Operations Zone and Restricted Zone

All communication between the PAZ and the other controlled zones (OZ and RZ) should be processed by the perimeter and white listed. In case of a departmental network, the OZ email service can only communicate with the PAZ email proxy service. The OZ desktop service must use the PAZ web proxy service, which in turn communicates with the PZ web services. Figure 11 below illustrates the communications paths from the PZ to the RZ.

4.3.2.4 Communication Policy to/from the OZ, PAZ, RZ to Management RZ

All communication between the RZ management zone and the other controlled zones (PAZ, OZ, and RZ) should be processed by the perimeter and white listed. Figure 11 illustrates the communications paths from the PZ to the RZ.

4.3.3.1 Usage

Most government activities take place in the controlled zone. OZ systems are allowed filtered access to the PZ for legitimate government activities. OZ computer platforms accessing the PZ will be filtered by Internet proxy services and perimeters in the PAZ.

For example, workstations, printers, and VoIP terminals would be located in the OZ.

4.3.3.2 Communication Policy to/from the Public Zone

OZ services do not communicate directly with the public zone. Encrypted IT service examples such as SSH and HTTPS cannot be properly proxied through the PAZ and should either be denied or white listed using access controls.

White listing is enforcing a set of approved addresses and protocols. A risk assessment should be performed to assess the risk to the network if a protocol cannot be terminated within the PAZ through a proxy.

If the risk assessment results are acceptable to the department, then communications may go through the PAZ and terminate within the OZ.

4.3.3.3 Communication Policy Inbound from the Public Access Zone and Restricted Zone

All communication between the OZ and other controlled zones (RZ and PAZ) should be processed by the perimeter and white listed. The desktop service (web browsing for example) should only communicate with the PAZ web proxy service.

4.3.4.1 Usage

Restricted zones (RZs) contain services for the Departmental and Internet services network operations that require additional safeguards from threats originating from the controlled zones.

For the departmental network, critical data services that need to be protected from the OZ are located in the restricted zone.

The data tier internet services are located in the restricted zone (3rd layer) Footnote 3 . This configuration was illustrated in Figure 10 . In certain commercial-off-the-shelf applications, the application and data tier services may be bundled in a single product. This restriction would necessitate that the application and data service be deployed in the RZ (2nd tier) instead of an RZ (3rd Tier). The three layer approach is the preferred security architecture because a perimeter can be placed between the application and the database services.

4.3.4.2 Communication Policy Inbound from the Public Zone

RZ services do not communicate with the public zone directly.

4.3.4.3 Communications Policy Inbound from the Operations Zone and Public Access Zone

All communication between the RZ and other controlled zones should be processed by the perimeter and white listed. RZs only communicate directly with the OZ and the other RZs. The exception is if the RZ is the management RZ which also communicates with the PAZ.

4.3.5.1 Usage

Departmental and Internet services network architectures have a restricted zone designed specifically for management called the management RZ. This zone contains IT administration related services for the Departmental and Internet services network operations.

4.3.5.2 Communication Policy to/from the Public Zone

Services located in the management RZ only communicate with the public zone via the PAZ for updates from a vendor network sites using appropriate security safeguards that protect integrity and confidentiality of the communication and authenticate the vendor network address.

4.3.5.3 Communication Policy to/from the OZ, PAZ, and RZ

All communication between the RZ and other controlled zones should be processed by the perimeter and white listed. The management RZ communicates with all controlled zones (OZ, RZ, and PAZ).

4.3.6.1 Usage

Departmental and Internet services network architectures have a restricted zone designed specifically for the application tier internet services called the application tier internet services RZ. This zone contains application tier internet services.

4.3.6.2 Communication Policy to/from the Public Zone

Management RZ services only communicate with the public zone via the PAZ for updates from controlled vendor network sites using appropriate security controls that protect integrity and confidentiality of the communication and authenticate the controlled vendor network address.

4.3.6.3 Communication Policy to/from the OZ, PAZ, and RZ

All communication between the RZ and other controlled zones should be processed by the perimeter and white listed. The management RZ communicates with all controlled zones (RZs and PAZ).

• [Reference 1] National Information Assurance (IA) Glossary [PDF Version, 827 Kb], CNSS Instruction No. 4009, Committee on National Security Systems, National Security Agency, June 2006 [cited 6 November 2006].
• [Reference 2] Internet Security Glossary, Version 2 [Text Version, 293 Kb]
• [Reference 3] Baseline Security Architecture for GC IT Infrastructures, Communication Security Establishment Canada. 2009.
• [Reference 4] ITSG-22, Baseline Security Requirements for Network Security Zones in the Government of Canada, Communications Security Establishment. Canada. 2007
• [Reference 5] ITIL® V3 Glossary v01, 30 May 2007 [PDF Version, 395 Kb]
• [Reference 6] NIST SP 800-53 rev 3 – Recommended Security Controls for Federal Information Systems, National Institute of Standards and Technologies. February 2009.
• [Reference 7] SHIREY, Robert W. Request for Comments: 2828 – Internet Security Glossary [Text Version, 489 Kb] . The Internet Society, May 2000 [cited 25 January 2006].

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Thank you for your help!

You will not receive a reply. For enquiries, please contact us .

DMZ Networks

• Fortinet Named a Leader in the 2022 Gartner® Magic Quadrant™ for Network Firewall

What is a DMZ Network?

A DMZ  or demilitarized zone is a perimeter network that protects and adds an extra layer of security to an organization’s internal local-area network from untrusted traffic.

The end goal of a demilitarized zone network is to allow an organization to access untrusted networks, such as the internet, while ensuring its private network or LAN remains secure. Organizations typically store external-facing services and resources, as well as servers for the Domain Name System (DNS) , File Transfer Protocol (FTP) , mail, proxy, Voice over Internet Protocol (VoIP), and web servers, in the DMZ. 

These servers and resources are isolated and given limited access to the LAN to ensure they can be accessed via the internet but the internal LAN cannot. As a result, a DMZ approach makes it more difficult for a hacker to gain direct access to an organization’s data and internal servers via the internet. A company can minimize the vulnerabilities of its Local Area Network, creating an environment safe from threats while also ensuring employees can communicate efficiently and share information directly via a safe connection.

How Does a DMZ Network Work?

Businesses with a public website that customers use must make their web server accessible to the internet. To protect the corporate local area network, the web server is installed on a separate computer from internal resources. The DMZ enables communication between protected business resources, like internal databases, and qualified traffic from the Internet.

A DMZ network provides a buffer between the internet and an organization’s private network. The DMZ is isolated by a security gateway, such as a firewall, that filters traffic between the DMZ and a LAN. The default DMZ server is protected by another security gateway that filters traffic coming in from external networks.

It is ideally located between two firewalls, and the DMZ firewall setup ensures incoming network packets are observed by a firewall—or other security tools—before they make it through to the servers hosted in the DMZ. This means that even if a sophisticated attacker is able to get past the first firewall, they must also access the hardened services in the DMZ before they can do damage to a business.

If an attacker is able to penetrate the external firewall and compromise a system in the DMZ, they then also have to get past an internal firewall before gaining access to sensitive corporate data. A highly skilled bad actor may well be able to breach a secure DMZ, but the resources within it should sound alarms that provide plenty of warning that a breach is in progress.

Organizations that need to comply with regulations, such as the Health Insurance Portability and Accountability Act (HIPAA), will sometimes install a proxy server in the DMZ. This enables them to simplify the monitoring and recording of user activity, centralize web content filtering, and ensure employees use the system to gain access to the internet.

Benefits of Using a DMZ

The main benefit of a DMZ is to provide an internal network with an advanced security layer by restricting access to sensitive data and servers. A DMZ enables website visitors to obtain certain services while providing a buffer between them and the organization’s private network. As a result, the DMZ also offers additional security benefits, such as:

• Enabling access control: Businesses can provide users with access to services outside the perimeters of their network through the public internet. The DMZ enables access to these services while implementing network segmentation to make it more difficult for an unauthorized user to reach the private network. A DMZ may also include a proxy server, which centralizes internal traffic flow and simplifies the monitoring and recording of that traffic.
• Preventing network reconnaissance: By providing a buffer between the internet and a private network, a DMZ prevents attackers from performing the reconnaissance work they carry out the search for potential targets. Servers within the DMZ are exposed publicly but are offered another layer of security by a firewall that prevents an attacker from seeing inside the internal network. Even if a DMZ system gets compromised, the internal firewall separates the private network from the DMZ to keep it secure and make external reconnaissance difficult.
• Blocking Internet Protocol (IP) spoofing: Attackers attempt to find ways to gain access to systems by spoofing an IP address and impersonating an approved device signed in to a network. A DMZ can discover and stall such spoofing attempts as another service verifies the legitimacy of the IP address. The DMZ also provides network segmentation to create a space for traffic to be organized and public services to be accessed away from the internal private network.

Services of a DMZ include:

• DNS servers
• FTP servers
• Mail servers
• Proxy servers
• Web servers

DMZ Design and Architecture

A DMZ is a “wide-open network," but there are several design and architecture approaches that protect it. A DMZ can be designed in several ways, from a single-firewall approach to having dual and multiple firewalls. The majority of modern DMZ architectures use dual firewalls that can be expanded to develop more complex systems.

• Single firewall: A DMZ with a single-firewall design requires three or more network interfaces. The first is the external network, which connects the public internet connection to the firewall. The second forms the internal network, while the third is connected to the DMZ. Various rules monitor and control traffic that is allowed to access the DMZ and limit connectivity to the internal network.
• Dual firewall: Deploying two firewalls with a DMZ between them is generally a more secure option. The first firewall only allows external traffic to the DMZ, and the second only allows traffic that goes from the DMZ into the internal network. An attacker would have to compromise both firewalls to gain access to an organization’s LAN.

Organizations can also fine-tune security controls for various network segments. This means that an intrusion detection system (IDS) or intrusion prevention system (IPS) within a DMZ could be configured to block any traffic other than Hypertext Transfer Protocol Secure (HTTPS) requests to the Transmission Control Protocol (TCP) port 443.

The Importance of DMZ Networks: How Are They Used?

DMZ networks have been central to securing global enterprise networks since the introduction of firewalls. They protect organizations’ sensitive data, systems, and resources by keeping internal networks separate from systems that could be targeted by attackers. DMZs also enable organizations to control and reduce access levels to sensitive systems.

Enterprises are increasingly using containers and virtual machines (VMs) to isolate their networks or particular applications from the rest of their systems. The growth of the cloud means many businesses no longer need internal web servers. They have also migrated much of their external infrastructure to the cloud by using Software-as-a-Service (SaaS) applications. 

For example, a cloud service like Microsoft Azure allows an organization that runs applications on-premises and on virtual private networks (VPNs) to use a hybrid approach with the DMZ sitting between both. This method can also be used when outgoing traffic needs auditing or to control traffic between an on-premises data center and virtual networks.

Further, DMZs are proving useful in countering the security risks posed by new technology such as Internet-of-Things (IoT) devices and operational technology (OT) systems, which make production and manufacturing smarter but create a vast threat surface. That is because OT equipment has not been designed to cope with or recover from cyberattacks the way that IoT digital devices have been, which presents a substantial risk to organizations’ critical data and resources. A DMZ provides network segmentation to lower the risk of an attack that can cause damage to industrial infrastructure.

Frequently Asked Questions about DMZ in Cybersecurity

Is a dmz safe.

The DMZ network itself is not safe. It enables hosts and systems stored within it to be accessible from untrusted external networks, such as the internet, while keeping other hosts and systems on private networks isolated. The main purpose of using a DMZ network is that it can add a layer of protection for your LAN, making it much harder to access in case of an attempted breach.

What is the benefit of DMZ?

A DMZ provides an extra layer of security to an internal network. It restricts access to sensitive data, resources, and servers by placing a buffer between external users and a private network. Other benefits include access control, preventing attackers from carrying out reconnaissance of potential targets, and protecting organizations from being attacked through IP spoofing.

Should you use a DMZ on your router?

A DMZ can be used on a router in a home network. The DMZ router becomes a LAN, with computers and other devices connecting to it. Some home routers also have a DMZ host feature that allocates a device to operate outside the firewall and act as the DMZ. All other devices sit inside the firewall within the home network. A gaming console is often a good option to use as a DMZ host. It ensures the firewall does not affect gaming performance, and it is likely to contain less sensitive data than a laptop or PC.

Related Reads

White papers, quick links.

Free Product Demo

Explore key features and capabilities, and experience user interfaces.

Resource Center

Download from a wide range of educational material and documents.

Free Trials

Test our products and solutions.

Contact Sales

Have a question? We're here to help.

JavaScript must be enabled in your browser to use this website without limitations.

Best Firewall Security Zone Segmentation for Optimal Network Security

Posted by Geraldine Hunt on Wed, Mar 29th, 2023

Hardware firewalls are the cornerstone of network security for almost all TCP/IP networks. Whether it’s small business networks or large enterprise environments, a network firewall provides a primary defense against cybersecurity events targeting corporate infrastructure systems and digital information assets. Modern networks have expanded outside the firewall perimeter, making firewalls more critical than ever. Most corporate networks have an expanded design beyond an internal environment, including intranets on internal network zone, untrusted demilitarized zone (DMZ), and other optional intermediate security zones.

A security zone is a network segment that hosts a group of systems with similar functionality for information protection. In other words, a security zone is usually a layer3 network subnet where several hosts (e.g., servers and workstations) are connected. A layer 3 firewall then controls traffic to and from this specific network by analyzing and allowing traffic using an IP address and port. 

Some firewalls work on layer 7 of the OSI model. Layer 7 firewalls control authorized traffic on the application layer, evaluating input sent to various internal services such as a database or a web server. For example, suppose you have an application firewall that protects the database from a public-facing web server. When users send input to the web server, the web server then sends the input to the database. An application firewall analyzes information for malformed input such as cross-site scripting (XSS) or SQL injection (SQLi) and rejects input if malicious activity is detected.

Perimeter Security Zone Segmentation for Enterprise Networks

Every enterprise network has its unique environment, so a security zone network segment will look different from business to business. Each perimeter network topology will only fit some enterprise network environments. In addition, each network has its unique requirements and functionalities so that IT teams can create security infrastructure designs based on your business model, employee activity (e.g., remote employees and on-site employees), and any public-facing applications.

Even with unique requirements, organizations should still follow best practices. A “best practice” approach to implementing a network perimeter offers enhanced security and data protection from common cybersecurity attacks. A general best practice approach is illustrated in the diagram below. Again, the defined network topology is just an example shared in enterprise networks. Still, every organization will have variations from the example design, such as using two firewall devices instead of one or only one DMZ zone instead of two. However, a firewall protects the internal corporate environments from the public internet. In some designs, two firewalls protect the DMZ and internal network from the public internet.

The suggested perimeter network above includes two DMZ (Demilitarized Zones), DMZ1 and DMZ2, and an Internal Zone for authorized users only. The red line arrows indicate the authorized traffic flow from the firewall. Notice that the public internet can only access one DMZ, which is common when corporations host their servers and internal applications available to the public. A DMZ zone is commonly open to the public internet and internally authorized employees, so it’s considered partially secure. However, traffic should never flow directly from the DMZ to the internal network without additional firewalls and security protocols.

Why Have a DMZ Zone?

A DMZ zone is an isolated layer3 subnet on which connected hosts are usually exposed to the public internet to provide services to users such as web applications, email communications, and DNS services. DMZ environments are the most vulnerable to cybersecurity attacks, as these zones take input from the public internet and allow access to services from internet users. Because of the increased cyber risks associated with a DMZ’s infrastructure and services, DMZ security is maximized to limit damage to the internally protected network should one of these servers suffer from a cybersecurity event resulting in a compromise. The strategy contains a compromised server within the DMZ, so internal applications are protected from data exfiltration, malware, ransomware, and eavesdropping.

A DMZ is necessary if an organization hosts any application available on the public-facing internet. Usually, they are reserved for organizations using on-premises services, but a security engineer might set up DMZ in a hybrid cloud environment. Organizations with cloud-hosted services must also set up a protected zone when private cloud applications are hosted on the same network. It often requires professional help and penetration testing for an organization to set up a DMZ and correctly configure the environment with the proper security controls.

Enhance your network security with WebTitan DNS filtering solution. Book a free demo

DMZ1 – Publicly Available Applications

This zone hosts the public-facing servers which must be accessible from the Internet. This zone usually hosts services such as Web, Email, DNS, Proxy etc. The firewall should allow traffic from the Internet towards DMZ1 only (see Traffic Line 1 above). Also, only the required TCP/UDP ports must be allowed (such as 80, 443, 25 etc).

DMZ2 – Intermediary Between Internal and External Networks

DMZ2, on the diagram, is an intermediary zone set up to host application servers, database servers, and other services available to both the public internet and internal employees. To protect the internal environment from the public internet, DMZ2 acts as an intermediary between public users. Creating an additional step from the public internet to DMZ2 reduces risks from a compromise and cybersecurity event. For example, a threat might compromise a service on DMZ1, but it still must compromise another security layer before reaching the internal environment. 

Some enterprise environments have a public-facing web server and a web-based application dedicated to employee productivity. For example, a web-based customer service application might pull data from a publicly available web application. In this example, the front-end public web server should communicate with a web application server in a separate security zone. The example diagram has a web application in DMZ1 and an employee-accessible web server in DMZ2.

Security experts suggest that a web application sending and receiving data on a database must not be installed on the same physical machine as the database server. Separating physical devices adds a layer of security, requiring cyber-attackers to compromise two separate environments, which reduces risks. The added layer also increases the chance that intrusion protection services will detect anomalous behavior and alert administrators before both machines can be compromised. Mitigating risks is the primary goal for security infrastructure, and no environment is completely protected against all cyber threats.

The above arrangement protects the internal private network since any compromise of the database or application servers via the DMZ1 servers will not result in access to the protected internal network.  Network security always works in layers ; the two DMZ environments add t hese layers to the protected internal environment.

In the diagrammed example, the firewall is configured to only allow access to DMZ2 from DMZ1 on authorized ports indicated by the red line labeled “2.” Also, DMZ2 has limited access to and from the internal zone, indicated by the red line “3.” Traffic flow from the internal network to DMZ2 is set for exceptional cases, such as accessing an internal management server, automated backup procedures, or authentication services on an Active Directory server. All these exceptional cases are examples, but an enterprise environment might have these scenarios or more when firewalls are configured between DMZ environments.     

Internal Security Zone

This zone usually hosts internal user workstations and other critical servers such as file servers, Active Directory servers, internal databases, specialized applications (ERP, accounting software), etc. The firewall must not allow direct access from the internet to this Internal network. Moreover, outgoing Web traffic from users in this network can use an HTTP Proxy server (see Traffic Line 4) located in DMZ1 to access the internet. Companies can implement countless network perimeter topologies to facilitate their business needs. The discussion above suggests a solid firewall zone segmentation to achieve strong network security in an enterprise environment. 

Use this, and it should ensure you have solid network security.

A Few Other Firewall Configuration Best Practices

The example diagram won’t represent every enterprise network, but it means a  robust network security  environment. Here are a few best practices you can incorporate into your firewall configurations and infrastructure design:

• Keep audit logs: Logs are necessary for investigations and analysts to detect suspicious behavior. Keep logs based on your retention plan to support incident response after a cyber event.
• Default deny: It’s better to allow traffic rather than default allow all traffic except on specific ports. Set firewalls to allow only traffic necessary for business services. 
• Label everything: Firewalls allow administrators to label rules, and labeling helps other administrators understand traffic flow. Labeling rules avoid any mistakes in configurations that could be detrimental to the security of your environment.
• Secure administrator accounts: Use strong passwords on accounts with permission to change firewall settings and rotate passwords and keys regularly to reduce the window of opportunity during an account compromise.
• Always test configurations: Before deploying a firewall to production, test settings and ensure traffic flow is as expected.
• Update firmware: Security patches are essential to the security of your environment, and developers deploy firmware updates to address specific security vulnerabilities. By keeping firewalls updated, patches known vulnerabilities that could threaten the integrity of your entire environment.
• Regularly audit firewall configurations: Changes happen even after testing a firewall before deployment to production. Administrators should devise a plan to periodically audit firewall settings to ensure that no new changes alter the security of your network environment. 
• Configure firewalls using the least privilege principle: The least privilege principle says that users should only have access to data necessary to perform their job function. Firewall configurations should follow this strategy to avoid an overly permissive traffic flow, which could lead to an unexpected system compromise.
• Use a change management plan: Firewall changes affect traffic flow, so they can negatively impact security, network availability, and integrity. Design a change management plan to determine the best time of the day to deploy changes and warn users that the change may impact the availability of applications.
• Have a rollback plan: If changes or a firewall negatively impact network availability after deployment, have a rollback plan ready to return the network to its initial state.
• Automate repeatable tasks: Administrators using automation are much less likely to make mistakes, so automate repeatable tasks when you can. 

Read TitanHQs Complete Network Security Checklist

Are you an IT professional who wants to protect your internal data and network environment? 

Talk to a security specialist at TitanHQ for help or email us at [email protected] with any questions.

Related Articles

Cisco Umbrella Roaming Client- End-of-Life

The imminent Cisco Umbrella Roaming Client End-of-Life has left many users uncertain about their next steps and exploring alternative DNS protection.

Chromebook Content Filtering for K12 Schools and Why it’s Essential

School districts around the world over are issuing Chromebooks to students to help close equity, technology and homework gaps. Discover why and how to protect K12 students.

The Threat of QR Code Phishing

A 2024 report highlights the soaring popularity of QR codes, with a 47% yearly usage surge. However, cybercriminals are exploiting this trend, targeting unsuspecting users with scams and malware infections due to...

Never Miss a Blog Post

Sign-up for email updates...

Talk to Our Email and DNS Security Team

Call us on UK/EU +44 203 808 5467

Your browser is out-of-date!

Update your browser to view this website correctly. Update my browser now

What is a landing zone?

A landing zone is a well-architected, multi-account AWS environment that is scalable and secure. This is a starting point from which your organization can quickly launch and deploy workloads and applications with confidence in your security and infrastructure environment. Building a landing zone involves technical and business decisions to be made across account structure, networking, security, and access management in accordance with your organization’s growth and business goals for the future.

When you start to use AWS at scale, you can look to AWS for prescriptive guidance and an approach for establishing your environment. AWS best practices in this area center around the need to isolate resources and workloads into multiple AWS accounts (resource containers) for isolation and scope of impact reductions. The next section explains why you want to use multiple accounts.

The multi-account framework

While there is no one-size-fits-all answer for how many AWS accounts you should have, we recommend that you create more than one AWS account. Multiple accounts provide the highest level of resource and security isolation. Consider creating additional AWS accounts if you answer yes to any of the following questions:

Does your business require administrative isolation between workloads?

Does your business require limited visibility and discoverability of workloads?

Does your business require isolation to minimize the scope of impact?

Does your business require strong isolation of recovery and/or auditing data?

Here are other reasons why a single account might not be enough:

Security controls – Different applications might have different security profiles, requiring different control policies and mechanisms around them. It’s easier to talk to an auditor and point to a single account hosting the Payment Card Industry (PCI) workload.

Isolation – An account is a unit of security protection. Potential risks and security threats should be contained within an account without affecting others. There could be different security needs that require you to isolate one account from one another, whether due to multiple teams or a different security profile.

Data isolation – Isolating data stores to an account limits the number of people that can access and manage that data store. This contains exposure to highly private data and helps with General Data Protection Regulation (GDPR) compliance.

Many teams – Different teams have their different responsibilities and resource needs. They should not over-step one another in the same account.

Business process – Different business units or products might have different purposes and processes. You should establish different accounts to serve business-specific needs.

Billing – An account is the only true way to separate items at a billing level, including things like transfer charges. Multiple accounts help separate items at a billing level across business units, functional teams, or individual users.

Limit allocation – Limits are per account. Separating workloads into different accounts prevents them from consuming limits or potentially overprovisioning resources and then preventing other applications from working as intended.

To use the Amazon Web Services Documentation, Javascript must be enabled. Please refer to your browser's Help pages for instructions.

Thanks for letting us know we're doing a good job!

If you've got a moment, please tell us what we did right so we can do more of it.

Thanks for letting us know this page needs work. We're sorry we let you down.

If you've got a moment, please tell us how we can make the documentation better.

• Español – América Latina
• Português – Brasil
• Cloud Architecture Center

Decide the network design for your Google Cloud landing zone

When you design your landing zone, you must choose a network design that works for your organization. This document describes four common network designs, and helps you choose the option that best meets your organization's requirements, and your organization's preference for centralized control or decentralized control. It's intended for network engineers, architects, and technical practitioners who are involved in creating the network design for your organization's landing zone.

This article is part of a series about landing zones .

Choose your network design

The network design that you choose depends primarily on the following factors:

• Centralize control over the network including IP addressing, routing, and firewalling between different workloads.
• Give your teams greater autonomy in running their own environments and building network elements within their environments themselves.
• On-premises or hybrid cloud connectivity options: All the network designs discussed in this document provide access from on-premises to cloud environments through Cloud VPN or Cloud Interconnect . However, some designs require you to set up multiple connections in parallel, while others use the same connection for all workloads.
• Security requirements: Your organization might require traffic between different workloads in Google Cloud to pass through centralized network appliances such as next generation firewalls (NGFW) . This constraint influences your Virtual Private Cloud (VPC) network design.
• Scalability: Some designs might be better for your organization than others, based on the number of workloads that you want to deploy, and the number of virtual machines (VMs), internal load balancers, and other resources that they will consume.

Decision points for network design

The following flowchart shows the decisions that you must make to choose the best network design for your organization.

The preceding diagram guides you through the following questions:

• If yes, see Hub-and-spoke topology with centralized appliances .
• If no, proceed to the next question.
• If yes, go to decision point 4.
• If yes, see Expose services in a consumer-producer model with Private Service Connect .
• If yes, see Shared VPC network for each environment .
• If no, see Hub-and-spoke topology without appliances .

This chart is intended to help you make a decision, however, it can often be the case that multiple designs might be suitable for your organization. In these instances, we recommend that you choose the design that fits best with your use case.

Network design options

The following sections describe four common design options. We recommend option 1 for most use cases. The other designs discussed in this section are alternatives that apply to specific organizational edge-case requirements.

The best fit for your use case might also be a network that combines elements from multiple design options discussed in this section. For example, you can use Shared VPC networks in hub-and-spoke topologies for better collaboration, centralized control, and to limit the number of VPC spokes. Or, you might design most workloads in a Shared VPC topology but isolate a small number of workloads in separate VPC networks that only expose services through a few defined endpoints using Private Service Connect .

Option 1: Shared VPC network for each environment

We recommend this network design for most use cases. This design uses separate Shared VPC networks for each deployment environment that you have in Google Cloud (development, testing, and production). This design lets you centrally manage network resources in a common network and provides network isolation between the different environments.

Use this design when the following is true:

• You want central control over firewalling and routing rules.
• You need a simple, scalable infrastructure.
• You need centralized IP address space management.

Avoid this design when the following is true:

• You want developer teams to have full autonomy, including the ability to manage their own firewall rules, routing, and peering to other team networks.
• You need Layer 7 inspection using NGFW appliances.

The following diagram shows an example implementation of this design.

The preceding diagram shows the following:

• The on-premises network is spread across two geographical locations.
• The on-premises network connects through redundant Cloud Interconnect instances to two separate Shared VPC networks, one for production and one for development.
• The production and development environments are connected to both Cloud Interconnect instances with different VLAN attachments .
• Each Shared VPC has service projects that host the workloads.
• Firewall rules are centrally administered in the host project.
• The development environment has the same VPC structure as the production environment.

By design, traffic from one environment cannot reach another environment. However, if specific workloads must communicate with each other, you can allow data transfer through controlled channels on-premises, or you can share data between applications with Google Cloud services like Cloud Storage or Pub/Sub . We recommend that you avoid directly connecting separated environments through VPC Network Peering, because it increases the risk of accidentally mixing data between the environments. Using VPC Network Peering between large environments also increases the risk of hitting VPC quotas around peering and peering groups.

For more information, see the following:

• Shared VPC overview
• Shared VPC architecture in the enterprise foundations guide
• Reference architecture in VPC design best practices
• Terraform deployment stage: Networking with separate environments as part of Fabric FAST framework
• Network stage for Terraform example foundation using Cloud Foundation toolkit

To implement this design option, see Create option 1: Shared VPC network for each environment .

Option 2: Hub-and-spoke topology with centralized appliances

This network design uses hub-and-spoke topology. A hub VPC network contains a set of appliance VMs such as NGFWs that are connected to the spoke VPC networks that contain the workloads. Traffic between the workloads, on-premises networks, or the internet is routed through appliance VMs for inspection and filtering.

• You require Layer 7 inspection between different workloads or applications.
• You have a corporate mandate that specifies the security appliance vendor for all traffic.
• You don't require Layer 7 inspection for most of your workloads.
• You want workloads on Google Cloud to not communicate at all with each other.
• You only need Layer 7 inspection for traffic going to on-premises networks, as described in Special use case with one shared VPC network on Google Cloud .

The following diagram shows an example implementation of this pattern.

• A production environment which includes a hub VPC network and multiple spoke VPC networks that contain the workloads.
• The spoke VPC networks are connected with the hub VPC network by using VPC Network Peering.
• The hub VPC network has multiple instances of a virtual appliance in a managed instance group. Traffic to the managed instance group goes through an internal passthrough Network Load Balancer.
• The spoke VPC networks communicate with each other through the virtual appliances by using static routes with the internal load balancer as the next hop.
• Cloud Interconnect connects the transit VPC networks to on-premises locations.
• On-premises networks are connected through the same Cloud Interconnects using separate VLAN attachments.
• The transit VPC networks are connected to a separate network interface on the virtual appliances, which lets you inspect and filter all traffic to and from these networks by using your appliance.
• This setup doesn't use source network address translation (SNAT). SNAT isn't required because Google Cloud uses symmetric hashing . For more information see Symmetric hashing .

By design, traffic from one spoke network cannot reach another spoke network. However, if specific workloads must communicate with each other, you can set up direct peering between the spoke networks using VPC Network Peering, or you can share data between applications with Google Cloud services like Cloud Storage or Pub/Sub.

To maintain low latency when the appliance communicates between workloads, the appliance must be in the same region as the workloads. If you use multiple regions in your cloud deployment, you can have one set of appliances and one hub VPC for each environment in each region. Alternatively, you can use network tags with routes to have all instances communicate with the closest appliance.

Firewall rules can restrict the connectivity within the spoke VPC networks that contain workloads. Often, teams who administer the workloads also administer these firewall rules. For central policies, you can use hierarchical firewall policies . If you require a central network team to have full control over firewall rules, consider centrally deploying those rules in all VPC networks by using a GitOps approach . In this case, restrict the IAM permissions to only those administrators who can change the firewall rules. Spoke VPC networks can also be Shared VPC networks if multiple teams deploy in the spokes.

In this design, we recommend that you use VPC Network Peering to connect the hub VPC network and spoke VPC networks because it adds minimum complexity. However, the maximum number of spokes is limited by the following:

• The limit on VPC Network Peering connections from a single VPC network.
• Peering group limits such as the maximum number of forwarding rules for the internal TCP/UDP Load Balancing for each peering group.

If you expect to reach these limits, you can connect the spoke networks through Cloud VPN. Using Cloud VPN adds extra cost and complexity and each Cloud VPN tunnel has a bandwidth limit.

• Centralized network appliances on Google Cloud
• Hub and spoke transitivity architecture in the enterprise foundations guide
• Terraform deployment stage: Networking with Network Virtual Appliance as part of the Fabric FAST framework
• Terraform hub-and-spoke transitivity module as part of the example foundation

To implement this design option, see Create option 2: Hub-and-spoke topology with centralized appliances .

Option 3: Hub-and-spoke topology without appliances

This network design also uses a hub-and-spoke topology, with a hub VPC network that connects to on-premises networks and spoke VPC networks that contain the workloads. Because VPC Network Peering is non-transitive, spoke networks cannot communicate with each other directly.

• You want workloads or environments in Google Cloud to not communicate with each other at all using internal IP addresses, but you do want them to share on-premises connectivity.
• You want to give teams autonomy in managing their own firewall and routing rules.
• You require Layer 7 inspection between workloads.
• You want to centrally manage routing and firewall rules.
• You require communications from on-premises services to managed services that are connected to the spokes through another VPC Network Peering, because VPC Network Peering is non-transitive.
• Connectivity to on-premises locations passes through Cloud Interconnect connections in the hub VPC network.
• On-premises networks are connected through the Cloud Interconnect instances using separate VLAN attachments.

This network design is often used in environments where teams act autonomously and there is no centralized control over firewall and routing rules. However, the scale of this design is limited by the following:

The limit on VPC Network Peering connections from a single VPC network

Peering group limits such as the maximum number of forwarding rules for the internal passthrough Network Load Balancer for each peering group

Therefore, this design is not typically used in large organizations that have many separate workloads on Google Cloud.

As a variation to the design, you can use Cloud VPN instead of VPC Network Peering. Cloud VPN lets you increase the number of spokes, but adds a bandwidth limit for each tunnel and increases complexity and costs. When you use custom route advertisements , Cloud VPN also allows for transitivity between the spokes without requiring you to directly connect all the spoke networks.

• Hub-and-spoke network architecture
• Hub-and-spoke architecture in the enterprise foundations guide
• Terraform deployment stage: Networking with VPC Network Peering as part of the Fabric FAST framework
• Terraform deployment stage: Networking with Cloud VPN as part of Fabric FAST framework

To implement this design option, see Create option 3: Hub-and-spoke topology without appliances .

Option 4: Expose services in a consumer-producer model with Private Service Connect

In this network design, each team or workload gets their own VPC network, which can also be a Shared VPC network. Each VPC network is independently managed and uses Private Service Connect to expose all the services that need to be accessed from outside the VPC network.

• Workloads only communicate with each other and the on-premises environment through defined endpoints.
• You want teams to be independent of each other, and manage their own IP address space, firewalls, and routing rules.
• Communication between services and applications uses many different ports or channels, or ports and channels change frequently.
• Communication between workloads uses protocols other than TCP or UDP.
• Separate workloads are located in separate projects and VPC networks.
• A client VM in one VPC network can connect to a workload in another VPC network through a Private Service Connect endpoint.
• The endpoint is attached to a service attachment in the VPC network where the service is located. The service attachment can be in a different region from the endpoint if the endpoint is configured for global access .
• The service attachment connects to the workload through Cloud Load Balancing.
• The endpoint is connected to a service attachment in a transit VPC network.
• The service attachment is connected to the on-premises network using Cloud Interconnect.
• An internal Application Load Balancer is attached to the service attachment and uses a hybrid network endpoint group to balance traffic load between the endpoints that are located on-premises.
• On-premises clients can also reach endpoints in the transit VPC network that connect to service attachments in the workload VPC networks.
• Publish managed services using Private Service Connect
• Access published services through endpoints

To implement this design option, see Create option 4: Expose services in a consumer-producer model with Private Service Connect .

Best practices for network deployment

After you choose the best network design for your use case, we recommend that for implement the following best practices:

• Use custom mode VPC networks and delete the default network to have better control over your network's IP addresses.

Limit external access by using Cloud NAT for resources that need internet access and reducing the use of public IP addresses to resources accessible through Cloud Load Balancing. For more information, see building internet connectivity for private VMs .

If you use Cloud Interconnect, make sure that you follow the recommended topologies for non-critical or production-level applications . Use redundant connections to meet the SLA for the service. Alternatively, you can connect Google Cloud to on-premises networks through Cloud VPN .

Enforce the policies introduced in limit external access by using an organization policy to restrict direct access to the internet from your VPC.

Use hierarchical firewall policies to inherit firewall policies consistently across your organization or folders.

Follow DNS best practices for hybrid DNS between your on-premises network and Google Cloud.

For more information, see Best practices and reference architectures for VPC design .

What's next

• Implement your Google Cloud landing zone network design
• Decide the security for your Google Cloud landing zone (next document in this series).
• Read Best practices for VPC network design .
• Learn how to use Centralized network appliances on Google Cloud .
• Read more about Private Service Connect .

Except as otherwise noted, the content of this page is licensed under the Creative Commons Attribution 4.0 License , and code samples are licensed under the Apache 2.0 License . For details, see the Google Developers Site Policies . Java is a registered trademark of Oracle and/or its affiliates.

Last updated 2023-09-11 UTC.

AI + Machine Learning , Announcements , Azure AI Content Safety , Azure AI Studio , Azure OpenAI Service , Partners

Introducing GPT-4o: OpenAI’s new flagship multimodal model now in preview on Azure

By Eric Boyd Corporate Vice President, Azure AI Platform, Microsoft

Posted on May 13, 2024 2 min read

• Tag: Copilot
• Tag: Generative AI

Microsoft is thrilled to announce the launch of GPT-4o, OpenAI’s new flagship model on Azure AI. This groundbreaking multimodal model integrates text, vision, and audio capabilities, setting a new standard for generative and conversational AI experiences. GPT-4o is available now in Azure OpenAI Service, to try in preview , with support for text and image.

Azure OpenAI Service

A step forward in generative AI for Azure OpenAI Service

GPT-4o offers a shift in how AI models interact with multimodal inputs. By seamlessly combining text, images, and audio, GPT-4o provides a richer, more engaging user experience.

Launch highlights: Immediate access and what you can expect

Azure OpenAI Service customers can explore GPT-4o’s extensive capabilities through a preview playground in Azure OpenAI Studio starting today in two regions in the US. This initial release focuses on text and vision inputs to provide a glimpse into the model’s potential, paving the way for further capabilities like audio and video.

Efficiency and cost-effectiveness

GPT-4o is engineered for speed and efficiency. Its advanced ability to handle complex queries with minimal resources can translate into cost savings and performance.

Potential use cases to explore with GPT-4o

The introduction of GPT-4o opens numerous possibilities for businesses in various sectors: 

• Enhanced customer service : By integrating diverse data inputs, GPT-4o enables more dynamic and comprehensive customer support interactions.
• Advanced analytics : Leverage GPT-4o’s capability to process and analyze different types of data to enhance decision-making and uncover deeper insights.
• Content innovation : Use GPT-4o’s generative capabilities to create engaging and diverse content formats, catering to a broad range of consumer preferences.

Exciting future developments: GPT-4o at Microsoft Build 2024 

We are eager to share more about GPT-4o and other Azure AI updates at Microsoft Build 2024 , to help developers further unlock the power of generative AI.

Get started with Azure OpenAI Service

Begin your journey with GPT-4o and Azure OpenAI Service by taking the following steps:

• Try out GPT-4o in Azure OpenAI Service Chat Playground (in preview).
• If you are not a current Azure OpenAI Service customer, apply for access by completing this form .
• Learn more about  Azure OpenAI Service  and the  latest enhancements.  
• Understand responsible AI tooling available in Azure with Azure AI Content Safety .
• Review the OpenAI blog on GPT-4o.

Let us know what you think of Azure and what you would like to see in the future.

Provide feedback

Build your cloud computing and Azure skills with free courses by Microsoft Learn.

Explore Azure learning

Related posts

AI + Machine Learning , Announcements , Azure AI , Azure AI Studio , Azure OpenAI Service , Events

New models added to the Phi-3 family, available on Microsoft Azure   chevron_right

AI + Machine Learning , Announcements , Azure AI , Azure AI Content Safety , Azure AI Services , Azure AI Studio , Azure Cosmos DB , Azure Database for PostgreSQL , Azure Kubernetes Service (AKS) , Azure OpenAI Service , Azure SQL Database , Events

From code to production: New ways Azure helps you build transformational AI experiences   chevron_right

AI + Machine Learning , Azure AI Studio , Customer stories

3 ways Microsoft Azure AI Studio helps accelerate the AI development journey     chevron_right

AI + Machine Learning , Analyst Reports , Azure AI , Azure AI Content Safety , Azure AI Search , Azure AI Services , Azure AI Studio , Azure OpenAI Service , Partners

Microsoft is a Leader in the 2024 Gartner® Magic Quadrant™ for Cloud AI Developer Services   chevron_right

Join the conversation, leave a reply cancel reply.

Your email address will not be published. Required fields are marked *

I understand by submitting this form Microsoft is collecting my name, email and comment as a means to track comments on this website. This information will also be processed by an outside service for Spam protection. For more information, please review our Privacy Policy and Terms of Use .

I agree to the above

Some of Arizona’s indicted fake electors want your spare change to help with legal bills

Six of the fake electors indicted in Arizona are turning to fundraising appeals to help finance their legal defense.

Michael and Kelli Ward are the only Arizonans seeking financial support so far. The other four indicted individuals are continuing campaigns they apparently started due to their involvement in other cases related to the 2020 presidential election. All of them have accounts on GiveSendGo , a Christian crowdfunding site that also collects prayers for the beneficiaries.

The Wards' attorney, Brad Miller, launched the couple's fundraising campaign in the wake of indictments sought by Attorney General Kris Mayes. As of Friday, the effort had raised $100,000 from 92 donors toward a goal of what appears to be $5.3 million. The target amount is not fully displayed on the fundraising website .

They also received 21 prayers.

Miller portrayed the Wards' presentation of themselves as Arizona's lawful presidential electors as a free speech matter.

Prep for the polls: See who is running for president and compare where they stand on key issues in our Voter Guide

"AG Mayes is trying to punish, bankrupt, and silence Kelli and Michael for speaking out in favor of election integrity," Miller wrote. "And Mayes wants to quash all future peaceable protests against the democrat party by criminalizing this type of speech."

The top donor through Friday was Hildy Angius, a member of the Mohave County Board of Supervisors and a Republican candidate for a state Senate seat from Legislative District 30 in the northwest part of the state.

Other fundraising appeals on the site are from Rudy Giuliani, an attorney, associate of former President Donald Trump and former New York City mayor; attorney Jenna Ellis, who worked with Giuliani on Trump legal matters; attorney John Eastman; and Michael Roman, a former Trump campaign official and a co-defendant in the Georgia case involving fake electors.

Giuliani's site was started by Jackson Lahmeyer, an Oklahoma pastor who ran an unsuccessful campaign for the GOP nomination for U.S. Senate in 2022.

Giuliani "has been persecuted to the highest level through law fare due to his support of President Donald Trump," Lahmeyer wrote. As of May 24, the campaign had raised $40,000 toward the comparatively modest goal of $100,000. He also has received 198 prayers.

Proceeds will be funneled to the Rudy Giuliani Freedom Fund, another account set up to defray the former mayor's legal bills.

Other defendants and their legal defense totals as of late May:

• Eastman started his own account on GiveSendGo with a goal of $1.5 million. He had raised $865,000 as of May 24.
• Ellis' account was started by attorney Michael Melito, who represented her in a Colorado disciplinary case where Ellis admitted to several statements she made in 2020 that violated professional ethics rules. She had raised $220,150, although no fundraising goal was posted. Her biggest donor was conservative author Dinesh D'Souza and his wife, who gave $100,000.
• Michael Roman, a Trump campaign staffer in 2016 and 2020. He joined the crowdfunding site to raise $300,000 toward his legal bills. As of May 24, he had reached $64,000 toward that goal. He is represented by the  Dhillon Law Group, the same firm that is defending Arizona state Sen. Jake Hoffman in the fake elector case.

Another of the indicted individuals is fundraising, but for a different cause. State Sen. Anthony Kern, R-Glendale, dashed off an appeal for funds to fuel his congressional bid soon after the indictments were handed down.

“If they lock Trump and me up…You all will be next,” Kern's email states . He is in a six-way race for the GOP nomination to represent the 8th Congressional District in the West Valley.

Following advice or fraud? Elements of AZ fake electors case that will be crucial at trial

Reach the reporter at   [email protected]  or at 602-228-7566 and follow her on Threads as well as on X, the platform formerly known as Twitter   @maryjpitzl .

Pro Motocross Championship

Four live network telecasts on nbc highlight broadcast schedule for 2024 season, friday, may 24, 2024 | 3:30 pm, four live network telecasts on nbc highlight broadcast schedule for 2024 pro motocross championship, pair of encore presentations on usa network combine for six network showcases; peacock continues as centerpiece of supermotocross coverage.

The 2024  Pro Motocross Championship , sanctioned by AMA Pro Racing, kicked off its 53rd season on Thursday with a press conference ahead of Saturday’s opening round at the Honda Fox Raceway National Presented by Fox Racing. Pro Motocross serves as the midway point of the SuperMotocross World Championship Series (SMX), beginning the summer portion of the regular season with Round 18. Southern California’s Pala Casino provided the setting for the industry gathering, after which the adjacent Fox Raceway saw all entered racers take to track for the first time.   A focal point of the press conference was the dynamic broadcast package that encompasses the SMX Series. Another successful season of Monster Energy AMA Supercross saw impressive growth across all areas, including a 30-percent increase in live minutes watched on Peacock, the centerpiece of SMX broadcasts that will carry wall-to-wall live coverage of all 11 rounds of the Pro Motocross Championship. Additionally, network showcases of Supercross on NBC and USA Network, along with re-airs on CNBC, saw 24-percent growth in audience reach. Additionally, SuperMotocross Video Pass continued to drive a broader reach for the sport’s international audience, which included the introduction of a dedicated Spanish-language broadcast that contributed to more than 130 different countries being represented. To top it all off, a new partnership with Telemundo brought the Spanish-language broadcast to the domestic SMX audience in the U.S. for the first time, with three simulcasts on Telemundo Deportes’ YouTube channel and the Telemundo page on the NBC mobile app–the recent Supercross finale from Salt Lake City, the upcoming Pro Motocross finale from Indiana’s Ironman Raceway on August 24, and the SuperMotocross World Championship Final in Las Vegas on September 21.

The Pro Motocross Championship will carry the momentum into the summer with an action-packed broadcast schedule highlighted by four live network showcases on NBC–Round 3 from Colorado’s Thunder Valley Motocross Park on June 8, Round 6 from Michigan’s RedBud MX on July 6, Round 7 from Minnesota’s Spring Creek MX Park on July 13, and Round 8 from Washington’s Washougal MX Park on July 20. Additionally, USA Network will feature a pair of Sunday encore presentations, with Round 4 from Pennsylvania’s High Point Raceway, which will air on June 16, and Round 10 from Southern Maryland’s Budds Creek Motocross Park, which will air on August 17.

The entirety of the 2024 season will unfold live on Peacock, with uninterrupted streaming coverage of every moto across the 450 Class and 250 Class. Each Saturday on the championship calendar will begin with Race Day Live Presented by MotoSport.com, available exclusively on Peacock, with live coverage of the final timed qualifying sessions of the “A” groups from each division. Once the racing is complete, Peacock’s exclusive post-race show will bring viewers the latest from the paddock after the checkered flag has waved and the champagne has been sprayed.

All 11 rounds of the Pro Motocross Championship will also re-air via tape delay on CNBC every Sunday night for viewers in the Pacific Time Zone at 11 p.m. PT and Monday morning for viewers in the Eastern Time Zone at 2 a.m. ET.

For international viewers, the SuperMotocross Video Pass will continue to provide fans around the world with the same award-winning production found domestically, with live streaming of every moto, from every round of the season. Viewers from more than 130 different countries have subscribed to Video Pass, which has seen even more growth this year with the introduction of the aforementioned Spanish-language broadcast hosted by veteran announcer Edgar Lopez and former racer Tommy Rios. With a continued influx of international talent contesting the Pro Motocross Championship, this reach is expected to expand even further. For a limited time, new subscribers can sign up for  SuperMotocross Video Pass  with a 50% discount.

For any fans unable to watch the action on television or a mobile device this summer, SiriusXM satellite radio will provide an audio simulcast of the broadcast of each round via NBC Sports Audio Channel 85.

The talented broadcast team bringing the action of the Pro Motocross Championship to viewers all summer long will consist of host and play-by-play commentator Jason Weigandt, the longtime voice of American motocross, and the analyst duo of AMA Motorcycle Hall of Famers Ricky Carmichael and James Stewart in the booth. On the track, pit reporters Jason Thomas and Will Christien will bring the latest breaking news and perspective from the paddock and will be joined at select rounds by veteran reporter Katie Osborne.

Each week in between races, fans can stay connected to the season through SMX Insider, the weekly news magazine hosted by Jason Weigandt and Jason Thomas, airing each Thursday on the SuperMotocross YouTube channel. Additionally, the Title24 podcast with Ricky Carmichael and fellow AMA Motorcycle Hall of Famer Ryan Villopoto, will bring an insider’s perspective from two of the sport’s most decorated champions each week and can be seen on Peacock and the Motorsports on NBC YouTube channel.

635th Anti-Aircraft Missile Regiment

635-й зенитно-ракетный полк

Military Unit: 86646

Activated 1953 in Stepanshchino, Moscow Oblast - initially as the 1945th Anti-Aircraft Artillery Regiment for Special Use and from 1955 as the 635th Anti-Aircraft Missile Regiment for Special Use.

1953 to 1984 equipped with 60 S-25 (SA-1) launchers:

• Launch area: 55 15 43N, 38 32 13E (US designation: Moscow SAM site E14-1)
• Support area: 55 16 50N, 38 32 28E
• Guidance area: 55 16 31N, 38 30 38E

1984 converted to the S-300PT (SA-10) with three independent battalions:

• 1st independent Anti-Aircraft Missile Battalion (Bessonovo, Moscow Oblast) - 55 09 34N, 38 22 26E
• 2nd independent Anti-Aircraft Missile Battalion and HQ (Stepanshchino, Moscow Oblast) - 55 15 31N, 38 32 23E
• 3rd independent Anti-Aircraft Missile Battalion (Shcherbovo, Moscow Oblast) - 55 22 32N, 38 43 33E

Disbanded 1.5.98.

Subordination:

• 1st Special Air Defence Corps , 1953 - 1.6.88
• 86th Air Defence Division , 1.6.88 - 1.10.94
• 86th Air Defence Brigade , 1.10.94 - 1.10.95
• 86th Air Defence Division , 1.10.95 - 1.5.98

Follow Puck Worlds online:

• Follow Puck Worlds on Twitter

Site search

Filed under:

• Kontinental Hockey League

Gagarin Cup Preview: Atlant vs. Salavat Yulaev

Share this story.

• Share this on Facebook
• Share this on Twitter
• Share this on Reddit
• Share All sharing options

Share All sharing options for: Gagarin Cup Preview: Atlant vs. Salavat Yulaev

Gagarin cup (khl) finals:  atlant moscow oblast vs. salavat yulaev ufa.

Much like the Elitserien Finals, we have a bit of an offense vs. defense match-up in this league Final.  While Ufa let their star top line of Alexander Radulov, Patrick Thoresen and Igor Grigorenko loose on the KHL's Western Conference, Mytischi played a more conservative style, relying on veterans such as former NHLers Jan Bulis, Oleg Petrov, and Jaroslav Obsut.  Just reaching the Finals is a testament to Atlant's disciplined style of play, as they had to knock off much more high profile teams from Yaroslavl and St. Petersburg to do so.  But while they did finish 8th in the league in points, they haven't seen the likes of Ufa, who finished 2nd. 

This series will be a challenge for the underdog, because unlike some of the other KHL teams, Ufa's top players are generally younger and in their prime.  Only Proshkin amongst regular blueliners is over 30, with the work being shared by Kirill Koltsov (28), Andrei Kuteikin (26), Miroslav Blatak (28), Maxim Kondratiev (28) and Dmitri Kalinin (30).  Oleg Tverdovsky hasn't played a lot in the playoffs to date.  Up front, while led by a fairly young top line (24-27), Ufa does have a lot of veterans in support roles:  Vyacheslav Kozlov , Viktor Kozlov , Vladimir Antipov, Sergei Zinovyev and Petr Schastlivy are all over 30.  In fact, the names of all their forwards are familiar to international and NHL fans:  Robert Nilsson , Alexander Svitov, Oleg Saprykin and Jakub Klepis round out the group, all former NHL players.

For Atlant, their veteran roster, with only one of their top six D under the age of 30 (and no top forwards under 30, either), this might be their one shot at a championship.  The team has never won either a Russian Superleague title or the Gagarin Cup, and for players like former NHLer Oleg Petrov, this is probably the last shot at the KHL's top prize.  The team got three extra days rest by winning their Conference Final in six games, and they probably needed to use it.  Atlant does have younger regulars on their roster, but they generally only play a few shifts per game, if that. 

The low event style of game for Atlant probably suits them well, but I don't know how they can manage to keep up against Ufa's speed, skill, and depth.  There is no advantage to be seen in goal, with Erik Ersberg and Konstantin Barulin posting almost identical numbers, and even in terms of recent playoff experience Ufa has them beat.  Luckily for Atlant, Ufa isn't that far away from the Moscow region, so travel shouldn't play a major role. 

I'm predicting that Ufa, winners of the last Superleague title back in 2008, will become the second team to win the Gagarin Cup, and will prevail in five games.  They have a seriously well built team that would honestly compete in the NHL.  They represent the potential of the league, while Atlant represents closer to the reality, as a team full of players who played themselves out of the NHL. 

• Atlant @ Ufa, Friday Apr 8 (3:00 PM CET/10:00 PM EST)
• Atlant @ Ufa, Sunday Apr 10 (1:00 PM CET/8:00 AM EST)
• Ufa @ Atlant, Tuesday Apr 12 (5:30 PM CET/12:30 PM EST)
• Ufa @ Atlant, Thursday Apr 14 (5:30 PM CET/12:30 PM EST)

Games 5-7 are as yet unscheduled, but every second day is the KHL standard, so expect Game 5 to be on Saturday, like an early start. 

Loading comments...

• Election 2024
• Entertainment
• Newsletters
• Photography
• Personal Finance
• AP Investigations
• AP Buyline Personal Finance
• AP Buyline Shopping
• Press Releases
• Israel-Hamas War
• Russia-Ukraine War
• Global elections
• Asia Pacific
• Latin America
• Middle East
• Election Results
• Delegate Tracker
• AP & Elections
• Auto Racing
• 2024 Paris Olympic Games
• Movie reviews
• Book reviews
• Personal finance
• Financial Markets
• Business Highlights
• Financial wellness
• Artificial Intelligence
• Social Media

Putin says Russia wants a buffer zone in Ukraine’s Kharkiv but has no plans to capture the city

Russian President Vladimir Putin says that Moscow’s offensive in Ukraine’s Kharkiv region aims to create a buffer zone but has no plans to capture the city.

This image released by Maxar Technologies shows a damaged plane, likely a MiG 31 fighter aircraft, at Belbek air base, near Sevastopol, in Crimea, Thursday, May 16, 2024. (Satellite image ©2024 Maxar Technologies via AP)

• Copy Link copied

This image released by Maxar Technologies shows an overview of a destroyed fuel storage facility at Belbek air base, near Sevastopol, in Crimea, Thursday, May 16, 2024. (Satellite image ©2024 Maxar Technologies via AP)

This image released by Maxar Technologies shows an overview of a destroyed SU 27 fighter aircraft in revetment at Belbek air base, near Sevastopol, in Crimea, Thursday, May 16, 2024. (Satellite image ©2024 Maxar Technologies via AP)

This image released by Maxar Technologies shows an overview of destroyed MiG 31 fighter aircraft and fuel storage facility at Belbek air base, near Sevastopol, in Crimea, Thursday, May 16, 2024. (Satellite image ©2024 Maxar Technologies via AP)

This image released by Maxar Technologies shows an overview of Belbek air base, near Sevastopol, in Crimea, Thursday, May 16, 2024. (Satellite image ©2024 Maxar Technologies via AP)

This image released by Maxar Technologies shows a closer view of a destroyed MiG 31 fighter aircraft at Belbek air base, near Sevastopol, in Crimea, Thursday, May 16, 2024. (Satellite image ©2024 Maxar Technologies via AP)

KYIV, Ukraine (AP) — Russian President Vladimir Putin said on Friday during a visit to China that Moscow’s offensive in Ukraine’s northeastern Kharkiv region aims to create a buffer zone but that there are no plans to capture the city.

The remarks were Putin’s first on the offensive launched May 10 , which opened a new front and displaced thousands of Ukrainians within days. Earlier Friday, a massive Ukrainian drone attack on the Russia-occupied Crimean Peninsula cut off power in the city of Sevastopol, after an earlier attack damaged aircraft and fuel storage at an airbase.

In southern Russia, Russian authorities said a refinery was also set ablaze.

Moscow launched attacks in the Kharkiv region in response to Ukrainian shelling of Russia’s Belgorod region , Putin told reporters while visiting the Chinese city of Harbin .

“I have said publicly that if it continues, we will be forced to create a security zone, a sanitary zone,” he said. “That’s what we are doing.” Russian troops were “advancing daily according to plan,” he said and added there were no plans for now to take the city of Kharkiv.

Ukrainian troops are fighting to halt Russian advances in the Kharkiv region that began late last week. In an effort to increase troop numbers, President Volodymyr Zelenskyy signed two laws Friday, allowing prisoners to join the army and increasing fines for draft dodgers fivefold. The controversial mobilization law goes into effect on Saturday.

Russia enlisted prisoners early on in the war, and personnel shortages compelled the new measures. The legislation allows for “parole from serving a sentence and further enlistment for military service” for a specific period for some people charged with criminal offences. It doesn’t extend to those convicted of crimes against Ukraine’s national security.

Penalties will be increased to 25,500 hryvnias ($650) for citizens and 51,000 hryvnias ($1,300) for civil servants and legal entities for ignoring draft notices or failing to update the draft board of their information. Fines were previously 5100 hryvnias ($130) for citizens and 8500 hryvnias ($215) for civil servants and legal entities.

Ukrainian authorities have evacuated around 8,000 civilians from the recent flashpoint town of Vovchansk, 5 kilometers (3 miles) from the Russian border. The Russian army’s usual tactic is to reduce towns and villages to ruins with aerial strikes before troops move in.

At least two people were killed and 19 were wounded in the Russian bombing of Kharkiv, regional chief Oleh Syniehubov said on his Telegram posting on Friday. Four of the wounded were in critical condition.

Russia’s new offensive has “expanded the zone of active hostilities by almost 70 kilometers” (45 miles), in an effort to force Ukraine to spread its forces and use reserve troops, Ukraine’s military chief, Col. Gen. Oleksandr Syrskyi, said Friday.

In the Kharkiv region, Russian forces have advanced 10 kilometers (6 miles) from the border, Zelenskyy said Friday.

Separately, speaking about Ukraine’s upcoming peace conferences in Switzerland next month, Putin said it was a vain attempt to enforce terms of a peaceful settlement on Russia and stressed that Russia wasn’t invited to the meeting.

He said that Russia was ready for talks but shrugged off Zelenskyy’s peace formula as wishful thinking. Any prospective peace talks should be based on a draft deal negotiated by Russia and Ukraine during their Istanbul talks in 2022, he said.

Ukraine meanwhile carried out drone raids on Crimea in an attempt to strike back during Moscow’s offensive in northeastern Ukraine, which has piled on pressure on outnumbered and outgunned Ukrainian forces awaiting delayed deliveries of crucial weapons and ammunition from Western partners.

A Ukrainian intelligence official confirmed to The Associated Press that the country’s intelligence services struck Russia’s military infrastructure sites in Novorossiysk, on the Black Sea coast, and in Russian-occupied city of Sevastopol. The official was not authorized to make public comments and spoke on condition of anonymity.

The operation, carried out by Ukraine-built drones, targeted Russian Black Sea Fleet vessels, the official said.

The Russian Defense Ministry said air defenses downed 51 Ukrainian drones over Crimea, 44 over the Krasnodar region of Russia and six over the Belgorod region. Russian warplanes and patrol boats also destroyed six sea drones in the Black Sea, it said.

At least three fighter jets were destroyed in an earlier attack in Crimea a few days ago, according to satellite imagery of the airbase provided by Maxar Technologies.

Mikhail Razvozhayev, the governor of Sevastopol, which is the main base for Russia’s Black Sea Fleet, said the drone attack damaged the city’s power plant. He said it could take a day to fully restore electricity and warned residents of power cuts. He also announced city schools would be closed temporarily.

In the Krasnodar region, authorities said a drone attack early Friday caused a fire at an oil refinery in Tuapse, which was later contained. There were no casualties. Ukraine has repeatedly targeted refineries and other energy facilities deep inside Russia, inflicting damage.

The Krasnodar region’s governor, Veniamin Kondratyev, said fragments of downed drones around the port of Novorossiysk caused several fires, but there were no casualties.

Belgorov Gov. Vyacheslav Gladkov said a Ukrainian drone struck a vehicle, killing a woman and her 4-year-old child. Another attack there set a fuel tank ablaze at a gas station, he said.

Recent Russian attacks have also targeted the eastern Donetsk region, as well as the Chernihiv and Sumy regions in the north and in the southern Zaporizhzhia region — apparently seeking to further stretch depleted Ukrainian resources.

Having boosted their forces in northern Ukraine, Russian forces are now pushing to advance near the village of Lyptsi, as well as the town of Vovchansk, according to Syrskyi, the Ukrainian military commander.

Syrskyi also said he inspected units that are “preparing for defense” of Sumy. On Tuesday, the head of Ukraine’s Military Intelligence, Kyrylo Budanov, reportedly said Russia’s military planned to launch offensive actions in Sumy.

Russia has also been testing defenses elsewhere along the roughly 1,000-kilometer (620-mile) front line, which snakes north-to-south through eastern Ukraine. The line has barely changed over the past 18 months, in what has become a war of attrition.

Follow AP’s coverage at https://apnews.com/hub/russia-ukraine