Client Network & System Requirements
Zingle is a fully cloud-based platform with no on-premise software nor servers required. As such, the system requirements to allow usage of Zingle are rather simple.
Zingle’s Team Inbox requires a modern web browser (supported versions viewable here ) and the ability to access Zingle’s systems using standard HTTPS over port 443 with TLS 1.1 or higher.
The domains used by Zingle’s system are:
d.zingle.me (if using leased Zingle printers)
To provide maximum system availability Zingle uses AWS Elastic Load Balancers (ELB). ELBs do not support static IP addresses and as such Zingle is unable to provide blocks of IP addresses for firewall whitelisting. If you are unable to whitelist the domains listed above please contact your Zingle account manager for possible workarounds.
All of Zingle’s infrastructure is hosted with Amazon AWS. Our primary infrastructure resides in AWS’ Oregon data center. Zingle has redundant storage of all customer data in multiple AWS regions with snapshots saved to secure AWS S3 buckets four times per day.
Zingle’s engineering staff utilizes local development environments (on their own computers) which contain nor have access to customer data. Zingle’s testing and staging environments also do not contain nor have access to customer data. These environments are hosted with AWS but are sandboxed in Virtual Private Clouds (VPC) that have no network access to the production environment.
Zingle uses three systems for data storage: MySQL (primary data store), ElasticSearch (message and contact indexing), and Redis (cache, queue, and session management). None of these systems are directly accessible from the public internet. Access to these systems is only allowed from other internal segments within Zingle’s production Virtual Private Cloud (VPC) Only AWS-hosted Zingle application servers have access to Zingle data stores.
All production Zingle data stores encrypt data at-rest using disk encryption mechanisms provided by AWS. All encryption keys are managed by AWS’ Key Management Service. All data in transit is encrypted using TLS 1.1+. This includes data transmission between clients (customers) and Zingle’s systems as well as data transmission between Zingle systems within the production VPC. The only exceptions to this policy are integrations with 3rd-party systems on behalf of customers that do not support encryption. For example, Oracle Opera is able to send room-ready messages but not using HTTPS, therefor we allow this information to be transmitted to us by Opera unencrypted, but only when this functionality is demanded by a customer. Integration with such 3rd-party systems is optional and only enabled upon customer request.
Operating system and software security patches are installed on all Zingle system regularly. Systems approaching end-of-life (due to removal of vendor support) are upgraded or removed prior to vendor support being terminated
Automated dynamic vulnerability scans are carried out nightly against the QA environment (to ensure that coming releases do not introduce security issues) and weekly scans are carried out against the production environment. These scans check for known general security vulnerabilities (including OWASP Top 10) as well as possible security vulnerabilities in the languages and frameworks used by Zingle’s platform.