Delegation of security features
In most places we leverage existing security solutions by industry-leading 3rd party providers, such as Google Cloud platform. This removes the majority of exploitable vulnerabilities in cloud-based web apps of similar nature to our product. We refer you to their documentation in those instances below, but we provide an overview of where and how those solutions are implemented.
Industry Best Practices adhered to
Some Industry best practices adhered to:
Principle of least privilege
All data is encrypted in transit
All data is encrypted at rest
Web Security Scanning
Proactive Data Loss Prevention Scanning
Web Security Scanning
Offsite Backups (Data-loss prevention)
All nodes are Private, they are not allocated Public Addresses
Automated Key Rotation
Database Admin Access and Credentials
Our database is provisioned by the Google Cloud Platform, in particular, the Firebase suite of products. Read / write access to the data is restricted to administrative service accounts with private key credentials (x509).
Only our own back-end servers perform read / write via these admin service accounts, and no other services or 3rd parties are privy to these credentials. We ensure these keys are never exposed through:
We avoid creating static copies/downloads of private keys and rely on Google's run-time environment to automatically manage admin credentials in cloud server deployments
Exclusion from code repositories and version management systems (Github, Git)
Role-based management of our app ensures that only our development team (and not, for example, sales) has access to these keys to download or use.
Client authentication and Firewall
We ensure that only our web-browser app can successfully perform REST requests to our server API. This is done through both client authentication, as well as a firewall on our server.
In client authentication, we mint and sign JWTs (JSON Web Tokens) for a limited duration session. Clients must provide this authentication token on all HTTPS requests to our servers, and must refresh them regularly. The signing and verification of tokens is entirely handled by a Google Firebase Authentication server. (https://firebase.google.com/products/auth/).
Development versions of our app are subject to a Google-provisioned Firewall to prevent requests from outside our development team. (https://cloud.google.com/appengine/docs/standard/python/creating-firewalls).
We do not store any employee passwords, as authentication happens through federated providers (Microsoft, Google) through SSO (see Client Roles below).
Federated Provider Access Tokens
In performing 3rd party calendar and HRIS integration, we obtain access/refresh tokens or API keys with the right to read customer's HRIS data or calendars organization-wide. These tokens/keys are stored securely (encrypted) in a secondary database. In order to make requests to Google Calendar, Outlook Calendar or HRIS vendor APIs with these tokens, we decrypt these credentials at runtime.
Tokens or keys must always be accompanied by a secondary credential, typically client secret or username/password respectively. We ensure that the tokens/keys and their respective secondary credential are stored in separate environments, accessed by different admin service accounts.
Client access and roles
Users login to our web app with their organization Outlook or Gmail credentials. If you have single-sign-on (SSO) enabled, this will work with these credentials automatically.
Only a customer's program administrators have rights to access the program administrator portal, which contains information regarding mentor/mentee pairings, feedback given by employees, and other information sensitive across employees in the organization. All other employees only have access to pages and features in the web app for managing their own mentorship experience.
In the case of employees leaving or joining a customer's organization, we rely on two factors to expire or grant access to the platform and their account:
They must be able to provide their identity through Outlook or Gmail login, thus their email and password must be valid
They must be deemed an active employee in the organizational data provided by the customer