Krzysztof Kąkol: Designing for Privacy in AWS

This talk covers the essential principles of designing for data privacy within AWS environments, emphasizing the importance of protecting sensitive information, particularly in human resources management systems. The speaker, Kristof Kackle, shares a real-life project experience to illustrate how thorough risk assessments and best practices can lead to a privacy-centric architecture. He discusses the application of the Norwegian data protection authority's checklist, which provides practical guidelines for managing data privacy requirements. Key aspects include ensuring confidentiality, integrity, accessibility, resilience, and traceability of data throughout the system. The speaker elaborates on using infrastructure as code, secure management of access rights, and the implementation of encryption strategies to maintain data privacy effectively. Kristof concludes by stressing the importance of documentation and continuous improvement in adopting privacy-centric practices in software development.

[Music] ladies and Gentlemen please welcome our next speaker Kristoff kackle presenting the topic designing for privacy in AWS I everyone uh I'm happy that so many people are here it was a sarcasm I think that uh probably some of the people are still waiting for their launch I hope so least um I wondered how the artificial intelligence will read my name it was absolutely funny uh my

name correctly is pronounced Christ of conol but it's too hard even for artificial intelligence which is absolutely an ultimate proof that AI does not exist uh today I would like to tell you a real life story this is just based on a real product that we did for our customer uh on real application where we made a journey to design it for privacy and I will give

you an overview how we did that but I will get get into a lot of technical details as well just to leave you with some proper knowledge and just to give you a set of hints how to think about data privacy and how to design these things uh from this architect's perspective developers perspective devops perspective so and business-wise perspective as well uh just a few words about

myself I'm a chief of data engineering uh Department in uh cabia Poland also a Solutions architect or mostly a Solutions architect I'm an AWS Community Builder and uh AWS Ambassador and that's why my first question to you how many of you are working with AWS oh most of you okay great then you will uh basically grasp the idea of the well uh so first of all the

story about the product this product is is an application ASAS application for human resources management and the problem or the challenge with the uh HRM world is that HR is about data privacy when we started to think about data privacy in the HR solution uh it was like which data actually should be protected or should be treated as private and we ended up with a thinking that

all of the data in HR System are private at some point just to simplify things so we protect everything then clients would like to be secure they would like to know who has access to the data where the data are stored do we trust the cloud this is just an initial question do we trust all the parties and all the third party components in inside the system

then we have business requirements this is pretty difficult because the business requirements quite often are about to remove the data privacy rules because customer wants something super ex exciting for the custom for for the users but something that actually spoils the the big picture privacy and we are a vendor we are providing the software for our customer so we have a big responsibility of how it's used

where it's used uh who has access to it uh and what happens if the DAT if the data leakage occurs I'm a big fan of theory it's not that I'm a theoretical guy I'm a developer as well but the thing is that theory prepares you to do things I mean if you can do things if you can develop a software a piece of software then you have

a practical knowledge how to do things but if you know the theory then you know why you are doing it that way that's absolutely powerful and changes uh changes the way of thinking uh by Developers what they actually do the same thing is I always repeat that with Gen once you use chat GPT it's great but if you understand how uh chat GPT Works under covers then

it makes your experience much better so we started from this Theory it's a data privacy by Design approach uh it's pretty old and it has seven principles uh proactive not reactive so it's like pretty much self-explanatory rules privacy is the default setting in a system so you don't not as a user have to have have to set up anything privacy embedded into design so you have to

start thinking about that from the very beginning uh full functionality positive sum it's a nice feature because it's it says you cannot make trade-offs it's not that either you have a grade ux or data privacy you have to have both End to End security so you don't only think about the database or the software you all also think about the deployment processes and these kind of things

uh visibility and transparency so you have to be open to your stakeholders what the system act actually does where it stores the data and these kind of things and respect for user privacy it means that you have to keep all the features of data privacy uh visible for the customers for the users but these rules are just generic rules that you can apply to pretty much everything

and because of that they are pretty useless because they don't give you a hint what to do in your specific workload or what system uh that's why we switch to uh the checklist uh called Data protection by Design and by default prepared by Norwegian data protection authority and it was pretty convenient because our customer is from Norway but this list is much more powerful because it gives

you specific hints what to do starting from the very beginning first you need to provide training to your team and to your customers uh to everyone that's involved in the process of producing the application then requirements you have to create uh you have to manage your data privacy requirements but not only from the perspective of data privacy but how they deal with the re the general business

requirements of the system but you specify the non-functional requirements that are applicable to your uh to your application then you have the design principles what to do to design an application having data privacy in mind how to make coding and testing practices uh uh in such a way how to set them up in a such a way that data privacy is always uh in the center how

to manage the release processes and how to maintain the application as you can see these checklists seem to be at the F first glance uh much more practical than these previous rules which are absolutely nice but they are as I said mainly useless but these checklists are very useful it's a ver it's a full uh for every section in these uh checklist you have a full document

which describes step by step what to do it does not apply to Cloud it does not apply to any type of workload specifically but the they are Universal or uh they are Universal in a way that you can apply it to everything so once we got this information or Theory once we get this list we read them we understood them uh they are pretty simple to understand

by the way then we have to make some prerequisites that's what we did in the project so the project was in a it it was not a startup phase it was like a 50% of the features were there done and deployed and when and and work on production and we try to start thinking about data privacy it's quite often that you start from different points you might

have a startup where you have only wireframes uh drawn on a piece of paper or you have a full product working with a complex landscape uh with complex set of servers and everything else is working from couple of years so it's probably a legacy but you can start thinking about data privacy at any point in time so the first thing that we did was a risk assessment

or risk analysis and there are lots of methods uh to do risk assessments but I my personal choice is always tried because it's focused on security this is the first thing and the second thing which is super important it just creates uh something that I call a world of concerns it means that if you are focused on the stri F risks then you know what to do

and you know where is the end of your risk management or risk analysis work uh I've spent quite a lot of time in uh working in in working for different projects where we just made a typical risk analysis where many people thought about different risks it was chaotic and it was a never- ending brainstorming but sted streamlines your effort in finding risks for these six categories first

is spoofing which means that someone or something is doing some something on uh like pretending that this some someone else uh you have tempering so someone is unlawfully changing your I know codes resources data whatever then you have repudiation this is like masking your traces so claiming that you did not do something uh then you have information disclosure so someone gets access to uh uh the data

or the information that he's not allowed to uh then you have a denial of service which is self-explanatory uh but does not only apply to distributed denial of service but also to the situation where the service stops responding for different reasons and elevation of privileges is also self-explanatory so someone gets Privileges uh in an again unlawful way uh gets additional privileges I will tell you a a

little story about that which happened in our system uh actually and once you get these categories then you just think of the risks that occur in the system and a very important hint sometimes I met a situation that people thought about uh one of these categories and thought about the risk and they said well we have implemented something that is basically uh removing this risk but this

is not a good choice you have to put all the risk even though you have done something that protects you uh from this risk risk to happen so this is important the next uh prerequisite is valid for a system that already exists and uh on the right hand side you have a uh architecture which is wrong uh I gave this presentation um like two months ago and

I did not have this this is wrong and people said well uh nice architecture but was it really wrong so now I put explicitly that this is wrong this is wrong architecture because for all of you who work in AWS you have only public subnets you have no replication resources lots of mistakes are made here and this is the thing that happens or occurs in many many

system that I have reviewed myself uh so you have lots of situations or lots of setups that you have to correct something and you see these mistakes at the very beginning for instance the typical situation is that if you have a workload in AWS you've probably seen that before you have hundreds of uh security groups which are managed by nobody so you don't basically know what they

are for and once you enter a landscape with 200 servers you don't know may I remove it or not so this is something that happens all the time some of these security groups are open and this is a risk so the best way to start with is is making a high level recommendations for how to improve the system from the infrastructure point of view and then this

is something that I recommend to everyone even though you might not have an opportunity to do that for your project just think of any theoretical project think of anything and make a well architected review it's available it's a tool that is available in AWS well well architected tool and this is just a list of questions uh with an explanation what are the best practices so this is

the best way from my point of view to learn best practices how to handle workloads in the cloud although it's not only focus on handling the workloads but it's also focused on uh their habits or how do you really work so on soft things as well so this is very very valuable to to spend some time and uh click through it even though as I said you

don't have any workload to review so just for the summary of prerequisites first of all create the world of concerns with anal RK analysis you like but I recommend stri this is what we done what we've done and then uh learn some best practices and again from whatever Source but I recommend myself uh well architected tool in AWS so then we go with implementation so once we

get got that theory and once we uh learned the best practices and created our world our world of concerns so we've made our risk basically uh we should focus on how to do things so what is important to implement and uh the Norwegian data protection authority checklist have has these five features confidentiality Integrity accessibility resilience and traceability which are the main building blocks of thinking or implementing

the data privacy in your project uh you can create an acronym it will sound weely but don't care about that uh the thing is to remember these uh items to remember these components and to understand what can you what should you do conceptually but also how could you implement that and that's what I would like to show you now how we've implemented these five basic rules first

of all confidentiality so it refers to protecting sensitive data from unauthorized access this is just a simple definition but how can we do that that our setups or uh uh our infrastructure or our code might be very complex and might consist of different components so these lists that I will show you in a second might not may not apply to your workloads 100% but usually these are

the basics which you can do and this this is the very important fe uh very important mindset that you should probably have when thinking about data privacy in your application so start small start with the single components don't try to be ideal at the first at at the day one because it doesn't work and it's actually what happened in our project so we just moved step by

step improving improving constantly improving once we got to any stage we thought okay we should do something more but these small steps are making you closer to to to the goal and this is to the Target and this is the main uh thing when uh trying to implement these rules so for confidentiality the main most important rule that is repeated in in many presentation in many papers

is principle of list privilege but what does it actually mean it might be that you limit their access to your production database and then production environment so only these people who should have access to the production environment and database uh will will get this access but in fact it works in a different way it's like I need to fix something can you give me admin rights on

production environment just for a second and know you you're given this these rights and then admin forgets about that and you have these rights for a long time even if you're fired from the organization something uh very wrong but you have to try to uh manage that from your point of view so the best way to manage that is to use infrastructure as a code like terraform

or cloud formation on AWS of course you have to uh also manage the access to your code base so you have GitHub actions or uh GitHub or uh gitlab or any other uh repository for your code so you have to probably manage it uh in a in a way that you can revoke the access whenever it's not needed anymore and uh the last thing that we did

is we store the secrets we actually do not store it in Secrets manager most often but in a parameter store as a as a secure string but it does not really matter whatever tool you use maybe it will be simpler for you at the very beginning to use parameter store because it's cheaper but then you think okay some of the uh Secrets should be rotated like the

access uh keys for the database then maybe Secrets manager might be a better choice some authentication policies this is something that is often forgotten we create a AWS account we give access to people and well it works but then uh the AWS console shouts all the time that the root account does not have MFA uh configured uh but we omit that screen and don't do anything with

that it's better to start uh from the beginning to implement uh all of these rules that are on the on the screen so good password policy using T TFA and en Forest whenever possible because it's not always possible and uh access restriction policies to your environment uh for instance if you have your workload you have ec2 servers ec2 machines on AWS it's better to not use to

avoid using SSH because you have systems manager uh if you have your database in a private subnet you have to have access to it to to an endpoint probably have to create a VPN connection or a Bastion host but please uh pay attention to the Bastion host is like a uh is a weak point in your infrastructure or might be a weak point so you have to

think do you do I need to have it all the time or maybe only uh switch on uh uh in incident incidentally uh and Switched Off afterwards if if everything is fixed then encryption this is the basic physics uh when we started to create that application and then uh we've worked on the data privacy uh after a couple of years we've went through the ISO certification it

was uh specifically the iso certif certificates that are focused on uh data protection and Security in the cloud and this was the main point do we have encryption pretty everywhere uh first of all we have an encryption add rest so for the day databases uh diss uh storages and everything and in transit and again if you have an in transit encryption you might have it from the

user to your load balancer and you can have an encryption in transit within your network the second one is not required for ISO and gdpr and even for p p pcidss compliance rules but still you might think maybe it's it increases the security the overall security of your system so it's like a Content encryption so a Thrust and communication encryption and the control of the key this

is something uh quite funny because uh how many of you are using KMS actively okay not too many of you but KMS provides a couple of ways to create your keys the there is a default key for every service it's a service oriented key but it's managed by AWS uh then you have a so-called customer managed key where you create the key you do not create it

physically you just uh say that it should be created or tell the tell the AWS please create the key for me and these people will have access to it and these people will have access to to make a rotation and these people uh these roles will have access to uh encrypt encrypt data with this key and it means that you are in a control of the key

even though the key is absolutely managed by AWS this is sufficient although I believe that the default keys are the keys that you don't touch they are rotated uh by AWS they are probably the most secure option but the thing is that uh I the the certification and compliance rules require you to have a control on the key and last think well-designed features this is absolutely critical

because this is an application so you have to think think of how to create a permission model so that everyone has access to what uh what is uh so to what he's or she is allowed to uh some sensitive data might be used so there there are some ways to make a special behavior so we for instance in our application we have a field salary which is

a sensitive data so once you open a page where the salary is displayed it's not displayed by default you have to click an icon to reveal this the salary because someone might just go behind you and notice the salary by accident so these are these small solutions that improve the security further elevating privileges should be impossible and that's the story that I wanted that that I mentioned

at the very beginning uh we have a feature that allows to onboard new employees uh in the HR System and when the employee who has a permission to on board anyone else uh Fs in the form this person also picks a role for the new person and this role might be in terms of permission higher than his own role which means that this person might on board

himself or herself with a higher permission then Elevate privileges in an unlawful way so this is something that we noticed after and a couple of months and we said okay we even didn't think about that that this is possible so you have to sometimes think what is possible in the application and uh uh consider that from the security perspective and of course uh tested permission model it's

testing permission model is super difficult I will say uh a little bit about the permission model itself uh uh a little later so integrity means that the data is protected against unwanted alteration destruction loss whatever might might happen to the data so someone uh Records your data uh as an employee and someone else destroys this data so we have to protect it uh but first of all

these are Basics S3 object versioning is a default setting and it's used in our system for all the files uh regardless of their purpose it might be uh a document contract agreement with the with an employee whatever everything is uh managed through S3 object versioning it's an easy thing to to to uh to create but please remember one thing object versioning Works in a way that if

you remove an object from a tree you don't actually remove it you make a uh a new version which says the object is removed so once you normally try to get the access to the object it does not exist but you can remove the flag and recover the object so this is super important you can remove it uh like 100% but this requires a CLI uh call

IM roles uh it's typical that people try to use some credential in application and it's inevitable so you you have to use them somehow because you have access to external services and and anything else but uh it's possible to you to avoid using long living credentials for AWS specifically so if we focus on using rols only for all the resources for all of them you can use

these roles then you avoid storing long living credentials anywhere and at least you uh minimize the uh the attack Surface by removing all the long living credentials for AWS which is absolutely uh super convenient if you create a role then you apply a permissions a permission set or permission policy and then you can attach this role to any uh aw service machine whatever uh and this thing

this service is able to do only what's in the policy there are of course some additional policies like resource-based policy uh so for instance a service is calling a Lambda so this service might have permissions to call the Lambda Service uh but in fact the Lambda service M must give an explicit permission uh to be called or to be invoked by the other service or roll or

machine or whatever and uh the last thing seems to be trivial like semantic roles but it's super important once you once you have all these roles in your system you might end up with multiple roles like I know 100 roles and if you do not make them semantic you will not be able to manage them at all in any way you will lose the context all the

time that's why creating sem R so the RO this is a role for a service that is responsible for I know saving the contracts for the employee then you have a semantic role and you know that this service is uh allowed to do this and that that's uh absolutely important the same thing uh is for security groups uh in AWS data validation uh is again one of

the ways to avoid uh uh problems with data data validation is something uh simple I mean simple in a way that uh in application you do that probably all of the time uh but it might be uh worth thinking or considering the scenario where you validate the the data in an additional way so not only if it's a good type of the data but also if it

fits uh in a certain range for instance if you have a field H and you insert uh I don't know 223 it's a good uh integer but still it's a age and monitoring and logging this is something that helps to keep Integrity of both resources and data uh whatever you have uh even the processes might be done like that so cloud trail for API calls for API

activity it helps quite a lot quite quite a lot of time to detect who did what and uh logs for uh managing all the resources so for S3 for the database for the workload itself uh we've sent we send these logs to uh cloudwatch except for the locks for the resources or for kubernetes uh cluster that we have that are sent to elastic search directly um but

this is just uh an exception in the general rule you have to think of uh the costs of cloudwatch they might be uh very high if you send everything to them like for instance um the cloud trail um locks uh should be uh sorry not the cloud trail but the VPC flow locks so the network locks from your setup can be sent to both cloudwatch and S3

so uh I recommend a tree because these Network locks are absolutely huge and you might pay couple of hundreds of dollars per month just for locks from VPC and audit Trail in the application it also helps audit Trail is information what happened with the given record so if I entered the record or the data of a given user of a given employee and I've changed the name

it should be stored somewhere the history that Kristof conol has changed this and this employee and on this and this date this is what was before and this is what is after it helps if you try to investigate what happened with the given set of data accessibility this is a term used now in a different context but in the uh data protection authority checklist it's used in

a way that the personal data must be available to authorized personal only who require it for their work and there is also a general rule that uh this uh access to this data should be given only for the time that it's needed but first of all access to infrastructure in AWS uh it's the best ways to use identity center right now uh a couple of years ago

it was Landing zones but it whatever way you uh you choose just uh try to manage these accesses through infrastructure as a code and Define proper proper roles or proper accesses for different users identity Center helps a lot here it's easy to configure and you can quickly give and revoke access whenever needed because some people will have access to infrastructure of course the permission model and this

is uh something that I want to tell uh a little bit more detail because permission models are different there are various possibilities here we can have an RO based access control which means that we are giving a user a role in the application and this role is uh connected to uh some functions or some capabilities so what this person can actually do in the application we can

have have an attribute based access control for instance imagine a flag of manager in the list of employees and uh we say if this flag says true then this person can do this and this then we have access control list which means this is like in I don't know Jenkins or in Confluence uh there are lots of applications using access control list which means that we have

an item a resource or a data and we say this and this person can read this data this and this person can read and write and this person can remove only this is a complex way to manage access but very flexible although it's not manageable at all in the commercial application when users want to have an easy setup but at the end of the day we end

up usually in with access policies that's why in AWS you specify the permission using access policies it's not because it's just a super exciting concept it's because most most often it's not possible to specify the permissions in a uh in a simple way with the use of rbac or ABAC or ACL uh and you have to say for instance I have access to my employees and one

another employee but for this employee I don't have access to his salary it's complex you cannot do that simply in in in in a simple way that's why access policies are also used in our system and well it's not simple but flexible but you have to balance these things availability of data well it means that you make your data and infrastructure and everything else redundant so you

always run your machines in replication uh you store the uh backups of your data or anything like that you manage probably some data life cycle policies so we don't do that because we don't have that many data that much data but if you have a lot of data then you probably have to make a life cycle saying after a couple of months move this data to Glacier

to pay less uh and have a full control on where where they actually are an incident management if you're if you have done a good stride risk analysis then probably this will be an easy uh it will be a piece of cake because what you have to do is just to take the risk and say what will do when this risk actually materializes should we meet should

we talk about that should we Implement some steps to fix the thing and this is just an incident management uh procedure next letter is resilience this is sometimes omitted in the data privacy approach because people say well what resilience has to do with data privacy but it has a lot to do if gdpr says you have to have access to your data all the time then if

you're server does not respond you don't have access to your data this is the most plain explanation why resilience is uh is over great importance here so what can we do high availability this is a separate topic for a separate presentation totally uh but we have to have something what we call a self-healing infrastructure so once anything fails uh then it is uh rebuilt automatically by the

system by the by the Cloud so you have uh replication uh of your uh components you're working in multiple a availability zones because one of them might be off for some reason uh you're using uh probably managed Services because they are uh highly available uh By Design and these kind of things so thinking about high availability is as I said separate topic but uh this is the

most important part apparently this is the most easy part Disaster Recovery this is not the easy part nobody wants to do disaster recovery and again this is a topic by itself we are using so-called uh pilot light which means that the whole infrastructure is in Ireland region but only the database is replicated as a read replica to another region why only database it's because it's most difficult

to set the set it up again uh when something fails on the AirLand region for instance Ireland region is off then we have our database in the it is in Stockholm and then we can set everything else up with terraform but the database if we would like to restore the database from backup it takes hours so we keep the small database in Stockholm region and it's okay

but there is a big rule about Disaster Recovery a disaster recovery plan without the test is not a disaster recovery plan so you have to not only write on on a paper but just to try it out uh we've done one mistake with that we've prepared the disaster recovery plan with a backup and restore approach so we assumed that if we copy or replicate the database snapshot

database back up to another region and then uh run a database from this snapshot it will work but apparently it didn't although we've met all the requirements set by AWS so we had uh multi- region keys and everything else but for some reason uh AWS console said we cannot restore my cql from an encrypted snapshot why I don't know up to this day to be honest but

apparently it's a feature of an RDS myql so please be aware of that and better test your Dr plan whatever it is makeup strategy this is again quite obvious but it's best to write it down what do you do with snapshots what do you do with backups where they are stored how often often they are stored how long they are stored from compliance perspective like in HR

we have a rule that the backups are stored for one year only and after that they are removed and that's a basically uh very important thing to write it down how long and how often you how long do you store the backup and how often how frequent uh are you making them and resilience to attacks you can use many many services in AWS that will help you

for instance Doos uh distributed denial of service attacks are handled by cloudfront or Amazon Shield you can even purchase uh Amazon Shield Advanced because the shield is for free as far as I remember Shield Advanced you have to pay for it but you get more uh features with that again using semantic security groups to be able to manage them and know what they are what they are

used for uh and this kind of uh approach that you make things uh meaningful in a cloud will help you to manage that later application firewalls which will help you to manage the potential attacks uh which are around uh SQL injection or these kind of uh attacks is always also a value and of course like I showed you the uh workload at the very beginning which was

wrong uh the workload should be in private subnets always except for the services you usually manage services uh that are available from the external world like load balancers or not gateways and but other than that database your cluster whatever should be in a private subnet always and the last thing quite interesting traceability there is always a moment that you would like to investigate what really happened what

was actually the reason of of of a failure so traceability helps in that so lock everything whatever you can even though you put these locks into a tree even though if you have uh short retention periods so after 3 days you remove the locks it might help you at the end of the day but of course logging and saving the locks without analyzing and notifying them is

of no value absolutely so uh try to pick the things that are important to use so to be notified whenever I know uh the N Gateway outcoming traffic is too high or something like that then you'll be more secure the more it's not like the more notifications you set up uh the the more secure you are it's not working that way uh it should be just for

purpose audit Trail I mentioned that before but there is one more thing it's is called slowly changing Dimensions this is a name from a warehousing uh world what does it mean in a the trail you store the information then someone changed something at a very given date and you have uh the information what was before and what was after in slowly changing Dimensions you store every form

of the record so if I'm uh you have a John Smith and someone changes this name John to some something else to Kevin for instance then you store the old version of the record and the new version of the record and every record in the data base has flux from which date it's valid to which date and it's pretty complex but gives you a lot of information

again for being able to trace what happened uh and what actually uh occurred in the system when something went wrong I don't recommend to start with that but just think of when it might be uh helpful for you it will just give you an opportunity to do something like a time machine so you can just go back in time and what was the status of my records

at the given date it's simple to pick that's why it's used in warehousing so once we went through all the five letters and all the five features then we should do what everyone loves to do so documentation and everyone's happy that have to write something how many of you love to make documentation sorry I there was not there was not that sorry forget about this question but

we have to do that the documentation is quite important in this process because time change time time flies people change in the project so we have to think about the documentation and where these data are stored so first of all we've done we've done an O top top 10 review we store the information about personal data access so who has access to what we have to update

that of course because people change and responsibilities change as well uh the personal data management rules have to be written for compliance reasons so why we actually process the data do we have a some some reason to do that and these kind of things so this is all described in the checklist so we can just take these things and copy and fill your data is convenient then

we have to create the document uh We've created the document regarding coding and testing practices so how do we code when do we uh how is the branching model how does the brch in model looks like how do we make uh code reviews and these kind of things what tests do we Implement and and uh you know all these things that apply to how how do we

work in in a team and of course some other documents that uh I I think that creating creating them was pretty obvious uh when I described all the topics like Disaster Recovery plan backup strategy Incident Management plan release management and maintenance process it's quite a lot of work but it pays off believe me once you have all these documents you have to update them from time to

time but that's all and you are pretty secure if the auditor comes in and says I would like to see these documents you have them ready you don't have to prepare for that and you have them updated all the time it does not take too much time to update them later on so quick summary and key takeaways first of all prepare well so Define your concerns uh

get the best practices learn about that analyze the risk this is you know for me making the risk analysis is fun because uh you always uh it it's always fun to find things that might go wrong recognize best practices using well architected tool well well framework uh document everything this is again something that we love and the last but most important thing is evolution over Revolution don't

start to don't try to be ideal from day one just improve over time improve learn improve learn this is the best way to achieve the uh goal of being data privacy oriented and this is something that worked in our project although we have still work to do thank you very much uh if you would like to connect with me on LinkedIn this is the LinkedIn link and

I don't know do we have any questions there's one question Al wants to know how do you test permission models it's a secret top secret uh it's like if you try to uh if you try to think of your personas in the system you always have a set of roles or a set of principles or a set of permissions that have to be verified for these personas

you cannot test the permission system as a whole because there are lots of variants the more flexible the the permission system is the more combinations you have so uh it's best to create personas and it's best to create scenarios with these personas that might must work and the things or the places that should not work for this given persona it's the most often uh created way of

uh managing or testing permissions okay is there another question here from the audience obviously yeah there's one thank you uh hello thank you for this presentation so my question is about um how do you um tell clients that they need to pay a little bit more to be a bit more safer because what I'm specifically looking at some of the measures that you presented will generate additional

cost absolutely and is it complicated to tell the client hey you need to pay 20% more but with that you are more compliant with whatever rule like do you just did that it's simple okay you know it's it's like a building an awareness in a customer's approach is always difficult it depends on who is on the other side but if you say this is this will give

you this value but without that you will pay less but you will be more prone to attacks then you know it's just training them learning uh con or teaching constantly giving them knowledge and convincing that it works and uh while you cannot cannot do that from the day one quite often because they uh think of spending uh $100 instead of 1002 and they try to you know

save absolutely small amounts of money but then the awareness grows grows grows and then uh once they approach the compliance rules they say okay there is no other way around let's do that thank you okay thanks for that question one Chris thank you very much for this presentation and your insights and to data of privacy on AWS it's your applause please