SONs active keys exposed in configuration
Description
If there is a possibilities that active keys getting exposed in the configuration, then the following ideas can be considered as a solution.
Mitigation Ideas
QA process to detect any key exposure
Proper code review has to be done before code merge to avoid conflict.
Process in place to cycle active keys.
Using active key of Operator account on server instead of SON account active key - Whether custom_permission can be used to limit the damage caused by any Key?
Can we make config files encrypted which can be accessed only via their own passphrase?
Is it possible to write SONs code not to be dependent on the active key ?
Any possibility to get certain config value comes from ENV variable?
Response Plan
Shut down SON, change the active key.
Vote out SON
Use Owner key to change the active key.
Responder Team
In order to find the solution/ to know in details about the risk that has happened, responder team is one to be communicated first.
First Responder Team
Point of Contact: SON operator
Second Responder Team
Point of Contact: The community, who can vote out SON
Last updated