Management of sensitive keys and secrets

This document specifies how HeartAI platform components and HeartAI administrators and developers manage cryptographic keys and secrets. This includes private certificates, user credentials, and sensitive configuration parameters.

Policy

  1. Overview
    1.1. The following policy defines the responsibilities and obligations of HeartAI platform components and HeartAI administrators and developers when managing sensitive keys and secrets.
    1.2. This includes this management of three types of use cases with this information:
    1.3. The first use case is sensitive certificate information, such as the private key of a digital certificate. These keys are broadly used within HeartAI for the implementation of cryptographic protocols at network endpoints, such as web server endpoints and network appliance endpoints. This typically occurs both at externally facing HeartAI network endpoints in addition to internal HeartAI network endpoints.
    1.4. The second use case is user credentials, such as passwords, identity tokens, access tokens, refresh tokens, and biometrics. These are used in a broad variety of settings and these should not be exposed unnecessarily. The sensitive information of the user itself is governed by the corresponding policy section: Policy: Management of sensitive information.
    1.5. The third use case is sensitive configuration parameters, such as hostnames, network locations, service principal keys, and other such information that is often required to be injected into operation environments at runtime. It is important to manage this sensitive information in such a way that it is well-managed by platform components and doesn’t risk exposure to logs or software source code.
    1.6. Both the specifications and implementation of these sensitive keys and secrets is considered in addition to how these are managed and operated within HeartAI platform environments.
  2. Management of sensitive certificate information
    2.1. Sensitive certificate information includes in particular cryptographic private keys.
    2.2. When this information is deployed into an environment, such as a web server endpoint or network appliance endpoint, the injection of this information must be done in such a way that this information is securely input into the corresponding environment. This may include methods such as through environment variable injection or through configuration of an operating system image. This information must not be unnecessarily exposed throughout these processes.
    2.3. Sensitive certificate information should be rotated periodically. For HeartAI platform environments, this is specified to be 3 months. For sensitive certificate information that is provided by third-parties the rotation period of the third-party may be enforced.
  3. Management of user credentials
    3.1. User credentials includes information such as passwords, identity tokens, access tokens, refresh tokens, and biometrics.
    3.2. User passwords are typically provided to users initially as temporary passwords. The user will use the temporary password to create their own password. User-created passwords require at least 8 bytes of credential entropy with restrictions against commonly-used and dictionary phrases. In addition, multi-factor authentication should be enforced through integration with phone-based multi-factor authentication applications.
    3.3. Access tokens must be short-lived and regularly rotated. These tokens should have an expiry time no greater than 60 minutes.
  4. Management of sensitive configuration parameters
    4.1. Sensitive configuration parameters includes information such as hostnames, network locations, service principal keys, and other such information that is often required to be injected into operation environments at runtime.
    4.2. When this information is deployed into an environment, such as a web server endpoint or network appliance endpoint, the injection of this information must be done in such a way that this information is securely input into the corresponding environment. This may include methods such as through environment variable injection or through configuration of an operating system image. This information must not be unnecessarily exposed throughout these processes.
  5. Secure management of sensitive keys and secrets
    5.1. Event information relating to creating, deletion, and modification to sensitive keys and secrets should be logged and retained, and available for auditing as necessary.
    5.2. When removing sensitive keys and secrets, appropriate measures must be enacted to ensure non-recoverability of any sensitive information. This should include techniques such as entropy overwriting of the information.
    5.3. This information must be stored within platform environments in such a way that it is stored securely with an appropriate level of encryption at-rest.
  6. In relation to the ongoing review of this policy:
    6.1. This policy should be reviewed at least every 6 months. This review should assess the appropriateness of the existing policy, and should propose any modifications or extensions to the policy where needed.
    6.2. Modifications or extensions to this policy should be reviewed and approved by corresponding governing authorities.
    6.3. This policy welcomes suggestions and feedback.
  7. In relation to the governance and compliance of this policy:
    7.1. This policy must be understood and agreed to by HeartAI administrators and developers before the approval of access to HeartAI platform components.
    7.2. Where this policy does not provide a specification to, or conflicts with, a mandated SA Health or SA Government policy, the existing SA Health or SA Government policy will take precedence. HeartAI administrators will resolve policy deficits by approved modification or extension to HeartAI policy.
    7.3. HeartAI administrators are responsible for ensuring that this policy is compliant with SA Health and SA Government policies.