>
> One thought: The way the CEP is currently written, it is only possible to
> mask a column one way. You can only define one masking function for a
> column, and since you use the original column name, you could only return
> one version of it in the result set, even if you had a way to define
> several functions.
>

Right, it's one single type of mapping per the column, declared on
CREATE/ALTER TABLE statements. Also, users can manually specify their own
masking function in SELECT statements if they have permissions for seeing
the clear data.

For those cases where the data is automatically masked for an unprivileged
user, I don't see the use of including different types of masking for the
same column into the same result set. Instead, we might be interested on
having different types of masking associated to different roles. We could
do so with dedicated CREATE/DROP/LIST MASK statements, instead of using the
CREATE/ALTER/DESCRIBE TABLE statements. That CREATE MASK statement would
associate a masking function to a column and role. However, I'm not sure we
need that type of granularity instead of the simplicity of attaching the
masking to the column declaration. wdyt?


On Mon, 22 Aug 2022 at 19:31, Henrik Ingo <henrik.i...@datastax.com> wrote:

> One thought: The way the CEP is currently written, it is only possible to
> mask a column one way. You can only define one masking function for a
> column, and since you use the original column name, you could only return
> one version of it in the result set, even if you had a way to define
> several functions.
>
> I'm not proposing this should change, just calling it out.
>
> henrik
>
> On Fri, Aug 19, 2022 at 2:50 PM Andrés de la Peña <adelap...@apache.org>
> wrote:
>
>> Hi everyone,
>>
>> I'd like to start a discussion about this proposal for dynamic data
>> masking:
>> https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-20%3A+Dynamic+Data+Masking
>>
>> Dynamic data masking allows to obscure sensitive information without
>> changing the stored data. It would be based on a set of native CQL
>> functions providing different types of masking, such as replacing the
>> column value by "XXXX". These functions could be used as regular functions
>> or attached to table columns with CREATE/ALTER table. There would be a new
>> UNMASK permission, so only the users with this permissions would be able to
>> see the unmasked column values. It would be possible to customize masking
>> by using UDFs as masking functions.
>>
>> Thanks,
>>
>
>
> --
>
> Henrik Ingo
>
> +358 40 569 7354 <358405697354>
>
> [image: Visit us online.] <https://www.datastax.com/>  [image: Visit us
> on Twitter.] <https://twitter.com/DataStaxEng>  [image: Visit us on
> YouTube.]
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.youtube.com_channel_UCqA6zOSMpQ55vvguq4Y0jAg&d=DwMFaQ&c=adz96Xi0w1RHqtPMowiL2g&r=IFj3MdIKYLLXIUhYdUGB0cTzTlxyCb7_VUmICBaYilU&m=bmIfaie9O3fWJAu6lESvWj3HajV4VFwgwgVuKmxKZmE&s=16sY48_kvIb7sRQORknZrr3V8iLTfemFKbMVNZhdwgw&e=>
>   [image: Visit my LinkedIn profile.]
> <https://www.linkedin.com/in/heingo/>
>

Reply via email to