Network and app architecture
The diagram will give you the fastest overview of Robin's service architecture.
Robin is a cloud service, and hosted by data centers with the highest level of certifications including ISO 27001 and SOC2. For more compliance information, you can visit AWS Security and AWS Compliance.
All application servers are based in the US, but may be accessed internationally via the internet. Robin’s CDN serves static assets (e.g. webpage stylesheets, avatar images) from servers across the world, but does not touch sensitive customer data.
All customer data is stored on AWS services, which follows a strict decommissioning policy outlined at https://aws.amazon.com/compliance/data-center/data-layer/
"When a storage device has reached the end of its useful life, AWS decommissions media using techniques detailed in NIST 800-88. Media that stored customer data is not removed from AWS control until it has been securely decommissioned."
For customer-specific data, we will manually remove all identifying calendar data associated with your account from our database on request. Derivate anonymized data (i.e. "Total events booked on platform this month") will not be removed, as it cannot be linked back to source data. User accounts associated with your organization may also be removed on request. We retain backups for 30 days, after which time the data will be completely unobtainable.
We constantly monitor our service performance and have automatic notifications to ensure rapid response for service interruptions. All code is audited and peer reviewed before deploying to production servers. We also monitor updates from the security community and immediately update our systems when vulnerabilities are discovered. When we do have issues reported, we keep an updated system status here.
New features, performance improvements, and bug fixes are deployed multiple times per week. While agile, our development cycle relies heavily on a strict system for code quality and security. All code is peer reviewed, and requires multiple levels of acceptance on test/staging environments prior to deployment on production. Key highlights for common questions:
- Changes are checked for security and errors via extensive unit, integration, and static analysis tests.
- Production data is separated from development environments.
- We have completed rigorous reviews by internal security teams for multiple public companies
We maintain automatic access and security logs in multiple locations. All employees are required to use two-factor authentication and strong passwords that are unique from other services. Customer data access is limited, and is allowed only to a small set of employees as required for support and maintenance. Access is further limited to a small whitelist of IP addresses via VPN and require public key authentication.
Individual employee access follows a principle of least access, and access rights are reviewed quarterly.
Password authentication is available by default to end users and validated by entropy to restrict weak passwords. Robin also supports Single Sign-On through SAML 2.0, Google SSO, and ADFS (via SAML 2.0). Users registered through SSO use JIT provisioning. SCIM 2.0 support is offered for automatic provisioning and de-provisioning of users.
Customer data is encrypted when in-transit and at rest. All connections with Robin's services are encrypted and served through SSL/TLS 1.2+. You cannot access the service without using HTTPS. All certificates are verified on both sides with third party authorities. Data is encrypted every step of the way:
- Applications → Cloudflare
- Cloudflare → Amazon Web Services
- REST request → Robin application layer
- Robin application layer → Key Management Service → MySQL session
- API response → Applications
When at rest, customer data is encrypted using a key management system which logs all access automatically. Additionally, passwords are both hashed and salted using one-way encryption, which protect them even in the unlikely event of unauthorized database access. Application credentials are stored separate from the code base. Clients authenticate with Robin using a token system.
Each token has specific access scopes, which can be individually revoked without impacting others on the platform. We are also able to invalidate tokens across the entire platform instantly in the event of a security incident.
Servers are patched regularly to maintain a top security rating. Vulnerabilities are tracked via a combination of automated mailing lists, and critical systems are monitored in real time with Threat Stack IDS and vulnerabilities reviewed daily. Third party network vulnerability and web application penetration tests are completed on an annual basis.
Our engineering team actively contributes to security libraries, including an open source library of Microsoft's NTLM encryption used for secure Exchange authentication.
Robin syncs all calendar data with your existing system (e.g. Exchange), and you can continue to use the audit logs generated there to monitor activity between Robin and your system. Additional activity logs are available for download in our admin portal or upon request from your account manager.
System availability and status updates are also available via status.robinpowered.com and updates.robinpowered.com where you may also subscribe for automated notifications.
When you sign up for a paid subscription, we do not store your credit card information on our servers. We currently use Stripe, which is PCI-Compliant and dedicated to safely storing sensitive payment data. You can find a copy of their security practices here.
We do not store any data with regulatory requirements, such as HIPAA or PCI
Robin's public-facing web service uses the following IP addresses for calendar connection and webhooks. If you host your calendar server on-premise (e.g. Exchange), add these addresses to your firewall's incoming connection whitelist. This will make sure Robin is able to connect.
For additional verification, you can also match user agents containing RobinAPI, which will appear similar to RobinAPI/123456 in the request headers
The majority of application traffic is via standard web traffic port 443.
For networks that whitelist outbound connections, you can verify against our DNS (e.g. *.robinpowered.com) which is signed via DNSSEC. DNSSEC removes the need for specific IP address range since the DNS record itself is secured and can be validated with third party authorities similar to an SSL certificate. You can confirm using this tool from Verisign.
Once an external calendar account is connected to Robin, our cloud service will begin to synchronize data with the designated room calendars. In doing so, a subset of your calendar events and their details will be saved in Robin.
Robin will then keep this data in sync with your calendar system. Events booked through Robin will similarly synchronize the data back to your calendar service, so that Robin and connected calendars stay consistent. Synced event details include:
- Start and end times
- Location (e.g. "Acme Conference Room")
You may apply additional controls by changing the permissions of the associated service account Robin uses to access your calendar system. See an example with private meeting titles with Office 365 and Exchange.
We do not store event attachments. You can learn more about our specific connection practices by service (e.g. Exchange) in our help center.
We maintain automatic access and security logs in multiple locations. All Robin employees are required to use two-factor authentication and strong passwords that are unique from other services. Customer data access is governed by our documented security policies, and limited to a small set of employees as required for support and maintenance. Access is further limited to a small whitelist of IP addresses via VPN that require public key authentication and two factor authentication.
Individual employee access follows a principle of least access and access rights are reviewed quarterly.
Application and customer data is stored redundantly at multiple availability zones within Amazon's data centers with backups available for immediate recovery.
In the event of a security breach, our team will promptly notify you of unauthorized access to your data. Service availability incidents are published to our status page with additional information. See an example incident report.
Should your security team need additional logs for their investigation of an incident determined to affect your organization, our security team will coordinate responsibly provide access as needed.
All employees are governed by documented strict security policies covering acceptable use, customer data, and encryption standards. If you would like to request a copy of these policies, please contact your account manager.
We know these issues are important to you too. If you have any additional questions that aren't answered above or by the help center, please email email@example.com and we'll reply as fast as we can.
If you believe you've found a security vulnerability while using Robin, we'd also like to hear from you. Fixing problems quickly and responsibly is incredibly important to us.