December 8, 2017 | Written by: Daniel Dunn
Share this post:
IBM is rolling out an exciting transformation of our eCommerce portfolio. This is the fourth blog post in a series that formally introduces these advancements and reviews the architecture of the services from a technical point of view.
In this post, the author outlines security protocols that should be essential components of every digital commerce platform.
Post #1: Monolith to Pebbles: Transformation of the IBM Commerce Portfolio
Post #2: A New Approach to Customization for Commerce Platforms
Post #3: How to Build a Cognitive System
Security is one of the most important aspects of digital commerce. Without the proper protocols in place, online store owners can put themselves and their shoppers at risk for financial payment and identity fraud. In addition to the financial consequences, data breaches can damage the owner’s brand reputation, causing loyal customers to be reluctant to return and shop. IBM Digital Commerce, IBM’s multi-tenant SaaS eCommerce platform, now provides a feature-rich platform for online retailers to serve their customers, with business tools and underlying system infrastructure that are robust and secure, minimizing the risks of fraud and damage to your brand. In this blog, you will learn how IBM Digital Commerce (or IDC) makes use of a data vault, data encryption, and certificates to strengthen an online store’s security.
The Data Vault
A secret is anything that you want to tightly control access to, such as API keys, passwords for database and SFTP servers, and SSL certificates. This kind of data should not lie around and be publicly available in plain text. In fact, it must not be stored in plain text in any location. To store secrets the secure way by limiting access is always a challenge, but IBM Digital Commerce addresses this by making use of a vault management system to store and access secrets.
A vault management system is a network service which provides a safe and secure place for storing secrets, while providing tight access control and recording a detailed audit log. The following describes how IDC manages each tenant’s secrets with this vault service:
- Authentication and authorization – the IDC vault service works primarily with tokens. Each tenant specific token is assigned to a policy that constrains the actions and the access paths to only that tenant’s secrets. The vault is located behind the IBM Cloud external firewall and can only be accessed by the IBM Digital Commerce service running each tenant’s environment. Whenever a tenant’s Digital Commerce service needs access to the vault, it must provide its vault token so that it can be authenticated, and only then are the secrets for which this request is authorized accessible.
- Tenant isolation – each tenant’s environment is logically separated from one another using Calico, a secure network connectivity service for application containers and virtual machine workloads, and therefore it is technically not possible for one tenant to access another tenant environment’s token to gain access to other tenant’s secrets from the vault. Details will not be covered here in this blog as network isolation is a separate topic of its own.
- Data encrypted storage – when an IDC service creates an application-related key/value secret in the vault, this information is encrypted prior to writing to the vault’s persistent storage, so gaining access to the raw file system storage is not sufficient to access the tenant’s secrets.
- Audit trail – the system keeps a detailed log of all requests and responses to all vault services, including errors.
To reduce the risk posed by hackers, insider threats, and other malicious attacks, IBM Digital Commerce makes use of encryption to protect sensitive data wherever it is found across all tenant environments. This includes data at rest in application and web servers, file servers, databases, and network attached storage, as well as data in motion across the network.
Data-At-Rest Encryption (DARE) and Data-In-Motion Encryption (DIME)
Data-At-Rest Encryption (DARE) is a critical last line of defense. Transaction data of each online store, along with its shoppers’ sensitive data, is stored within each tenant’s IDC environment. The following illustrates how encryption applies security and access controls directly to sensitive structured and unstructured data wherever it resides in each tenant’s IDC environment.
- DB2 encryption – with database encryption, the database system itself encrypts the data before it calls the underlying file system to write that data to disk. This approach protects the data storage against physical theft of disk devices and privileged user abuse.
- Application encryption – IDC performs another level of one-way 128-bit encryption using AES to protect sensitive attributes, such as credit card and user password. AES is a more recent encryption algorithm and is widely considered to be the industry standard. This application level one-way encryption is slightly different from that provided by the persistence storage – with IDC application encryption, the encrypted data is never decrypted during the retrieval process. In the case of handling a user password, it is a common security practice to keep passwords encrypted during the authentication process. By using a user-specific salt, passwords are one-way hashed by using SHA-1 or SHA-256, and encrypted using a tenant specific merchant key stored inside of the vault.
- Lockout policies – in addition to application encryption, IDC also enforces password policies, such as password lifetime, length of password and change history, as well as account lockout policies, to provide additional protection to any online store data. For example, the two common account lockout policies are account locked out threshold, and consecutive unsuccessful login delay. An account lockout policy disables a user account if malicious actions are launched against that account to reduce the chances that the actions compromise the account.
- Access control – IDC provides a sophisticated fine-grain access control that allows complete control over who has access to what data, how much they can see, and what they can do with it.
- User access control – through an access control mechanism of logins and user roles, IDC provides security measures for multiple levels of customer service and administrative organizations.
- Service level access control – all IDC REST services ensure that the invoking user has appropriate access rights for the function being invoked.
In addition to protecting Data-At-Rest Encryption (DARE), IBM Digital Commerce also addresses threats to sensitive data as it traverses networks. Data-In-Motion Encryption (DIME) ensures any tenant’s business data is protected from eavesdropping, surveillance, and overt and covert interception.
- Transport Layer Security (TLS) is used from the shopper’s web browser to a tenant’s IDC environment, and from the IDC environment all the way to the persistence layer. This means that the secure connection does not just terminate at the external load balancer – the secure connection is maintained from the end user’s web browser all the way to where the business data is stored inside of the IDC environment.
- SSH File Transfer Protocol (SFTP), also known as the Secure File Transfer Protocol, enables secure file transfer capabilities between the IBM Drop Server and each tenant’s IDC environment.
85% of Online Shoppers Avoid Unsecured Websites, per a survey from GlobalSign. For many shoppers, security was one of the top concerns, placing third as an overall reason people choose one site over another. To stay competitive and allow shoppers and business users to connect using a secure web browser session, IBM Digital Commerce allows each tenant’s Developer to manage their own 3rd party SSL certificate through IDC Self Service. There are two kinds of SSL certificates that can be managed in IDC:
- Client certificate – is a certificate that third parties, such as shoppers, use to verify communications with services deployed to an IDC environment. This process requires a certificate, the certificate private key, and all issued intermediate certificates that are required to validate the certificate against the existing root certificates.
- Trusted certificate – is a 3rd party certificate that an IDC service uses to verify communications with that 3rdThis type of certificate only contains a certificate entry. For example, to enable IBM Order Management as your backend order management system, you will need to import the IBM Order Management server certificate to the trust store of your IDC environment. See Configuring two-way SSL authentication between WebSphere Commerce and Order Management for more information.
Each tenant’s IDC environment treats a custom SSL certificate just like other environment specific assets, meaning all SSL certificates are stored inside of the vault.
In this era of cloud computing, security is such a fundamental element that it can really define the trustworthiness of the underlying platform infrastructure. When a cloud platform does not have the proper security protocols in place, online businesses can put themselves and their shoppers at risk for payment and identity frauds. Data breaches can also destroy brand reputation and scare away loyal customers. To address cloud security issues, IBM Digital Commerce has implemented many security measures with the vault for storing secrets, and data encryption for protecting sensitive data wherever it is found across all tenant environments. Merchants can therefore have a peace of mind when running their businesses online.
For documentation and updates on IBM WebSphere Commerce V9, visit the knowledge center.