Architecture Models and Their Security Implications
Compare and contrast security implications of different architecture models
What you will learn
- Compare on-premises with cloud by what you gain and lose, not by which is "safer".
- Explain shared responsibility and know what stays yours under each service model.
- Understand why the triad's priorities invert in industrial control systems.
- Tell virtualisation, containers and serverless apart, and what each does to isolation.
The commonest misreading of this objective is asking "which model is more secure?". There is no answer. On-premises gives you total control and hands you the entire burden; cloud moves part of that burden to a provider and takes away your visibility beneath it. The trade itself is the subject, and the question describes a need and asks which model serves it.
The models
| On-premises | Everything is yours: hardware, network, patching, physical security. Total control, total responsibility, fixed cost. |
|---|---|
| Cloud | Shared infrastructure at a provider. Elasticity and speed, in exchange for third-party dependence and limits on what you can see and control. |
| Hybrid | A mix of the two. It widens the attack surface, because the join between the environments becomes a target in itself. |
| Virtualization | Virtual machines on one host, each with a full operating system. Isolation is strong; the risk is VM escape. |
| Containerization | Containers sharing the operating system kernel. Lighter and faster, and their isolation is weaker than virtualisation for exactly that reason. |
| Serverless | You run code without managing a server. The provider handles the whole platform; you remain responsible for your code, its permissions and its data. |
| IoT | Small connected devices. Their problem: default credentials, rare or nonexistent updates, and a long service life. |
| ICS / SCADA | Industrial control systems running plants, power and water. They are not taken down for updates, and their failure is physical, not digital. |
| IaC | Infrastructure as code: servers and networks defined in files. The gain is consistent, reviewable configuration; the risk is that one mistake replicates everywhere at once. |
On-premises vs cloud
| On-premises | Cloud | |
|---|---|---|
| Control | Complete, down to the hardware | Ends at the service boundary |
| Responsibility | All yours | Split — and the line moves with the service model |
| Visibility | You see every layer | You cannot see beneath the service |
| The characteristic risk | Patch lag and missing expertise | Misconfiguration — the best-known cause of leaks |
Shared responsibility: where the line falls
Infrastructure as a service
The provider secures hardware and virtualisation. You are responsible for the operating system and its patching, the application, the data and the permissions.
Platform as a service
The provider also takes the operating system. The application and the data remain yours.
Software as a service
The provider handles nearly everything. What always stays yours: your data, who reaches it, and how it is configured.
"We moved to the cloud, so we're secure now"
Moving shifts some responsibility, not all of it. The data, who reaches it, and the service's settings stay yours under every model without exception — and most cloud leaks come from a customer's wrong setting, not a breach of the provider. Any option saying the provider owns data security entirely is wrong.
In industry the triad inverts
In ordinary IT, confidentiality usually comes first. In industrial control systems: availability first, then integrity, then confidentiality. The reason is physical, not philosophical — stopping a production line or a water plant has immediate consequences, which is why these systems are not taken down for updates and why security agents that might slow them are kept off them.
Real-world example: the model follows the need
A hospital needs three different things: patient records under a regulation requiring the data to stay in-country, an appointment application whose load multiplies seasonally, and vital-signs monitors that must not stop. No single model serves all three. The records stay on-premises or in a cloud region inside the required sovereignty boundary. The booking application is an excellent cloud candidate, because elasticity is exactly its need. The monitors are closer to ICS: isolated on their own network and not updated during operating hours. An exam question describes one of these needs and asks which model serves it.
What matters on the exam
- Never pick a model because it is "safer". Read the need: elastic load, data sovereignty, or continuity that tolerates no interruption.
- Data, access and configuration are yours under every cloud model. That is the key to shared-responsibility questions.
- Containers share the kernel, so their isolation is weaker than virtual machines. If the question asks for the strongest isolation, the answer is virtualisation, not containers.
- ICS and IoT: no easy patching, long life, availability first. The answer for them is usually isolation and segmentation, not updating.
Quick check
Answer in your head first, then reveal.
Under SaaS, what remains your responsibility?Reveal the answer
Your data, who reaches it, and the service's own settings. The provider handles infrastructure, platform and application — it does not make your decision about who gets access.
Why does availability outrank confidentiality in industrial control systems?Reveal the answer
Because the impact of stopping is physical and immediate: a line halts, a water plant fails. That is why they are not taken down for updates, and why their weaknesses are handled with isolation and segmentation instead of patching.
What is the characteristic risk of infrastructure as code?Reveal the answer
That a mistake replicates as fast as a correct setting does: one wrong value in the template lands on every environment at once. It is also the source of its strength — which is why those files are reviewed like code.
A company wants the strongest possible isolation between two sensitive applications on the same host. Containers or virtual machines?Reveal the answer
Virtual machines: each has its own kernel and operating system. Containers share the host kernel, so one kernel flaw reaches all of them.
Sign in to track your progress on this topic.
Your next step
Read the lesson, then mark it complete
Sources
Used to verify the facts. The writing is original to Passuit.