Managing IT infrastructure secrets
Hi, gifts to all! I recently defended my diploma on developing a system for managing corporate secrets. In honor of this, I wanted to present a small excerpt from my work.
What other secret?
A secret is a confidential string of text that provides direct or indirect access to information resources. For example, a database connection string that provides access to information in the database.
What will you get from the article?
The article will show a practical example of using encryption and a combination of different types of encryption. You will also learn the basic principles of digital signature and cryptography. A link to the project's source code is available at the end of the article.
Why is this necessary?
The company where I interned has about 60 web services and applications that continue to be improved and supported. Each service has on average about 15-20 secrets, for example: login and password for the admin panel, API keys, database connection strings, encryption keys, etc. They are usually stored in special project configuration files (appsettings.json) or directly in the code. Managing them in this format, when they are scattered across different repositories and files, is problematic. By “manage” I mean actions such as obtaining and periodically updating secrets. These secrets are usually transferred between developers via instant messengers, which leads to their spreading.
To hand in this diploma To solve these problems, I created my own service for managing secrets.
Yes, similar systems have existed for a long time, for example, HashiCorp Vault and Passwork. But this article is not about them. However, I'll briefly tell you why I didn't use them:
“Difficult” to set up or expensive to buy.
I would hardly have defended a diploma with a ready-made solution.
I wanted to try to invent my own wheel, made on the company stack: C#, ASP.NET, Angular.
What is required from the system?
Of course, we will not implement all the functionality from existing services. I didn't have the time or resources for this. My goal was to pass my diploma with minimal effort and achieve maximum results, which is what ultimately happened.
Here's what we'll be implementing:
Data transfer between client and server is encrypted using asymmetric encryption (RSA).
Storing data in encrypted form so that a database compromise does not lead to the compromise of all secrets. For this, we will additionally use symmetric encryption (AES).
Securely distribute and transmit secrets to users and systems.
How will we implement it?
We use the following stack: C#, ASP.NET, Angular with TypeScript. Let's look at how to safely transfer information from client to server.
First, the data needs to be encrypted before sending. We can use symmetrical encryption where one key is used for encryption and decryption, or asymmetrical encryption, when different keys are used for encryption and decryption. Let me explain why we cannot use symmetric encryption. Let's say we generated a key on the client, encrypted data using this key, and sent this cipher to the server. An attacker will not be able to decrypt it without the client's key, but the server will not be able to decrypt it for sending to other clients. If you send the key, there will be no point in encryption. Therefore, we choose asymmetric encryption.
To decrypt secrets, the server needs keys. They will be stored in the “Safe” table. Each secret belongs to a safe. The safe has two keys – public and private. The private key is encrypted using a symmetric algorithm before being stored in the database, and the key for it is stored on the server (not in the database).
To gain access to the secret, you must have the appropriate permissions and the correct key to “open” the safe. The name of the project is Bank of Secrets (BOS) – an analogy with a bank, safety and reliability.
Scheme of interaction between client and server
Preliminary steps before sending the secret to the server:
The client sends a request to create a safe.
The server creates a safe and generates two keys (private and public). Before saving to the database, the private key is encrypted using AES. Example code:
//endpoint: api/safe/create var keys = asymmetricCrypto.GenerateKeys(); string PublicKeyPem = keys.publicKeyPem; string PrivateKeyPem = keys.privateKeyPem; // Encrypt private key before saving string EPrivateKeyPem = cryptorService.EncryptWithSecretKey(PrivateKeyPem); // save keysMethod
EncryptWithSecretKeyuses the key from the project configuration (appsettings.json) and methods from the namespaceSystem.Security.Cryptographyand gets the cipher for the key.
Now that the RSA keys are ready, we can begin encryption. Below are the data flow diagrams (DFDs) showing the secure exchange of information between the client and the server.
Create and send a secret to the server
The client receives the public key from the safe.
Encrypts the entered data using asymmetric encryption.
Hashes the cipher and asymmetrically encrypts it using the public key (a digital signature is formed).
Cipher + cipher hash (signature) + public key (for signature verification) are sent to the server.
The server checks the signature and saves the secret in the database exactly as it arrived to the server.
Getting the secret on the client
The client generates a pair of RSA keys, attaches a public key to the request, and sends a request to obtain the secret.
The server checks all user permissions.
An encrypted secret and a private key are taken from the storage. The private key is decrypted, then the secret is decrypted using it, which is immediately encrypted using the client's public key.
The received cipher is sent to the client.
The client decrypts it using his private key.
This approach ensures that the record is sent and received in encrypted form, ensuring that no one except the server and the client can decrypt it, even if the request or traffic is intercepted. Thanks to the digital signature, the data is protected from man-in-the-middle attacks (MITM) and information substitution. The combination of asymmetric and symmetric encryption protects us from database compromise: even if attackers gain access to the database, they will not be able to use this data.
What should be taken into account?
Risks associated with centralizing secrets. Well, think for yourself: all your secrets are stored on one server, the compromise of which will lead to the compromise of the entire IT infrastructure of the company. Reliable backups and a strict security policy for this service may help you.
Exists state standards for the implementation of such systems. It can be difficult to understand these GOST standards, since they are written in a language that is understandable mainly to mathematicians. They specify the requirements for key sizes and other mathematical parameters. Therefore, if you have to work with cryptography in the public sector, it is important to take these GOSTs into account.
As it turns out, to use cryptographic algorithms, you need to get a certificate from the FSB. They don't just want to watch you exchange incomprehensible symbols, they want to know everything. They will probably require you to provide all the keys so that they can decrypt any of your messages if necessary.
Generating paired keys for each request and using an asymmetric data encryption method is considered bad practice. It is better to use asymmetric encryption only to generate a shared symmetric key, since symmetric encryption is much faster. This is especially important if the volume of data is large.
Pay close attention to the key format, they come in different types. If you create keys on the client in PEM format, and the server uses PKCS 8 format for the algorithm, you will get an error.
Conclusion
I successfully defended my thesis on this project with an “excellent” grade, although there were a lot of mistakes. I hope my article helped you understand the best way to manage secrets – use free ready-made solutions 🙂
Telegram: https://t.me/khayka
