Pondering Security of Distributed Data

Mike Ferguson's been pondering data security across the slew of layers and applications in the enterprise. (content management, MDM, databases, networks, SANs, the list goes on)

To paraphrase, Mike essentially posed two excellent questions:

• Are the varying security policies able to be consistently managed across the organization, and
• Does data governance need to expand to include data security?

The Challenge

Layered technologies (databases, SANs, networks, etc) and distributed processing architectures (like SOA) makes the interaction points processes more granular -- potentially offering more points where we need to manage security.

SOA: Worth Considering a Security Service

Using SOA as an example at the application layer: Naive entrants to SOA development sometimes think only of business logic services. "Infrastructure" services such as security and logging can get pushed to the wayside. Or left to the individual service. Either is a mistake.

Gunnar Peterson argues in the SOA Magazine that one of the core services for any good SOA implementation is a security service. Nope, just using SSL encryption isn't enough. He points to the need for authentication, authorization, auditing, and assurance -- in a centralized approach. Check out his article for the details.

Data Integration: Similar Challenges

The data integration lifecycle (as described by Ed Tittel) exposes information to transfer and reprocessing at several points in the lifespan. SOA security concepts may apply here, particularly now that integration vendors are touting SOA capabilities.

I'm currently reviewing an organizational architecture with five distinct points of user login, and as many inter-application communication points, some of which are via web services. It's not just a matter of managing user security via a single signon. Cross-application boundaries need to be considered too.

Some suggest a "manage the outer boundaries" approach, in which we don't validate security between components once the user's authenticated. That's appropriate in some situations, but doesn't resolve the overall security consistency issue....

Regardless of Application Layer: Consistency Still a Problem

Even if you achieve the perfect world of consistent application security, there's still the risk of mismatch of security between technologies. The dba may set policies differently from the application, which may authorize differently from the Master Data Management system, and so forth.

Should Data Governance Include Data Security? Yes, Somewhat

At a minimum, the Data Governance group has to account for the flow of regulated data. They need to be able to assure that the data access policies were applied consistently. To that degree, data security is absolutely within their purview.

That said, accounting for something isn't the same as implementing it. If there's an infosec organization (or Chief Security Officer) the implementation responsibility lies there. Data Governance can and should influence the implementers' actions -- Governance contributes to overall policy, and they are within their rights to expect an accounting for its implementation.

At least that's my take on the issue. Since Mike started the discussion, please post any follow-up comments to his blog at Dataflux.