1
00:00:06,700 --> 00:00:08,940
- Now let's take a look
at bucket security with

2
00:00:08,940 --> 00:00:11,640
resource policies and ACLs.

3
00:00:11,640 --> 00:00:15,410
Many resources in AWS
support, what we would call,

4
00:00:15,410 --> 00:00:17,830
resource based policies.

5
00:00:17,830 --> 00:00:21,840
Earlier in this series, we talked about

6
00:00:22,790 --> 00:00:24,400
policies within IAM.

7
00:00:24,400 --> 00:00:27,920
Policies that grant permissions to access,

8
00:00:27,920 --> 00:00:31,220
perform certain actions
on certain resources.

9
00:00:31,220 --> 00:00:33,710
Policies like that, in
many cases, can and should

10
00:00:33,710 --> 00:00:36,850
be applied to users and
groups but in other cases

11
00:00:36,850 --> 00:00:40,890
we may want to apply or
need to apply the policy

12
00:00:40,890 --> 00:00:43,310
directly to the resource.

13
00:00:43,310 --> 00:00:46,590
Here is an example where
we are applying a policy

14
00:00:46,590 --> 00:00:49,410
directly to an S3 bucket.

15
00:00:49,410 --> 00:00:52,690
And the reason that we're
applying the policy to the bucket,

16
00:00:52,690 --> 00:00:56,610
in this particular case, is
because if we notice here.

17
00:00:56,610 --> 00:00:58,360
If we take a look at the principle.

18
00:00:59,490 --> 00:01:02,230
The principle you'll see is,

19
00:01:02,230 --> 00:01:05,250
in this particular case, an asterisk.

20
00:01:05,250 --> 00:01:07,820
And the asterisk, in this case,

21
00:01:07,820 --> 00:01:12,820
means that we are allowing
anyone and everyone,

22
00:01:13,300 --> 00:01:18,300
even people who don't
have an account with AWS.

23
00:01:18,300 --> 00:01:19,730
Even anonymous users.

24
00:01:19,730 --> 00:01:21,700
People who are not authenticated.

25
00:01:21,700 --> 00:01:26,700
So, by placing an asterisk here,

26
00:01:26,960 --> 00:01:29,760
we are essentially enabling this bucket

27
00:01:29,760 --> 00:01:32,180
to be read by the public.

28
00:01:32,180 --> 00:01:33,730
Anonymous users.

29
00:01:33,730 --> 00:01:35,700
What we're saying here
is that, essentially

30
00:01:35,700 --> 00:01:40,700
asterisks, anyone and everyone
is allowed to download

31
00:01:41,480 --> 00:01:46,480
using the S3 GetObject
action from anywhere

32
00:01:47,870 --> 00:01:50,410
in this particular bucket.

33
00:01:50,410 --> 00:01:53,290
This bucket being cerulean.systems.

34
00:01:53,290 --> 00:01:57,210
In this particular case, if
you were to visit that domain,

35
00:01:57,210 --> 00:02:01,330
cerulean.systems then
you would see a website

36
00:02:01,330 --> 00:02:03,130
and it would be static content.

37
00:02:03,130 --> 00:02:06,790
A static website being served directly

38
00:02:06,790 --> 00:02:09,024
from that particular bucket.

39
00:02:09,024 --> 00:02:11,850
We can do a number of different things

40
00:02:11,850 --> 00:02:13,440
with resource policies.

41
00:02:13,440 --> 00:02:16,640
Resource policies will also allow us

42
00:02:16,640 --> 00:02:20,470
to share buckets between
different accounts.

43
00:02:20,470 --> 00:02:24,030
In this example, you'll notice that

44
00:02:24,030 --> 00:02:26,849
we are specifying again the principle.

45
00:02:26,849 --> 00:02:31,849
But we are saying, using the AWS key here,

46
00:02:32,680 --> 00:02:35,490
we're saying that we want
to share this account

47
00:02:35,490 --> 00:02:39,500
or at least allow these particular actions

48
00:02:39,500 --> 00:02:42,290
with this particular account.

49
00:02:42,290 --> 00:02:45,173
So we're specifying this
particular account number.

50
00:02:47,689 --> 00:02:51,920
This particular action,
the S3 PutObject action,

51
00:02:51,920 --> 00:02:55,650
is then essentially
delegated to that account.

52
00:02:55,650 --> 00:02:57,223
To the root of that account.

53
00:02:58,320 --> 00:03:01,640
The root user of that account can then

54
00:03:01,640 --> 00:03:06,344
further delegate that
permission to their users.

55
00:03:06,344 --> 00:03:08,350
Essentially, what we're
saying here is this

56
00:03:08,350 --> 00:03:13,350
some other account is allowed to upload,

57
00:03:13,650 --> 00:03:18,650
perform the S3 PutObject
action to anywhere

58
00:03:18,890 --> 00:03:21,030
in this particular bucket.

59
00:03:21,030 --> 00:03:25,240
Resource based policies allow
us to do several key things.

60
00:03:25,240 --> 00:03:29,350
One, either generally making
them publicly accessible

61
00:03:29,350 --> 00:03:31,730
or sharing them with another account.

62
00:03:31,730 --> 00:03:36,730
S3 is one example of
resource based policy usage.

63
00:03:37,170 --> 00:03:40,130
Simple Queue Service
and other resources also

64
00:03:40,130 --> 00:03:42,543
support resource based policies.

65
00:03:43,460 --> 00:03:46,080
Another thing that we can do with S3,

66
00:03:46,080 --> 00:03:50,470
in terms of making a bucket
or objects publicly readable

67
00:03:50,470 --> 00:03:52,770
or sharing or granting access,

68
00:03:52,770 --> 00:03:56,280
is either using a policy like we just saw.

69
00:03:56,280 --> 00:04:00,320
We can use a policy where
if we specify an asterisk

70
00:04:00,320 --> 00:04:04,240
for the principle then we are sharing that

71
00:04:04,240 --> 00:04:06,833
or granting access to anyone and everyone.

72
00:04:08,570 --> 00:04:10,670
Another way that we can grant access

73
00:04:10,670 --> 00:04:14,803
is by using ACLs or access control list.

74
00:04:15,746 --> 00:04:18,830
A resource based policy, a bucket policy

75
00:04:18,830 --> 00:04:21,580
allows us to be very, very fine-grained

76
00:04:21,580 --> 00:04:24,900
and specify conditions
and all kinds of things

77
00:04:24,900 --> 00:04:28,460
to really target the different actions

78
00:04:28,460 --> 00:04:32,410
and different resources
under different conditions.

79
00:04:32,410 --> 00:04:35,500
But ACLs are more core-screened.

80
00:04:35,500 --> 00:04:38,900
So, if we were to specify read operations

81
00:04:38,900 --> 00:04:42,410
or write operations, those
would actually end up

82
00:04:42,410 --> 00:04:46,010
including a number of different actions

83
00:04:46,010 --> 00:04:48,660
that we might specify in a policy.

84
00:04:48,660 --> 00:04:52,000
Personally, I prefer to use policies

85
00:04:52,000 --> 00:04:53,770
because they are fine-grained

86
00:04:53,770 --> 00:04:56,140
and I only generally use ACLs

87
00:04:56,140 --> 00:04:58,100
in very certain circumstances

88
00:04:58,100 --> 00:04:59,633
when that's the only option.

89
00:05:00,759 --> 00:05:04,380
In terms of making data publicly readable.

90
00:05:04,380 --> 00:05:07,430
I want to spend some time
here because over the last

91
00:05:07,430 --> 00:05:11,700
few years, a number of
organizations have gotten themselves

92
00:05:11,700 --> 00:05:16,390
in trouble by exposing
sensitive information in

93
00:05:16,390 --> 00:05:19,240
publicly available S3 buckets.

94
00:05:19,240 --> 00:05:23,750
I think, mainly, that comes
down to a lack of education

95
00:05:23,750 --> 00:05:26,170
and/or a lack of communication.

96
00:05:26,170 --> 00:05:31,170
That perhaps the person who
created or put that policy

97
00:05:31,590 --> 00:05:35,300
or ACL into place didn't
realize what they were doing

98
00:05:35,300 --> 00:05:39,810
or they did but didn't
communicate that was a

99
00:05:39,810 --> 00:05:43,783
publicly accessible bucket to
people who were writing data.

100
00:05:44,710 --> 00:05:48,000
As an organization, we need
to keep in mind that the

101
00:05:48,000 --> 00:05:50,760
security of our data
within these S3 buckets

102
00:05:50,760 --> 00:05:52,393
is our responsibility.

103
00:05:53,360 --> 00:05:57,810
The onus of knowing, the
consequences of using

104
00:05:57,810 --> 00:06:00,120
these kinds of things, is on us.

105
00:06:00,120 --> 00:06:02,250
We have to be aware of
these kinds of things

106
00:06:02,250 --> 00:06:05,360
and we have to educate
ourselves, educate our team

107
00:06:05,360 --> 00:06:08,660
and communicate that
this particular bucket

108
00:06:08,660 --> 00:06:11,860
is publicly accessible and it
should only be made that way

109
00:06:11,860 --> 00:06:14,192
if it needs to be that way.

110
00:06:14,192 --> 00:06:19,192
There are several canned
ACLs that we can use to make

111
00:06:19,387 --> 00:06:22,640
certain objects or
buckets publicly readable.

112
00:06:22,640 --> 00:06:26,066
One of them, as the name
suggests, public-read.

113
00:06:26,066 --> 00:06:28,260
That one's very straight forward.

114
00:06:28,260 --> 00:06:31,180
If you apply that ACL
to an object or a bucket

115
00:06:32,320 --> 00:06:35,160
it will be accessible by the public.

116
00:06:35,160 --> 00:06:37,240
Another one would be public-read-write.

117
00:06:37,240 --> 00:06:40,520
Meaning that now it's not
only readable by the public

118
00:06:40,520 --> 00:06:42,450
but it's also writable.

119
00:06:42,450 --> 00:06:43,800
That people can write to it.

120
00:06:43,800 --> 00:06:46,293
Anonymous users can write to that.

121
00:06:47,130 --> 00:06:51,760
Another one that is
perhaps, anti-intuitive,

122
00:06:51,760 --> 00:06:55,860
counter-intuitive, is
the authenticated-read.

123
00:06:55,860 --> 00:06:57,760
I want to draw your attention to this one

124
00:06:57,760 --> 00:07:01,360
and make sure that you remember this.

125
00:07:01,360 --> 00:07:03,330
If you take away anything, take away this.

126
00:07:03,330 --> 00:07:06,580
The authenticated-read ACL

127
00:07:07,980 --> 00:07:12,980
applies to anyone who
authenticates to the AWS API.

128
00:07:14,600 --> 00:07:18,763
Even those users outside
of your organization.

129
00:07:19,600 --> 00:07:22,530
Keep in mind that anyone in the world

130
00:07:22,530 --> 00:07:25,300
with a valid credit card can sign up

131
00:07:25,300 --> 00:07:27,400
for an AWS account.

132
00:07:27,400 --> 00:07:30,513
Even people with potentially
malicious intent.

133
00:07:35,360 --> 00:07:37,000
Some random person out there

134
00:07:37,000 --> 00:07:39,060
could sign up for an AWS account

135
00:07:39,060 --> 00:07:44,060
and if your data has the
ACL authenticated-read

136
00:07:44,570 --> 00:07:46,920
this person could access it.

137
00:07:46,920 --> 00:07:51,290
This is really one that I
would recommend avoiding.

138
00:07:51,290 --> 00:07:54,030
I'm really not sure
exactly why that's in there

139
00:07:54,030 --> 00:07:55,590
but I would recommend avoiding that.

140
00:07:55,590 --> 00:07:58,200
There are plenty of other ways to

141
00:08:01,700 --> 00:08:05,150
grant access to your
users rather than using

142
00:08:05,150 --> 00:08:08,078
the authenticated-read canned ACL.

143
00:08:08,078 --> 00:08:10,380
Those are some things to keep in mind

144
00:08:10,380 --> 00:08:14,170
as you move forward and
continue to work with S3.

145
00:08:14,170 --> 00:08:18,160
Keep in mind that the
security of that bucket

146
00:08:18,160 --> 00:08:21,130
is your responsibility
and you can leverage

147
00:08:21,130 --> 00:08:26,130
these kinds of things;
bucket-based policies and ACLs

148
00:08:26,530 --> 00:08:29,200
to help manage the
permissions of that bucket.

149
00:08:29,200 --> 00:08:32,660
When it comes to allowing
access to that bucket

150
00:08:32,660 --> 00:08:35,883
from the public or from other accounts.