Oracle DBAs understand securing data in transit and at rest, but they don't have to deal with file level encryption, security of the databases, firewalls, denial of service attacks, SQL injection attacks, and other OS level security.
General infrastructure security concepts:
1. Some networking concepts such as VPC, VPN, and IPSec also apply to the security realm. More on these concepts can be found here: http://cloudconclave.blogspot.com/2013/07/aws-network-101-for-oracle-dbas.html
1. SSL : The Secure Sockets Layer (SSL) is a commonly-used protocol
for managing the security of a message transmission on the Internet. SSL uses the public-and-private key encryption
system from RSA, which
also includes the use of a digital
certificate.
2. ACLs : Access Control Lists (ACLs) specifies which users or system processes are granted access to
objects, as well as what operations are allowed on given objects.
6. IDS : An intrusion detection system (IDS) is a device or software application
that monitors network or system activities for malicious activities or
policy violations and produces reports to a management station. Some
systems may attempt to stop an intrusion attempt but this is neither
required nor expected of a monitoring system.
7. IPS : Intrusion prevention systems (IPS), also known as intrusion detection and prevention systems (IDPS), are network security
appliances that monitor network and/or system activities for malicious
activity. The main functions of intrusion prevention systems are to
identify malicious activity, log information about this activity,
attempt to block/stop it, and report it. Intrusion prevention systems are considered extensions of intrusion detection systems because they both monitor network traffic and/or system activities for malicious activity.
8. DoS : A denial-of-service attack (DoS attack) or distributed denial-of-service attack (DDoS attack) is an attempt to make a machine or network resource unavailable to its intended users. IPS, iptables, AWS security groups, NACLs, and bastion hosts are all ways to prevent DoS attacks.
9. Penetration testing : A penetration test, occasionally pentest, is a method of evaluating computer and network security by simulating an attack on a computer system or network from external and internal threats.
AWS specifics. You must be familiar with all of these concepts in order to perform basic actions on AWS and EC2:
1. Access key and secret key : The access key is used to access AWS using the CLI and TEST API. The REST and Query APIs use your access keys as the credential.You might be using a third-party product such as S3Fox or ElasticWolf that requires your
access keys (because the product itself makes AWS requests for you). Although access keys are primarily used for REST or Query
APIs, Amazon S3 and Amazon Mechanical Turk also use access keys with their SOAP APIs. Your Access Key ID identifies you as the party
responsible for service requests. You include it in each request, so
it's not a secret.The secret key provide anyone that possesses them incredible power to perform delete, terminate, start etc actions on your AWS resources (EC2, ELB, S3 etc) so be very careful with them. Don't e-mail it to anyone, include it any AWS requests, or post it on
the AWS Discussion Forums. No authorized person from AWS will ever ask
for your Secret Access Key.
2. x509 : X.509 certificates are based on the idea of public key cryptography. It is used for \making requests to AWS product SOAP APIs (except for Amazon S3 and Amazon Mechanical Turk, which use access keys for their SOAP APIs). SOAP services are being defocused so x509 will not be used as much moving forward.
3. Key pair file (SSH pem file) : You use an Amazon EC2 key pair (aka: PEM file) each time you launch an EC2 Linux/UNIX or Windows instance. The key pair
ensures that only you have access to the instance.Each EC2 key pair includes a key pair name, a private key, and a public key. more on using PEM with EC2 here http://cloudconclave.blogspot.com/2012/09/connecting-to-aws-ec2-using-ssh-and-sftp.html
4. Security Groups : A security group acts as a firewall that controls the traffic allowed
to reach one or more instances. When you launch an instance, you assign it one or more security groups.
You add rules to each security group that control traffic for the instance. You can modify the rules
for a security group at any time; the new rules are automatically applied to all instances to which
the security group is assigned.
These AWS security concepts are not necessary but one you get beyond the 'playing around phase' of working with AWS these security components are key to working with AWS:
1. ARNs : Amazon Resource Names (ARNs) uniquely identify AWS resources. We require an ARN when you
need to specify a resource unambiguously across all of AWS, such as in IAM policies,
Amazon Relational Database Service (Amazon RDS) tags, and API calls. Here is an example ARN:
<!-- Amazon RDS tag -->
arn:aws:rds:eu-west-1:001234567890:db:mysql-db
ARNs are used extensively with IAM to place security/access policies on AWS services.
2. IAM : AWS Identity and Access Management (IAM) enables you to securely
control access to AWS services and resources for your users. Using IAM
you can create and manage AWS users and groups and use permissions to
allow and deny their permissions to AWS resources. More details here: http://cloudconclave.blogspot.com/2012/10/aws-iam-service.html, http://cloudconclave.blogspot.com/2013/05/aws-getting-started-with-groups-and.html
3. NACLs : Network ACLs operate at the subnet level and evaluate traffic entering
and exiting a subnet. Network ACLs can be used to set both Allow and
Deny rules. Network ACLs do not filter traffic between instances in the
same subnet. In addition, network ACLs perform stateless filtering
while security groups perform stateful filtering.
4. S3 SSE : http://cloudconclave.blogspot.com/2013/07/s3-sse-without-request-header.html Server-side encryption is about data encryption at rest, that is, Amazon S3 encrypts your
data as it writes it to disks in its data centers and decrypts it for you when you access
it. As long as you authenticate your request and you have access permissions, there is no
difference in the way you access encrypted or unencrypted objects. Amazon S3 manages
encryption and decryption for you. For example, if you share your objects using a pre-signed
URL, the pre-signed URL works the same way for both encrypted and unencrypted objects.
