All right, we're going to have a
little bit of fun with this session. It says here that we're going
to do 10, easy and effective ways to secure your AWS environment. And I'll tell you
what we really mean by that. My name is Becky Weiss,
I'm an engineer at AWS, I've worked around a number
of technology areas in AWS, networking, DNS, Serverless, identity
and access management, storage, and mostly around the area
of the security controls that we offer our customers. And what we're going to talk about,
I myself, am also a builder. In fact, I think I'm AWS's,
his biggest fan, maybe not,
that's a hard title to have. But I love building on AWS,
in particular, I think it offers some really great security controls
and techniques that you can use when you're building to just know
that you're building securely. So, what I'm going to share
with you this is going to, we're going to talk builder
to builder here. So, you're in the right place,
if you are hands on building things or securing things
in the cloud. Because I'm going to talk to you
as kind of as your as your peer
as a fellow builder in AWS, I'm going to share with you
10 different techniques and strategies
and skills around AWS that I have found, make have made me
and my customers very effective at securing architectures
in the cloud. So, it's going to be
kind of 10 different topics, these are going to be
different skills that you can pick up
300 level talk, meaning that I'm assuming
that you've been building on AWS, know some of the fundamental
concepts already. So, the good news is here
is 10 topics in 30 minutes, you do the math. The good news here is that
if something is boring, old hat, you already knew
it isn't relevant to you? Well, you only got to wait
a couple minutes till I'm talking
about something else. The bad news here is, of course,
each of these topics is actually a skill meaning
that it's going to take more than three minutes
for you to pick it up. So, you know, I'm going to be
going through them quickly, covering the high points, just sort of raising them
as something, you know, I'll tell you a little bit
about kind of what they do, why you would do it. And I have links
in all of these slides to my favorite page
in the documentation for learning more
about how to do these things. So you can look
at the list of lists that we're going to go
through some of them, you might recognize,
I hope that for each of you, even if you have
some experience with AWS, that maybe there are
some things on here that you didn't know how to do yet that you can come away
from this learning how to do. So, we're going
to get right into it. All right, yeah, this has got to be
the first one here, right? If you're going to build
securely on AWS, if you're going to
build anything in AWS, you're probably going
to have data in AWS and that data is probably
going to be in S3. So, the easiest thing you can do
to keep that data secure in S3 is to turn on this very easy feature,
it's called block public access, you can turn it on across
your entire account, set it and forget it.
What does it do? Well, I'm sure many of you
may be familiar with it. We've had it
for a couple of years now. When you create an AWS S3 bucket
really any AWS resource and an account, it's private
and local to the account. And what that means
technically is that IAM principals
within that same account with appropriate permissions
can access it, but it's closed to the outside world.
Now. You know, if you use S3,
you can write a policy on the bucket, or you can use the older means
of access control called ACL to grant access to specific
parties outside the bucket. Now, those are valid scenarios,
you probably have them. What's less likely
is that you have data in S3, that you actually intend
to be publicly accessible. It happens. But it's rare.
It's not, not most of the time. And in fact, if you're
putting a website in S3, your best bet nowadays is to put
a CloudFront distribution in front of it because you get
all kinds of benefits just from that. But unless you actually
truly have public data, this block public access, what it does is it creates a shield
around the data in your account. And it effectively makes it so that no matter what kinds
of bucket policies people might put on these buckets
in the future, it makes sure that your data
is shared with the exact entities
you want to share it with. So that part still works. But public access is just blocked,
as the name suggests. So, go back and turn that on. You did nothing else
from watching this talk do this one. Tip number two. Now this tip is relevant to you
if you are in charge of the security and particularly human access
to an entire AWS environment, like if you're in charge
of the security of that organization. So, for some of you
that will be true. For some of you that won't be true. There are probably many of you
watching this talk and you work it
within an AWS environment that somebody else set up for you,
you have a way to get into AWS. So, for those of you in charge
of setting this up, nowadays,
you want to try to get to make where you can all of
your credentials in AWS can be temporary.
What do I mean by that? Well, for your applications,
this is pretty straightforward, like easy to lambda, et cetera, all these compute environments
in AWS, they all give you the ability to, they all have an integration
with IAM roles where you choose an IAM role
and then AWS takes care of making the temporary credentials
available to you. That part's really easy,
you're probably already doing it. If you think about human access
to the AWS environments, though, in the modern era, your best way to do that
is with Federation. And what I mean by that word
is it means that you are authenticating
to a directory to perhaps AWS SSO to user pools
that you create in there. And from there, you're being
pivoted into, once again, the short-term credentials.
Now the security benefits here, probably self-evident,
a short-term credential is obviously going to have
less of a blast radius than the long-term credential,
which is why it's preferred. And this technique
is easier than ever. If you have an existing
corporate directory that speaks the skim protocol, and you have the you
have access to it, you can set it up to sync identities
into our AWS SSO service and provide a really
nice experience for mapping people into these different environments. If you're a small shop,
and you don't even have a directory, but you're looking for a place
to create your human identities to get into AWS, well, you can do that
with AWS SSO as well. It has its ability to create
its own pool of users and groups. So, you don't even need
a directory to be effective here. And what that means is really,
in AWS, if you have human beings, getting into the environment,
make those credentials temporary, use some kind of Federation.
Tip number two. Tip number three
is also relevant to those of you who have those of you
who have, who are sort of in a more kind
of security administrative role over a full AWS environment
in the form of an AWS organization. You're probably
familiar with CloudTrail. CloudTrail is the AWS service that maintains
an audit log of events, all of the API calls that actors
make around your entire environment, probably have this turned on
in each of the individual AWS accounts that you have,
if you don't have it turned on, you should because you know
for obvious reasons. But CloudTrail is one of several, a growing set of AWS
services around AWS that have an integration
with organizations. So AWS organizations, of course,
this is the service that helps you manage a group of accounts
that go together, it's kind of corresponds
to a customer, an organization
has a single payer and a management
administrative account, these services that integrate
with organizations, and we'll see another
one later on, they do so because it is,
when it is useful, such as in the case
of CloudTrail to be able to configure it
across an entire organization. So, what you can do
with CloudTrail's, organizations integration, is you can set it up
so that your CloudTrail gets automatically turned on across
all of these accounts, accounts that exist today accounts
that you'll create tomorrow, get delivered centrally
into one trail, one trail and one S3 bucket. And actually as a as a bonus,
point 3.5, go and look at a new S3 feature
called bucket ownership controls when you have an AWS service
writing into your bucket, like cloud trail, turn on the bucket
ownership controls, bucket owner preferred, I'm not going to go into
exactly what that does here today, but you know, this is a feature
that we added based on our customer feedback
about how we can simplify cases when you have external entities
writing into your S3 buckets. So, I recommend you look
into that, turn it on. It's probably what you want. Tip number four, okay,
I've got a CloudTrail. This is such a useful tip.
If you've never tried this before, you should go home
and try this with your CloudTrail. So if you go to
our cloud trail console, you will see that there's
and you go to the you go to one of the pains
of the console, you will see that it gives you kind
of a one click way, it mentions AWS Athena, gives you a one click way
to create a to create a database in a technically AWS glue
that can be queried with Athena. What does that mean?
So, the Athena service is, it's actually serverless
in the true sense of the word, it's a service that can take
a pile of structured data in S3, such as the kinds of data
that cloud trail leaves behind, and give you the ability
to issue SQL statements against SQL queries against it.
Well, that's really useful, because I've got all of this
great data in CloudTrail about who's been doing what,
and now this gives me, this gives me really
limitless opportunity to get insights out of what's
going on in my environment. And I'm not just talking security, I'm talking, debugging,
troubleshooting, needle in a haystack
kind of things. Now, I've got some examples up here, I've also got a link
to the documentation about kind of
how to write these queries, it takes some practice,
but you'll get the hang of it. And once you do it, you'll realize that you kind of
have a superpower in understanding how your AWS environment's
being used. I've got some SQL queries up here not to impress you
with my SQL ability, but just to give you an idea
of what kind of insights you can actually start getting,
for example, that top one,
what did this role do? Well, if I know what this role
did in the last month, I can probably write a very good
IAM policy for them, because I know
what they actually did do. And now I can write an IAM policy
that corresponds to, well, these other things
they need to do. So, I'll write
a good least privilege policy. That's the kind of thing
you can do with these insights, good skill to have,
go back and try it. Okay, let's move into your network. This is another, this is another
really powerful tool you have for infrastructure security
at your disposal in AWS. Now, if you've ever set up virtual
private clouds and networks in AWS, you know that we talk a lot about
public subnets and private subnets, you probably have both of those,
you know, across an environment, you have lots of different accounts,
they've got their VPC's, they've got public subnets
and private subnets, across multiple availability zones
but I'm not showing you that because it would be
too much clutter on the page. You probably have some kind
of infrastructure as code, like cloud formation stack sets
that are stamping out these VPCs so each of them looks exactly the way
that you want it to look. So now I've got public subnets
and private subnets here. When we use
the word public subnet, it has a specific meaning
when we use that word, it means that the subnet
is part of a network, it has a route
to an internet gateway, which means it's routable directly
to and from the internet. And that's things in a public subnet
if they have public IP addresses on, yeah, they have route ability
to and from the internet. Private subnets in contrast,
no such route. So public subnet is where I might
put my external load balancer that I want the internet
hitting the private subnets where am I put my database that's really kind of local
to my network and doesn't ever need
to be routable outside it. Now start to think
about that at scale. Of course, I can write IAM policies
about these subnets by their IDs, you know, Cisco EC2 gives me these ideas for subnets.
They don't mean a lot, but I can write
very specific policies about them. But if I want to try to express this
at scale in a more kind of meaningful and easy to easy to interpret way.
Well, that's where tagging comes in. EC2 has, has quite good support
for tagging, particularly on subnets. So, I can tag my subnets
with whether they're public or whether they're private. Now these are, these are properties,
I can write authorization policies about that are actually meaningful
to me at scale. So, for example, if you look
at this policy statement here, this policy statement here,
it's a deny policy. So, I would attach it along
with a number of other policies that actually give people permission
to do things. But if this policy statement
is attached to you, it means that my intention is
that you should be able to you know, for example, launch EC2 instances
only in the private subnets, and the ones
that have tagged private. Now, as you get good at writing tag
based authorization policies, and IAM, you'll realize
that you'll also want to write some policy statements
that I'm not showing you here, around who can assign which tags
and for something like this, where your VPCs are probably being
created by Infrastructure as Code, that's fairly straightforward,
you would take the role that those run under
and you would give those, that role permission to write
these kind of activity type tags, and nobody else and so then things would be
tagged correctly from the get go. And you could just off
to the races from there. So, more network security at scale. If you're doing if you're using
VP C's and you're building security, you know that actually your number
one security tool in the VPC is something called the,
you know, EC2 Security Group, a very simple firewall, you know,
that sort of stateful firewall, things in your VPC, they're a member
of one or more security groups. And those security groups have rules and they have rules about who
can initiate connections inbound, and who can connect
and what kinds of connections can be initiated outbound. So really, that's your first line
of defense in your network and it you know,
even if the only thing you're good at is security groups in in VPC, you'll actually already have quite
good network security at this point. So, um, but of course, once again
at scale, these security groups, they have these identifiers,
you can absolutely right IAM policies about them. But these identifiers,
they're assigned by the system that you know,
not inherently meaningful. So, if you want a way to manage
these security groups at scale, there are a number of techniques
that are useful one to pay attention to that I'm not specifically
talking about here is a new, relatively new arrival on the scene
in EC2 called prefix lists. So, if you want
to kind of canonicalize, the list of IP address ranges
that are meaningful to you and reuse them
all over the place, it's a really good tool
for doing that and making your security group
rules a lot more meaningful. But here firewall manager so this
is a higher-level AWS services actually not in easy to proper because it's one of these
higher-level management services. Firewall manager is again, one of the services it's integrated
with your organization. The nice thing about firewall
managers, it actually doesn't require, in order to work with firewall
manager across an organization, you actually don't need access to
that powerful management account. You can designate
in your organization an account that is in charge,
it's called delegated administration, you might see that word,
an account that is designated to be able to manage firewall
manager across the organization. Now, you can do some really
useful things at scale here to make sure that
your security groups and you know I also web
application firewall rule sets are kept in line
across this organization. So, the WAF rules, they kind of
protect you at the at the outside, make rules about
what kinds of traffic is even is even going to reach you
in the first place. And the security group rules
are of course, that next level of defense, you know, what IP addresses,
what ports and so forth. And you can make rules that
standardize the security groups that you have across
your organization, standard rules around
which things can be members of which security groups,
you can run it in detective mode, you can even run this thing
in remediation mode, where it takes action
when it finds something somewhere in this organization
that's out of compliance, a really powerful tool,
we're learning how to use it. This topic of networking, actually, you can do a lot
with your network in AWS, and I'm going to talk a little bit
for the next two tips are about how the intersection
of network-based security and authorization-based security
is a really powerful combo in AWS. So over here in this picture
is you know, a grossly simplified, grossly simplified version
of probably what, about how you think
about access in your network, access to AWS from your network.
Over on the left-hand side, we've got an EC2 instances running
some application under an IAM role, in order to do whatever,
it is that they do, they're supposed to be reading and writing data from this
from this S3 bucket. That's what they're supposed to do. And of course,
when I run something on EC2, when I create an EC2 instance, I know exactly what VPC
it's supposed to go in, right, because I put it there,
I put it in some subnets. And, you know, sometimes I'll be
using something called a VPC endpoint, we'll talk about that
in the next tip, to be able to connect
to these services. And given that I know
that this EC2 instances are supposed to run from this network
and not somewhere else, well, I'd like to make an assertion
that locks that in. These credentials need to be
using this network. On the right-hand side
of the picture, I've got a human being, I've got an operator
who works for my organization and should be accessing this data
in S3. I'm expecting her
to access this data in S3. Now, as is often the case, I might
have a specific corporate network, including our corporate VPN,
that she might, that she's expected to be
using our AWS environment from. So maybe I'd also like
to make rules about that. Now notice, I'm being very specific
in how I talk about this, it is very unlikely
that you want to make access rules on the basis of network alone. Right, just because those easy two
instances are running in your VPC, just because that human happens
to be on your corporate network, that alone shouldn't grant
anybody access. You also want them you know,
principles of zero trust networks, you also want them to be
authenticated and authorized to the specific resource
to trying to access and that's kind of IAM's job. But this network signal
is a really useful secondary signal to be able to assert
who can do what, from where. So over here on my, you know,
I've got some policy for the role that my application runs under.
I have this additional statement. Again, it's a deny statement
doesn't let anybody do anything but makes an assertion about the
conditions under which they can't. I say that this role, I don't care
what service it tries to talk to, I don't care what it tries to do.
I don't care what it's talking about. If these credentials show up
somewhere other than this VPC that I know
I launched this instance into, well, I'd like
that request to be denied. On the other side of this picture
my human being, I've attached this policy to her
like to her federated role she came in through her directory
per tip number two, she came in and she's using AWS
from our corporate network. And let's say our corporate network
reaches AWS over public endpoints. So, I'm using this source IP, it's kind of the sibling to source
VP source VPC is what you get when you're
coming through a VPC endpoint source IP is what you get when you're
coming through the public endpoint, then dot one dot two dot three, let's say that's my corporate
IP address range. Oh, you see that
other condition there? That's effective security tip
number 7.5. This is really useful. And I'm giving you this example
for my human access, because it comes into play,
when, let's say my human being is following effective security
tip number four, and she's using Athena to query
your cloud trail logs in S3. Well, in order the way
Athena works is, Athena makes onward calls to S3
to get to get the underlying data. And Athena is not running
in your corporate network, Athena runs in our network at Amazon. And so, this via AWS service accounts
for those cases, I don't want to block her from using
Athena, I don't want to block her
from using cloud formation, which in turn will provision
resources under her identity. So, I add this condition to say,
well, if the you know, she's originating the requests,
it's got to be from her network, if, if it's coming by way
of an AWS service, that too is okay, because the first hop would have been
covered by the rest of this policy. So, this is how you assert
network in your IAM, use that secondary signal,
it's very powerful. To kind of keep on this topic
of the of the intersection of network security controls
and authorization controls and sort of flip it on its head, your next effective security
tip here VPC endpoint policies. So over here, in my VPC, I'm running
some applications, some on EC2, some on Lambda, some on ECS,
maybe bunch of other things. And I've you know, to keep the story, really it probably using a whole
bunch of AWS services here. But to keep this keep the story
really simple, let's say I'm using S3,
you know, because all these applications
handle data, and I'm using CloudWatch logs, because I'm running agents
on the EC2 instance, and so on to be able
to get my application logs into Cloud watch logs. We think about that a second,
the app, the data that my applications are
processing and the application logs. This is, you know, you start to think
this is some valuable data flowing around this network. And so, I would like to use
this network as a boundary and make some rules that are true
across the whole network, regardless of who's doing
what and under what circumstances and for what application. I want to make some rules
across this entire network about what kinds of actions
can take place with these services that I have connectivity to. And that's where the VPC
endpoint policy comes into play. I'm going to show you a VPC endpoint
policy for my S3 VPC endpoint. You can do this for your cloud
watch logs VPC endpoint, as well, though, of course, you could say logs
colon star instead of S3 colon star. This is, well, the first thing
you might notice about this policy is its law
and you might be you know, if you've never seen
one of these before, you might be a little bit suspicious
about what I'm doing here, because it seems pretty broad.
There's a lot of stars in it. The VPC endpoint policy,
it's a boundary. So, it's a gate
that you need to pass through. Nobody ever gets permission
to anything on the basis of what's in a VPC endpoint policy. It's necessary, but not
sufficient for granting access. And as such, you tend to write
these policies, you know, it's, I find that customers are most
successful writing these policies when they just make like
a really coarse-grained assertion. This policy here
that you're looking at asserts that all use of S3 is from the set
of principles that I expect. Principles in my network are going
to be using S3 from this network, that eliminates a whole set
of unexpected use cases. If somehow there was some kind
of problem in the environment where you know, where a different
set of credentials showed up, they'd be unable to use S3
from this network, and they had valuable data in here. So that's an assertion
I want to make. I could get more granular than this,
if I wanted to, for example, if this was a fairly simple,
well constrained VPC and I knew that, you know, hey, this list
of 10 S3 buckets is being used, I could have added
a resource condition to insist that it be one of those 10 buckets.
So, you could do that as well. But my recommendation is, as you're
using these boundary policies, you keep them really simple and save
your least privilege policies for the permission policies
that actually grant access. So over here, these EC2 instances,
it's an application. It's code. It's machine. It's not man.
It's completely predictable. I know that it is,
I know that it is writing data to this specific path
under this specific bucket. So that's where I write my good least
privileged policy that grants access. The VPC endpoint asserts the that,
you know, all of my access fits this pattern. I have the corporate network here
in this picture as well with a you know
the icon for a VPN connection. Most of our AWS services that offer
VPC endpoints offers something called interface
VPC endpoints. It's the kind of VPC endpoints
that they offer. Those are reachable over a direct
connect over or over a VPN, because they're just addresses
in your they'll just appear
at addresses in your VPC. So, if you wanted that network
assertion that VPC endpoint policy to cover your own premises network
as well, you could do that. Tip number nine,
my favorite of these 10 tips. Want to question why I put it Tip Number nine,
I'm not exactly sure. Connecting to EC2 instances,
in my opinion, a way better way, EC2, for probably as long as
there's been EC2 has had the ability to create
key pairs or resources in EC2. EC2 hangs on to the public key,
you get the part you manage and take care of that private key.
And it's just an SSH key. It works exactly like SSH,
because it is SSH. You need direct network connectivity
to that EC2 instance, within a public subnet, you can do
that if it's in a private subnet, you'll need a bastion in the middle,
public connectivity to the private to the public
to the bastion in the public subnet. And then for the SSH connection
to the private subnet, then, of course, you think about the, many of you are probably
doing this today. And you probably have good security
practices around these private keys. But the fact of the matter
is that you know, this is work that you do
to secure these private keys because the private key is
really outside the world of AWS. And in fact,
the effect of a connection, the connection attempt is also
kind of outside this world of AWS. So that's where our AWS
System's Manager, session manager, really, like I would
if you haven't looked at this, I would definitely recommend
that you do this, it makes connecting to your EC2
instances simultaneously easier and more secure. Systems manager's
just an AWS service, so it's API's that you use
to interact with it. When Fred wants to connect
to an easy to instance, he no longer has to take the SSH, private SSH key
that somebody emailed to him. He now makes an AWS API call
that gets authorized, authenticated and authorized
against his IAM policy. Either he has permission to call
start session on this instance, or he doesn't.
Because it's an AWS API call. It gets logged in cloud trail.
And in fact, you can even set it up so that the session itself
gets logged CloudWatch logs. And from a network perspective
that EC2 instance, no, he no longer needs a direct
network path to the EC2 instance, because the EC2 instance
is running an SSM agent that is that has an open tunnel
to the SSM service technically called SSM messages and EC2 messages,
these have VPC endpoints, so you don't need any internet
connectivity at all to be able to get to them. And that's how we connect
to this instance. So, this is from both a control
and visibility perspective, this is strictly better,
you're now controlling who has access to these instances
on the basis of IAM. And in case you're wondering,
well, why is he even talking about like SSH access to you know,
shouldn't we be taking operators away from direct access to these machines,
and I agree, and that's true. SSM also offers functionality
called documents. These documents, it's kind of
what it sounds like. They're these pre canned
sort of operational scripts that you can set up in advance, they are AWS resources
controlled by IAM so you can give Fred permission
to this document on this instance, but not that document
on that instance. And so, if you know once you are
at the operational excellence stage where you're doing
all of your operations via these pre
canned pre-approved steps, you can move to that and it has
all of those same properties. Final tip here, DNS logging,
though for quite some time, most of you use the EC, most of you use the DNS provided
natively by EC2 in your VPC, you have the option to override that
and do your own DNS in VPC, but most of you are using
the DNS provided by EC2. Used to be called EC2 DNS,
we now call that route 53 resolver. If you look at how
your DNS resolution works; it's your DNS is going to the dot
two address at the base
of your VPC address range. There's a lot, for quite a while
there's a lot you can do with this resolver for example, set up private hosted zones
to get DNS working the way you want a relatively
newer arrival on the scene. That's very useful. Both for security
and as a builder for troubleshooting, debugging,
understanding dependencies, DNS logging, very simple to turn on. You tell route 53,
you'd like to turn it on. You tell them where you'd like them
to put your logs. It could be S3, CloudWatch logs,
kinesis firehose, depending on how you plan
to analyze them. And what you get is you get
a record of the DNS queries that happened from your network. This gives you great visibility
into what's going on in your network. So, you can see here from this log,
somebody queried turtles.org, that is a website
dedicated to marine wildlife. Tells me what private address and
the VPC tells me what instance ID, not showing you here but you also
get ports and information on the answer that was received
and of course what this information, you know, of course
from a security perspective, I can know what kind of
outbound calls are being made but even just from
an operator perspective, I'd like to know
what the dependencies are, and this is a really great
source of truth for that. All right. Ten pro tips. I hope there was something on here
that you hadn't seen before. Gives you something that,
gives you a thread you can pull on, something you can learn a little bit
more about in this re:Invent season. So, I hope you learned something new
and have a great rest of your re:Invent
and happy building.
