DEV Community: David Colebatch

Using Zero Trust Networking in Cloud Migrations

David Colebatch — Thu, 09 Jun 2022 18:21:02 +0000

Moving workloads to the cloud has many benefits, and one that is often overlooked is the opportunity to modernize your network.

In a traditional “perimeter-based” architecture, users and devices are authenticated and authorized on a device-by-device basis when connecting remotely via VPN.

The perimeter approach to securing access worked reasonably well when the majority of data was kept within company walls and accessed by a few employees, but as the past few years have shown us: workers are increasingly remote, probably using their own devices but most definitely increasing their thirst for data and cloud-based services.

Something’s gotta give!

The Zero Trust security framework (or architecture) allows you to protect your data without burdening your users with excessive authentication and authorization processes. As companies accelerate their cloud migrations today, mature organizations are seizing the opportunity to holistically rethink how they secure their data and applications. The perimeter network model is often the last to go, but consider this:

LIMIT YOUR BLAST RADIUS

Network and account segmentation reduces the attack surface for workloads in the cloud.

In our data centers, or “on premises”, network segmentation often meant that we would have one production environment and host all of our applications there. One breach though, and an attacker could often move laterally from one production app to another. In the cloud, we can cheaply (read: free) segment each production application into its own network, and make the only interface to data via secure APIs.

Sure, this requires planning and configuration to be properly implemented, but a cloud migration initiative is the perfect time to do this: You have the skills and resources spun up already, and often the desire to improve the status-quo.

YOUR IDENTITIES ARE THE PERIMETER!

With data securely stowed away behind your application layer, the path to access that data is secured via authentication and authorization (IAA). As technology has evolved, so have our behaviors and expectations.

Nowadays, we benefit from the more secure Multi-factor authentication (MFA) in a variety of applications from GMail and Microsoft 365, to Facebook and more. Users are so accustomed to this in their personal computing, that introducing MFA into corporate settings is no longer a change management problem.

In addition to MFA, modern cloud IAA systems allow you to configure conditional access policies which allow you to provide additional layers of security for sensitive data by requiring additional credentials from users.

So What?

More secure, and more predictable migration timelines.

With a Zero Trust approach to your cloud architecture, if when a threat actor gains access to one instance of a workload, they are far less likely to then be able to “pivot” or move laterally through the network.

Using zero trust networking can help you deal with the complexity of migrating workloads to the cloud, making your migration initiative faster and more predictable. One of the ways this is achieved, is by employing templates and modules of infrastructure code such as terraform and being able to stamp out additional environments more quickly and repeatedly, without having to worry about IP planning, network peering, firewall rules and other traditional networking concerns.

Summary

Zero trust’s approach to networking aims to secure applications by assuming that attackers may have already breached other parts of your systems. It requires you to think about cloud as a different paradigm, and avoid re-creating your on-premises network topologies in the first place.

Reach out if you have stories about how pivoting from hub-and-spoke only networking in the cloud to isolated VPCs and VNETs has improved your performance or opsec. I’d love to hear.

-–
David Colebatch is the Chief Migration Hacker at Tidal Migrations. Connect on twitter at @dcolebatch or follow on LinkedIn.

Discover Database Servers In 3 Steps

David Colebatch — Thu, 13 Jan 2022 21:11:55 +0000

I recently had a cloud migration client who was at the beginning stage of their discovery phase and looking to jump straight to “which database platforms should I be using in the cloud?” - a tall ask you might say, but following the three steps below they were able to discover and analyze all of their database servers in just two weeks.

Stepping back for a moment, let’s review “the why” - Why is database analysis important to perform at the earliest stages of a cloud migration?

Why Assess Databases for Cloud?

Increasingly enterprises are coming around to the view that the cloud is more than a datacenter. They frequently tout new drivers such as: unlocking new business capabilities, becoming more agile, and leveraging our data to become more competitive.

The application-centric and data-led migration initiatives we see today are the new normal, and gone are the days of infrastructure-led, lift-and-shift-only migrations. 😅

As such, if you are setting a strategy and planning migrations you need answers to questions like (a) which technologies will we use, (b) what skill sets do I need to develop/hire, and (c) how difficult will it be? Those answers are provided by a comprehensive database and application assessment.

We perform these assessments rapidly using purpose-built discovery and assessment tools, and today I will focus on the three steps you can take today to answer these questions.

Step 1 - Discovery

nmap -sV -p1433,1521-1525,3306,5432,7474,27017 192.168.2.2/24 -oX databases-on-my-network.xml

tidal sync nmap databases-on-my-network.xml

Leveraging the well known and free Nmap, together with Tidal Tools (docs) we can find all the servers on our network that are listening on default database ports, and obviously, you can tweak these for your environment if you know of other ports that your Ops teams may use in addition to these.

In the example above these are:

TCP/1433 - Microsoft SQL Server
TCP/1521-1525 - Oracle Server
TCP/3306 - MySQL
TCP/5432 - PostgreSQL
TCP/7474 - Neo4J
TCP/27017 - MongoDB

Running this nmap command is fast, and results in a portable XML file containing the results.

Note: It’s common practice to have firewalls and IPS devices in enterprise networks to either block or report on this type of discovery. We recommend working collaboratively with your IT Operations and Security teams to determine which networks to run it against, and from what node in the network to begin with.

Once you have your XML file(s) of results, uploading those to the tidal platform is a quick way to bolster your migration inventory with these special servers:

tidal sync nmap databases-on-my-network.xml

Step 2 - Analysis

tidal analyze db databases.yml

With your inventory complete, you can now get credentials to be able to query each of these databases. We recommend discovery tools that require read-only access, like the user permissions required in this guide under Getting Started.

It is worth noting that you do need to analyze the databases you intend to migrate. That is, be sure to analyze your production databases. While it is tempting to claim success after analyzing development or test servers, the reality is that production databases often have (a) different features enabled, but almost always have (b) separate application dependencies and (c) performance requirements.

Step 3 - Plan

Review the analysis results in your Tidal Migrations workspace for each database, and determine if the cloud-native technologies you would like to adopt will be easy or difficult to migrate to adopt for each database. You’ll uncover database features in your Oracle and SQL databases that require extra work to Replatform to alternatives like PostgreSQL, MySQL and others, as well as the number of application dependencies, database sizes and IO performance requirements.

Having these data points at your fingertips for one database is very useful for the migration teams in later stages, allowing them to migrate with certainty and not waste time in endless meetings, or chasing down precious DBA resources (who has enough of them anyway?). Getting this information in aggregate across all your databases early on: priceless. Now we can plan effectively, based on our databases and our actual usage requirements.

Conclusion

As you can see, at even the earliest stages of cloud migration discovery, migration teams can quickly capture data-driven insights from not only their applications and server infrastructure but their databases too. Having this comprehensive assessment available early on informs migration strategy, business case formation as well as migration team staffing requirements. More data upfront means less surprises during migration execution and far better outcomes.

Written By:
David Colebatch, Chief Migration Hacker, Tidal Migrations

AWS Migration: Lessons from the trenches

David Colebatch — Mon, 26 Oct 2020 14:52:32 +0000

It’s been over 12 years that I’ve been on AWS and I’ve seen a lot of cloud adoption initiatives since 2008, lately there’s been an accelerating number of cloud migration projects to AWS, Azure and Google Cloud. It seems only fitting that I share with you a run-down of the top three lessons I’ve learned in this time I’d be interested in hearing yours too.

TOP 3 CLOUD MIGRATIONS LESSONS LEARNED

1. Analysis Paralysis

Usually seen when more traditional IT departments take the lead on a cloud migration, analysis paralysis is the problem of spending months and years in abstract architectural planning meetings trying to solve all the problems of the universe. Generally, this comes from a lack of understanding in the new paradigm that AWS provides and trying to shoe-horn existing ITSM process as well as their datacenter architectures into the cloud-box.

If you find yourself in endless discussions around the perfect landing zone design and playing “what if?” whack-a-mole with your security team, do yourself a favour and spend a few dollars hiring someone who has done it before. Then, start small.

2. Too Big to (not) Fail

On the other side of the spectrum from #1 is when companies jump in without any thought given to the organizational change that is required to support a technology transformation. This results in customers adopting only EC2 and treating AWS as a giant virtualization provider. Yikes — didn’t that strategy ever miss the point — we’ve just moved our same operational problems elsewhere.

Thankfully there are now enough case studies of these lift-and-shift mass-migrations which have resulted in sticker shock, and in some cases, reverse migrations, that our current customers aren’t considering the outsourced “migration factory” approach.

Top trigger term here: “Flash-cut the DC to the cloud.” Yeah, not anymore.

3. Start small, migrate with purpose

The most successful cloud deployments we have seen start with an application portfolio assessment, to identify the low-hanging fruit of applications that are (a) easiest from a technology perspective and (b) valuable enough to the business that the applications migration yields tangible results for the business.

Leveraging out-of-the box landing zone automation and reference architectures gets customers a long way in terms of adopting best practices. Having the organization recognize that these architectures will continue to evolve over time through small incremental changes, will remove the need to wait until every man and his dog has “signed off” on the designs.

It’s a novel approach for most teams, and one that goes against the grain of traditional enterprise architecture gating processes. But it is one that has served us very well in the past, with the right executive leadership to support it.

Summary

Lesson learned: Start small, don’t over-complicate things, and build momentum for your organization. Each migration can feel slow to get going, be it from naysayers, server huggers or lack of confidence from your team itself. If you follow these 3 steps, your migration will snowball and your project sponsor will look like a visionary genius, while your name lives forever as a migration hero.

It’s that easy. :)

-David Colebatch
Chief Migration Hacker, Tidal Migrations