Secure-by-default architecture: how ArduMaker is designed
Published on 2026-09-12 by frfrand
Puertos cerrados por defecto, SSH con fecha de vencimiento, aislamiento por empresa y auditoría de cada comando: por qué la seguridad que depende de la memoria siempre falla.

Almost all security incidents that end badly start the same way: someone opened something "for a while" and forgot about it.
Port 5432 opened to test a connection from home. SSH access given to a contractor in March. The temporary firewall rule that has been there for eight months. None of those decisions were irresponsible at the time; the problem is that they depended on someone remembering to undo them.
That's why the question guiding the design of ArduMaker is not "how do we make this more secure?" but "how do we make this not depend on someone remembering?".
Closed by default, open by declaration
The initial state of a VPS in ArduMaker is: everything closed. No ports listening to the world except those you declare explicitly.
The difference with the usual approach is subtle but important. On a common server, secure configuration is something you do after installing: you close what you don't use. This means there is a window, sometimes minutes and sometimes months, in which the server is more open than it should be.
When the default state is closed, that window does not exist. And neither does the work of keeping it closed: there is nothing to review periodically, because opening something requires a deliberate action that is recorded.
SSH with expiration date
This is the part we are asked about most, so it's worth explaining in detail.
When you request SSH access to a VPS, the port does not open "until you close it." It opens with a closing timestamp. A control process periodically checks those timestamps, and when one expires, it closes the port.
You don't have to remember. You don't have to set a reminder. No access remains open from that time you went in to check a log.
In practice, this changes the psychology of access: requesting SSH stops being a decision that drags on indefinite consequences and becomes something cheap, because it reverts on its own. And since it's cheap, people request exactly the access they need instead of requesting "everything, just in case."
Isolation as structure, not as configuration
There are two ways to separate clients in an infrastructure.
The first is by configuration: a shared server where each client has their user, their folder, and their permissions. It works as long as no one makes a mistake with a chmod, as long as no application has a privilege escalation vulnerability, and as long as the neighbor next door doesn't consume all the CPU.
The second is by structure: each client lives in a separate Company, with their own VPS. There are no permissions that can be misplaced between one and another, because there is no place where they touch.
ArduMaker uses the second. It is more expensive to operate and much harder to break by accident, which is exactly the trade-off we are looking for.
Everything is written down
Every command executed on a VPS through the platform is logged: what was executed, who launched it, and when.
This is not just for formal audits. The real value shows up in day-to-day operations, when something stopped working and the question is "what changed here?". Without a log, the answer is usually a reconstruction from memory. With a log, it's a query.
The same goes for backups: they are stored on a host different from the one running the VPS, because a backup on the same disk as the database is not a backup, and they are verified with their hash, so you know if the file is intact before you need it, not after.
SSL without calendar dates
Let's Encrypt certificates last 90 days. That is, statistically, one of the most common causes of a site going down: no one touched anything and suddenly the browser shows the red warning.
In ArduMaker the certificate is issued and renewed automatically. There is no cron task that someone has to check, nor an email that someone has to read.
It's the same principle as always: if a task has to happen no matter what, it cannot depend on a person.
The underlying idea
Minimizing human error is not distrusting people. It's accepting that we all have bad weeks, and that an infrastructure that is only secure when the team is rested and attentive is not secure.
More isolation, more control, fewer things to remember.

