- Welcome back to CloudAcademy's course on Governance on AWS. So in this last lecture of the course, we're going to be talking about Actor States. So we'll have to review different ways that we can manage IAM users, roles, and groups. We'll look at the AWS config rules for IAM resources so we can manage the way that we're allowing people to access different pieces of our AWS Cloud. We're going to look at the AWS directory service, which is a great way for larger enterprises that are also using Microsoft Active Directory to connect to their Amazon Cloud and automatically synchronize permissions across both systems. And we'll look at IAM reports, which is a great way to, after the fact, run an audit of the different credentials, how frequently they've been rotated out, and so on and so forth to make sure that any kind of access controls, security policies are being followed and maintained. So without further ado, let's get into it in the console. Okay, so as we move forward with our actor governance, so our actor resource governance in Amazon Web Services, we're back in the console again, looking at the different ways that we can manage our people, or our infrastructure that is acting as people, operating under different roles that we've given them authorization and authentication for. So first and foremost, whenever we think about authentication, authorization, identity management, or actors and the resources associated with actors, we should again immediately think of this AWS IAM, or Identity and Access Management. You should have already taken at least some basic IAM courses or labs here. The resource model for IAM is that we have users, roles, groups, identity providers, and customer managed policies. So what are we getting into here? So the users that we need to govern, these are individual people that are actually logging in, or they are abused often as access key and secret keys pairs that you pass over to different service providers that might need to log in on your behalf for your Amazon account. So users are issued either a username and password or an access key ID and a secret access key, or both. And they can create AWS API calls and execute them against different resources if they are authorized to do so by merit of the policies that are attached to them in their resource or by the policies that are attached to the groups that the users are attached to. So when we're thinking about doing governance for our account, we should one, go to our IAM console and make sure that we're in a production account where we're actually taking things seriously. I have a disposal account. We want to make sure that all five of these boxes are checked. It's a very good checklist, right? We should always be using this as a monitor check for governance. Make sure that you always have all five of these green if you're running in production. When we're talking about doing governance for a large scale operation, rather than doing inline policies on different groups and users, we should be creating customer managed policies. Why would we do that? Well, whenever you create a customer managed policy, that allows you to reuse that policy and have it be updated and propagated across all users or roles that have the policy attached to it, and only allow users who need to grant access to things IAM pass role or attach policy for certain customer managed policies. So what that will let you do is when you have these managed policies, you can specify the exact permissions that your different users are allowed to grant to other users. That way you can enable people to operate efficiently on their own and not lock them down too much, but again only grant them access to the different roles that they actually need access to. So this is a great way for us to do our governance because we can also look back and see our attached entities. Because we're using a managed policy, unlike an inline policy, the managed policy will actually tell you that the different entities that you're attached to, as well as the policy versions over time if you make updates or changes. Access advisor will also tell you the different times that you've done access using managed policies, so you can create customer managed policies in addition to the different built-in policies. So presumably if I'm doing my governance, if I go into my policies during an audit and I see, oh wow, I don't want anybody with administrator access on my account. Who has administrator access? Oh, look at that. A fake person hacker, oh no. So this is a fake user, but it's here to illustrate that I have the ability to discover, oh my God, somebody has higher permissions than you need in the user base. So I just detach that policy from the user and we call it a day. So again, the IAM identity console is a great place to do your governance and actor user audits just by looking at the managed policy documents if you're using managed policies correctly and doing a reverse lookup of by policy, then look up the agents. So that gives you a nice ability to go through your policies list over and over again, and try to detach as many policies as you can on a periodic basis for manual review. You can also connect Lambdas to this and create notification lists. There's all kind of automation that you can do, realizing that anything that you can see in the console here is also programmatically accessible via the SDK or the CLI. So beyond the audit trail here, we can also look at a nice little audit trail in AWS config. AWS config we might have remembered from our previous lectures in the same course, are also good for doing our AWS standard resource audits, or timeline checks. But we can do timeline histories and auditability from our compliance perspective of specific users over time. So let's look at my fake person IAM user here and see the config timeline for that person that I just detached from. So if we look at this, we can see that we have the person that we created a little bit ago, the change that I just made to remove the policy hasn't propagated yet, since AWS config works in batch, and a little bit slower than real-time. But we can see that from our relationships perspective that relationships to that policy or that managed policy is gone already. So we also have in addition to the IAM console itself, we can use the config console to look up the resource timelines. So beyond AWS config, again, we can look at something like a directory service. So we were just looking at how we would do manual management of different people inside of our deployment, but we can also use this AWS directory service, which I don't have configured because I don't have a Microsoft Active Directory license for my personal account set up. But what Microsoft Active Directory does, if anybody's familiar with their enterprise setup, is it's an enterprise level up to 50,000 users, it's an enterprise level directory service that allows you to do identity management from a centralized place and do single sign-on for a lot of different enterprise products. AWS actually plays nice with Microsoft Active Directory as well. So when we're thinking about creating these directories... So we can create domains, let's use the corp.example.com. So I could very simply create a synchronized Active Directory name with my on-site systems. So simple managed Samba 4 Active Directory Compatible server on the AWS Cloud. So it provides a subset of the Active Directory capabilities for the simple directory. And if we do the Microsoft Active Directory that we connect, this is Windows Server 2012 R2 based, but it's fully compliant, not just the simpler Samba 4 installation. So we have the ability to beyond the reactive setups that we can do for governance, where we were just looking at the IAM users, roles, and groups attached to different managed policies, and looking at config rules for IAM changes over time, we can use the directory service to force our system to automatically update permissions with our centralized identity management system that already exists: Microsoft Active Directory. If you have a large company that you're running an installation for. So for the Active Directory, if you want to learn more and you should for if you're trying to get any kind of certification, you should walk through the getting started guide in the Amazon documentation, but be aware this is what the purpose is. It's to create a synchronized identity set with your IAM users and allow federated logon with your Microsoft Active Directory credentials and do single sign-on. So pursue that on your own time and try setting it up with your on-site server. So finally, if we're looking at all of our different ways that we can monitor piecemeal individual IAM users or synchronize a batch of IAM users, in either case, we will want to at the end of the day make sure that my credential policies are being followed. So when you go to this IAM credential report page, you can see all of your different IAM users and their authorization authentication. So we can see when we last used passwords, last time we used access keys, the name of the access keys, all of these different credential based things that we're interested in from a compliance perspective, are just a click away in a nice spreadsheet for our review at our convenience or by batch analysis inside of a big CSV understanding job. So we have a number of different ways that we can manage and overview our different IAM or identity users, or our actor model that we're talking about when we're talking about doing governance. So we should be investigating all of these different technologies that we've reviewed in-depth by reading the Amazon documentation and exploring different areas of the console. So that's the end of our lecture and the course. Let's go over a brief recap of what we learned during the course. So when we talk about AWS governance, we need to think about aligning the way that we're managing and the processes and the technology for IT groups to align with business value. We talked about more concretely what that means from an Amazon Web Services perspective, making sure that we align with the different pieces of risk mitigation, and so on and so forth. The business value, cost reduction, making sure that we're keeping track of all of our inventory of our resources. We also talked about the ways that we can go through the three steps of compliance and governance. So we start with the creation of a policy that we want people to follow. So a best practice or requirement of the business to go through and make sure that we follow these rules for one reason or another. A compliance method, so a way to measure compliance, some sort of detection mechanism to make sure that people are following policies in the AWS account. And then we talked about how we can use enforcement techniques, where we have SNS topics to push out notifications from various value added auditing services that AWS provides us, such as CloudTrail, Config, and CloudWatch events. So we learned a whole different slew of techniques that we can use and this is just the beginning of the journey. So realize that while we did a good cursory overview of how we can use each of these tools in a simple case to create a compliant system, it would be good for you to go on your own and further explore the AWS documentation for all the services that we covered since this was a good cursory overview, but we can't make a course that will be 24 hours long for you to learn all of the ins and outs. There's no better thing than experience.