※This article is a compilation of discussions and experiences within our organization based on general security principles. It does not represent the official views of any specific company or organization, nor the internal implementation of any specific vendor.

✅ Disclaimer #

• The content of this article introduces general approaches to the design and operations of information systems and does not guarantee safety or suitability for all organizations.

• When implementing in practice, we recommend consulting with experts and conducting internal reviews, taking into account your organization’s size, industry, risk tolerance, regulatory requirements, and contractual obligations.

• The author and their organization assume no responsibility for any damages resulting from operations, configurations, organizational changes, or other actions based on this article.

Introduction: The “One Person Knows Everything” State Is Powerful and Risky #

In the world of infrastructure, cloud, and security,
“super engineers” who can do and know everything tend to be highly valued.

However, this also carries significant risks:

• Operations cannot continue without that person (Bus Factor of 1)

• Authority becomes too concentrated, with catastrophic impacts in case of misoperations or incidents

• From a security perspective, this creates high “insider threat risk”

In large-scale clouds, financial institutions, and organizations like SWIFT,
avoiding this issue by implementing “structures where no single person can control everything” is becoming standard practice.

However, if you try to apply the same approach directly in small to mid-size organizations,
management costs skyrocket and operations become unsustainable.

That’s why this article organizes a **”lightweight zero-trust segmentation model” that is easier to implement even in small to mid-size organizations**.

Model Goals #

This model aims to achieve the following state:

• ✅ Eliminate the situation where one person “knows and can access everything”

• ✅ Keep daily operations from becoming overly complex

• ✅ Be able to respond properly when emergencies occur (including emergency response)

“Zero-trust” may sound grandiose,
but here you can think of it simply as “giving people and systems access only to what they need”.

Step 1: Divide Roles into 3 Areas (Domain Segmentation) #

First, let’s keep it super simple:
divide your systems into 3 domains.

A. Infrastructure Team #

• Virtual platforms (VMware / Proxmox / Hyper-V, etc.)

• Operating systems (Linux / Windows)

• Storage

• Basic networking

• Backup infrastructure

B. Application Team #

• Web / API servers

• Middleware (Nginx / Apache / Redis / MQ, etc.)

• Databases

• CI/CD pipelines

• Application configuration and deployment

C. Security and Authentication Team #

• IAM / Account management

• VPN / SSO / AD / LDAP

• Permission design

• Certificate and key management

• Logging and audit infrastructure

Key point:

Ensure that no single person has full access to all of A + B + C.

Even in small organizations,

• Primary owner + backup owner

• Or establishing a clear boundary like “can touch up to this point, but must request others for beyond”

simply documenting this clearly will significantly reduce risks.

Step 2: Prepare Permission Levels in “3 Tiers Only” #

When you hear “zero-trust,” you might think of granular RBAC and detailed role design,
but in small operations, overdoing it leads to failure.

So we intentionally narrow it down to just 3 tiers.

D1. Operator (Operations Staff) #

• Monitoring and log viewing

• Service restarts

• Simple configuration changes

• Operations following documented procedures

D2. Maintenance Administrator (Infrastructure / Application Admin) #

• VM creation and deletion

• Adding storage volumes

• Network configuration changes

• Middleware updates and configuration changes

D3. Security Administrator (IAM / Authentication) #

• Account creation and deletion

• Role and group definition changes

• Password policy changes

• VPN, key, and certificate lifecycle management

Absolute rule:

Do not have the same person serve as both D2 (Maintenance Administrator) and D3 (Security Administrator)
on a regular basis.

In other words, don’t make “a super admin who can do anything—VMs and IAM alike” a permanent state.

If staffing constraints require dual roles,

• normally keep only one role active at a time

• and make the other available only for emergency use with elevation procedures and logging

is the recommended approach.

Step 3: “Properly Keep” Operation Logs — That Alone Is Quite Powerful #

Even if you can’t design perfect permissions,
simply being able to track “who did what and when” creates a dramatic deterrent effect and peace of mind.

Examples #

• Virtual platforms: Audit logs (Proxmox / vCenter Audit Log, etc.)

• OS: journalctl / auditd

• Network devices: syslog aggregation

• IaC / Git: commit logs and Pull Requests

At minimum:

1. Enable log output for all critical components in some form

2. Preferably aggregate logs in one place (syslog server or log infrastructure)

3. Make it possible to see “who, when, under which account, and what they did”

Simply by keeping logs,
an environment where “people naturally hesitate to do unauthorized things” naturally emerges.

Step 4: Automation and IaC — Put “What’s in People’s Heads” Into Systems #

A major cause of knowledge silos is

“configurations and setups exist only in someone’s head”

.

The quickest way to break this down is **automation and IaC (Infrastructure as Code)**.

Examples #

• Manage cloud and virtual platform configurations with Terraform

• Standardize OS and middleware settings with Ansible

• Standardize deployments with GitHub Actions / GitLab CI

• Even shell scripts are fine—automate manual work

The key is

“reducing the number of times people directly touch the console”

as the direction.

Step 5: Entrust Secrets to “Systems,” Not to “People” #

SSH private keys, API keys, passwords, certificates—
it’s critical not to keep such information on individual PCs or under personal management.

Representative Methods #

• Password managers (1Password, Bitwarden, KeePass, etc.)

• Secrets management services (Vault, AWS Secrets Manager, etc.)

• Don’t store plaintext in Git (encrypt or use reference IDs)

By controlling “who can access which secrets” at the system level,
you aim for a structure where secrets are not tied to individuals.

Step 6: “Segment” Design Documentation as Well #

If documentation becomes a monolith,
only the person who understands all of it becomes strong.

So we segment design documents by role.

• Network design document (managed by Infrastructure Team A)

• Server configuration and role inventory (shared between Infrastructure and Application)

• Application architecture document (managed by Application Team B)

• Authentication and IAM design document (managed by Security Team C)

• Logging and audit design document (Security Team C)

“Design documents written by multiple people and segmented by role” are healthier
than “design documents written by one person and understood by that person alone.”

Step 7: Set up a “Two-Tier Mode” for Emergencies #

In small organizations especially,
you need to avoid the **”nobody can do anything in an emergency and everything falls apart”** scenario.

So we separate the rules for normal times and emergencies.

Normal Times #

• Operate with permissions separated into D1 / D2 / D3

• Dangerous operations are generally D3-only

Emergencies #

• Define conditions such as “complete service outage” or “critical incident”

• With approval from 2 or more people (e.g., leader + security person), temporarily elevate permissions

• After recovery, revert the elevation and review operation logs

This way,

“normally stay separated”
“but when truly necessary, temporarily activate ‘god mode’ with proper audit trail”

you can achieve a good balance.

Summary: “No Need for Super Engineers” Is Not Idealism—It’s a Design Question #

Summarizing the lightweight model presented in this article:

1. Divide roles into 3 domains: Infrastructure, Application, and Security

2. Split permissions into 3 tiers (Operator, Admin, Security), eliminating “someone who can do everything all the time”

3. Keep operation logs properly so “who did what” is traceable

4. Automate infrastructure and configurations with IaC to move “what’s in people’s heads” into code

5. Have systems, not people, hold secrets

6. Manage design documentation segmented by role

7. Set rules to enable “god mode with 2-person approval” only in emergencies

These approaches are based on practices used at major cloud providers, financial institutions, and organizations like SWIFT,
scaled down to be practical for small to mid-size environments.

In Closing #

“One person knowing everything” is
very convenient in the short term, but
becomes a major risk in the long term from the perspectives of business continuity, security, and organizational health.

Conversely,
incrementally pursuing “segmentation,” “separation,” and “automation” makes it possible
to escape “super-engineer-dependent organizations”.

This article is merely one framework, so please adapt it
to your organization’s specific needs.