Discussion on cloud Security in application lifecycle management

Application Lifecycle Management (ALM) will still be a challenge when an application is a unit of huge software running on a single server, because of the need to maintain business operations at the level of the entire software change. With the combination of cloud computing and resilient resources on the employee side, multi-vendor integration, modularity, and choreography, the challenges are magnified. The area where the magnification is very serious is the security field. Like other requirements in application deployment, cloud security needs should be reflected in ALM, not by luck.

In ALM, applications run through the entire iteration cycle of development/modification, testing, rollout, deployment, production/operations, versioning, and then from the beginning. In traditional static data center deployments, security processes are often used in environments such as data centers, networks, where applications are deployed, tested, and are more like deployments of operations than the application itself. The periodic ALM process runs under a consistent security umbrella. Unfortunately, this approach does not work for cloud steps.

In a cloud deployment, applications are increasingly deployed in virtual subnets that are managed to shut down virtual machines or SaaS component elements. These are then accessed via a gateway connected to the WAN on the application subnet. All of these virtualization masks the fact that every application structure is a new infrastructure for security purposes. Only as a virtual LAN, without any gateway, is not able to support user connections, there is no specific security features on that network LAN is also unsafe. This forces the user to reverse the environmental issue of security management to an application problem, which is the shift to the ALM problem.

A starting point based on ALM security must be a virtual network model, such as a real infrastructure, that can be protected. Both the public cloud, the private cloud, and the SaaS model for all cloud services should also be assumed to be compatible, assuming that a given application component is hosted on a virtual LAN and accessible via a gateway on the IP address set. This model provides a network connectivity framework that allows your LAN to be protected in the data center, which means that firewalls, access control, and so on, can follow the standard datacenter model that ALM professionals are likely to have already used in internal it. The model will have to adapt to the cloud in the future, and it must involve the entire ALM process, from development/modification to versioning and initiating a new cycle of change.

Changes to cloud security practices now relate to the virtual network model of managed applications and the differences between the real-world network models used for data center applications. If the application's virtual network is only useful for controlled VPNs, this means that security does not improve compared to traditional VPN access applications. If the application of virtual networks is accessible through the Internet and Internet VPN, then the gateway to the application is addressable on the internet and is targeted by hackers or DDoS attacks. This is often mitigated by an ISP or application listening to VLAN gateways, but either way, the activation security process must be clear (through the contract or by selecting and setting the correct mesh). These steps will have to be added to the ALM process list in the future, not just for production deployments, but also for all stages before the application is exposed.

The problem with ALM is that the version diversity and application can operate at a given point. A given software is likely to exist in at least two operating states (production and testing), it may also be 5 or more states, depending on the complexity of the software modification process and the number of tests, and the number of pre-production phases associated with migrating an application in full production. While it is important to test security and application functionality for each test phase, it is equally important that the security process be significantly different from all other versions of the set of controlled resources. Just having a security umbrella to protect all software ALM phases, or testing contaminated production using existing risks, is unsatisfactory.

In fact, the safest path to protect an application's multiple states or multiple versions in ALM is assume that each ALM state or version (for example, production and testing) has its own virtual network, and that the same toolset and operating procedures do not protect each virtual network, each has its own iterative tools and processes.

These must be mutually protective and independent, just as the real version of the software remains independent, as is the case. Mixed security processes can Ching impact production application security, or allow users to access test systems when they are confident that they are using the resulting version of the refresher. Most importantly, for the cloud, security must be an element of ALM, because virtual resource security cannot be simply managed or secured, but only through traditional networks and it processes related to fixed resources and devices.

Security is not the only Toolset and practice, it has to move from a whole infrastructure to an application focused, moving from fixed escrow to a cloud application, but it is probably the first and most important. Assuming cloud security is a major technical barrier to migrating applications to the cloud, it is reasonable to assume that the inability to adapt to the new security model in ALM could slow down cloud applications and reduce overall benefits.