David Clinton
Outline
All the tutorials in this course:
- Introduction to EC2 Security
- The Basics
- Controlling External (Application) Access
- Controlling Internal (Administration) Connectivity
Just to make sure we're all on the same page, let's spend just a couple of minutes reviewing how EC2 works, what it's supposed to do, and then how to get through their famous quick launch process without accidentally exposing ourselves to security risks.
Unlike serverless tools like AWS Lambda, or highly-abstracted application delivery tools like Elastic Beanstalk or even the Elastic Container Service, EC2 was designed to provide a virtual experience that looks and feels pretty much the same as it would working with a physical server. You need to define your hardware environment: provisioning CPU power, storage and memory capacity, and network configurations; choose an operating system; and then install your application. I guess this was a model that they figured would work for the largest number of admins they hoped would migrate to the cloud. It's also possible that when they built EC2, no one had even thought of alternative paradigms.
I'm going to walk through the familiar dashboard quick-launch process while focusing on a few potential pain points. Now, in general, I would prefer to avoid the AWS dashboard - and especially when I'm teaching this stuff. One reason for that is that the AWS CLI is, for most cases, far more efficient and automation-friendly. But also because AWS is constantly updating their dashboard UI. That means that by the time you actually see this video, things might look quite different. Forget that: by the time I'll have turned my computer off on my way to bed tonight, AWS will probably have changed the UI. Still, even though things might not look quite the same, the actual underlying process has been largely consistent for many years - and probably won't be changing any time soon.
Ok. I expect you're already good and familiar with giving your instance a name and choosing an image. The instance type also shouldn't give you any trouble and, offhand, I can't think of any security implications related to selecting one type over another. But the encryption key pair you use will represent the keys to the castle. If you decide to go with an existing pair, make sure you still have the private key on your local system. But, even more important, make sure it has never been insecurely exposed. That means that if the key was ever, say, sent over unencrypted email as an attachment or was on the unencrypted drive of a laptop that was stolen or compromised, you should definitely stop using it.
Creating a new key pair isn't difficult as long as you follow these straightforward instructions. But just make sure you copy and store the new pair they'll show you securely.
Which brings us to the security group. This is where we're most likely to mess ourselves up. Obviously, you'll be able to change your security group rules later on when your instance is running. The most common reason for such changes is when you're having trouble connecting to your instance. When that happens, there's always a temptation to just open everything up and worry about security later. Don't do that. Figure out what the real problem is and fix it. Better yet, anticipate your needs up-front and get the configuration right the first time.
To help you with that, AWS recently introduced the Reachability Analyzer that can show you exactly what's happening at every step a request might take between a client and your VPC-based resource. There is a charge for each connectivity analysis, but at this point, it's only around ten cents a shot.
To satisfy more complex connectivity needs, you should build a custom security group in advance and select it from the drop-down. Remember, only groups within the current AWS region will be available here. If you decide to create a new group, the GUI offers you the three most common settings: SSH, secure HTTPS (port 443), and insecure HTTP (port 80). Note this warning: permitting SSH connection requests from anywhere - represented by the 0.0.0.0/0 CIDR address - is dangerous. If I limit that to just my own IP address - which AWS conveniently provides here - I'll cut back on my risk exposure. Remember all those fraudulent attempts to login to my server using SSH I showed you a while back? None of those would have got anywhere near my server had I limited access by setting this value to my IP.
Let's move down and expand the Advanced details section. If you've got team members on a local Microsoft Active Directory domain who will need administrative access to this instance, you can control how they get in by integrating your domain through Amazon's Directory Service. You can achieve similar control by applying an IAM instance profile. We'll talk more about that later on.
One more detail: tenancy. For most use-cases, there's nothing wrong with launching your instance into a shared-tenancy server. That means your instances might be sharing physical resources and space with instances run by other AWS customers. Frankly, I doubt there would ever be a problem with that. But to satisfy the security policies of some organizations, you many need to specify the use of dedicated hardware here. That'll cost you some more money, but if you need it you need it.
You can also drop a setup script here if there's any code you want executed on the operating system as it boots. Naturally, you shouldn't paste anything here that wouldn't be safe and secure on a regular running system.
Homework Exercise:
In case you've never had the pleasure, be sure to provision and launch your own simple EC2 instance they way we'll see in the demo. Just make sure you terminate the instance when you're done with it - forgetting that it's running could end up costing you money.