AWS Application Security
AWS requires a shared security responsibility, with Amazon taking responsibility below the trust boundary and users taking responsibility above the trust boundary. In this chapter, I describe Amazon’s security offerings that address its area of responsibility. But how about yours?
Many people are unsure what steps to take to improve security for their applications. This uncertainty is troubling because Amazon (and every other cloud provider in the world) rightly refuses to take on user security responsibility.The company cannot possibly know what users do inside their applications, of course, so Amazon and other cloud providers leave application security to the user.
Given this situation, follow my recommendations to increase your AWS application security:
✓ Use security groups appropriately. Obviously, you should avoid using the Default security group for applications. Every security group should be identified explicitly with a name that indicates its purpose. This strategy makes it easier to audit the security groups to ensure that they’re appropriately configured. If you see a security group for web serversand it has Port 21 (FTP service) listed in addition to Port 80 (HTTP service) and 443 (HTTPS service), it’s probably incorrect. Earlier in this chapter, I discuss the use of security groups to partition your application to implement defense in depth, and I strongly urge you to follow that strategy. Limiting traffic to appropriate IP address ranges is a good practice to follow as well.
✓ Implement data encryption in transit. If you encrypt your network traffic, both external to AWS and within AWS, you prevent anyone from reading your packets. Though AWS’s record in maintaining packet securityis exemplary, you still may implement encryption — just to be certain.Trust but verify.
✓ Implement data encryption at rest. If you encrypt data that’s stored within AWS, you protect it from being examined by other AWS users as well as by AWS personnel. One of the strongest arguments against encryption is the performance penalty it imposes, so evaluate your data to see whether it has particularly sensitive portions for which a performance hit would be acceptable. ✓ Manage security keys carefully. Administrative access to AWS Linux instances is typically via shared key SSH. Stories abound about organizations in which keys are widely shared by many administrators, placed on individual user’s drives, and never rotated. Even worse, many organizations fail to change the keys they’re using when an employee quits (or,even worse, is fired for a serious reason) and the former employee still has a copy of the key used to administer AWS instances. This neglect constitutes playing with fire, and any organization that fails to manage its keys carefully deserves to have its fingers burned. Many key management olutions exist in the marketplace — and several open source options — so implement a solution to manage your keys.
✓ Install and configure your software packages correctly. It’s a cliché that many IT organizations install software and leave default passwordsin place, leave unnecessary ports open, and fail to configure the software packages to properly protect them against attack. Don’t make that mistake. Evaluate every component of your application (including the operating system in the image) and ensure that you’ve installed and configured them correctly and securely.
✓ Implement on-instance security. The move to deperimeterized security emphasizes the need for every resource to be appropriately protected against security issues. It’s critical that you put Host-based IntrusionDetection/Prevention Software (HIDS) in place to track and respond to attacks. If you’re running Windows-based instances, you should also ensure that you have antivirus and antimalware software operating aswell. Frankly, this area is the one where most organizations commonlyfail, and it often reflects the unwarranted assumption that AWS is responsible for security. For its portion of the environment, it is responsible. For your stuff, it isn’t. Be sure to have on-instance security in place.
✓ Manage your instance code properly. Too many organizations create an image and then use it, untouched and unchanged, for months (or years!) on end. That’s a huge problem. First, this level of carelessness neglects the installation of important security patches and can leave your application exposed to security holes. Second, if you don’t manage your application code correctly, you can’t be sure what version of your application is running, and that’s a big problem. Many organizations address it by creating new images, but that strategy poses a different problem: image sprawl. A better approach is to implement the techniques described in Chapter 6 for managing instance code, to ensure that you have better security in place and always know what you’re running.