Security is one of the biggest concerns in systems nowadays. The amount of information leaked from big companies is worrying, especially because 90% of the information leaks could be mended with very small actions by the software developers. Something similar happens with the logging of events and the traceability of errors. No one really pays too much attention until someone requests the logs that you don't have in order to audit a failure. In this chapter, we will discuss how to manage security and logging so that our system is safe and traceable, with the help of the following topics:
- Infrastructure logical security: We will discuss how to secure our software infrastructure in order to provide the industry standard security layer in our communications.
- Application security: We will introduce the common techniques to secure our applications. Practices such as output encoding or input validation are the industry standard and they could save us from a catastrophe.
- Traceability: Being able to follow the requests around our system is a must in microservices architectures. We will leverage this task to Seneca and learn how to get the information from this fantastic framework.
- Auditing: Even though we put our best efforts in building a software, accidents happen. The ability to rebuild the sequence of calls and see exactly what happened is important. We will discuss how to enable our system in order to be able to recover the required information.
Infrastructure security is usually ignored by software engineers as it is completely different from their area of expertise. However, nowadays, and especially if your career is leaning towards DevOps, it is a subject that should not be ignored.
In this book, we are not going to go very deep into the infrastructure security more than few rules of thumb to keep your microservices safe.
It is strongly recommended for the readers to read and learn about cryptography and all the implications around the usage of SSH, which is one of the main resources for keeping communications secure nowadays.
In any organization, there is a strict list of people who can access certain services. In general, this authentication for these services is done via username and password, but it can also be done using a key to verify the identity of the user.
No matter what authentication method is used, the communication should always be done over a secure channel such as SSH.
SSH stands for Secure Shell and it is a software used to access shells in remote machines, but it can also be a very helpful tool to create proxies and tunnels to access remote servers.
Let's explain how it works using the following command:
/home/david:(develop) x ssh [email protected] The authenticity of host '192.168.0.1 (192.168.0.1)' can't be established. RSA key fingerprint is SHA256:S22/A2/eqxSqkS4VfR1BrcDxNX1rmfM1JkZaGhrjMbk. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added '192.168.0.1' (RSA) to the list of known hosts. [email protected]'s password: Last login: Mon Jan 25 02:30:21 2016 from 10.0.2.2 Welcome to your virtual machine.
In this case, I am using Vagrant to facilitate the building of virtual machines. Vagrant is a very popular tool to automate development environments and their website (https://www.vagrantup.com/) consists of useful information.
In the first line, we execute the ssh [email protected] command. This command tries to open a terminal as the user david in the 192.168.0.1 host.
As it is the first time that this command is executed against the machine in the IP 192.168.0.1, our computer will not trust the remote server.
This is done by maintaining a file called known_hosts, under the /home/david/.ssh/known_hosts folder in this case (it will depend on the user).
This file is a list of hosts with the corresponding key. As you can see, the following two lines explain that the host cannot be trusted and present the fingerprint of the key held by the remote server in order to verify it:
The authenticity of host '192.168.0.1 (192.168.0.1)' can't be established. RSA key fingerprint is SHA256:S22/A2/eqxSqkS4VfR1BrcDxNX1rmfM1JkZaGhrjMbk.
At this point, the user is supposed to verify the identity of the server by checking the key. Once this is done, we can instruct SSH to connect to the server, which will result in the following log being printed:
Warning: Permanently added '192.168.0.1' (RSA) to the list of known hosts.
Now, if we check our
known_hosts file, we can see that the key has been added to the list, as follows:
This key stored in the known_hosts file is the public key of the remote server.
SSH uses a cryptography algorithm called RSA. This algorithm is built around the concept of asymmetric cryptography, which is shown in the following image:
The asymmetric cryptography relies on a set of keys: one public and one private. As the name states, the public key can be shared with everyone; whereas, the private key has to be kept secret.
The messages encrypted with the private key can only be decrypted with the public key and the other way around so that it is almost impossible (unless someone gets the other half of the key) to intercept and decrypt a message.
At this point, our computer knows the public key of the server and we are in a position to start an encrypted session with the server. Once we get the terminal, all the commands and results of these commands will be encrypted and sent over the wire.
This key can also be used to connect to a remote server without password. The only thing we need to do is generate an SSH key in our machine and install it in the server in a file called authorized_keys under the .ssh folder, where the known_hosts file is.
When working with microservices, you can be remotely logged in to quite a few different machines so that this approach becomes more attractive. However, we need to be very careful about how we handle the private keys because if a user leaks that private key, our infrastructure could be compromised.