Spyglass Security
Last updated
Last updated
At Spyglass, data security, data access and privacy are top of mind when designing our platform and business processes. We employ industry best practices to ensure that customer data is completely safe at all times. Our security program is endorsed by our executive team and is involved in all aspects of operations, including, but not limited to:
Application Security
Infrastructure & Network Security
Compliance
Privacy
Spyglass is a platform that provides access management tools on top of data warehouses (e.g. Snowflake). Provided services include: visualization, insights, recommendations, and self-service workflows in order to improve an organization’s ability to manage and secure user access to data.
Our platform allows data engineering teams to understand who can access what, construct data access policies and automatically audit data access, enhancing data governance and reducing risk of improper data access.
Spyglass consists of a web user interface, an API layer, cache storage, a real-time database, and third-party platform storage (e.g. Snowflake). The system relies on Google SSO for Authentication, Cloud Functions, Cloud Run, Cloud Firestore, and Secrets Manager as core infrastructure. Database writes are sent directly to third-party platforms; whereas reads may be stored temporarily in cache storage.
All connections to Spyglass' web application are encrypted by default using industry-standard cryptographic protocols (TLS 1.2+). Any attempt to connect over an unencrypted channel (HTTP) is redirected to an encrypted channel (HTTPS). To take advantage of HTTPS, your browser must support encryption protection (all versions of Google Chrome, Firefox, and Safari).
Spyglass uses Snowflake Key Pair Authentication to connect to an customer’s Snowflake instance. An organization-specific RSA private key is stored in Google Secret Manager, so data is encrypted in transit with TLS and at rest with AES-256-bit encryption keys.
The RSA private key is accessed when reading or writing from a customer’s Snowflake instance. The private key is only accessed for the purpose of setting up a SQL connection, and it is never transmitted or stored in plain text.
Physical and environmental security is handled entirely by our cloud service providers. Each of our cloud service providers provides an extensive list of compliance and regulatory assurances, including SOC 1/2-3, PCI-DSS, and ISO27001.
Spyglass reads data from its customers’ Snowflake instance as part of its regular operations. This data includes: users, roles, Snowflake account-level tables (such as user-to-role mappings and access history), and any tables created and managed by Spyglass.
For all other Snowflake objects (i.e. databases, schemas, tables, and views), Spyglass only reads names, identifiers, and metadata. Spyglass will never have access to the contents of any other objects in its customers’ Snowflake instance(s). The SPYGLASS_USER that Spyglass provisions on account creation is never granted permission to access the contents of the mentioned Snowflake objects.
Spyglass has advanced Role Based Access Control (RBAC) functionality, which allows for granular control over what each user can and cannot do in the platform in regards to all create, update, delete, execute and read actions.
Spyglass offers a comprehensive audit trail of changes that take place in the customers Snowflake instance including a detailed description, time of the event and attribution.
Spyglass relies on a few major Google Cloud systems: Authentication, Cloud Functions, Cloud Run, Cloud Firestore, and Secrets Manager. These systems are deployed in Google’s us-central1 region across four availability zones. Spyglass also relies on additional third parties including Snowflake for data storage.
During onboarding, a customer employee with ACCOUNTADMIN role creates the following objects:
SPYGLASS_USER – User that executes Spyglass queries, secured by a unique RSA private key.
SPYGLASS_ROLE – Role that grants Spyglass access to the customer’s Snowflake instance.
The SPYGLASS_ROLE is granted a few roles:
SECURITYADMIN – Role that can manage any object grant globally, as well as create, monitor, and manage users and roles. More detail available in Access control: system-defined roles.
APPLY MASKING POLICY – Grants the ability to set a Column-level Security masking policy on a table or view column and to set a masking policy on a tag. More detail available in Security access control privileges.
APPLY TAG – Grants the ability to apply tags to objects. More detail available in Security access control privileges.
SNOWFLAKE.GOVERNANCE_VIEWER – Database role for the Account Usage schema that grants access to the following views: MASKING_POLICIES, QUERY_ACCELERATION_ELIGIBLE, QUERY_HISTORY, POLICY_REFERENCES, ROW_ACCESS_POLICIES, TAG_REFERENCES, ACCESS_HISTORY.
SNOWFLAKE.SECURITY_VIEWER – Database role for the Account Usage schema that grants access to the following views: POLICY_REFERENCES, GRANTS_TO_ROLES, GRANTS_TO_USERS, LOGIN_HISTORY, ROLES, SESSIONS, USERS.
The Spyglass application is expected to create new resources as part of its normal operations: new users, roles, schemas, tables, and other objects. Spyglass may grant itself other roles and privileges in the future beyond the scope of those mentioned above.
Because of this, Spyglass can provide its customers with a transparency report that describes its active roles, privileges, and managed objects, as well as a summary of its access.
We take the security of this software very seriously. To report any security issues or potential vulnerabilities, send an email to security@spyglass.software.
At a minimum, please include the following:
Description of the vulnerability.
Steps to reproduce the issue.
We'll send a confirmation email to acknowledge your report, and we'll send an additional email when we've identified the issue positively or negatively.
