Hi Davide,
first of all: welcome to the community 
Regarding your question:
Generally speaking, you should try to avoid putting your DB credentials into application.properties. First of all to keep it outside of source control, but also to prevent being able to read it.
Jmix puts the credentials in fact in the application.properties though. The main reason for it that for the local development environment this is fine.
For a production scenario, there are multiple options to achieve what you want.
Environment Variables
The first one is to set the values through Environment variables. This is a native Spring Boot feature and a lot of people leverage that to externalise those values:
So instead of putting the values main.datasource.username and main.datasource.password in the application.properties, you set the following environment variables on your server / docker container: MAIN_DATASOURCE_USERNAME and MAIN_DATASOURCE_PASSWORD.
This way the credentials are injected into the application through the external operation systems settings. Here in the docs on how to deploy it to AWS Beanstalk, it is described in a very similar way: Amazon Web Services :: Jmix Documentation. The only difference is that in the application.properties it is explicitly mentioned that it refers to an external environment variable like this: main.datasource.password = ${RDS_PASSWORD}.
Both options will work fine.
Now, there are multiple ways on how you set the environment variables in the operating system. This highly depends on your deployment environment. In Kubernetes you can use something like Secrets to further obfuscate them / store them in a safe place. In an AWS context you can use e.g. Secrets Manager to set the values from secrets manager into your Docker container (in case of ECS).
But all of those approaches share one common pattern: within the container / operating system, everyone who has access to read the environment variables can still read the values.
The second approach goes a little further.
Dynamically Load credentials form Secret Store
In this case, the Jmix / Spring Boot application will at startup ask a secret store to grant them the values. E.g. there are solutions out there for Hashicorp Vault or also AWS Secrets Manager, where basically the application proactively reads the actual DB credentials from those secret stores on application startup.
The difference is that you have not laying around those environment variables anymore. Combining that approach with having short lived credentials will improve the situation even further. Here is an example of such approach for AWS: RDS Database Authentication with Spring Boot: Part 2, IAM Authentication — Chariot Solutions
From what I read from your question, solution number 1. is probably enough for you and also I think what most people are doing.
I hope this helps
Mario
