1

00:00:03,310  -->  00:00:08,480
welcome back to Backspace Academy in
this lecture I'm going to run through

2

00:00:08,480  -->  00:00:15,529
data security we've already gone through
I am and VPC networking the security

3

00:00:15,529  -->  00:00:21,259
issues around that we're going to look
now at actually data security and how we

4

00:00:21,259  -->  00:00:26,150
ensure that our data is secure at rest
when it's stored and in transit when

5

00:00:26,150  -->  00:00:31,460
we're communicating over the Internet so
we'll look at the AWS compliance program

6

00:00:31,460  -->  00:00:38,390
and how AWS is compliant with certain
standards and how we can actually launch

7

00:00:38,390  -->  00:00:42,760
applications or deploy applications that
will be compliant with certain standards

8

00:00:42,760  -->  00:00:49,399
we'll also look at monitoring and
protection in relation to security we'll

9

00:00:49,399  -->  00:00:52,670
look at the different types of
credentials that we have and that we

10

00:00:52,670  -->  00:00:59,210
need to secure we'll look at storage and
managing encryption keys and then we'll

11

00:00:59,210  -->  00:01:07,460
look at protecting our data at rest and
in transit so the AWS compliant program

12

00:01:07,460  -->  00:01:13,040
AWS is compliant with a number of
standards which we have listed them but

13

00:01:13,040  -->  00:01:19,850
it also allows clients to deploy
solutions that meet other standards so

14

00:01:19,850  -->  00:01:22,760
for example there we've got the HIPAA
standard the Health Insurance

15

00:01:22,760  -->  00:01:30,170
Portability and Accountability Act AWS
isn't actually compliant with that

16

00:01:30,170  -->  00:01:35,480
because there is no compliance
specification for infrastructure in

17

00:01:35,480  -->  00:01:44,020
regards to HIPAA but AWS does allow you
to by using AWS it does allow you to

18

00:01:44,020  -->  00:01:49,250
deploy solutions or deploy applications
that are HIPAA compliant so although

19

00:01:49,250  -->  00:01:54,500
there is no actual compliance program
for a cloud infrastructure that is

20

00:01:54,500  -->  00:02:01,880
specified by HIPAA AWS does allow you to
deploy solutions that meet HIPAA and

21

00:02:01,880  -->  00:02:05,870
that's a difference between a device
been compliant with the actual standard

22

00:02:05,870  -->  00:02:13,629
and having AWS as a means for achieving
a standard

23

00:02:14,630  -->  00:02:22,340
AWS monitoring and protection now we've
already gone through in previous

24

00:02:22,340  -->  00:02:27,160
lectures we've gone through cloud watch
and implementing alarms for certain

25

00:02:27,160  -->  00:02:35,210
situations but out of us itself also
provides monitoring and protection as

26

00:02:35,210  -->  00:02:40,130
part of that shared responsibility they
have a responsibility and they take that

27

00:02:40,130  -->  00:02:46,570
seriously to monitor and protect the
infrastructure so AWS monitors for

28

00:02:46,570  -->  00:02:52,130
server and network usage if there's any
unusual activity going on there it will

29

00:02:52,130  -->  00:02:59,180
monitor for port scanning activities it
will monitor application usage and it

30

00:02:59,180  -->  00:03:05,330
will also monitor for unauthorized
intrusion attempts so other URLs

31

00:03:05,330  -->  00:03:11,210
provides protection against distributed
distributed denial of service or DDoS

32

00:03:11,210  -->  00:03:17,660
attacks man-in-the-middle attacks IP
spoofing port scanning now if you would

33

00:03:17,660  -->  00:03:24,530
like to do penetration testing then you
need to contact AWS to allow you to do

34

00:03:24,530  -->  00:03:29,270
that penetration testing otherwise they
will they will see that as being an

35

00:03:29,270  -->  00:03:34,460
attack on your infrastructure they also
provide protection against packet

36

00:03:34,460  -->  00:03:44,720
sniffing by other tenants so we have a
number of AWS credentials and different

37

00:03:44,720  -->  00:03:51,920
types that are required to access and
use the AWS services subtly the first

38

00:03:51,920  -->  00:03:57,410
one is going to be our password for our
to access to our AWS management console

39

00:03:57,410  -->  00:04:04,130
and we can also attach multi-factor
authentication to that now multi-factor

40

00:04:04,130  -->  00:04:09,050
authentication can also be detailed in
our a in policies and it supports

41

00:04:09,050  -->  00:04:16,340
hardware tokens and virtual MFA device
applications and it conforms to RFC

42

00:04:16,340  -->  00:04:23,170
6238 standard for time-based at one
time password

43

00:04:23,380  -->  00:04:29,710
we also have access keys and they are
used for digitally signing requests to

44

00:04:29,710  -->  00:04:38,650
AWS API so that could be request to the
AWS or using the AWS software

45

00:04:38,650  -->  00:04:44,650
development kits the command-line
interface or directly using the API for

46

00:04:44,650  -->  00:04:51,010
REST Web Services requests and it's a
signature that is calculated using the

47

00:04:51,010  -->  00:04:59,470
HMAC sha-256 protocol we also have key
pairs and their use with our ec2

48

00:04:59,470  -->  00:05:04,420
instances so we create public and
private key pairs for signing into our

49

00:05:04,420  -->  00:05:13,540
ec2 instances via SSH we also have x.509
certificates and then mainly use for

50

00:05:13,540  -->  00:05:21,160
site based requests so the AWS API is a
rest Web Services API so you wouldn't be

51

00:05:21,160  -->  00:05:26,170
using it for that but there are some
services for example certain services

52

00:05:26,170  -->  00:05:38,220
within s3 that that can take advantage
of x.509 certificates it is one thing to

53

00:05:38,220  -->  00:05:44,890
encrypt data but you also need to make
sure that your encryption keys are

54

00:05:44,890  -->  00:05:49,870
stored and managed securely otherwise
you defeat the purpose of encrypting

55

00:05:49,870  -->  00:05:54,990
that data so you can use your own key
management processes or you can use AWS

56

00:05:54,990  -->  00:06:00,760
server-side encryption your keys should
be stored securely

57

00:06:00,760  -->  00:06:10,060
in hardware security modules AWS to also
provide the AWS cloud HSM service which

58

00:06:10,060  -->  00:06:18,010
is a cloud-based HSM or you can use on
premise of storage and access those keys

59

00:06:18,010  -->  00:06:25,320
via and IPSec VPN but you need to make
sure those encryption keys are secure

60

00:06:25,320  -->  00:06:31,840
AWS also provides a very good key
management service see AWS kms and that

61

00:06:31,840  -->  00:06:36,409
can create and at the same time secure
those encryption key

62

00:06:36,409  -->  00:06:43,639
for you protecting data at rest or
protecting data when it is being stored

63

00:06:43,639  -->  00:06:50,300
I'm just going to quickly go through the
main AWS services and what it's built

64

00:06:50,300  -->  00:06:55,729
into those services for protecting data
at rest and what additional options we

65

00:06:55,729  -->  00:07:00,889
can use for further protecting that data
at rest so the Amazon s3 service

66

00:07:00,889  -->  00:07:06,349
obviously has bucket policies
it also has I am policies that we can

67

00:07:06,349  -->  00:07:11,959
implement for permissions at the bucket
level we can also look at protecting at

68

00:07:11,959  -->  00:07:16,550
the object level through access control
lists we can look at implementing

69

00:07:16,550  -->  00:07:24,499
versioning or enabling versioning on our
buckets and also Amazon s3 as we know

70

00:07:24,499  -->  00:07:30,079
has a high degree of replication so it's
highly available and it's highly durable

71

00:07:30,079  -->  00:07:36,979
so that is built into Amazon s3 and
there is also server-side encryption

72

00:07:36,979  -->  00:07:46,039
available for Amazon s3 to aes-256
additional to that we can look at doing

73

00:07:46,039  -->  00:07:50,179
client-side encryption so making sure
that on our side of things that we

74

00:07:50,179  -->  00:07:56,269
encrypt out before it goes to Amazon s3
before it goes to a bucket and we can

75

00:07:56,269  -->  00:08:01,819
also look at backup software additional
- - what is available if we would like

76

00:08:01,819  -->  00:08:09,039
to have our service backed up in another
region or off-site or whatever

77

00:08:09,039  -->  00:08:15,800
EBS has replication built into it so
there are two copies of an EBS volume

78

00:08:15,800  -->  00:08:22,009
within an availability zone that is not
cross region so there is replication

79

00:08:22,009  -->  00:08:26,839
within an availability zone so if a
region goes down you will still lose

80

00:08:26,839  -->  00:08:33,379
that data we also have iedf snapshots -
Amazon s3 and we have a number of

81

00:08:33,379  -->  00:08:38,990
encryption options available for us
depending on whether we're using Linux

82

00:08:38,990  -->  00:08:43,699
or Windows so with windows we have EFS
or BitLocker available to us and with

83

00:08:43,699  -->  00:08:49,460
Linux we have DM crypt available
built-in we can also

84

00:08:49,460  -->  00:08:55,460
look at block-level cross region
replications so in the event that we

85

00:08:55,460  -->  00:09:01,490
want to have availability even if we
have an entire region go out then we

86

00:09:01,490  -->  00:09:05,390
need to look at our own solution to do
that through our application or through

87

00:09:05,390  -->  00:09:13,160
our own solution to do brock level
replication to another region we have a

88

00:09:13,160  -->  00:09:17,060
number of other options available for
encryption as well from third parties

89

00:09:17,060  -->  00:09:25,340
that includes TrueCrypt and SafeNet
protectively RDS has automated backups

90

00:09:25,340  -->  00:09:30,350
to s3 and DB snapshots to back to to
Amazon s3 as we know from our RDS

91

00:09:30,350  -->  00:09:36,620
lecture those DBS snapshots will not be
deleted if they manually implement it

92

00:09:36,620  -->  00:09:41,780
that will not be deleted upon
termination of that RDS instance and we

93

00:09:41,780  -->  00:09:46,040
have a number of encryption options
available to us depending on what the

94

00:09:46,040  -->  00:09:51,080
database we are actually using so with
Oracle we can have the Oracle

95

00:09:51,080  -->  00:09:56,960
transparent data encryption service and
that is available to us if we bring our

96

00:09:56,960  -->  00:10:02,510
own license across to Amazon Web
Services we also have transact SQL for

97

00:10:02,510  -->  00:10:08,030
sequel server instances we can also look
at application level encryption so

98

00:10:08,030  -->  00:10:12,910
making our applique our application
responsible for the encryption of data

99

00:10:12,910  -->  00:10:20,170
Glacia by default has server-side
encryption to aes-256

100

00:10:20,170  -->  00:10:26,150
dynamodb doesn't necessarily have
automated backups as such but we can

101

00:10:26,150  -->  00:10:33,080
always export a table to Amazon s3 and
we can also look at using the dynamodb

102

00:10:33,080  -->  00:10:39,680
cross region replication library to
replicate to a different replicated data

103

00:10:39,680  -->  00:10:47,210
to a another region we can also look at
the Amazon data pipeline and that will

104

00:10:47,210  -->  00:10:54,770
create an EMR cluster that will export
or will backup data to Amazon s3 force

105

00:10:54,770  -->  00:10:59,720
and we can also again look at
application level encryption and elect

106

00:10:59,720  -->  00:11:05,870
it elastic MapReduce so our data that he
used by elastic MapReduce in Amazon s3

107

00:11:05,870  -->  00:11:10,670
we can have server-side encryption on
that and we can also look at application

108

00:11:10,670  -->  00:11:17,480
level encryption for that when
communicating with our AWS services we

109

00:11:17,480  -->  00:11:23,120
also need to make sure that if that
communication is intercepted that our

110

00:11:23,120  -->  00:11:28,130
data is also secure so making sure that
our data is protected while it is in

111

00:11:28,130  -->  00:11:33,230
transit with our general internet
communication we obviously have built in

112

00:11:33,230  -->  00:11:39,680
our VPN we have SSL we also have SSH
that we use when we're communicating

113

00:11:39,680  -->  00:11:45,260
with our Linux ec2 instances and we have
RDP when we're communicating with our

114

00:11:45,260  -->  00:11:51,290
Windows ec2 instances additional to that
if we are looking for protection against

115

00:11:51,290  -->  00:11:57,050
peer identity compromised for identity
spoofing or man-in-the-middle attacks we

116

00:11:57,050  -->  00:12:03,470
can use IPSec with internet key exchange
with pre-shared keys we can use x.509

117

00:12:03,470  -->  00:12:08,899
certificates for verification of
identity and we can use ssl with service

118

00:12:08,899  -->  00:12:14,120
certificate authentication based on the
server common name or alternative name

119

00:12:14,120  -->  00:12:21,950
for Amazon s3 RDS and dynamo DB and for
elastic MapReduce communication with

120

00:12:21,950  -->  00:12:30,350
that with those services is through HTTP
and we also as with any ec2 instance

121

00:12:30,350  -->  00:12:35,450
when we're communicating with an EMR
cluster or our Hadoop cluster on the

122

00:12:35,450  -->  00:12:42,620
elastic MapReduce service communication
with that will be through SSH so that is

123

00:12:42,620  -->  00:12:51,320
how we protect our data both in transit
and at rest and I will see you in the

124

00:12:51,320  -->  00:12:53,950
next lesson