Callpotential’s application makes extensive use of our customer’s data and as such, protecting the data we store, transmit and manipulate is mission critical to the success of our company.   Callpotential continually strives to be an active participant in the AWS shared responsibility model and implement security measures as a core component of our platform.

How customer data is obtained

While some of the sensitive customer data is entered by users into our application directly, much of the data is obtained through API access provided via property management software.  While each system is implemented differently, there are some key principles that must be adhered to:

1. Data may not be physically stored in local storage on servers processing data

2. All communications between 3rd party systems and CP servers must be encrypted using SSL/TLS1.2 or higher.

3. SSL/TLS1.2 or higher connections are required to access CP databases and data stores

4. Services may not cache data locally or create local copies of any data

How customer data is stored

The source of truth for customer data is our production database housed in AWS Aurora.  Aurora provides an encryption-at-rest storage layer using RSA2048 bit SHA256 managed keys and provides encryption-in-transit using SSL.   Elastic search, used to provide caching of customer data and long CP historical data is provided via a managed service and also provides encryption-at-rest and encryption in transit via SSL.

In addition to the application database, Callpotential uses Snowflake data warehousing to power its reporting and BI offering. Customer data is pushed into snowflake at a routine interval using an SSL/TLS1.2 or higher connection from within the Callpotential application’s Virtual Private Cloud (VPC) with no intermediate caching of data.  Data housed in Snowflake is not accessible to CP services or CP personnel except for those working on the data team.  Snowflake data is only accessed via the BI tools we provide in the application.

Who and what can access data

Support personnel when troubleshooting customer data may access customer data using the read-only access provided to them.  Access is granted on an individual basis using unique credentials.

Production data may not be downloaded, installed into local development systems, copied, or cloned for any reason. We’ve established development data for this purpose. 

Non-production environments may not have access to production data. Conversely, production environments shall not have access to non-production data.

How data can be accessed by people

All data access by people must be accessed via the provided ssh tunnel. Keys are generated by engineering and handed out to individuals.  The bastion host shall be the only means to access data outside the platform.

How data can be accessed by the platform

Data is only to be accessed by application services and code contained within the AWS VPC. Any components housed outside the VPC (CDNs, client-side code, etc) will never have direct access to the data. The callpotential infrastructure establishes a network security layer preventing external access and security groups restrict access within the VPC to platform components which need data access.

External References

AWS:

• https://d1.awsstatic.com/whitepapers/aws-security-whitepaper.pdf

• https://aws.amazon.com/compliance/shared-responsibility-model/

• https://aws.amazon.com/blogs/database/best-practices-for-securing-sensitive-data-in-aws-data-stores/

• https://aws.amazon.com/blogs/security/

Snowflake:

• https://docs.snowflake.com/en/user-guide-admin-security.html

• https://docs.snowflake.com/en/user-guide-data-share.html

Elastic Search:

• https://qbox.io/blog/elasticsearch-netty-secure-ssl-tls-implementation/

Twilio

• https://www.twilio.com/legal/security-overview