Product Documentation

    The strongauth credential is the only one that has direct access to cryptographic keys in the cryptomodule. This access is enabled through the web service application that provides cryptographic services to requesting applications. This web service application—called EncryptionService—working though a back-end module, must have knowledge of the three PINs that guard cryptographic keys in the cryptomodule. Without knowledge of the PINs it is incapable of encrypting, decrypting, generating hashed message authentication codes (HMAC) and verifying them.

    While the strongauth credential does not require any other privileged access on the system (that may compromise the system), the fact that this credential has access to cryptographic key material that can disclose sensitive data—such as a credit-card's Primary Account Number (PAN)—makes this account highly sensitive. Consequently, it must be protected as diligently as the privileged root account of the system.

    The following controls can help protect the strongauth account:

    Control Description

    Setup an unlock account on the Linux system (if it hasn't already been created for controlling the root account)

    This account becomes the fail-safe measure to recover access to the strongauth account in the event it is needed for extraordinary administrative actions.

    Add the unlock account to /etc/sudoers with the ability to unlock the root account.

    Replace the <FQDN> with the fully qualified domain name of the SAKA server:

    unlock <FQDN>=/usr/sbin/usermod --unlock strongauth

     

    Add the normal Linux account of the Systems Administrator to /etc/sudoers to perform SAKA-specific SA tasks (as defined by company policy).

    This ensures that SAs can perform their day-to-day jobs with the SAKA software—backup, restore, log management, performance management, patching, etc.

    These accounts must be the only legitimate means of managing the SAKA software.

    For tighter control, depending on company policy, sites may add multi-factor authentication tokens to the system to ensure only legitimate SAs with 2-factor tokens can login into SA accounts on the SAKA.

    Add these watches to audit modifications to various configuration files.

    This first watch listed below will monitor for writes, appends and reads of the /etc/sudoers file and log them. Logged records can be searched with the filter key sudoers.

    The second will watch for execution of the sudo command and log them with a filter key of sudo-exec.

    auditd should be turned on to monitor for access to the sudo command and report it to appropriate authorities for review (third-party reporting tools may also be used for this purpose, if desired). The generic auditctl command is:

    auditctl -w <file> -pwar -k  <filter key>

     

    <file>

    <filter key>
    shell>STRONGKEYLITE_HOME/etc/strongkeylite-configuration.properties shell>strongkeylite-configuration
    shell>GLASSFISH_HOME/domains/domain1/config/domain.xml shell>glassfish-config

    Finally, lock the strongauth account on the system.

    This has the effect of disabling the strongauth account so no one can gain access to the account.

    shell>/usr/sbin/usermod --lock strongauth