我们不想要你的数据。

是的,我们认为每个人都应该能够探索数据并从中学习。但我们也认为您应该将所有数据都留给自己。

简介

开端:开源、数据库内分析

从一开始,我们就将 Metabase 构建为以我们希望自己的数据被对待的方式来对待您的数据——私密且安全。为了实现这一目标,我们从开源、数据库内分析开始。这意味着

  • 您的数据保留在您的服务器上——并由您控制。 我们绝不会查看或复制您的数据。 句号。
  • 您可以随时查看我们项目的内部结构。 这里没有黑匣子。
  • 现场或 物理隔离部署 并非事后才考虑。

尽管我们提供(明确标记且完全可选的)共享匿名使用情况数据的方式,但大多数人的开源实例根本不需要与我们联系,并且我们非常小心,绝不查看任何人的数据。

从不查看您的数据只是解决方案的一部分。我们还构建了详细的隐私和安全功能,以确保组织内的数据访问安全,包括细粒度的权限控制和对 SSO 的支持。

没有妥协的云

我们一直都知道,我们希望让人们更容易使用 Metabase。当我们决定是时候提供云托管计划时,我们也知道我们希望将对数据安全和隐私的相同承诺带到这些计划中。

为了实现这一目标,我们在设计托管计划时采用了旨在支持该承诺的架构。

Metabase cloud architecture Metabase cloud architecture
Metabase 云架构
  • Metabase 的入门实例就是这样——我们的开源项目方便地与其自己的托管捆绑在一起。 边缘有一些小的调整,但在大多数情况下,它是您喜欢开源 Metabase 的一切,并具有额外的便捷托管。您甚至可以将其保留在附近,在美国、欧洲、拉丁美洲和亚太地区提供云托管选项。
  • 我们设计的架构优先考虑隔离: 我们的每个托管客户都有自己的容器,没有共享集群。这意味着对您的 Metabase 实例的请求就是您的请求。
  • 就像我们的开源产品一样,我们仍然非常不希望看到您的数据。 我们尽可能多地将其保留在您的服务器上,对于我们确实接触到的数据,我们会对其进行传输中加密,并对任何可识别的数据进行哈希处理。这意味着,除非您启用结果缓存,否则您的数据库返回的任何数据都不会存储在我们的终端上,并且我们永远不会看到该内容。

我们的托管计划附带相同的选择加入选项,用于共享匿名使用情况数据,以及相同的隐私和安全功能,以帮助您确保组织内的访问安全。

企业级合规性

SOC 2 Type II

SOC 2 Type II

我们的 SOC 2 Type II 报告证明了我们已实施的控制措施,这些措施管理客户数据的安全性,因为它们映射到美国注册会计师协会 (AICPA) 建立的信托服务原则 (TSP)。

General Data Protection Regulation

通用数据保护条例

在 Metabase,我们致力于使我们的产品、流程和程序符合 GDPR。

California Consumer Privacy Act (CCPA)

《加州消费者隐私法案》(CCPA)

Metabase 在《加州消费者隐私法案》(CCPA) 下充当客户的服务提供商,我们支持客户遵守 CCPA。

数据隐私

数据共享和处理

  • Metabase 遵循 GDPR 和 CCPA 指南,以确保对我们客户的数据保护义务。这包括仅在遵守这些义务的情况下收集、处理和存储客户数据,并为您提供随时访问或删除它的权利。

  • Metabase 提供了在不再出于合法商业目的需要客户数据时删除客户数据的控制措施,并且还为用户提供了选择退出我们网站上的跟踪 Cookie 的选项。

  • Metabase 还要求我们的数据处理供应商证明客户数据的使用仅用于提供服务。

数据处置

  • 作为客户,您可以随时请求删除买方相关数据。
  • 与实例相关的数据会在一段时间不活动后自动删除。
  • Metabase 的托管提供商维护行业标准的安全实践,以确保从存储介质中删除数据。

供应商管理

  • Metabase 已建立协议,要求 二级处理商 遵守保密承诺,并采取适当措施以确保我们的安全态势得到维护。
  • Metabase 通过在使用前和至少每年对其控制措施进行审查来监控这些二级处理供应商。

渗透测试和漏洞披露

渗透测试

  • 除了我们的合规性审计外,Metabase 还聘请独立实体每年至少进行两次应用程序级和基础设施级渗透测试。
  • 这些测试的结果会按优先级排序,并及时进行修复,并与高级管理层共享。
  • 客户可以通过向其成功团队代表请求来接收这些活动的执行摘要。

漏洞披露

  • 我们的工程流程集成了实时漏洞扫描器。
  • Metabase 致力于与世界各地的安全专家合作,以掌握最新的安全技术。我们在 Github 上发布我们的安全公告。

访问管理、加密和端点安全

访问管理

  • Metabase 在配置访问权限时坚持最小权限原则和基于角色的权限;工作人员仅被授权访问他们为了履行当前工作职责而合理必须处理的数据。
  • Metabase 要求员工使用经批准的密码管理器。

加密

  • Metabase 使用行业标准协议加密数据。
  • 传输中的数据使用 TLS 1.2 或更高版本加密。
  • 敏感数据(如连接字符串和设置)在行级别使用 AES256 + SHA512 加密。此外,AWS 还会加密写入数据的磁盘。
  • 密钥管理已到位,用于生产服务的加密密钥。

端点安全

  • 发放给 Metabase 员工的所有工作站均由 Metabase 配置为符合我们的安全标准。
  • 这些标准要求所有工作站都经过正确配置、更新和跟踪,并由 Metabase 的端点管理解决方案进行监控。
  • Metabase 的默认配置将工作站设置为加密静态数据、使用强密码并在空闲时锁定。
  • 工作站运行最新的监控软件以报告潜在的恶意软件。

网络安全和系统监控

网络安全和服务器加固

  • Metabase 将其系统划分为独立的网络,网络之间采用现代化的限制性防火墙,以更好地保护敏感数据。
  • 测试和开发系统托管在与生产基础设施系统分离的网络中。
  • 我们生产队列中的所有服务器都根据行业标准 CIS 基准进行加固。
  • 从开放的公共网络对 Metabase 生产环境的网络访问受到限制,只有负载均衡器可以从 Internet 访问。
  • Metabase 记录、监控和审计所有系统调用,并对指示潜在入侵或数据泄露尝试的调用进行警报。

系统监控、日志记录和警报

  • Metabase 监控服务器和工作站的基础设施,以全面了解安全状态。
  • Metabase 生产网络中所有服务器上的管理访问、特权命令的使用和系统调用都会被记录和监控。
  • 日志分析是自动化的,以检测潜在问题并向负责人员发出警报。

灾难恢复和事件响应

灾难恢复和业务连续性计划

  • Metabase 利用其托管提供商部署的服务,在不同的可用区分布生产运营。这些分布式区域可保护 Metabase 的服务免受连接中断、电力基础设施和其他常见的特定位置故障的影响。
  • Metabase 每天对其核心数据库执行备份和跨区域复制,并支持恢复功能,以在影响任何这些位置的站点灾难事件中保护 Metabase 服务的可用性。
  • 完整备份至少每天保存一次,事务会持续保存。
  • Metabase 每年测试备份和恢复功能,以确保灾难恢复成功。

响应安全事件

  • Metabase 制定了用于响应潜在安全事件的策略和程序。
  • 所有安全事件均由 Metabase 的专门事件响应团队管理。这些策略定义了必须通过事件响应流程管理的事件类型,并根据严重程度对其进行分类。
  • 如果发生事件,受影响的客户将通过我们的客户成功团队的电子邮件收到通知。事件响应程序每年至少测试和更新一次。