on 2021 Oct 16 9:36 AM
Hi All,
We would like to install SAP SQL Anywhere on a server that would allow to serve multiple tenants. I already read some articles posted about the subject and the advantages / disadvantages about each method but I have some worries about each method:
1) Different SQLSRV per tenant - each server would compete for server resources - in terms of security it seems more secure to me (each server would have an encryption key for TDS / ODBC communication) my worries are how would this scale and how the different servers would compete for resources (databases will be small ~2GB each lets say) - in a server with 32GB RAM how much clients could I have and still getting a decent performance?
2) One server with multiple databases - the server would have multiple databases each providing isolation (in terms of storage) - problem is communication layer since all databases will be served in the same PORT and with the same encryption KEY - if an malicious actor with the key (the key must be installed on all tenants / clients so it's relatively easy to access) could guess the database name it would have access to all tenants DB's using only one KEY - the exposure to a breach is wide.
3) In terms of the encryption key instalation on the client side do you think it would be more secure to have the key installed manually (client must download the access key from its client area and store the key on its profile for example) or the key is never stored locally and there is a central system where the app (when logged on) would call a WebService that would download the key do a temporary folder and then use it to connect to the DB.
Sorry for the "too much" questions!
Thanks in advance, Rui Cruz
Request clarification before answering.
Something else to think about, depending on the architecture you eventually choose, and what features your system provides, is about isolating the databases from each other. Look at both disk sandboxing and the -sf security settings option.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
I'd add the -edi database server option to allow "database isolation". (Note, it can also be controlled via the security settings option Justin has suggested.)
AFAIK disk sandboxing does not affect how database files are isolated from one another... it affects where non-database files are written: relative to the folder containing the database versus relative to the server's working folder. In a cloud environment both of these locations are on the cloud computer, and they imply the end user has file access to that computer. If not, then perhaps the non-database files should be written to the client computer.
I would imagine the default configuration for a new multi-client cloud setup should be "allow nothing until proven necessary" 🙂
Just as a general comment:
As you have stated in one comment, you are not talking about database encryption but communication encryption via TLS. But please note that communication encryption via TLS with server certificates is no means to authenticate users, therefore it's also no means to restrict access. It's just a means to prevent others from "reading and understanding" the network traffic between client and server. - It's just the same intention as using HTTPS with a ordinary web server.
SQL Anywhere's user management is database-specific, not server-specific (say, in contrast to MS SQL Server or SAP ASE), so in that respect it does not matter whether different databases run on the same or on different servers. Each user will need to have valid credentials to the database he/she wants to access. Of course, if both databases db1 and db2 have credentials for a user "JohnDoe" with the same password, that user could connect to both databases.
For that reason, I do not quite understand your thoughts about sharing vs. not sharing "DBKEY" - a DBKEY is used for database encryption, which you do not plan to use according to your comment. So are you talking about the trusted certificates one has to accept? Those are no "secret", so there's not much sense in "hiding" them. For ease of usage, you can store certificates within the database, so there's no need for client users to "mange them". - As you can see from the sample connection strings for TLS clients from the docs, there's no key here to be provided.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
User | Count |
---|---|
60 | |
10 | |
8 | |
8 | |
7 | |
6 | |
6 | |
5 | |
5 | |
4 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.