Remember when Larry Ellison poked Amazon about being a huge Oracle customer and Amazon proceeded on the journey to leave Oracle DB? It only took the world’s biggest cloud provider a few years to move off of Oracle. I say this to make the point; this stuff is hard! If it took the creator of Amazon Relational Database Service (RDS) several years to leave Oracle, it’s safe to say the rest of us will have Oracle in our environment for years to come.
That being said, technology marches forward. Today, I required a podcast with Martez Reed that we’ll publish over the coming weeks. So we went into some depth talking about where cloud abstraction and legacy IT meet.
One of my favorite examples is the security implications of running a serverless function such as Lambda against an on-premises Oracle DB. We’d have an application server in an application security zone segmented from the Oracle DB in the DB security zone in legacy design. We’d open a rule in the corporate firewall that allows SQL traffic between the two nodes. It was good enough security.
Today, there’s no concept of an “application” security zone when dealing with functions as a service. The functions are stateless. So, there’s no server to pin a firewall rule to.
So, how do you centrally enforce security policies between stateless cloud workloads and on-premises systems?
I’ll leave that open for discussion.
Use a VPC with tunnel/route back to corp DB, connect Lambda to VPC. AWS has fine grain controls and you can setup cloudtrail to log "all current and future" functions to ensure you log all Lambda operations. FW logs at corp side quite usable as source IP is static.