Hello, On 9/19/24 12:33 PM, Edward Shryane wrote:
This in turn makes the API keys unsuitable for use by automated systems (e.g., integration with an IPAM system), as one certainly do not want those to stop working simply because the person who created the API key in the first place quit the company and had their user account deleted. If IPAM integration stop working, it must be straightforward to identify the cause and solution (i.e. that API key no longer works, generate a new one).
That's typical "developer's" reaction... make it someone else's problem. But there's another reason why it's better to have the API keys associated with the organization and not with individual accounts. In case of key compromise, it needs to be invalidated as quickly as possible. Anyone from the organization must be able to do this. From the point of view of the organization, it is very important to see ALL active keys. And not to think about whether a specific user generated an API key or not. NIS2 makes this even more critical for many organizations. Yes, this can be somewhat circumvented by organization shared account. But that's not the best solution from a security point of view. But this still won't solve the problem that other user will generate a key for himself as well. Sure, we try to graft new things onto the really old database. But the maintainer object should be a I think associated with the organization, company. Not with a person. It's not that easy with SSO authorization (like webupdates), but that's easy with API keys. This just wants to change perspective and not try to tie everything to a person. Security cannot really be solved by saying "and that's your problem". So I support idea of having API keys linked with organisation. From a security point of view, it will be more transparent. - Daniel