When you think of a car, you most likely envision its physical appearance and impressive features at surface level. What most of us haven't stopped to consider is how safety is designed into the different parts of that car.

Take a minute and think about it. The body is shaped in such a way that if it crumples in a collision, force doesn't reach you. Then you have the tire tread that is designed to hold the road in bad weather and the braking system was built to not lock up when you slam on the brakes.

When we consider the design of a car in such a way, we begin to realize that safety was a requirement at every stage of the design, and the car protects you because those parts work together.

Security architecture works the same way.

A simplified way of understanding security architecture is to see it as the security processes and technical controls that are designed to secure all components that make up an organization and contribute to its mission and strategic objectives, including personnel, offices, and computers.

Centering a single company makes it easier to see how security architecture contributes to a secure enterprise. Let's say Valleywind Health is a medium-sized healthcare provider with a mix of cloud and on-prem systems, remote workers, sensitive data, APIs, and multiple departments.

We'll walk through the identity and network components to see how a company like Valleywind Health would secure its architecture.

Identity & Access Management (IAM)

Valleywind Health uses a hybrid model: Entra ID for cloud identity, Active Directory for on-premises legacy systems, and Google Cloud Platform (GCP) IAM for its analytics tools and cloud infrastructure. Single Sign-On (SSO) is used wherever possible in third-party SaaS applications and for access to internal systems, including its own patient portal.

How IAM is structured

The access management policy enforces the application of the principle of least privilege by default when administering access for employees. This means staff accounts should only have access to what they need.

  • Nurses can view patient charts but cannot view Billing resources or make Billing changes.
  • Billing staff can make changes to certain resources, but they cannot access clinical data as this is beyond the scope of their role.
  • Admin privileges are separated by role and group memberships that require just-in-time (JIT) access and approval so access is given only for the duration of time that it's needed.

IAM gets interesting for Valleywind Health when service accounts are involved. They use several of these accounts in GCP to run jobs, sync clinical records, and send data to their analytics dashboards. This is potentially one of the biggest risk areas in their architecture if not correctly handled. These accounts usually end up with a lot of access and hardly any oversight, and since no human-user is signing into them, their activity can easily pass as benign.

Here's an example scenario where an overly permissive service account can lead to a breach.

One of their service accounts, responsible for collecting anonymized patient data from the clinical systems, was created in a hurry during a vendor migration and was granted the role of GCP Owner.

Given the excess of permissions, this service account can now create new VMs, change firewall rules, modify IAM policies, access or delete storage buckets, deploy new containers, and disable logging. All of that from one admin rushing to get home.

What if that service account key somehow got leaked through a GitHub repo, or maybe a misconfigured server, or even a VM compromise? If this happens, an attacker can easily become a cloud administrator at Valleywind without ever touching a user account.

What proper IAM looks like

If the admin had done this correctly, that service account would only have the access it needed, scoped to its role. Maybe Storage Object Viewer, BigQuery Data Editor, and Pub/Sub Publisher permissions. Identity permissions should be assigned in such a way that if an account does get compromised, the impact radius stays small.

Network Security

Looking at Valleywind's network security, the environment revolves around network segmentation across a headquarters location, three clinics, and their cloud platforms.

The network was designed so devices don't all pool into one big network.

  • Clinical network for the Electronic Health Records system
  • Guest Wi-Fi, isolated from internal systems
  • HR, billing, and executive systems that sit on their own network
  • Development environment, separated from production
  • Legacy on-premises systems that have their own network segment
  • Remote employees on a dedicated, restricted VPN segment

In this setup, if an attacker compromises a receptionist’s workstation, the layout of Valleywind's architecture would keep them from pivoting into the clinical network where patient data lives.

Think of a scenario where an employee working remotely clicks a malicious link embedded in a PDF, allowing an attacker to gain access to their work computer. If the network was not segmented, the attacker could scan laterally until they discovered something of value. But since Valleywind's network is segmented, such movement would be far more difficult. Similarly, employees connecting via VPN would be subject to policies that restrict visibility into clinical servers. Even if this attack were to progress, the architectural design would ultimately limit what the attacker can actually reach.

This is a good example of how network protection is not all firewalls. Every boundary must be set with the intention of disrupting attack progression and protecting the company's assets.

Where This Leaves Us

Identity and network are only two layers that contribute to secure architecture in the enterprise, but there is already a clear pattern. Proper scoping around identity limits what an account can do, while segmentation determines how effective an attack can be once the network has been breached.

But what happens on the device itself, or at the API, or to the data once someone reaches it? In the next part, Layered Security Architecture: Endpoint, Application, and Data, we'll discuss how each of those fits enterprise security architecture.