January 18, 2011 at 6:06 pm
I don't see these as holes in SSIS, but more potential holes in process using SSIS.
January 19, 2011 at 5:48 am
Craig Farrell (1/18/2011)
Your department head and data integrity are miles above the average company I've worked in. That includes financial firms and healthcare providers. No I won't mention names.
We're a publicly traded company providing healthcare management applications for employees of some of the largest corporations and insurance providers in the US, so HIPAA and SOX are mandated by the government. I'm no big fan of government regulation in general, but when it comes to how corporations respect our financial, healthcare, and other personal information, I'm glad to know we have some standardized guidelines and there are people looking over our shoulder.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
January 19, 2011 at 6:01 am
Steve Jones - SSC Editor (1/18/2011)
I don't see these as holes in SSIS, but more potential holes in process using SSIS.
Right, a SSIS package is just an XML document, so it's function is transparent. You don't have to depend on a developer to tell you what the ETL process is doing, anyone with access to the .dtsx package file can open it up in Visual Studio and look for themselves.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
January 19, 2011 at 10:03 am
This definitely isn't a hole in SSIS, any more than SQL injection attacks are a hole in SQL.
The difference between report security and ETL security, is that a report does just one thing, which is query and present data. Securing one can be relatively simple.
An ETL tool, on the other hand, often needs things like data access AND file system access. It's lazy, but common, to use sysadmin privileges in the job running the ETL package, so that it has the file access needed to do things like create, fill and move text files, and e-mail or FTP large files. Doing so, however, may expose data that has more granular security under normal circumstances, but is now being queried by an account that has, by default, full access to all data.
Again, that's not a problem with the ETL tool, it's a problem with the use of it. But it is something to pay attention to, and that, I think, was the point of the original editorial.
Security is always about alertness, and ability to anticipate consequences. This is just one of the factors to take into account in both of those things.
- Gus "GSquared", RSVP, OODA, MAP, NMVP, FAQ, SAT, SQL, DNA, RNA, UOI, IOU, AM, PM, AD, BC, BCE, USA, UN, CF, ROFL, LOL, ETC
Property of The Thread
"Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon
March 21, 2011 at 4:11 am
The data warehouse created from the ETL tool can be used for decision making and thus the security measures should be provided during these processes of extraction transformation and loading.
we can discuss on how this security can be provided during each of the process of ETL and develop a secure Data warehouse.
Conventional ETL does not address any security feature. so we can think on this aspect
Viewing 5 posts - 16 through 19 (of 19 total)
You must be logged in to reply to this topic. Login to reply