Traffic Light Protocol alike Security Reference Architecture for Azure

Introduction

The way how organizations categorize/handle classified information can vary significantly. Where it can go from about 6 categories towards a more “limited” set of 3 to 4 categories. Where you see that some government organizations have even tried to reduce this in an effort to make it more accessible.

 

So for today, we’ll be looking at how we can handle sensitive/classified information in Azure. And to ensure you that you Azure implementations can facilitate sensitive data.

 

Side Story : Security should be like a roundabout

Though I don’t remember which conference talk it was… One visual has always stuck with me when talking about security. Imagine security like road infrastructure. Having a complex situation might be needed at times, though it will increase the risk that the drivers (~users) will make mistakes.

Cloud Migration Strategies – The Subway Map!

A while ago I saw a kinda flow chart / subway map entailing the various paths to migrate your workloads to the cloud. My personal view on the matter differed slightly from this, so I’ve mocked up my own version…

 

 

The various tracks ;

• “Retire” ; For the workloads that are not relevant anymore to the business… decommission them.
• “Re-Host” ; A typical “lift & shift” scenario where you move the system “as-is” to the cloud.
  • Variant “Manual” ; Tedious effort… doing a manual rebuild of your systems in the cloud.
  • Variant “Automated” ; Work via migration tooling or redirect your automated deployments.
• “Re-Purchase” ; Some applications are not compatible with cloud platforms. Therefore it might sometimes be interesting to purchase another software suite. Where you’ll join the manual track once the implementation starts…
• “Re-Platform” ; Cloud provider typically offer “PaaS”-services too, where an On Premises deployment only favors “IaaS”-thinking. Examples here ; IIS on premises vs Webapps in the cloud.
• “Re-Architect” ; If you have control over your application, you might consider to refactor it towards cloud native components. Given, this is not always an easy/cheap task, but it’s a play considering the long term.

But for all, it starts with ;

• Discover ; Identify all the workloads in your IT landscape.
• Assess ; Investigate their readiness towards the cloud and which migration paths are viable.

And “ends” with ;

• Validate ; After a “construct” / “deploy”, always validate (test) if everything is according to your expectations / specifications.
• Transition ; Never forget to ensure that your operational team is ready before the “go live” of your workload.
• Go-Live ; The moment your customers will use the workload. 🙂