> > Is there enough support here for VIEWS to be the implementation strategy > for displaying masking functions?
I'm not sure that views should be "the" strategy for masking functions. We have multiple approaches here: 1) CQL functions only. Users can decide to use the masking functions on their own will. I think most dbs allow this pattern of usage, which is quite straightforward. Obviously, it doesn't allow admins to decide enforce users seeing only masked data. Nevertheless, it's still useful for trusted database users generating masked data that will be consumed by the end users of the application. 2) Masking functions attached to specific columns. This way the same queries will see different data (masked or not) depending on the permissions of the user running the query. It has the advantage of not requiring to change the queries that users with different permissions run. The downside is that users would need to query the schema if they need to know whether a column is masked, unless we change the names of the returned columns. This is the approach offered by Azure/SQL Server, PostgreSQL, IBM Db2, Oracle, MariaDB/MaxScale and SnowFlake. All these databases support applying the masking function to columns on the base table, and some of them also allow to apply masking to views. 3) Masking functions as part of projected views. This ways users might need to query the view appropriate for their permissions instead of the base table. This might mean changing the queries if the masking policy is changed by the admin. MySQL recommends this approach on a blog entry, although it's not part of its main documentation for data masking, and the implementation has security issues. Some of the other databases offering the approach 2) as their main option also support masking on view columns. Each approach has its own advantages and limitations, and I don't think we necessarily have to choose. The CEP proposes implementing 1) and 2), but no one impedes us to also have 3) if we get to have projected views. However, I think that projected views is a new general-purpose feature with its own complexities, so it would deserve its own CEP, if someone is willing to work on the implementation. On Wed, 31 Aug 2022 at 12:03, Claude Warren via dev < dev@cassandra.apache.org> wrote: > Is there enough support here for VIEWS to be the implementation strategy > for displaying masking functions? > > It seems to me the view would have to store the query and apply a where > clause to it, so the same PK would be in play. > > It has data leaking properties. > > It has more use cases as it can be used to > > - construct views that filter out sensitive columns > - apply transforms to convert units of measure > > Are there more thoughts along this line? >
