BEARCLAVE

M365 and Azure architecture with security built in

A design of the target environment and landing zones where security is part of the foundation, not stuck on afterwards. An environment that is properly built, sensibly priced and secure from day one.

Price

from 120,000 CZK

Output

by scope, typically 4 to 8 weeks

Approach

security-first, not security on top

Book an intro call What the design covers

Scope of the design

What the design covers

Eight areas. The scope of the network part is agreed up front, because that is where it varies the most.

Hierarchy and subscription modelThe key by which new environments are created, how policy is inherited and where the line runs between development and production.
Identity and permission modelWho can reach what, how permissions are granted and removed and how administration is separated from everyday work.
Network and segmentationThe design of connectivity, separation of environments and control of traffic in and out, to the extent agreed in the order.
A security baseline in the foundationDiagnostics, alerts, environment policy and locks built into the landing zone from the start, not added later.
Cost and how it is managedTagging and naming that make it possible to charge back and find the owner, and an assessment of where security settings make operations needlessly expensive.
The boundary between toolsWhat is managed by infrastructure code and what by tenant configuration. Nothing is configured in two places, otherwise the two drift apart.
Deployment modelHow changes pass approval, what is verified automatically and who has the right to deploy to production.
A machine-readable outputThe hierarchy and the skeleton of the configuration in a form that can be used directly, not just a picture in a document.
What the design does not include

The deployment itself, which is separate follow-on work. Nor does it cover application migration, application architecture, design outside the Microsoft environment and the decision on who gets which permissions — what is designed is the model, not who fills it.

Inputs

What we need from you

  • An account in your environment — either a guest invited into your tenant, or one you create in it. One is enough, it has read access only and you remove it at handover.
  • Read access over Azure from the top level and read access in the identity directory.
  • Access to billing data. Without it the split of subscriptions cannot be designed.
  • The existing network documentation, even out of date. It is an input, not evidence.
  • A decision on who will hold which permissions. That is up to you, the design supplies the model.
  • A note on what must not be migrated or has to stay where it is.

How we treat your environment and data →

Read access is enough for the design phase. The permissions needed for deployment are agreed as part of the follow-on order.

Deliverables

What you get

  • The hierarchy and the subscription model with the reasoning for why it looks like that.
  • The identity model and the permission model.
  • The network and segmentation design within the agreed scope.
  • A security baseline built into the landing zone.
  • Machine-readable inputs — the hierarchy and the skeleton of the configuration, not just a document.
  • The design in PDF, a simple summary for the board and a handover record.
Download a sample deliverablePDF in Czech, based on an anonymised environment

How it runs

How it runs

Intro call

Thirty minutes. We get to know each other and go through what is going to be deployed, who will run it and how you are connected to your own infrastructure.

Snapshot of the environment

Collection of the current state and of billing data. No impact on operations.

Design

Hierarchy, identity, network and baseline. Decisions are consulted as we go, not delivered as one large document at the end.

Handover

A presentation of the design and handover of the machine-readable inputs.

Frequent questions

What people ask most often

Are you not security people? Why do you design architecture?
Both. A design of an environment made by someone without security knowledge has to be redone within a year, because protection cannot reliably be stuck onto a finished hierarchy and network. And the other way round — security recommendations from someone who does not understand what Azure and Microsoft 365 should look like cannot be deployed in practice. This service sits exactly at the intersection.
How does it differ from a typical environment design?
The security foundation is built together with the environment, not as a separate phase that comes later. Diagnostics, alerts, policy and permissions are designed together with the hierarchy and the network, not after them. The second difference is the output: a machine-readable design, not a document.
Will security make it more expensive?
Not necessarily, and cost is part of the design itself. Security settings drive the price up mainly through what is logged and which protection plans are switched on. The design therefore also includes an assessment of where savings are possible without losing visibility.
Do we have to order the deployment from you?
No. The design is yours and it is machine-readable precisely so that anyone can build it. If you build it yourselves or with another supplier, that is fine.
Someone else has already built our landing zone.
Then the design can work as a review. A frequent finding is a hierarchy built around an organisational structure that has changed twice since, and policy nobody enforces.

Related

What it leads on to

Hardening M365 and AzureThe configuration analysis often shows that the problem is in the foundation. Microsoft Sentinel — optimisationThe design decides what gets logged and at what cost.

Are you building an environment that will last five years?

On the call it is enough to say what is going to be deployed and who will run it.

Book an intro call Back to the services