Put security first in cloud migration planning

Companies considering migration to a cloud environment usually focus first on infrastructure, from data centers to system performance to storage.

But even before you select a cloud environment, the fundamental issue to be considered must be security. Protecting that environment against inappropriate access is critical. And a deep understanding of all the vectors associated with the cyber kill chain is essential to ensure that any environment is protected. Clouds are inherently no more or less secure than any other environment, but with carefully crafted monitoring and vigilance, they can provide the highest level of security available.

It is not a surprise when customers that we work with choose Red Hat OpenShift as their cloud platform. It is built with a fundamental security model to ensure a secure environment. That environment includes continuous security across all aspects of the application deployment. Customers tell us that being able to control, defend, and extend their application platform’s security is one of the critical benefits they see with OpenShift.

Tied into this is the granular security provided by Nastel Navigator. Nastel Navigator offers self-service access to the middleware environments running IBM MQ, Tibco EMS, and Apache Kafka (and derivatives). Security is a fundamental aspect of providing self-service. If users are allowed to serve themselves, they have only to do what they are authorized to do. Access is critically important when crossing the various environments.

Even where just a single messaging middleware platform is in use, multiple versions spreading across different servers and even other platforms is a typical complexity issue, especially as we move to hybrid cloud. The nature of these messaging middleware systems typically demands that each server be individually connected to for configuration management purposes. And once you log in to a server, you can immediately access all of the individual queues, stream configurations, and data associated with that server. Since multiple business processes and teams may well use the same server, it is not appropriate to directly give the individual developers access to the server. Instead, the developer typically requests changes through a messaging middleware administration team (aka a shared services team). This request requires approvals and to model the changes in a test environment before delivering them into production. This arrangement enables the integrity of the entire environment to be guaranteed, but it adds complexity, time, and cost to the environment’s management. This heavy process impacts the time to market.

When a company spins up an OpenShift environment, Nastel Navigator gives each development team access to its entire messaging middleware environment across the whole application stack while maintaining privacy and security using access controls. Furthermore, it includes auditing all changes and attempted changes. It doesn’t matter what mix of cloud or on-premise architectures are in use or what middleware versions are running; it can all be managed from a single web browser pane of glass (SPOG) complete end-to-end business application view.

One login gives a user full access to just what they have rights to, and the administration team sets the rules. This setup means that users can manage their configurations and messages, delivering solutions quickly without impinging on anyone else. Simple, fast, and secure.

Try Nastel Navigator for free from the Red Hat Marketplace.

Originally published by Red Hat.