Replies: 2 comments
-
I agree - I think this is probably the most important security change we need to make to JIMI, and one we've known about with Web for a while. |
Beta Was this translation helpful? Give feedback.
-
2.0 was aimed to build upon the stability of the platform over the last 2 versions and enhance the overall user experience. I think this would be good to add to 3.0, but happy to consider it sooner |
Beta Was this translation helpful? Give feedback.
-
Currently jimi is split into two main components jimi_core and jimi_web.
jimi_core - requires access to the mongo database
jimi_web - requires access to all jimi_core instances and the mongo database
Due to the inherent database for jimi_web there is increased impact in the event of compromise as the entire database would be accessible enabling the manipulation of jimi_core instances as a direct result.
If the jimi_web architecture was changed to include the option of using jimi_core as a proxy for all requests then we can reduce the overall impact of a comprise that occurs on jimi_web instances.
Furthermore we can use differing private keys for session validation on the jimi_core and jimi_web instances as well as ensuring that jimi_web can only create encrypted values and remove the ability for it preform decryption.
With recent attacks published in relation to other monitoring products it is more important than ever to ensure that automation systems such as jimi have well thought out and implemented security features.
Beta Was this translation helpful? Give feedback.
All reactions