This article was written under the guidance of Michael,
our Senior DevOps Engineer with 10+ years of experience in this domain.
The first correct question that should arise when you are ready to invest money in a Gambling or Fintech project (because in fact they are both related to money) should be: “How to configure the security of the project during development?”. This is the first and key question, without solving which you will have neither a project nor money with a probability of 97%, no matter what you develop. In the first of a series of articles on the development of large-scale projects with a significant turnover of funds, we will talk about security architecture from the perspective of our own many years of experience.
Access is the foundation of the foundation
To get access to a project means to get the project itself. No, now we are not talking about distrust of developers or trade secrets from competitors. Just accept that data protection should be in any case and no one except the owners can have the opportunity to use it to the fullest. After all, even honest and decent people whom you completely trust (this sometimes happens) can indirectly become victims of data thieves who use. Your data.
The option of storing everything “on a piece of paper”, as, for example, secret words work in the popular crypto wallet service MetaMask, is categorically not suitable for the project. Yes, this is a great approach exclusively for protecting personal information intended only for you. But if you even store access outside the network, the main question is: “How to transfer this to the right people?”. Let’s say to developers. With a photo via WhatsApp or any other messenger? Dictate with a voice message? You can continue endlessly, but in vain — all this is a direct path to parsing, loss and theft of data.
Modern, effective practice for storing data in a project (secrets), where they should be used by different categories of people (DevOps, developers, administrators), looks like this:
It is forbidden to store in code
● Environment — (environment variable) — is a method of obtaining system configuration data used by applications either through the code itself (e.g. env.get in Node-RED) or through OS environment variables. This allows settings such as API keys to be stored outside of the application code;
● DB_PASSWORD= is a variable used in application configuration files (e.g. .env, wp-config.php, config/database.php) to store the database access password;
● PAYMENT_API_KEY= is a secret key used to authenticate your application when interacting with a payment gateway (e.g. Cryptomus, iPay, Stripe). It allows your site or bot to accept payments.
● JWT_SECRET= is a secret key used to sign JSON Web Tokens (JWT). It ensures data integrity: it allows the server to verify that the token was issued by it and has not been modified by an attacker;
● PRIVATE_KEY= is a secret alphanumeric code (password) that provides full and absolute access to cryptoassets on a blockchain address or to encrypted data.
All of this is direct access to the most sensitive project information that can (and will) be used against you at the most unexpected time.
Store in a specialized storage facility
Currently, there are many reliable and proven services that are able to maintain access and create the necessary conditions for data protection using various methods. These include:
If this statement, based on our own experience, seems unfounded, we will provide confirmation from the global and independent community of developers and cybersecurity experts OWASP . On the site, everyone will find direct recommendations for centralized storage, management, auditing, rotation and control of Secrets through the above and other services. The most effective security scheme from OWASP looks like this:
Database access
Separately, it is worth mentioning the security of access to databases. While in other cases, unwanted access can be limited and configured, an open database means access to everything at once. The positive aspect here is the large amount of information: it takes time to copy or damage it, which means it is skillfully used against attackers.
The best option today is to use dynamic secrets. In this case, the basis is the secret data lifecycle ( Lifecycle) , where each stage is under strict control and accessible with a temporarily generated login and password::
- Creation /Generation: Creating strong, unique secrets. Best practice is to use random generation rather than manually creating passwords.
- Storage : Securely storing secrets in specialized vaults (Secret Managers such as HashiCorp Vault, AWS Secrets Manager, Azure Key Vault), rather than in code or configuration files.
- Usage : Access to secrets by applications or services only when needed.
- Rotation : Regularly replacing secrets with new ones to reduce the risk of an old secret being compromised.
- Revocation & Destruction : Removal or deactivation of secrets that are no longer needed or in case of suspected leakage.
From our own experience, we can see that different services have different approaches to rotation. For example , AWS Secrets Manager and Google Secret Manager support rotation of secrets. In turn, Google understands this process more as a periodic update of passwords, API keys and encryption keys to reduce the risk of compromise. In any case, rotation of accesses every 30 minutes is possible, but it is not of key importance — this time can be longer. More appropriate for protecting databases would be:
- Replacing critical dynamic secrets: TTL 15–60 min;
- Rotation of regular API keys: rotation according to a schedule;
- JWT/private keys: key rotation + versioning;
- Root/admin credentials: exclude from the rotation list for the project altogether
Critical secrets
So how do you determine which accesses in Gambling or Fintech projects are important? After all, development may require numerous logins and passwords for many regular or related services at the same time. Turning the project into a complete “Iron Curtain” would be unnecessary and could significantly slow down the entire process. We have compiled a list of critical secrets that must definitely be protected:
- Database passwords have already been mentioned above, but additional repetition will only benefit;
- API keys of payment systems are unique codes for authenticating your site or application, allowing you to accept payments automatically. They usually consist of a public (Public Key) and a secret (Secret Key) parts, which are generated in the security settings of your business account (for example, LiqPay, Portmone, Fondy). Each provider rightly emphasizes: “Never transfer the secret key to third parties”, but in the case of project development we rephrase: “Provide the secret key only if it is previously protected”;
- Software tokens for access to CRM, KYC, antifraud or affiliate systems. We are talking exclusively about software tokens – unique sequences of characters transmitted via API. There can also be hardware, i.e. physical tokens (USB flash drives or smart cards on which the KEP secret key is generated and stored), but that is another matter;
- JWT secrets are a string of characters (password) used by the server to create a digital signature for JSON Web Tokens. This secret is unsafe because if an attacker gets your JWT Secret, he can sign his own tokens, impersonating any user (for example, an administrator), which will lead to a complete system compromise;
- OAuth client secrets — a password given to an application (client) by an authorization server (e.g. Google, Facebook, GitHub) when the application is registered. It is used in conjunction with the Client ID to authenticate the application when it attempts to access user data via the API;
- Private keys — in the case of working with blockchain. This is a code that acts as a password for accessing, managing, and signing transactions in a cryptocurrency wallet;
- SSH keys are a pair of cryptographic keys (private and public) used for secure authentication to a remote server without a password. They are a more secure alternative to passwords and protect against brute-force attacks. The pair consists of a private key (stored by you) and a public key (hosted on the server).
- Webhook secrets are a password used to verify that a webhook request came from the expected service and not from an attacker. They provide security by allowing the recipient to authenticate the sender using a signature;
- Credentials to cloud infrastructure — a generalized concept of individual accesses to information located in cloud storage;
- Access to Redis, RabbitMQ, Kafka, Elasticsearch, etc. — access to the messaging tools (message brokers) and data management used in the project, which provide asynchronous interaction between services. In skillful hands, this is a powerful lever of influence on the project, which should remain under your control;
- Encryption keys — self-explanatory.
The only right way
Everything written above about access protection is not intended to scare potential developers of their own Gambling or Fintech projects. On the contrary: based on the best global development trends, and most importantly, our own expertise, we are ready to help you do everything as correctly as possible. After all, you will have to share access in any case: at the beginning of development, when changing developers or attracting new specialists, at the DevOps stage, which plays a key role in such projects. We know how to make it so that developers write code, work with APIs, use private keys, and so on, but at the same time do not know the real logins and passwords to all your secret data or use purely temporary passes. And this is the only way to guarantee the security of the project at any stage of development and after release.
