02 Corporate network and employee access segmentation in a financial company's office

An office of several dozen workstations ran on one flat network. That means exactly what it sounds like: any computer in the office could see any network folder, any service, and any colleague's machine. There was no separation because the network had grown organically: equipment got connected as it showed up, and nobody had designed who should be connected to whom.

Access to working folders rested on shared passwords. The password to the accounting folder was known not only to the accountant: it got passed along whenever someone needed to look at something, and it stayed known long after the need had passed. For a company handling clients' financial data, that means there was no honest answer to the question 'who has access to these files.'

There was no answer to 'who has access to clients' financial data': the folder password was known to whoever it had once been passed to.

A separate problem was the guest network that didn't exist. Contractors, clients, and employees' personal phones connected to the same Wi-Fi as the working machines and ended up inside that same flat network.

Backups were made, but by hand and onto the same server where the originals lived. A copy like that protects against accidentally deleting a file and against nothing else: a drive failure takes out the original and the copy at the same time.

We started with design, not with configuring hardware. First we mapped out what departments the company has, what data each one works with, and which of that must never overlap. The network layout grew out of that mapping: it reflects the company's structure, not the order in which equipment had once been plugged in.

The network is split into segments. A working segment where employees operate, a guest segment where personal devices and contractor connections land, and a server segment where data lives. Traffic between segments follows explicit rules: what's needed for work is allowed, everything else is closed by default. A guest device physically cannot see either working machines or servers.

The network layout grew out of the company's structure, not out of the order in which equipment had once been plugged in.

A server went up inside the office: it holds the company's shared data and internal services. Before this, files were scattered across employees' computers, and a working document existed in three versions on three machines.

Access moved to personal accounts. Every employee has their own sign-in, tied to their department, and rights are granted to the department rather than to each person individually: accounting sees accounting data, the client team sees its own, management sees the consolidated view.

Granting rights to individual people looks more precise, and for the first month it genuinely is. The problem starts afterward. An employee moves from one department to another, goes on leave and hands off their work, quits, comes back for project work. Every one of those events requires remembering exactly what was once granted to them, and in a company of several dozen people nobody remembers that after six months.

Rights tied to a department survive turnover. Onboarding a new employee means adding them to a department, not reconstructing from memory the list of folders an accountant needs. Termination means disabling one account, not hunting down every place a person was listed by name, and not changing a shared password that then has to be communicated to everyone else.

An employee leaving stopped being a reason to change a shared password and hand out a new one to everyone left.

For a financial company this has one more consequence. The question 'who had access to this data in March' now gets a verifiable answer: the department's membership is known, and the department's rights are documented. Previously the answer was a list of people who might have been told the password.

Some employees worked from more than just the office, and they needed internal data outside the workplace. The easy path here is exposing the needed service to the internet and locking it behind a password. We didn't do that: a service reachable from the internet is reachable by everyone, and a password remains the only thing standing between financial data and anyone who wants it.

Instead, remote employees connect to the working network over a secured channel and land in the same segment as they would in the office, with the same rights their department has. Internal services don't face the internet: from the outside, only the connection point is visible, not what's behind it.

Internal services don't face the internet: from the outside, only the connection point is visible, not what's behind it.

Rights don't split into two versions either. An employee working from home and the same employee at their desk is one account with one set of rights, not two access modes that drift apart the moment either one changes.

Backups are now scheduled and written to separate storage, not to the same drive where working data lives. A copy sitting next to the original protects against one scenario out of many, and it's not the scenario backups are made for in the first place.

More important than the schedule itself turned out to be verification. A backup that has never been restored is an assumption, not a backup: a configuration error surfaces at the exact moment restoration is needed right now. That's why restoration is verified, and it's known not just that copies get made, but that data actually comes back up from them.

A backup that has never been restored is an assumption, not a backup.

Everything we configured is documented: the network layout, addressing, the rules between segments, and departmental rights. The document isn't for us: the company's next administrator should be able to work from the description, not reverse-engineer the logic of whatever they inherit.

The company now has a verifiable answer to the question of data access. Not 'accounting knows the password,' but a specific department membership and that department's documented rights. For a financial company that handles other people's money and other people's information, that's the difference between 'we believe things are fine' and 'here is how it's set up.'

Personal phones, contractors' laptops, and guest connections stopped landing on the same network as the working machines and the server.

Working from home stopped requiring a choice between convenience and a network exposed to the outside. And backups turned from a ritual into a mechanism known to work, because it was actually tested.

The whole project took about a month. This is a case where most of the time goes not into configuration but into working out how the company is organized: what the departments are, who works with what data, and which of that must never overlap.