IAM integration with on premise LDAP

You can manually create IAM users with passwords for access to AWS resources using the AWS Management Console, AWS CLI or API calls. This is a great way to start, but you may already have an identity store (such as Active Directory) that you wish to leverage for AWS resource access. Two methods are possible: Replication and Federation.

With replication, you copy account credentials from your identity store into AWS IAM. This is useful for smaller organizations who need a quick solution without building ongoing connectivity between the two identity stores. While fast to execute, this method has some drawbacks such as: Limited to the number of accounts supported by IAM (5,000 default), changes between identity stores are not automatically propagated, this includes password changes, and disabling or deleting of accounts.

Federation can be done using AWS STS or a third-party such as Okta.   

Remember IAM is not a substitute for an identity store such as Active Directory. 

AWS IAM services and features that play a role when moving Oracle workloads to AWS

Identity and access management (IAM) is a key component of AWS security.  IAM allows the creation of users, groups and roles. IAM services and features you will most likely consider when host Oracle on AWS are:

1. Security Token Service (STS) : STS generates temporary credentials for an IAM User or for users that you authenticate (federated users). Useful for improving security posture, mobile applications, and identity federation. Here are some basics of STS:

A. Generates a temporary Access Key, Secret Key, and Token
B. Expire automatically (15 minutes ~ 36 hours)
C. You write an “identity broker application” ( sample code here: http://docs.aws.amazon.com/STS/latest/UsingSTS/STSSampleApps.html)
D. Users authenticate to your identity broker
E. Your identity broker provisions temporary credentials via STS
F. SSO via the management console: Temporary credentials can be used to sign user directly into the AWS Management Console

More reading: http://docs.aws.amazon.com/STS/latest/UsingSTS/Welcome.html

  Get the temporary temporary token (access key ID, secret Key, and security token) by issuing the get_federation_token API call.  The thing to keep in mind with your identity broker application is that you will have to have all the policies defined some where (in code as below, relational database, XML file, JSON templates, some file, etc) as you probably don't want to hard code in the application and will have 1000's of different users with different policies. 

http://docs.aws.amazon.com/AWSSDKforPHP/latest/index.html#m=AmazonSTS/get_federation_token
The role needs to have a policy associated. Here is the way it is done it code:

// Generate a new IAM policy (https://awspolicygen.s3.amazonaws.com/policygen.html)

$policy = new CFPolicy($token, array(

    'Statement' => array(

        array(

            'Sid' => 'SID' . time(),

            'Action' => array('s3:GetObject', 's3:GetObjectVersion', 's3:ListBucket', 's3:ListBucketVersions'),

            'Effect' => 'Allow',

            'Resource' => 'arn:aws:s3:::my-bucket/*'

        )

    )

));

Here is a REST web services call to generate temporary credentials: http://docs.aws.amazon.com/STS/latest/UsingSTS/CreatingFedTokens.htm

or you can use the assume-role API or web services all in document above. Here you would not need to send in a policy as the role would have a policy:

http://docs.aws.amazon.com/AWSSDKforPHP/latest/index.html#m=AmazonSTS/assume_role

2. IAM resource level permissions - More information can be found here:  http://aws.amazon.com/about-aws/whats-new/2013/07/08/announcing-resource-permissions-for-amazon-ec2-and-amazon-rds/

3. IAM Roles: Roles can be used to securely allow EC2 instances access other AWS services, enables identity federation with STS, cross account access, and web identity federation. 

A. Allow your applications (e.g., Java) running on EC2 to securely access other services (e.g., S3, SQS, etc)

B. Identity federation (including STS)

C. Web Identity federation : Web Identity Federation allows authenticating via Login with Amazon, Facebook, or Google, getting temporary security credentials, and then using those credentials to make a request to AWS. 

D. Allow cross-account management/access

Jane in Account A may assume a Role in Account B, giving Jane an Access Key/Secret Key/Token that may be used to make API calls to Account B. 

More reading:http://docs.aws.amazon.com/IAM/latest/UserGuide/WorkingWithRoles.html

Striping volumes for an Oracle Database

Often times you will want to stripe your Oracle database volumes for better performance.  Here are the steps for creating the EBS volumes and creating the Linux logical volume:

1. aws ec2 create-volume --availability-zone us-west-2b --size 100

2. aws ec2 create-volume --availability-zone us-west-2b --size 100

3. aws ec2 describe-volumes --volume-ids vol-7c2e9955 vol-2e2e9907

4. aws ec2 attach-volume --volume-id vol-7c2e9955 --instance-id i-f0ef69c6 --device /dev/sdc

5. aws ec2 attach-volume --volume-id vol-2e2e9907 --instance-id i-f0ef69c6 --device /dev/sdd

6. aws ec2 start-instances --instance-id i-NewDBServer

7. ssh -i YourFile.pem ec2-user@10.50.x.x

Once you are logged into the EC2 instance,  stripe and then recognize your additional volumes with this series of commands:

1. sudo mkdir /mnt/oraclestripe

2. sudo vgcreate vg /dev/sdc /dev/sdd

3. lvcreate -L 200 -n lv -i 2 vg

(Notes:

1. Using default stripesize 64.00 KiB

2. The parameter -i in the lvcreate command specifies the number of physical volumes to stripe across. If you wanted to stripe across more than 2 drives, you would have to specify that number.

)

4. sudo mkfs -t ext3 /dev/vg/lv

5. sudo mount /dev/vg/lv /mnt/oraclestripe

6. Next, update /etc/fstab to ensure these mounted drives are automatically mounted on reboot.

A. sudo vi /etc/fstab and add these lines:
/dev/sdb /mnt/piops1 ext3 defaults 0 2
/dev/vg/lv /mnt/oraclestripe ext3 defaults 0 2

7. df -h (to view the new volumes mounted to the logical volumes created)

Security on AWS

Good overview of top security tips for running on AWS:
http://stratumsecurity.com/2012/12/03/practical-tactical-cloud-security-ec2/

AWS Security 101 for Oracle DBAs, Developers and Architects

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.

3. MFA : Multifactor authentication (MFA) is a security system in which more than one form of authentication is implemented to verify the legitimacy of a transaction. The goal of MFA is to create a layered defense and make it more difficult for an unauthorized person to access a computer system or network.  An MFA device can be a Gemalto token (http://onlinenoram.gemalto.com/) or even an iPhone.  http://cloudconclave.blogspot.com/2013/06/mfa-made-easy.html
4. Bastion Host :A bastion host is a special purpose computer on a network specifically designed and configured to withstand attacks. Information on bastion hosts on AWS with Oracle on these two posts: http://cloudconclave.blogspot.com/2013/05/aws-bastion-host-as-single-point-of.html http://cloudconclave.blogspot.com/2013/05/dba-and-developer-access-to-oracle.html
5. iptables : iptables are the tables provided by the Linux kernel firewall.  These firewall rules make it possible for administrators to control what hosts can connect to the system, and limit risk exposure by limiting the hosts that can connect to a system.  Information on iptables for security on AWS here: http://cloudconclave.blogspot.com/2013/06/aws-security-with-iptables.html

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.  PEM is a file format that may consist of a certificate (aka. public key), a private key or indeed both concatenated together. Don't pay so much attention to the file extension; it means Privacy Enhanced Mail, a use it didn't see much use for but the file format stuck around. 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.

5. Data Encryption : AWS does not provide encryption of EBS (Elastic Block Storage) . More details on a couple of vendors that provide solutions here: http://cloudconclave.blogspot.com/2013/04/ebs-volume-encryption.html

AWS SSO integration with AWS

This is a question that comes up quite often, "How can I delegate authentication into my on premise MS AD for AWS users?"  This product has just been released.

SSO integration with AWS

http://www.okta.com/aws/

They were also showcased in Andy’s keynote on Tuesday at the SF AWS Summit.

http://www.youtube.com/watch?v=bWL0_Xdntzo#t=50m52s  

The other option is to use AWS STS: http://docs.aws.amazon.com/STS/latest/UsingSTS/Welcome.html

AWS getting started with groups and users

A common question is when first setting up and AWS environment is how to prevent developers, OS administrators, DBAs, architectures and all the different roles you may have in your organization from having the correct privileges.  You use IAM group and users.  You would create a developer group.  Ignore roles to start with as these are for AWS services to access other services  (example: EC2 accessing S3) and cross account access.  Then add policies to the group (use policy generator or select a template). Then add each developer as individual users and adding them to the developer group.

Good resource for all of your questions….You can explicitly manage roles and policy

http://docs.aws.amazon.com/IAM/latest/UserGuide/IAMBestPractices.html

http://docs.aws.amazon.com/IAM/latest/UserGuide/cross-acct-access-walkthrough-creategroup.html

Nice blog entry here:
https://forums.aws.amazon.com/message.jspa?messageID=197920