RDS Resource-Level Permissions
A free video tutorial from Vedvistara Technologies
Getting students from the campus ready for the Corporate world in terms of Corporate Awareness, Corporate Life Skills and Technology/Domain Skills.
4.0 instructor rating • 4 courses • 4,359 students
Learn more from the full courseAWS RDS for DBAs
Oracle Database Cloud & AWS RDS
04:19:01 of on-demand video • Updated February 2018
- Basics of Cloud computing, Basics of Oracle Database Cloud, AWS RDS
- Advantages of Cloud Computing
- AWS RDS Administration
English [Auto] Everyone will come to this lecture in this lecture. We will continue our discussions around ideas security best practices in the previous lecture we looked at how do we associate a security group specific to NDB instance in this lecture we will get into details about how to deal with an individual. I am a coward. How do we grant each user the minimum set of permissions required to perform his or her duties and more importantly how do we enforce our ideas or resource level permissions. Let's get started with the discussions around that. And then we have a demo which would allow us to explain the concepts we have to them was lined up for this audience resource level permissions. So these are the key things that you need to have in mind if you are an artist administrator and if you want to allocate resources to your developers are your junior Bebe's or any other DBMS who are handling in multiple departments. Fuzzing you've got to do is to categorize your resources then you need to define how users access those resources. And we also learned about something called tagging. You have to lock down your tags and kids if you don't want users to access your tax and you don't have. You don't want to give them the privilege to change or modify or come up with new tax on their own. And then finally you attach all these policies that you would have created to the specific set of users to get into the details as we progress. So let's get started with the categorization of resources. What do I mean by categorize your resources. It is a good practice to categorize all your resources into something like all their instances or maybe all databases owned by John Scroop ideas to support a policy creation process by categorizing and tagging the RDF resources. So you should actually make use of the tagging capability that Arbys pro-white out of the box. And this tagging is supported for many different resource types including instances option groups parameter groups security groups you name it. All those resources that you have within the various instance are within the ideas engine and would be supported for you to categorize them or to tag them. Once you have categorized your resources you don't need to define how users access those resources you should be able to appreciate the fact that on the access control policies are going by I am which is identity and access management and by default whenever a new user has created they will be treated based on the principle of least privilege. You will not be able to do anything unless you explicitly have any kind of privilege or permission to do so by getting appropriate privileges from the root user or the admin user. This exchange was a decent document of a policy that can be attached to a particular user who been given a grand to perform a certain action which stands for ideas delete the instance the action is you could perform an action on an obvious resource. The action is bleet instance where there is a restriction on the resource and this resource could only belong to the U.S. East one region and to put the account ID and to all the data bases belong to this particular region in this account ID and you also have a condition that is added which is string not equally to production. And you also have a key attached to it which is state. So you need to define the stack. You would see that as a placeholder for Andrius calling the hyphen tag. You need to define Dagh or image tag an instance and any instance that is tagged as production with the value of stage would be discounted from this particular policy which means that you won't be allowed to do the delayed action on this particular instance which is motus production and another way to look at this is if you want to do a denial on any resource you can explicitly deny access to a set of resources DVD policy would work. It provides an additional layer of protection. Because you deny command we take precedence even if other policies allow. And that's a very important thing that you have to understand that any kind of denial policies would be followed by an allowed policy and that is the best practice that you need to have. Mind you in this case we're going to do to deny on all the obvious actions ideas calling STARR With respect to a particular resource and the resources identified in the U.S. East region and it has the account number and the name of the resource specifically is the Prady the be achieved. So you want to deny access to this particular instance but you might want to allow access to other instances. So if you just say this then you won't get access to any of these instances even though you are only doing it denied. So that's really important that you need to understand we look at that and we do the them. And the important aspect is to lock down your tags. You need to restrict which users have permission to apply and remove tags if you're a developer or if you're a Junior Beebe I should not be playing along with tags and mucking around with the standard policies. So I assume created the policy so that they are not able to add facts to a resource or remove text from a resource for any other resource that belongs to the Arias family. So that is how you lock down your tags. And then finally once you have defined your policies you have to attach them to the users as we said earlier. I am access control policies are based on privilege. You could address the policies you created in the I am principle principle is nothing but a user or a group or a group. And you would actually see that as we do the Lap's and more importantly you should perform periodic checks or audits to ensure that you have proper compliance in place. Policies have not been misused or have been applied inappropriately. This brings us to a logical end to this particular discussion here. I will see you in the next lecture wherein we discuss more about how do we deal with these resource level permissions. From a practical standpoint. By taking you through lapsing that you are the inept. So thank you for watching. I'll see you in the next lecture.