You have been building your architecture to be fast, redundant and cost-effective. It has helped you grow and scale your startup. You can deploy new patches with the push of a button and opened SSH so you can change things when needed. But where is the security, bro?
The architecture you have created is available to everyone worldwide. It runs in one or multiple datacenters and has public IP adresses with services that listen on a variety of ports. Do you have a list of all these services, their ports and their software versions?
There is a rise in security threats as finding vulnerabilities is becoming relatively easy. Getting your hands on malicious software, vulnerability scanners and brute force tools is a piece of cake. Protecting against this should be just as easy!
Shared Security Model When using Iaas/Paas you may think that your service provider secures your architecture. Now as this is true to some extend, they can only do so much. The purpose of the Shared Security Model is understanding your responsibilities in comparison to those of the provider.
The service provider takes care of the underlying services like the facilities, physical security, physical infrastructure, network infrastructure and the virtualization infrastructure. You are responsible for everything on the application layer.
Secure your applications Applications running on your nodes must be secure. These may have large codebases and their security can never be guaranteed but a risk analysis may be drawn based on a few requirements.
Who can access? Access management plays a key role in securing your architecture. You will not be the first victim of stolen credentials that accidentally had permission to delete crucial data. Index all your assets within your current architecture, list the possible permissions and group these within roles. This way you can assign users to a role and keep the roles strict. Do not simply hand out permissions to single users as this decreases the overview of permissions given out.
Try to centralize access management and authorization as much as possible. Ask yourself the question, do I want a single point of potential failure but a clean overview of all performed authentications with their permissions, or do I want to have multiple systems with different roles, different permissions, duplicate users and more manual work.
Log log log log Why wouldn't you log everything that happens? It's not a storage issue, that is unlimited and practically free (S3, Glazier). Logs can be analysed in realtime to detect any kind or error, unexpected behaviour and even suspicious activity. You can hook into these findings and perform automated tasks like honeypotting, texting/calling yourself or anything you can think of.
Consider using control servers when direct access must be made to servers within your architecture. These control servers can log every command made with the authenticated users, timestamp, origin etc.
End to end security To be able to sleep good at night without constantly worrying about your architecture, set up a tight security protocol that covers end to end. Are all servers locked down with IP tables and firewalls? Do you have antivirus and intrustion detection software monitoring every part of your system? Are your logs monitored in realtime and stored securely? Can you cut in users permissions to further increase security and do they authenticate with two-factor? Define a list that fits your business and make sure every checkpoint screams yes, all the time.
Obey a framework Security is nothing new and you do not have to reinvent the wheel here. There are frameworks that I would encourage you to use. A popular one is CSIS 20 Critical Security Controls 4.0.
The Critical Security Controls is based on the latest Advanced Targeted Threats from which priorities are defined. With a strong emphasis on "What Works" - security controls where products, processes, architectures and services are in use that have demonstrated real world effectiveness. Standardization and automation is another top priority, to gain operational efficiencies while also improving effectiveness.
Patch regularly Software is outdated fairly quickly. Its therefore considered good practice to lay some groundrules for yourself.
Understand your responsibilities When you have mapped out your architecture in terms of networks, servers, services and more you will have a better overview of what parts you are required to secure and which are not covered by your cloud provider. After implementing your security protocol, make sure it stays secure after changes by testing regularly.