There has been a policy in integration that has stored up a really great challenge of data security, and by great I don't mean 'fantastic' I mean 'aw crap'. Its a policy that was done for the best of reasons and one that really will in future represent a growing challenge to Big Data and federated information.
The policy can be described as this:
This approach has tended to work for operational systems however because they work in linear ways on data sets, you know what you are showing and you pull out what you want to show. The trouble is as these federated sets are then shifted into next generation Big Data solutions or accessed in a federated query is that the security model completely breaks down because application to application security doesn't recognise the individual actually making the request.
So now we have a world where the data sources don't do data security and privacy 'by design' they do it 'by functionality'. So the reason you get your account information is because of that magic ID, but there is nothing stopping a piece of code saying 'return account information from account ID, account ID +1 and account ID +3. Its just practice that stops that rather than a fundamental information security approach.
There are mechanisms that can help with this but historically they've been more pain than its worth. Its going to be interesting seeing how the next generation of joined up analytics and operational IT estates will retrofit user and role level analytical security into a world of application to application authentication.
The policy can be described as this:
Users authenticate with Apps, Apps authenticate with the database and Apps authenticate with the ESB/EAI/IntegrationWhat this means is that Users don't authenticate against any of the federated data. This is normally glossed over by saying that 'the source application is responsible for filtering' but the reality is that applications rarely do this terribly well. Put it this way, most of the time when a front end banking system accessing your account information the only reason its getting your account data is because of the account ID it has, if it for some reason had the wrong account ID stored then it would display something else even though that information isn't yours.
This approach has tended to work for operational systems however because they work in linear ways on data sets, you know what you are showing and you pull out what you want to show. The trouble is as these federated sets are then shifted into next generation Big Data solutions or accessed in a federated query is that the security model completely breaks down because application to application security doesn't recognise the individual actually making the request.
So now we have a world where the data sources don't do data security and privacy 'by design' they do it 'by functionality'. So the reason you get your account information is because of that magic ID, but there is nothing stopping a piece of code saying 'return account information from account ID, account ID +1 and account ID +3. Its just practice that stops that rather than a fundamental information security approach.
There are mechanisms that can help with this but historically they've been more pain than its worth. Its going to be interesting seeing how the next generation of joined up analytics and operational IT estates will retrofit user and role level analytical security into a world of application to application authentication.
No comments:
Post a Comment