I have a program which looks for a config.json file where it reads needed sensitive infos like DB creds, different APIs creds, etc. I don't upload the config file to the git repository because I understand it's a bad approach, although it's a private repository. Now I'm starting to fear the case that I by accident delete this file, or due to a failure in my machine, I could permanently lose it. My question is - what is the best approach I could use to have a constant secured backup for this file, considering that it may contain very sensitive informations?
Also I would like to specify that this config file is frequently changed (and may increase in size...).
Select, implement, and test a backup system that meets your requirements for securing sensitive data. Access controls to the backup system, encrypting backup media, and logging jobs run are fundamental features to manage data.
Storing secrets in version control like git is tempting. But beware, a git repo may be cloned to many places, and every copy contains your credentials forever. Deleting them permanently requires rewriting history. Possibly easier to change any creds that got committed, leave the old ones in history, and don't commit secrets in the future.
Think about how you want to manage secrets. Secrets management software exists that wraps creds and keys in strong authentication and encryption. Building the application server could involve installing the application, and retrieving the API creds via the secret server. It may suit your needs to have different systems to store automation scripts, secrets, and backups.
Related
I am using KeyCloak as my user management tool, and love it.
The data of Keycloak is stored for me on a Postgres database. Over time, more clients are being registered, and other alterations to the realms may be done. My question is: How do I properly keep track of that, and propagate automatically changes between my different environments? For databases, I use liquibase for a purpose like this. I couldn't find anything similar for the Keycloak case.
So, I wanted to ask: How are you folks out there handling this? What am I missing?
It depends on how you're doing the management of those changes. There are generally two approaches:
Using the Keycloak admin console
Using the Keycloak CLI
If you're applying your changes via the admin console, then you can either rely on the database backup or setup a scheduled pipeline in your CI tool to make an export of the Keycloak realm into a file and archive it somewhere.
In case you're using the second approach, then you can have a git repository containing all the Keycloak CLI scripts that you run on your server (e.g. to add a client, to update a realm config, etc.). In that case, you can have them reviewed, versioned and then run as part of an automated pipeline. This will also allow you to run a script on different environments. But of course it comes with a price which is to write a script for every single task that you can typically do in admin console with a couple of clicks.
I have a react-native app that communicates with a server that makes calls to stripe for payment processing/customer creation. I want to ensure that requests are coming only from my app. so i figured i could create a token of sorts on the client, and encrypt it with a special key using b-crypt, then on the server side when the request comes in with the encrypted token as a parameter, i can decrypt that token with the same special key.
i understand the optimal place to store this key is in the env variables server-side, but how do you manage security of a secret key client-side in a react-native app?
There are several ways to store keys on the client side.
The easiest way is to use the Async storage which stores data in a key value pair.
The problem with Async storage is that its nor encrypted so it wont suit your requirement.
The other option is to use the react-native-keychain library which stores the passwords or keys in the securely in the keychain of IOS and keystore in Android. The security part will be managed by the operating system. So this is an approach that can be recommended for your requirement.
There are multiple ways to do this, these are just two options.
After further research, I ended up revoking the accepted status of #GuruparanGiritharan. his solution (react-native-keychain) dealt with storing passwords in an OS's keychain implementation. this ended up not being the solution for my question. as my question deals with storing secrets keys in a way they wouldn't be visible in binary, de-compiling situation.
What I did was research key management services. I found this:
Handling secrets with dotenv
In Node.js secrets are usually loaded from env files using the dotenv
module. This is done in order to separate the secrets from source
code. For example an env file might look like this (reference below):
DB_HOST=localhost
DB_USER=root
DB_PASS=s1mpl3
Now doing this in a context (potentially development) where you dont need to implement continuous integration, it's referred to a "manual provisioning"
My issue (admittedly, I did not specify a production environment in my question) is when it comes to a production environment, in my case, with visual studio app center (a CI option for React-Native apps)
Continuing on this site for an option for key management services:
While this removes hardcoded secrets from source code, it doesn’t
solve your problem completely; Now you need to find a way to provision
your app with the .env file.
This guide will show how you can remove the secrets from the .env file
altogether, so that it can be safely checked into source control and
shipped with your application.
This guide is discussing how to implement key management in the context of a production environment with continuous integration. This approach is relatively simple and straightforward, as all you need to do is create an .env file, add the keys with a variable, and add (in this tool's case) an additional run script to your main node.js start script.
Tool mentioned: SecretHub
https://secrethub.io/docs/guides/nodejs/
So, a common practice these days is to put connection strings & passwords as environment variables to avoid their being placed into a file. This is all fine and dandy, but I'm not sure how to make this work when trying to set up a continuous deployment workflow with some configuration management tool such as Salt/Ansible or Chef/Puppet.
Specifically, I have the following questions in environments using the above mentioned configuration management tools:
Where do you store connection strings/passwords/keys separate from codebases?
Do you keep those items in a code-repo of some type (git, etc.)?
Do you use some structure built-in to your tool?
How do you keep those same items secure?
Do you track changes/back-up these items, and if so, how?
In Chef you can
store passwords or API tokens in either encrypted data bags or using chef-vault. They are then decrypted while chef does the provisioning (with encrypted data bags using a shared secret, with chef-vault using the existing PKI of Chef client).
set environment variables when calling external software using the environment parameter of e.g. the execute resource.
not sure, what to write here -- I'd say you don't really manage them. This way you set the variables only for the command that needs it, not e.g. for the whole chef run.
With puppet, the preferred way is probably to store the secrets in Hiera files, which are just plain YAML files. That means that all secrets are stored on the master, separate from the manifest files.
truecrypt virtual encrypted disks are cross-platform and independent of tooling. Mount it read-write to change the secrets in the files it contains, unmount it and then commit/push the encrypted disk image into version control. Mount read-only for automation.
ansible-vault can be used to encrypt sensitive data files. A CI server like Jenkins however is not the safest place to store access credentials. If you add Hashicorp Vault and Ansible Tower/AWX, then you can provide a secure solution for several teams.
I have a "central" Mercurial repository, which configured to use HTTPS and requires authentication to clone-pull-push changes. Developers has their own repositories on their computers. They configure their local settings freely, and for example add section like
[ui]
username = anyname
to their local mercurial.ini file.
When a user try to push his changes to the "central" repository, he authenticates, but authentication info is not stored in Mercurial. Mercurial store locally configured username as revisions author in central repository. So I cannot find who really made changes in central repository, but I strongly wish to do it. Mercurial developers does not care about it and consider this behavior to be correct.
But I want to keep authentication info near changesets. I think the best way to do it is add one more additional field in revision description, like "pusher id" and store there authentication data.
Extensions I found do not implement similar functionality. Can you give me info about some third-party extensions, hooks, or just code templates or ideas how to do it? (I'm absolutly new in Python)
The fundamental problem that makes Mercurial developers (like myself) reject this is that changesets are immutable. It is impossible for a server to add extra information to the changesets when they are pushed.
More concretely: a changeset is identified by it's changeset hash. This hash is computed based on all the information the changeset contains, such as username, date, commit message, and the change itself. You cannot change any part of this, without also changing the changset hash — otherwise the integrity of the repository is destroyed.
This gives you security against accidental (or malicious!) changes made on the server: if Alice and Bob talk about "changeset X", then they can be sure they really mean the same thing. If the server (or someone else) could change the content of a changeset without affecting the ID, then Alice and Bob would not be guaranteed that "X" really means the same
thing in both their repositories. This property is of course also fundamental to the way Mercurial works when synchronizing repositories.
You have two options here:
You can let the server reject a push if Alice tries to push a changeset with Bob's name in it. This is can be done with a pretxnchangegroup hook on the server. It will inspect the HG_SOURCE environment variable and verify that the user listed there is also the committer of all pushed changesets between HG_NODE and tip.
You can let the server log the pusher. This is called a "pushlog". The Mozilla project uses one and the source appears to be here. There you make your server store information about who pushed what. This is done in a changegroup hook that logs the necessary information in a small database.
If you want a push log, then take a look at Kallithea, which has this functionality built in. Kallithea is in general a great way to host Mercurial repositories! It has much more functionality than the normal hgweb CGI script.
We have SSIS package config files that contain DB encryption passwords or PGP encryption passwords. I came to the conclusion that there is no "silver bullet" solution for encrypting SSIS package config files like with web.config files ect.
Should we consider not using config files at all for SSIS packages and if so what other options do we have available for storing settings?
Encryption of configuration files are not handled by SSIS itself. You can use NTFS encryption and/or ACLs to control access to config files and contents. It beats learning and administering a new access/encryption mechanism, and nicely ties in to your AD efforts.
Another option is to store the configurations in a SQL table and use SQL security to control access, but most administrators seem to prefer file-based management.
Could you use a table for config storage and lock down access to it? Throw that database/log/backup in an EFS protected folder and the only people that could access would be SQL sysadmins/or authorized accts and whoever has access to decrypt efs with a recovery account and restore the database (domain admins?).
You could also use SQL 2005's native encryption and write your own procedure to access the data and then set the connection properties in a script task. I haven't done this, but theoretically it might work.
While storing configuration information in a database is a viable alternative, if you are stuck with XML configuration files (for a variety of reasons), you may try BI xPress Secure Configuration Manager or SSISCipherBoy (freeware, I am affiliated to this project). These two utilities answer your question precisely.