First steps to a successful cloud migration: know the cloud’s risks and how it will fit in the enterprise’s IT structure

Editor’ note: This chapter is excerpted from chapter 5 of Identity Management: A Business Perspective (MC Press, 2016).

The cloud provides an ideal opportunity for organizations to rethink their identity management (IdM) environment and plan an approach that will not only allow them to manage their cloud-based future but also exploit the capabilities of the cloud to drive an innovative and agile organization.

Possibly the biggest issue when considering cloud migration is the changes it makes to the way IT is managed within an organization. In some companies, cloud is seen as outside IT’s purview because the cloud gives business managers the laxity to “do their own thing” without the constraints imposed by the IT department, which has developed processes that not only take time but have a tangible cost to the company. This is dangerous since it removes cloud infrastructure from the controls that are required to ensure good governance. While the board of directors might not realize it, cloud represents a potential “wild frontier” of computing that can lead to significant trouble in the absence of governance.

So how can an IT operation assimilate the cloud without destroying its attractive qualities: agile, inexpensive, and powerful? Among the many issues that must be addressed are two main concerns: risk management and enterprise architecture.

Risk Management

A risk management approach is highly recommended for any company that seeks to migrate applications to the cloud. The selection of a cloud services provider (CSP) should include a risk assessment that will guide the process to select an appropriate supplier to provide the required cloud service. While many assessment tools are available, at minimum you should evaluate a service based on three categories of risks.

Organizational risks such as:

• Lock-in to a single provider
• Loss of governance over IT services
• Cloud service failure

Technical risks such as:

• Malicious insider activity
• Management interface compromise
• Denial of Service (DoS) attack

Legal risks such as:

• Data protection risks
• Licensing risks
• Changes of jurisdiction risks

Only when the risks are understood can they be managed and disaster averted.

Enterprise Architecture

From a strategy perspective, an organization’s enterprise architecture should address cloud services. Organizations that lack an enterprise architecture are paying too much for their IT infrastructure and should expedite the development of at least a technical architecture. This will mandate what operating systems should be supported, and which are deprecated. It should also indicate which type of configurations (patterns) are supported. This will reduce the management cost of the organization’s IT infrastructure.

Note: Locating a suitable consultant is not a trivial exercise. It seems many IT architecture consultants tend to make the development of an enterprise architecture overly complex. This is unfortunate because developing an enterprise architecture is not too difficult. There are basically four levels to be addressed by an organization’s IT architecture:

Business system’s architecture—how the IT infrastructure will support business unit applications. This includes planning the touchpoints between the applications and the identity management infrastructure. Process maps assist in this understanding.

Information architecture—indicates the information in the organization’s main data stores and how it maps to the requirements of the applications that the organization supports. Entity relationship diagrams are a useful tool.

Application portfolio—an inventory of the applications used in the organization, which indicates their operating system requirements, storage requirements, and support requirements. This will also include the development plans for each application, so that the enterprise architecture will be used to optimize upgrades —in an application that requires additional identity attributes, the collection and storage of these attributes needs to occur first.

Technical architecture—indicates the server infrastructure (and operating system versions), supported technical patterns (e.g., client/server, n-tier Web services), supported databases, and guidelines for deployed interfaces. Most organizations will maintain a Web services environment (browser client, Web server, application server, database server); some will have client/server applications, possibly with a standard operating environment deployment model; and some might also support a hub-and-spoke pattern for a mainframe app. The more patterns to support, the more the environment costs to operate and the more complex will be the identity management environment. A Web services environment will typically use a Security Assertion Markup Language (SAML) request to communicate identity attributes, client/server apps will often use LDAP, and a mainframe application will typically require identity attributes to be written to its accounts repository.

Interface Support

A cloud strategy must also address the interfaces to be supported.

As noted in chapter 3, LDAP is not a good solution for cloud apps. This is a good thing because it means that software developers do not need to learn the intricacies of optimizing LDAP filters; they can work with the Java-based, RESTful API interfaces that they prefer. But these services do represent a potential vulnerability for organizations. There are two basic approaches to the modern identity management task: use a Web service to connect to the data repository or use an API that supports the programming language of choice to integrate with the identity provider (IdP) service. The latter will generally provide better security and performance; the former requires less programming prowess.

Developer guidelines should be developed and documented to dictate what the various HTTP methods are allowed to do. If an API is developed, both API management and API security controls need to be determined and documented. Engaging a Web developer on the basis of lowest cost is generally unwise.

The protocols shown below (explained in more detail in Identity Management: A Business Perspective) will be required for most cloud-based identity management deployments.

• SAML support for requests and assertions
• RESTful API with support for JSON arrays and XML files
• OData native support
• OpenID Connect with OAuth token support
• The Fast ID On-line (FIDO) Alliance

Planning a cloud deployment requires the definition of the protocol support to be put in place so that cloud services comply with organizational security policy.