Encryption is a major component to help ensure the authenticity, integrity, and confidentiality of data in transit. The following article discusses:
- Encryption in Transit (API Access, Media Files, Email)
- Encryption at Rest (Assets, Data, Logs)
API Access
Wildmoka enforces HTTPS, HTTP2 or WSS for all traffic over external networks. No authenticated connection is allowed via HTTP, WS or other clear-text protocols. Wildmoka only uses TLS 1.2+.
Internal data transfer is on RFC 1918 private IP addresses and may sometimes be sent in clear text within secure facilities, for example for traffic between virtual machines or within a kubernetes cluster. All traffic which leaves the secure facilities is encrypted.
We have audited the details such as the certificates we use and their effectiveness and that they conform to the latest standards and that we use TLS 1.2 or better with industry-standard strong encryption algorithms.
Media files
All files that are stored in Wildmoka provided storage are secured and encrypted using AES-256 and are transferred using HTTPS Protocol.
When transferring assets, Wildmoka uses time limited signed URLs which are created on request, making sure the requestor is authenticated, has the correct roles and permissions to upload the file. This signed URL is sent to the user’s browser which then uploads the file directly from the cloud bucket.
Wildmoka's internal access to assets is authenticated internally and uses HTTPS.
For custom sources or destinations, customers have full control over the encryption keys used, including encryption algorithms and key rotation intervals.
Data
All customer data is stored with Encryption at Rest. Our internal databases and search services are backed with redundant SSD drives with AES-256 with integrity and replicated and chunked across multiple storage devices and servers. They are encrypted using full disk encryption using AES-256 and it is not possible for customers to bring their own keys to encrypt database content.
We do not store any PCI or sensitive billing information at all.
System disks
All compute systems involved in Wildmoka use full-disk encryption using AES-256.
System Logs
System logs are logs which are produced by the system and are intended for our engineers to be able to monitor and trouble-shoot the different system components. System logs are stored in Microsoft Azure Storage and are protected using AES-256 encryption.
Audit Logs
Audit logs are per-request logs which are generated by our APIs and are stored in a secure database with AES-256 encryption.
All outbound email from Wildmoka is sent securely to a third-party email service, Google, using HTTPS. Email is sent from Google using encrypted connections if the receiving end supports this, otherwise emails are sent in clear text.
Custom sources and destinations
When you add your own custom source or destination to Wildmoka, it is your responsibility to make sure that the storage meets your security needs. To make your storage more secure:
- Restrict the access that is needed by Wildmoka to be the bare minimum that we require. We will warn you in the GUI if we don’t have sufficient rights.
- Do not share the Wildmoka Cloud storage access credentials anywhere else.
- Use our UI for Cloud Storage if you require to rotate those access credentials regularly.
- Turn on audit logging, and any other security logging features for the Cloud buckets
- Make sure that the cloud storage audit logging information itself is secure, such as logging to another bucket with restricted access.
Questions
If you have any questions or concerns please use the Support form and we will be happy to help.