CANYO CANYO

BEHIND THE SCENES OF

CANYO CANYO

How CANYO
Actually Runs.

You trust us with your technology. Here's what happens behind our walls.

// WHY WE'RE SHOWING YOU THIS

You Shouldn't Have to Trust a Black Box

CANYO is a Tucson-based managed IT services provider. We manage technology, infrastructure, security, backups, and day-to-day IT operations for businesses that depend on their systems working reliably.

That creates an important responsibility. Clients trust us with access to their networks, devices, systems, credentials, backups, and business data. We don't think that trust should require a black box.

So we've decided to open the box. Not by publishing credentials, internal addresses, or operational secrets — those should remain private. Instead, we're willing to explain how CANYO itself is designed and operated, the principles behind those decisions, the technologies we use, and the controls we use to enforce them.

Because we believe a good MSP should be willing to show its work.

// NON-NEGOTIABLES

The Four Principles We Don't Compromise

01

Least Privilege

Access should provide only the permissions actually required to perform a job. If something doesn't need the ability to delete, it shouldn't have delete permission. If something doesn't need administrative access, it shouldn't have it. We apply this to credentials, backups, infrastructure, automation, and the systems we use to manage technology.

02

Defense in Depth

Important security boundaries shouldn't depend on a single control. We design multiple independent layers so that a failure of one control doesn't mean the next boundary disappears with it. Security shouldn't be one locked door — it should be multiple doors that don't all use the same key.

03

Verification Over Trust

We don't consider something secure simply because it was configured that way. We test. Security-relevant configurations are verified against controlled or disposable systems before we trust them with real client data. The question isn't "did we configure it correctly?" — it's "can we demonstrate that it actually behaves the way we intended?"

04

Isolation by Default

Systems should be separated unless there is a deliberate reason for them to communicate. We don't want security to depend on someone remembering not to cross a boundary. Where practical, the boundary should be enforced by the technology itself.

These aren't four ideas we put on a webpage. They're constraints we use when building and operating CANYO.

// DEFENSE IN DEPTH, IN PRACTICE

Our Layered Access Model

One of the clearest examples of how CANYO applies its security principles is the way we protect our own internal management tools. They are not exposed directly to the public internet. Access is intentionally layered, with multiple independent controls between an outside user and the actual application.

// THE ACCESS PATH

01

Tailscale

Private network access

02

Authentication Gateway

Username + password

03

Second-Factor Verification

Independent second authentication factor

04

Application Authentication

Separate application credentials

Getting through one layer does not automatically get you through the next.

LAYER 1 — PRIVATE NETWORK ACCESS

Tailscale

The first boundary is the network itself. We use Tailscale to create a private, encrypted mesh network between authorized devices and internal resources. Our internal management tools are not sitting on the public internet waiting for someone to find a login page. A device must first be authorized to participate in our Tailscale network before it can even attempt to reach those services. An unauthorized party would first have to somehow gain access to an authorized device or otherwise satisfy the controls governing our private network — otherwise, the internal application simply isn't reachable.

LAYER 2 — USERNAME + PASSWORD

Authentication Gateway

Assume, purely for the sake of explaining the architecture, that someone somehow makes it through the private network layer. They still haven't reached the application. The next boundary is a dedicated authentication gateway requiring a separate username and password. These credentials are not the same credentials used by the underlying application. Getting through the private network therefore does not automatically make someone an authenticated user.

LAYER 3 — SECOND FACTOR

Second-Factor Verification

Take the hypothetical one step further: suppose someone somehow obtains the correct gateway username and password. They're still not through. The next step requires an independent second factor of authentication. This creates another separate requirement before the protected application can be accessed — a compromised password alone is not intended to be sufficient.

LAYER 4 — SEPARATE CREDENTIALS

Application Authentication

Now suppose someone somehow makes it through every previous layer. They finally reach the actual internal application — and they're still not automatically logged in. The individual application maintains its own separate authentication, with credentials distinct from those used by the gateway. We deliberately don't identify which internal applications we run: the architecture is what matters, and publishing a target list would only hand out enumeration information.

// FOUR INDEPENDENT QUESTIONS

01

Tailscale

Is this device authorized to participate in our private network?

02

Gateway

Does the user have the correct username and password?

03

Second Factor

Can the user satisfy the second authentication factor?

04

Application

Does the user have the separate credentials required by the actual tool?

A user must successfully pass each of these layers before the protected application can be accessed.

// THE REASONING

Why We Built It This Way

Could we make this easier? Absolutely. We could expose an application directly to the internet. We could use a single authentication layer. We could reuse credentials. It would also be easier to operate. We deliberately chose otherwise.

The goal isn't to claim that any individual security layer is impossible to defeat. The goal is to make sure that defeating one layer does not automatically defeat the next. A person who somehow crosses the network boundary still encounters authentication. A person who somehow obtains a password still encounters two-factor authentication. A person who somehow crosses those controls still encounters the application's separate credentials.

The additional friction is intentional. Defense in depth means that one mistake, one compromised credential, or one failed control should not automatically become complete access.

// THE TOOLS

The Technologies Behind CANYO

Our stack explains what we use. Here's why each piece exists in this architecture.

Tailscale

The private mesh network connecting authorized devices to internal resources. Its role: keep internal services off the public internet and restrict network access to authorized devices.

NETWORK BOUNDARY

Authentication Gateway

A dedicated authentication layer in front of protected internal services. Its role: provide another independent boundary, including two-factor authentication, before any application can be reached.

AUTHENTICATION BOUNDARY

Application Authentication

The applications themselves maintain their own authentication. We don't treat the gateway as a replacement for application-level security — where practical, the application has its own separate credentials.

APPLICATION BOUNDARY

The products themselves aren't the security strategy. The architecture is. Together, they create multiple independent controls between an unauthorized party and the tools we use to operate CANYO.

SEE WHAT CANYO USES →

// BACKUPS

Backups: Designed to Resist the Worst Case

Backups are only useful if they survive the thing you're trying to recover from. That's why we don't treat backup security as simply "we have another copy of the files." We care about what an attacker — or a compromised machine — is actually capable of doing to that copy.

Data is encrypted before transmission. Files are encrypted on the client device before they ever leave it, so the backup destination isn't simply receiving a collection of readable client files.

The backup credential can't delete what it creates. The credential stored on a client device is intentionally limited: it can add new backup data, but it cannot delete existing backup data. If a client machine were compromised, the credentials available on that machine shouldn't automatically give an attacker the ability to erase the backup history they need to destroy. A separate credential exists for cleanup and administrative operations — and that credential does not live on the client device.

Least privilege isn't a statement here. It's a property of the credential itself.

// ISOLATION

Client Network Isolation Is Enforced Technically

We don't want network isolation to depend on a policy that says "CANYO won't let these systems communicate." We prefer the network itself to enforce the boundary. A client's devices are permitted to communicate according to the rules defined for that environment — and where communication isn't permitted, the network prevents it.

That's an important distinction. A policy depends on someone following the policy. A technical boundary doesn't care about someone's intentions.

It's the difference between saying "please don't open that door" — and building the door so you don't have access to it in the first place.

// HUMAN ACCOUNTABILITY

Some Things Should Still Require a Human

Automation is powerful. But automation shouldn't mean that every sensitive operation becomes possible without deliberate human involvement.

The provisioning of new infrastructure that touches our most sensitive master credential remains a deliberate human step. It isn't something we allow an unattended process to perform automatically — a real person has to trigger it intentionally when it's needed.

We deliberately accept that small amount of friction, because the alternative is allowing one more highly privileged operation to happen without human intent.

// VERIFICATION

We Test the Isolation

A configuration isn't proof. A policy isn't proof. A checkbox isn't proof.

Behavior is proof.

When we introduce security-relevant infrastructure or configurations, we test the isolation and behavior against controlled, disposable systems before trusting those configurations with real client data. The goal is to discover mistakes while they're cheap and harmless to fix. We would much rather discover that an isolation boundary doesn't behave as expected in a throwaway environment than discover the same thing after a real client system is involved.

This is the same philosophy we apply throughout CANYO: Verification Over Assumption.

// THE CANYO APPROACH

Enforcement Over Promises

There is a common pattern in technology: "we have a policy for that." We prefer a different question: can the system enforce it?

THE PROMISE VERSION

  • "We have a policy that these networks don't communicate."
  • "We have a policy that backup credentials are protected."
  • "We have a policy that sensitive changes require approval."
  • "We have a policy that security boundaries are tested."

THE CANYO VERSION

  • The network itself prevents the communication.
  • The credential technically lacks deletion privileges.
  • The process requires deliberate human action.
  • The boundary is tested against disposable systems first.

This doesn't mean policies aren't important. It means important policies should be backed by technical controls whenever practical.

// THE DIFFERENCE

What Makes CANYO Different

We don't believe managed IT should depend on trust alone.

CANYO builds its operations around verification, restricted access, technical isolation, and deliberate change. When something matters, we look for ways to make the desired behavior enforceable rather than simply writing a policy and hoping someone follows it.

That's why we don't just ask: "Do we have a policy for this?" We ask: "Can the system enforce it?"

That distinction shapes how we approach security, backups, access, network design, infrastructure, and day-to-day IT operations.

We don't just manage technology. We engineer the environment around it.

// THE BUSINESS TRANSLATION

Why This Matters to Your Business

The point of all this technology isn't to impress another IT professional. It's to reduce two things for the people running a business.

Less Downtime

Technology should be predictable. Problems should be detected early, systems maintained deliberately, backups usable, and changes made with an understanding of how to reverse them. The goal isn't simply to respond when something breaks — it's to make serious problems less likely to happen in the first place.

Less Stress

Business owners shouldn't have to wonder whether everything is actually working, whether the backups are really there, who has access, or what happens if a computer fails or ransomware hits. Good IT should remove uncertainty rather than create more of it.

The technology is important. But the outcome we care about is a business that can operate without constantly worrying about its technology.

// TRANSPARENCY WITHOUT EXPOSURE

What We Keep Private

Transparency doesn't mean publishing an attack map. There is a meaningful difference between explaining architecture and exposing secrets.

WE'RE HAPPY TO EXPLAIN

  • Our security principles and access-control approach
  • How we think about isolation and backups
  • Why we use multiple security layers
  • How we verify important configurations
  • Why certain operations require human involvement
  • The technologies we use to implement these principles

WE DO NOT PUBLISH

  • Credentials, secrets, or keys
  • Internal addresses, hostnames, or ports
  • Authentication endpoints or configuration details
  • Internal application names or client infrastructure details
  • Anything that would unnecessarily increase our attack surface

Transparency means showing our reasoning, not handing out the keys.

// OPERATING PHILOSOPHY

We Don't Expect You to Take Our Word for It

That's the underlying idea behind everything CANYO does. We document. We verify. We isolate. We restrict access. We test. We make important boundaries technical where practical. And when something is important enough to require an exception, we want that exception to be deliberate rather than accidental.

Our clients don't need to understand every technical detail behind their environment. But they should be able to understand the philosophy behind the way we operate it.

// THE SHORT VERSION

If You Remember Nothing Else

01

Least Privilege

Give systems only the access they need.

02

Defense in Depth

Don't let one failed control become total access.

03

Verification Over Trust

Don't assume a security boundary works. Test it.

04

Isolation by Default

Don't rely on people to respect boundaries that technology can enforce.

We try to make the secure behavior the behavior the system permits.

That's how CANYO runs behind the scenes. That's also how we believe managed IT should be done.

// GET STARTED

Want IT That Works This Way for Your Business?

CANYO provides structured managed IT services for small businesses in Tucson and across Southern Arizona. Monitoring, maintenance, support, backup and recovery, security, reporting, and ongoing management — handled as one managed system. Less downtime. Less uncertainty. Less IT to worry about.

Get a Free Assessment See What's Covered