E13 · Woori FIS · Feb 2026 – Oct 2026
Setting a security baseline for a financial cloud that had none
Network separation as structure, security settings as code
IaC 0 → Terraform standard
- AWS
- Terraform
- Network separation
- Network Firewall
- WAF
- Finance
In one line
I moved network separation rules out of documents and into structure and code, so every new account gets the same security baseline.
Background
I joined as an early member of a financial group’s public cloud adoption. The group’s companies were adopting cloud for the first time, and there was no IaC (managing infrastructure as code) at all.
Each account had different needs, but the common security baseline had to hold everywhere.
What I did
Network separation became design principles. Network separation (a Korean financial regulation) splits networks by sensitivity so outside threats cannot reach inside directly. I turned it into three principles.
- Separate the DMZ subnet, which faces the outside, from the internal Private subnet
- Block public IPs on backend resources entirely
- Allow outbound traffic to approved destinations only
These principles shaped the design of the VPC (virtual network), security groups, and endpoints (paths to AWS services that do not cross the outside network).
What I did
Security settings became code. I introduced Terraform and defined AWS Network Firewall (a firewall in the VPC path) and AWS WAF (a web application firewall) as code. The same code went to every account, which removed the variation between engineers by design.
For baseline DDoS protection, I used AWS Shield Standard, which AWS applies to every customer automatically.
Result
- The same security baseline repeats through code as accounts are added
- Settings no longer vary by engineer
What I learned
Put a rule in structure and code instead of a document, and every deployment meets the same bar.
The less familiar the environment, the more it helps to turn constraints into concrete items first. Then the first step becomes clear.