Moving Mainframe Workloads to AWS Changes the Security Equation
Cloud migration requires a different approach to identity and access management, as the potential for data exposure increases
Cloud migration requires a different approach to identity and access management, as the potential for data exposure increases.
Mainframe teams moving some or all of their workloads to AWS may be focused on determining which applications and data to transfer, but understanding the implications for the enterprise’s security architecture is just as important.
Securing cloud or hybrid environments requires more than transferring mainframe controls to AWS. It introduces new considerations around identity, access control, encryption, observability and governance, as the more connected cloud environment changes the potential attack surface.
As Herb Hogue, Chief Technology Officer (CTO) at Myriad360, tells TechChannel, teams may need to adapt to an unfamiliar security approach. “The finite ability to have control of the application and what’s being operated may be different than what they’re used to, because in an AWS construct, you’re probably depending on a Microsoft framework, or an Okta framework, or something else, and so that whole security construct is completely different than an encapsulated construct.”
While mainframe environments allow data, application identities and security controls to be relatively tightly encapsulated, data in an AWS architecture may move through APIs, cloud services, databases, applications, analytics platforms and AI services, as well as on-premises systems—distributing the security problem.
“When you move from a mainframe environment that is encapsulated to an open environment, that also generally means that the data is now traversing and interacting with other applications or processes,” Hogue notes. “And that opens up data sprawl issues, control issues, data subsets permeating across and around the organization or environment that they did not have to deal with prior, which I think is a very big security concern, and also encrypting that data in flight, depending on what type of data it is.”
As AI Agents Evolve, So Must Security
The challenge becomes greater still as enterprises introduce AI applications and autonomous agents that can access and act on data across previously separate environments.
“I would be remiss not to say also the portability of dealing with AI in an open environment is very different than in a mainframe environment,” Hogue says.
Microsoft Entra or Okta frameworks can provide baseline identity systems, but robust security still requires other enhanced products to ensure that agents operate safely.
Hogue cautions that AI agents are fundamentally different from the relatively stable technologies that IT teams are used to managing. “The other piece that I think is underestimated is in the technology space, we’re used to deploying a technology and it being consistent for a reasonable period of time. The agent space, in particular, is evolving daily,” Hogue says.
“The sophistication of the agents, the round robinning of agents, are all new dynamics that weren’t even thought about six months ago. … Though the fruit of that labor will be plentiful, the degree of safety and security to maintain it will be high.”
Hogue compares managing agentic security to maintaining an F1 car as opposed to a daily driver. “Everything is very sophisticated. You’re going to get optimal performance, but you have to maintain it depending on what your budgets will allow.”
Security needs to evolve with the operating model to become automated and repeatable, Jonathan LaCour, CTO at MissonCloud, tells TechChannel.
“You do not want security implemented in the way that we used to years ago, where it’s a human being clicking around an interface and setting configurations. That’s not how we do things now.”
Instead of manually configuring each environment, enterprises can establish standard security controls as code and apply them consistently across accounts and workloads.
“Using tools like infrastructure-as-code platforms to define things like security groups and access controls and IAM and everything, you want it to be repeatable and consistent, so you can lay a foundation and create … [a] standard AWS landing zone for workloads.”
Tiered AI Models to Require Careful Orchestration
Depending on the work developers are doing, it may be reasonable for them to use Apple Mac Minis to run AI large language models (LLMs) locally for testing and validation.
“That’s far less expensive and easier from an orchestration perspective than trying to figure out some large, elaborate workflow model. That will negate at least part of the challenge,” Hogue says. “You still need your service management deployment methods for when code graduates, and what you run against that from a security perspective to ensure that whatever you’re trying to protect from is valid.”
AI agents can add value at this pre-production stage, particularly for large organizations, as they can carry out faster and more sophisticated testing than legacy tools, improving outcomes from a security perspective, Hogue says. “The problem with more sophisticated is the cost per token and the return is getting out of control. So a lot of clients are having a tough time trying to manage and maintain that.”
And there is a trade-off as local models lag the performance of cloud-based LLMs, which may lead to the tiering of models for different workloads as “the next new norm,” Hogue says. These will need to be “gracefully orchestrated” rather than manually selected. “You still have the identity issue for agents, regardless, because you still have to have that enhanced agentic-centric security model,” Hogue adds.
Tools that provide enhanced observability and logging mechanisms to manage agentic AI are still at an early stage, and most are open source.
While established security products are available, “there’s not one tool that solves the whole ecosystem problem, so you’re looking at what is the best collection of tools to give you either your regulatory comfort or just be able to give you a reasonable sense that you’re protected, both from the inside as well as the outside,” Hogue says.
Identity Becomes a Bigger Architectural Question
Establishing clearly defined access control before deploying the first agent is crucial. Recent high-profile breaches and errors have highlighted the consequences of poorly controlled agent access.
“The other piece is managing the agents in a way that a user can’t activate an agent to acquire data that they may not be able to get themselves, but the agent could,” Hogue says, “which is a whole other dimension because we’re used to common rights management constructs for data. … Those don’t transfer easily in many cases, so you’re opening up a lot more data with the agents unknowingly.”
When enterprises start deploying agents outside the confines of a ChatGPT or Claude, the scope for authorized access changes, along with the potential for malicious attacks.
“What if a user just puts an agent on their machine because they want to? Well, now you have that potential activity,” Hogue says. “Not to mention if it was a nefarious method.”
The risks will continue to grow as so-called “shadow AI” proliferates.
“Deploying agents is getting easier by the minute, and they don’t have the same overhead constraints of an LLM, so they can run rather lightly without a user even knowing in many cases,” Hogue notes.
LaCour advises that enterprises “start from the first principle of ‘no’,” and grant access when needed rather than keeping permissions open on the assumption that they might be useful later.
“There’s a lot of blind spots. The principle of least privilege is something that is very helpful in those circumstances,” he says. “It tends to be a problem when people try to lock down specific things versus granting access to certain things. If you think about it as nobody gets anything until they ask, that’s a much better view.”
“Security people are really good at saying no, so you want them to do that in this circumstance,” LaCour adds.
It is important to understand how data storage services such as Amazon Simple Storage Service (Amazon S3) work on AWS, as “a very common vector of exfiltration is open S3 buckets,” LaCour says. “I always encourage people to use best practices and scan… making sure this isn’t a thing you do once.”
As part of its premium support, AWS offers Trusted Advisor, which continuously scans the environment for exposed bucket permissions, missing multi-factor authentication and other security gaps, while also helping to optimize AWS resources and performance.
Agentic AI is complicating security, and while enterprise leaders may be inclined to race ahead with deployments, Hogue cautions that they risk leaving vulnerabilities open to exploit by moving too fast:
“The ecosystem is getting more complex, not less, and my advice would be crawl, walk, run. And if you don’t understand the security elements, don’t deploy it, because you [soon] will understand, and it won’t probably end well for you after the fact.”
“Testing is key,” Hogue adds, “Because of the innovation cycles happening so fast, there aren’t readily available people on the street that have done it for five years. This is all six months old, so everybody’s going to take their smart guy and have them go figure it out, and hopefully they figured it out well enough.”