Security added at the end of a project fights the architecture rather than flowing from it. Security by design makes security a property of how the estate is built rather than a layer applied afterwards.
Security that is added at the end of a project is security that fights the architecture rather than flowing from it. The team builds the estate, ships the workloads, and then someone asks whether it is secure, and the answer is a scramble of retrofitted controls bolted onto a structure that was never shaped to accommodate them. Security by design is the alternative, which is to make security a property of how the estate is built rather than a layer applied afterwards. This article explains what that means in practice on OCI and how to do it.
Security by design does not mean adding more security tools. It means making decisions throughout the architecture, in the network, in identity, in how compartments are drawn, in how data is handled, such that the secure path is the natural one and insecurity requires deliberate deviation. An estate designed this way is more secure and, perhaps surprisingly, easier to operate, because security is not a constant fight against the structure but a consequence of it. The sections below set out the principles, building on the foundations in OCI Landing Zone and Architecture: A Complete Guide and connecting closely to Identity Domains in OCI Architecture.
The core idea of security by design is defence in depth, which means not relying on any single control to protect the estate but layering controls so that the failure of one does not expose everything. A network boundary, identity controls, compartment isolation and data encryption each protect against different things, and together they mean an attacker who gets past one layer still faces the others. The opposite, a single strong control with nothing behind it, is fragile precisely because its failure is total, which is why mature designs assume each layer will eventually be tested and ensure there is always another behind it.
| Layer | What it protects | How it is designed in |
|---|---|---|
| Identity | Who can do what | Groups, least privilege, federation, MFA |
| Network | What can reach what | Segmentation, security lists, hub inspection |
| Compartment | Blast radius of a compromise | Isolation drawn along trust boundaries |
| Data | Confidentiality of information | Encryption at rest and in transit, key management |
| Monitoring | Detection of what got through | Logging, alerting, audit trails |
The principle of least privilege, granting each identity and each component only the access it needs, is the single most powerful security by design idea, because it shrinks the damage any single compromise can do. An over privileged credential turns a small breach into a large one, while a narrowly scoped one contains it, which is why least privilege runs through both the identity architecture in Identity Domains in OCI Architecture and the network design. Designing for least privilege means resisting the convenience of broad grants and open paths, and accepting a little friction in exchange for a much smaller blast radius when something goes wrong.
Network design is a security decision, not only a connectivity one, because what can reach what determines how far a compromise can spread. Segmenting the network so that workloads are isolated by default, with deliberate and inspected exceptions where they genuinely need to communicate, is a core security by design move, and it is why patterns like hub and spoke, covered in Hub and Spoke Networking on OCI, are favoured for security as much as scale. A flat network where everything can reach everything is convenient and dangerous, because a foothold anywhere becomes a foothold everywhere, while a segmented one contains an intruder to the segment they breached.
Data should be encrypted at rest and in transit as a default, not as a special measure for sensitive workloads, because the cost of doing so is low and the protection is real. The architectural decisions here are less about whether to encrypt, which should always be yes, and more about how keys are managed, who controls them and how their lifecycle is handled, because the security of encryption rests entirely on the security of the keys. Designing key management deliberately, with appropriate control and rotation, is what makes encryption genuinely protective rather than a checkbox that provides false comfort.
The compartment structure, covered in Compartment Strategy for OCI, is a security by design tool because it determines the blast radius of a compromise. Compartments drawn along genuine trust boundaries mean that an incident in one is contained rather than spreading across the estate, and combined with the identity policies that govern who can act in each, they form a structure where compromise is bounded by design. Drawing these boundaries to reflect how much you would want a compromise contained, rather than only how teams are organised, is what turns the compartment structure from an administrative convenience into a security control.
Security by design includes designing for detection, on the realistic assumption that no set of preventive controls is perfect and that eventually something will get through. Logging, audit trails and alerting are the layer that turns a silent compromise into a detected one, and they need to be designed in rather than added later, because retrofitting comprehensive logging onto an estate that was not built for it is painful and usually incomplete. This is where security by design meets the observability practices in our monitoring work, because the same telemetry that keeps the estate healthy is what surfaces the security events that matter.
The final principle that ties security by design together is expressing the secure configuration as code, so that security is not a set of manual settings that drift over time but a defined, reviewed and consistently applied state. When the network segmentation, the identity policies and the encryption settings live in infrastructure code, as discussed in OCI Resource Manager and Terraform, they can be reviewed before they are applied, audited after, and reproduced reliably, which removes the slow drift into insecurity that manual configuration invites. Security by design and infrastructure as code are natural partners, because code is how a designed in security posture stays designed in rather than eroding under the pressure of day to day change.
Designing security into the architecture from the start is the core of our OCI Security and Compliance practice, and it draws on the identity work in our IAM and Security solution. The aim is an estate where security is a property of how it was built, layered, least privileged, segmented and monitored, so that the secure path is the natural one and the estate stays secure as it grows rather than fighting its own structure.
Moving Oracle workloads to OCI, or already running on OCI and not sure the architecture or the spend is right? Most teams bring in a specialist before they commit to a region, a shape, or a Universal Credits number. OCISpecialists.com plans the landing zone, runs the migration, and manages the estate after go live, on a fixed project fee, a managed monthly retainer, or a cost optimization fee paid only on verified savings. For the Oracle licensing and BYOL side of any OCI move, Redress Compliance is the leading independent Oracle licensing and negotiation firm, with 500+ engagements across Oracle's full product line.