SSH Key Management

How Joyous keeps SSH keys secure for transferring people data via SFTP

This document is only relevant for organisations who send Joyous a CSV people data file via SFTP. If your people data is transferred via a system integration such as Microsoft Azure Active Directory, the transfer is secured by the Microsoft Azure API.

A number of internationally recognised standards exist for the management of keys for SSH-based access management to ensure security. This article summarises key recommendations from the following standards from the National Institute of Standards and Technology (NISTR), and notes how Joyous adheres to each:

  • NISTR 7966
    Security of Interactive and Automated Access Management Using Secure Shell (SSH)
  • NISTR SP 800-131A
    Transitioning the Use of Cryptographic Algorithms and Key Lengths
  • NISTR SP 800-57
    Recommendation for Key Management: Part 1 – General

1. AWS Security and Compliance

Joyous relies on AWS adhering to best practices when managing SSH keys and SFTP servers. AWS does not surface the implementation details, but we can be confident that a first-tier cloud service provider such as AWS will adhere to the industry standards.

According to AWS Security & Compliance documentation:

  • AWS Transfer Family is compliant with PCI-DSS, GDPR, FedRAMP, and SOC 1, 2, and 3. The service is also HIPPA eligible
  • AWS Transfer Family is FISMA compliant

AWS Transfer Family supports the following clients:

  • OpenSSH (macOS and Linux)
  • WinSCP (Microsoft Windows only)
  • Cyberduck (Windows, macOS, and Linux)
  • FileZilla (Windows, macOS, and Linux)

2. Secure SSH Implementation

NISTR 7966 makes a number of recommendations regarding secure SSH implementations, including the following:

a. Disable SSH v1 protocol

AWS enforces this practice on all infrastructure used by Joyous.

b. Disable unapproved authentication methods

Joyous uses the TransferSecurityPolicy-2018-11 for the transfer security policy. The policy explicitly specifies the allowed authentication methods and disables all other unapproved methods.

c. Prevent implicit access

SSH accessible accounts and groups (including root) are limited. All Joyous SFTP users assume a role which is only able to perform the following set of actions:

  • PutObject
  • GetObject
  • DeleteObjectVersion
  • DeleteObject
  • GetObjectVersion

d. Use approved ciphers.

AWS maintains a list of approved ciphers for the SFTP server.

e. Enforce SSH inactivity timeouts.

AWS enforces SSH inactivity timeouts when connected to the SFTP server.

f. Use least privileged access model.

Joyous SFTP users are bound to their home directory.

3. SSH key properties

Industry standards including NISTR 7966 make a number of recommendations about SSH key properties, including the following:

a. Minimum key length and approved algorithms

NIST SP 800-131A recommends a minimum key length for RSA keys of 2048 bits.

Joyous server host RSA keys are 3072 bits.

b. Maximum key lifetime

In accordance with the standard NIST SP 800-57 Joyous cycles the user symmetric key every 2 years.

c. Identity key access Control

NISTR 7966 recommends that users with access to the keys is limited and users with access to keys have limited access control.

Joyous uses keys for authentication, and user privileges are restricted with role policies.

d. Identity key passphrases

NISTR 7966 recommends that keys should be protected by a passphrase.

All SSH keys in Joyous are stored within LastPass, a secure information storage service, protected by a passphrase.

e. Identity key duplication

NISTR 7966 recommends that keys should not be duplicated and copied to other systems. If this is occurring, it is recommended to tightly monitor and investigate these duplicated keys.

Joyous customer keys are only used to create users for the SFTP server. The keys are not duplicated for use anywhere else.

f. Authorized key access control

NISTR 7966 makes the following recommendations for key access control:

  • Maintaining control of who can access what information.
  • Properly identifying users accessing the system.
  • Preventing a user from accessing the system after his/her account is terminated.
  • Ensuring that users cannot bypass privileged access systems.
  • Controlling remote access.
  • Enforcing authorization boundaries.

Joyous stores customer keys in a secure LastPass vault location. Only a set number of people have access to this location.

g. Authorized key source restriction

In accordance with NISTR 7966 the keys for a given organisation only allow read and write functions within the directory designated for the organisation. Commands are restricted for all other directories.

h. Authorized key source restriction

Joyous SFTP servers have security groups that can be configured with IP allow-lists to limit authentication from a specified list of IP addresses.

Due to orgnizations connecting to Joyous from different configurations, including non-static IP addresses, this functionality is not currently implemented.

i. Replacing keys on compromise/reassignment

Joyous supports key cycling in the event of key compromise or key expiration.

j. Usage logging

NISTR 7966 recommends logging key fingerprints based on activity on the SSH server.

Joyous logs the user when logging SFTP activity, which allows Joyous to track the SSH key used.

k. No environment crossing

NISTR 7966 recommends that the same keys are not uses in different environments. Compromise in one environment should not result in compromise in another environment.

Joyous does not use the same customer keys between different environments.

4. SSH key lifecycle

In accordance with the standard NISTR 7966 Joyous regularly reviews and reauthorizes SSH keys. Keys that are no longer in use are terminated.

5. Continuous monitoring and auditing

a. Keep a baseline of authorized keys and periodically match actual keys against expected

Joyous keep a log of customers using our SFTP servers. When a customer no longer uses our SFTP server Joyous will go through a process of terminating the SSH key.

b. Log activity for each key

NISTR 7966 recommends keys which have had no activity for prolonged amount of time should be revoked. Keys should be used from approved locations.

Joyous logs all SFTP server activity. Joyous periodically check customers data integration. If no integration has been done after a period of time, Joyous will enquire whether the customer is still using the SFTP server.

Joyous does not currently use IP whitelisting however are adhering to the other recommended practices of NISTIR 7966.

5.  Inventory and remediate SSH keys

a. Remove keys that do not comply with NISTR 7966 recommendations

When Joyous identify keys that do not comply with our Joyous standards we remove their access to our SFTP server.

b. Structured process for adding new SSH keys

Joyous follows a structured process to add new users to the Joyous SFTP server.

6. Automate processes

NISTR 7966 recommends with many SSH keys to have a system to automate removal and addition of SSH keys. This is due to it becoming increasingly difficult to ensure that the inventory of the keys is correct.

Joyous currently have a manageable number of SSH keys. Joyous can easily revoke/change customer SSH keys when required to do so.

7.  Educate executive management

NISTR 7966 recommends that management and engineering teams understand the importance of SSH keys.

The Joyous team that manages SSH keys are made aware of the importance of SSH keys and the severity if there were to be exploited. Joyous ensures to educate whoever becomes involved in the handling of SSH keys.

Joyous also ensures that only a set number of team members have access to the SSH keys.