How can we help you today? How can we help you today?
PlantBasedSQL
Hi @ben_b thank you for your message - glad to hear the Webinar was helpful! Typically we see the 2 main use cases for SQL Data Catalog being 1) The masking of lower environments as you stated and 2) Informing other business decisions about data. This could be anything from putting auditors minds to rest that we know where all of our sensitive data is to deciding whether or not to give people access to certain systems - it could also be useful in some kind of impact assessment if we were to evaluate our readiness for data breaches and our response times. I've also heard of companies both using this to a) Catch new columns/Tables that are added by developers and ensure they stay on top of the classification workflow and b) Use it for reporting purposes to data governance teams i.e. who owns the data, where is it being used etc. I guess the point is that whilst the initial Cataloging requirement can be satisfied, it's actually the ongoing consumption of that Catalog that drives the real value! As for the differentiation between Confidential and Confidential GDPR, this is primarily the Microsoft specific sensitivity labels that come out of the box with SQL Server 2016+, but like I mentioned in the webinar, with Data Catalog these can be extended to reflect your own business-agreed taxonomy so someone could use "Confidential - POPI" if they're in South Africa, or can add their own Categories and tags like "Treatment Intent" or "Retention Period", but the point is it really has to be agreed up front so that everyone is tackling the classification from the same angle. We actually package up an example taxonomy out of the box with Data Catalog, which represents an amalgamation of categories and tags that we have seen many of our Early Access Users adopt into their own taxonomies. I hope some of this information helps? Let me know if you have any additional questions! Thank you very much! Chris / comments
Hi @ben_b thank you for your message - glad to hear the Webinar was helpful!Typically we see the 2 main use cases for SQL Data Catalog being 1) The masking of lower environments as you stated and 2...
0 votes
Hi @rob_wingate - long time no speak - I hope you're well! What you're describing is deterministic masking. The first thing I would ask before describing this is why you would need to have the names be masked to the same value every time? Is there an intended workflow for this? The reason I ask is that implementing this functionality requires a bit of perseverance as the tool was not intended to handle this initially.  If it is a workflow you must have to ensure you have viable Images and Clones every time then you have 2 options (as far as I know): Pre-Requisite for both approaches: Have a database on the staging server you're using for the imaging process, to which you can add a mapping table (i went for dbo.MaskingMapper) this table can be something like: ID int, MFName nvarchar(100), MLName nvarchar(50) -- With a primary key on ID. Options: 1) Restore the Database to your staging server first, in your masking set you will need a second rule controller that links to the MaskingMapper DB. As part of the process: - Mask all of the names in the DB - Use a Table-To-Table Sync Rule to copy across values that may already be present in the mapping table - Write a command rule to insert distinct IDs, and the now masked first and last names into the mapping table This process then will run each time adding new masked values to the table and copying across the ones that already existed - but you will need to call data masker via the command line after the restore THEN kick off the imaging process from your now live masked DB, and then afterwards you can drop the temporary copy.  2) If you want to ensure this process runs as part of the image creation process and you don't want to restore the DB then you will just need to use Command rules instead of the Table-to-Table Sync Rule.  The command rules would, after you've masked the names, then go off and Update the table based on what is in MaskingMapper and then write any new values to MaskingMapper. Because this mapping table is on the staging server but not included as part of the backing up / restore or Imaging process it will always be preserved, and because the table is ID and then any masked fields, you're never storing additional sensitive data (unless the ID is in itself sensitive, in which case this process won't work and I'd have to have a think about how you could adapt it to work!) Does that make sense? Let me know if you need any clarification! Thank you very much :-) / comments
Hi @rob_wingate - long time no speak - I hope you're well!What you're describing is deterministic masking.The first thing I would ask before describing this is why you would need to have the names ...
0 votes
Hi @arungk Thank you for that - yes that is the correct email address - I look forward to receiving your masking set. / comments
Hi @arungk Thank you for that - yes that is the correct email address - I look forward to receiving your masking set.
0 votes