SSH Key Rotation

[BenGarrison]

I am curious what your strategy for key rotation looks like? I want to dive into some POC's for key rotations and how we might be able to leverage the SSH management within JC

[steven]

We currently don't enforce SSH key rotation, since we have no way to 'police' it.

For our organization, ideally we'd have our developers roll their keys once a year at minimum. It would be really nice if we had an option globally to enforce SSH key rotation... What would be even better is if you had that, plus we could add override settings with a user group.

Fictional use case example: We have a client with a lot of PII stored on their server. Per legal regulations our keys need to be rotated once every 90 days. Only a subset of our developers have access to this particular server (managed via a User Group, which grants access to that device), so I don't think it's fair to force all of our developers to roll keys every 90 days. SO... If developer is in that user group, then force rotation every 90 days.

Here... I even mocked it up for you 😉

[BenGarrison]

What an amazing mock-up! I will actually send this to my product team. With a feature request! Unless you want to do so, and I can attach this image to the card

[steven]

Haha, Go ahead and get it submitted! I'd love to see this feature implemented

[sam-gt]

Is there a way to +1 a feature request? We're rolling out a new compliance framework that requires this too... Only way I can think to do this is to delete the Devs' public key from their portal and tell them to generate a new one, or run a new one for them. But that sounds super un-scalable...

@BenGarrison have you heard of anyone using a 3rd party KMS with JumpCloud, or have any ideas how something like that could work?

[sam-gt]

Dropping this in here in case anyone else finds it useful. This was the guideance shard with us by our compliance team re: how to meet this standard.

I think we're going to try out a solution where we have a network requirement on top of ssh keys for user access, with the network access tied to a JumpCloud user group, and see if we can pass with that...

From the experts:

Annex A control 10.1.2 has the following as part of the implementation guidance in 27002 in terms of rotating keys:

"A key management system should be based on an agreed set of standards, procedures and secure methods for:
exchanging or updating keys including rules on when keys should be changed and how this will be done; In order to reduce the likelihood of improper use, activation and deactivation dates for keys should be defined so that keys can only be used for the period of time defined in the associated key management policy"

Keep in mind that 27002 is only guidance. This does not mean you have to rotate keys, it means you need to consider whether rotating keys is necessary for mitigating risk.

A certification body is going to audit against the control, which states that "A policy on the use, protection and lifetime of cryptographic keys shall be developed and implemented".

At the surface level, the control does not require key rotation, it requires that a policy is implemented to manage the lifecycle of keys. If you feel key rotation is not necessary, I would recommend removing this from your policy. If you call it out in your policy and don't implement it, a certification body will probably call it out as non-conformity. However, simply not rotating keys would not be called out as a non-conformity in itself, unless it was deemed necessary as part of mitigating risk as part of your ISMS.