Automatic Key Management

Regular key rotation and expiration are common requirements in security and compliance frameworks. Outside of those requirements, the operational cost to your administrators and counterparties rarely justifies the security benefit. If your organization has no mandate for key rotation, you probably don't need these features.

Key Lifecycle Rules let you define policies to automatically remove dormant security keys, either SSH keys or GPG/PGP keys.

Key Lifecycle Rules

Site Administrators and Workspace Administrators can define and manage Key Lifecycle Rules. Each rule targets a single type of key: either SSH keys or GPG/PGP keys.

Each rule must also specify the number of days the key can be unused before it is removed automatically. For an SSH key, this is the time since the key was used by a user account to connect to your site. For a GPG/PGP key, this is the time since the key was used for a cryptographic operation (encryption, decryption, or recryption).

Rules for GPG/PGP Keys

For GPG/PGP key rules, the rule must include Inactivity Days, or the number of days a key can be unused before it is removed automatically. This represents the time since the key was used for a cryptographic operation (encryption, decryption, or recryption).

Rules for SSH Keys

Key Lifecycle Rules for SSH Keys apply to only SSH public keys linked to Users for SFTP/SSH login. SSH keys stored in Remote Server configurations are not affected.

For SSH rules, you can configure Inactivity Days, Expiration Days, or both. At least one is required.

Inactivity Days removes the key automatically after it goes unused for the specified number of days, measured from the last connection to your site. Keys that have never been used are removed after the same number of days from the date they were added.

Expiration Days marks the key as expired a set number of days after its creation date. Expired keys cannot be used to authenticate.

When both values are set, if the key's lifetime reaches the expiration before it reaches the inactivity threshold, the key is expired and cannot be used for authentication. Expired keys remain in the list until they go unused for the length of the inactivity threshold.

How Key Removal for Inactivity Works

When GPG/PGP keys are removed by a lifecycle rule, automatic encryption, decryption, or recryption behaviors that use that key are not removed. When a new file operation triggers a behavior that uses a deleted key, the GPG cryptography fails and an alert email is sent to site administrators.

When an SSH key is removed, the user account associated with the key is not disabled or removed. If the user account has no other authentication methods or valid keys, it can no longer connect. Only SSH keys associated with a user account are affected by lifecycle rules. SSH keys stored in Remote Server configurations are not deleted by lifecycle rules.

How SSH Key Expiration Works

Expiring an SSH key does not delete the key from your site. The key is marked as expired instead. It does not matter how recently the SSH key was used. When the expiration date is reached, the key is expired.

Once the expiration date has passed, expired SSH keys can no longer be used to authenticate. An expired key is not deleted from your site.

Files.com sends reminder emails to an expiring key's owner 28 days, 14 days, 7 days, and 1 day before the expiration.

SSH Key Expiration Dates

Each SSH key's expiration date is calculated as the rule's Expiration Days value after the date the key was added to Files.com. Adding, modifying, or removing an Expiration Days rule immediately updates the expiration date on all affected keys.

When you save an SSH key expiration rule for the first time, any existing SSH key older than the Expiration Days will be treated as expired immediately.

When the rule is removed, the expiration date is removed from all affected keys and previously-expired keys can be used for authentication.