 So, hi guys, how are you doing right now, almost 3 session gone, so it is the last session. I will not take much time, so I will go through the slides a bit fast and so let us start with this thing. So this session is about the security, you know the AWS security is a very vast topic and it takes even not days, even the weeks to cover all the topics. So right now we are going to talk about the two edge cases about the AWS security today and those two topics are the organization service control policies and the permission boundary of IEM. So let me introduce myself, I am Mohit Thinanwal, basically I work for medical security company in Singapore and I play with data, so I am a data professional okay and is it okay with go with this, but it is going on. So guys, we go ahead with this, is it okay, okay, so today's presentation agenda basically we are covering three things here, so one is we will just go and touch base the high level of organization SCP, I guess everybody might be familiar with the organization, if you guys have worked with AWS, okay and second thing we will talk about the high level of the permission boundary and the last thing we will talk about the two, we will do some demo for both the things how we can implement those things, okay. So I will go through the slides a bit faster, okay but all the things and the material and the links will be there, so you can go through those things, okay. So let's talk about the high level of AWS organization, since we lot of organization have multiple accounts and they have a multiple policies and all those things to manage all this, it became very nightmare and when the Amazon came up with the cloud offering that this thing was missing, so they come up with the centralized billing in the call of organization and later on they added all this service control policy and other things. So basically it covers four or five main things which is mentioned in the slides, okay. So it covers the policy across the all the AWS account that you can add into the your organization, okay, so you can add the services resources, okay. It helps you to create the account also within the organization, okay and then it allows you to configure those multiple accounts, okay and the last thing is the billing, so you can leverage those different accounts, billing and consolidate those things and get the discount from the Microsoft from the AWS, sorry, okay. So today we are going to talk about the special case about the AWS organization which is SCP, okay, service control policy, okay. So basically what service control policy is that if you have an organization and you have added three, four or multiple accounts in this, how are you going to manage the policy of those accounts? Is there a centralized way where we can provide all the policy and you can manage those policy across the multiple accounts, okay. So this helps you for governance and security purposes, so what we are going to do today is that we are going to, we are going to have an organization, we will have a multiple accounts then see we will create one policy, we attach that policy and see how it works it out on the multiple accounts, okay. So this is the demo that we are going to do today, okay. So first is create in the organization and then in the organization you will have multiple accounts, okay and in the multiple accounts we will create one policy, okay. Then we implement that policy at the organization unit level and see how it propagates into the multiple accounts, okay and then we will test this restriction whether we have applied the policy whether it has been successfully implemented or not, okay. So this is the thing, the second, we will go through the demos, both the demos together. The second case that we are going to discuss above is that the IAM also we have some capability we can restrict the access by using the IAM boundaries, permission boundaries, okay. So we will touch base on this IAM permission boundary. Once we cover this, the second demo will come back to this slide and see how this thing is working, how the when we have applied this policy, how this thing is working with the overall permission of the IAM user, okay. So how SAP is working, the overall permission of the user and the boundary that we have applied, okay. So let's go through the demos. Any question till now before we move to the demos, okay. So since we have a shortage of a time, so what I have done is that I have created the organization already, okay. And I have added the, I have created the organization unit and added the account in that. So basically if you see here, this is my original account, okay, my main account on which I have created the organization, okay. And on that account I have created another three accounts and added into part of the organization unit. So these are the three account that I have created, okay. This was the first one, this is the second one and this is the third one, okay. So these are the three accounts I have added into the organization unit. So this is the structure of this. So this is the root. Then I have created this production organization unit. On this production organization unit I have added all these three accounts. So we have one main account, okay, in which we have created the organization unit, okay. And those organization units we have created three accounts, three AWS accounts which we are going to manage now, all clear now, okay. Let's move on. You see this one. So these are the three accounts that we have added into this organization unit, okay. So where this SAP comes here, if you go through this tab at the policies, okay, you will see this policy which is full AWS access, okay. This is a default policy that you added into the organization unit, okay. So this is already added into this organization. If you click into this organization you will see this has been attached. So either you can attach or detach, you will see the status. If you are showing detach that means it has already been attached, okay. Now I have created another policy which is called as deny S3, okay. So what we want to do is that we want to create a policy that I don't want to give this production unit the S3 access and how we are going to manage this across my multiple AWS account, okay. So this is the thing we are going to do now, okay. So I will show right now because this deny S3 right now is not been attached this policy, okay. So this is a very simple policy just to denying the S3, okay. So let me show you right now what is the current behavior right now. I am just doing the row switch right now to one of the child account in the organization unit, okay. And let's see, so see right now. So this account, this rich account have access to S3 right now, okay. And same thing we can try with the another account, let's see, okay. So all three account have S3 access right now, okay. Just to clarify, each of these accounts that you are showing right now are logged in using an IAM user that has some permissions probably at least for you. Yeah, yeah. I can show you that permission also, yeah. Because like this is, SCPs are so powerful because they, another layer that will override anything that's on the IAM user and that's what you are going to show. Yeah. So we go back to this, so we go back to our organization, okay. So let's attach this policy to our organization unit. So I am going to attach this policy right now, okay. So this policy is attached now. We can see this also. We can check here also. So status is attached, okay. Now let's go to one of the child account that we have. So you see, the policy is showing the effect. So now we are getting the S3 denied access, okay. And I can just zoom in, zoom out. The address bar, click on this button. It's now coming up. Control zero, probably. Control zero. I think. Okay. Thank you. Okay. So let's go back here and see what the actual permission this account, these accounts were having, okay. So I am detaching this policy, okay. Let's go back and see whether this effect is back to normal now, okay. So you are able to see the S3 back again, okay. And what these original access that it had, I will show you that also. So all this permission it has, okay. So this is one of the example demo I wanted to show you, okay. Now the second demo that I want to show you is that there is another way we can restrict the access of a user at the permission boundary level, okay. So we'll go to this one, okay. So this is one of the test user that I have created for one of the account, okay, the child account, okay. And right now this account has admin access over the, all the resources, okay. So it's able to access like S3, okay. So S3 and EC2, okay. So this is basically, this is the test user. You can see at the top, this is the test user, okay, created as account, the one of the child unit account, okay. So now we go to this account, okay, okay. So this is part of the admin group which has admin access, okay. So now what we can do is, okay, here you see this permission boundary where you can restrict what, up to what access or what services it can access, okay. You can click on the set boundary, okay. And you can create, either you can create a policy, I've already created the policy. So basically I want this user to have only EC2 access, okay. So I'm creating a boundary policy which will have only EC2 access. So since we have applied this EC2 boundary, this is getting a S3 bucket access. But if you go through and browse EC2, you will be able to check the EC2 services, list all the things, okay. So these are the two things that I want to show you. Any question on this? Okay. So this is within the permission boundary, service control. See service, yeah, service control policies apply at the organization, organization unit level. So whatever the accounts that you have inside the organization unit, that service control policy applied across those unit accounts, including the root user of those account also. So if this policy, you're saying that deny S3, even the root user of those account will not be able to access the S3, okay. And the permission boundary that the second demo that I have showed you is mainly is restricted to the IM user, okay. So that is the one of the edge cases. Service control policy is very powerful. You apply across your accounts which you have created under, putting under one unit, okay. I tell you one thing. And let's say you have, you have in the organization, you have a multiple accounts, okay. And those multiple accounts is segregated basis on the, is it, whether it's a production account or test account or any other training and all those things account, okay. So you create an organization unit, okay, for production. And let's say you have 10 accounts for production and you put those 10 accounts into the production unit, okay. And then you want to govern and you want to put all the security and compliance policies for those 10 accounts, okay. I'm talking, when we're talking about the accounts, we're talking about the full account. In each account, you can have 100 IM users, users, role, all those things. So when you want to govern those 10 accounts, then you use the SCP and apply that SCP on the organization unit which having those 10 accounts. The IM permission boundary is a very, you can say, edge case that, you know, let's say you want to, the auditor comes into your company, okay. And you want to create account for auditor, okay. And you want to give only certain access, but you want to restrict that thing, okay. So you create a permission boundary for that account, okay. So this account, I'm creating the permission boundary. Even somebody accidentally give more access, this permission boundary overrides that access. Think of them like successive levels of more power to say no. Yeah. So it goes from like most specific to most general. So we'll start with the user, see what policies are on the user, what he or she kind of cannot do. Then, okay, well what roles is that IM user part of, or does it assume, right? Okay. Those things will then take precedence. Then it goes to the next one, which is the permission boundaries. No? Okay. What about the account level with SCPs? So it's all these different use cases. So sure, you could have a IM user and have a role that restricts that user instead of a permission boundary, right? You could do it that way. But if you, like he said, if you're worried that somebody else might go and change that role, because maybe there's permissions that need that role, it could be managed by multiple people, and only one account can answer the permission boundaries, then you would put it there, the restriction there. It's really just a number of different ways that you might not ever need, but it's really good to know about them, and especially service control policies. That's like, it's the most powerful thing that I find so many people don't know about when they should, so I'm glad that you're hearing about it here. Yeah. Thank you. So, okay, this is the last slide we have. Okay. So in the demo, if you look at those two diagrams and see how the effective permission actually is applied on the IM user or the account, okay? So in the first case, if you see that we have implemented the permission boundary, so you know the permission boundary across the account, okay? And then you have an individual identity-based policy, okay? So that identity-based policy comes under the permission boundary, okay? So this is the first case. The second case is that you have SCP applied, okay? Then you have identity-based policy, okay? And third is the permission boundary. The second demo that I showed you, okay? That user, the test user were part of an account which was part of the SCP, okay? So already you have a SCP policy. Then you have IM user individual policy, which has an admin access to that account. On top of that, we have applied the permission boundary in which we have restricted that user only to use that EC2. So ultimately, what was the effect that that user was only able to use EC2, EC2 resources? Any question on this? And this is the basic simple syntax of JSON. It's the same syntax, it's the same policy. You can apply on the SCP and you can apply on the permission boundary. The code and the syntax is the same, okay? So that's my last slide, okay? Thank you.