All you need to get started.
Depending form your are coming from, your background will force you to thing is a certain way.
If you only know a hammer as a tool, all your problems will be handle like a nail. So if you have a infrastructure background is likely that your would say that the network perimeter is fundamental and must be define in first place. Is you are from security, all must be closed. Is you are from the development area, you will just deploy and run.
All is needed, true! Moving into the cloud you must put identify as your first objective, at least if you like to get it right with a single attempt. How many tenants? How many active directories? Who is managing what? Who can access? etc. and more.
Keep your number of tenants limited, TWO are more than sufficient. One for your identity team (sandbox tenant), and identity based projects, and yet another for the rest (Production Tenant). If you already have more, prepare to spend money in keeping systems that you do not need that much.
Are we ready to define the network? Not yet.
Another key aspect to consider is the type of clouds you need in your company. Yes, there are many types of clouds, and I’m not talking about cloud providers, like Microsoft, Amazon or Google.
In simple terms, you need a Sandbox to play in, you need a Manged service area to optimize your workloads and teams, you need a data center extension and you need an innovation area. Let’s define the cloud types like this: Sandbox - A non production subscription that allows you the tryout cloud services, with the limitation that will get them evicted after a trial period. Manage - A production and non production subscriptions, manage under your Azure DevOps Factory, with the limitation of only using pre approved architectural patterns, forcing a limited set of resources. Innovation - A production and non production subscriptions, manage under your Azure DevOps Factory, limited by operational capacity, run on best effort and bound to a time frame, either moves to Managed or gets evicted. Extension - A production and non production subscriptions, manage by your operations team, to extend the data center network into Azure, limited for internal access.”
There is no way that you can make it without automation. The cloud industrialization (revolution) is based on controlled automation.
In software we are trying to translate the real world process and behaviors, in order to help people, use their time in the most effective way. For the cloud revolution you need to translate your company enterprise architectures, solution architecture, all architecture into metadata, that in turn can be handle by algorithms.
The Architectural Metadata is the foundation of Azure DevOps Factory. It is what allows all sorts of nice, fluid process, that actual serve Security, Developers, Operations, Governance, Auditors and others.
In any automation scenario you need an orchestrator, a system that can read your Architectural Metadata and trigger all necessary executions, like: scripts, APIs, workflows, communications, etc.. “
Meeting after meeting, session after session, just talking and writing the definitions of what will be your cloud. This pain is needed, you need to send time in having a proper taxonomy and classifications.
This is the shelf where you put books in a certain order.
This is the base to describe the architectures, but also to set order in process and teams, fundamental to your naming convention and tagging strategy.
Granting that you have 2 tenants, and they are called something like [name].onmicrosoft.com and [name]SBX.onmicrosoft.com. You have defined 2 constants in your architecture. I my descriptions I do not spend too much time on the sandbox tenant, I will focus more on the production tenant.
Subscriptions, main key classifications are the split in production and non production subscription, and clearly the cloud type they represent. Subscription classification:NP and PR. Subscription type: SB, MNG, INN, EXT. As sandbox does not have production, your will have 7 subscription to manage.
Depending of the size of your company and the geo location of teams, existing data centers, business demand, pure business segregation, you will be needing to access if there is the need to multiply the sub. class./type by X.
Let’s imagine that your are part of a large multi national, with several type of business. On unit A buys/sells cars, the unit B build/sell houses. Each as their own IT, and unit A is in Europe and Asia, while unit B is in Europe and America.
At the Azure enterprise level you will split this two. having one IT team managing 7 sub. and another 7 sub. for unit B. This puts us at 14 subs. Just maybe this is too many. Question your self is my innovation unit split as well? Do I have a global IT? Is the data center shared?
After some time, and practice, you will come to the conclusion that the company need 1 sandbox, 4 innovation, 2 extension, and 4 managed. That make 11 subscriptions, this is already a good number, remember less subscriptions are easy to secure and manage.
There is so many possibilities of organizing your IT department but is will always end up with some level of segregation. At least at a role level, developers want to code, and cloud operations want to keep the system reliable and always running, product owners want the latest new features ready to be used, testers want a stable environment to test on, and sufficient time to do it.
Here you already get some sense of what you need. A SecDevOps oriented organization that provides independency to projects while keeping things under predefined boundaries. (basically, telling what a project can do and what cannot do).
Yes, your IT operations are no longer the right name for them, they are now Reliability Engineers. You need them to keep the system running and stable. Their focus is not to run and execute operations, but to assure a reliable platform. But how? By working side by side with the DevOps teams in giving them the working boundaries.
The other question I get a lot is, why Sec at the beginning of the SecDevOps, most of the time is at the middle. I am a true believer that security is a feeling, not a fact. You can feel more or less secure, you cannot state that you are completely secure. Therefor, you need to think about security at the beginning, while you are doing idealization, not later, as an afterthought.
In summary, you need a SecDevOps team per each Project, you need the support from subject matter experts on security, operation, development, cloud, reliability engineers, release managers, etc… Depending on your scale, number of people, project, roles, budget, it will define the IT organization, it can be just one person, or thousands. Most important make sure that your architecture fits your organizational needs, or you will end with a software you cannot manage.
04 September 2015
Zug, Switzerland