Security and Monitoring
Watching the thing the system is for, not just whether it is switched on.
Green dashboards are not evidence
Most monitoring reports on the machine: is it running, how much memory is left, is the disk filling up. All useful, and none of it notices that last night's export produced 400 rows instead of a million, or that the file your supplier depends on never left the building.
The failures that hurt are usually quiet. Nothing crashes, no alarm sounds, and the first person to notice is a customer three days later. Monitoring the events your business actually cares about is what turns that into a message on a Tuesday morning instead.
The access and network decisions here are made as part of the cloud design, and applied consistently across environments because they are defined as code.
Four ways we get brought in
Three are quiet work done in advance. One is not.
Designing access from the start
Who and what can reach which system, decided while it is still cheap to decide.
Getting credentials out of the code
Passwords in config, keys in a repository, a connection string pasted into a chat two years ago.
Monitoring that means something
Instrumenting the events the business depends on, so an alert names the export that never ran.
After something has gone wrong
What happened, what it reached, and what would have caught it sooner. Then the three above.
What we put in place
- Identity instead of passwords
- Where the platform allows it, a service proves what it is rather than presenting a secret, so there is nothing to leak, rotate or find in an old commit. What must remain a secret is referenced from a vault, not copied.
- One credential per consumer
- Everyone connecting gets their own, so a key can be withdrawn from one without taking the others down with it. It costs nothing to design in and it is close to impossible to add under pressure.
- Alerts on outcomes, not machines
- Each thing that matters emits a record of what it did: how many rows, how large, how long, and where it went. An alert then fires on the absence or the shape being wrong, not just on the process having died.
- The platform's own tooling first
- Monitoring and response build on the security tooling your cloud platform already provides, so the platform you're paying for does the watching, and there's one less product to buy, learn and patch.
What lands on your desk
- An access model written down
- So when someone asks "who can reach that", you look it up.
- Credentials out of the application
- And into a vault, with a list of what we found on the way.
- Instrumented business events
- Queryable after the fact, so you can ask what happened last Thursday.
- Alerts that reach a person
- With an agreed answer to who that person is. Where the estate needs more than one step,.
- a risk-aligned roadmap
- So protection lands in the order the risk justifies.
Our team hears about it before yours does
On our most recent Azure build, the weekly export of over 1.1 million records emits a record of every run: how many rows, how big the file was, how long the generation took against the upload, and where it went. So the question "did it run, and did it look normal" has an answer that does not involve anyone logging in to check. The service itself holds no credentials, authenticating by identity instead, with what must stay secret held in a vault behind a private endpoint. Each consumer connects with its own key, so one can be withdrawn without affecting the rest. Production sits behind a firewall and has no public address, personal references are hashed rather than stored in the clear, and the whole thing had an internal security review before it went live.
Common questions
We already have monitoring. Why would we need more?
Most monitoring answers whether the machine is running. That is worth knowing and it is not the question your business asks. The useful alert is the one that fires when the file did not arrive, the queue stopped draining or the nightly job produced a tenth of the usual rows, all of which happen on a perfectly healthy server.
Who gets the alert?
On work we run, we do. The point of monitoring a system we built is that we hear about a problem first, and your team hears about it from us.
How do you handle credentials?
By having as few as possible. Where the platform supports it, a service proves who it is rather than presenting a password, so there is nothing to leak. What genuinely has to be a secret lives in a vault and is referenced, never copied into configuration or a repository.
What happens when someone leaves, or a supplier's key is exposed?
It should be a small event, not an incident. That means each consumer holding its own credential so one can be revoked without breaking the others, which is a design decision made long before anybody needs it.
Is this the same as a penetration test?
No. A test tells you what an attacker could find today. This is the design work that decides what they would reach if they did, and the monitoring that tells you when something changes. The two are complementary, and a test is a reasonable thing to do after this rather than instead of it.