|
|
|||
|
|||
|
As we move more into the cloud we are noticing an issue that may become a problem in the future.
I know how big companies do it, but we are at a disadvantage with commit. We cant control access by asset. We keep accounts, passwords, etc on file for customers. When they need a "password" reset or just need to know what it is, we give it to them. What happens when someone asks for a password to a resource they shouldn't have? How is our staff to know who has access to what? An easy fix = If we could password or pop-up protect assets. Lets say Julie calls from acme construction. Her boss needs his email setup on his phone. They need the login info for their hosting account. if julie her her PIN our support staff could easily know shes authorized and reset the password or whatever. 2 things could work; 1) A pop-up thst said [Sensitive Info | Account challenge] that informs our staff to authenticate the person before giving out any information would work. We dont need it for the entire account, just specific assets. 2) For certain assets my staff would have to put in a pin that the customer should have. Before the entered the pin they could only see the asset name. We could set the pin requirement for staff depending on their level, access, etc. ------------------ When we were smaller i knew the boss and knew julie. I could just give it to them. As I add staff everyone doesn't know every customer like i do. The bigger we get the more likely i see an issue happening where someone gives out information they shouldn't. I know we can tell everyone never to give out passwords unless we know they are supposed to have it, but that seems error prone. If my support staff had to enter a PIN to get access themselves, then the customer has to have it, or the request has to get escalated up to a supervisor who has more access. Thoughts? |
|
|
|||
|
|||
|
Thank you for posting this, lot's of good ideas here!
A built in access manager to sensitive information may indeed be a useful tool. We will take a note about your suggestion how it can work. What you may want to consider is storing sensitive Asset/customer information inside of an encrypted document, for example a password protected Word file, and attach it to the relevant Asset or Account. Provide the file password only to the relevant staff, then, whenever access is needed doubling this attached Document in RangerMSP will give authorized users with access to the sensitive information. I hope this helps. |
|
|
|||
|
|||
|
I have been asking for this for about five years... not for the ability for us to store security sensitive information directly into CommitCRM (even Commit doesn't recommend doing this, instead, attach an encrypted document if you must have that info there) but to have a way to track the rights, privileges and other information at a Contact level. Unfortunately Commit seems to think that 12 fields is enough to detail all the information we need to have in order to work with Contacts... you know, those people we actually work with and for every day... it's just crazy that we don't have more fields (seriously, how hard is it to add another dozen fields to contacts!).
So our current solution for this issue is to use the only field we can customize, the "Contact Code" field (not sure if this is the default/original name). We have set this up to track what each Contact can request of us and what rights they have in the system. Basically we have set up a list of rights, called roles, which indicate what each users has access to and can request of us. Our current list of roles is as follows:
Every person that requests support MUST be in our system AND they must have a code assigned to them. If they don't, we explain the situation and ask them to have one of their authorized persons call in to authorize them in our systems so we can proceed. So if Joe Smith is assigned the "Helpdesk" role and asks us to reset another users password, we don't do it. But if Jane Jones is assigned the "User-admin" role, she can ask us to reset the password of any user with rights at or below her role level. This process is a bit tedious but it's the only way we have been able to come up with to track and work with all the different contacts we have in our systems. What would make this better is if Commit would give us more Contact fields to work with AND the ability to do multi-select lists (something similar to the new labels for Tickets -- these lists need to be specific to the field though!). Multi-select lists would allow us to define and assign rights directly to Contacts (in addition to the roles we are using), which would make this somuch easier to understand and track! Commit: WE NEED MORE FIELDS FOR CONTACTS AND THE ABILITY TO USE MULTI-SELECT LISTS! //ray |
