0.0.1 - CI Build
0.0.1 - CI Build
SequoiaProjectHealthcareDirectoryImplementationGuideSTU3 - Local Development build (v0.0.1). See the Directory of published versions
Previous Page - Operational Best Practices
The Sequoia Healthcare Directory has several key security considerations which will be discussed in this section.
Client software must be configured to use 2-Way-TLS with mutual authentication. This approach provides assurance to both sides of any transaction that the other party is authentic. CONF: Directory client software MUST authenticate the server using 2-way-TLS.
As discussed elsewhere, since access to the PROD directory requires a Sequoia-issued x.509 end entity certificate, your organization should protect your environment and the private key associated with that environment using all applicable IT best practices for the use of keys used to establish secure connections AND authenticate connectivity. Such practices are outside the scope of this document, but should include, without limitation, practices such as never backing up or moving a private key off of the environment for which it is intended to be used, never sharing the private key, restricting access to the private key to need-to-know only staff, and deploying it in a securely managed data center. Client x.509 private keys must be managed using best practices, such as, without limit: OWASP FBCA NIST FIPS The Sequoia Project technical support knowledge base
The nature of RESTful calls, even those occurring inside an HTTPS (TLS) secure tunnel, exposes the entire URL to some intermediaries between client software and the Sequoia Project Healthcare Directory server. Specifically, various logging software, such as within low-level TLS libraries, or client stacks, may log the URL in its entirety, in plain text format. Full URLs should not be shared with others (such as would occur when an end-user copy/pastes the URL for diagnostic purposes with a peer) because they contain client API Keys. If you are testing the Sequoia Healthcare Directory using a web browser, then the browser may store the URL, including the API Key, in the browser history. If the client software library is written in JavaScript, then attacks such as the Proxy Auto Conf (PAC) vulnerability may also expose the URL and the API key. Other scripting languages used for retrieval or debugging may also contain this value hard-coded. In the event you reasonably suspect that your API key has been obtained by an unauthorized party, then please email Sequoia technical support to request a new key and to ask that the prior key be retired. Note that the actual risk from a compromised API Key is mitigated by the requirement, outside of the DEV environment, to establish a TLS connection using a Sequoia Project-issued x.509 certificate.