

As this Thesis derive from work done within a collaboration with a company; we had to create a deliverable requested by the client.
In this chapter, I am going to work you through the project implementation from the beginning to the end.
I will explain what was the client's request in more details and how we executed it.

\section{The client's requirements}

The client's objective was to implement a type of data protection through dynamic data masking with specific operating logic.

The user observing the database had to access in 2 different modalities; RBAC and ABAC.

\subsection{Role Based Access Control}

Role-based access control (RBAC) is a system that manages access based on the roles assigned to users.
It grants permissions and access rights to users based on their roles within an organization.

In most organizations, access to sensitive data is allocated according to the varying roles and responsibilities of employees through RBAC.
This method ensures that only staff members holding specific roles are authorized to view or modify certain pieces of information.

Access rights for each employee are defined by their respective roles, determining the level of permissions they have within the system. 
For instance, access can be tailored so that only managers, testers, or basic users can interact with particular resources or perform certain operations, depending on their role \cite{RBAC_Explained}.

\subsection{Attribute Based Access Control (ABAC)}

Unlike RBAC, which grants access based on user roles, ABAC (Attribute-Based Access Control) relies on the user's attributes to determine their access rights to resources. 
The characteristics of the user requesting access are critical in making this decision.

ABAC provides a more granular level of access control, focusing on detailed attributes rather than broad roles, thus offering a deeper and more nuanced approach to managing access \cite{ABAC_Explained}.


\subsubsection{How does ABAC work}

In order to allow access , ABAC checks the requester's attributes. These attributes can be subdivided into four main parts:

\begin{itemize}
\item \textbf{Subject/user}: attributes defines the user making an access request. Examples include name, codice fiscale, job title, the user's role, organization the requester work for, department he is assigned to and his security clearance.
\item \textbf{Resources/object}: attributes are the description of the resources being accessed.
\item \textbf{Action}: is the type of activity the user will do to the resource requested. Examples include Read, Write, Update, delete, etc.
\item \textbf{Environmental}: attributes describe the conditions when the user attempts to access the resource. Examples include time and location, device used, etc.
\end{itemize}
An ABAC system checks the environment attributes and rules are developed that will clarify what attributes to be met in order to allow access a user \cite{ABAC_IN_DETAILS}. 

In summary, an ABAC system creates policies and rules to design a combination of different attributes(subject, environmental,user). These attributes are needed to perform an action to a resource. Grant and deny accesses are provided by those policies created.

For example, if you do not want the bank employees to view all the data, ABAC can place limitations so only employees of the bank in Turin  can view sensitive information.

\noindent \textbf{Here is how it works:}

When an access request is generated, attributes are checked by the ABAC tool to see if they match established policies. If they match, the user will have access to a resource. In our case, it would be bank employees who works Turin, and who is trying to view sensitive information.

Figure \ref{fig:project description} shows in details how in our project we implemented the ABAC system for better granularity and a high level of control.



\begin{figure}[!h]% per piazzare la tabella t:top b:bottom h:here, in ordine di preferenza; h è sconsigliato
\centerline{\includegraphics[width=0.9\textwidth]{projArch2.png}}
\caption{Project Architecture \label{fig:project description}}
\end{figure}



\section{User Attributes}

In the course of our project, ensuring and enforcing security protocols required pinpointing the locations of user attributes/information. 
The client relied on two distinct data sources to gather this information.

\subsection{Active directory}

it is a logical grouping of users and assets within a domain. For each user, his detailed information is recorded, including:
\begin{itemize}
    \item User Memberships
    \item Name, Surname
    \item Email
    \item Other context information (account expiration date, account creation date, etc.)
\end{itemize}

\subsection{Secure database}

This database is the other data source which contains part of the user's attributes as well as the mapping between the acronym and related enabling groups.

In this database we get all the necessary information used by policies implementing rules as a gauge.

Some of the information retrieved are:
\begin{enumerate}
    \item \textbf{User role}: This is the type of user trying to connect.
    \item \textbf{Legal Entity}: This is self explanatory as it is the legal entity the user is affiliated to.
\end{enumerate}

Both of these information are highly important in the implementation of the legal entity policy. This will be further explained in later chapters.

\section{Policies}

\noindent Based on the user's attributes, the Dynamic Data Masking solution authorizes the user to view the data, otherwise it applies the masking policies.

\noindent We are going to take a look at those masking policies in details as they are the pivotal point we base this whole project on.

\noindent Policies are access and visibility rules that are implemented by a tool on the data.

\noindent They are subdivided into 5 categories and below we are going to explain each category in detail.

Those categories are:
\begin{itemize}
    \item ACL POLICY
    \item GDPR POLICY
    \item LEGAL ENTITY POLICY
    \item RESERVED POLICY
    \item PROFILED POLICY
\end{itemize}


\subsection{ACL POLICY}

The objective of the Access Control list policy(ACL) is to provide access to data based on the user's 
attributes, in this case guaranteeing access only if in possession of the ACL enabling code associated with the queried acronym(database).
This policy inhibits users who access any database they don't have permissions to.

\noindent \begin{figure}[!ht]% per piazzare la tabella t:top b:bottom h:here, in ordine di preferenza; h è sconsigliato
\centerline{\includegraphics[width=0.9\textwidth]{withACL.png}}
\caption{User with ACL codes \label{fig:UserACL}}
\end{figure}



Figure \ref{fig:UserACL} shows that when users have an ACL code for the database, they can access them.

\noindent \begin{figure}[!ht]% per piazzare la tabella t:top b:bottom h:here, in ordine di preferenza; h è sconsigliato
\centerline{\includegraphics[width=0.9\textwidth]{withoutACL.png}}
\caption{User without ACL codes \label{fig:UserNOACL}}
\end{figure}


Figure \ref{fig:UserNOACL} on the contrary shows how a user with no ACL code has no possibility to access data in hive servers.

In the implementation of the ACL policy, each acronym has to be defined with its appropriate ACL groups.
Users found in those groups are the ones allowed to access that acronym.
By default, the masking tool blocks all users not belonging to the indicated groups who try to access the resource.

\subsubsection{ACL FLOW}


\noindent \begin{figure}[!ht]% per piazzare la tabella t:top b:bottom h:here, in ordine di preferenza; h è sconsigliato
\centerline{\includegraphics[width=0.9\textwidth]{ACLFLOW.png}}
\caption{Flow of the ACL implementation \label{fig:ACLFLUSSO}}
\end{figure}

In Figure \ref{fig:ACLFLUSSO} is presented the ACL flow implemented, which consists in the following actions:
\begin{enumerate}
    \item  The masking tool verifies if it exists an ACL policy associated to the acronym (DB) that the user is requesting.
    \item  The masking tool by default applies a Deny access if there is no ACL policy associated to the requested resource.
    \item  The tool finds the ACL policy and guarantees that the access is through ACL groups.
    \item  The tool checks if the user connected belongs to at least one of those ACL groups. (These groups are part of the user Attributes and can be found on the Access Directory.)
    \item  The tool gives access of that acronym(DB) to that user if the previous check was a success otherwise the user is denied.
    
\end{enumerate}

\subsection{GDPR POLICY}

The objective of the GDPR policy is to provide protection of data intended as personal, Indicated by the client, based on the user's attributes.
In this case, guarantee the visibility of personal data only to those in possession of the GDPR enabling code associated with the acronym in question.

\begin{figure}[!ht]
    \centering
    \includegraphics[width=0.9\textwidth]{noGdprArch.png}
    \caption{unauthorized user to view the data}
    \label{fig:GDPR_image}
\end{figure}



\begin{figure}[!ht]
    \centering
    \includegraphics[width=0.9\textwidth]{gdprArch.png}
    \caption{authorized user to view the data}
    \label{fig:GDPR_with_code}
\end{figure}

Figures \ref{fig:GDPR_image} and \ref{fig:GDPR_with_code} shows the 2 different users one with gdpr code who accesses the database in clear and the other one without the code who only sees sensitive data masked.

\subsubsection{GDPR FLOW}

Ranger, our masking tool allows you to develop two types of policies: resource based and tag based.
Resource Based Policies are applied to resources that are specified in the policy itself (DB/table/column). 

Tag Based Policies are applied using, as the name suggests, a tag. The tag allows you to control multiple resources with a single policy.

Ranger allows you to implement a single masking policy for each acronym, but having the need to implement masking on multiple columns of multiple tables within the same acronym, this could not be done with a normal resource based policy.

To deal with this problem, the GDPR policy is developed following the tag based policy method and is defined as follows:
\newpage

\begin{figure}[!ht]
    \centering
    \includegraphics[width=0.9\textwidth]{gdprFlowNew.png}
    \caption{Implemented GDPR Flow}
    \label{fig:GDPR_flow}
\end{figure}

In Figure \ref{fig:GDPR_flow} is presented the GPDR flow implemented, which is composed of the following actions:
\begin{enumerate}
    \item The masking tool checks if there are any policies (Tag based) associated with the table that the user is querying.
    \item The tool does not find policy tags associated with the queried tables and allows clear access on all columns.
    \item The masking tool finds a masking policy associated with the requested table and runs the rules:
     \begin{enumerate}
        \item  Grants clear visibility to users who belong to the following group: GDPR.
        \item Mask all other users.
    \end{enumerate}
    \item  The tool checks if the user belongs to the GDPR group, if not, the rule described in 3.b is applied, while, if so, the rule 3.a is applied.
\end{enumerate}

With GDPR, we have labels to protect, each of which identifies a type of data. The security product will have to protect these types of data with a masking logic. Some of the labels are as follows:

\begin{enumerate}
    \item GDPR\_DATO PARTICOLARE: This includes
        \begin{itemize}
            \item BIOMETRICAL DATA: e.g., image shape, iris image...
        \end{itemize}
    \item GDPR\_DATO ANAGRAFICO: This includes
        \begin{itemize}
            \item NAME AND SURNAME e.g., John Smith,...
            \item EMAIL e.g., mario@tirocinio.com
            \item CODICE FISCALE e.g., QWEDFV76L45W480B
            \item HOME ADDRESS e.g., via Verdi, 5
            \item DATE OF BIRTH e.g., 05/03/1934
        \end{itemize}
    \item GDPR\_DATO BANCARIO E OPERATIVO: This include
        \begin{itemize}
            \item IP ADDRESS e.g., 138.147.34.217
        \end{itemize}
\end{enumerate}


\subsubsection{TYPE OF MASKING}

The type of masking done a value depends on what is the type of that data before being masked.
We have two different ways of masking. 

\begin{itemize}
    \item \textbf{String masking}: string masking is used every time we try to mask a string value. At that point the mask is \textbf{XXXX}.
    \item \textbf{Date masking}: date masking is used every time we try to mask a date value. At that point a data changes from \textbf{Day/Month/Year} to \textbf{**/**/YEAR} in which YEAR is the original value of the date.
\end{itemize}

\subsection{LEGAL ENTITY POLICY}

In the context of the definition of access control policies to the data present in the acronyms.
The policies for the Legal Entities aim to define and implement the cones of visibility, limiting the visible information only to the data users based on the legal entity to which they belong and the user role they possess, in line with the principle of least privilege.

We have 2 scenarios in our legal entity policy, the first one is of a user with role A who has only visibility to data of the legal entity he belongs.
The other scenario is a user with role B who has an entire visibility of the data independently of the legal entity.

\begin{figure}[!ht]
    \centering
    \includegraphics[width=12cm]{LE_end.jpg}
    \caption{user with Role A and visibility only on Torino Legal entity}
    \label{fig:LE_end}
\end{figure}


\begin{figure}[!ht]
    \centering
    \includegraphics[width=12cm]{LE_begin.jpg}
    \caption{User with Role B and authorized to view all the data}
    \label{fig:LE_begin}
\end{figure}

\newpage


Figures \ref{fig:LE_end} and \ref{fig:LE_begin} above show how a user when connecting to hive servers receives the information. Other users of a different legal entity will see their data accordingly.

\subsubsection{LEGAL ENTITY FLOW}


\begin{figure}[!ht]
    \centering
    \includegraphics[width=12cm]{LEflow.png}
    \caption{Legal Entity flow graph}
    \label{fig:LE_flow}
\end{figure}

In Figure \ref{fig:LE_flow} is present the Legal Entity flow implemented, which consists of the following actions:
\begin{enumerate}
    \item  The masking tool verifies if it exists a LE policy associated to the acronym (DB) that the user is requesting.
    \item  The masking tool by default applies a least visibility access if there is no LE policy associated to the requested resource.
    \item  The tool finds the LE policy and guarantees that the access is through user Role and Legal Entity.
    \item  The tool checks if the user connected has User Role ``A" and Legal Entity (the User Role and Legal entity are user Attributes  and can be found on the secure database). 
    \item  The tool gives partial visibility of acronym(DB) to that user if the previous check was a success otherwise the user has full visibility.
    
\end{enumerate}


\subsection{RESERVED POLICY}

The objective of the Reserved policy is to provide protection of data intended as Confidential, Indicated by the client, based on the user's attributes.
In this case, we guarantee the visibility of personal data only to those in possession of the Private Data enabling code associated with the acronym queried.


\begin{figure}[!ht]
    \centering
    \includegraphics[width=12cm]{Reserved_WithOUT_Code.jpg}
    \caption{Reserved Policy with a user without a Code}
    \label{fig:reserved_without_code}
\end{figure}

\begin{figure}[!ht]
    \centering
    \includegraphics[width=12cm]{Reserved_With_Code.jpg}
    \caption{Reserved Policy with a user with a code}
    \label{fig:reserved_with_code}
\end{figure}

Figure \ref{fig:reserved_without_code} and \ref{fig:reserved_with_code} presents the reserved policy in different case where a user does not have abilitating code on the first image hence could not access the table, on the contrary, the latter image shows a user with the code that allows him full access to the database.

The reserved policy is like the acl policies but instead done on the table instead of the whole database.

\subsubsection{Reserved Data flow Graph}

\begin{figure}[!ht]
    \centering
    \includegraphics[width=12cm]{reservedGroup.png}
    \caption{Reserved Policy control flow}
    \label{fig:reserved_controlflow}
\end{figure}

In Figure \ref{fig:reserved_controlflow} is presented the implemented reserverd policy control flow, which is composed of the following actions:
\begin{enumerate}
    \item Ranger(Our dynamic data masking) checks if there are any policies (tag based) associated with the DB that the user is querying;
    \item Ranger allows access if there is no Confidential Data policy associated with the requested resource;
    \item Ranger finds an access policy associated with the requested resource and grants access to Confidential Data (DR) or Emergency groups
    \item Ranger checks if the user belongs to one of the groups associated with the resource access policy
\end{enumerate}

\subsection{PROFILED POLICY}

The Profiled Data policy is a Custom policy that reflects the client's need to protect the data of its acronyms based on the values contained in the tables and on the memberships associated with the user's profile.


\newpage

\begin{figure}[!ht]
    \centering
    \includegraphics[width=13cm]{profiledPolicyNew.png}
    \caption{Profiled Policy}
    \label{fig:profilati}
\end{figure}

Figure \ref{fig:profilati} presents a filtering case where it depends on the value in the table, in our example we filtered depending on the user having a value F1 in a column.

The Profiled Data policy is divided into two different types of policies:
\begin{itemize}
    \item Consent Policy
    \item Policy legal nature
\end{itemize}

\subsubsection{Consent Policy work flow}

\begin{figure}[!ht]
    \centering
    \includegraphics[width=0.9\textwidth]{consenso.png}
    \caption{Implemented Consent Profiled Policy}
    \label{fig:profilato_workflow_consenso}
\end{figure}
Figure \ref{fig:profilato_workflow_consenso} presents the implemented consent profiled policy, which consists in the following actions:
\begin{enumerate}
    \item The data masking tool (Ranger) checks if there are any policies (resource based) associated with the DB that the user is querying;
    \item The tool allows access if there is no Profiled Data policy associated with the requested resource;
    \item Ranger finds an access policy associated with the requested resource and checks if two filtering rules
        \begin{enumerate}
            \item If the value ``X" value contained in the ``A" table is equal to ``M" or ``N" it grants access to the resource
            \item  If the value ``X" value contained in the ``A" table is equal to ``J" or ``P" it denies access to the resource
        \end{enumerate}
    \item If the value ``X" value contained in the ``A" table is equal to ``M" or ``N" it allows access to the resource, otherwise it denies it
\end{enumerate}

\subsubsection{Policy legal nature work flow}
\begin{figure}[!ht]
    \centering
    \includegraphics[width=12cm]{giuridica.png}
    \caption{Legal Nature Policy Workflow}
    \label{fig:giuridic_flowDiagram}
\end{figure}

The legal nature policy on Ranger is developed following the Resource Based Policy method. Figure \ref{fig:giuridic_flowDiagram} presents the implemented policy, which is defined as follows:
\begin{enumerate}
    \item The user queries our database;
    \item Ranger allows access if there is no Profiled Data policy associated with the requested resource;
    \item Ranger finds a Profiled Data policy associated with the requested resource and checks which rule to apply:
        \begin{enumerate}
            \item The user belongs to both group H and group F
            \item The user belongs to Group F
            \item The user belongs to Group H
            \item None of the above rules apply
        \end{enumerate}
    \item If the user belongs to both group F and group H, he has access to the resource
    \item If the user belongs to Group F, he has access to the lines where X = 'H'
    \item If the user belongs to Group H, he has access to the lines where X = 'F'
    \item If none of the previous rules are applied, access is denied and ranger checks if there are any policies (resource based) associated with the DB
    
\end{enumerate}

\section{How Were the Policies Implemented}

The question anyone would ask himself at this point would be, how is it possible to keep up with the policies creation and not be overwhelmed or confused when creating them?

\noindent The simple answer to that question is that it would be very difficult to create the policies manually.

\noindent  We developed a tool that were connecting to ranger APIs and through a series of configuration files and properties file, create those policies for each acronyms/database.

\noindent There was also a need to create another plugin called the Hook along the development of the Legal entity policies.

\noindent This was due to the fact that our legal entity was to be customized to take the values of the user to be filtered from the database.



\chapter{Thesis conclusion and future work}

%This thesis has explored the critical realm of data protection in an era where digital information's value and vulnerability are both at their peak.Through a comprehensive examination of data breaches, the impact they wield, and the subsequent legal frameworks developed to mitigate these risks, we've delved into the intricacies of safeguarding sensitive data.A focal point of our investigation was the deployment of data masking tools as a robust defense mechanism against unauthorized access, with a detailed comparison of various tools on the market such as Delphix, K2View, Informatica, Immuta, and Apache Ranger.These tools represent the forefront of a technological response to an increasingly sophisticated threat landscape, offering nuanced approaches to data privacy that range from role-based access control to attribute-based access control (ABAC), each catering to different aspects of data security needs.The practical application of these tools and methodologies within a project implementation context further illustrates the thesis's relevance.It underscores the necessity of understanding client requirements, the significance of user attributes in shaping access controls, and the critical role of policies in ensuring compliance with legal standards like GDPR. The thesis concludes that while technology provides potent means to protect data, its effective implementation hinges on a deep understanding of the legal, operational, and ethical dimensions of data privacy.




This thesis has explored the critical realm of data protection in an era where digital information's value and vulnerability are both at their peak.
Through a comprehensive examination of data breaches, the impact they wield, and the subsequent legal frameworks developed to mitigate these risks, we've delved into the intricacies of safeguarding sensitive data.

We also saw how dynamic data masking (DDM) plays a pivotal role for fortifying data privacy within the financial services sector, particularly in light of the European Union's stringent data protection mandate, GDPR. Through a comprehensive investigation and a practical project implementation at PwC Italy, this study has illuminated the essential role of DDM in transforming how businesses manage and secure user data.

Our results show that dynamic data masking (DDM) works well in meeting the GDPR's rules for limiting data use and helps create new, higher standards for protecting privacy across different industries.
Despite facing challenges such as integration complexities and the need for alignment with evolving compliance requirements, the project highlighted the indispensable value of combining technical solutions with organizational policies to achieve robust data protection.

As of our project right now, we are evolving with analysing how DDM can work in the new European union regulation on financial service called DORA(Digital Operational Resiliency Act).

A promising direction for future research lies in the evolution of data masking tools through the integration of artificial intelligence (AI).
Currently, the implementation of dynamic data masking (DDM) requires the meticulous creation of policies for each data column to be masked, a process that can be both time-consuming and complex, especially in large databases with diverse data types.
An AI-enhanced tool could revolutionize this process by automatically analyzing the data within each column, identifying sensitive information such as personal identifiers (e.g., Social Security Numbers, credit card details, and so on) based on patterns, context, and predefined criteria.
By recognizing the nature of the data, such a tool could then apply the most appropriate masking technique without the need for extensive manual policy configuration.
This advancement would not only streamline the setup and maintenance of DDM systems but also significantly enhance the efficiency and adaptability of data protection measures in response to evolving regulatory requirements and data landscapes.

In conclusion, this thesis highlights how important dynamic data masking is for protecting data today. It provides a detailed way to keep sensitive information safe from unwanted access and breaches.