Build, protect and deploy apps across any platform and mobile device
Leverage a complete UI toolbox for web, mobile and desktop development
Automate UI, load and performance testing for web, desktop and mobile
Rapidly develop, manage and deploy business apps, delivered as SaaS in the cloud
Build mobile apps for iOS, Android and Windows Phone
Optimize data integration with high-performance connectivity
Connect to any cloud or on-premise data source using a standard interface
Build engaging multi-channel web and digital experiences with intuitive web content management
Automate decision processes with a no-code business rules engine
Ran across this article on data center security today, and noticed some parallels between the way they’re thinking about physical security, and I think about SOA security (and governance).
A key SOA governance challenge is making sure that things in runtime are compliant with all CURRENT governance policies and procedures.
Why is that such a trick? Well... because most companies implement “armadillo governance.” (I copied this phrase from Mitch in the comments of the post referenced above.)
That is, most companies have governance that is hard on the outside and soft on the inside. Mitch says, “The most carefully maintained $100,000 firewall does no good if someone can simply move a ceiling tile and gain complete and unfettered access...” Amen.
Well, the most carefully implemented developer time governance pre-production testing does nothing to ensure compliance in run-time.
Let me share a couple of real-world examples.
I was working with a semiconductor company on a pilot governance project. They had strict tests for their applications before moving them into production. The tests passed... the application was moved to production but development systems were still able to access this “in production” application.
The problem was, the company tested at the border (they had a hard outside), but once inside production they had no idea what was really happening (they had a soft inside).
In that example, it turned out there were holes in a firewall that shouldn’t have been. So, the failure wasn't at the application level. But... how about this one? An application was successfully in production and the governance rules changed. All new applications tested fine before they were moved into production,and the customer thought they were OK in all the existing production applications. Unfortunately, that wasn’t the case. As it turns out, there was an old server being used by some customers and everything was chugging along OK because it never broke, so no one ever complained. In time, developers moved to other projects, and the application was lost in the shuffle.
Now, before you say “we don't lose stuff here”... early in my career, while working at Box Hill Systems and going in to replace a failed hard drive at a big financial firm, I had to wait on-site about 4 hours for them to find the machine that failed. They knew it failed because they couldn’t access it, but they didn't know where the machine was. They lost a server, the hard drive and all. Now, we're talking about services, software, bits in the ether. Much easier to lose... and there are a lot more of them than there are servers!
Border security is important but please don't design your SOA like an Armadillo. It's a design that works for Armadillo’s but not so much for SOA infrastructure or for data centers.
Interestingly, Dan's discussed why "checkpoint governance isn't good for design time" either. So it seems that like lemmings, deployment managers can't help but heed the call of their profession, though it is of limited value (on it's own -- I think it has value when part of a bigger governance plan) when deploying services as part of an SOA for either developers or operators.
View all posts from david bressler on the Progress blog. Connect with us about all things application development and deployment, data integration and digital business.
Copyright © 2017, Progress Software Corporation and/or its subsidiaries or affiliates.
All Rights Reserved.
Progress, Telerik, and certain product names used herein are trademarks or registered trademarks of Progress Software Corporation and/or one of its subsidiaries or affiliates in the U.S. and/or other countries. See Trademarks or appropriate markings.