How to Handle Card Data with Serverless and AWS - PCI Regulations

do you want to learn how you and your team can build a solution using aws and serverless that can comply with handling payment card information in this video that is exactly what we're going to be looking at hi guys my name is sam with complete cloud architects in this video we'll be looking at how serverless itself can help you actually reduce the number of requirements you need to meet significantly compared with a more traditional architecture and then we're going to look at some very specific design patterns or architectures that you can implement to help resolve the remaining set of requirements so those 12 different requirements are that you protect your system with firewalls you configure passwords and settings so that they are not the defaults you protect stored cardholder data so that people cannot access the stored data you must encrypt all of the data that contains cardholder information when it is moving across public networks you must regularly update and patch your all of your systems you must restrict access to your users when they're trying to access card holder data onto a business need to know basis you also need to assign everyone who has computer access to your network a unique id you need to restrict physical access to wherever your cardholder data is stored you need to implement logging and log management you need to conduct vulnerability scans and penetration tests on your systems and last of all you need to document everything in your system and provide risk assessments on what would happen if something went wrong and the mitigating things that you've put in place to stop that from happening so now that we know some of the requirements well why would you use serverless you don't want to be spending all of your time reading up on these pci regulations designing systems and processes to meet these requirements and then having to write all of this up into the documentation required to meet these requirements when you're with a cloud provider they've actually done a lot of the work already aws have a list of pci compliance services and here is a diagram showing you the responsibilities that you have when building a pci service using ec2s as you can see aws will handle the physical security of the hardware but pretty much everything else is up to you that means that you are doing almost all of this pci compliance work which is actually quite a lot of work if on the other hand you go with a serverless service then the story is quite different with serverless aws does a lot of things for you in terms of development they manage resources runtime environments container isolation much more so this is great as a developer as those things you don't need to think about but when it comes to pci this actually means that they are in charge and they have the responsibility for a lot more of those requirements as you can see you still have a good set of requirements that you need to meet on your own but they are less than half of the total number of requirements which is a massive reduction into the amount of work that you need to put in to become pci compliant so now that you've chosen to build your solution using serverless services you might think the rest is going to be easy unfortunately there are still some quite tricky requirements that you need to meet luckily there are some very nice design patterns and systems that you can put in place to help you tackle those the ones that we're going to be looking at are using a multi-account aws setup where you split things into different accounts for isolation we're going to be doing this for both pci and non-pci sets of infrastructure as well as for each of your environments and then we're going to actually move on to some very specific services and how they actually help you meet the requirements i'm going to read through these nice and quickly and give a very short summary of what each of them is so we've got cognito cloud watch and cloudtrail and that is for your user management as well as logs and being able to tell who of your team has made what changes or accessed what data you then have dynamodb for encrypted storage lambda for all of your compute needs and then the serverless framework to help put all of those parts together in an easy to use system we can then move on to iam which is your access management and how we can use this to enforce the principle of leased access we can then also use static code analysis and finally we can actually monitor the runtime events and use services to make sure that we are not having a vicious or malicious events triggering our services when you're being assessed for your pci compliance every single piece of technology or service that could have access to cardholder data is classed as being in scope and therefore is subject to all of those 12 requirements and all of their subsections if you can prove that one part of your system has absolutely no access to the cardholder data or any way of getting in there then you can actually say that that bit of system is out of scope with your whole project actually in scope then everything has to follow those rules for example a developer wouldn't be able to add a new dependency to a front-end library without having fully reviewed it and fixed any of the vulnerabilities that it might have this massively slows down the development process as developers can't use the tools they used to without these extra steps luckily you can actually architect your aws accounts in a way that makes it really easy to prove that certain parts of your system have absolutely no access to cardholder data and we call this d scoping parts of your system the way you do this is that you have at least two aws accounts per environment in one of them you put everything that will have any access to the raw cardholder data that'll be all of your storage and all of your apis and anything else where cardholder data needs to be accessed in the other accounts you can put basically everything else this could be the website that sits around your payment window it could be other services such as notifications or all sorts of other systems the way that these work is that they only ever reference a payment card via a random id which is not directly translatable into a cardholder data this means that all of the services that live in that second account are completely out of scope and have no way of accessing cardholder data this means when any of your team are working in that second account they don't have to meet the really strict regulations and rules that they would have to if they were working in the pci account now one thing you might be asking is how does is there a communication between the accounts when say one of the services in the non-pci account needs to for example find out the expiry date of the card in this case you use something called sts which allows you to assume a role in another aws account this can be used in a very very controlled way to let a very specific lambda in your non-pci account trigger another lambda that is in the pci account and get the response this lambda that's in the pci account will have a very very controlled set of access and functionality so that it never returns the card data in a raw format but could only return other things such as as i said before the expiry date or the name of the card holder these things you are allowed to have outside of pci so they can be transported back into the non-pci account another thing i mentioned earlier was that you have two accounts per environment now i definitely recommend having at least three sets of environments so having a development environment where your team can actually do whatever they need to they can figure things out they can work out how each part works together and have the freedom to know that if they break something that's not too bad that is a development environment which isn't needing to be stable you then have a middle environment some people call this integration testing staging or even pre-production and in this environment you want it to be stable you want this to be as close a replica of production as possible but not having any live card holder data in there this means that if needed one of your developers or your team or even your qa team can actually go into the pci account in that environment and see what's gone wrong if something doesn't work that is a massive bonus as it's much easier to resolve the issue like that finally you have your production account and this one is the real one so the pci account in production will have the highest level of security and accessing that is going to be really limited and that actually brings us nicely on to our next section which is the aws single sign-on system now that we have these multiple accounts for our aws environments and our pci and non-pci accounts we need a way of managing who has control to and permissions to access these accounts aws single sign-on is a really nice way of doing this it gives you a single user interface where you can create permission sets which define the access rights or the permissions that a user would have when they are using one of these permission sets as well as that you can then assign this permission set to one of your groups on a specific account this then automatically gets deployed to the account so you can do everything and control multiple accounts from a single location this is really nice compared to the old solutions where you'd have to go in and out of every single account anytime you wanted to change anything with this you can very easily show which users have access to the pci production account and exactly what they are able to do what i would actually suggest is that none of your team absolutely nobody has access to that production account and everything is deployed using continuous integration and development but when you don't need access to their account for deployment you don't really need access to the account so this massively reduces the chance of a employee accessing the cardholder data either by accident or but possibly on purpose so on screen i'm showing now a screenshot of what it looks like when you're looking at which groups have access to your account with which sets of permissions this is a really easy to understand system but it's actually also a really nice experience for your team so when they log in they can just see all of the aws accounts that they have access to and each of the permission sets that they can use to access this account which honestly is one of the nicest experiences working with multiple accounts on aws that i've used in the past so now we're moving on to more of the technical side of things we'll be looking at some specific services and tools that you guys can use to make pci compliance a lot easier to achieve two of the remaining requirements are to have authorization controls for anyone accessing your applications and data and to log and maintain audit trails of who does actually access your applications and data amazon cognito is a identity service that provides a really simple way of having a storage mechanism for your users authenticating them and then having the ability to control what access they have all this is really easy to use and it will actually meet the first of these two requirements cognito also works really well with cloudwatch and cloudtrail which are solutions that allow you to log and audit the access to your applications and data with these three services put together you'll be able to monitor exactly which of your users have accessed what level of data you can then set up some really cool triggers so that all of your data whether it's from a pci account or from your non-pci production account are all transported into a single location and then you can monitor that with whatever monitoring tool you like to use and another one of the requirements is that you store these logs for at least a year but in some cases it can be longer obviously storing this all in a high speed storage is going to be expensive so you can use s3 lifecycle triggers so that after say 30 days it is automatically transported into their archive storage called s3 glacier which reduces the cost of storing all of those logs another requirement for pci as well as just good practice in general is to store all of the cardholder data in encrypted form now encrypting your data managing keys rotations and all of this can become an actually relatively large and complex system and it's something that's going to grow as your company grows and become can become an unwanted burden on your team luckily with dynamodb encryption comes as standard it's on by default and having just this can save your team hours and hours and days and days of time sorting all of this encryption setup and maintenance so it's a really nice thing to have dynamodb also has a couple of really massive technical benefits such as massive scalability redundancy and it works beautifully with the next tool on our list and therefore it's personally my go-to method for storage in the cloud so aws lambda is basically the backbone of the serverless development process it provides you with an incredible amount of computing power without charging you a penny when it's not running not having to think about auto scaling your clusters redundancy ip ranges networking and all of these kind of things can save your developers a massive amount of time each lambda is completely isolated from all of the other lambdas so you know that there is never going to be the case where one lambda accidentally triggers another accessing pci data each of these isolated lambdas can also scale up and down really quickly so if there's a sudden spike in your usage aws will create more of these lambda containers to handle the workload another benefit of having each lambda as a isolated instance is that you can say this lambda has this very specific set of permissions and that's something we're actually going to be talking about in about two things time with all of these different services we've already covered we really need a nice way of managing and controlling our whole system for that we're going to be going with the serverless framework which is an open source framework that allows you to manage and control the infrastructure on aws and other cloud providers the way it does that is it allows you to define your infrastructure as code creating your infrastructure this way makes it really easy to replicate if you need to copy it from environment to environment which makes it perfect for a continuous integration in continuous deployment process but also makes it easier to analyze and more reliable to reproduce this also acts as a kind of self-documentation explicitly stating what you are deploying in terms of infrastructure as well as code and into which account this ticks off one more of the requirements on our list of things that we need to do and it also is a really enjoyable developer experience i've been using it for years and all of the other flashy frameworks have come up i'm still sticking with the serverless framework the serverless framework also has a really really big user base which is really useful for everybody because that means there are more people developing plugins plugins are an awesome way to extend the core functionality of the serverless framework in a way that allows you to reduce the amount of effort it takes to deploy certain services some of my favorites are using dynamodb local which allows you to test things offline also another one is using webpack so that you can minify the code and make sure that the each of your landers just has the code it needs which actually helps it spin up faster and reduce your cold start times as i talked about in the previous section about lambda because each of them is completely isolated from the other you can with the serverless framework say that this lambda has this set of permissions this custom i am policy allows you to restrict which tables or which functions and which services that lambda is allowed to interact with this allows you to grant the absolute minimum privilege to each lambda and each lambda can have different kinds of permission based on the tasks that it needs to achieve doing this with something more traditional would be really really difficult but with lambda it's actually a very very easy process to get set up and meets one of the requirements of pci which is enforcing least privileged access so now that we've designed all of our system using the serverless framework iam for permission management and lambda and dynamo and cloudwatch incognito that's all in our serverless framework we need to analyze basically is it compliant and one of the great things about the serverless framework is that when it actually deploys it compiles all of that information into raw cloud formation templates cloud formation is just aws's mechanism for defining infrastructure as code but writing it raw is really complicated which is honestly one of the other benefits of serverless one of the big benefits of it actually translating it into cloud formation is that there are multiple tools out there which help you analyze whether your cloud formation is compliant with a set of rules one example is cfn nag which is a cloud formation tool which allows you to test against a set of rules for example that you're not giving any wild card access to any of your functions this can be really useful as it's another one of the requirements in the pci requirement spec as well as scanning the cloud formation you can actually have tools that scan the actual code that's going to be running inside your lambdas in there you can make sure that you're not accidentally console logging out the raw card holder data or other things where you're not quite sure whether the data is going to be secure you can have rules that test against this and ensure that you remain compliant with a traditional architecture you'll normally have a cluster of servers that are running and they will be triggered through end points that are either exposed to the network that they're on or possibly to the public network when you're running a truly serverless architecture then there's a huge range of things that can actually trigger your landers they could be triggered by a dynamodb change a file uploaded it could be actually manually invoked from another lambda in this case you need to actually inspect the event that is coming into your lambda and make sure that that doesn't contain any malicious content though so there are two real ways that you can do that the first is by defining the exact schema of the event you are expecting to have coming in you can use a tool such as yup to define exactly what fields what shape the object is what parameters you expect to be on the objects and if you don't get an object that meets meets that you can just reject it this will actually catch so many of the possible attack surfaces that your app may have previously been vulnerable against but you can also take it a step further anywhere where there is some custom user input so this could be the text entered into a dynamo table or it could be the if it's an api gateway request it could be the text of the message sent to your service in here you could actually do a static analysis on the object content itself to ensure that that doesn't have any malicious code in there which could make vulnerabilities in your system so i said that's all the first option the second option is there are services out there which do this all as a single package you can pay for a license to use their system and they give you a package that you can load into your landers you pass your event through their system before processing it and they will analyze whether there is a risk that that event is malicious or not this obviously has a higher cost but means that you're offloading some of the responsibilities onto a separate company who will have to then also have all of the pci accreditation required to provide that service if we're now going to go back to the diagram that we looked at right at the very start of this video we can have a look through the requirements that the solutions we've talked about have already met so the first one is the authentication of users as well as the authorization control of access to applications and data those have all been met with aws cognito and our aws single sign-on cloudwatch and cloudtrail help us meet the logging and auditing requirements so that's another one ticked off and finally the serverless framework with all of the plugins and tools that we've talked about will meet the requirements for using the least privileged iam roles application behavior management code scanning and configuration as well as the requirements to maintain a full cloud asset inventory this setup will also provide a solution for gathering and transporting all of your logs there you can easily monitor the events and the security incidents i've chosen not to talk about this the specifics of monitoring tools as there's a lot of solutions out there and everyone has their favorite you can connect that up to the logs in a central location and monitor to your heart's content meeting yet another of the requirements to meet the requirement for data leak protection you've still got to architect a robust and sound application but luckily with dynamodb's encryption as well as iam least privilege and using single sign-on and account isolation a lot of those boxes are going to be very easy to tick and that process should be a lot easier than with a traditional system that leaves the responsibility for detecting vulnerabilities in third-party dependencies and removing obsolete cloud services these are tasks that you're continuously going to need to do with your team throughout the development process of your solution if we try and compare the responsibilities you now have compared to the ones that you would have had with a traditional architecture you can start to see the time effort and resource savings you will have if you implement this kind of serverless setup this can save your company huge amounts of money and help you develop develop a pci solution quicker and more efficiently so this video has been a bit different but if you've enjoyed it make sure to hit that like button and if you're a company who is looking at serverless and aws and needs some support doesn't have to necessarily be around pci it could be anything aws and service related then just drop me an email you can find my contact details in the about section of this channel and i look forward to helping you design and build some really awesome aws systems

Channel: Complete Coding

Views: 426

Keywords: AWS, serverless, Serverless Framework, NodeJS

Id: dLfKeIqNRP8

Length: 32min 28sec (1948 seconds)

Published: Thu Jun 03 2021

Reddit Comments

[u/SamWSoftware]

If you've got any questions then just let me know