WEBVTT

1
00:00:00.000 --> 00:00:02.400
In this lesson, we will learn

2
00:00:02.400 --> 00:00:05.940
about Cloud Security Considerations.

3
00:00:05.940 --> 00:00:10.290
Cloud Security Considerations involve addressing risks

4
00:00:10.290 --> 00:00:12.975
and vulnerabilities to protect data

5
00:00:12.975 --> 00:00:17.220
and resources within cloud environments.

6
00:00:17.220 --> 00:00:20.064
Cloud Security Considerations include

7
00:00:20.064 --> 00:00:25.064
Insecure storage resources, data exposure, data leakage,

8
00:00:25.517 --> 00:00:27.690
and data remanence.

9
00:00:27.690 --> 00:00:32.690
Insecure storage resources refer to cloud storage

10
00:00:32.700 --> 00:00:35.942
that lacks proper security configurations, such

11
00:00:35.942 --> 00:00:39.870
as encryption or access controls.

12
00:00:39.870 --> 00:00:44.220
Data Exposure occurs when sensitive information is

13
00:00:44.220 --> 00:00:49.220
unintentionally made accessible to unauthorized users.

14
00:00:49.290 --> 00:00:51.926
It is often due to misconfigurations

15
00:00:51.926 --> 00:00:55.440
or inadequate security measures.

16
00:00:55.440 --> 00:01:00.210
Next Data Leakage refers to the unauthorized transmission

17
00:01:00.210 --> 00:01:03.450
of data from within the cloud environment

18
00:01:03.450 --> 00:01:06.690
to external parties, which can happen

19
00:01:06.690 --> 00:01:10.710
through insecure channels or compromised accounts.

20
00:01:10.710 --> 00:01:14.580
Finally, data remanence is the residual data

21
00:01:14.580 --> 00:01:16.920
that remains on storage devices

22
00:01:16.920 --> 00:01:21.360
after deletion, which can be maliciously recovered,

23
00:01:21.360 --> 00:01:24.000
if not properly sanitized.

24
00:01:24.000 --> 00:01:28.440
Let's learn more about insecure storage resources

25
00:01:28.440 --> 00:01:33.440
and Data Exposure, Data Leakage and data remanence.

26
00:01:33.630 --> 00:01:37.830
First, we have Unsecured Storage Resources.

27
00:01:37.830 --> 00:01:41.550
There are many ways to store data in the cloud,

28
00:01:41.550 --> 00:01:45.900
but the most commonly misconfigured storage resources are

29
00:01:45.900 --> 00:01:48.060
buckets and blobs.

30
00:01:48.060 --> 00:01:52.140
Buckets and blobs essentially function the same way,

31
00:01:52.140 --> 00:01:56.370
but the name that is used depends on the cloud provider.

32
00:01:56.370 --> 00:01:59.700
For example, in Amazon Web Services

33
00:01:59.700 --> 00:02:04.110
or AWS storage containers are called buckets.

34
00:02:04.110 --> 00:02:08.070
While in Microsoft Azure, they're known as blobs.

35
00:02:08.070 --> 00:02:10.950
Regardless of the name, both are used

36
00:02:10.950 --> 00:02:14.190
to store files and data in the cloud.

37
00:02:14.190 --> 00:02:17.281
When you store a file into the cloud, it goes into one

38
00:02:17.281 --> 00:02:20.070
of these types of containers.

39
00:02:20.070 --> 00:02:22.500
These containers can be located

40
00:02:22.500 --> 00:02:25.143
in different geographic regions, such

41
00:02:25.143 --> 00:02:29.160
as the East Coast, West Coast, Europe,

42
00:02:29.160 --> 00:02:33.300
or Asia, depending upon your chosen data center

43
00:02:33.300 --> 00:02:35.910
at the time of storage setup.

44
00:02:35.910 --> 00:02:39.360
However, unlike your personal computer

45
00:02:39.360 --> 00:02:41.580
where you can nest folders inside

46
00:02:41.580 --> 00:02:45.660
of each other, you cannot nest containers in the cloud.

47
00:02:45.660 --> 00:02:47.660
This means that each container hosts

48
00:02:47.660 --> 00:02:51.240
its own data objects or files.

49
00:02:51.240 --> 00:02:53.550
Once a container is created,

50
00:02:53.550 --> 00:02:57.450
configuring access control is the next step,

51
00:02:57.450 --> 00:03:01.410
and this is where can occur.

52
00:03:01.410 --> 00:03:04.364
Access control for storage containers is managed

53
00:03:04.364 --> 00:03:09.364
through three key components, the container's policies,

54
00:03:09.540 --> 00:03:14.400
Identity and Access Management, or IAM authorizations

55
00:03:14.400 --> 00:03:18.780
and object access control lists or ACLs.

56
00:03:18.780 --> 00:03:21.960
When these elements are configured properly,

57
00:03:21.960 --> 00:03:24.360
they provide strong security,

58
00:03:24.360 --> 00:03:28.710
but misconfigurations can leave the data exposed.

59
00:03:28.710 --> 00:03:31.680
For example, a common issue is

60
00:03:31.680 --> 00:03:34.624
that newly created storage containers may come

61
00:03:34.624 --> 00:03:38.520
with default read and write access,

62
00:03:38.520 --> 00:03:42.030
which can leave them more open than intended.

63
00:03:42.030 --> 00:03:46.358
So it's important to update these default settings to align

64
00:03:46.358 --> 00:03:49.200
with your security needs.

65
00:03:49.200 --> 00:03:52.024
Additionally, misconfigurations can occur

66
00:03:52.024 --> 00:03:56.670
in origin settings, which determine the source location

67
00:03:56.670 --> 00:03:59.310
from which the data is retrieved

68
00:03:59.310 --> 00:04:01.830
and how that data is distributed

69
00:04:01.830 --> 00:04:04.380
through a content delivery network

70
00:04:04.380 --> 00:04:07.830
or CDN to end users.

71
00:04:07.830 --> 00:04:10.770
If these origin settings are incorrect,

72
00:04:10.770 --> 00:04:15.420
data could be unintentionally shared across the CDN

73
00:04:15.420 --> 00:04:18.210
to unintended locations.

74
00:04:18.210 --> 00:04:22.680
Moreover, when data is shared across different domains,

75
00:04:22.680 --> 00:04:27.680
Cross-origin Resource Sharing or CORS policies

76
00:04:28.313 --> 00:04:32.438
are used to control how resources are shared between

77
00:04:32.438 --> 00:04:34.020
these domains.

78
00:04:34.020 --> 00:04:38.460
Improper CORS configurations can expose

79
00:04:38.460 --> 00:04:41.876
your storage resources to security risks, such

80
00:04:41.876 --> 00:04:45.360
as cross site scripting attacks.

81
00:04:45.360 --> 00:04:49.140
Therefore, always double check these settings

82
00:04:49.140 --> 00:04:53.370
to ensure your data is securely stored and shared.

83
00:04:53.370 --> 00:04:56.550
Second, we have Data Exposure.

84
00:04:56.550 --> 00:05:00.450
Data Exposure occurs when sensitive information is

85
00:05:00.450 --> 00:05:05.310
accidentally made accessible to unauthorized users.

86
00:05:05.310 --> 00:05:08.730
Typically because of poor security practices

87
00:05:08.730 --> 00:05:11.070
or misconfigurations.

88
00:05:11.070 --> 00:05:13.922
This can happen when cloud storage resources

89
00:05:13.922 --> 00:05:16.920
like buckets or blobs are set

90
00:05:16.920 --> 00:05:21.060
with incorrect access permissions, allowing the public

91
00:05:21.060 --> 00:05:25.830
or untrusted parties to access confidential data.

92
00:05:25.830 --> 00:05:29.820
For example, if a company's customer database is stored

93
00:05:29.820 --> 00:05:34.820
in a cloud container and is mistakenly set to public, anyone

94
00:05:35.009 --> 00:05:40.009
with the URL could access the database exposing sensitive

95
00:05:40.031 --> 00:05:44.520
personal information, such as names, addresses,

96
00:05:44.520 --> 00:05:46.560
or financial details.

97
00:05:46.560 --> 00:05:51.560
Data exposure can also occur through weak access controls.

98
00:05:51.840 --> 00:05:53.008
If proper identity

99
00:05:53.008 --> 00:05:57.180
and access management policies are not enforced,

100
00:05:57.180 --> 00:06:01.890
unauthorized users may gain access to sensitive information.

101
00:06:01.890 --> 00:06:05.310
For instance, if an employee has access

102
00:06:05.310 --> 00:06:07.620
to highly confidential data,

103
00:06:07.620 --> 00:06:11.310
but then leaves the organization without having their

104
00:06:11.310 --> 00:06:14.730
permissions revoked, they could still access

105
00:06:14.730 --> 00:06:16.470
that data remotely.

106
00:06:16.470 --> 00:06:20.130
This is why we should regularly audit permissions

107
00:06:20.130 --> 00:06:23.809
and ensure that only authorized users have the necessary

108
00:06:23.809 --> 00:06:27.840
level of access to sensitive information.

109
00:06:27.840 --> 00:06:32.430
One way to prevent data exposure is through encryption.

110
00:06:32.430 --> 00:06:36.720
That way, even if the data is accidentally exposed,

111
00:06:36.720 --> 00:06:40.110
encryption can prevent unauthorized users

112
00:06:40.110 --> 00:06:43.650
from being able to read or use the data.

113
00:06:43.650 --> 00:06:48.120
So ensuring that all sensitive data is encrypted both

114
00:06:48.120 --> 00:06:51.600
at rest, when in storage, and in transit

115
00:06:51.600 --> 00:06:56.340
between systems is an important security practice.

116
00:06:56.340 --> 00:07:00.000
Tools like AWS Key Management Service,

117
00:07:00.000 --> 00:07:05.000
Microsoft Azure Key Vault and encryption protocols, such

118
00:07:05.070 --> 00:07:09.360
as transport layer security, are essential for managing

119
00:07:09.360 --> 00:07:12.810
and automating this encryption process.

120
00:07:12.810 --> 00:07:16.050
Additionally, regular security audits

121
00:07:16.050 --> 00:07:19.710
and automated tools like AWS Config

122
00:07:19.710 --> 00:07:24.710
or Azure Security Center can help detect misconfigurations

123
00:07:24.810 --> 00:07:29.810
early before they lead to a major Data Exposure event.

124
00:07:30.300 --> 00:07:33.210
Third, we have Data Leakage.

125
00:07:33.210 --> 00:07:36.948
Data Leakage refers to the unauthorized transmission

126
00:07:36.948 --> 00:07:41.948
or transfer of sensitive data from within an organization

127
00:07:42.570 --> 00:07:46.020
to an external or untrusted party.

128
00:07:46.020 --> 00:07:49.290
This can happen through a variety of channels such

129
00:07:49.290 --> 00:07:54.290
as insecure email communications, cloud applications,

130
00:07:54.450 --> 00:07:56.460
or USB drives.

131
00:07:56.460 --> 00:08:00.810
For example, an employee may unknowingly send

132
00:08:00.810 --> 00:08:03.840
sensitive files like financial reports

133
00:08:03.840 --> 00:08:08.490
or customer information to an external email address

134
00:08:08.490 --> 00:08:13.490
without encrypting the content resulting in data leakage.

135
00:08:14.220 --> 00:08:18.270
In cloud environments using unauthorized applications

136
00:08:18.270 --> 00:08:22.110
or storage services can also lead to leakage

137
00:08:22.110 --> 00:08:26.070
if proper security controls are not in place.

138
00:08:26.070 --> 00:08:29.130
Data Leakage is particularly concerning

139
00:08:29.130 --> 00:08:31.980
because it often goes unnoticed.

140
00:08:31.980 --> 00:08:36.090
For instance, if an employee syncs sensitive files

141
00:08:36.090 --> 00:08:39.060
to an unapproved cloud storage service

142
00:08:39.060 --> 00:08:43.020
like a personal Dropbox or Google Drive account,

143
00:08:43.020 --> 00:08:48.020
the data could be exposed to risks including theft or loss.

144
00:08:48.391 --> 00:08:51.630
IT departments may not even be aware

145
00:08:51.630 --> 00:08:54.953
of this activity if they are not actively monitoring

146
00:08:54.953 --> 00:08:58.290
employee behavior, making it difficult

147
00:08:58.290 --> 00:09:01.320
to detect when sensitive data has left the

148
00:09:01.320 --> 00:09:03.360
organization's control.

149
00:09:03.360 --> 00:09:07.500
Preventing Data Leakage requires both technology

150
00:09:07.500 --> 00:09:09.090
and policy.

151
00:09:09.090 --> 00:09:12.605
Data Loss prevention tools can be implemented to monitor

152
00:09:12.605 --> 00:09:14.520
and control the movement

153
00:09:14.520 --> 00:09:18.210
of sensitive data within the organization,

154
00:09:18.210 --> 00:09:22.260
ensuring it doesn't leave through insecure channels.

155
00:09:22.260 --> 00:09:24.450
Additionally, clear policies

156
00:09:24.450 --> 00:09:27.660
and training for employees regarding the use

157
00:09:27.660 --> 00:09:30.840
of personal devices, cloud services,

158
00:09:30.840 --> 00:09:34.555
and email communication can help reduce the risk

159
00:09:34.555 --> 00:09:36.690
of data leakage.

160
00:09:36.690 --> 00:09:40.770
Fourth and last, we have data remanence.

161
00:09:40.770 --> 00:09:44.040
Data remanence refers to residual data

162
00:09:44.040 --> 00:09:46.372
that remains on storage media even

163
00:09:46.372 --> 00:09:50.610
after it has been deleted or erased.

164
00:09:50.610 --> 00:09:53.910
This residual data can be recovered

165
00:09:53.910 --> 00:09:57.510
if proper deletion techniques aren't used.

166
00:09:57.510 --> 00:10:01.170
Presenting a significant security risk.

167
00:10:01.170 --> 00:10:05.196
For instance, when a company retires a cloud storage

168
00:10:05.196 --> 00:10:09.360
instance but fails to fully wipe the data stored

169
00:10:09.360 --> 00:10:13.560
in the containers, fragments of sensitive information

170
00:10:13.560 --> 00:10:17.325
might remain accessible and could be recovered by someone

171
00:10:17.325 --> 00:10:21.090
with the right tools and expertise.

172
00:10:21.090 --> 00:10:23.604
This could lead to unauthorized access

173
00:10:23.604 --> 00:10:26.239
to confidential information even

174
00:10:26.239 --> 00:10:30.360
after the data was thought to be erased.

175
00:10:30.360 --> 00:10:32.070
In cloud environments,

176
00:10:32.070 --> 00:10:36.119
data remanence becomes a concern when organizations move

177
00:10:36.119 --> 00:10:41.119
or delete virtual machines, containers, or volumes.

178
00:10:41.250 --> 00:10:45.330
If the storage devices are not properly sanitized

179
00:10:45.330 --> 00:10:48.571
or if the cloud provider does not follow strict data

180
00:10:48.571 --> 00:10:50.880
destruction protocols,

181
00:10:50.880 --> 00:10:55.880
sensitive information could still exist in residual form.

182
00:10:55.950 --> 00:10:57.880
This could happen, for example,

183
00:10:57.880 --> 00:11:00.913
if a cloud provider reuses hardware

184
00:11:00.913 --> 00:11:02.910
that hasn't been fully wiped

185
00:11:02.910 --> 00:11:07.910
after one client stops using it, potentially exposing data

186
00:11:08.280 --> 00:11:12.210
to a future client who uses the same hardware.

187
00:11:12.210 --> 00:11:16.020
So to mitigate the risk of data remanence,

188
00:11:16.020 --> 00:11:19.822
organizations should use secure deletion methods such

189
00:11:19.822 --> 00:11:24.304
as cryptographic erasure or physical destruction

190
00:11:24.304 --> 00:11:29.304
of storage devices to ensure that no residual data remains.

191
00:11:30.330 --> 00:11:33.701
When using cloud services, it's essential to confirm

192
00:11:33.701 --> 00:11:37.544
that the cloud provider follows industry standard data

193
00:11:37.544 --> 00:11:39.870
destruction practices

194
00:11:39.870 --> 00:11:41.978
by ensuring data is securely erased

195
00:11:41.978 --> 00:11:46.029
from all storage, media organizations can prevent

196
00:11:46.029 --> 00:11:50.279
unauthorized access to sensitive information even

197
00:11:50.279 --> 00:11:54.750
after the data is no longer active use.

198
00:11:54.750 --> 00:11:59.130
So remember, insecured storage resources,

199
00:11:59.130 --> 00:12:01.980
data exposure, data leakage,

200
00:12:01.980 --> 00:12:04.124
and data remanence are concerns

201
00:12:04.124 --> 00:12:07.080
that organizations must address

202
00:12:07.080 --> 00:12:09.300
to protect sensitive information.

203
00:12:09.300 --> 00:12:13.680
Insecured storage resources occur when cloud storage

204
00:12:13.680 --> 00:12:15.420
containers like buckets

205
00:12:15.420 --> 00:12:18.660
or blobs are not properly configured

206
00:12:18.660 --> 00:12:20.790
with the right access controls

207
00:12:20.790 --> 00:12:24.060
or encryption, leading data vulnerable

208
00:12:24.060 --> 00:12:26.490
to unauthorized access.

209
00:12:26.490 --> 00:12:30.038
Next, data exposure occurs when sensitive data is

210
00:12:30.038 --> 00:12:35.038
accidentally made accessible to unauthorized users due

211
00:12:35.181 --> 00:12:40.181
to misconfigurations or inadequate security measures.

212
00:12:40.410 --> 00:12:43.680
This can lead to unauthorized access

213
00:12:43.680 --> 00:12:46.530
and compromised confidential data.

214
00:12:46.530 --> 00:12:48.512
Next, Data Leakage refers

215
00:12:48.512 --> 00:12:51.570
to the unauthorized transmission

216
00:12:51.570 --> 00:12:55.920
of sensitive information from within the organization

217
00:12:55.920 --> 00:12:58.050
to external parties.

218
00:12:58.050 --> 00:13:00.720
Often through insecure channels

219
00:13:00.720 --> 00:13:03.600
or unauthorized cloud services.

220
00:13:03.600 --> 00:13:05.913
This can go unnoticed for long periods

221
00:13:05.913 --> 00:13:10.913
of time, increasing the risk of data theft or loss.

222
00:13:11.460 --> 00:13:15.600
Last, data remanence involves residual data

223
00:13:15.600 --> 00:13:18.286
that remains on storage devices even

224
00:13:18.286 --> 00:13:21.690
after deletion, posing a risk

225
00:13:21.690 --> 00:13:25.860
if proper erasure techniques are not used.

226
00:13:25.860 --> 00:13:28.290
So preventing data remanence

227
00:13:28.290 --> 00:13:32.040
requires secure deletion practices to ensure

228
00:13:32.040 --> 00:13:35.730
that no data fragments remain accessible

229
00:13:35.730 --> 00:13:39.963
after storage resources are no longer in use.

